Subject: [Sip] RE: [Sipping] RE: [Sip-implementors] 4xx by stateless proxy

From: Jiri Kuthan <[email-masked]>
Date: Mon, 05 Nov 2001 04:00:40 +0100

[resent to sip]

Why is a redirect server expected to be stateful
(bis-05, Section 8.3)? IMHO, one of great uses
of redirect servers is increasing network scalability.
They can distribute traffic across multiple destinations 
and allow upstream clients to cache the returned routes.
Going stateful reduces scalability of such a server.

-Jiri

At 05:16 AM 11/1/2001, Jonathan Rosenberg wrote:
[...]
>Stateless proxy is just a ROLE. If an element needs to generate a response,
>it becomes a UAS. We have tried to make that consistently clear in bis-04. 
>
>That said, it is possible for a UAS to statelessly generate a response. Each
>request retransmission would trigger the response to be recomputed and
>re-sent. This only works if the element never generates a 1xx, but rather
>responds with the final response right away. This is used, for example, to
>prevent unauthenticated requests from creating state in servers.

>[...] 
>> A stateless proxy receives an INVITE and doesn't have any destination
>> for it. What is it supposed to do? Generate 4xx upstream? 
>> Then who takes
>> care of the retransmission stuff? Note that this is a 
>> stateless proxy --
>> no call state, no transaction state. Or does it silently discard the
>> INVITE? Or does it dump the INVITE onto a UAS and let the UAS do the
>> dirty job? Doesn't sound elegant, though.

--
Jiri Kuthan            http://iptel.org/~jiri/

_______________________________________________
Sip mailing list  http://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: "Bob Penfield" <[email-masked]>
Date: Mon, 5 Nov 2001 09:00:09 -0500

> Going stateful reduces scalability of such a server.
It only needs to maintain minimal transaction state so that it would re-send
the same 3xx response if it got a retransmission. Otherwise, it would need
to completely process the INVITE each time. You have to ask yourself, is it
more expensive to maintain the transaction state or to re-compute the
redirection every time? If you did go stateless, would you get different
results for a re-transmission? And if you did would it really matter? Also,
would you just "eat" the ACK?

cheers,
(-:bob

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 05 Nov 2001 08:28:32 -0600

Jiri Kuthan wrote:
> (bis-05, Section 8.3)? 

Because it must match up the incoming ACK to the 3xx it send in response.  
Recall that the ACK is part of the same INVITE transaction in case of a 
non-2xx response.  Furthermore, it must also be able to match up a CANCEL, 
if one should arrive, to the INVITE, and stop further processing of the
INVITE.

> IMHO, one of great uses

Going transaction-stateful is not that prohibitive, I would assume.  
Furthermore, are there any other options, given that the protocol specifies
the 3 way handshake.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 05 Nov 2001 16:37:57 +0200

Hi,

>if one should arrive, to the INVITE, and stop further processing of the

If the server has sent 3xx the CANCEL will have no affect, no matter if
you keep state or not, right?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 05 Nov 2001 08:55:26 -0600

Christer Holmberg wrote:
> >non-2xx response.  Furthermore, it must also be able to match up a 
> >CANCEL, if one should arrive, to the INVITE, and stop further processing 
> >of the INVITE.
> 

Yes, of course.  If the CANCEL arrives after a 3xx has been sent, it has no
effect.  The redirect server will still need to generate a 200 OK to the 
CANCEL (assuming that the original transaction was still around in the
"Confirmed" state).  If the original transaction has been cleaned up, the 
CANCEL will probably result in a 481.

Regards,

- vijay

---

From: Dorgham Sisalem <[email-masked]>
Date: Mon, 5 Nov 2001 16:02:53 +0100

Hello,

> if one should arrive, to the INVITE, and stop further processing of the

I guess the question is: what will terribly happen if one just "eats"
the ACK? For the CANCEL, I guess there was already a great deal of
discussion mentioning that it is save to just ignore it by sending a
200 OK. I know this contradicts some of the pure interpretation of
SIP, but again what is the big harm done?

-- 
Best regards,
 Dorgham                            mailto:[email-masked]

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 05 Nov 2001 09:09:51 -0600

Dorgham Sisalem wrote:
> 
> Hello,
> 
> > Because it must match up the incoming ACK to the 3xx it send in 
> > response. Recall that the ACK is part of the same INVITE transaction in 
> > case of a non-2xx response.  Furthermore, it must also be able to match 
> > up a CANCEL, if one should arrive, to the INVITE, and stop further 
> > processing of the INVITE.
> 
> the ACK? 

Well, in the case of a non-2xx response, ACK basically is used on the server
end to stop retx'ing (if UDP is being used as the transport).  Unless you
are working on a lossless network, I don't think you can be sure that the
3xx send upstream over UDP actually made it.  The ACK serves as that not-
ification.

> For the CANCEL, I guess there was already a great deal of

You could probably get away with "eating" up a CANCEL, but not so on the
ACK.

Regards,

- vijay

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 05 Nov 2001 17:24:12 +0200

Hi,

I guess this does not only affect CANCEL, but also if the redirect
server receive a BYE (chapter 8.3 only talks about CANCEL) for the setup
(if the server first sent a 18x with a tag, and for whatever reason the
UAC wants to terminate the dialog)?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Dorgham Sisalem <[email-masked]>
Date: Mon, 5 Nov 2001 16:27:09 +0100

Hello,

> 3xx send upstream over UDP actually made it.  The ACK serves as that not-

considering that the UA client (or the last proxy that generated a
provisional response) would retransmit the request I do not see this
as a big problem.

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 05 Nov 2001 09:59:23 -0600

> UAC wants to terminate the dialog)?

