Subject: RE: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 16 Jan 2001 18:33:46 -0800

Yes I agree Henning. In fact, that was one of the reasons I believe that
Keith's first option (a) [ie, the UA/proxy removing the next Route header
even if it doesn't route to it] is a risky idea. I think you may run into
problems when you get chains of outbound proxies, etc UA sends to outbound
proxy which in turn sends to another outbound proxy. In my mind the Route is
better left in place until it is actually used.

Cheers,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

		-----Original Message-----
		From:	Henning G. Schulzrinne [mailto:[email-masked]]
		Sent:	Wednesday, January 17, 2001 12:21 PM
		To:	Fairlie-Cuninghame, Robert
		Cc:	'Keith Robinson'; [email-masked]; Jonathan
Rosenberg
		Subject:	Re: Outbound Proxies Renewed (was [SIP]
Proxy Routing Logic)

		> "Fairlie-Cuninghame, Robert" wrote:
		> 

		> I would also like to reiterate Jonathan's design goals for
a
		> solutions: that a proxy should not need to know whether it
is being
		> used as an outbound proxy or have to take special action
when being
		> used as a outbound proxy. The UA should be responsible for
taking any
		> action required (given that the UA is the only entity that
knows
		> whether it using a proxy as an "outbound proxy").

		Before we get into details, I want to make sure we don't
forget that
		proxy servers can also use outbound proxies, not just UAs. 

		-- 
		Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Keith Robinson" <[email-masked]>
Date: Thu, 18 Jan 2001 12:05:40 +0000

Going back to an earlier posting on this thread, Jacek Grabiec defined routing
procedure
that took into account chains of outbound proxies. I don't think that it is a
problem.

Regards,

K. Robinson

"Fairlie-Cuninghame, Robert" <[email-masked]> on 17/01/2001 02:33:46

                                                              

 To:      "'Henning G. Schulzrinne'" <[email-masked]>    
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN,                     
          [email-masked], Jonathan Rosenberg         
          <[email-masked]>                           

 Subject: RE: Outbound Proxies Renewed (was [SIP] Proxy       
          Routing Logic)                                      

Cheers,

Robert.

          -----Original Message-----

a
is being
when being
taking any
knows

---

From: "Keith Robinson" <[email-masked]>
Date: Thu, 18 Jan 2001 12:07:35 +0000

---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 18/01/2001 12:07
---------------------------

18/01/2001 11:31
Keith Robinson

To:   "Fairlie-Cuninghame, Robert" <[email-masked]> @ MCEXT
cc:   [email-masked], Jonathan Rosenberg <[email-masked]>

Subject:  Re: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
      (Document link: Keith Robinson)

Thanks for reply, even if you didn't agree !

Considering your proposal of placing the address of the proxy in the R-URI when
the UA is unable to do the Route mechanism because it lacks DNS; the following
R-URI may be received by the proxy (serving sipnet.com) in an initial INVITE

a) sip:[email-masked]
b) sip:proxy.sipnet.com

For case a), the userA lies within the domain served by the proxy so the proxy
must
perform some type of location service to determine the physical endpoint to
which
to send the request.

For case b), the request is for the domain served by the proxy, but as there is
no user
identified it means that this must be a request from a UA that couldn't Route
using DNS
so the proxy must do the Routing for it; this suggests that the proxy is
inferring when it is
acting as an outbound poxy.

It appears, then, that the proxy must execute different logic for
R-URIs that identify the domain the proxy serves but have different formats (or
perhaps some
abstract user name for case (b), say [email-masked]) as opposed
to
always performing a location service when it receives an intial INVITE
identifying that
domain.

So, while I agree that this mechanism will, I think it still requires the proxy
to know when it is acting as an outbound proxy.

As a counterpoint, perhaps a proxy recognising it is being addressed as an
outbound proxy
and then following a set of standard procedures accordingly is not, in fact, the
wrong thing to do................

The most important point out of this is that the new Record-Route text needs to
identify exactly what
a UA, that can't or won't Route, puts in the R-URI and what it does with the
Route headers;
otherwise Record-Route is always going to be problematic when interoperating.

Regards,

K. Robinson.

"Fairlie-Cuninghame, Robert" <[email-masked]> on 16/01/2001 10:36:41

                                                              

 To:      Keith Robinson/MAIN/MC1@MCMAIN                      
                                                              
 cc:      [email-masked], Jonathan Rosenberg         
          <[email-masked]>                           

 Subject: Outbound Proxies Renewed (was [SIP] Proxy Routing   
          Logic)                                              

Trying to revive a stale unresolved thread ...

Keith Robinson wrote a very good synopsis of the problems but I disagree
with the conclusions drawn.

I would also like to reiterate Jonathan's design goals for a solutions: that
a proxy should not need to know whether it is being used as an outbound
proxy or have to take special action when being used as a outbound proxy.
The UA should be responsible for taking any action required (given that the
UA is the only entity that knows whether it using a proxy as an "outbound
proxy").

We seem to have two cases on the UA side:
1)   Does not have "Outbound Proxy" configured _or_ only needs to use
outbound proxy for SIP routing of initial request in a Call Leg.
2)   Needs to use outbound proxy for all SIP messages because it lacks
some ability. Eg DNS.

And we seem to have three cases on the proxy side. The proxy is
(unknowlingly) acting as a
1)   Normal proxy for UA, may or may not Record-Route.
2)   Outbound proxy for UA, no Record-Route needed [eg outbound proxy
only used for routing initial request]
3)   Outbound proxy for UA, needs to Record-route [eg. Firewall-like
proxy that must be used for all requests]

I am a proponent of Keith second course of action, that is, the UA does
_not_ strip the Route if it cannot use it (ie, UA case 2). [And Jonathan's
original suggestion]. However, I have a slight key modification! If the UA
sends a message without using the first Route header (assuming one exists),
then the request-URI is set to the outbound proxy's address !! eg
sip:proxy_address

Let me first say that I am not in favor of using Record-Routes of the form
Record-Route: original_request_uri;maddr=proxy_address.
Under the new record-route rules this should not be required. The "problem"
that Keith poses is a good example of why this form of record route is bad.
Whenever a Route header of this form is used, the maddr is often dropped. A
proxy that sees the request has no way of knowing whether the Request-URI is
due to a Route header that the proxy added itself (or not). In the first
case proxy should use the next route; otherwise I believe it should merely
forward the request to the Request-URI as written.

In my mind, it is this problem that causes the difficulties that are being
experienced.

The only problematic situation of all the above outbound proxy UA/proxy
permutations is when the proxy record routes _and_ the UA does not remove
the record route. (Proxy case 3 & UA case 2). So the first Route entry is
actually the Route header added by the outbound proxy- but now the
Request-URI will be equal to the proxy's address.

A proxy should not gobble/use the next Route header unless the Request-URI
specifies the proxy itself, right?  So it makes sense that when the proxy is
(unknowingly) acting as an outbound proxy _and_ the first record-routed
proxy that you might have to route/process a message twice (logically). The
UA inserted request-uri ensures that the message is routed to the outbound
proxy and that the proxy is able to use the next Route entry.

I don't see it as a problem that the proxy receives a request (to which it
is the target) and also finds itself in the first Route - it shouldn't break
things. Spiral routes included. The proxies need to differentiate multiple
Record-Routes for spiral routes in any case !! The first proxy should see
itself as the target of the Request-URI (due to UA's actions) which allows
the proxy to process the next Route header. Finding yourself as the next
recipient should not break things - its possible for this to occur with
spiral routes in any case, right?

This topic brings many of the currently contentious SIP issues out into the
open: Record-Route mechanism, maddr problems, transparent proxies and of
course outbound proxies. I'm sure many people will disagree but I thought I
would at least throw another cat among the pigeons.

Regards,

Robert.

          -----Original Message-----
          From:     Keith Robinson [mailto:[email-masked]]
          Sent:     Thursday, January 04, 2001 3:42 AM
          To:  [email-masked]
          Cc:  [email-masked]; [email-masked];
[email-masked]; Jonathan Rosenberg; [email-masked];
[email-masked]; [email-masked]
          Subject:  RE: [SIP] Proxy Routing Logic

          The main conflict appears to be when a call stateful proxy,
which is acting as
          an outbound proxy for some UAs, record routes.
          The question for subsequent requests is who does the popping
of the first ROUTE
          entry into the R-URI ?

          For the UA, the two cases are :

          a) The UA pops the first route entry into the R-URI and
sends to its outbound
          proxy

          or

          b) The UA sends the request directly to its outbound proxy
without modifying the
          Route header and using, say, the URI in TO field as the
R-URI

          For case (a) the proxy (serving sipnet.com)  will see
something like the
          following
          (Assume the original request was addressed to
[email-masked])

          INVITE sip:[email-masked];maddr=proxy.sipnet.com

          the Route header may or may not be empty dependant on
whether further
          downstream proxies have record routed.

          For case (b) the proxy will receive something like

          INVITE sip:[email-masked]
          Route: <sip:[email-masked];maddr=proxy.sipnet.com>

          Now,  for case (a), the request will be routed internally to
the appropriate
          call state machine
          using the R-URI, To, From and Call-Id headers. The request
will be processed and
          routed to the next server
          using information obtained from the original INVITE lookup,
stored CONTACT or
          the ROUTE header
          if present.

          For case (b) the request will be routed internally to the
appropriate call state
          machine as for
          case (a). The request will be processed and routed to the
next server using the
          ROUTE header
          which will send it back to the this proxy, identifying the
same call state
          machine as before; at best
          this will cause the request to be processed twice, at worst
it could cause
          problems with state,
          duplication of output etc,. The situation could be even
worse if the proxy uses
          rr-params to store state
          information to be returned in the R-URI, perhaps for
identifying spiralled call
          state machines.
          To stop this from happening, the proxy would have to perform
some look ahead
          processing on the
          Route header before deciding whether or not to actually use
the next Route
          entry, or merely
          remove it; this is special case processing on the usage of
the Route header and
          could become problematic if the proxy appears more than once
in the Route list
          due
          to spiralling.

          I therefore think that the UA should function as in case (a)
to eliminate the
          problems associated with
          case (b).

          Now, consider what happens when a UA operating as in case
(a) sends a subsequent
          request to
          its outbound proxy BUT the outbound proxy has deliberately
NOT record routed
          because it is not
          required to keep call state; however, two further downstream
proxies, serving
          nextsipnet.com and
          furthersipnet.com, HAVE record routed.

          The UA will have constructed a ROUTE header that looks
something like:

          Route: <sip:[email-masked];maddr=proxy.nextsipnet.com>
          Route:
<sip:[email-masked];maddr=proxy.furthersipnet.com>

          When the UA sends a subsequent INVITE, because it functions
as in case (a)
          it will pop the first Route entry into the R-URI, and send
this to its outbound
          proxy
          as it can't resolve proxy.nextsipnet.com because it has no
DNS capability.

          The proxy will receive the following :

          INVITE sip:[email-masked];maddr=proxy.nextsipnet.com
          Route:
<sip:[email-masked];maddr=proxy.furthersipnet.com>

          And this is the central point of the debate; should the
proxy route the above
          request by popping the first route entry into the R-URI, or
should it use
          the maddr in the R-URI received. In this case, the proxy
should clearly
          route the request using the maddr in the received R-URI,
otherwise
          proxy.nextsipnet.com will be bypassed even though it asked
to be kept
          in the path; this does, however, represent special case
processing dependant
          on the contents of the maddr.

          If the UA had functioned as in case (b) for the above
situation, then the proxy
          would need to route using the Route header.

          So, special case processing at the proxy appears unavoidable
no matter
          whether the UA functions as in case (a) or case (b), and
