On 4/29/13 10:48 AM, Aman wrote:
> Nope Paul, no response from UAS to INVITE.
>
> This seems to be UAS is broken. Thanks a lot for your help.
So in this case your UAC should eventually time out the INVITE transaction.
At this point you need to ask the supplier of the UAS (or maybe the
middle boxes between you and it) to figure out what is happening on
their end.
Maybe the INVITE was simply lost. Did you retransmit it? (Technically
every transaction is independent. So in principle the transaction state
machine for the INVITE should be causing you to retransmit it
independent of the CANCEL. But I can see how you might choose to
suppress that once you decide you don't want the INVITE. But that could
result in the error you got.
Thanks,
Paul
> Cheers,
> Aman
>
>
> On Mon, Apr 29, 2013 at 7:52 PM, Paul Kyzivat <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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:[email protected];user=__phone SIP/2.0
> Via: SIP/2.0/UDP
> XXX-xxxxxxxxxxx.XXX:5060;__branch=z9hG4bK___11462326110041973718
> From:
>
> "Display_Name"<sip:5678@XXX-__xxxxxxxxxxx.XXX;user=phone>;__tag=1_1146_f232611_d526___CtkM00017D
> To: <sip:[email protected];user=__phone>
> Call-ID: [email protected]
> CSeq: 1 INVITE
> Max-Forwards: 70
> Supported: 100rel,timer,replaces,unknown
> Contact: <sip:[email protected]:__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:5678@XXX-__xxxxxxxxxxx.XXX;user=phone>
> User-Agent: XYZ
> Content-Length: 408
> Content-Type: application/sdp
> ...
> SDP
> ...
>
>
>
> CANCEL sip:[email protected];user=__phone SIP/2.0
> Via: SIP/2.0/UDP
> XXX-xxxxxxxxxxx.XXX:5060;__branch=z9hG4bK___11462326110041973718
> From:
>
> "Display_Name"<sip:5678@XXX-__xxxxxxxxxxx.XXX;user=phone>;__tag=1_1146_f232611_d526___CtkM00017D
> To: <sip:[email protected];user=__phone>
> Call-ID: [email protected]
> 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
> <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>__>
> 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
> > [email protected].__columbia.edu
> <mailto:[email protected]>
> <mailto:Sip-implementors@__lists.cs.columbia.edu
> <mailto:[email protected]>>
>
> >
> https://lists.cs.columbia.edu/__cucslists/listinfo/sip-__implementors
> <https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors>
> >
>
> _________________________________________________
> Sip-implementors mailing list
> [email protected].__columbia.edu
> <mailto:[email protected]>
> <mailto:Sip-implementors@__lists.cs.columbia.edu
> <mailto:[email protected]>>
> https://lists.cs.columbia.edu/__cucslists/listinfo/sip-__implementors
> <https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors>
>
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
