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

Dovid Bender dovid at telecurve.com
Mon Feb 24 23:49:13 CET 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200224/822824e8/attachment.html>


More information about the sr-users mailing list