whether a proxy that is
          being used as an outbound proxy has record routed or not. I
think the question
          has
          to be is what special case processing is preferable and what
are  UA mandated to
          do with the Route header if they wish to use an outbound
proxy for subsequent
          requests.

          IMO, UAs using an outbound proxy should function as in case
(a) and proxies
          should look at the value of the received maddr before
deciding whether or not
          to route using the Route header if available. This provides
for the simplest
          rules; requiring the proxy to look at the entries in the
Route header before
          deciding
          if it can use the first entry (situation arising through
case (b) ) seems much
          more complex
          and prone to error.

          The text in 6.34.3 is unclear as to what a UA must do if it
is using an outbound
          proxy; I think
          it will lead to some UA functioning as in case (a) and some
as in case (b) which
          is the
          worst scenario as it becomes almost impossible for proxies
to know which
          processing
          to apply.

          Also, considering the above and continuing my previous point
on this thread
          about
          a roaming UA wishing to route through the context of its
home domain proxy I
          have the following in mind.

          A UA at visitednet.com has been given proxy.visited.net as
its local outbound
          proxy.
          The UA wishes to set up a call through its home domain proxy
to
          [email-masked].
          The UA may well construct a Route header to get to
proxy.homenet.com which looks
          like:

          Route <sip:[email-masked];maddr=proxy.homenet.com>

          Now, a UA that functions as in case (a) will send the
following to
          proxy.visitednet.com

          INVITE sip:[email-masked];maddr=proxy.homenet.com

          The Route header will be empty, as the UA has already popped
the entry
          into the R-URI.

          Upon receiving this request, proxy.visitednet.com (which
assumes all UA do case
          (a) )
          will see that the maddr refererences a domain not served by
itself and so
          forward the
          request to proxy.homenet.com, which will see the request:

          INVITE sip:[email-masked];maddr=proxy.homenet.com

          which is Billy's very first example on this thread.

          In this case I would want proxy.homenet.com to now route
using the URI
          [email-masked], which was my original point.

          If the UA functions as in case (b) then proxy.visitednet.com
(which assumes all
          UA do case (b) )
          receives

          INVITE sip:[email-masked]
          Route: <sip:[email-masked];maddr=proxy.homenet.com>

          proxy.visitednet.com then pops the first Route entry into
the R-URI and forwards
          to proxy.homenet.com
          which receives the following

          INVITE sip:[email-masked];maddr=proxy.homenet.com

          which is exactly the same as if the UA/proxy were
functioning as in case (a).

          So, to summarise, assuming UAs function as in case (a), if a
proxy receives a
          R-URI
          with an maddr that does not reference the domain the proxy
serves then the proxy
          sends the request to that maddr, regardless of the Route
headers; if a proxy
          receives
          a R-URI with an maddr that does reference the domain it
serves then it strips
          the maddr
          and goes through the normal routing procedures. The only
special case processing
          is
          the result of checking the maddr.

          Regards,

          K. Robinson.

          [email-masked] on 02/01/2001 15:07:13

           To:      [email-masked]

           cc:      [email-masked], [email-masked],
Jonathan
                    Rosenberg <[email-masked]>,

                    [email-masked], [email-masked],

                    [email-masked](bcc: Keith Robinson/MAIN/MC1)

           Subject: RE: [SIP] Proxy Routing Logic

          Jonathan Rosenberg wrote;
          >To comment on the primary issue, ignoring the Route header
if the request
          >URI domain is not your own, and sending it to that domain
first, is
          >dangerous, IMHO. Thats because, nearly as I can tell, it
completely breaks
          >the existing usage of record-routing. In the existing
usage, a proxy copies
          >the request URI in the request into the record-route, and
adds its own
          >maddr. Requests in the reverse direction will only get
routed correctly
          >through that same set of proxies IFF each proxy uses the
top route header no
          >matter what. If proxies start to only sometimes use them,
we will end up
          >with incorrectly routed requests.

          I'm not sure if 'ignoring the Route header if the request
          URI domain is not your own, and sending it to that domain
