Subject: [Sip] [query] service level capabilities spefifications between different SIP entities

From: "Khare, Anir" <[email-masked]>
Date: Thu, 16 Mar 2006 07:27:00 -0600

3261 provides mechanisms to advertise capabilities between the
interacting SIP entities. E.g. SIP header fields like require etc. The
capabilities exchanged are essentially related to SIP level artifacts
e.g. a particular SIP method supported or a particular SIP extensions
specified in RFCs supported. However there are no mechanisms available
to specify capabilities related to distributed services which use SIP as
signaling mechanism to coordinate between different services entities.
Hence these SIP entities do not necessarily interoperate even if all of
them strictly comply to SIP standards for transporting service
interactions. Some standard call flows and best practices are specified
in RFCs, however there are no standard ways of specifying service level
capabilities of a SIP entity and the associated call flows that it can
support. 

SDP focuses on end point to end point negotiation of some service
attributes, however there is no semantics anticipated related to
capabilities negotiation with intermediaries. RFC 3959/3960 suggests
some mechanisms during "early media" phase of the session.

SIP is rendezvous protocol, this means existence of intermediaries is
central part of the architecture (in peer to peer SIP the definition of
intermediaries is slightly diluted). Intermediaries are essentially
envisaged for finding the end points and routing communication between
them. RFC3840 suggests that end points can externalize some information
(during registration time) in order to influence this routing.

In non- peer to peer models, SIP proxies provide more than the basic
rendezvous functions and it may be useful to have some unified mechanism
for service level negotiations between end points and intermediaries or
between intermediaries. 

If this is available then a given SIP end point will be able to
dynamically participate in different service environments, by
dynamically recognizing call flows/capabilities in a particular service
environment. 

Are there any existing mechanisms specified in any RFCs which can deal
with these issues. If not, will addition of those be inline with the
overall SIP architecture?

Standardization of call flows across all service environments could be
another alternative way to look at this; however it will lot difficult
to realize and may not be inline with the spirit of SIP as an open
signaling protocol.

Any clarifications, suggestions on this topic are appreciated.

Thanks,

Anir Khare

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Mar 2006 23:17:11 -0500

Comments inline.

	Paul

> capabilities of a SIP entity and the associated call flows that it can 

Not in 3261, which is why there are other RFCs and drafts that extend it.

> some mechanisms during “early media” phase of the session.

I don't see that those RFCs are especially relevant to the discussion. 
However RFC3312 is applicable to certain kinds of media service 
attributes. You can work on negotiating preconditions with multiple 
candidate target UEs and settle on the one that can (first) meet your needs.

> (during registration time) in order to influence this routing.

Yup. This is a mechanism that has yet to see much use. None of these 
mechanisms is perfect, including this one that is far from perfect. But 
this one, like the others, brings something to the table, that may be 
used when appropriate.

> for service level negotiations between end points and intermediaries or 

I think there is considerable disagreement over what kinds of services 
are appropriate to be provided by intermediate nodes.

As has been mentioned elsewhere, the work on end-to-middle policy 
exchange may be applicable.

> dynamically recognizing call flows/capabilities in a particular service 

I am still seeking enough concrete examples of these "service 
environments" to be able to infer the concept that is intended.

> overall SIP architecture?

Some mentioned above.

> to realize and may not be inline with the spirit of SIP as an open 

Sounds like a bad idea, and doesn't really solve the problem. You can 
write down call flows for different cases, but they may be impossible to 
realize. Each node on the path needs to make a decision about what to do 
based on information available. In general it doesn't know which call 
flow it should be following.

> ------------------------------------------------------------------------
>