< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

[SFtrack] Commented: (XECS-1615) Park server does not stop transmitting media stream even after it is sent a BYE


    [ 
http://track.sipfoundry.org/browse/XECS-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_30872
 ] 

huijun yang commented on XECS-1615:
-----------------------------------

Tested with callwithus.com and les.net, indeed the "HACK" works! Thanks, Ranga!
But we want to be clear that for this particular issue, the issue is because of 
the way  how some particular ITSPs handle hold request, and it is not a bug in 
sipXecs. Now Ranga's fix can satisfy them as well now ;-)

Although I don't think the fix will affect other ITSPs that have worked in the 
scenario, such as AT&T, or BT, but to be more cautious,  we probably want to 
verify it before close the issue.  As I don't have account for those ITSPs, I 
will assign the issue back to Ranga for now.



> Park server does not stop transmitting media stream even after it is sent a 
> BYE
> -------------------------------------------------------------------------------
>
>                 Key: XECS-1615
>                 URL: http://track.sipfoundry.org/browse/XECS-1615
>             Project: sipXecs
>          Issue Type: Bug
>          Components: sipXpark
>    Affects Versions: 3.11.5
>            Reporter: M. Ranganathan
>            Assignee: huijun yang
>            Priority: Critical
>             Fix For: 3.11.6, 4.0
>
>         Attachments: callwithus.cap.gz, callwithus.pcap.gz, snapshot.tar.gz
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> Scenario
> -------
> Make call via sipxbridge
> Make an outbound call with callwithus.com to pstn number
> Do an attended transfer to extension 201 from extension 203. 
> Music on hold is playing when transfer happens ( as expected ).
> Symptom
> ------
> Music on hold continues to play even when BYE is sent to park server.
> Strangely, it works fine for AT&T. Does not work for callwithus.com ( the 
> flow is the exact same ).
> I can also get it to stop by re-inviting the ITSP ( I am not sure what this 
> has to do with it ).
> Included are the debug logs and wireshark capture (unfiltered as requested by 
> Dale).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://track.sipfoundry.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira