[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D on service identification now available
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:jdrosen at cisco.com]
Sent: Wednesday, May 09, 2007 11:09 AM
To: Markus.Isomaki at nokia.com
Cc: sipping at ietf.org
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.
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
_______________________________________________
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