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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 May 2007 12:42:01 -0400

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-identification-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
[email-masked]                              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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 May 2007 20:29:58 -0400

Jonathan,

This draft is GREAT!

Its the first discussion of the subject that really seems to get at the 
heart of the issue.

	Thanks,
	Paul

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 08 May 2007 07:32:55 -0500

I wanted to echo Paul here - this draft definitely moves us from discussing 
a specific proposal for a specific header to the architectural level, and we 
need to be thinking about the architectural level for this topic.

Thanks, Jonathan, for taking time out of your busy schedule to put this on 
paper.

Spencer

From: "Paul Kyzivat" <[email-masked]>

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 8 May 2007 14:43:25 -0700

I would also add my self to the list of enthusiastic readers of this
excellent document. 
Bravo Jonathan for adding such clarity to the notion of service
identifiers!

Thanks, Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Tuesday, May 08, 2007 7:33 AM
To: Paul Kyzivat; Jonathan Rosenberg
Cc: IETF Sipping List
Subject: Re: [Sipping] I-D on service identification now available

I wanted to echo Paul here - this draft definitely moves us from
discussing 
a specific proposal for a specific header to the architectural level,
and we 
need to be thinking about the architectural level for this topic.

Thanks, Jonathan, for taking time out of your busy schedule to put this
on 
paper.

Spencer

---

From: <[email-masked]>
Date: Wed, 9 May 2007 10:56:33 +0300

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 

>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>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:
>
>This is a complete rewrite of the previous document, following 
>the outline I proposed in Prague.
>
>Thanks,
>Jonathan R.
>-- 
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 9 May 2007 11:12:34 +0300

> destined to IPTV session or a video conference.

markus,

how does caller's domain figure out from http uri what the service is?
why this is a problem with sip and not http?  or if there is a solution
for http, why can't the same solution be applied to sip?

-- juha

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Wed, 9 May 2007 14:08:54 +0530

I really don't think comparing SIP and HTTP is appropriate. HTTP has
never been used for 'main stream session control' as SIP does. The
role that SIP plays in this aspect is therefore more significant both
in terms of architecture as well as revenue to the deploying network
and therefore, potential problems of HTTP, while allowable may not be
allowabe in SIP.

This is a very valid situation. One potential I see is that following
the same logic that signaling should provide sufficient information on
the service being executed, it is possible that the calling domain's
'policy server' may apply this decision not at the outgoing INVITE
stage, but likely on inspecting the return 1xx or 2xx from the called
domain. I would assume that it architecturally possible to ensure that
the return path signaling has information to further identify the end
domain service.

This would imply:
a) The termination would not be as 'graceful' as that of INVITE based
filtering (in this case not possible)
b) Likely the 'policy server' is really a B2B to be able to pull this off

But I hardly believe that b) is a problem for anything in an IMS
network, since anyway, almost everything there, in some unit of time,
pulls out its B2B horns.

regds
arjun

On 5/9/07, Juha Heinanen <[email-masked]> wrote:
> *****************************************************DISCLAIMER*****************************************************
>
> This message and/or attachment(s) contained here are confidential, proprietary to HUGHES SYSTIQUE and its customers.
> Contents may be privileged or otherwise protected by law. The information is solely intended for the entity it is
> addressed to. If you are not the intended recipient of this message, it is strictly prohibited to read, forward,
> print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error,
> please notify the sender immediately and delete the message.
>
> ********************************************************************************************************************
>
>

-- 
Arjun Roychowdhury

---

From: <[email-masked]>
Date: Wed, 9 May 2007 12:33:00 +0300

Juha,

That's because HTTP is Internet and SIP is telecom ;-)

More seriously speaking, in SIP there is a model where a request/session
can be routed through "application servers" doing some specific
functions, before reaching the targeted destination. One of the
discussions related to "service identification" has been how the proxies
can decide when to route the request to such a server. Jonathan's draft
says that Request-URI is a good tool for that, but it should be noted
that this does not work that well between different domains. If such use
cases are important (there are many people who are not convinced),
something else needs to be used.

Markus 

>From: ext Juha Heinanen [mailto:[email-masked]] 
>Sent: 09 May, 2007 11:13
>To: Isomaki Markus (Nokia-SIR/Espoo)
>Cc: [email-masked]; [email-masked]
>Subject: RE: [Sipping] I-D on service identification now available
>
> > 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.
>
>markus,
>
>why this is a problem with sip and not http?  or if there is a 
>solution for http, why can't the same solution be applied to sip?
>
>-- juha
>

---

From: Bruce Qi <[email-masked]>
Date: Wed, 09 May 2007 20:11:19 +0800

Hi Jonathan and All ,
      The draft is really great!   The draft describes many problem that we are discussing .
 
About "egotiation of Service",I  think that something need to be clarified.

5.6.  Negotiation of Service

   In some cases, when the caller initiates a session, they don't
   actually know which service will be utilized.  Rather, they might
   like to offer up all of the services they have available to the
   called party, and then let the called party decide, or let the system
   make a decision based on overlapping service capabilities.

   As an example, s user can do both the game and the voice chat service
   of Section 4.2.  They initiate a session to a target AOR, but the
   devices used by that user can only support voice chat.  Consequently,
   voice chat gets utilized for the session.

1)  When the called party or the system decide the sevice that this session will invoke,  should the caller know the invoked sevice? Maybe the sip response message includes the infomation about the invoked service .
2)  There is the other case about "negotiation of service", For example , the initial request includes the  two or more service identifiers. when the called party or the system receives the request, they may decide which one service will be invoked.  I think the cases of " negotiation of service " should include this case.

Thinks 
Bruce Qi

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 May 2007 10:58:00 -0400

> 1)  When the called party or the system decide the sevice that this session will invoke,  should the caller know the invoked sevice? Maybe the sip response message includes the infomation about the…

This is tricky. As noted in the draft, what ends up being negotiated may 
not exactly match either end's definition of a service. Rather, in the 
loose sense the service is "what you see" when the session is 
established, which is a subset of "what you said". Typically it is what 
the response says. This includes who/what was actually contacted, what 
media have been negotiated, what QoS has been negotiated, etc.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 May 2007 12:08:35 -0400

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 May 2007 12:11:48 -0400

Paul is correct. The 2xx response will contain information on what media 
streams are in use, who the connected party is, and so on. The 
originatin domain would then make a determination what 'service' this 
corresponds to. As Paul has indicated, this may be different than what 
would 'normally' be seen.

A natural conclusion of this is that service identification is really 
based on something more akin to a region mapping; a domain would 
classify a service as being something where certain parameters are 
present and/or within certain ranges, and the presence/absence of other 
things is not relevant. This would allow you to deal with varying 
capabilities. It ultimately requires you to figure out what is really 
the 'essence' of a particular service - what session functionality HAS 
to be there, for something to be considered that service.

-Jonathan R.

Paul Kyzivat wrote:

>> 1)  When the called party or the system decide the sevice that this 
>> session will invoke,  should the caller know the invoked sevice? Maybe 
>> the sip response message includes the infomation about the invoked 
>> service .
> 
> 
>> 2)  There is the other case about "negotiation of service", For 
>> example , the initial request includes the  two or more service 
>> identifiers. when the called party or the system receives the request, 
>> they may decide which one service will be invoked.  I think the cases 
>> of " negotiation of service " should include this case.
>>
>>
>> Thinks Bruce Qi
>>
>>
>> ----- Original Message ----- From: "Jonathan Rosenberg" 
>> <[email-masked]>
>>> 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:
>>>

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 May 2007 11:11:49 -0500

On May 9, 2007, at 3:12 AM, Juha Heinanen wrote:

> solution

The phone company operators running the access networks want to have  
more control over your life with SIP than they currently have with HTTP.

For example, if you're using "Service=PORN", they want to be able to  
charge you extra, even though they're not really doing anything  
extra. Or perhaps they want to deny your usage of the service,  
because you haven't certified you're old enough. Note that with HTT,  
the service provider (not the access network provider) gets to make  
these choices. The access providers want to get in so they can get a  
bigger share of the "value".

