Subject: RE: [Sip] UAS behavior dealing with "merged" request afterdialogestablishment

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 22 Mar 2005 13:19:06 -0500

Instead of tweaking the transaction state machine behavior, why couldn't
this be handled at TU Core. When the retransmitted INVITE arrives at TU
Core, you can match it w/ ongoing dialogs while taking into account only
the UAC-half of the dialog id.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shan Lu
Sent: Tuesday, March 22, 2005 11:52 AM
To: 'K. Hal Purdy'; [email-masked]
Subject: RE: [Sip] UAS behavior dealing with "merged" request
afterdialogestablishment

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
>
>
>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
>

_______________________________________________
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

_______________________________________________
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 17:50:39 -0500

How does TU decide whether to:

A. No-op
B. 482
C. start anew?

Any of the above can be the right thing to do.

Regards,

Shan Lu

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Jain, Rajnish
>Sent: Tuesday, March 22, 2005 1:19 PM
>To: Shan Lu; K. Hal Purdy; [email-masked]
>Subject: RE: [Sip] UAS behavior dealing with "merged" 
>requestafterdialogestablishment
>
>

---

From: Malleswara Rao Ankem <[email-masked]>
Date: Thu, 24 Mar 2005 10:26:33 +0530

I think it should respond with a 482 (as per 3261). As for the
previous 200Ok if it doesnot result in an ACK the dialog itself will
cease to exist.
But treating it as  a no-op or as a new INVITE will create more confusion.
regards
Mallesh