[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] I-D on service identification now available

Paul is correct. The 2xx response will contain information on what media streams are in use, who the connected party is, and so on. The originatin domain would then make a determination what 'service' this corresponds to. As Paul has indicated, this may be different than what would 'normally' be seen.

A natural conclusion of this is that service identification is really based on something more akin to a region mapping; a domain would classify a service as being something where certain parameters are present and/or within certain ranges, and the presence/absence of other things is not relevant. This would allow you to deal with varying capabilities. It ultimately requires you to figure out what is really the 'essence' of a particular service - what session functionality HAS to be there, for something to be considered that service.

-Jonathan R.

Paul Kyzivat wrote:



Bruce Qi wrote:

Hi Jonathan and All ,
The draft is really great! The draft describes many problem that we are discussing .
About "egotiation of Service",I think that something need to be clarified.

5.6.  Negotiation of Service

   In some cases, when the caller initiates a session, they don't
   actually know which service will be utilized.  Rather, they might
   like to offer up all of the services they have available to the
   called party, and then let the called party decide, or let the system
   make a decision based on overlapping service capabilities.

   As an example, s user can do both the game and the voice chat service
   of Section 4.2.  They initiate a session to a target AOR, but the
   devices used by that user can only support voice chat.  Consequently,
   voice chat gets utilized for the session.

1) When the called party or the system decide the sevice that this session will invoke, should the caller know the invoked sevice? Maybe the sip response message includes the infomation about the invoked service .


This is tricky. As noted in the draft, what ends up being negotiated may not exactly match either end's definition of a service. Rather, in the loose sense the service is "what you see" when the session is established, which is a subset of "what you said". Typically it is what the response says. This includes who/what was actually contacted, what media have been negotiated, what QoS has been negotiated, etc.

    Paul

2) There is the other case about "negotiation of service", For example , the initial request includes the two or more service identifiers. when the called party or the system receives the request, they may decide which one service will be invoked. I think the cases of " negotiation of service " should include this case.


Thinks Bruce Qi


----- Original Message ----- From: "Jonathan Rosenberg" <jdrosen at cisco.com>
To: "IETF Sipping List" <sipping at ietf.org>
Sent: Tuesday, May 08, 2007 12:42 AM
Subject: [Sipping] I-D on service identification now available


During the Prague IETF, we discussed producing a document that is an expository on the architectural principles behind service identification - what it means, why people want it, what the perils are. I've now finished this, and posted it. Until it appears, you can pick it up here:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-service-identification-02.txt


This is a complete rewrite of the previous document, following the outline I proposed in Prague.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP



--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP