Subject: [Sipping] comments on draft-rosenberg-sipping-arch-00

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 17 Mar 2005 15:08:24 -0500

Some comments on this excellent doc.:

-         Section 3.1 states that a proxy "does not" maintain call state.
The document is about architecture, so my suggestion is that it should be
"should not". Most proxies today maintain some kind of call state. Not
maintaining the call state certainly makes things simple and easy to build
systems which are more available, scalable and flexible. However systems
could still be highly available and scalable depending how they are designed
internally. I think what we really need to say here is that the main
function of proxies is routing and SIP would work even if the proxy
maintained no call state. This makes it easier to build highly available and
scalable systems.

-         In section 4.2, we should also talk about the more interesting
case of the re-INVITE having different ports than what it was before
(redirection etc). The intermediate system performing inspection would now
need to know the previous state as well. I guess this starts to interact
with some earlier comments on proxies, state etc.

-         The document does not talk too much about application servers.
These may be dealt as endpoints, but since they sometimes provide proxy like
functions, this interacts with how state and features work across them and
other things in the document. I think this also connects to the familiar
issue of B2BUAs which are getting deployed in greater numbers, reasons being
the flexibility they offer (because their behavior is left unspecified).

-Medhavi.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP