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

[Dale.Worley at comcast.net]

   From: <Markus.Isomaki at nokia.com>

   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.

Though in fact, in regard to QoS demands, IPTV and videoconferencing
often have different demands.  (I think the draft actually mentions
this later on.)

      Frequently, a network administrator will want to authorize whether a
      user is allowed to invoke a particular service.

Which can mean more than one thing.  If two services have exactly the
same network demands, then a *network* administrator has no reason to
differentiate authorizations for the two services.

The more interesting situation is when the service authorization is
used for reasons other than network impact.

Dale


_______________________________________________
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