Subject: Re: [Sip] Bis-05 question: CANCEL

From: Christer Holmberg <[email-masked]>
Date: Thu, 01 Nov 2001 08:12:57 +0200

Hi,

>>I KNOW what the solution is. What I am saying is that since we DO have
>>to THAT case into consideration in any case, we can use the SAME
>>mechanism if we receive a 200 to an INVITE we have tried to
>>CANCEL - ie we simply ACK and BYE it.
>
>CANCEL is not the same thing as BYE. CANCEL terminates *all* pending
>branches, BYE terminates a specific one.

Yes.

>As such, the UAC would need to continue to BYE individual 1xx as they arrive,

Why? If the UAC sends CANCEL, receives 481 (the CANCEL reaches the
server before the INVITE), and then starts receiving 1xx provisional
responses for the INVITE it can send a new CANCEL, which should cancel
ALL legs. Only if it receives a 200 FINAL response it would then send
ACK/BYE for that specific leg.

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 01 Nov 2001 08:34:45 +0200

Hi,

>>>>It's logical and ok for billing to have nothing to do with bis-05, but
>>>>service providers will be the ones to get stuck with any possible billing
>>>>repercussions from these requirements.
>>>>
>>>>By the way, what is the probability that, using UDP, INVITE will be received
>>>>after CANCEL? I assume a very small percentage of the time. Therefore, it
>>>>would be preferrable that CANCEL be sent right away rather than consume
>>>>resources by waiting for provisional responses for a moot reason. How about
>>>>change "CANCEL must" wait for provisional response to "CANCEL should".
>>>>
>>>
>>>Don't you undestand that what the harm that you can produce by being
>>>unable to hang up a call because the CANCEL made it before the INVITE is
>>>much higher than having to wait for a provisional response?
>>
>>First, maybe I don't get the point, but exactly what "harm" could this
>>produce?
>>
> 
>If you do not think that not being able to hang up a call is harmful
>then we live in different worlds.

If my UAC works correctly I will be able to hang up the call... Yes,
there is a small chance, if the caller hangs up very fast, that the
phone will ring for a while, until the UAC realises what has happended
and sends a new CANCEL or BYE (depending on the type of response it
first receives for the INVITE).
 
>>Second, IF it will be a requirement to wait for the 1xx, then I think it
>>also must be a requirement to send a 1xx in the first plavce
>bis-05 says that the server transaction MUST send a 100 Trying unless
>another response will be sent in 200 ms.

So, who is going to start a timer for 200 ms??? Wouldn't it be much more
CLEAR and SIMPLE to simply write that the server MUST send a provisional
response as soon as it receives the INVITE?

>>>About the chances of a CANCEL arriving before the INVITE, you only need
>>>one single message lost (the first transmission of the INVITE) and the
>>>caller hanging up in less than half a second... not a so strange
>>>scenario, I believe.
>>
>>Which scenario? Loosing a message, or hanging up in less than half a
>>second? :)
>>
> 
>Both at the same time.

And, how often will both at the same time happen? I think that we could
come up with a long list of "strange things" that can happen in SIP (and
in other networks too). Some of those we'll just have to live with, and
for the others I think we should try having general mechanisms to handle
them. If we try to solve issues case by case, by defining case specific
rules, I think that we may end up having a very complicated and
restrictive protocol, and we will go on adding rules forever...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 2 Nov 2001 00:58:43 -0500

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, November 01, 2001 1:13 AM
> To: Jonathan Rosenberg
> Cc: Bob Penfield; 'IETF SIP Mailing List'
> Subject: Re: [Sip] Bis-05 question: CANCEL
> 
> ALL legs. 

Sorry, that is not correct. This CANCEL will look identical to the previous
one, and therefore be treated as a retransmission, returning once more the
same response, 481, and having no effect.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com