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.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
