Subject: RE: evolving behavior of proxy servers

From: "Paul Defrain" <[email-masked]>
Date: Fri, 29 Oct 1999 10:13:43 -0500

Bill,

I would concur that there seems to be a slide towards "relaxing"
requirements on the path of messages subsequent to an INVITE where proxys
are concerned considering that the Contact header has risen in
"significance" in the latest draft of RFC-2543. The consensus seems to be
that one uses the Record-Route and Record headers to nail down a path from
end-to-end. In certain applications it is critical that the path traversed
remain unchagned for all messages involved in a particular session (all
messages related to a particular SIP session). One must rely on components'
adherence to the standard when a fixed message path is desired. There are
measures that can be employed to protect servers from non-compliant
clients/components -- see recent mailings on this list for these examples. 

__________________________
Paul D. DeFrain
IP Services SIP Feature Development
ESN 444.7570 (972) 684.7570
[email-masked]

> -----Original Message-----
> From:	Bill Newman [SMTP:[email-masked]]
> Sent:	Thursday, October 28, 1999 6:04 PM
> To:	[email-masked]
> Subject:	evolving behavior of proxy servers
> 
> I'm trying to update a presentation summarizing how SIP works.
> 
> In reading RFC2543 and looking at some older slides on SIP, it
> looks as though the original default behavior of SIP was to 
> have ACKs and BYEs travel back through proxy servers, through
> the same paths as INVITEs and OKs.
> 
> >From a number of more recent sources, notably the "Wandering ACKs"
> entry in the SIP bugs page
>   <http://www.cs.columbia.edu/~hgs/sip/notes.html>
> it appears that that behavior is no longer favored, and the 
> future standard will send ACKs and BYEs directly from user agent
> to user agent, bypassing any proxy servers.
> 
> Is that correct?
> 
> Furthermore, is it correct that the issue here is largely
> a tradeoff of two desirable features
>   (1) In the old way, proxy servers had the opportunity to 
>       (crudely, modulo network errors and ill-behaved clients
>       and other real-world stuff) keep track of what calls
>       were in progress.
>   (2) In the new way, proxy servers not only don't need to retain
>       call state, but don't need to have any sort of constant
>       state, so all sorts of hairy time-dependent or random
>       behavior (e.g. ACDs) can be implemented without messing up
>       calls.
> and that the consensus is now that (2) is more important than (1)?
> 
>   Bill Newman
>   Nortel Networks
>   [email-masked]
>