Subject: RE: [SIP] Stateless Proxy

From: "Pizzimenti, Joe" <[email-masked]>
Date: Fri, 08 Sep 2000 16:22:21 +0000

Agreed.

- Joe

-----Original Message-----
From: Gethin Liddell [mailto:[email-masked]]
Sent: Friday, September 08, 2000 11:45 AM
To: Pizzimenti, Joe; [email-masked]'; [email-masked]
Subject: RE: [SIP] Stateless Proxy

Stateless proxies do NOT generate responses of any kind.

As soon as responses are created, it becomes stateful.  Now this all
leads into the argument about how a stateless proxy is only a logical
role that can be applied in certain circumstances (i.e. when everything
is good and great) as soon as errors/redirect/etc... occur then the
proxy needs to find someway to become stateful.

so stateless proxies only proxy.  if you have to re-direct, you have a
statefull server. if you don't want to turn statefull then the only
thing you can do is drop the request.

HTH

:)

On Fri, 08 Sep 2000, Pizzimenti, Joe wrote:
> Vimal,
> 
> According to the RFC 
> 
> The "action" parameter is used only when registering with the REGISTER
> request. It indicates whether the client wishes that the server proxy or
> redirect future requests intended for the client. If this parameter is not
> specified the action taken depends on server configuration."  
> 
> So if the action is not specified in the contact the server should, in my
> opinion, be permissive and proxy the request.
> 
> In the case where the registrar search results in action values of
> "redirect" then the server should redirect the response back to the
> originator.  When the intended behavior of the server is to only proxy
> requests, then when the server's registrar search results in a "redirect"
> action, I would think a 4xx response (e.g. "403 Forbidden") would be sent
to
> the originating agent.
> 
> Also, according to the RFC, "All current registrations MUST share the same
> action value.  Registrations that have a different action than current
> registrations for the same user MUST be rejected with status of 409
> (Conflict)."  
> 
> - Joe Pizzimenti
> WorldCom

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Sep 2000 11:29:00 -0400

> From: Jo Hornsby [mailto:[email-masked]]
> > > > I would still question the assertion that an ACK
> > > > without a Route never needs to be routed on by
> > > > a Proxy. For example when a UA is configured to
> > > > always use a Proxy for every outbound request.
> > > 
> > > There are two interpretations of the outbound proxy concept:
> > > 
> > > (1) It's clearly needed to force routing for the first 
> request in a
> > > transaction or call, since Record-Route isn't available.
> > > 
> > > (2) It could be implied for each request, regardless of 
> Record-Route.
> > > Isn't strictly necessary, since Route can do the job, but it seems
> > > easier to have outbound proxy mean "always use, even if it doesn't
> > > record-route". My impression is that most implementation 
> always use it
> > > if configured.
> > 
> > Actually, I thought that outbound proxy would apply only for 
> > requests which don't already have Route. The reason is that this
> > gives the provider flexibility - if they want to see every request,
> > they  record-route. If they just need to see the first, then they
> > don't.
> 
> It might be helpful to have some clarification here in the spec;
> the current definition is:
>     Outbound proxy: A proxy that is located near the originator of
>     requests. It receives all outgoing requests from a particular UAC,
>                           ^^^
>     including those requests whose Request-URLs identify a host other
>     than the outbound proxy. The outbound proxy sends these requests,
>     after any local processing, to the address indicated in the
>     request-URI. (All other proxy servers are simply referred as
>     proxies, not inbound proxies.)

Right - thats the current definition in the bis draft. RFC2543 offers no
definition. The question is - is this current definition correct, or do we
want to rather specify that the local outbound proxy is used ONLY if there
is no specified route as a result of a previous Contact or Record-Route.

