Subject: Re: Proxy Server Inconsistencies

From: Sean Olson <[email-masked]>
Date: Wed, 3 Feb 1999 09:07:50 -0600 (CST)

> I agree that the PING method seems to add as much load in the
> _stateful_proxy_ as the re-INVITE. But, I believe it's a option for a
> proxy to be stateless for certain SIP transactions, e.g. those received
> via UDP. I think being stateless for a SIP transaction makes the proxy
> more efficient and reduces the load on it since it does not need to
> remember anything about the transaction ( retransmissions, TCP
> connections, timeouts... ).
> 
> Now, consider a proxy that keeps a call record for the duration of the
> session and thus wants to know when it ends. To be efficient, it acts
> like a stateless proxy per SIP transaction if possible. When the proxy
> receives a SIP message it can act stateless on it just updates its call
> record if the session has changed and then forwards it forgetting
> everything about the SIP transaction the message is part of.
> 
> A re-INVITE SIP transaction will not force the proxy to become stateful,
> but the PING transaction will since the proxy itself initiates it.
> 

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)

> 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"? 

> /Lars
> 
> -- 
> Lars Berggren       <[email-masked]>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414
> 

Sean Olson

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Lars Berggren <[email-masked]>
Date: Thu, 04 Feb 1999 10:25:03 +0100

> (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.

> 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