Christer:

I am hard pressed to see why a *redirect* server would return a 18x response
to establish an early dialog...

- vijay

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 05 Nov 2001 23:23:48 +0100

Vijay,

assume having a stateless redirect server is a useful thing. I think
that in some scenarios a stateless request-reply service scales better
and is more robust than a public state storage service. This is where
I see its value.

It is difficult for me to find a use for ACK which is meant to tell 
stateful server "take it easy,  the client got it and you can stop 
retransmitting". A stateless server does not retranmist a message it 
does not remember. Thus, it does not need to be told to stop doing so. 
If a message gets lost, then the client who is primarily interested 
in seeing a reponse simply retransmits.

So what does break with a "stateless ACK eater"?

(I think CANCEL is clear now ... 481 is probably adequate if a client
 attempts to cancel provisional state which has never been estabslihed.)

Thanks,

-Jiri

[...]

At 04:09 PM 11/5/2001, Vijay Gurbani wrote:
>end to stop retx'ing (if UDP is being used as the transport).  
[...]
>Unless you

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 06 Nov 2001 07:42:34 +0200

Hi,

>to establish an early dialog...

Well, it IS allowed to do so, for whatever reason, so... Also, when it
sends the 18x it may even not yet know that the final answer is going to
be a 3xx, since the node may also have other than redirect
functionality.

And, even if it does know it will redirect the call, it will probably
have to make some database lookups etc, which take time, so it must send
some 1xx provisional response. Yes, it may send only 100, but SIP allows
it to also send 18x. Maybe it wants to play some kind of "your call is
beeing redirected" announcement, or something...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 06 Nov 2001 08:56:44 -0600

Christer Holmberg wrote:

> > Vijay Gurbani wrote:
> >I am hard pressed to see why a *redirect* server would return a 18x 
> >response to establish an early dialog...
>

Theoritically, yes; I agree.  But to my admittedly simple mind, the value of 
a redirect server *speed*.  If I wanted to engage in an extended dialog that
involved playing announcements, collecting digits, voice recognition, why 
not just use a richer service entity then a simple redirect server.

In a related thread we are arguing to keep redirect servers even simpler by 
"eating" up the ACK, yet here we are making them more complex by estab- 
lishing early call legs!

- vijay

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 06 Nov 2001 09:40:10 -0600

> in seeing a reponse simply retransmits.

Jiri:

What you describe above is response handling for non-INVITE transactions.
Since redirect servers send 3xx in response to an INVITE transaction (I 
guess they may do so for other requests -- REGISTER, for instance), the
rules for INVITE response retransmission for redirect serves have to be 
special-cased.

> So what does break with a "stateless ACK eater"?

