[Sip-implementors] Cancel part of Invite transaction?

[Mushtaq Ilyas]

Hello all

Is a Cancel request (meant to cancel an invite request) part of the Invite transaction?
Because if it is doesn't it cause sever problems in the statemachine (Invite server and client FSMs).

Regards
Mushtaq Ilyas




___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html

[Dale.Worley]

From: Mushtaq Ilyas <mushtaqilyas at yahoo.com>

Is a Cancel request (meant to cancel an invite request) part of the
Invite transaction?

No, the CANCEL has its own transaction (and thus gets its own
response).

Dale

[Rayees Khan]

Here is a snippet from RFC 3261

SIP Transaction: A SIP transaction occurs between a client and
a
server and comprises all messages from the first request
sent
from the client to the server up to a final (non-1xx)
response
sent from the server to the client. If the request is
INVITE
and the final response is a non-2xx, the transaction also
includes an ACK to the response. The ACK for a 2xx
response to
an INVITE request is a separate transaction.

I guess it specifies that CANCEL is part of the transaction.


regards
Rayees



-----Original Message-----
From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of Mushtaq
Ilyas
Sent: Thursday, April 26, 2007 2:00 PM
To: sip-implementors at cs.columbia.edu
Subject: [Sip-implementors] Cancel part of Invite transaction?

Hello all

Is a Cancel request (meant to cancel an invite request) part of the
Invite transaction?
Because if it is doesn't it cause sever problems in the statemachine
(Invite server and client FSMs).

Regards
Mushtaq Ilyas




___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign
up for your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07
.html
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________




----------------------------------------------------------------------------------
IMPORTANT The information contained in this e-mail any
attachments is intended only for the named recipient and may be
privileged or confidential.

If you are not the intended recipient, please notify us immediately
on [phone] and do not disclose, copy, distribute
or take any action based on the contents of this e-mail.

You should understand and accept that, when communicating with us
by e-mail, it is not a totally secure communication medium.

We accept no liability for any direct, indirect or consequential loss
arising from any action taken in reliance on the information contained
in this e-mail and give no warranty or representation as to its accuracy
or reliability.

DIGITALK has the facility to monitor and read both incoming
and outgoing communications by e-mail. In line with industry efforts
to reduce the proliferation of Un-Solicited SPAM messages,
DIGITALK uses various methods including Reverse-DNS
lookups and ban-lists to prevent malicious content reaching our users.

This message and any attachments has been scanned for known
viruses. However, we would advise you to ensure the content is
indeed virus free. We do not, to the extent permitted by law, accept
any liability (whether in contract, negligence or otherwise) for any virus
infection and/or external compromise of security and/or breach of
confidentiality in relation to transmissions sent by e-mail.

VAT No: GB 876 3287 81. Reg No: 3080801
Place of Registration: England
Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes
----------------------------------------------------------------------------------"

[Ryan Mitchell]

CANCEL is not a distinct transaction. In particular, the CANCEL request
should have the same cseq value as the INVITE, and the UAS sends a single
final response.

ex:

INVITE ----->
<----- 1xx
CANCEL ----->
<----- OK

[Ryan Mitchell]

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.

[Mushtaq Ilyas]

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 <brak2718 at gmail.com>
To: sip-implementors at cs.columbia.edu
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.
--
Ryan Mitchell
Telecom Logic, LLC
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors







___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html

[Ravi Rupela]

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

Post by Rayees Khan
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 <brak2718 at gmail.com>
To: sip-implementors at cs.columbia.edu
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.

[Muazzam Arslan Bhatti]

Post by Mushtaq Ilyas
How would one identify that the 200 is for the Invite or Cancel?

by looking at the method in CSeq of 200 response like CSeq : 2 INVITE OR
CSeq : 2 CANCEL

further if 200 OK for INVITE is issued CANCEL request is no more effective.


----- Original Message -----
From: "Mushtaq Ilyas" <mushtaqilyas at yahoo.com>
To: "Ryan Mitchell" <brak2718 at gmail.com>; <sip-implementors at cs.columbia.edu>
Sent: Monday, April 30, 2007 11:29 AM
Subject: Re: [Sip-implementors] Cancel part of Invite transaction?

Post by Mushtaq Ilyas
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."

Post by Mushtaq Ilyas
Yes CANCEL is a distinct transaction but with same response context as the

INVITE it is cancelling?

Post by Mushtaq Ilyas
The problem however is that using thesame response context causes an

abnormality is the state-machine.

Post by Mushtaq Ilyas
UA Client Proxy Server
================================
---->Invite
<==180
---->Cancel
<==200
---->Cancel
<==200 or 487 (SIP Proxy

Server or UA Server)

Post by Mushtaq Ilyas
How would one identify that the 200 is for the Invite or Cancel?
Regards
Mushtaq Ilyas
----- Original Message ----
From: Ryan Mitchell <brak2718 at gmail.com>
To: sip-implementors at cs.columbia.edu
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.
--
Ryan Mitchell
Telecom Logic, LLC
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today

http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.htm
l

Post by Mushtaq Ilyas
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[A B]

CSeq contains sequence number and the method. CSeq header in the response to
the CANCEL request shall contain the token "CANCEL".

regards

Post by Rayees Khan
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 <brak2718 at gmail.com>
To: sip-implementors at cs.columbia.edu
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.
--
Ryan Mitchell
Telecom Logic, LLC
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today
http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Attila Sipos]

Post by Mushtaq Ilyas
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?

The CSeq will tell you whether it is for method "INVITE" or method "CANCEL".

e.g.
CSeq: 1272 INVITE
or
CSeq: 1272 CANCEL


Regards,

Attila





-----Original Message-----
From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu]On Behalf Of Mushtaq
Ilyas
Sent: 30 April 2007 07:29
To: Ryan Mitchell; sip-implementors at cs.columbia.edu
Subject: Re: [Sip-implementors] Cancel part of Invite transaction?


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 <brak2718 at gmail.com>
To: sip-implementors at cs.columbia.edu
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.
--
Ryan Mitchell
Telecom Logic, LLC
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors







___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html