Subject: RE: Proxy Server Inconsistencies

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Thu, 21 Jan 1999 21:44:36 -0000

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> 
	...snip...

> >The third approach seems to minimize the amount of messaging required.
> 
> I'm not sure how; for each call-confirmation period, there would be
> three messages passed back and forth (INVITE, response, ACK). This
> looks like it is the most message-intensive proposal so far.
> 
> (Actually, a non-recurring SUBSCRIBE/NOTIFY implementation would be
> even more expensive, requiring a four message "SUBSCRIBE, response,
> NOTIFY, response" sequence).
> 
	My primary concern with the amount of messages was with option 2
when there are multiple proxies involved in the session.  If each proxy
sends the PING according to its schedule, their could be an inordinate
number of PINGs floating around in the network.  This could be dealt with by
a proxy only sending a PING if it has not seen a PING/ACK combination for a
specified period of time.

	Option 1 has a similar problem if each proxy involved needs to send
a SUBSCRIBE to each participant in the session and each user agent involved
in the session needs to send a NOTIFY to each proxy involved.

	I don't see the need for the ACK in the INVITE, response, ACK
sequence, and I would think it would be defined such that only one
participant in the session would extend the length of the session.  This
would be compared to the proxy needing to send a PING to both parties or
receive a NOTIFY from both parties (although one could argue that the NOTIFY
would not need to be responded to).

	...snip...

---

From: [email-masked] (Adam B. Roach)
Date: Thu, 21 Jan 1999 17:22:01 -0600 (CST)

>From: "Donovan, Steven R. (MCI)" <[email-masked]>
>

Since it makes no sense for stateless proxies to send a PING, it's
really only proxies in the chain that maintain call state for the
duration of the call we need to worry about. If we allow these
proxies to process PING requests locally, the problem of superfluous
PINGs goes away. In any given proxy chain, each link will carry
PINGs *only* between the two closest stateful servers (proxies
or UAS:s)

>in the session needs to send a NOTIFY to each proxy involved.

This could be solved similarly to what I described above, but the 
semantics get more confusing.

>sequence...

Not having it there adds additional complication to the already
confusing world of INVITE final response handling. (New rules would
include: don't send an ACK when you receive a final response for an
INVITE request involving a currently ongoing session, but ONLY if
none of the session parameters have changed).

>...and I would think it would be defined such that only one

In the same vein, there is nothing preventing a proxy from PINGing
only one client involved in the call. Both have the same implications.

/a