Subject: [Sip] Question on RFC3261 Merged Requests

From: "Shan Lu" <[email-masked]>
Date: Wed, 29 Sep 2004 18:21:31 -0400

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 30 Sep 2004 07:41:15 +0200

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