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

["Henry Sinnreich" <[e-mail]>]

I suggest we forget this comment about using QoS since it diminishes the
great value of the draft. After all QoS is an evil tool targeted to foul
up the application in the end points from competitors. This is how I
read the IAB LC RFC (no number yet) Reflections on Internet Transparency
by B. Aboba and E. Davies.

http://www.ietf.org/internet-drafts/draft-iab-net-transparent-05.txt 

Henry


-----Original Message-----
From: Jonathan Rosenberg [mailto:[e-mail]] 
Sent: Wednesday, May 09, 2007 11:09 AM
To: [e-mail]
Cc: [e-mail]
Subject: 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.

[e-mail] 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:[e-mail]] 
>>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
>>[e-mail]                              FAX:   [phone]
>>http://www.jdrosen.net                         PHONE: [phone]
>>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 
>>[e-mail] for questions on current sip 
>>Use [e-mail] for new developments of core SIP
>>
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP