[SFtrack] Updated: (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:all-tabpanel
]
M. Ranganathan updated XECS-1615:
---------------------------------
Priority: Critical (was: Major)
I cannot fully test the functionality unless the MOH stops playing after I
transfer the call hence changed severity ( per Scott's advice). If I block
re-invite things work but this does not exercise full functionality. Note that
this condition can be re-created using sipxbridge and calling the ITSP
callwithus.com ( please contact me for account details ).
> 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
> Reporter: M. Ranganathan
> Assignee: Dale R. Worley
> Priority: Critical
> Attachments: callwithus.pcap.gz, snapshot.tar.gz
>
>
> 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
