You may have to work this out based on which of you has the most vested
interest in making the end user happy. If you work with a bunch of
phones, and this is the only one misbehaving, then you can perhaps argue
that this vendor's product isn't up to the quality of the others, and so
it ought to shape up.
OTOH, if the device vendor has an incumbent relationship with the end
customer, and bringing in your product is causing this problem, then the
pressure may be on you to adapt.
Good Luck,
Paul
On 4/4/12 4:46 PM, James Ryan wrote:
>
>
>> -----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
