Subject: [Sipping] draft on SIP architectural principles

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Mar 2005 03:06:27 -0500

Folks,

I wanted to call your attention to the following I-D:
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip-arch-00.txt

This is an attempt to summarize some of the key architectural and design 
principles that underly SIP. Henning and I would welcome comments and 
suggestions for additional principles.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 2 Mar 2005 10:25:54 -0500

I like this draft.

The only technical issue I thought of when reading is in:
   That said, the specifications do not prohibit proxies from invoking
   special routing logic based on method or other information in the
   message.  Such behaviors are typical of distributed proxy networks
   where the overall processing of a SIP user agent is distributed
   across multiple components, and a proxy is used to route messages to
   the appropriate component.

The problem is with the phrase "other information in the message".
If you had said "other information in the headers" I would have no 
problem.  By saying "in the message", you sanction examining the SDP, and
thus run afoul of SMIME encryption.

I noticed a few nits other than "wrong at once"
Section 3.2 "use a button the remote to indicate" missing an "on"
Section 3.4 "Of course, if the endpoints fail, the call is over even in any
case" probably doesn't need the word "even"
Section 3.8 "SIP has not tried to parsimonious in its" missing a "be"
Section 4.3 "Genreally speaking" oh really?
Section 4.9 "including non-SIP URI like the" probably "URIs"

Brian
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jonathan Rosenberg
> Sent: Wednesday, March 02, 2005 3:06 AM
> To: sipping
> Subject: [Sipping] draft on SIP architectural principles
> 
> Folks,
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 03 Mar 2005 10:17:36 -0600

> suggestions for additional principles.

Jonathan:

For old timers in SIP, this was an interesting read.  I have a
basic question though: what do you seek to do by capturing the
key set of architecture and design principles?  I see two reasons
to do so:

1) Explain why SIP works the way it does to provide
ammunition (or cover?) for those who want to use it in
an orthogonal way (dare I say the S word ... SBC :-))

2) Dissect what we have learned from the protocol.  Certainly,
Section 4.8 poses an observation that can only be gleaned
by hindsight.  But then we should also probably address
other things such as:
   a) Should forking have been made part of the base
   protocol?  Clearly, since SIP was designed as a rendezvous
   protocol, yes.  In pure SIP forking is not as much a
   service as simply a mechanism to find a user.  But since
   SIP's adoption as a telephony protocol, forking has been
   viewed as a service, similar to "Find me/Follow me".
   b) Does the endpoint model exacerbate the feature
   interaction problem?  We do have a feature negotiation
   mechanism in SIP which helps; but the negotiation mechanism
   may not help in prioritizing features (i.e. features A and
   B interact in such a way that A must be done first).

I have one suggestion for a new design principle: "Treating
new requests as non-INVITE from the transactional point of
view."  This design principle is what makes method
extensibility work seamlessly across existing implementations.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Mar 2005 23:36:01 -0500

inline.

Vijay K. Gurbani wrote:

>> This is an attempt to summarize some of the key architectural and 
>> design principles that underly SIP. Henning and I would welcome 
>> comments and suggestions for additional principles.
> 
> 
> Jonathan:
> 

The primary reason was that people ask all the time, and there is no 
written answer.

> an orthogonal way (dare I say the S word ... SBC :-))

I think there is some value in explaining these principles to folks that 
are building new components, systems, or protocols, yes.

>   protocol? 

Though Dean continues to have it on his "7 deadly sins of SIP list", I 
think the answer is yes.

  Clearly, since SIP was designed as a rendezvous
>   viewed as a service, similar to "Find me/Follow me".

The point being?

>   B interact in such a way that A must be done first).

Thats a good question. I have lots of thoughts on this, but rather than 
getting sidetracked on that, I'm not sure its an issue for this 
document, which is meant to be an enumeration of SIP protocol design 
principals. I assume you are not disputing that features live in 
endpoints in SIP?

> extensibility work seamlessly across existing implementations.

OK, I'll add that.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 08:38:26 -0500

> principals. I assume you are not disputing that features live in 

The problem is the definition of "feature". I'd consider the 'supported' 
  protocol extensions more as building blocks for possible features, not 
features (or services) themselves. Vijay, do you have a particular 
example of a clash in mind?

(And, yes, the combination of 'supported' declaration and caller 
preferences was intended to avoid many of the classical feature 
interaction problems that are caused by lack of indication of caller 
intent.)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Mar 2005 09:33:03 -0500

Henning Schulzrinne wrote:

> 
>>
>> Thats a good question. I have lots of thoughts on this, but rather 
>> than getting sidetracked on that, I'm not sure its an issue for this 

Lack of user intent causes some feature interaction problems, and 
explicit signaling helps fix those. App interaction also helps by 
allowing smarter sip phones to direct their stimulus to specific 
applications.

Other interactions, like forwarding/screening, are different. 
Independently of how they are signaled, there is an interaction that 
needs to be sorted out. In the PSTN world, big complex specs were 
written that describe the "standard" resolution of these interactions, 
and because the features were implemented in a single place - the switch 
- the resolutions could be implemented.

SIP has the interesting effect of moving some of the features into the 
endpoints, and some into the network. This means that you can not easily 
coordinate a resolution between features that run in the two places. I'd 
be curious if anyone has studied this in detail, and looked at whether 
this ends up being a problem in reality or just in theory.

Its also interesting to note that a pure endpoint model, where all 
features live in the endpoints, allows the endpoint to fully resolve the 
feature interactions in whatever way it chooses.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Mar 2005 09:38:29 -0500

Xiaotao Wu and I have looked at some of these issues and will have a 
paper in the upcoming Feature Interaction Conference. The final version 
should be out shortly. Xiaotao can send a pointer to the list once it is 
finished. That paper also cites a number of related recent efforts that 
try to treat this problem somewhat more systematically.

I think the outbound call screening service is largely useless, except 
as a feature interaction example and to prevent access to broad classes 
of destinations for billing purposes (900#, international calls), but 
there are plenty of other possible policy conflicts. We've discussed the 
caller preferences vs. callee policy one in the past.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Mar 2005 11:44:13 -0600

> - the resolutions could be implemented.

Agreed; but even then the feature interaction experts
say that this is not a solved problem (I am not a Feature
Interaction expert, nor do I play one on IP TV ;-).  I
just find this general area interesting).

> coordinate a resolution between features that run in the two places. 

Exactly.

> feature interactions in whatever way it chooses.

Unless of course, a feature in the endpoint wants to co-ordinate
itself with its counterpart in the network or in the far
endpoint.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Mar 2005 11:42:08 -0600

Jonathan:

I think so.  Given the rendezvous nature of SIP, forking is a good
means to have the user be "wrong" at many places ;-) (Personally,
I think you should leave that typo in -- kind of an inside joke).

>>   viewed as a service, similar to "Find me/Follow me".

The point being that traditional telephony does not view
forking as an intrinsic capability of the protocol, but
rather equates it to a well known service already available
on that network.  It's a pedantic point, probably not
worth loosing sleep over.

> principals. I assume you are not disputing that features live in 

Nope, far be it for me to dispute that.  Endpoints are quite
powerful and capable of hosting many interesting features.  But
the reality also is that some features -- large scale
conferencing, aggregating information, prioritized routing of
emergency calls -- do require some network support.

>> extensibility work seamlessly across existing implementations.

Thanks.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Mar 2005 11:43:41 -0600

> example of a clash in mind?

Prof. Schulzrinne:

The prototypical example that comes to mind is Privacy Manager
and Caller ID.  For the former to work, the latter is required
and should be applied first.  Admittedly, that example is
drawn from the telephony network, but the possibility of the
same interaction also occurs in SIP.  Consider for instance the
interaction between the Privacy service (rfc3323) and a
Privacy Manager service implemented in a CPL script.  In order
for the CPL script to work correctly, either the Privacy
Service has to be disabled, or other services such as
P-Asserted-Identity must take precedence.

> interaction problems that are caused by lack of indication of caller 

In the example above, it is the features (or services)
running on behalf of the called party that may need a
resolution.  Something like called party's precedence
rules.  It occurs to me that in SIMPLE we have visited
this same problem in the context of presence.  I may
know you have a bunch of services, but what I do not
know is how to get both of us to agree that we should use
a particular service to communicate, or even if I can
start communications with a lesser-grade service and
ramp up later.

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Tue, 08 Mar 2005 18:10:59 -0600

Vijay K. Gurbani wrote:
>> endpoints, and some into the network. This means that you can not 
>> easily coordinate a resolution between features that run in the two 
>> places. 
> 
Features could potentially live on the caller endpoint, the callee 
endpoint, and possibly multiple application servers the network. Thus, 
some kind of feature interaction would actually need to coordinate 
features between a number entities.

In that sense, feature interaction it is probably more a problem of 
enabling the negotiation of features between the entities in a call than 
defining a table that says "features X doesn't work with feature Y". 
Needless to say, that such a mechanism that covers all entities in a 
call seems to be a very complex thing...

>> features live in the endpoints, allows the endpoint to fully resolve 
>> the feature interactions in whatever way it chooses.
> 
Absolutely.

Btw. we have done some work on coordinating features between an endpoint 
and a network server and have submitted a paper about this to Globecom. 
Anyone who is interested, please contact me if you would like to get a 
copy of the paper.

Thanks,

Volker
-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Mar 2005 21:49:53 -0500

See also http://www1.cs.columbia.edu/~xiaotaow/main/research.htm and 
some of the references in the 2005 paper, as well as
http://www1.cs.columbia.edu/~lennox/featint.pdf (2000)