[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_30860
]
huijun yang commented on XECS-1615:
-----------------------------------
Should be more clear on my previous comment...
Then when sipXbridge with ACK with "sendrecv" corresponding to the 200 OK of
the RE-INVITE, callwithus.com still keeps playing the music.
> 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
