Subject: [sipcore] REGISTER AOR Loop Scenario.

From: Santhana Krishnan <[email-masked]>
Date: Thu, 25 Apr 2013 05:10:27 -0700 (PDT)

Dear Experts, 
           I am having a following case, where the REGISTER request To header URI and the Contact URI are same. Pls see the message below.

REGISTER sip:10.232.15.206:5070 SIP/2.0
To: <sip:[email-masked]>
Via: SIP/2.0/TCP 10.232.122.70;branch=z9hG4bK-6928-1-0
From: <sip:[email-masked]>;tag=123451001
Call-ID: [email-masked]
CSeq: 11 REGISTER

Max-Forwards: 70

supported: gruu,path,outbound

require: gruu

Contact: <sip:[email-masked];deviceName=device1>;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c9e6bf6>"

Content-Length: 0

RFC 5627 says, 
The contact URI MUST NOT be equivalent, based on
   the URI equality rules in RFC 3261 [1], to the AOR in the To header
   field. If the contact URI is equivalent (based on URI equivalence in RFC
   3261 [1]) to the AOR, the registrar MUST reject the request with a
   403, since this would cause a routing loop. 

From RFC 3261, URI equality rules say, 
URI uri-parameter components are compared as follows:
         -  Any uri-parameter appearing in both URIs must match.
         -  A user, ttl, or method uri-parameter appearing in only one

            URI never matches, even if it contains the default value.
         -  A URI that includes an maddr parameter will not match a URI

            that contains no maddr parameter.
         -  All other uri-parameters appearing in only one URI are

            ignored when comparing the URIs.
 URI header components are never ignored.  Any present header

         component MUST be present in both URIs and match for the URIs
         to match.  The matching rules are defined for each header field
         in Section 20.

Now, while checking To and Contact URIs for equality, we can ignore the uncommon URI parameters in the Contact URI(here it is deviceName). But do we need to consider the Contact "header" parameters(here in above message +sip.instance param) also while comparing the URIs in To and Contact to decide that they are equal and reject the request with 403 as it would cause loop during lookup ? Getting this doubt bcos RFC 3261 says "URI header components are never ignored". What is an URI header component ? Does it apply to Contact header parameter in this case ?

In this case, is the above REGISTER request to be rejected with 403 or not ?

regards
+Santhana

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 13:25:35 -0400 (EDT)

> From: Santhana Krishnan <[email-masked]>

> Now, while checking To and Contact URIs for equality, we can ignore
> the uncommon URI parameters in the Contact URI(here it is
> deviceName). But do we need to consider the Contact "header"
> parameters(here in above message +sip.instance param) also while
> comparing the URIs in To and Contact to decide that they are equal
> and reject the request with 403 as it would cause loop during lookup
> ? Getting this doubt bcos RFC 3261 says "URI header components are
> never ignored". What is an URI header component ? Does it apply to
> Contact header parameter in this case ?

The "URI" in the To header is "sip:[email-masked]".
The "URI" in the Contact header is "sip:[email-masked];deviceName=device1".

The "+sip.instance=..." part is *not* part of the URI, it is a
"contact-param" -- see the grammar rule "Contact" in section 25.1 of
RFC 3261.  These sort of parameters attached to URIs in the values of
header fields are often called "field parameters" because they have
the same syntax in many different header fields, although the grammar
in 25.1 uses different non-terminal names depending on which header
field they appear in.

The "URI header components" referred to in section 19.1.4 refers to
the nonterminal "headers" in section 25.1, that is, constructs like
"?Subject=foo" in the URI "sip:user@host?Subject=foo".

Dale