Subject: [Sip] UAS behavior dealing with "merged" request after dialog establishment

From: "K. Hal Purdy" <[email-masked]>
Date: Fri, 18 Mar 2005 16:08:20 -0500

I have a question about UAS behavior related to detecting "merged" 
requests *after* the initial request has already resulted in an 
established dialog. If a UAC sends a request that goes through a 
parallel forking proxy, multiple forked requests may ultimately reach 
the same UAS. This is a known scenario and is covered in section 8.2.2.2 
of 3261:

   If the request has no tag in the To header field, the UAS core MUST
   check the request against ongoing transactions.  If the From tag,
   Call-ID, and CSeq exactly match those associated with an ongoing
   transaction, but the request does not match that transaction (based
   on the matching rules in Section 17.2.3), the UAS core SHOULD
   generate a 482 (Loop Detected) response and pass it to the server
   transaction.

 However, if the UAS has already sent a 2xx response to the first 
request received, there is no longer any "ongoing transaction." From 
Section 17.2.1:

   If, while in the "Proceeding" state, the TU passes a 2xx response to
   the server transaction, the server transaction MUST pass this
   response to the transport layer for transmission. ...  The server 
transaction MUST then
   transition to the "Terminated" state....Once the transaction is in 
the "Terminated" state, it MUST be
   destroyed immediately.

Barring any additional work on the part of the UAS to detect this 
condition, it seems that a subsequent merged request might be treated as 
an initial INVITE transaction. This doesn't seem like a good idea. What 
should the UAS do, and where is this behavior covered in a RFC?

More generally, what  normative statements can be made about the 
responsibilities of UASs as regards enforcing the uniqueness of 
Call-IDs, branch parameters, etc?

Regards,
Hal Purdy

_______________________________________________
Sip mailing list  https://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: "Shan Lu" <[email-masked]>
Date: Tue, 22 Mar 2005 11:51:37 -0500

Hi,

Your question touched two issues in RFC3261.

The first is late arrival of a retransmitted INVITE at UAS. Note although
you are interested in forking, your situation is no different than a
retransmitted INVITE arriving after the INVITE server transaction has
terminated. See
http://www1.ietf.org/mail-archive/web/sip/current/msg10326.html. The
proposed solution is to keep the original INVITE transaction a bit longer
(till ACK).

Then you will run into second issue. See
http://www1.ietf.org/mail-archive/web/sip/current/msg10432.html. Depending
on your system, Section 8.2.2.2/RFC3261 does not always make sense. The
prescribed behavior for merged requests is incomplete and often times
broken.

Regards,

Shan Lu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of K. Hal Purdy
>Sent: Friday, March 18, 2005 4:08 PM
>To: [email-masked]
>Subject: [Sip] UAS behavior dealing with "merged" request 
>after dialogestablishment
>
>

---

From: "K. Hal Purdy" <[email-masked]>
Date: Wed, 23 Mar 2005 15:20:35 -0500

Shan,
Thanks for your reply.
Further comments inline.

>proposed solution is to keep the original INVITE transaction a bit longer
I agree this is a somewhat related case though it doesn't get to the 
heart of the issue I'm asking about. In this case, *if* the UAS 
maintains transaction state, it can determine that the branch tag is the 
same and therefore, this INVITE is a retransmission. Admittedly 3261 
doesn't cover this case, but at least it's now clear to us that a UAS 
implementation should maintain some additional transaction state even 
after the transaction is destroyed. It's also clear that the correct 
behavior is for the UAS to simply ignore the retransmitted INVITE(s). 
Finally, I think it's clear that waiting for the ACK is not sufficient 
to completely handle this case in scenarios where message order is not 
preserved. A retransmitted INVITE could be sent before but arrive after 
the ACK sent in response to the 2xx.

The case I raise is different because it's not clear (to me) what the 
proper UAS behavior should be. Should it ignore the "merged" request, 
reject it with 482 or some other code, or treat it as a new request? 
Treating as a new request doesn't seem right. If it rejects with 4xx 
code, could this cause the UAC trouble? It certainly could lead to some 
confusion if the 2xx were lost. Even if the 2xx is not lost, it seems 
that some problems might arise. I think you succinctly summarized this 
question in a subsequent post.

>prescribed behavior for merged requests is incomplete and often times
As I understand it, this thread raises the issue of whether sending a 
482 is proper when the Request-URI in the merged request is different 
from the one in the original INVITE that created the UAS transaction. 
Again, this seems unrelated to my question since in the case I raise, 
once the UAS has responded with 2xx to the original INVITE, the 
transaction is destroyed. In the case The Request-URI could be the same 
or different, and its value doesn't seem to help in resolving what the 
correct behavior of the UAS should be.

Regards,
Hal Purdy