Subject: [Sip] Detecting merged requests?

From: Sachin Shenoy <[email-masked]>
Date: Mon, 02 Dec 2002 16:39:44 +0530

Hi,

According to RFC 3261,  a request is a merged request if ...

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

Suppose if there are 2 UAS application sharing the same SIP stack
(same process). They are listening for incoming calls for the same
user. One application is handling the fax machine for user_a and the
other the phone for user_a.

user_a's fax machine can be reached at  [email-masked]
And user_a's phone can be reached at    [email-masked]

A call made to [email-masked] gets forked at a proxy. The
2 forked request arrives at the UAS with the respective request
URI's

INVITE sip:[email-masked]
...

INVITE sip:[email-masked]
...

Now, according to the RFC, the first INVITE would be processed and the
second would be responded with 482 "loop detected". Shouldn't the
second INVITE also be processed? Logically, these are 2 different
application handling 2 different devices for the same user. The fact that
they are sharing the same process should not interfere each other.

I think merged request matching should also take the Request-Uri
into consideration. Request-Uri  identifies the end point at UAS. If
a UAS gets 2 INVITES  for the same request-uri with the same Call-ID,
Cseq and From-Tag, and with no To-Tag then it should be considered
as merged request.

Thanks
Sachin

_______________________________________________
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" <[email-masked]>
Date: Wed, 4 Dec 2002 22:39:03 -0600

Sachin
Your interpretation is correct. The request is not considered merged, unless
the ReqUri matches that on a previously received request on the same calId
(in addition to other headers specified in the RFC).
ReqUri is a primary parameter in a merged request. The other criteria come
into play only when the request uri indicates this as a possibility. In
transaction matching rules, used to detect retransmissions/merged requests
ReqUri, VIA, From Tag/ToTag, CSEQ and CallId are all used.

The correct thing for the two UASs to do is respond with a different To Tag
on each request and proceed to set up the calls independently(This is
distinct from 2 legs on the same call.) This scenario is also referred to,
loosely, as UAS forking.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Sachin
Shenoy
Sent: Monday, December 02, 2002 5:10 AM
To: [email-masked]
Subject: [Sip] Detecting merged requests?

Hi,

"8.2.2.2 Merged Requests

Thanks
Sachin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Dec 2002 02:43:18 -0500

Remember, SIP talks about logical elements, and doesn't care about 
specific implementations. In your example, there are really two separate 
user agents, in the sense that there are two separate entities making 
decisions about whether to accept or reject calls. That these happen to 
share an internal stack and port is a matter of implementation. As such, 
  according to the spec, they would be treated as separate UA and thus 
not subject to the merged request rule. That rule is meant to deal 
explicitly with the case of a single UA, in the logical sense above, 
getting two requests. The issue is how a particular call acceptance 
decision - accept, reject, redirect - manifests itself in terms of 
responses across multiple transactions. That is a non-issue in your case.

-Jonathan R.

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