On Fri, Sep 19, 2008 at 7:08 AM, M. Ranganathan <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 10:13 PM, M. Ranganathan <[EMAIL PROTECTED]> wrote: >> On Thu, Sep 18, 2008 at 6:28 PM, Huijun Yang <[EMAIL PROTECTED]> wrote: >>>> I am investigating http://track.sipfoundry.org/browse/XECS-1615, and >>>> trying to find out where park server > initiates media playing request >>>> in the code. I thought ParkedCallObject::playAudio() was the one, but >>>> apparently it isn't. I commented out > the call >>>> of ParkedCallObject::playAudio() for experiment purpose but music still >>>> plays when call parked. I am not sure >>>> > where it comes from and who initiates the play request. I must >>>> have gotten into a wrong place. Does anyone know the code better, > and >>>> point me the right direction? >>> >>> I got the answer. It acturely comes from ITSP's MOH server. >> >> >> >> >> Astonishing! Could you share some details of how you concluded this. >> Could you kill the park server ( i.e. kill -9 ) when the Music On Hold >> is being played and if you do so, do you still hear the music? What >> signals the ITSP to play music on hold? All I do is to re-INVITE it to >> the Park Server. It does not know that it is being re-invite to the >> park server. How do they figure out that its time to start playing >> Music On Hold. Let me know if you want to try with another ITSP ( for >> example les.net ) to check your hypothesis. >> >> >> >> Thanks >> >> >> Ranga >> > > > As I noted on the issue, AT&T does not have this problem but my > conjecture was that they use a different codec and hence that problem > did not occur. > > > Note that this does not happen when I put the ITSP side on hold ( > playing music on hold from sipx at that time ) and resume so I wonder > what could be triggering this behavior on transfer only. The ITSP > never sees REFER so I do not think they can tell the difference. > > If this is happening because of ITSP settings / strange behavior, I > would like to verify by experiment with other ITSP and by sipxproc > --stop on the park server when the call is being transferred to make > sure its not something we are doing. We must surely make a note of it > on Wiki if this an ITSP issue. Perhaps there is a setting for the > ITSP account for music on hold. I will check into that. I will mail > details on the les.net account to double check. > >
It was the ITSP playing music indeed. Kudos to Huijun for figuring this out. Good work. There does not seem to be a way of stopping it by configuration on the iTSP ( callwithus.com ) -- at least I did not find any. So now we have three sources, phones, park server and ITSP all wanting to play Music On Hold. all ready to play musaac in your ear and add to the cacophony of life. The "fix" that I just committed ( to be verified by Huijun ) turned out to be relatively simple -- edit the sdp in the ack to change the attribute to "sendrecv" (whereas it ought to be "sendonly" ) en route in the ACK. Ranga > >> >> >> >>> >>> Thanks, >>> >>> Huijun >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> M. Ranganathan >> > > > > -- > M. Ranganathan > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