The problem now is that every access-side operator would have to  
understand every possible service-side offering. The only way to do  
that is to reduce the set of potential services to a least-common  
denominator that is contractually agreed between the service  
providers. This is the death of service innovation in the Internet,  
and something I believe we must say "NO" to.

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.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 9 May 2007 22:15:20 +0300

Dean Willis writes:

 > because you haven't certified you're old enough. 

that sounds very scary.  i hope this working group does nothing to
support that kind of censorship and cow milking.

 > and something I believe we must say "NO" to.

yes.  i wonder how long does it take for the mobile operators to realize
that standardizing every service and then having roaming agreements for
everyone for each service separately (nxn) simple does not scale and
limits innovation.

 > current protocol is flawed for having let them into the control

yes, it is high time to move this discussion out from ietf mailing
lists. 

-- juha

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 9 May 2007 18:02:09 -0500

>
>The problem now is that every access-side operator would have 
>to understand every possible service-side offering. The only 
>way to do that is to reduce the set of potential services to a 
>least-common denominator that is contractually agreed between 
>the service providers. This is the death of service innovation 
>in the Internet, and something I believe we must say "NO" to.
>
>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 am 100% in the agreement with you on this. IMHO, We need SIP 3.0 . 
SIP Providers need to change the business models which were adopted 
from PSTN.

Thx
Samir

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 9 May 2007 17:33:38 -0700

>The problem now is that every access-side operator would have to
understand >every possible service-side offering. The only way to do
that is to reduce >the set of potential services to a least-common
denominator that is >contractually agreed between the service providers.
This is the death of >service innovation in the Internet, and something
I believe we must say >"NO" to.

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

Amen! We should have IETF T-shirts with this or similar text. 
Maybe provided courtesy of an enlightened access provider?

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, May 09, 2007 11:12 AM
To: Juha Heinanen
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 9 May 2007 17:41:54 -0700

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:[email-masked]] 
Sent: Wednesday, May 09, 2007 11:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

Thanks,
Jonathan R.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 10 May 2007 04:25:01 +0200

Hi,

I have some questions/issues on the draft.

Q1.
---

Chapter 4 gives a few examples where it is claimed that signalling
information can be used to determine the service. I haven't had time to
look at the examples in detail yet, but let's assume they are ok.

However, later chapter 6.2 says:

"Given that the information in the signaling message always conveys
enough information to identify the service,..."

Can we make such a statement purely based on a few examples in chapter
4??? Or, have I missunderstood something?

I would also like to include at least a couple of more examples:

- "Game 1 vs Game 2"

- "Telephony vs VoIP"   

(Telephony refers to the case where e.g. supplementary services
functions are applied, in the UA and/or an AS)

For the part which talks about using SDP information to determine the
service, I would also like the draft to talk about the following cases:

- There is no SDP in the INVITE

- Additional streams and SDP information may be added after the initial
INVITE has been sent

Q2.
---

Chapter 5.7 is a little unclear. I think you should get more details on
how the "dispatcher" knows which terminals supports gaming (based on
registration information etc) and once the INVITE reaches the terminal,
how it is routed to the appropriate application.

Q3.
---

How does the draft relate to draft-rosenberg-sip-app-media-tag-00 and
draft-DRAGE-sipping-service-identification-00, which were made available
a while ago?

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 09 May 2007 22:58:01 -0500

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

 > 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

---

From: Dean Willis <[email-masked]>
Date: Wed, 09 May 2007 23:14:47 -0500

> enough information to identify the service,..."

This is, as I understand it, a cyclical definition of terminology.

The statement in question appears to be completely consistent if one 
believes that the "service" being referred to is specifiable in the 
signaling.

For example, two requests to a given URI with idential URI parameters 
and identical SDP bodies are, by this definition, requests for the same 
service.

If, however, you have a conceptual model wherein those requests might be 
to different services, despite the fact that the network is going to 
experience exactly the same loading factors, then it doesn't apply -- 
you have a different definition of "service".

Take for example two requests to a video robot, where the robot randomly 
chooses whether to display a comedic video or a product advertisement, 
and debits the user for the comedic video or credits them for watching 
the advertisement as appropriate. Both video clips are rendered in 
exactly the same codec, persist for the same duration, require the same 
bandwidth, and transmit the same number of bytes at the same priority.

If you believe that these are somehow different "services" and should be 
treated differently by the intermediate nodes, then you disagree with 
Jonathan's definition of service. If you think they're the same service, 
then you probably agree with Jonathan;s definition.

Some of the proponents of service identifiers have argued that these 
SHOULD be differentiated servcies, and that the robot in the above 
example should somehow signal "the network" appropriately so that the 
access network provider can also differentiate billing to the user.

I find this to be a very awkward idea of "service" and believe it leads 
to insurmountable problems related to the complexity of peering 
agreements (and service definitions) in the resulting environment.

--
Dean

---

From: <[email-masked]>
Date: Thu, 10 May 2007 13:12:55 +0300

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  

>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 10 May, 2007 06:58
>To: [email-masked]
>opaque to 
>  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.
>
>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.
>
> > 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  > 
> > 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
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 May 2007 07:56:32 -0400

inline.

[email-masked] wrote:

> service and act accordingly? 

Sure. My point wasn't to say that they can't; only that, for services 
that are basically identified based on the r-uri, they cannot. However, 
those are services they, by definition, aren't providing, so it 
shouldn't ever be a problem.

I have a couple of cases in mind that sound
> highest-priority conference.

So, are you saying this conference is in the originating domain or 
terminating domain? If in the terminating domain, clearly the 
originating domain can know its PoC, based on other information in the 
request.

> - The user might want to make a call or join a conference through a

Right - I elected not to treat this question (how a user can explicitly 
ask for services to be added) in this draft, since I really think its 
quite separable.

> implemented as B2BUAs).

In cases where a user wants to explicitly add a service, yes, that makes 
sense.

  Jonathan once had a proposal to use Service URN
> using e.g. pre-loaded Route? All in all this seems a bit complicated in

I still think that approach makes sense, including the usage of service 
URN and chaining of services by pre-loaded Route. However, as I said 
above, I think its pretty orthogonal to the concepts in the service draft.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Thu, 10 May 2007 11:09:56 -0500

> using e.g. pre-loaded Route? All in all this seems a bit complicated in

I think you're headed in the right direction here.

Rather than having the service invocation be an implicit side-effect of 
analyzing the signaling, I'd much rather have the invocation be explicit.

Pre-loaded routes give us a reasonable way to do proxy services.

In cases where the services are implemented as B2BUAs, we don't need that
sort of complexity.

If Alice is calling Bob and wants to invoke a recorder for the call, Alice
could send her initial request to the recorder-B2BUA, along with whatever
parameters are needed (file format, location, billing account, etc.) and
a URI to be used for Bob.

This takes all of the silly guessing games and requirements for "service
identifiers agreed to by all providers" right out of the equation.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 May 2007 13:20:29 -0400

> identifiers agreed to by all providers" right out of the equation.

This could be very much like a conference server. Establish a session 
with it, and then send it a REFER to get it to call somebody else and 
bridge you, while recording. Its really just a conference server that 
records the conference, where the conference only has two participants.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 11 May 2007 08:14:51 +0200

Hi,

>Rather than having the service invocation be an implicit 
>side-effect of analyzing the signaling, I'd much rather have 
>the invocation be explicit.

Both Jonathan's and Keith's draft are based on signaling analyzing
(including service id type of information), aren't they?
 
>Pre-loaded routes give us a reasonable way to do proxy services.

One needs to remember that routing towards the correct intermediates is
only one step. You also need to to be able to route the request towards
terminals which support the service.

>In cases where the services are implemented as B2BUAs, we 
>don't need that sort of complexity.
> 
>If Alice is calling Bob and wants to invoke a recorder for 
>the call, Alice could send her initial request to the 
>recorder-B2BUA, along with whatever parameters are needed 
>(file format, location, billing account, etc.) and a URI to 
>be used for Bob.

Based on the assumption that Bob knows that he has to invoke a recorder
in the first place (maybe he knows that in this specific example), that
Bob knows has the URI of the recorder (and possible all other
intermediates that need to be inserted), and that Bob knows where and in
which order to put the URI(s) in the pre-Route (there can also be other
pre-Route headers in the request).

I also think it's important to remember that RFC3261 allows a proxy to
forward requests pretty much based on ANY information (DNS lookups,
databases, signalling information etc etc), so I think it would unfair
to say that such behavior would "break" SIP as a protocol (no, I didn't
say that someone has said it as part of this thread).

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 May 2007 07:43:56 -0500

On Fri, 11 May 2007 08:14:51 +0200

> terminals which support the service.

From a Service Oriented Architecture point of view -- No, you don't.
What we need to do is to be able to route the request towards the
terminals which have the capabilities required by the service. 

That's a VERY different problem.

Otherwise you get into this exponential race condition of all the nodes
having to agree to all the "service names" and there's very little hope
of anything actually being introducable ever again.

> pre-Route headers in the request).

Or (and that's why I used INVITE instead of REFER) Bob's proxy (based on 
perhaps web-controlled policy) could retarget Bob's INVITE through the 
recorder. This way Bob's UA doesn't even have to know about the service.
 
> say that someone has said it as part of this thread).

right.

--
dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 May 2007 13:06:04 -0400

What the previous version of the draft proposed, and what I still think 
makes sense, but should be documented elsewhere, is to do something like 
this. The phone, wanting a recording service, would emit a request that 
looks like:

INVITE sip:[email-masked]
From: sip:[email-masked]
Route: urn:service:call-recorder

when this arrives at the outbound proxy in the originating domain, that 
proxy would basically translate this URN to a URI for a recording 
service that it knows about:

INVITE sip:[email-masked]
From: sip:[email-masked]
Route: 
sip:record-service.store=y.format=[email-masked]

and then it happily goes there.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 May 2007 12:17:13 -0500

Hum, interesting. I like the concept, but...

A few questions:

1) Wouldn't this cause some backward compatibility problems? Won't some
proxies choke on
   URNs in a Route header? Or are you making the assumption that you
have to ensure that the
   Route entry is the first one in the list (i.e., the outbound proxy)?
I'm assuming that's
   the assumption.

2) Couldn't we just load
sip:record-service.store=y.format=[email-masked]
   directly in the client??? When the client is provisioned, it would
equate
   "Call-Recorder-Service" to
"sip:record-service.store=y.format=[email-masked]
   domain.com"? I'm not sure I see a huge advantage in having the
Outbound proxy do
   the substitution versus the client doing it. Especially if automatic
provisioning 
   is used (Config-framework for example).

3) Why do you want to document it "elsewhere"?

