> 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
