Attila Sipos wrote:
>>> it is not comparable to forking scenario.
>
> As I tried to explain in my e-mail, a UAS can do forking by itself
> if it sends different to tags in its responses.
> Though not usual, it is perfectly valid.
>
> If the UAS sent these 2 responses without different to tags,
> then the UAS is behaving wrongly.
Why? There is nothing wrong with this.
The 183 indicates that the UAS is working on without indicating if
alerting has happened, and establishes a media path that needn't have
anything to do with ringback. The 180 indicates that alerting is
occurring at the UAS, and also doesn't say anything (pro or con) about
whether inband ringback is being sent.
There is in fact no way to know whether inband ringback is being sent.
The UAC can tell it is receiving inband media, but not whether it is
ringback. The best it can do is play inband media if it receives it on
the assumption that it might be ringback or at least something the
caller would rather hear than ringback.
This gets more complex if there is forking. The UAC has lattitude to
decide how best to render this to give the best user experience.
Paul
> Regards,
>
> Attila
>
>
>
> -----Original Message-----
> From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED]
> Sent: 01 November 2007 11:20
> To: Attila Sipos; Brocha Strous; [email protected]
> Subject: RE: [Sip-implementors] 180 with body AFTER 183 with body - is
> itvalid
>
> Inline ...
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Attila Sipos
>> Sent: Thursday, November 01, 2007 6:34 AM
>> To: Brocha Strous; [email protected]
>> Subject: Re: [Sip-implementors] 180 with body AFTER 183 with body - is
>> itvalid
>>
>>
>> it is ok because this is what happens in forking scenarios.
> I agree that it is ok for UAS to send 180 with sdp after 183 with sdp,
> but it is not comparable to forking scenario. Because in case of forking
> 18xs coming from different forked endpoints will have different to-tags
> and so each will have a separate early dialog with the UAC.
>
> Sanjay
>
> _______________________________________________
> 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
