I agree with Dale, with an added comment

On 11/19/2010 5:04 PM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: sip-implementors-boun...@lists.cs.columbia.edu 
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Tarun2 Gupta 
> [tarun2.gu...@aricent.com]
>
> Consider the following scenario:
>
>   1.  A sends INVITE to B with SDP 1 as offer.
>   2.  B sends reliable 183 with answer having 1 inactive stream only (with 
> a=inactive)
>
> Now my question is that
>
>   1.  Is B's behavior correct (with respect to reliable/non-reliable 18x) ? 
> Can you give me some reference (RFC/draft) in support of your answer ?
>   2.  In my case, A is sending PRACK followed by CANCEL. Is this correct?

Its not *incorrect* - you are free to cancel if you wish, for whatever 
reason you wish. So if you don't wish to establish a call with the media 
in inactive state you may do this.

BUT its probably a bad idea, because you may be blocking communication 
when your user would wish you had not. There are a variety of reasons 
why the UAS might do this. For instance, some service providers may 
cause this behavior because they don't want to exchange media until the 
200 because that is when they can start billing for it.

I think it would probably be better to allow the call to continue and 
let the user decide. But in the end it is an implementation choice.

        Paul

> ________________________________
>
> Both of these are correct because no specification forbids them.  In 
> particular, an offered m= line with a=sendrecv may be answered with 
> a=inactive per the SDP offer/answer specifications.
>
> Dale
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to