first' breaks
          anything.
          I can see it may add another proxy to the path, but at least
all record-routed
          Proxies are on the path as well. Doing otherwise will break
routing (I gave an
          example
          in one of my previuos postings). I would argue that proxy
cannot blindly follow
          logic 'replace RURI with Route' no matter what just like it
does not proxy
          responses
          downstream if top-via doesn't match the server - it checks
if it matches first.

          >So, I would modify my proposal to satisfy some of the other
requirements:

          >1. If there is a Route header in a request, that ALWAYS
takes priority for
          >routing the request.
          >2. If there is none, and the request URI has a domain NOT
matching that of
          >the server, but the address/domain in the maddr does, the
server forwards to
          >the domain in the userhost portion of the R-URI. If the
neither the maddr or
          >userhost have an ipaddress/domain matching the proxy, the
proxy sends the
          >request to the address in the maddr. Stripping of maddr is
optional.

          your 2 suggestion is really close what I would have in mind.
There's also
          another
          scenario: where Proxy receives a request with maddr where
neither maddr nor host
          portion of RURI matches the server.

          Let's say proxy at sip.company.com receives a requests like:

          sip:[email-masked];maddr=proxy.com
          .......
          Route:
<sip:[email-masked];maddr=yet-yet-someone-else.com>

          As Billy pointed out you, being the proxy, don't really want
to pop Route header
           blindly. I would rather
          propose something along theses lines - it is really close to
your 2 case (it
          also takes care of scenario where
          Proxy has it's own outbound Proxy which may have its own
outbound Proxy etc - if
           you were to pop Route at
          every hop the message would never get to the proper
Proxies):
          Investigate RURI first:
          1)   if maddr exist and it doesn't match your domain send
message to:
               - address indicated in maddr and strip maddr.
               - or, if outbound Proxy is used, to outbound Proxy and
preserve maddr
               - or, return 488 if unwilling/unable to forward the
request (I explained my
           reasoning for 488 in previous posting)
          2)   if maddr exist and it matches your domain strip maddr
and go to 3
          3)   if host part of RURI doesn't match your domain send
message to:
               - address indicated in host part of RURI and preserve
existing RURI and
          Route(s),
               - or, if outbound Proxy is used, to outbound Proxy and
preserve existing
          RURI and Route(s),
          4)   if host part of RURI does match your domain pop first
Route header and go
          back to 1
               (now your RURI is whatever Route header contained).
          5)   if there's no Route header do whatever you want (get
contact from your
               location/registrar server most likely) and go back to 1
(now RURI is
          whatever you got
               from location/registrar server)

          regards, Jacek Grabiec
          sip:[email-masked]

          _______________________________________________
          SIP mailing list
          [email-masked]
          http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 19 Jan 2001 07:21:48 -0800

> Thanks for reply, even if you didn't agree !

Hi Keith,

I'll agree to the easiest, least brittle method _ I'm just trying to get it
settled. I'm actually having a bit of a change of heart. The reason I didn't
like your (a) suggestion originally [use first Route even if you don't send
to it] was because of maddr's in the Record-Route and the potential problems
they caused with chains. For example Record-Route's of the form:
sip:[email-masked];maddr=localproxy. 

If a proxy does not use this format but instead ensures that the
Record-Route will always route to the proxy (eg Record-Route:
<sip:[email-masked];state=6867868965454890> ) then I don't see too
much of a problem with removing the Route even if you don't actually send
the message to that address. If the Record-Route globally routes to the
correct proxy then you should be able to send the request to any outbound
proxy without problems - it must get there eventually (and intermediate
proxies shouldn't remove any further Record-Routes).  

Another reason I am having a change of heart from the other suggestion
[leave Route in place until it is used] is that in the case where there is
no Record-Route header (just a Contact) then the UA may have to make a
special case for outbound proxies used for all requests.

Regards,

Robert.

> abstract user name for case (b), say 
> [email-masked]) as opposed
> to