Subject: RE: [Sip] Question on RFC3261 Merged Requests

From: "Shan Lu" <[email-masked]>
Date: Fri, 1 Oct 2004 12:02:26 -0400

Christer,

I appreciate your comments. After thinking over the point you raised (why
old transaction mapping rules have to be used in 3261-compliant
environment), I came to the conclusion that 8.2.2.2 is completely broken. 

My gateway example showed that at least when R-URI is different, second
INVITE should not be automatically rejected on the basis that it shares same
call-id, cseq, and the from tag with an INVITE in a different transaction.

Even when the two INVITEs have identical R-URI, the fact that they may have
visited different proxies after being forked could make one of them more
desirable than the other. The order they arrive at the UAS should not
determine which one gets presented to user and which one gets discarded. The
protocol can not make that distinction.

The forking proxy and calling UA both have built-in mechanisms to avoid one
single INVITE leading to two established dialogs. When it works, Section
8.2.2.2 is an optimization on top of that. And there are plenty of cases it
simply does not work.

I propose two options moving forward:

1. strike out 8.2.2.2 completely, or
2. replace it with a note to say that UAS may receive INVITEs in different
transactions but with identical call-id, cseq, from tag, and possibly same
R-URI. UAS should be prepared to handle this situation as it would with any
other incoming INVITEs.

I like to hear the list's opinion on this and whether it is a bug that
should be logged.

Regards,

Shan Lu
sentitO Networks  

>-----Original Message-----
>From: Christer Holmberg (JO/LMF) 
>[mailto:[email-masked]] 
>Sent: Thursday, September 30, 2004 1:41 AM
>To: 'Shan Lu'; 'IETF SIP Mailing List'
>Subject: RE: [Sip] Question on RFC3261 Merged Requests
>
>
>
>Hi,
>
>Interesting point.
>
>One could argue that the existing text is ok for a normal SIP 
>phone, because there is really no idea in receiving multiple 
>"calls" (multiple "instances" of the same forked INVITE) from 
>the same caller (in most cases the SIP phone can handle only 
>one call at a time anyway, no matter if the incoming INVITEs 
>origin from the same user or different users).
>
>However, for a gateway that may not be a valid case. Even if 
>the gateway from a SIP perspective is a single SIP endpoint 
>there are multiple end-users behind it, so IF we want to allow 
>"forking" into the PSTN network (or whatever is on the other 
>side) you are correct, I think.
>
>The problem I have with merged requests is that it takes away 
>the advantages of only using the RFC3261 Via branch cookie 
>from transaction identification. A node compliant with RFC3261 
>will basically still have to use the "old" transaction mapping 
>mechanism, in order the to the merge check...
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf Of
>> Shan Lu
>> Sent: 30. syyskuuta 2004 1:22
>> To: 'IETF SIP Mailing List'
>> Subject: [Sip] Question on RFC3261 Merged Requests
>> 
>> 
>> Hi,
>> 
>> RFC3261 has following text:
>> 
>> 8.2.2.2 Merged Requests
>> 
>>    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.
>> 
>> Assume that calls to [email-masked] is forked to two 
>> phone numbers on
>> PSTN, say, 555-1111 and 555-2222. Further assume that there 
>> is only one
>> SIP-PSTN gateway. The two INVITEs arriving at the gw are 
>> identical except
>> for R-URI userinfo and top VIA branch (assuming forking proxy 
>> is the only
>> proxy). 
>> 
>> My question is: why should GW 482 second INVITE? Isn't that 
>> the purpose of
>> forking? Should 8.2.2.2 be modified as:
>> 
>> ... If request URI, the From tag, Call-ID, and CSeq exactly match ...
>>        ^^^^^^^^^^^^ 
>> 
>> Regards, 
>> 
>> Shan Lu
>> sentitO Networks
>> 
>> 
>> _______________________________________________
>> 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: "Arunachalam Venkatraman \(arunvenk\)" <[email-masked]>
Date: Fri, 8 Oct 2004 09:53:12 -0500

Shan
You are correct about this, In a gateway implementation I am familiar with,
the user part of the ReqUri are compared and if this also matches, a 482
response is sent to the second request. Otherwise, the second call is set up
to the distinctly different number.
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shan
Lu
Sent: Wednesday, September 29, 2004 5:22 PM
To: 'IETF SIP Mailing List'
Subject: [Sip] Question on RFC3261 Merged Requests

Hi,

8.2.2.2 Merged Requests

   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.

Assume that calls to [email-masked] is forked to two phone numbers on
PSTN, say, 555-1111 and 555-2222. Further assume that there is only one
SIP-PSTN gateway. The two INVITEs arriving at the gw are identical except
for R-URI userinfo and top VIA branch (assuming forking proxy is the only
proxy). 

My question is: why should GW 482 second INVITE? Isn't that the purpose of
forking? Should 8.2.2.2 be modified as:

Regards, 

Shan Lu
sentitO Networks

_______________________________________________
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