[SR-Users] Using the To header to route a call

[Alex Balashov]

I am not aware of any specific text to that effect, as it would be redundant given the findings you pasted, which characterise the request URI as the source of truth for next-hop routing (absent overrides). 

—
Sent from my iPad

> On Feb 24, 2020, at 5:51 PM, Dovid Bender <dovid at telecurve.com> wrote:
> 
> 
> Hi,
> 
> We are fighting with a vendor and trying to explain to them that call routing should be based on the RURI on the INVITE and not the To header. I went through RFC 3261 and while there are many "indicators" and it seems like its screaming that we should be using the RURI, is anyone aware of any specific text (that I may have missed) where it says specifically call routing should be done based on the RURI and NOT the to header?
> 
> TIA.
> 
> Dovid
> 
> 
> 
> 
>   https://tools.ietf.org/html/rfc3261#page-78
> 
> 1) 8.1.1.1 Request-URI
> The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. - Note that it says SHOULD but is NOT mandatory. Also this is for the INITIAL request.
> This may or may not be the ultimate recipient of the request. - Again this is the To field. The RURI is what we are supposed to follow when we want to know where the call should be delivered to.
> 
> 2) 8.1.2 Sending the Request
> -Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification.  In this specification, only the tags are used for dialog identification.  It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. - While this is for subsequent requests (and not an original one) you see that the only point of the To field is to identify the dialog. 
> 
> 3) 8.2.2.1 To and Request-URI
> The To header field identifies the original recipient of the request designated by the user identified in the From field. - Note that the TO field identifies the ORIGINAL recipient, this *CAN* change. This is basically telling you that you can't rely on the To header for routing.
> However, the Request-URI identifies the UAS that is to process the request. - As you can see the Request-RU and *NOT* the TO header tells you where the request should go.
> 
> 5) 12.2.1.1 Generating the Request
> a.    The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. - This is self explanatory. it shows that the RURI is using for routing and NOT the to header.
> b. The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the topmost Route header field value or the Request-URI if no Route header field is present.  Subject to certain restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented in the route set). Again self explanatory.
> 
> 6) 16.5 Determining Request Targets
> Each target in the set is represented as a URI. - This clearly shows that how we route is based on the RURI and *NOT* the to header.
> 
> 7) 26.5 Privacy
> Thus it MAY be desirable for privacy reasons to create a To header field that differs from the Request-URI. - Again this shows that the to may not match up the RURI. Think of the To header as the contact in someones phone and the RURI as where we are calling. The to header may be bob at 1.1.1.1 but the URI is where we are actually calling which is 12346 at 1.1.1.1 or bob_smith at 1.1.1.1.1
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200224/b78457b1/attachment.html>