On 4/28/13 4:47 AM, Aman wrote:
> Thanks Paul for your response.
>
> CANCEL is correctly formed, here are the INVITE and CANCEL messages sent
> by UAC,
OK. It looks valid to my eye.
(Note that the use of user=phone is incorrect, because the user part is
not valid tel uri syntax. But this is unrelated to the current question.)
> INVITE sip:1...@yy.xx.xy.yx;user=phone SIP/2.0
> Via: SIP/2.0/UDP
> XXX-xxxxxxxxxxx.XXX:5060;branch=z9hG4bK_11462326110041973718
> From:
> "Display_Name"<sip:5...@xxx-xxxxxxxxxxx.xxx;user=phone>;tag=1_1146_f232611_d526_CtkM00017D
> To: <sip:1...@yy.xx.xy.yx;user=phone>
> Call-ID: 9...@xxx-xxxxxxxxxxx.xxx
> CSeq: 1 INVITE
> Max-Forwards: 70
> Supported: 100rel,timer,replaces,unknown
> Contact: <sip:5...@xxx-xxxxxxxxxxx.xxx:5060;transport=udp>
> Allow:
> INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE
> Min-SE: 900
> Session-Expires: 1800;refresher=uac
> P-Asserted-Identity: "Display_Name"<sip:5...@xxx-xxxxxxxxxxx.xxx;user=phone>
> User-Agent: XYZ
> Content-Length: 408
> Content-Type: application/sdp
> ...
> SDP
> ...
>
>
>
> CANCEL sip:1...@yy.xx.xy.yx;user=phone SIP/2.0
> Via: SIP/2.0/UDP
> XXX-xxxxxxxxxxx.XXX:5060;branch=z9hG4bK_11462326110041973718
> From:
> "Display_Name"<sip:5...@xxx-xxxxxxxxxxx.xxx;user=phone>;tag=1_1146_f232611_d526_CtkM00017D
> To: <sip:1...@yy.xx.xy.yx;user=phone>
> Call-ID: 9...@xxx-xxxxxxxxxxx.xxx
> CSeq: 1 CANCEL
> Max-Forwards: 70
> Content-Length: 0
>
>
> Shouldn't the UAC send the ACK for 481(for CANCEL) received from UAS?
> and then wait for the final response for the INVITE form UAS.
There is no ACK for CANCEL.
There is really nothing to be done about the response to the CANCEL.
But that is always true of CANCEL - at best it accelerates the
completion and outcome of the invite, but regardless of whether the
CANCEL succeeds or not you still must await the outcome of the invite.
So just keep waiting for responses to the INVITE, allowing its
transaction state machine to play out normally.
Did you get any responses to the INVITE, either before or after the CANCEL?
Thanks,
Paul
> Thanks,
> Aman
>
>
> On Sat, Apr 27, 2013 at 7:16 PM, Paul Kyzivat <pkyzi...@alum.mit.edu
> <mailto:pkyzi...@alum.mit.edu>> wrote:
>
> Can you provide the complete INVITE and CANCEL messages?
>
> Normally, when a CANCEL is sent there is as yet no dialog.
> The rules for forming the CANCEL message mean that in such cases there
> will be no to-tag in the CANCEL. The exception to that would be if you
> sent a re-INVITE within an established dialog, and then a CANCEL for it.
>
> So, if this was a CANCEL to the initial INVITE, and it was correctly
> formed, then the UAS is broken.
>
> If this was a CANCEL to a re-INVITE, and was well formed, and it
> occurred before the INVITE transaction timed out, then the UAS is still
> wrong. But if the dialog was gone at the time the re-INVITE was
> received, then I can at least understand how a UAS might send a 481
> to both.
>
> But you asked what you should do. From a practical perspective I would
> just consider that the CANCEL failed, and wait for the response to the
> INVITE. This is pretty much the only thing that it makes sense to do for
> *any* response to CANCEL.
>
> Thanks,
> Paul
>
> On 4/27/13 3:39 AM, Aman wrote:
> > Hi All,
> >
> > Stuck on a scenario, want to understand what should be the UAC
> behavior if
> > it receive "481 Call/Transaction Does Not Exist" for the CANCEL
> it sent to
> > terminate the transaction.
> >
> > RFC3261 is not much clear on this part, here is the call flow,
> >
> > UAC UAS
> > ------------------------> INVITE
> > <------------------------ 100 Trying
> > <------------------------ 180 Ringing
> >
> > ------------------------> CANCEL
> > <------------------------ 481 CANCEL
> >
> >
> > As per my understanding, the primary purpose of the CANCEL
> request is to
> > terminate a pending transaction. The CANCEL request is never sent to
> > terminate a SIP dialog or, a session. The UAC upon receiving the
> error
> > response to a CANCEL request should destroy the transaction (
> e.g. INVITE )
> > for which it issued the CANCEL request.
> >
> > INVITE transaction should be destroyed on the UAC side?
> > UAC must send the ACK for 481 to clear the transaction/ dialog at
> UAS side?
> >
> >
> > Cheers,
> > Aman
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@lists.cs.columbia.edu
> <mailto: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
> <mailto: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
