Subject: [SIP] message retransmission - a need clarification

From: "Piotr S. Kossowski" <[email-masked]>
Date: Thu, 26 Oct 2000 15:50:28 +0200

Hi All,

I need some clarification on support of message retransission on UAS side,
because it isn't explicite wrote in the spec, i think.

First of all:

10.1.1 of the rfc 2543bis-02:

"Servers discard ISOMORPHIC requests, but first retransmit the appropriate
response. (SIP requests are said to be idempotent, i.e., receiving more
than one copy of a request does not change the server state.)"

For me it means that if UAS gets a message what it have already got
the last time it sends a response that it sent the last time,
independable of its current state. I think, for yet, it's clear.

According to 1.3:

"Two requests or responses are defined to be ISOMORPHIC for the purposes
of this document if they have the same values for the Call-ID, To, From
and CSeq header fields. In addition, isomorphic requests have to have 
the same Request-URI and the same second branch parameter in their 
top-most Via header."

So, by definition, retransmission generates always Isomorphic request.
On the other hand, if, for example, UAC sends retransmitted message,
but it adds e.g. Subject header, what means that it is not 
retransmission (it's not allowed without changing of CSeq, of course), 
for UAS this message is still ISOMORPHIC and must (should?) be 
treated as a retransmission. Is it true ?

Next:

Let's assume that after INVITE from UAC, UAS sent final 603 (Decline)
response (without Retry-After), without eariler provisional response.
It probably means that UAS' user will not accept any call from the UAC
in the nearest future. Let's assume that this 603 message lost.
Thus, UAC retransmit the INVITE. It causes that UAS' user will be 
bothered by incoming call again (it's of course implemmentation matter).
Anyway, we don't want UAS to take up decission again (accept, reject,
redirect). So, UAS should keep information about no longer existed
calls in case of need of retransmission of response. And that's my 
questions: 
1. Is it true ?
2. If yes, how long (as I noticed, the spec says only about proxies
   - 32 seconds. The only one such kind of timeout for UAS is on figure 
   12) ?

The last:

10.1.1 (again):

"If the request is accepted and matches an existing call leg, the server
compares the CSeq header field value. If LESS than or equal to the current
sequence number, the request is a retransmission.
"

It's said: LESS or equal. In case of equal - this message is ISOMORPHIC
with last received message befor this one, and UAS sends again response.
in case of LESS - ???. Should it retransmit something ? If yes,
what is ISOMORPHIC with what and how many messages must 'remember" UAS ?

Thank You,
Piotr

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 29 Oct 2000 16:00:51 -0500

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:[email-masked]]
> Sent: Thursday, October 26, 2000 9:26 AM
> To: [email-masked]
> Subject: [SIP] message retransmission - a need clarification
> 
> 
> Hi All,
> 

Headers are not supposed to change on retransmissions. THus, if a UAC
changes the subject or something, but keeps the Call_ID, To, From, CSeq,
R-URI and top Via the same, the UAS or proxy still treats it as a
retransmission, which means that the message with the modified Subject will
not get forwarded downstream.

> calls in case of need of retransmission of response. And that's my 

Yes.

>    - 32 seconds. The only one such kind of timeout for UAS is 

Figure 12 explains it quite clearly, I think. You wait around for ACK, and
then after that, 32 seconds.

> what is ISOMORPHIC with what and how many messages must 

It is a retramsission of a previous request, so you would follow the rules
for that state machine for that request - if you're in the failure state,
retransmit the response. In confirmed and completed, do nothing. Does this
mean you need to remember the state machines for all requests always? Of
course not. Once the machine has moved to completed, you know that the
appropriate action is always "do nothing", so for any request with a CSeq
less than the last received message, for which there is no state machine, do
nothing.

-Jonathan R.

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