Hi Mustaq,
200 Ok response of any request contains method name in Cseq request
of which it is responding.....
--
Confidence comes not from always being right but from not fearing to be
wrong.....
Ravi Rupela
Software Engineer
EliteCore Technologies
Mushtaq Ilyas wrote:
> RFC 3261
> "While a CANCEL request is handled in a stateful proxy by its own server
> transaction, a new response context is not created for it. Instead, the
> proxy layer searches its existing response contexts for the server
> transaction handling the request associated with this CANCEL. If a
> matching response context is found, the element MUST immediately return a
> 200 (OK) response to the CANCEL request. In this case, the element is
> acting as a user agent server as defined in Section 8.2. Furthermore, the
> element MUST generate CANCEL requests for all pending client transactions
> in the context as described in Section 16.7 step 10."
>
> Yes CANCEL is a distinct transaction but with same response context as the
> INVITE it is cancelling?
> The problem however is that using thesame response context causes an
> abnormality is the state-machine.
>
> UA Client Proxy Server
> ================================
> ---->Invite
> <==180
> ---->Cancel
> <==200
> ---->Cancel
> <==200 or 487 (SIP Proxy
> Server or UA Server)
>
> How would one identify that the 200 is for the Invite or Cancel?
>
>
> Regards
> Mushtaq Ilyas
>
>
> ----- Original Message ----
> From: Ryan Mitchell <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Saturday, 28 April, 2007 11:34:34 PM
> Subject: Re: [Sip-implementors] Cancel part of Invite transaction?
>
> My mistake -- CANCEL is a distinct transaction (RFC 3261 sec 9.1). The cseq
> value is used to match up on the INVITE that's being cancelled.
>
> For reverse compatibility with RFC 2543, the UAS may or may not send a 487
> (request terminated) response to the cancelled INVITE. I suspect this may
> be the source of confusion -- with only a single 200 OK response for the
> cancel you might guess there's only 1 transaction.
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
