Subject: RE: [SIP] Stateless Proxy

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 8 Sep 2000 15:20:55 -0400

Actually, turns out that you can send a response and be stateless, but 
ONLY if you don't send a provisional response first.

Here's how it goes. The "stateless" server receives a request, and sends
some response. It then forgets the transaction. The response is lost, but
thats OK. Because the client never got a 1xx, it resends the request. To the
stateless server, this is a brand new request, and it regenerates and
resends the
response. Voila - reliability. Any ACKs it gets would just be dropped. 

Neil writes:
>You would not expect to find a Stateless Proxy operating like
>this.
>In stateless mode a Proxy is really just a next hop router of SIP
>messages, where the next hop is most likely to be a stateful
>Proxy, 
>possibly co-located with a Registrar, or a Redirect Server.
>Proxies 
>operating in stateless mode can be thought of as existing in the
>core 
>of the network and being concerned with issues of performance,
>reliability and scalability. 

I disagree. There is no reason a stateless proxy can't talk to a location
server to access registrations, and use them to proxy. In general, a proxy
is best being stateless whenever it can, and routing services can almost
always be handled by a stateless proxy.

-Jonathan R.

> -----Original Message-----
> From: David Daiker [mailto:[email-masked]]
> Sent: Friday, September 08, 2000 2:44 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [SIP] Stateless Proxy
> 
> 
> 
> this is silly,
> are you saying that a stateless server that fails or can't
> decode the request can't respond with a 5xx or 4xx ?
> The only alternative is to drop the message and let the
> sender retransmit an invalid message 7 or 11 times ?,
> why not return the final response, if he gets it,
> he'll return an ACK which can be dropped,
> it not, he'll retransmit and you return the error again. 
> 
> Seems a lot friendlier to the sender, without any downside
> 
> what's the problem ?
> 
> david
> 
> 
> > 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
> > 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Sep 2000 09:03:02 +0100

> always be handled by a stateless proxy.

I did not say it was impossible, but the reason I would not 
expect this to be a typical configuration for a Stateless 
Proxy is that when a Registrar returns multiple locations a 
Stateless proxy cannot fork to them. I would expect a Proxy 
to operate in stateless mode when it is routing on to other 
domains. When it has a request for it's own domain, and hence 
is co-operating with the Registrar for that domain, it is 
Stateful.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Sep 2000 12:02:45 +0100

> response. Voila - reliability. Any ACKs it gets would just be dropped.

Any ACKs it gets would be dropped? If the stateless
server has no concept of transactions that it previously 
responded to this wouldn't this in effect mean all ACKs 
get dropped. I think that might break the odd thing, like
basic call setup for example. If you really, really  
wanted to do this sort of thing I would say you need to 
route on all ACKs and make sorting things out after your 
poor implementation somebody elses problem. Not at all to 
be recommended. If you want to send a response become
stateful, after all the spec states in 12.3 that:

"A stateless proxy forwards every request it receives 
downstream, and every response it receives upstream."

Cheers,
Neil.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 11 Sep 2000 13:50:05 +0200

Neil Deason wrote:
> get dropped.

Not necessarily. As long as the stateless server is able to recognize
that it has previously rejected the corresponding INVITE things should
work. This could be achieved in different ways, e.g.

 1. by the same logic that caused the server to reject the INVITE in the
first place (e.g. on basis of the request url). So if the server knows
that it rejects all requests destined for sip:[email-masked], it
can safely throw away ACKs destined for that address.

 2. If the server inserted a Contact header identifying itself (allowed
for 3xx responses), the ACK should be destined for the stateless server
itself, and can be safely discarded.

Basically, in this case state is not per-transaction, but per-server in
some implementation dependent way. The point is that it ends up behaving
as if it was transaction stateful. I agree it's not really
recommendable, though.

 I think that might break the odd thing, like

--
Anders Kristensen

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 11 Sep 2000 14:53:44 +0300

I agree that a stateless proxy should not generate responses.  I also think it
should not have registrar search capabilities.  It just forwards requests
(including ACKs).

The question here is what would a stateless proxy do when it recieves a request
with the host part of the request-uri indicating its domain?  Forwarding the
request will cause loops.  If searching a registrar or generating responses is not
the behaviour of a stateless proxy, do we drop the request?  how would the client
be informed?  should we just rely on retransmision timeout? (not very nice since
this does not inform the caller that his request is failing because the proxy he
is trying to contact is stateless)

regards,
Hisham

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 11 Sep 2000 14:06:27 +0200

> is trying to contact is stateless)

The proxy should respond with an error, in this case presumably a 404.
In this case the "stateless proxy" acts as a UAS and this would
ordinarily be done in a transaction stateful fashion. The point here is
that "proxy", "uac", "uas", etc are logical roles and a SIP entitiy may
be all of them at the same time for different transactions.

This must be the ultimate FAQ. Go check the list.

Anders

--
Anders Kristensen

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Sep 2000 13:10:41 +0100

Hi Anders.

Good to hear from you.

> can safely throw away ACKs destined for that address.

The same logic may not be applicable:
A "stateless" server gets an INVITE which is illegaly 
formatted and responds 400 Bad Message. The ensuing ACK is a 
legal message. Or the Server gets an INVITE with a Max-Forwards 
containing zero and responds 404, the resulting ACK does not 
have Max-Forwards set.

> as if it was transaction stateful. I agree it's not really

Yeah, I think we are looking at ways to hack state into 
stateless operation when there is no justification.

Cheers,
Neil.

---

From: David Daiker <[email-masked]>
Date: Mon, 11 Sep 2000 10:11:13 -0400 (EDT)

Neil,

a couple more ways of accomplishing this statelessly

when the stateless proxy creates the 'To:' tag in the final response,
it includes its own id that it recognizes in the ACK,

alternatively, if the server is configured to always redirect INVITEs,
because it fronts a registrar or other location service,
it could drop all ACKs without causing problems.

david

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Sep 2000 15:24:26 +0100

> it includes its own id that it recognizes in the ACK,

In a re-INVITE case you couldn't do this because a tag 
would already exist in the To: header.

> it could drop all ACKs without causing problems.

Or you could just be sensible and use a Redirect Server.
I see no good reason for wanting to do an ugly hack like 
this.

Cheers,
Neil.

---

From: David Daiker <[email-masked]>
Date: Mon, 11 Sep 2000 11:06:49 -0400 (EDT)

> would already exist in the To: header.

I think sending a spurious ACK into the network is preferable to
repeatedly dropping the original request

> I see no good reason for wanting to do an ugly hack like 

yeah, that's what I'm saying, a stateless redirect server,
I thought someone was asserting it wasn't possible, it is,
imo, nothing ugly about it.

david

---

From: Shail Bhatnagar <[email-masked]>
Date: Mon, 11 Sep 2000 11:36:25 -0400

I tend to think that the new bis version almost implies that :

1) An ACK without Route header is for the proxy and should be dropped.
(Stop response retx timer in stateful mode)

2) An ACK with Route header needs to be forwarded based on Route 
header.

Of course, to be sure about #1, stateful behavior helps.

Shail

-- 
Best regards,
Shail

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Sep 2000 17:05:07 +0100

> (Stop response retx timer in stateful mode)

What changes are you thinking of? I thought that a UAS MUST
add a Contact to a 2xx reponse for INVITE but it is only a 
MAY as to whether the UAC sends the ACK directly there.
Therefore an ACK without a Route may still need to be 
sent on by a proxy.

Cheers,
Neil.