[Sip] Detecting merged requests?

[Sachin Shenoy <sachins@netlab.hcltech.com>]

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  fax_user_a@test.com
And user_a's phone can be reached at    phone_user_a@test.com


A call made to user_a@test.com gets forked at a proxy. The
2 forked request arrives at the UAS with the respective request
URI's

INVITE sip:fax_user_a@test.com
...

INVITE sip:phone_user_a@test.com
...

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip