Discussion:
[Sip-implementors] Cancelling a request
isshed
2014-07-15 09:52:46 UTC
Permalink
Hi All,

I have a doubt in the following scenario.

UA has sent INVITE to remote party.
It received the 100 Trying.

Now user wants to CANCEL the call.

Can A CANCEL be sent at this point in time or it can not unless some
non-100 provisional response comes?


Thanks,
Isshed.
Tarun2 Gupta
2014-07-15 09:55:53 UTC
Permalink
Hi

CANCEL can be sent after receiving a 1xx response including 100.

Regards
Tarun Gupta

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of isshed
Sent: Tuesday, July 15, 2014 3:23 PM
To: sip-implementors
Subject: [Sip-implementors] Cancelling a request

Hi All,

I have a doubt in the following scenario.

UA has sent INVITE to remote party.
It received the 100 Trying.

Now user wants to CANCEL the call.

Can A CANCEL be sent at this point in time or it can not unless some
non-100 provisional response comes?


Thanks,
Isshed.
Rahul Pathak
2014-07-15 10:01:45 UTC
Permalink
as per rfc 3261 you can send CANCLE message in this case.
isshed
2014-07-15 10:09:07 UTC
Permalink
Thanks Rahul and Tarun..

Can there be any case when CANCEL reached to UA2 before INVITE in case
od UDP? because the 100 trying can be sent by proxies as well.
Post by Rahul Pathak
as per rfc 3261 you can send CANCLE message in this case.
Rahul Pathak
2014-07-15 10:13:48 UTC
Permalink
No, because CANCEL is in dialog message.
Post by isshed
Thanks Rahul and Tarun..
Can there be any case when CANCEL reached to UA2 before INVITE in case
od UDP? because the 100 trying can be sent by proxies as well.
Post by Rahul Pathak
as per rfc 3261 you can send CANCLE message in this case.
--
*Regards,*
*Rahul Pathak*
www.rahulpathak.in
blog.rahulpathak.in
Brett Tate
2014-07-15 11:07:16 UTC
Permalink
Post by isshed
Can there be any case when CANCEL reached to UA2
before INVITE in case od UDP? because the 100 trying
can be sent by proxies as well.
Yes (although no longer as common); as mentioned within RFC 3261 section
28.1, RFC 2543 did not have the same mandate as RFC 3261.

"o A UA or proxy cannot send CANCEL for a transaction until it gets a
provisional response for the request. This was allowed in RFC
2543 but leads to potential race conditions."
Paul Kyzivat
2014-07-15 15:04:06 UTC
Permalink
Post by Brett Tate
Post by isshed
Can there be any case when CANCEL reached to UA2
before INVITE in case od UDP? because the 100 trying
can be sent by proxies as well.
Yes, 100 is sent hop by hop. But CANCEL is itself also hop by hop. So at
each hop the cancel is only sent if a 1xx has been received from downstream.
Post by Brett Tate
Yes (although no longer as common); as mentioned within RFC 3261 section
28.1, RFC 2543 did not have the same mandate as RFC 3261.
"o A UA or proxy cannot send CANCEL for a transaction until it gets a
provisional response for the request. This was allowed in RFC
2543 but leads to potential race conditions."
I guess Brett is saying that it can only happen if there is a device on
the path that supports 2543 and not 3261. I hope there are no longer any
of those deployed.

Thanks,
Paul
isshed
2014-07-20 15:16:36 UTC
Permalink
Thanks Paul and Brett!!
Post by Paul Kyzivat
Post by Brett Tate
Post by isshed
Can there be any case when CANCEL reached to UA2
before INVITE in case od UDP? because the 100 trying
can be sent by proxies as well.
Yes, 100 is sent hop by hop. But CANCEL is itself also hop by hop. So at
each hop the cancel is only sent if a 1xx has been received from downstream.
Post by Brett Tate
Yes (although no longer as common); as mentioned within RFC 3261 section
28.1, RFC 2543 did not have the same mandate as RFC 3261.
"o A UA or proxy cannot send CANCEL for a transaction until it gets a
provisional response for the request. This was allowed in RFC
2543 but leads to potential race conditions."
I guess Brett is saying that it can only happen if there is a device on the
path that supports 2543 and not 3261. I hope there are no longer any of
those deployed.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Loading...