Subject: Re: Proxy Server Inconsistencies

From: Sean Olson <[email-masked]>
Date: Thu, 4 Feb 1999 09:33:11 -0600 (CST)

> Sean Olson wrote:
> > 
> > 
> > If a proxy is stateless, it NEVER has to initiate a PING transaction. It
> > handles the PING transaction just like any other transaction without adding
> > any additional state/timers/etc. That is the nice thing about introducing a
> > PING method, only those nodes that need to use it have to deal with the added
> > complexity, to all other nodes its just another method to be passed along.
> > (of course the UAS must handle the PING in all cases)
> 
> This was an example of a 'stateless proxy' that _needs_ to use the PING
> method. Do you think it should rely on that someone else is PINGing?
> This is the case of the re-INVITEs, where the proxy uses the re-INVITEs
> to determine liveness. But with PING it is not guaranteed that someone
> is PINGing, is it? Whereas the re-INVITES are sent during the lifetime
> of the session.
> 

The "guarantee" that re-INVITES get to the 'stateless proxy' above depends
on the proxy using a Record-route: header. The purpose of a PING is to
determine the liveness of a call irregardless of the current path for call
control. There is no guarantee that someone is PINGing the proxy in this case,
but since he is the one wanting liveness information, he should be sending
PINGs. There are pros and cons to both approaches. I don't really care which
approach is taken as long we can standardize on one and get it implemented on a
broad scale. :) 

> > 
> > > Hence, I think the PING method adds more load in a proxy that tries to
> > > be stateless per SIP transaction.
> > >
> > The issue of course is how long does the proxy keep that state/call record
> > around. To figure that out, the proxy examines every message associated
> > with that call and update the call record according to the current state of the
> > call (necessary for error handling at least).
> > 
> > Plus the proxy has to maintain the same T1-T4 timers that
> > every other node does. I don't see then, how a proxy that maintains a call
> > record, can be "stateless per SIP transaction"?
> >
> 
> It is a difference between having state for a call leg ( a SIP initiated
> session ) and having state for a SIP transaction (requests-responses
> identified by the CSeq within a call leg). A proxy that have state for
> the transaction and thus implements the client and server state machines
> is what I call a stateful proxy. A stateless proxy is the opposite, it
> does not have state for the transaction. Whether a proxy has state for a
> call leg or not is not relevant when I classify the proxies as being
> stateless or stateful.
> 
> Let me clarify what I mean by a stateless proxy that keep call records
> for the duration of the session. Call this proxy P.
> 
> P records on-going sessions initiated by SIP. Each initiated session is
> determined from the To, From and Call-ID header fields ( the call leg )
> of an INVITE-200-ACK sequence of SIP messages. P records details of the
> session and thus wants to know when it changes or ends.  The recording
> of on-going sessions does not force P to be stateful for all SIP
> transactions. Rather it is the transaction itself that may require it.
> If the transaction requires that P is stateful, e.g. P accepted a TCP
> connection, P becomes stateful and implement the server and client state
> machines for this transaction. Otherwise, it acts like a stateless
> proxy, forwarding messages without state machines. In both cases, it
> updates the session record if there are changes in the session.
> 
> Am I wrong in my thinking here, have I misunderstood something in the
> SIP spec? Please let me know.
> 
> /Lars
> 
I understand the distinction you are making. I regard a proxy as stateful
if either 1) It is handling TCP connections or 2) It is maintaining call record
(per call leg) information.  (Of course many proxies will do both)

In the first case, no re-INVITES are necessary. When the client closes the
connection, the proxy knows based on the current state of the call how to
proceed. The SIP standard is well defined in this case.

In the second case, a re-INVITE or PING is necessary. Either the proxy has
to be involved in all points of the call or it must be able to determine
externally if the call is still up.

I just hope one or the other approaches can make it into the SIP standard.

/Sean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Feb 1999 21:49:08 -0500

> I just hope one or the other approaches can make it into the SIP standard.

Well, its clearly too late for this, since SIP is now officially
approved. So, the question is whether to (1) have it as an extension,
(2) roll it in for draft, (3) cycle SIP at proposed later on and then
add it in then. 

I would probably prefer making it (whatever it is) an extension, and
then see how deployment goes. If people really implement it and make use
of it, it can be added to the spec itself when it goes to draft or
cycles at proposed, depending on which happens.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen