> -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Paul Kyzivat > Sent: April-04-12 11:22 > To: [email protected] > Subject: Re: [Sip-implementors] Question about SIP Refer with 183-Early > Media from the third party > > On 4/3/12 2:51 PM, James Ryan wrote: > > We are currently having an argument with a vendor regarding how the > handle media streams during the REFER process. We are issuing a REFER > request to our peer after placing them on sendonly hold per the standard > practice in RFC3515. In processing the REFER our peer receives a 183 from > the third party that sends SDP with Early Media. 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. The result is > garbled audio. > > > > The vendor is suggesting that out silence packets are causing this behaviour > and we should modify our logic to remove ourselves from the media stream > after issuing the REFER request. They also suggest that we should do this > after receiving a NOTIFY with a 183 SipFrag. Does anyone have any > experience dealing with a scenario like this? Do any of the specs deal > specifically with how to handle media in this case? > > AFAIK there are no written guidelines on what to do in this regard. > But this is not the only circumstance in which a UA can be receiving multiple > RTP streams and must figure out the best way to render. (E.g. > this can happen at call initiation due to parallel forking and multiple early > dialogs with media.) The recipient should have some policy to handle this in a > way that provides a good user experience. > > The fact that this vendor is counting on particular sorts of good behavior by > multiple uncoordinated UAs is not a good plan.
We are in a tough position here as it seems that we may in fact be a poorly behaved UA in this regard. Nonetheless, this is exactly the way I have presented our stance to this vendor. In this specific case we are targeting a PSTN endpoint via a 'sip trunking' gateway provider, so there is no expectation that forking will occur but nonetheless, this is a very valid point I didn't consider. As I mentioned in the previous message, we have pretty much entered a stalemate with neither party wanting change to deal with this issue. The forking angle may give us a bit of leverage to push the vendor to make the fix now. However, I'm starting to feel that I can improve our UA interoperability by make the change to tear down the RTP connection during the REFER. Thanks for the response. James > > Thanks, > Paul > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
