> -----Original Message----- > From: Worley, Dale R (Dale) [mailto:[email protected]] > Sent: April-04-12 12:22 > 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.
That seems to be the case. Unfortunately, when negotiating with a vendor over who needs to make a fix, not having a standard document to refer to makes for an easy stalemate. > > 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. These are excellent lists. Are these documented in anyway, unofficially? > > 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. This is exactly what I suggested to our vendor as the 'correct' solution. They basically feel that they should forward on any and all packets they receive without considering the source. Obviously, they would prefer that we modify our system to remove the silence packets. Hence the stalemate we seem to have found ourselves in. > > > 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. We use Dialogic boards and the Natural Access Fusion API for managing RTP streams and we just don't tear down the stream while the REFER is in progress. This simplifies handling the recovery of the failed REFER since we don't need to re-establish the connection. However, as long as the stream is up it continues to stream the data is receiving, which is silence. I agree with your assessment here, but the fact is we have to do work to stop RTP and this is the first time this approach has caused a problem. I may plan to fix it in the future, but the impact to the current release is too large to consider as a patch fix. > > Dale Thanks for the input Dale. James. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
