Hi Dale, Wouldn't it make better sense for the Transferee to send an inactive SDP to the transferor once it detects that there's early media on the secondary call-leg? I feel that the media termination endpoints (UA in this case) should use the following logic: At a given time, there could be multiple media paths connected to an endpoint, but only one of them must be active.
RFC 3264 says: =========== Once the answerer has sent the answer, it MUST be prepared to receive media for any recvonly streams described by that answer. Same goes for the Offerer. So the transferee MUST be ready to receive media on both primary and secondary call-leg. Therefore it would be prudent for the Transferee ( the third-party vendor UA in this case ) to make the held call-leg inactive and be ready to receive early media on the active (secondary) call-leg. Cheers, Pranab -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Worley, Dale R (Dale) Sent: Wednesday, April 04, 2012 9:52 PM To: James Ryan; [email protected] Subject: Re: [Sip-implementors] Question about SIP Refer with 183-Early Media from the third party > From: James Ryan [[email protected]] > > Our implementation continues to stream silence to the transferee while > the transferee begins to play out the early media data. In this > scenario, the UA interleaves our silence packets with the early media > packets from the third party. There have been discussions from time to time how a UA should handle a situation where it receives multiple RTP streams. There are no standards for this, because it is not part of the protocol design, it is not visible on the wire. In the context of initiating a call, the best models run along these lines: The "sources" that the UA considers are: - RTP streams being received - a locally-generated ringback tone for each 180 Ringing that has been received (or perhaps one ringback tone for all of the 180's together) >From these sources, remove any source that is known to have been dropped from the call because: - the UAC has received a 199 response (RFC 6228) - the UAC has received a final response for a fork of the call that it generated (e.g., because the UAC received and acted on a 3xx response) A locally-generated ringback tone is associated with the to-tag of the 180, and so the to-tag of the above responses tells which ringback tone source to terminate. In the case of RTP streams, they can only be associated with to-tags when one receives SDP in a response whose media address/port matches the network source of the RTP. Also remove any source that is silent, even if it appears to be from a still-valid source, since there's no point in playing silence. If more than one source remains, the UAC has to decide what to do with them. Probably the best strategy is to mix them and present the mixed output to the user. In the case of a REFER, it seems to make sense that the on-hold media from the referrer should be considered a source, but with a lower priority than the sources from the new call leg. That is, if there are no sources from the new call leg, play the referrer's on-hold media, but if there are new sources, disregard the referrer's on-hold. > In processing the REFER our peer receives a 183 from the third party > that sends SDP with Early Media. [...] They also suggest that we > should do this after receiving a NOTIFY with a 183 SipFrag. Though that is problematic if the new call leg receives a 183 from some fork (which provides early media), and then that fork terminates (hence no more media), and some time passes before another fork provides more early media (because on-hold media could still be available). > Our implementation continues to stream silence to the transferee It's not clear to me why you do this, since these packets contain no information. If you're sending RTCP for the stream, the RTCP shows that the stream is still alive. If you need to keep a NAT pinhole, you could sent one silence packet every several seconds. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
