[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D on service identification now available
Hi Dean,
It's clear that SIP and other application protocols should be totally
opaque to access network providers. Their role is just to forward IP
packets. However, there is also the question on the role of the
"originating" SIP service provider, who can be independent of any access
networks. That SIP provider gives user his/her SIP identity (AoR),
authenticates the user and transfers traffic to and from other SIP
domains (possibly signing outbound requests with SIP identity or tagging
them with P-Asserted-Identity).
If the user of the SIP service provider establishes a session (or does
something else with SIP) to some other domain, are there any valid cases
where the "originating" provider should understand something about the
service and act accordingly? I have a couple of cases in mind that sound
at least remotely useful:
- This is something that some PTT/PoC systems actually have: When user
joins a PTT conference, this is not done directly, but the user wants to
join through a "front-end" mixing service, so that he can be included in
many conferences at the same time while having just a single session or
media stream open towards the network. The front-end mixer has some kind
(user configurable) policy on what to do when there is traffic in more
than one conference. Typically the conferences can have some kind of
priority order, so the user would always hear what is going on in the
highest-priority conference.
- The user might want to make a call or join a conference through a
local recording service.
It may be that even in these cases the model where the "originating" SIP
provider tries to determine what to do based on inspecting the SIP
message may not be the right one. It would be better if we had a
mechanism whereby the UAC/user could request something like "recorder"
or "front-end mixer" to be included in the session (presumably these are
implemented as B2BUAs). Jonathan once had a proposal to use Service URN
to address these type of services. Perhaps it would be enough to use
just SIP URIs also here. Is it possible to "chain" these in your session
using e.g. pre-loaded Route? All in all this seems a bit complicated in
practice...
Regards,
Markus
>-----Original Message-----
>From: ext Dean Willis [mailto:dean.willis at softarmor.com]
>Sent: 10 May, 2007 06:58
>To: sipping at ietf.org
>Subject: Re: [Sipping] I-D on service identification now available
>
>Dean Willis wrote:
>
>>
>> Further, it's why I think the SIP-level signaling should be
>opaque to
>> the access network provider. It's none of their business, and the
>> current protocol is flawed for having let them into the
>control channel.
>>
>
>I've caught some considerable flack from people for the above
>statement,
> but I'm afraid I must stand by it. I absolutely and totally
>believe it to be true. However, it may perhaps not be clear
>what I meant.
>
>A model that splits service delivery into "access" and
>"service" layers only works as long as the access network is
>comepletely transparent to the service being delivered.
>
>Once the access network provider starts to restrict service
>delivery functionality to services they can "make a premium"
>on (or otherwise have reason to "understand"), you just don't
>have the Internet any more.
>
>In short, what happens is that new services can only be
>delivered with the explicit consent of and by arrangement with
>the access network providers. This turns the introduction of a
>new service into an exponential problem, paralyzing the whole system.
>
>Take, for example, HTTP (as Juha mentioned). If every new web
>application had to get explicit buy-in from AOL, UUNET,
>Sunrise, Verizon, Vodafone, DT, BT, FT, and every other
>access-providing organization, there'd never be another
>web-based application launched. I believe it's totally
>unreasonable to propose this sort of model, and will do
>everything in my power to keep us from heading that way.
>
>Jonathan raised the same question in his response of earlier today:
>
> > 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?
>
>and he proposes an alternative model:
>
> > 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.
>
>Note that this approach works just fine in a topology where
>access and service are separated. It does require (as proposed
>above) a new interface (like "policy server peering") for the
>QoS agreement, but it does NOT require that the access network
>understand the specific service being delivered. I believe
>this property is an absolute necessity for an Internet standard.
>
>--
>Dean
>
>
>_______________________________________________
>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