There are no syntax problem.
("The Request-URI, Call-ID, To, the numeric part of CSeq, and From header
fields in the CANCEL request MUST be identical to those in the
request being cancelled, including tags. A CANCEL constructed by a
client MUST have only a single Via header field value matching the
top Via value in the request being cancelled" )
+++++
INVITE sip:[email protected];transport=udp SIP/2.0
From: "AHTV Ric
1"<sip:[email protected]>;tag=13e7858-7a8c200a-13c4-5506-38-3625c56-38
To: <sip:[email protected];transport=udp>
Call-ID: 14800c0-7a8c200a-13c4-5506-38-1b91bc30-38
CSeq: 1 INVITE
Via: SIP/2.0/UDP 10.32.140.122:5060;rport;branch=z9hG4bK-38-dc39-6b4deb27
CANCEL sip:[email protected];transport=udp SIP/2.0
From: "AHTV Ric
1"<sip:[email protected]>;tag=13e7858-7a8c200a-13c4-5506-38-3625c56-38
To: <sip:[email protected];transport=udp>
Call-ID: 14800c0-7a8c200a-13c4-5506-38-1b91bc30-38
CSeq: 1 CANCEL
Via: SIP/2.0/UDP 10.32.140.122:5060;rport;branch=z9hG4bK-38-dc39-6b4deb27
+++++
See rfc
9.1 Client Behavior
A CANCEL request SHOULD NOT be sent to cancel a request other than
INVITE.
Since requests other than INVITE are responded to immediately,
sending a CANCEL for a non-INVITE request would always create a
race condition.
Rosenberg, et. al. Standards Track [Page 53]
RFC 3261 SIP: Session Initiation Protocol June 2002
The following procedures are used to construct a CANCEL request. The
Request-URI, Call-ID, To, the numeric part of CSeq, and From header
fields in the CANCEL request MUST be identical to those in the
request being cancelled, including tags. A CANCEL constructed by a
client MUST have only a single Via header field value matching the
top Via value in the request being cancelled. Using the same values
for these header fields allows the CANCEL to be matched with the
request it cancels (Section 9.2 indicates how such matching occurs).
However, the method part of the CSeq header field MUST have a value
of CANCEL. This allows it to be identified and processed as a
transaction in its own right (See Section 17).
If the request being cancelled contains a Route header field, the
CANCEL request MUST include that Route header field's values.
This is needed so that stateless proxies are able to route CANCEL
requests properly.
The CANCEL request MUST NOT contain any Require or Proxy-Require
header fields.
Once the CANCEL is constructed, the client SHOULD check whether it
has received any response (provisional or final) for the request
being cancelled (herein referred to as the "original request").
If no provisional response has been received, the CANCEL request MUST
NOT be sent; rather, the client MUST wait for the arrival of a
provisional response before sending the request. If the original
request has generated a final response, the CANCEL SHOULD NOT be
sent, as it is an effective no-op, since CANCEL has no effect on
requests that have already generated a final response. When the
client decides to send the CANCEL, it creates a client transaction
for the CANCEL and passes it the CANCEL request along with the
destination address, port, and transport. The destination address,
port, and transport for the CANCEL MUST be identical to those used to
send the original request.
If it was allowed to send the CANCEL before receiving a response
for the previous request, the server could receive the CANCEL
before the original request.
Note that both the transaction corresponding to the original request
and the CANCEL transaction will complete independently. However, a
UAC canceling a request cannot rely on receiving a 487 (Request
Terminated) response for the original request, as an RFC 2543-
compliant UAS will not generate such a response. If there is no
final response for the original request in 64*T1 seconds (T1 is
Rosenberg, et. al. Standards Track [Page 54]
RFC 3261 SIP: Session Initiation Protocol June 2002
defined in Section 17.1.1.1), the client SHOULD then consider the
original transaction cancelled and SHOULD destroy the client
transaction handling the original request.
Thanks!
Valdemar
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of ext
Pavesi, Valdemar (NSN - US/Irving)
Sent: Wednesday, April 20, 2011 9:28 AM
To: ext Chandan Kumar; [email protected]
Subject: Re: [Sip-implementors] SIP request Cancel Issue
Ckumar.,
I think the client is terminating the dialog after receives a 200OK for CANCEL.
Normally we do have:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Uac --------------------> UAS
----invite-------------->
<----100/180/------------
---cancel------(cseq cancel)---------->
<---487 ( cseq INVITE)----
-----ack-(Cseq INVITE)--->
<-------200OK for cancel---(cseq cancel)-
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
The cancel just tell to server that there is a intention to cancel the dialog.
In your case after 200ok Then the client must wait for 487 and send ACK and
then can clean the dialog.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Regards!
Valdemar
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of ext
Chandan Kumar
Sent: Wednesday, April 20, 2011 8:21 AM
To: [email protected]
Subject: [Sip-implementors] SIP request Cancel Issue
Hi ,
Iam facing an issue with Cancel. Please find the Cancel.txt which has the
call cancel sequence..
Voip-1 makes a call throough Server ,before Voip2 accepts it cancels call.
1)Voip-1 sends Cancel ,Server responds with 200 Ok.
2)Server sends 487 Request Termination ,But Voip1 is not responding .Whats
exactly the issue here .?Please Can some one clarify here.
3) Voip1 sends Cancel request for which server responds with 481 call doesn't
exist
4) Voip1 Sends ACK .Even After this Server keep sending 481 call doesn't exist.
Voip 1: 10.32.140.122
Voip 2: 10.32.140.139
Server: 10.32.128.20
Please Can some one let me know where excatly the issue is.
Best Regards,
Ckumar.
_______________________________________________
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
