Subject: Re: [SIP] Retransmissions

From: [email-masked]
Date: Tue, 30 May 2000 18:12:18 +0530

Hi Gonzalo,
     Answers inline.

Gonzalo Camarillo <[email-masked]> on 05/30/2000
05:34:06 PM

To:   sip <[email-masked]>
cc:    (bcc: K Binu/HSSBLR)

Subject:  [SIP] Retransmissions

>Hi,
>
>In section 10.5.1 of the bis document it is said that when UDP is used a
>final response is retransmitted until:
>
>1) ACK arrives
>2) BYE arrives
>3) CANCEL arrives (status code > 299)
>4) 7 retransmissions
>
>In section 4.2.5 it is said that CANCEL has to be answered with 487.
>

The section does not say that CANCEL is to be answered with a 487. The
CANCEL has to be answered with a 200 OK. The 487 response is to be sent if
a retransmission of the cancelled INVITE request comes by.

>So, if a server receives an INVITE and it responses with 400 for
>instance. If a CANCEL is received, it will stop sending the 400 and it
>will send the 487. It will retransmit the 487 until the ACK for the
>INVITE arrives. Does the retransmission counter get re-started (the
>server might have retransmitted already some times the 400 response)?

So the correct behaviour here would be to stop the 400 response
retransmissions for the INVITE and answer the CANCEL with a 200 OK. The
server would send a 487 if the cancelled INVITE happens to come by and not
otherwise.

>
>Thanks,
>
>Gonzalo
>--
>Gonzalo Camarillo         Phone :  +358  9 299 33 71
>Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
>Telecom R&D               Fax   :  +358  9 299 30 52
>FIN-02420 Jorvas          Email :  [email-masked]
>Finland
>
>
>______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

Binu

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 May 2000 18:52:58 -0400

> server would send a 487 if the cancelled INVITE happens to come by and not

No, no, no. 

This section of the bis draft has not changed, but it will. We have
discussed this on the list extensively. If you receive a request, and
you haven't yet sent a final response, and then a CANCEL comes, respond
to the CANCEL with 200 OK, and the original request with 487. Continue
to retransmit that 487 as you normally would , even if a BYE comes.

If you've already responded to a request with a final response, and then
a CANCEL comes, respond to the CANCEL with 200 OK, and thats it.
Continue with processing the final response to that request
independently of the CANCEL.

No matter what, don't ever start sending one final response, and then
change to a different once when CANCEL comes. Very bad.

The idea here is that CANCEL is a separate transaction, which basically
says "respond to this original request with 487 if you haven't already,
otherwise don't do anything special". The CANCEL and the transaction it
cancels still complete normally. No matter what, each transaction should
execute and complete normally, independent of any other. 

This includes the case where you get an INVITE, and then a BYE. Respond
to the INVITE with a 487 (or something), and then respond to the BYE
with 200 OK. Both the INVITE and BYE transactions complete normally.

We are in the process of updating this diagram to reflect this.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Billy Biggs <[email-masked]>
Date: Tue, 30 May 2000 20:11:45 -0400

> with 200 OK. Both the INVITE and BYE transactions complete normally.

  I do hate to beat on this more, but...

  In the case where you get an INVITE and then a BYE with a higher CSeq,
it seems really silly to have to keep around state for both of these
transactions on the call leg.  Why bother with the INVITE transaction at
all?  The far end has cancelled it anyways?  That just seems like more
unnecessary state to keep in my code.

  It seems more important to me to worry about keeping the endpoints
simple rather than the proxies, otherwise it's going to take everyone
alot longer to implement good clients.  Proxies can afford more bloat
than endpoints: let them time out or be smarter with the CSeqs.

  Any proxy that cares that much about old transaction state is likely
subject to alot of DoS attacks anyways.

  Since that argument will likely get me nowhere, please hear the message
that I would like to see simpler endpoint requirements.

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 May 2000 23:46:07 -0400

> unnecessary state to keep in my code.

Its good for UAs, and really good for proxies. For the UA, it allows for
independence of transactions, and separation of transaction processing
from call state. I would argue that requiring the INVITE transaction to
cease

For proxies, which don't see call state in many cases, it allows for
independent operation of each transaction. Without that, proxies will be
left with state hanging around (i.e., INVITE transaction state) when the
BYE comes, particularly when the proxy doesn't even see the BYE. This
leads to wasted resources in proxies, performance bottlenecks, and more
complex code to clean up.

> than endpoints: let them time out or be smarter with the CSeqs.

I disagree completely. What you are suggesting is at odds with the
entire IP model of scalability (and with the model supported by SIP),
which says to push complexity to the edge, where it is easier to manage.
In any case, this detail of completing INVITE transactions hardly
qualifies as complex. As I argue above, I think it makes things simpler.

> subject to alot of DoS attacks anyways.

You want your protocols to clean up state under normal operation.

-Jonathan R.