> Sent: Friday, May 11, 2007 10:06
> To: Dean Willis
> Cc: [email-masked]; [email-masked]; Christer 
> Holmberg (JO/LMF)
> What the previous version of the draft proposed, and what I 
> still think makes sense, but should be documented elsewhere, 
> is to do something like this. The phone, wanting a recording 
> service, would emit a request that looks like:
> 
> when this arrives at the outbound proxy in the originating 
> domain, that proxy would basically translate this URN to a 
> URI for a recording service that it knows about:
> 
> >>One needs to remember that routing towards the correct 
> intermediates 
> >>is only one step. You also need to to be able to route the request 
> >>towards terminals which support the service.
> > 
> > 
> > Otherwise you get into this exponential race condition of all the 
> > nodes having to agree to all the "service names" and there's very 
> > little hope of anything actually being introducable ever again.
> > 
> > 
> >  
> > 
> the call, 
> >>>Alice could send her initial request to the recorder-B2BUA, along 
> >>>with whatever parameters are needed (file format, 
> location, billing 
> >>>account, etc.) and a URI to be used for Bob.
> >>
> >>Based on the assumption that Bob knows that he has to invoke a 
> >>recorder in the first place (maybe he knows that in this specific 
> >>example), that Bob knows has the URI of the recorder (and 
> possible all 
> >>other intermediates that need to be inserted), and that Bob knows 
> >>where and in which order to put the URI(s) in the pre-Route 
> (there can 
> >>also be other pre-Route headers in the request).
> > 
> > 
> > Or (and that's why I used INVITE instead of REFER) Bob's 
> proxy (based 
> > on perhaps web-controlled policy) could retarget Bob's 
> INVITE through 
> > the recorder. This way Bob's UA doesn't even have to know 
> about the service.
> >  
> > 
> >>to say that such behavior would "break" SIP as a protocol (no, I 
> >>didn't say that someone has said it as part of this thread).
> > 
> > 
> > right.
> > 
> > --
> > dean
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 11 May 2007 13:28:35 -0500

I may not be completely in sync on the subject. Pl correct me, if I am
wrong.

If service is provided by the far end APP SERVER (UAS), then It should
be none of the business of originating domain proxy and/or intermediate
proxies (Access Providers) to do translation or looking into services
types etc. That's where REQUIRE kind of logic works more appropriately.

Can somebody clarify the chain of preloaded routes which Markus was
mentioning? 

Thx
Samir

> Sent: Friday, May 11, 2007 10:06 AM
> To: Dean Willis
> Cc: [email-masked]; [email-masked]; Christer Holmberg
(JO/LMF)
> > Otherwise you get into this exponential race condition of all the
nodes
> >>Based on the assumption that Bob knows that he has to invoke a
recorder
> >>to say that such behavior would "break" SIP as a protocol (no, I
didn't

---

From: [email-masked]
Date: Fri, 11 May 2007 17:09:36 -0400

From: Jonathan Rosenberg <[email-masked]>

Functionally, it seems like there are two cases:

In one case, the UAC and its outbound proxy are tightly coordinated
(e.g., by a service provider that provides and maintains both).  In
that case, the means by which the UAC requests this forwarding service
from the outbound proxy does not need to be standardized.

In the other case, the UAC and its outbound proxy are not necessarily
coordinated.  In that case, the routing URN
"urn:service:call-recorder" needs to be standardized in regard to what
(functionally) it is requesting.  And that seems to send us back into
the "service identifier" problem that
draft-rosenberg-sipping-service-identification is warning us away
from.

It seems to me that Francois' approach is more likely to work, where
the UAC is provisioned in some way with the URI of the service, and
requests it of the outbound proxy.

>From a business point of view, Francois' approach seems better, too --
In the default case, a roaming phone has no special arrangements with
the access network, and so has to tell the access network *how* to get
the call back to the service network which operates the AS for the
service the UAC wishes to invoke.  In the more sophisticated case,
where a roaming phone has an implicit service agreement with the
access network (because the access network has a deal with the service
network), the roaming phone can presumably query the access network
for the URI of the access network's AS.

Dale

---

From: [email-masked]
Date: Fri, 11 May 2007 17:36:41 -0400

From: "Henry Sinnreich" <[email-masked]>

   ... After all QoS is an evil tool ...

IMHO, QoS is a much more complex area than it first seems.  As the
IAB's I-D points out, QoS can be used to reduce Internet transparency
for undesirable means.  But on the other hand, the proper use of QoS
is very useful in situations where the demand for bandwidth exceeds
the supply, and if skillfully applied, can be used to place the costs
of infrastructure deployment on the users that require the additional
infrastructure.

Consider the case of someone who set up an open Wi-Fi network and
within a few days discovered that someone had attached a Bit Torrent
server to it.  As Internet applications become more sophisticated,
it's always possible to build applications that can consume more
bandwidth than is available.

If QoS is properly applied and priced, it becomes like
congestion-pricing of roads -- most of the costs are borne by the
users whose demands require adding infrastructure, while users willing
to avoid making those demands use the service for much, much lower
prices.  (Which will reduce the need for explicit subsidies for
poverty-stricken users.)

How do you get the good and avoid the bad?  As far as I can see, if a
service provider has a free hand and a monopoly, they can impose all
of the evils of QoS, even if there is no QoS architecture in the
protocols.  But if there is adequate competition, or regulation that
produces the results that adequate competition would provide, QoS
limitations and pricing would be driven by the impact of usage on
infrastructure costs.

Dale

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 May 2007 16:37:02 -0500

>    is used (Config-framework for example).

As for WHY you might do service invocation in a proxy -- perhaps  
you'd like calls that originate from your old phone (which has no  
knowledge of a recording service) to be recorded, but only when you  
call your lawyer.  Proxies can certainly do this. I'd maintain that  
this is one of the few reasons to actually use a proxy. If all the  
smarts were in the endpoints, we could eliminate proxies and use only  
location servers and TURN servers.

--
Dean

---

From: [email-masked]
Date: Fri, 11 May 2007 17:38:17 -0400

From: [email-masked] (Juha Heinanen)

Ironically, the answer to this has been deployed...  Consider the HTTP
proxies many companies have to prevent employees from accessing
pornography via the company networks.  As far as I know, the proxies
just use a gigantic blacklist.

Dale

---

From: [email-masked]
Date: Fri, 11 May 2007 17:41:46 -0400

From: <[email-masked]>

   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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 11 May 2007 16:51:51 -0500

I don't think we are talking the same thing.

If the proxy want to invoke it, it can easily put the full
blown SIP URI in a Route header.

What I'm really questioning is the usefulness of having a URN
as an alias for a SIP URI being signalling on the wire between
the UA and the proxy, just to be replaced by a SIP URI by that
proxy.

I'm just saying that that phone should be able to do that on it's 
own by having the URI being downloaded in the phone at provision
time.

> Sent: Friday, May 11, 2007 14:37
> To: Audet, Francois (SC100:3055)
> Cc: Jonathan Rosenberg; [email-masked]; 
> [email-masked]; Christer Holmberg (JO/LMF)
> >    the substitution versus the client doing it. Especially if 
> > automatic provisioning
> As for WHY you might do service invocation in a proxy -- 
> perhaps you'd like calls that originate from your old phone 
> (which has no knowledge of a recording service) to be 
> recorded, but only when you call your lawyer.  Proxies can 
> certainly do this. I'd maintain that this is one of the few 
> reasons to actually use a proxy. If all the smarts were in 
> the endpoints, we could eliminate proxies and use only

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 11 May 2007 15:05:01 -0700

> someone who set up an open Wi-Fi network and
> server to it.

I though Bittorent is P2P...

> congestion-pricing of roads

There is no such thing. Once you pay toll on the toll road (Internet
access) all cars have the same rights.

This is what Internet Neutrality and now the new Wireless Neutrality is
all about. But that's another discussion.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 11, 2007 4:37 PM
To: [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

Dale

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 11 May 2007 17:10:21 -0500

It is the right direction of thinking. Why URI need to downloaded from
the ACCESS Provider's proxy. It should be wholly localized within the
UA. 

My analogy is when I hookup the PC with my ISP, does he care about
FTP,HTTP etc which my PC is pumping in? Access Provider just need to
look for the identity, security etc. No business with service logic.

Thx
Samir

> From: Audet, Francois (SC100:3055)
> Sent: Friday, May 11, 2007 2:52 PM
> To: Dean Willis
> Cc: Christer Holmberg (JO/LMF); [email-masked];
[email-masked]

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 11 May 2007 19:11:40 -0400

Henry

All Cars - yes.

But trucks pay per axle usually.

- And if you buy an I-pass then you get a 50% discount.

Andrew

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Friday, May 11, 2007 6:05 PM
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D on service identification now available

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 11, 2007 4:37 PM
To: [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

Dale

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 11 May 2007 19:00:34 -0500

Does it care about at what speed I am running (Security vouch by the
Police in case of overspeeding) and what I am carrying within my vehicle
?

Thx
Samir

> From: Andrew Allen [mailto:[email-masked]]
> Sent: Friday, May 11, 2007 4:12 PM
> To: Henry Sinnreich; [email-masked]; [email-masked]
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
non-public
> information. Any use of this information by anyone other than the
intended
> recipient is prohibited. If you have received this transmission in
error,
> please immediately reply to the sender and delete this information
from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 May 2007 20:08:29 -0400

Certainly it should be fine for the phone to be configured with the 
server to use.

Using a URN is a tradeoff between need for configuration and need for 
standardization. By using a standard URN you can avoid the need for 
configuration, while delegating the job of allocating a particular 
resource to a proxy.

This is not much different from the use of a service:sos URN for 
emergency calling. In that case we are using standardization to allow 
delegation of the selection of the PSAP to a proxy.

It does have some of the same issues as service identification. But at 
least it is not e2e. It is a contract between you and your provider.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 May 2007 20:26:45 -0400

I agree with Dale that this *can* be used in a way that equitably 
assigns cost for resources consumed. I just don't see how to ensure it 
isn't abused.

The obvious case that has come up recently is whether the SPs that 
provide *access* should be charging the big web server companies, such 
as Google, for better QoS to the access customer.

And I think the answer to that is "it depends".

If a SP customer has already paid for access, with some bandwidth 
guarantees, then Google should not have to pay the SP again in order for 
the customer to use that bandwidth to send or receive content from Google.

But, if the customer would like to receive content using bandwidth over 
and above what he has contracted for, then its not unreasonable to set 
up a way to arrange for somebody to pay for that. There are a number of 
possibilities that all seem plausible:
- the customer could upgrade his level of service, paying more per
   month to get a higher bandwidth guarantee.

- the SP could bill the customer one-time charges for use of extra
   bandwidth over and above is guarantee.

- the SP could bill Google  a one-time charge for providing
   extra access bandwidth to the customer.

- the SP could establish a service contract with Google which gives
   Google the right to use bandwidth in excess of customer's contracted
   bandwidth.

What I don't consider reasonable is if the SP wants to charge Google to 
send data to the customer *within* the bandwidth guarantees covered by 
the customer's contract with the SP. I fear that is what is desired. It 
seems that the SPs want to establish contracts with customers that 
appear to provide QoS guarantees, but in fact do not. Then they want to 
charge on top of that to actually provide QoS.

If there was a way for Google to pay the SP for service from a SP in 
excess of what the customer has contracted for, presumably Google could 
bill the customer back for that. This would be very similar to the way 
Amazon bills customers various categories of shipping.

	Paul

---

From: [email-masked]
Date: Fri, 11 May 2007 21:59:50 -0400

> congestion-pricing of roads

   There is no such thing. Once you pay toll on the toll road
   (Internet access) all cars have the same rights.

There are a very few places where roads have congestion pricing,
usually with much higher tolls during rush hours than non-rush hours.
Which is economically rational -- the person who wishes to drive at
3am is creating no demand to build new roads.

(And as Andrew and Samir note, trucks are charged a different rate.
But that is more complex, because the wear-and-tear a truck places on
a road varies depending on its weight.)

What holds up these sorts of schemes is the "transaction costs" of
charging appropriately are high relative to the amount of money
involved.

But for more expensive resources, congestion pricing is more common.
For example, if you desire to fly, you will have to pay less if it is
not at a time when the airport facilities are saturated.

   This is what Internet Neutrality and now the new Wireless
   Neutrality is all about. But that's another discussion.

Equality is not always advantageous if different users prefer
different cost/capacity tradeoffs.

But as Paul says, the difficult question is not the theory but how to
implement this (or any other scheme) in practice, and prevent it from
degenerating into mere rent-seeking.

Dale

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 May 2007 17:09:29 -0500

On Fri, 11 May 2007 16:51:51 -0500
 
> the UA and the proxy, just to be replaced by a SIP URI by that

Ah. That's a fair question.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 May 2007 17:14:03 -0500

On Fri, 11 May 2007 20:08:29 -0400

> least it is not e2e. It is a contract between you and your provider.

yes, but which provider? Even in a "simple" user->originating provider->terminating provider->user model, there's a question of which "provider" executes on the URN, and what happens if the two providers have conflicting efinition of the URN.

When there is a many-layer model, with possibly remote service invocations, it gets complicated.

The URI model doesn't have this, since it explicitly indicates WHO the service should be provided by.

My guess is that the URN model only works for a few services of global significance, like emergency calling.

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 13 May 2007 07:28:48 -0700

Thanks Paul, well said!

What worries me as a paying customer for both Vonage and Skype (chat,
international + video to see grandson) is my cable or DSL provider
should not give them _de-prioritized_ packet handling over their own
VoIP.

So far both Comcast and now Time Warner have provided us excellent
broadband service, but reading some statements coming out from Telco's
make one apprehensive.

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, May 11, 2007 7:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

the customer to use that bandwidth to send or receive content from
Google.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 14 May 2007 07:42:44 +0200

Hi, 

>The statement in question appears to be completely consistent 
>if one believes that the "service" being referred to is 
>specifiable in the signaling.
> 
>For example, two requests to a given Ul URI 
>parameters and identical SDP bodies are, by this definition, 
>requests for the same service.
> 
>If, however, you have a conceptual model wherein those 
>requests might be to different services, despite the fact 
>that the network is going to experience exactly the same 
>loading factors, then it doesn't apply -- you have a 
>different definition of "service".

I guess so.

My understaning of "service" is something which is provided to a user.
Based on the service definition you choose thee tools (protocols and
protocol elements) to implement that service.

Your definition is the complete opposite. You (and many other protocol
people) define the service based on the protocol, which also makes the
service protocol specific.
 
>Take for example two requests to a video robot, where the 
>robot randomly chooses whether to display a comedic video or 
>a product advertisement, and debits the user for the comedic 
>video or credits them for watching the advertisement as 
>appropriate. Both video clips are rendered in exactly the 
>same codec, persist for the same duration, require the same 
>If you believe that these are somehow different "services" 
>and should be treated differently by the intermediate nodes, 
>then you disagree with Jonathan's definition of service. If 
>you think they're the same service, then you probably agree 
>with Jonathan;s definition.

I do think they are different services, because they have different
definitions.

Yes, in this case, from a SIP perspective, you may be able to implement
the service in a similar way, but in my view that doesn't mean that they
are the same services.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 May 2007 10:33:38 -0500

I'm not sure I agree with this.

I really doubt that you'd want to hardcode the URN in the device.

So it really boils down to congiguring one of the following
in the route set for the device:
- urn:service:call-recorder
-
sip:record-service.store=y.format=[email-masked]

>From an end-user perspective, those are equally obscure.

And the second one has the advantage that it looks and smells just
like any other SIP URI.

In both cases, the idea is to associate a URI to a service in the phone.

> Sent: Friday, May 11, 2007 17:08
> Cc: Dean Willis; Christer Holmberg (JO/LMF); 
> [email-masked]; [email-masked]
> Certainly it should be fine for the phone to be configured 
> with the server to use.
> 
> Using a URN is a tradeoff between need for configuration and 
> need for standardization. By using a standard URN you can 
> avoid the need for configuration, while delegating the job of 
> allocating a particular resource to a proxy.
> 
> This is not much different from the use of a service:sos URN 
> for emergency calling. In that case we are using 
> standardization to allow delegation of the selection of the 
> PSAP to a proxy.
> 
> It does have some of the same issues as service 
> identification. But at least it is not e2e. It is a contract 
> between you and your provider.
> 
> 	Paul
> 
> Francois Audet wrote:
> > What I'm really questioning is the usefulness of having a URN as an 
> > alias for a SIP URI being signalling on the wire between the UA and 
> > the proxy, just to be replaced by a SIP URI by that proxy.
> > 
> > I'm just saying that that phone should be able to do that 
> on it's own 
> > by having the URI being downloaded in the phone at provision time.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 May 2007 11:58:10 -0400

> protocol elements) to implement that service.

I have no problem with you having a definition like this of service that 
applies between you and your UA, and perhaps between the user's UA and 
some network elements under its control.

But it gets dicier if you are talking about something provided to some 
other user - presumably the one you are calling, or the one that called you.

> service protocol specific.

Thats because we are concerned with the protocol, and not with 
standardizing the UI. The question is whether we want to incorporate 
protocol elements to standardize the UI e2e, or whether it is better to 
expect that the UI need not be standardized e2e.

> I do think they are different services, because they have different

You think these are different services even though the caller can't 
determine which one it will get until after the session is established, 
and even though which one is chosen is random?

I'd be more inclined to think of this as one service that has two 
modalities.

	Paul

---

From: [email-masked]
Date: Mon, 14 May 2007 11:58:30 -0400

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>

Sentences in the passive voice are dangerous, because they have a verb
that describes an action without specifying the actor.  In this case,
you say "service is provided" without making clear *who* you think is
providing it.

Who is "you"?  The user or some hypothetical "service provider"?

Why would anyone care to consider them being different?  More
particularly, why would anyone care to charge for them differently,
since their implementation consumes resources in exactly the same way?

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 May 2007 12:55:47 -0500

> since their implementation consumes resources in exactly the same way?

Here we have the defining difference of perspective.

 From the point of view of the network, these two services are  
exactly the same.

 From the point of view of the content provider and billing system,  
they're completely different. Why do some DVDs sell for $1 and others  
for $100? Because the content on them is different.

The totality of components defining a business system has to  
recognize these differences and be able to accommodate them.

However, that is NOT our problem to solve.

Our task in the IETF is to define the protocol at the network level.  
The network level has and requires no knowledge of this  
differentiation. It makes the address or name of the "content"  
available to the business layer, reports on the actual network  
resources used (bandwidth, packets. time, addresses, etc.) and that's  
it. How somebody builds a business out of that is out of our scope.

Take for example the delivery of content on HTTP. Whether you use  
eBay to buy a new Ferrari or buy a toy replica of the same car  
doesn't make a bit of difference to the HTTP protocol, and not a lot  
of difference to the infrastructure of eBay. The price and selection  
of the product is critically important to the buyer and the seller,  
but not to correct operation of the web servers, the browsers, load  
balancers, SSL concentrators, routers, and stuff like that. Keeping  
track of whether it was a real Ferrari or a toy Ferrari is NOT a  
protocol problem. It's a problem of the application implementation.

All we can reasonably do at the SIP level is solve the problems that  
are within the scope of a transport protocol. Jonathan's draft is an  
excellent start at defining what parts of this aggregate problem are  
within the scope of that protocol. The parts of the aggregate problem  
that don't fit within that scope are, I believe, not something that  
the IETF can reasonably address. If we attempt to define the business  
surround at a protocol level we are doomed to fail, and none of the  
failure modes are pretty. Therefore, we MUST NOT make that attempt.

How can we steer clear of this quandary? By developing a clear  
understanding of the problem scope, and rigorously staying within  
that scope.

We probably can't deliver on Christer's definition of "service". We  
can't even seem to agree on what it means. But I think we do have an  
understanding of "service" at the network level (stemming from  
Jonathan's draft) that is adequate for somebody else to build a  
business layer on top of. Perhaps we can help educate them on how to  
do that building, but we can't design their business for them.

I propose we take the scope of network-level "service" as Jonathan  
(more or less) has it and run with it. Once this layer is in-place, I  
believe the business designers will be able to use it to get their  
jobs done.

--
Dean

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 14 May 2007 14:23:34 -0500

Hi, Dean,

This is very helpful, and very well said.

It does make me wonder if you need to add an Evil SIP Idea [1] about 
assuming that all content ("all movies", say) is equally valuable because 
the bandwidth, latency and jitter requirements are the same... there may be 
evidence of this, based on recent movies in the theatre, but it's still 
wrong in the general case.

Spencer

[1] http://www1.ietf.org/mail-archive/web/sip/current/msg10808.html

> From the point of view of the network, these two services are  exactly the 
> same.
>
> they're completely different. Why do some DVDs sell for $1 and others  for 
> $100? Because the content on them is different.
>
> The totality of components defining a business system has to  recognize 
> these differences and be able to accommodate them.
>
> Our task in the IETF is to define the protocol at the network level.  The 
> network level has and requires no knowledge of this  differentiation. It 
> makes the address or name of the "content"  available to the business 
> layer, reports on the actual network  resources used (bandwidth, packets. 
> time, addresses, etc.) and that's  it. How somebody builds a business out 
> of that is out of our scope.
>
> Take for example the delivery of content on HTTP. Whether you use  eBay to 
> buy a new Ferrari or buy a toy replica of the same car  doesn't make a bit 
> of difference to the HTTP protocol, and not a lot  of difference to the 
> infrastructure of eBay. The price and selection  of the product is 
> critically important to the buyer and the seller,  but not to correct 
> operation of the web servers, the browsers, load  balancers, SSL 
> concentrators, routers, and stuff like that. Keeping  track of whether it 
> was a real Ferrari or a toy Ferrari is NOT a  protocol problem. It's a 
> problem of the application implementation.
>
> All we can reasonably do at the SIP level is solve the problems that  are 
> within the scope of a transport protocol. Jonathan's draft is an 
> that don't fit within that scope are, I believe, not something that  the 
> IETF can reasonably address. If we attempt to define the business 
> understanding of the problem scope, and rigorously staying within  that 
> scope.
>
> We probably can't deliver on Christer's definition of "service". We  can't 
> even seem to agree on what it means. But I think we do have an 
> understanding of "service" at the network level (stemming from  Jonathan's 
> draft) that is adequate for somebody else to build a  business layer on 
> top of. Perhaps we can help educate them on how to  do that building, but 
> we can't design their business for them.
>
> I propose we take the scope of network-level "service" as Jonathan  (more 
> or less) has it and run with it. Once this layer is in-place, I  believe 
> the business designers will be able to use it to get their  jobs done.
>
> --
> Dean
>
>
>
>
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 14 May 2007 14:56:48 -0400

If the access network needs to make a service decision, especially if it is
one that will determine billing, then it will hopelessly lose by using
something like a service identifier.

Let us take the example everyone loves: IPTV.  First is the reality check:
if the access provider offers a differential IPTV service, offering
third-party content, they probably have a business relationship with the
third-parties, and thus will know a priori from the Request-URI the request
is for IPTV.  Thus the access network knows directly this is an IPTV
request.

Let us examine a complementary situation: the subscriber takes an "IPTV
Quality" service from the access provider.  That is, the subscriber wants to
setup their session such that they get IPTV quality of service when they
target the session to what the subscriber knows is IPTV, but the access
provider does not know it is an IPTV source.  In this case, explicit
signaling of the requested QoS parameters is all that the access network
requires.  When the user requests "special" QoS parameters, and the UAS
accepts them (200 OK), the access network can bill for the "IPTV Quality"
service.  Everyone is happy: the user gets their QoS, the service provider
(the IPTV folks) get their customer without intervention or special
agreements with the access network provider, and the access network provider
gets to bill for premium service.

Note the service here is "IPTV Quality", and *not* IPTV.

Now, let us examine what happens if the access network does not know the
Request-URI resolves to IPTV yet the access network wants to differentially
bill for IPTV service.  The answer is... Count on the user lying!  I would
instantly hack my phone / device / endpoint to say all my IPTV calls are
video calls, unless IPTV is cheaper, in which case all my video calls will
be IPTV calls.

>> solution for http, why can't the same solution be applied to sip?

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Eric Burger <[email-masked]>
Date: Mon, 14 May 2007 14:57:01 -0400

I have to agree with Dean here.  The assumption in Route: urn:call-recorder
is the access network is the ONLY network that will act on this request.
This assumption is either trivial or wrong.

The trivial case is the one brought up earlier where the endpoint is always
connected to the same access network.  In this case, it is trivial to
configure either the outbound proxy or the endpoint to "do the right thing"
by either having the UAC explicitly routing through a call recorder, having
the UAC insert a proprietary token (like a URN) into the INVITE, having the
UAC do 3pcc to a media server, or having the outbound proxy apply whatever
logic would lead it to record the call (like being in a financial services
firm).

The wrong case is the endpoint puts in a token saying, "record this,"
without the endpoint knowing who will do the recording.  One bad outcome:
the first access network does the recording, and the user has no idea where
their recording is.  That could be quite embarrassing if you happen to be
roaming on the WiFi network of your local gossip magazine.  Another bad
outcome: the first access network and the termination network do the
recording, but *your* network, which never is in the call path, does not do
the recording.  Yet another bad outcome is the outbound proxy has no idea
what the URN is, and by applying loose routing strips the request from the
INVITE, so no recording gets done.

On 5/12/07 6:14 PM, "Dean Willis" <[email-masked]> wrote:

> yes, but which provider? Even in a "simple" user->originating
> provider->terminating provider->user model, there's a question of which
> "provider" executes on the URN, and what happens if the two providers have
> conflicting efinition of the URN.
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 15 May 2007 11:01:47 +0200

Hi,

I also think you need to separate the case where the UA may "know" that
an AS (in this case the recorder) needs to be invoked, and in the case
where it has no clue whether one or more AS:s need to be invoked.

But, assuming that the UA somehow knows, and somehow gets the URI(s) of
the AS(s) - it also needs to know where to put the URI(s), e.g. if the
UA has received a Service-Route with multiple entries during the
registration, and generates the INVITE route based on them. Especially
if the UA wants to reach AS(s) somewhere in the "middle of the path"
(e.g in the access network), it needs to know where in the route to
insert the URI(s). Also, if the UA wants to invoke AS(s) both in the
access- and home network (and possible whatever other network), it needs
to know which URI(s) "belongs" to which network, in order to build the
route correctly.

Regards,

Christer

> Sent: 12. toukokuuta 2007 0:10
> To: [email-masked]
> In one case, the UAC and its outbound proxy are tightly 
> coordinated (e.g., by a service provider that provides and 
> maintains both).  In that case, the means by which the UAC 
> requests this forwarding service from the outbound proxy does 
> not need to be standardized.
> 
> In the other case, the UAC and its outbound proxy are not 
> necessarily coordinated.  In that case, the routing URN 
> (functionally) it is requesting.  And that seems to send us 
> back into the "service identifier" problem that 
> draft-rosenberg-sipping-service-identification is warning us 
> away from.
> 
> It seems to me that Francois' approach is more likely to 
> work, where the UAC is provisioned in some way with the URI 
> of the service, and requests it of the outbound proxy.
> 
> In the default case, a roaming phone has no special 
> arrangements with the access network, and so has to tell the 
> access network *how* to get the call back to the service 
> network which operates the AS for the service the UAC wishes 
> to invoke.  In the more sophisticated case, where a roaming 
> phone has an implicit service agreement with the access 
> network (because the access network has a deal with the 
> service network), the roaming phone can presumably query the 
> access network for the URI of the access network's AS.
> 
> Dale
> 
>

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Tue, 15 May 2007 17:25:23 +0530

After reading through the comments. I wonder what is the key concern:

* The entire discussion started because 3GPP wanted to define a service ID that
classify services so that it is easier to policy and/or charge

* The IETF group felt that trying to dictate what a 'service' is is detrimental
to service innovation, since the IETF thought is these are all primitives which
can be infinitely combined to provide new features, so how can one
classify them?

It seems to me that the concern seems to be valid, only, if it is proposed that
service-id is:
	a) Mandatory
	b) Called 'Service ID' (fundamentally against the principles of many here)

So why is this not a solution:
	a) Make this opaque token optional, or, a P-Header, which is used for
a specific netwrok
	b) Rename 'Service-ID' to 'P-Classification-ID' - and declare this