> 
> I would also note Section 11.4:
>     If a UAC does not support DNS resolution or the full
>     Record-Route/Route mechanism, it MAY send all requests to a
>     locally configured outbound proxy. In that case, that proxy
>     behaves as described above. The UAC MUST, however, perform the
>     mapping of Record-Route to Route header fields and MUST include
>     all Route header fields, i.e., the UAC does not remove the first
>     Route header field.
> 
> Thus it's potentially a bit messy (although will work) if an
> outbound proxy decides to add itself in Record-Route, since
> re-INVITEs, or what have you, are likely to needlessly loop
> through the outbound proxy (okay -- so the proxy could be
> intelligent here).

Yuck; we really need consistent behaviors here. I'd rather specify that the
local proxy needs to, or doesn't need to, add itself, but not both.

> 
> I think Henning's observation on most UACs using an outbound
> proxy for _every_ request is about right (after all, that is
> what the spec says); however, as Johnathan points out, just
> using it for initial request would seem to give the necessary
> flexibility.

Lets be clear - its what bis says right now. RFC2543 says nothing, and thus
the need for discussion.

My preference is to require the outbound proxy to record-route if it wants
subsequent requests.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2000 00:38:09 -0400

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, September 15, 2000 10:04 PM
> To: Jo Hornsby
> Cc: Jonathan Rosenberg; 'Neil Deason'; [email-masked]
> Subject: Re: [SIP] Stateless Proxy
> 
> 
> Jo Hornsby wrote:
> > 
> 
> > Seems right to me; the only exceptions are of course if
> > Record-Route were present, and if there were no Contact (in
> > which case I guess one uses To).
> 
> Clarified the Section "Caller Receives Response to Initial Request" to
> read, in part:
> 
> If the 200 (OK) response contained a \header{Contact} header 
> field, it   
> is copied into the \header{Request-URI} of the {\ACK} or {\BYE}
> requests.  Otherwise, the \header{To} header field address is copied
> into the \header{Request-URI}.

This is still not correct; it would only be true if the 200 OK had no
Record-Route parameters. Why not just reference the section on Record-Route,
and say that you need to set the Route header + request URI as defined
there?

> There is a slight twist here. A minimal client does NOT have to
> implement Record-Route/Route (only a firewall-friendly client 
> does). 

These days, I'm not sure that such a minimal client is worth anything at
all.
Realistically, every UA needs to support Route and Record-Route if they
ever want to leave the lab.

For
> firewalls to work, the "every request" rule seem safest. The only
> drawback is an increase in messages for those outbound proxies that
> really only want to see the first request. I don't recall seeing an
> example of a practical application where this would be required. All
> examples where proxies want to be in the path are for the 
> whole call, as
> for firewalls, billing, and ACDs.

Its a bit of a stretch, but I could imagine large networks that have a
hierarchy of outbound proxies. The first stage determine which peer SIP
network to terminate to, and then the second stage would be a firewall/nat
controlling proxy. The second stage would need to see every message, but the
first stage wouldn't. This would mostly be an issue for phone numbers.

> 
> One could make the distinction that minimal clients always send to the
> outbound proxies and others listen to the Record-Route/Route 
> info, but I
> somehow don't see that adding yet another obscure distinction to the
> spec as helpful.

Yuck. We should be completely consistent here.

> 
> Thus, since the negative consequences of sending subsequent 
> requests to
> the proxy is far greater than sending an extra ACK, BYE or 
> re-INVITE to
> a proxy server that could do without them, the simple "always" rule
> seems least likely to cause surprises and debates about backward
> compatibility.

Here's an issue, though.

With this behavior, a local outbound proxy should never record-route. Since
if it does, it will end up getting requests that have the top Route header
pointing to itself. These *may* work, since we have just agreed to disable
loop detection when Route is present, and the addition of the additional via
branch ID would make the looped request look different from a transaction
perspective. Even so, its not pretty.

Problem is, local outbound proxy is a logical role. For different requests,
it may not even be sure whether it is, in fact, a local outbound proxy for a
given request. The proxy will thus need logic to determine for which
requests it is a local outbound proxy, and for those, disable RR, and for
others, keep it on. This is quite a pain. Seems simpler that a proxy always
record-routes if it wants subsequent requests for the same call.

-Jonathan R.

---