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

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

This is a very good question, Markus.

Firstly, as you indicate, for these types of services, only the called domain can ascertain what the service is. Interestingly, it is in exactly these cases that the calling domain is not actually providing the service. This raises interesting questions, like, does it even make sense for an originating domain to *authorize* the access of a service that it is not even providing?

Clearly, though, some of the things we'd want to do based on knowledge of the service, do make sense in the calling domain. One clear one is QoS authorization. I think the right answer there is that the SIP signaling would be sent all the way to the terminating domain, which would then be able to make the service determination, and through something like policy server peering, communicate information back to the originating domain on the required QoS and whether it should be authorized or not. Such an approach has the benefit that it allows a terminating domain to offer whatever services it wants, without coordinating with the originating side, yet still allow service-based QOS authorization in the originating domain.

Thanks,
Jonathan R.

Markus.Isomaki at nokia.com wrote:

Hi Jonathan,

Thanks for putting this together. 

One of the points that you make in the draft is that the SIP signaling
itself contains enough information on the "service", without the need
for an additional explicit identifier. In the IPTV vs. multimedia
conferencing case you suggest that it is the target URI that makes the
difference:

   IPTV vs. Multimedia Conferencing:  The two services in Section 4.1
      appear to have identical signaling.  They both involve audio and
      video streams, both of which are unidirectional.  Both might
      utilize the same codecs.  However, there is another important
      difference in the signaling - the target URI.  In the case of
      IPTV, the request is targeted at a media server or to a particular
      piece of content to be viewed.  In the case of multimedia
      conferencing, the target is a conference server.  The
      administrator of the domain can therefore examine the two Request-
      URI, and figure out whether it is targeted for a conference server
      or a content server, and use that to derive the service associated
      with the request.

This is all true. However, what if the caller and the server are in
different domains, and caller's domain wants to enforce some policy
based on what the service is. For instance the one that is explained in
the draft itself:

   Frequently, a network administrator will want to authorize whether a
   user is allowed to invoke a particular service.  Not all users will
   be authorized to use all services that are provided.  For example, a
   user may not be authorized to access IPTV services, whereas they are
   authorized to utilize multimedia processing.  A user might not be
   able to utilize a multiplayer gaming service, whereas they are
   authorized to utilize voice chat services.

Request-URI is totally opaque to the caller and caller's domain. Neither
of them can know without some further information, whether INVITE is
destined to IPTV session or a video conference.

I agree with all the problems that explicit identifiers cause, but how
to deal with this case.

Regards,
Markus



-----Original Message-----
From: ext Jonathan Rosenberg [mailto:jdrosen at cisco.com] Sent: 07 May, 2007 19:42
To: IETF Sipping List
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-i
dentification-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




--
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