MAY be used by nodes
	to validate against any network specific policy and/or charging issue.

Under this, if I choose to insert P-Classification-ID: "voice+video",
this is as good as any
artibrary text for me to correlate it any way I want for my policy or
Charging needs.

There have been examples posted here where just based on R-URI, it is
not possible for the calling
domain to know what service is invoked, and policying may still be needed.

So by changing the concept of 'Identifying a Service' to 'Identifying
a session for charging and/or policy
requirements', does this not address the philosophical objections ?

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 May 2007 12:13:00 -0500

> artibrary text for me to correlate it any way I want for my policy or

The main problem is that the service-ID debate has multiple concepts  
mixed together, with the argument presented that it solves all these  
things, whereas many people don't see it as working that way. Clearly  
there are requirements here that are not yet clearly understood, and  
expectations that may not be reasonably meetable. Hence, more  
analysis and discussion is required.

For example part of the requirements include routing on the service  
identifier exclusively to devices that support the named "service".  
That would also require a registration extension for the "service  
capabilities" of each UA. This looks a lot like caller preferences  
and callee-caps, and should probably be handled using RFC 3840/3841.  
There's a related question on routing requests through non- 
registering service nodes, that RFC 3840 and 3841 might NOT be  
appropriate for.

Another problem is capability compartmentalization. Since these are  
named "services", not actually operational characteristics (like "has  
a camera"), it requires every device to support the service "by name"  
instead of just having the capabilities required to run it. For  
example, let's take video calling. It might be reasonable to place a  
call from your video phone and expect that it would be routed only to  
nodes capable of receiving that call. So we'd want to go to phones  
that have a camera, have a display, have a microphone, have adequate  
bandwidth, and support a reasonably matched set of audio and video  
codecs. So selecting on these capabilities would be an appropriate  
task. However, each operator or local standards body would like to  
produce a "name" for that collection of capabilities. Then you would  
be restricted to making calls to other people who have the same  
definition of that name. So you might only be able to communicate  
with other users whose phones also call this service "Vodafone Live  
with 3G Video Calling (TM)" (http://www.vodafone.co.nz/personal/ 
vodafone-live/vodafone-live-with-3g/experience-3g/video-calling/ 
index.jsphttp://www.vodafone.co.nz/personal/vodafone-live/vodafone- 
live-with-3g/experience-3g/video-calling/index.jsp). This would be a  
very bad thing, as it would assure that interoperability could never  
occur. This leads to protocol segmentation, which (as we learned with  
Kerberos and "patented" settings of unused Kerberos options flags)  
can really fragment the network. Since the "naming" of the service is  
protected by law (using trademark, copyright, and patent) it could  
make building an interoperable device illegal. You could even end up  
with a DMCA lawsuit on your hands for coding a SIP client that could  
talk to one of these "Services". That's a totally insane thing for  
IETF to endorse.

And there are probably a lot more of these gotchas hiding under the  
covers.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 May 2007 14:07:01 -0400

>> artibrary text for me to correlate it any way I want for my policy or

A rose by any other name is just as sweet, and a turd by any other name 
is just as smelly.

Changing the name of the feature doesn't change the issues.

> expectations that may not be reasonably meetable. Hence, more analysis 
> and discussion is required.
> 
> identifier exclusively to devices that support the named "service". That 
> would also require a registration extension for the "service 
> capabilities" of each UA. This looks a lot like caller preferences and 
> callee-caps, and should probably be handled using RFC 3840/3841. There's 
> a related question on routing requests through non-registering service 
> nodes, that RFC 3840 and 3841 might NOT be appropriate for.

Note that IMS *already* has a problem in this area. They started using 
Accept-Contact as a substitute for Service-ID, and then route to 
particular Application Server middle boxes based on the presence of 
particular values in it.

They also call for the home proxy (S-CSCF) to do normal callerprefs 
processing when routing to registered contacts.

The problem is that the Application Servers are, in effect, providing 
UAs with certain capabilities (such as voicemail), rather than those 
things being candidates that the callerprefs are applied to. And there 
is no application of the callerprefs selection rules to those 
Application Servers. The end result is that you in some cases can't 
effectively use callerprefs for what it was intended for.

> named "services", not actually operational characteristics (like "has a 
> camera"), it requires every device to support the service "by name" 
> instead of just having the capabilities required to run it. For example, 
> let's take video calling. It might be reasonable to place a call from 
> your video phone and expect that it would be routed only to nodes 
> capable of receiving that call. So we'd want to go to phones that have a 
> camera, have a display, have a microphone, have adequate bandwidth, and 
> support a reasonably matched set of audio and video codecs. So selecting 
> on these capabilities would be an appropriate task. However, each 
> operator or local standards body would like to produce a "name" for that 
> collection of capabilities. Then you would be restricted to making calls 
> to other people who have the same definition of that name. So you might 
> only be able to communicate with other users whose phones also call this 
> service "Vodafone Live with 3G Video Calling (TM)" 
> (http://www.vodafone.co.nz/personal/vodafone-live/vodafone-live-with-3g/experience-3g/video-calling/index.jsphttp://www.vodafone.co.nz/personal/vodafone-live/vodafone-live-with-3g/experience-3g/video-calling/index.jsp). 
> This would be a very bad thing, as it would assure that interoperability 
> could never occur. This leads to protocol segmentation, which (as we 
> learned with Kerberos and "patented" settings of unused Kerberos options 
> flags) can really fragment the network. Since the "naming" of the 
> service is protected by law (using trademark, copyright, and patent) it 
> could make building an interoperable device illegal. You could even end 
> up with a DMCA lawsuit on your hands for coding a SIP client that could 
> talk to one of these "Services". That's a totally insane thing for IETF 
> to endorse.

Yeah, all this worries me too.

	Paul

> And there are probably a lot more of these gotchas hiding under the covers.
> 
> -- 
> Dean
> 
> 
> 
> 
> 
> 
>

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 15 May 2007 14:17:30 -0400

Dean:
 
I am commenting just on "routing of services" using "service-ID."
 
You might contact Jon P. for this. I remember that Jon brought a solid, good contribution in IPTEL WG couple of years ago for routing features that carry "service-ID" in the context of TRIP/EGREP. Jon was not an AD at that time.
 
However, IPTEL WG folks did not accept this because of the fact, as you are saying, that there must NOT be any standards for "routing of services."
 
I was interested about this to carry the routing information about services. I talked to Jon even to use those services ID for routing of services as you know private enterprises do use many of those things here and there and might shy away to create any standards like this as they might want have their edges over their competitors.
 
It appears that history repeats itself.
 
However, I would request Jon P. to bring his IPTEL contribution back to life from the morgue if those kinds of concepts ever need to be standardized.
 
Best regards,
Radhika

________________________________

From: [email-masked] on behalf of Dean Willis
Sent: Tue 5/15/2007 1:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 15 May 2007 11:32:39 -0700

>that there must NOT be any standards for "routing of services."

This is part of the Gordian Knot
http://en.wikipedia.org/wiki/Gordian_knot or the Egg of Columbus
http://en.wikipedia.org/wiki/Egg_of_Columbus and the equivalent here is
that "services in the network" make no sense, whereas applications in
the endpoints do make sense in the e2e principle of the Internet
architecture.

What baffles me is that even here at the IETF where the "stupid network"
has been defined; all these issues have to be put to rest again. 

Let's hope this burial will thorough (deep) enough for the IN/AIN
monster not to resurface any time soon.

Though I must admit that we could jointly operate an interesting and
useful blog site :-)

Thanks, Henry

From: Roy, Radhika R. [mailto:[email-masked]] 
Sent: Tuesday, May 15, 2007 1:18 PM
To: Dean Willis; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] I-D on service identification now available

Dean:

You might contact Jon P. for this. I remember that Jon brought a solid,
good contribution in IPTEL WG couple of years ago for routing features
that carry "service-ID" in the context of TRIP/EGREP. Jon was not an AD
at that time.

However, IPTEL WG folks did not accept this because of the fact, as you
are saying, that there must NOT be any standards for "routing of
services."

I was interested about this to carry the routing information about
services. I talked to Jon even to use those services ID for routing of
services as you know private enterprises do use many of those things
here and there and might shy away to create any standards like this as
they might want have their edges over their competitors.

However, I would request Jon P. to bring his IPTEL contribution back to
life from the morgue if those kinds of concepts ever need to be
standardized.

Best regards,

Radhika

--
Dean

---

From: [email-masked]
Date: Tue, 15 May 2007 16:05:22 -0400

From: "Arjun Roychowdhury" <[email-masked]>

   So why is this not a solution:
	   a) Make this opaque token optional, or, a P-Header, which
	   is used for a specific netwrok

If it's used in a specific network, it's not a matter of
interoperation, and so is out of our scope of interest.

And wasn't there someone who said a similar thing earlier, that once a
network classifies a request *for its internal purposes*, it is quite
reasonable for it to cache that classification in a header (as long as
that header doesn't leak into other networks).

Dale

---

From: [email-masked]
Date: Tue, 15 May 2007 16:31:35 -0400

How does that come about?  If the UA wants the call recorded, and
cannot record the call itself, it *has* to ask somebody to do the
recording.  How would it not know that an AS is needed?

   insert the URI(s).

That's an interesting technical problem, but conceptually it's not
complicated -- In order to have this case, the UA must know a priori
that the AS is in the access network's network, that is, it must have
a prior arrangement with the access network.  Presumably based on
that, it is also configured to know how to access the access network's
AS.

   Also, if the UA wants to invoke AS(s) both in the access- and home
   network (and possible whatever other network), it needs to know
   which URI(s) "belongs" to which network, in order to build the
   route correctly.

I think the problem you are attacking here has never been well
described:

The UA desires to place a call using features that it does not (wish
to) implement itself, but rather to invoke additional SIP agents
("application servers") to implement.

One approach is for the UA to tag the call with an abstract
description of the features that it needs and allow the network to
route the call via appropriate ASs.

This has disadvantages:  The features need to be described in a very
standardized way to ensure that all networks the call transits can
handle the request correctly.  The routing of the call is at the mercy
of not only the access network, but every other network it transits,
for the selection of ASs.  The UA may not have a business relationship
(or may not desire to do business) with the AS that the access network
chooses to implement a feature.

The other approach is for the UA to explicitly select the ASs to use
(usually via Route headers).

This has disadvantages:  The optimal AS to use may depend on the
access network of the moment (and the location of the UA in the access
network).  The optimal route to the AS may not be via the AS's
"public" address, but rather may short-circuit the service path used
to reach a public Internet access point.  Choosing the AS must be done
before the call is initiated, preventing the two endpoints from
negotiating which will be responsible for implementing the feature.

>From a protcol design point of view, the second approach is *safer*,
in that it is less likely to require global coordination to maintain
interoperability, and it allows endpoints to incrementally add
features, albeit often in a less than optimal way.

But what we're really looking for is a way for UAs to negotiate with
networks to allow the UA to more-optimally choose ASs for features
that it desires to use.

Dale

---

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 15 May 2007 16:58:02 -0400

Hi, all:
 
I am just commenting on Dale's statement as follows:
 
"... But what we're really looking for is a way for UAs to negotiate with networks to allow the UA to more-optimally choose ASs for features that it desires to use."
 
Again, it is a classical problem to choose the "optimal" AS out of many ASs. As if, it is a kind of load balancing as well as to find the azppropriate AS that offers this particular service.
 
It can be a kind of routing in the application server domain of a given kind. The other thing may be a service discovery.
 
If we take an example like SIP proxy call control (application) server, we know how people solve the optimal routing indirectly using the policy. Based on a given set of policies, proxy does the routing. DHCP/DNS has been used for SIP proxy discovery as well.
 
In the case of Web services, a host of things have been developed like UDDI.
 
It seems to be that there is no "generic" solution for "all" services for optimal routing and service discovery. And we do not need to solve this problem at all using a generic standard.
 
In other words, for a given service, there is a standard "application" protocol (e.g., SIP Call Control Service, Web Service, IM, Voice Mail Service, Speech-to-Text,/Text-to-Speech Service). The application-specific "standard" protocol itself takes care of those.
 
Is it not that UA needs to those application-specific protocols to solve those application-specific services, and those application-specific protocols need to take care of optimal routing and/or service discovery?
 
Am I missing something?
 
Best regards,
Radhika

From: [email-masked] on behalf of [email-masked]
Sent: Tue 5/15/2007 4:31 PM
To: [email-masked]
Subject: Re: [Sipping] I-D on service identification now available

Dale

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 May 2007 08:39:08 +0200

Hi Dale, 

>How does that come about?  If the UA wants the call recorded, 
>and cannot record the call itself, it *has* to ask somebody 
>to do the recording.  How would it not know that an AS is needed?

What I meant was that we need to separate the services where the UA may
"know" that an AS has to be inserted. The recording may be a service
where the UA does know, but in the case of service X the UA may not know
that an AS is needed.

>>UA has received a Service-Route with multiple entries during the
registration, and generates the INVITE route based on 
>>them. Especially if the UA wants to reach AS(s) somewhere in the
"middle of 
>>the path" (e.g in the access network), it needs to know where in the
route to
>>insert the URI(s).
> 
>That's an interesting technical problem, but conceptually 
>it's not complicated -- In order to have this case, the UA 
>must know a priori that the AS is in the access network's 
>network, that is, it must have a prior arrangement with the 
>access network.  Presumably based on that, it is also 
>configured to know how to access the access network's AS.

Yes. But, it may not just be enough to know in which network the AS is.
Again, if the UA has received multiple Service-Route entries during
registration, and builds the INVITE route based on those (or, based on
any other mechanism) it must still know WHERE in the route to insert the
AS URI. The Service-Route entries may point to multiple nodes, both in
the access network and in the remote network, so the UA must know where
to put the AS(s).

>to) implement itself, but rather to invoke additional SIP 
>agents ("application servers") to implement.
> 
>description of the features that it needs and allow the 
>network to route the call via appropriate ASs.
> 
>This has disadvantages:  The features need to be described in 
>a very standardized way to ensure that all networks the call 
>transits can handle the request correctly.  The routing of 
>the call is at the mercy of not only the access network, but 
>every other network it transits, for the selection of ASs.  
>The UA may not have a business relationship (or may not 
>desire to do business) with the AS that the access network 

It depends. One may define that only the home network (or networks that
has some kind of agreement with the home network, and knows when/if to
do something based on the service indication) does the service routing.
No, based on that definition the mechanism will not allow you to trigger
service routing in "any" network, but in some cases and environments
that may not even be required. As Radhika said, maybe the most optional
way is not to try to find one generic solution that would work anythime,
anywhere and in any possible scenario...

>The other approach is for the UA to explicitly select the ASs 
>to use (usually via Route headers).
> 
>This has disadvantages:  The optimal AS to use may depend on 
>the access network of the moment (and the location of the UA 
>in the access network).  The optimal route to the AS may not 
>be via the AS's "public" address, but rather may 
>short-circuit the service path used to reach a public 
>Internet access point.  Choosing the AS must be done before 
>the call is initiated, preventing the two endpoints from 
>in that it is less likely to require global coordination to 
>maintain interoperability, and it allows endpoints to 
>incrementally add features, albeit often in a less than optimal way.

I guess what you mean is that the second approach is safter, because you
will have a SIP message with everything shown in Route headers, and
there is no need for the network to understand anything.

But, you can't just look at the SIP message. I think even Dean said that
there are cases where it is not feasible that the UA knows everything,
because in that case we wouldn't need proxies in the first place.
 
>But what we're really looking for is a way for UAs to negotiate with
networks to allow the UA to more-optimally 
>choose ASs for features that it desires to use.

Just because the UA is able to negotiate with networks, e.g. regarding
what services etc it provides, it doesn't mean that the UA needs to know
the details of the network itself (e.g. network topology, in order to
know exactly where to insert the AS URI).

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 May 2007 08:39:44 +0200

Hi, 

>I have no problem with you having a definition like this of 
>service that applies between you and your UA, and perhaps 
>between the user's UA and some network elements under its control.
> 
>But it gets dicier if you are talking about something 
>provided to some other user - presumably the one you are 
>calling, or the one that called you.
> 

>Thats because we are concerned with the protocol,

Yes, and I think we should keep it that way, and let the people/groups
specialized in defining services do their job.

I don't think it's our job to say whether A and B are the same services
or not, whether a service can be retrieved from "pure" SIP signalling or
not, without any extra information, whether operators charge differently
for A and B, whether operators provide different QoS for A and B, etc
etc etc.

I also see no reason why we shall try to define some type of new concept
where we group SIP signalling with similar syntax and "network load"
into some type of "SIP protocol level services". Nobody has asked us to
do that, as far as I know.

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Fri, 18 May 2007 18:06:17 -0400

That would have been me.

Caching the calculation makes a ton of sense, as it can be quite complex.

Passing the result of the calculation between domains makes no sense, for
all the reasons we have been trying to tell folks.

Note the current drage draft has something akin to the rose/dung naming
dichotomy.  It properly defines a header for caching purposes, but it also
defines another header, by another name, that looks, smells, and (yuck)
tastes an awful lot like a client- or proxy-specified service indicator.