Probably nothing.  I have argued that it is better to have a tacit 
understanding that a redirect server may "eat" up an ACK and retransmit the 
final response on arrival of a request.  It just seems to me that spelling 
this out in the spec may be inviting trouble (remember how many iterations
of constructing Routes from Record-Routes we had to go through...)

- vijay

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 06 Nov 2001 19:58:58 +0200

Hi,

Vijay Gurbani wrote:
>Theoritically, yes; I agree.

And, even if it's theoritically possible, it IS something we have to
take into consideration. Suddenly it may become reality - and then we'll
have this same discussion again...

>But to my admittedly simple mind, the value of a redirect server *speed*.

I don't agree. For example, the redirect server can try to take some
action (whatever that is), which may take some time. Also, which I said,
there may be a case where it doesn't know it's going to return a 3xx.
And, even if it DOES know it's going to return a 3xx it may take time to
find the correct value to return in the Contact header... or whatever.
And, if the redirect server is nothing more than a simple and fast
database, one could argue that SIP is not even needed to contact it -
use LDAP/whatever instead...

>If I wanted to engage in an extended dialog that involved playing announcements, collecting digits, voice >recognition, why not just use a richer service entity then a simple redirect server.

We should remember that a redirect server is not a physical thing - it's
a functionality. The node offering it may also offer other SIP related
services. And, again, I don't think we can assume that the redirect
server always - today and tomorrow - always will have the final reply
within 200 ms.
 
>"eating" up the ACK, yet here we are making them more complex by estab-

We don't make them more complex than any other SIP node...

Regards,

Christer (lmfchh)

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 06 Nov 2001 13:53:53 -0600

Christer Holmberg wrote:
[...]
> Vijay Gurbani wrote:
> >If I wanted to engage in an extended dialog that involved playing 
> >announcements, collecting digits, voice recognition, why not just use a 
> >richer service entity then a simple redirect server.
> 
> a functionality. 

Ultimately, any logical role has to be mapped to a physical reality.  And
we have to deal with the physical reality -- warts and all.

Which view is correct?  Streamlining redirect servers so that even the ACK
is optional?  Or burdening them with protocol accompaniments that that go 
beyond *quick* redirection (re-INVITEs, PRACK, 183 responses)?  We could 
debate ad nauseum about this without reaching any conclusion.  While SIP
provides the tools to do the latter, should we necessarily use them for
entities serving as redirect servers?

My personal feeling for redirect servers tend to be in the INVITE/3xx/ACK
category.  A redirect server should step out of the signaling path as soon
as possible and let the end points handle further communications.

Regards,

- vijay

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 06 Nov 2001 17:24:59 +0100

>of constructing Routes from Record-Routes we had to go through...)

Regardless of whatelse is spelled in the spec or not,
the sentence
“The redirect server maintains transaction state for the whole 
SIP  transaction.” seems too restrictive to me.

-Jiri

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 06 Nov 2001 22:33:14 +0200

Hi,

>as possible and let the end points handle further communications.

Yes, but in that case one could argue that 3xx is not even the correct
way to do it. Why can't the redirect server forward the INVITE to the
redirected destination instead, like a proxy?  Then, if the redirect
server doesn't insert its Via (or, it does insert its Via but puts the
UAS's address in the Via received parameter) it won't even have to
handle the responses. It would only need to forward the re-transmited
INVITE every time it receives it, until the UAC receives the 200 (or
whatever the final response will be), sent DIRECTLY from the UAS to the
UAC.

Is that nice SIP behaviour? Maybe not - but, what the heck: we DO get
rid of the redirect server from the signaling path very fast.

If we were to remake the protocol, I am sure there are things we would
do more effective (for example, I would like to be able to use PRACK
transactions without responses...), but I think we have to live with
what we have. And, if we start making "Diet SIP"/"SIP Light"/whatever
stuff for certain cases I am not sure we gain anything. 

And, as long as a redirect server IS allowed to send 1xx it may do so,
so this wouldn't even be general behaviour for a redirect server - it
would only be for a specific case.

I have spoken :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Paul Pangalos" <[email-masked]>
Date: Wed, 7 Nov 2001 13:46:33 -0000

Hi, has anyone got more information about the 
SIP INFO method. The only thing i found was 
rfc2976.

Thanks

Regards

Paul