Subject: [Sip] routing query

From: "Keith Robinson" <[email-masked]>
Date: Thu, 14 Feb 2002 16:02:02 +0000

Hello,

What is the reasoning behind the routing rule that limits a destination set
to contain only 1 member if the Route header  is not empty, when resolving
a R-URI in  the administrative domain of the proxy ?

Thanks,

K. Robinson

------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 12:16:52 -0500

> a R-URI in  the administrative domain of the proxy ?

Well, this restriction has actually been booted in the current working
editors copy. So, good point. Let me explain why it was there, and why
we booted it.

One of the main purposes of record-routing it so establish a specific
path from caller to callee. These are indicated through the route
headers in subsequent requests in the dialog. If a mid-dialog request is
forked, for example, we may end up creating new calls or other bad
things, when that is not intended.

Turns out, forking won't happen anyway. The reason for this was the very
important realiztion that the r-uri in the mid-dialog reuqests MUST BE
THE CONTACT of the far end. That is, you are sending the request to that
specific endpoint, the record-routes specify intermediate hops. Noting
also that proxies only rewrite r-uris in their own domain of control,
things work nicely. A contact header of sip:[email-masked] is only
under the control of 1.2.3.4, my PC. Thus, as this request traverses
proxies on the route set, none of them will rewrite the r-uri (as it is
sip:[email-masked], not under their control), none of of them will fork
as a result, and we achieved the desired goal without explicitly
mandating that there be no forking for mid-dialog requests.

Now, we also came across cases where we wanted to fork when route was
present. This was specifically in the service routing scenarios.
Consider an S-CSCF that sends a request to an app server, and puts a
route in there to force the AS to send the requests back to it. Now,
that proxy should be allowed to fork, if its service demands it. Both
requests would carry the route headers to carry it back to the S-CSCF.
This is perfectly reasonable and breaks nothing if you do it.

So, the ban is removed, resulting in yet another nice simplification of
the whole route/record-route mess. This will be reflected in -08, of
course.

Thanks,
Jonathan R.

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