Subject: RE: [Sipping] Service Identification in SIP

From: <[email-masked]>
Date: Thu, 1 Feb 2007 16:39:16 +0530

Hello,

IMO, Service Identification is definitely needed and should be taken up
as a WG as proposed below.

Further, I think Service Identification scope should be as per the
requirement in Jonathan's draft, as I still do not understand the need
for having a Communication Service Identifier and another Application
Identifier as given in the 3gpp-ics-requirements document.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 8:30 PM
> To: sipping
> Cc: Mary Barnes
> Subject: [Sipping] Service Identification in SIP
> 
> Folks,
> 
> during the last year, there have been a number of threads on 
> the mailing list discussing service identification in SIP. In 
> particular, the following thread discussed 3GPP requirements 
> on this area:
> 
> http://www1.ietf.org/mail-archive/web/sipping/current/msg10562.html
> 
> At a later point, those 3GPP requirements were documented in 
> the following (expired by now) Internet Draft, which was 
> presented in a face-to-face IETF meeting.
> 
> http://www.watersprings.org/pub/id/draft-loreto-sipping-3gpp-i
> cs-requirements-00.txt
> 
> Lately, the following draft has been submitted to the archives:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-se
> rvice-identification-00.txt
> 
> This draft proposes a solution that intends to meet known 
> requirements in this area.
> 
> Given the amount of discussions on issues related to service 
> identification we have seen during the last year, we believe 
> this is a fairly important topic for the SIPPING WG to 
> tackle. At some point, we would like to have a milestone with 
> its associated WG item dealing with this issue.
> 
> Therefore, we would like to encourage people to read this 
> draft and send comments to the list. Additionally, if you 
> believe that this work is (or is not) important, we would 
> like to hear that as well.
> 
> Cheers,
> 
> Gonzalo
> SIPPING co-chair
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Wed, 07 Feb 2007 10:07:22 +0200

hi Ravi,

in IMS a Service is a "type of communication defined by a service
definition that specifies the rules and procedures and allowed media, if
any, for a specific type of communication and that utilises the IMS
enabler. An IMS communication service defines what is possible within a
single SIP session or standalone transaction."
So a Service implies some combination of capabilities and ways to use
those capabilities.
If you want the Service specifies the context for a communication.

Instead the Application define the specific communication (or if you
want application) that you want run in the specific context. So you
should have several different applications designed to run on a specific
environment or that have different performance or behavior in different
context (running on top of different service).

Lets go to Jonathan's example of the Chess.
In his example the Chess is a service, for IMS instead is an application
that you can run on top of different service.
For example you can run Chess application on top of PoC service or on
top of the "standard" service. So let say you run Chess on top of PoC
service, then you can use only voice in the way that PoC specifies.

/sal

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Feb 2007 12:13:22 -0500

I still don't get the intent of identifying the application. It seems to 
me this is evil - akin to sending an email message and identifying that 
the recipient must use Outlook to receive it, not Thunderbird, Eudora, 
gmail, or whatever.

I also wish somebody could give better examples of a communication 
service. Chess is too artificial to be believable, and IMO PoC is only a 
service because of the way the implementation has been done. 
Conceptually PoC could be nothing but a special floor control protocol 
accompanying a voice session. In that case none of the Service mechanism 
would be needed.

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 7 Feb 2007 09:33:55 -0800

> I still don't get the intent of identifying the application. It seems
to > me this is evil - akin to sending an email message and identifying
that > the recipient must use Outlook to receive it, not Thunderbird,
Eudora, 
> gmail, or whatever.

This goes back to the old discussion about the IN versus the "dumb
network" and we know how this has played out.

Placing intelligence (AKA services) in the network is just "dumb design"
IMHO for all the good reasons, but makes no sense to discuss on this
list.

SIP was designed as a rendezvous protocol for multimedia communications
on the Internet and not to replicate ISDN, etc., as has been so well
documented in RFC 4485:

   "SIP is not meant to be used as a strict Public Switched Telephone
   Network (PSTN) signaling replacement.  It is not a superset of the
   Integrated Services Digital Network (ISDN) User Part (ISUP).
   Although it can support gatewaying of PSTN signaling and can provide
   many features present in the PSTN, the mere existence of a feature or
   capability in the PSTN is not a justification for its inclusion in
   SIP."

Which makes me wonder how many folks have read RFC 4485 and taken it to
heart or may have chosen to forget it.

Thanks, Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 11:13 AM
To: Salvatore Loreto (JO/LMF)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

would be needed.

	Paul

---

From: <[email-masked]>
Date: Wed, 7 Feb 2007 20:36:34 +0200

Hello Sal,

In your example of Chess application running on top of PoC service,
since the service (here PoC) defined what is possible within a single
SIP session, and I assume Chess was not defined to be possible as part
of PoC service, then how it is possible to run Chess on top of PoC
within single dialog, and if it is not possible, then what does it mean
to "run Chess on top of PoC" if it is only possible with separate SIP
dialogs? 

BR,
Jari

-----Original Message-----
From: ext Salvatore Loreto (JO/LMF)
[mailto:[email-masked]] 
Sent: 07 February, 2007 10:07
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Sipping] Service Identification in SIP

hi Ravi,

/sal

On Thu, 2007-02-01 at 16:39 +0530, [email-masked] wrote:
> Hello,
> 
> IMO, Service Identification is definitely needed and should be taken 
> up as a WG as proposed below.
> 

> > during the last year, there have been a number of threads on the 
> > mailing list discussing service identification in SIP. In 
> > particular, the following thread discussed 3GPP requirements on this

> > area:
> > At a later point, those 3GPP requirements were documented in the 
> > following (expired by now) Internet Draft, which was presented in a 
> > face-to-face IETF meeting.
> > 
> > identification we have seen during the last year, we believe this is

> > a fairly important topic for the SIPPING WG to tackle. At some 
> > point, we would like to have a milestone with its associated WG item

> > dealing with this issue.
> > 
> > Therefore, we would like to encourage people to read this draft and 
> > send comments to the list. Additionally, if you believe that this 
> > work is (or is not) important, we would like to hear that as well.
> > 
> > Cheers,
> > 
> > Gonzalo
> > SIPPING co-chair
> > 
> > 
> > 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
> > 
> 
> 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

_______________________________________________
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: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 8 Feb 2007 17:35:24 +0100

I don't claim to understand much of this, but I did understand that one
of the functions of the application identifier was to identify the
appropriate API to call up in the terminal. Therefore the in that sense
it could be used to "rendezvous" the APIs of the two communicating
terminals.

However, not being a terminal builder, maybe one of that select breed
could identify if that is a useful function.

Regards

Keith 

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: 07 February 2007 17:34
> To: Paul Kyzivat; Salvatore Loreto (JO/LMF)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> to > me this is evil - akin to sending an email message and 
> identifying that > the recipient must use Outlook to receive 
> it, not Thunderbird, Eudora, 
> > gmail, or whatever.
> 
> This goes back to the old discussion about the IN versus the 
> "dumb network" and we know how this has played out.
> 
> IMHO for all the good reasons, but makes no sense to discuss 
> on this list.
> 
> SIP was designed as a rendezvous protocol for multimedia 
> communications on the Internet and not to replicate ISDN, 
> etc., as has been so well documented in RFC 4485:
> 
> Which makes me wonder how many folks have read RFC 4485 and 
> taken it to heart or may have chosen to forget it.
> 
> Thanks, Henry
> 
> me this is evil - akin to sending an email message and 
> identifying that the recipient must use Outlook to receive 
> it, not Thunderbird, Eudora, gmail, or whatever.
> 
> I also wish somebody could give better examples of a 
> communication service. Chess is too artificial to be 
> believable, and IMO PoC is only a
> 
> Conceptually PoC could be nothing but a special floor control 
> protocol accompanying a voice session. In that case none of 
> the Service mechanism
> 
> would be needed.
> 
> 	Paul
> 
> > definition that specifies the rules and procedures and 
> allowed media,
> if
> > enabler. An IMS communication service defines what is 
> possible within
> a
> draft and 
> >>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: <[email-masked]>
Date: Fri, 9 Feb 2007 12:31:07 +0530

Hi Paul,

IMO, service identification is different from identifying the tool that
should be used for executing that service on the end device. In the
analogy that you have given, e-mail is the service. Eudora/gmail/... Are
the tools that are used to provide the service.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor

> Sent: Wednesday, February 07, 2007 10:43 PM
> Cc: RaviShankar Shiroor (WT01 - Product Engineering 
> Solutions); [email-masked]; [email-masked]; 
> [email-masked]
> I still don't get the intent of identifying the application. 
> It seems to me this is evil - akin to sending an email 
> message and identifying that the recipient must use Outlook 
> to receive it, not Thunderbird, Eudora, gmail, or whatever.
> 
> believable, and IMO PoC is only a service because of the way 
> the implementation has been done. 
> the Service mechanism would be needed.
> 
> 	Paul
> 
> > if any, for a specific type of communication and that 
> utilises the IMS 
> > a single SIP session or standalone transaction."
> > should have several different applications designed to run on a 
> > specific environment or that have different performance or 
> behavior in 
> > different context (running on top of different service).
> > 
> > In his example the Chess is a service, for IMS instead is an 
> > application that you can run on top of different service.
> >> requirement in Jonathan's draft, as I still do not understand the 
> >> need for having a Communication Service Identifier and another 
> >> Application Identifier as given in the 
> 3gpp-ics-requirements document.
> >>
> >> Regards,
> >> Ravi.
> >>
> >> --
> >>  
> >> Ravishankar. G. Shiroor

---

From: <[email-masked]>
Date: Fri, 9 Feb 2007 13:44:20 +0530

Hi Salvatore,

As an end user, poc is also an application that I use and chess is also
an application that I can use. The way I see it, in your example, it
will be running chess application on top of PoC application.

So the service urn for this would be something like:

Urn:service:voice.poc.chess

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor

> From: Salvatore Loreto (JO/LMF) 
> Sent: Wednesday, February 07, 2007 1:37 PM
> To: RaviShankar Shiroor (WT01 - Product Engineering Solutions)
> in IMS a Service is a "type of communication defined by a 
> service definition that specifies the rules and procedures 
> and allowed media, if any, for a specific type of 
> communication and that utilises the IMS enabler. An IMS 
> communication service defines what is possible within a 
> So a Service implies some combination of capabilities and 
> ways to use those capabilities.
> Instead the Application define the specific communication (or 
> if you want application) that you want run in the specific 
> context. So you should have several different applications 
> designed to run on a specific environment or that have 
> different performance or behavior in different context 
> (running on top of different service).
> 
> For example you can run Chess application on top of PoC 
> service or on top of the "standard" service. So let say you 
> run Chess on top of PoC service, then you can use only voice 
> in the way that PoC specifies.
> 
> /sal
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Feb 2007 08:26:47 -0500

> the tools that are used to provide the service.

The comment below was about identifying the application in the end 
system, not the protocol.

In the case of email, the "service" is determined by the protocol and 
the address/port of the destination. Nobody has suggested adding headers 
to mail messages to identify the service/application in the end system 
that should process the mail message. But here we see proposals to add a 
header to a sip message to identify the service/application in the UAS.

	Paul

>> service or on 
> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 
> 
> WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
>  
> www.wipro.com
>

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Fri, 09 Feb 2007 16:38:50 +0200

Hi,

In my opinion we should also consider the user expectation.
I fully agree with you about the mail service,
but if I have look at the Instant Messaging service where at present
there are different and incompatible programs, then maybe the necessity
of a identification for the specific IM service become a little bit more
clear.

I think that everyone here agree that there is the possibility to use a
media in different ways, and that we need a distinction about what the
capabilities are and how they are used, whatever will be the mechanism
that at the end we will identify to do that.
What we do need is a way to identify a preference.

then what I don't completely understand, surely it is my fault, that a
combination of capabilities and ways to use those capabilities it is not
itself a capability, perhaps something we can call a *macro-capability*
Even if I agree on the opportunity of don't create a real Tower of 
Babel and avoid . So definitely this macro-capability should be well
defined and standardized.

Of course we need also discuss the opportunity to use the collerpref
mechanism to address this capability.
I agree with Paul that "callerprefs doesn't support well, if at all, is
the inclusion of intermediate servers into the call path."
This of course is not a problem from 3GPP point of view, because in a
IMS network it is present the IFC mechanism that resolve this
"callerpref" problem. 
But I do think we need a general mechanism that works also in a pure SIP
environment.

/sal

---

From: "Salvatore Loreto (JO/LMF)" <[email-masked]>
Date: Fri, 09 Feb 2007 17:04:30 +0200

Hi Ravi,

if you consider the Jonathan draft, he says that 

        "...chess game that
        
        utilizes voice commands to move pieces.  When one player says "Queen
        to D7", the software on their phone recognizes this and moves the
        piece.  At the same time, the user's voice is sent to the other
        player, where it is both rendered to the user, and interpreted
        locally in order to move the piece."

and he suggests that the following urn

   urn:service:games:voice-chess 

could be used to identify the voice chess application.

I guess that with voice he supposes audio, but nowadays we can also have voice
using PoC. Then we need a way to specify which kind of voice we want: a standard
full-duplex or a PoC. 
Maybe the chess game works well with, or it is designed for a standard audio but 
not for a PoC audio.
So we need to address also the voice preference we want.

I like your proposal, having something hierarchical was something I was thinking too
I don't know if it is your idea, but with the service urn you are proposing:

I imaging you are asking to play a Chess game, that work utilizing voice commands, 
but specifically voice over PoC.
This is also compliant to the draft-ietf-ecrit-service-urn (see section 3)

        "Declaration of syntactic structure: The URN consists of a
        hierarchical service identifier, with a sequence of labels
        separated by periods.  The left-most label is the most significant
        one and is called 'top-level service', while names to the right
        are called 'sub-services'.  The set of allowable characters is the
        same as that for domain names [1] and a subset of the labels
        allowed in [5].  Labels are case-insensitive and MUST be specified
        in all lower-case.  For any given service URN, service-identifiers
        can be removed right-to-left and the resulting URN is still valid,
        referring a more generic service.  In other words, if a service
        'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service
        URNs."

Regards
sal

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Feb 2007 12:12:36 -0500

> of a identification for the specific IM service become a little bit more

I don't understand you here. Once upon a time there were different and 
incompatible mail programs. But the introduction of SMTP forced them to 
become compatible. Similarly, it seems to me that SIMPLE should result 
in the various IM clients being a user preference rather than a 
prerequisite to communication.

> that at the end we will identify to do that.

When stated in such a general way I guess almost everyone will agree. 
That is why I would like more examples, because I have the feeling there 
are a number of cases where some think there is a distinction that must 
be made, and others who think that making such a distinction is bad and 
will result in balkanization. Personally I am yet to be convinced that 
there are practical cases where the distinction cannot be made without a 
special mechanism.

> What we do need is a way to identify a preference.

I'm especially concerned with about a preference on one end implying 
that the same preference should be applied on the other end.

> defined and standardized.

This is one place where I think we really disagree. And this goes back 
several years to a similar discussion about RPIDS and the representation 
of "services" there.

The problem is that you may find some combination of capabilities to be 
interesting, and want to embody that combination in an application. 
Then, when you call me, I guess you want to simply name that 
combination, and expect me to understand it and use my application that 
supports the same combination.

But I may not know about that particular combination and have an 
application that supports it. But I may have an application that 
supports a different set of capabilities that is a superset of what you 
have requested. Or I may not have anything that supports the complete 
combination that you want, but be able to support a useful subset of 
those that should interoperate with you, if only in a degraded manner.

The compatibility between these things can be more easily achieved if we 
negotiate by enumerating the basic capabilities, rather than by using 
names for collections.

I think it would be fine to name macro-capabilities as a shorthand for 
communicating between a particular user and his UA, or perhaps even 
between a UA and its own service provider. But I think the two ends of 
the call should be able to decide for themselves that macro-capabilities 
they support, with interoperation being decided by the compatibility of 
the supported basic capabilities.

For instance, your service provider may provide basic telephony (audio) 
and multimedia (audio/video) services. Mine may have only an 
advanced-telephony (audio/video/im) service. You should be able to call 
me using either of your services even though I know nothing about them.

> IMS network it is present the IFC mechanism that resolve this

I have been concerned about the proposal to use callerprefs in IMS to 
provide service identification, and my concern has a lot to do with the 
idea that the IFC mechanism, applied to callerprefs, can solve the 
problem of including appropriate intermediate servers into the call 
path. This is another case where I would very much like to see an 
example of what is intended.

I know there can be a simple filter criterion that can test for the 
presence of the name of a particular feature tag in an Accept-Contact 
header, and then cause the request to be routed to a server that handles 
the "service" denoted by that feature tag.

But that assumes a simplistic use of callerprefs. If the callerprefs are 
structured to specify more complex criteria, such as establishing a 
priority rating among feaures, then a particular feature tag may be 
present and yet not imply that the corresponding server is needed. (E.g. 
I might prefer full duplex audio/video, full duplex audio less so, and 
PoC as a last resort. If an IMS system unconditionally routed that call 
to a PoC server it wouldn't be adhering to the intent of the caller.)

> But I do think we need a general mechanism that works also in a pure SIP

We agree here. Again I think it would be very useful to have a bunch of 
use cases to consider. Then we could see how they might interoperate 
with different assumptions about the environment of the caller and callee.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 10 Feb 2007 15:30:57 -0500

I have to admit that I find a discussion that uses a single example a  
bit peculiar, particularly since the example is rather contrived.  
(Why would you use voice, plus speech-to-text presumably, to talk to  
a chess application?)

In a networking sense, the issue seems to be that we're using voice  
as a transport protocol to carry different distinct applications. (In  
the old days, a modem would have been such an application.)

I'll repeat what I've said before: SIP doesn't exactly suffer from a  
lack of complexity and mechanisms. At this point, before adding more  
machinery, we might want to ask as to whether there is truly a broad- 
based need for justifying additional machinery.

With regards to service URNs, I happen to believe that they are very  
reasonable as "modern" replacements for tel URIs, essentially  
extending the concept of 800 numbers. But that's a different problem  
from what I understand this discussion to be about. (In that usage,  
service URNs would be mapped to SIP AORs based on geography, time-of- 
day and other factors.)

Henning

On Feb 9, 2007, at 10:04 AM, Salvatore Loreto (JO/LMF) wrote:

> "...chess game that utilizes voice commands to move pieces.  When  
> one player says "Queen to D7", the software on their phone  
> recognizes this and moves the piece.  At the same time, the user's  
> voice is sent to the other player, where it is both rendered to the  
> user, and interpreted locally in order to move the piece."
> I guess that with voice he supposes audio, but nowadays we can also  
> have voice using PoC. Then we need a way to specify which kind of  
> voice we want: a standard full-duplex or a PoC. Maybe the chess  
> game works well with, or it is designed for a standard audio but  
> not for a PoC audio. So we need to address also the voice  
> preference we want. I like your proposal, having something  
> hierarchical was something I was thinking too I don't know if it is  
> your idea, but with the service urn you are proposing:  
> Urn:service:voice.poc.chess I imaging you are asking to play a  
> Chess game, that work utilizing voice commands, but specifically  
> voice over PoC. This is also compliant to the draft-ietf-ecrit- 
> service-urn (see section 3) "Declaration of syntactic structure:  
> The URN consists of a hierarchical service identifier, with a  
> sequence of labels separated by periods.  The left-most label is  
> the most significant one and is called 'top-level service', while  
> names to the right are called 'sub-services'.  The set of allowable  
> characters is the same as that for domain names [1] and a subset of  
> the labels allowed in [5].  Labels are case-insensitive and MUST be  
> specified in all lower-case.  For any given service URN, service- 
> identifiers can be removed right-to-left and the resulting URN is  
> still valid, referring a more generic service.  In other words, if  
> a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid  
> service URNs." Regards sal
>> Hi Salvatore, As an end user, poc is also an application that I  
>> use and chess is also an application that I can use. The way I see  
>> it, in your example, it will be running chess application on top  
>> of PoC application. So the service urn for this would be something  
>> like: Urn:service:voice.poc.chess Regards, Ravi. -- Ravishankar.  
>> G. Shiroor Wipro Technologies, Bangalore.  
>> [email-masked] -- > -----Original Message----- >  
>> From: Salvatore Loreto (JO/LMF) >  
>> [mailto:[email-masked]] > Sent: Wednesday, February  
>> 07, 2007 1:37 PM > To: RaviShankar Shiroor (WT01 - Product  
>> Engineering Solutions) > Cc: [email-masked];  
>> [email-masked]; > [email-masked] > Subject: RE:  
>> [Sipping] Service Identification in SIP > > hi Ravi, > > in IMS a  
>> Service is a "type of communication defined by a > service  
>> definition that specifies the rules and procedures > and allowed  
>> media, if any, for a specific type of > communication and that  
>> utilises the IMS enabler. An IMS > communication service defines  
>> what is possible within a > single SIP session or standalone  
>> transaction." > So a Service implies some combination of  
>> capabilities and > ways to use those capabilities. > If you want  
>> the Service specifies the context for a communication. > > Instead  
>> the Application define the specific communication (or > if you  
>> want application) that you want run in the specific > context. So  
>> you should have several different applications > designed to run  
>> on a specific environment or that have > different performance or  
>> behavior in different context > (running on top of different  
>> service). > > Lets go to Jonathan's example of the Chess. > In his  
>> example the Chess is a service, for IMS instead is an >  
>> application that you can run on top of different service. > For  
>> example you can run Chess application on top of PoC > service or  
>> on top of the "standard" service. So let say you > run Chess on  
>> top of PoC service, then you can use only voice > in the way that  
>> PoC specifies. > > /sal > > > > > On Thu, 2007-02-01 at 16:39  
>> +0530, > [email-masked] wrote: > > Hello, > > > >  
>> IMO, Service Identification is definitely needed and should > be  
>> taken > > up as a WG as proposed below. > > > > Further, I think  
>> Service Identification scope should be as per the > > requirement  
>> in Jonathan's draft, as I still do not > understand the need > >  
>> for having a Communication Service Identifier and another >  
>> Application > > Identifier as given in the 3gpp-ics-requirements  
>> document. > > > > Regards, > > Ravi. > > > > -- > > > >  
>> Ravishankar. G. Shiroor > > Wipro Technologies, Bangalore. > > > >  
>> [email-masked] > > -- > > > > > > > -----Original  
>> Message----- > > > From: Gonzalo Camarillo  
>> [mailto:[email-masked]] > > > Sent: Wednesday,  
>> January 31, 2007 8:30 PM > > > To: sipping > > > Cc: Mary Barnes >  
>> > > Subject: [Sipping] Service Identification in SIP > > > > > >  
>> Folks, > > > > > > during the last year, there have been a number  
>> of threads on the > > > mailing list discussing service  
>> identification in SIP. In > > > particular, the following thread  
>> discussed 3GPP > requirements on this > > > area: > > > > > > >  
>> http://www1.ietf.org/mail-archive/web/sipping/current/ 
>> msg10562.html > > > > > > At a later point, those 3GPP  
>> requirements were documented in the > > > following (expired by  
>> now) Internet Draft, which was > presented in a > > > face-to-face  
>> IETF meeting. > > > > > > http://www.watersprings.org/pub/id/draft- 
>> loreto-sipping-3gpp-i > > > cs-requirements-00.txt > > > > > >  
>> Lately, the following draft has been submitted to the archives: >  
>> > > > > > http://www.ietf.org/internet-drafts/draft-rosenberg- 
>> sipping-se > > > rvice-identification-00.txt > > > > > > This  
>> draft proposes a solution that intends to meet known > > >  
>> requirements in this area. > > > > > > Given the amount of  
>> discussions on issues related to service > > > identification we  
>> have seen during the last year, we > believe this is > > > a  
>> fairly important topic for the SIPPING WG to tackle. At some > > >  
>> point, we would like to have a milestone with its > associated WG  
>> item > > > dealing with this issue. > > > > > > Therefore, we  
>> would like to encourage people to read this > draft and > > > send  
>> comments to the list. Additionally, if you believe that this > > >  
>> > > > > > > Cheers, > > > > > > Gonzalo > > > SIPPING co-chair > >  
>> > > > > > > > _______________________________________________ > >  
>> > 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 > > > > > > > _______________________________________________  
>> > > 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  
>> > > The information contained in this electronic message and any  
>> attachments to this message are intended for the exclusive use of  
>> the addressee(s) and may contain proprietary, confidential or  
>> privileged information. If you are not the intended recipient, you  
>> should not disseminate, distribute or copy this e-mail. Please  
>> notify the sender immediately and destroy all copies of this  
>> message and any attachments. WARNING: Computer viruses can be  
>> transmitted via email. The recipient should check this email and  
>> any attachments for the presence of viruses. The company accepts  
>> no liability for any damage caused by any virus transmitted by  
>> this email. www.wipro.com

---

From: [email-masked]
Date: Sat, 10 Feb 2007 23:49:41 -0500

I've attempted to re-read the threads that Gonzalo referred to, and
the major limitation that I see is the lack of any concrete example of
why these identifiers are needed.  Probably the IMS people have
discussed this so many times that they've forgotten the detailed
rationale behind the requirement.  But I'm a net-head, (and most of
the people here are net-heads) and the SIP systems that I've dealt
with show no evidence of needing "service identification", they're
pure proxies, and requests are passed transparently end-to-end.

Could somebody please lay out an example showing the utility of
service identification?

   From: "Salvatore Loreto (JO/LMF)" <[email-masked]>

Respectfully, I disagree.  We do need ways of identifying the
capabilities of SIP agents and transports, but I see no necessity of
creating specified bundles of capabailities, and then constraining
dialogs to require an initial agreement as to which bundle of
capabilities will be used.

One of the central features of Internet architecture is that agents
negotiate compatibility on a feature-by-feature basis; there are no
"profiles" which must be known on a network-wide basis.  (And I have
observed that this feature is of significant commercial value.)

In regard to identifying an "application" to process the dialog (and I
use "application" in a standard computing way), I see no reason that a
user cannot select URI-parameters to append to his AOR, and arrange
for his UA to route invites with those URI-parameters to the
appropriate application.  (And given the rich mechanisms for
redirection in SIP, the application need not even reside at a UA which
is registered for the AOR.)  These URI-parameters can be formally or
informally standardized, or established ad-hoc by each user.

In regard to PoC (as someone said, "a specialized floor-control
protocol") and similar features, SIP currently has mechanisms for
indicating support of features and requiring that a recipient support
a feature before accepting a call (the Supported and Requires headers,
and simply using the feature).  The only limitation I can see that
might need to be addressed is that there is no way to create an option
tag for a new feature that one has invented that is not yet thoroughly
standardized.

But I now discover RFC 3261 section 8.1.1.9:

   The option tags listed MUST only refer to extensions defined in
   standards-track RFCs.  This is to prevent servers from insisting that
   clients implement non-standard, vendor-defined features in order to
   receive service.  Extensions defined by experimental and
   informational RFCs are explicitly excluded from usage with the
   Supported header field in a request, since they too are often used to
   document vendor-defined extensions.

So I see that as a fundamental architectural decision, SIP does not
permit sending INVITEs that require specialized recipients, excepting
if the specialization is standards-track.

Dale

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 11 Feb 2007 06:56:44 -0800

Dale Worley wrote:

>Could somebody please lay out an example showing the utility of service
>identification?

Sure: The service identification is most likely a new charging
contraption invented in a marketing department. As such, any protocol
significance cannot be found nor explained.

One has to wonder if users who have the choice of superior quality
wideband audio are willing to see new billing items for what they can
have for free and with richer features, as long as they pay for the only
service that matters: Internet access.

Proposals such as the "Service Identification in SIP" could be better
handled in a marketing WG, if there were such a thing in the IETF :-)

It would be helpful if such schemas devised in other organizations and
submitted here for the IETF blessing would not burden the Internet
standards work. Maybe a guidance paper from the IESG is in order? 
My two cents. 

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, February 10, 2007 10:50 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

   I think that everyone here agree that there is the possibility to use
a
   media in different ways, and that we need a distinction about what
the
   capabilities are and how they are used, whatever will be the
mechanism
   that at the end we will identify to do that.

Dale

---

From: [email-masked]
Date: Mon, 12 Feb 2007 17:56:40 -0500

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

I think that it's more complicated than that.  If it was only a
matter of billing based on the services used, a fairly simple scheme
for monitoring the communication stream and generating billing entries
would be simpler and more efficient.

Let me throw out an idea (which I've probably stolen from someone
else), one which I recall based on the BT announcement.

AFAICT, for many service providers, an incoming call (regardless of
the destination E.164 number) will get routed to one of a set of
"application servers" (AS), each one of which handles a particular
"service".  The application server is responsible for managing the
final link to the phone.  From an Internet perspective, what is really
happening is that the UA is partitioned into two parts, part on the AS
and part on the real phone.

This has some advantages, in particular that a new service can be
implemented by buying and installing an AS, as long as the AS-to-phone
link provides adequate facilities for the lowest-level UI functions.

There are disadvantages, too, particularly that both ends of a call
have to agree on the "service" being used, and that each service in
effect defines a subset network, consisting of the ASs for that
service, and all phones which are serviced by an AS for that service.
Worse, services cannot be mix-and-matched in any way, even if both
users would be willing to pay the fees to support all of the needed
infrastructure.

In some cases, this sort of architecture may be difficult to avoid.
For instance, the push-to-talk (PTT) feature.  The way it's
implemented is rather a cheat -- The call is first sent to an AS.  If
the AS thinks that the callee's phone is registered with the network,
and the last status update from the callee's phone says that it will
answer PTT calls immediately, then the AS sends a "call connected"
indication to the caller before it has achieved a voice channel
connection with the callee phone.  It then starts buffering the
caller's audio for the several seconds it needs to gain a voice
connection to the callee phone.  Once it gets a connection, it plays
the buffered audio, using various tricks to make playback faster than
real-time.

But given the limitation that the last link to the callee's phone does
not impelment "immediate connection", there is no way provide PTT
without an AS.

I think the architectural challenge is how to support this sort of
network but without the nasty effects of "siloing":

- If a caller requests to use a particular feature, and the callee is
  unable or unwilling to support that feature, and the caller is
  willing to proceed without using the feature, the call should
  proceed without the feature.

- A call can request multiple features, and it will proceed using
  whatever subset of them are supported by the callee.

I don't see this as intrinsically impossible to achieve, even if every
feature is implemented by ASs.  Assuming the features are reasonably
well-behaved, it should be possible to chain a call through several
ASs before reaching the callee phone.

(This may require a separate charge for the use of each AS, but that's
not unfair -- by hypothesis, the ASs implement features that the
callee phones do not, and someone has to pay for the ASs.)

It would be helpful if each INVITE declared all of the features that
would ever be used during the call.  In some cases, the INVITE already
contains the needed information (particularly in regard to the media
features).  But it seems that we should avoid this requirement if
possible.  OTOH, it seems plausible that an AS could be inserted into
the service chain during a dialog -- I've plotted out call flows by
which a B2BUA can insert itself into an existing dialog using
INVITE/Join, and a cluster of ASs in a closed zone of a network can
perform more dexterous rerouting tricks.

Dale

---

From: <[email-masked]>
Date: Tue, 13 Feb 2007 09:39:35 +0530

Paul Kyzivat wrote:
> Sent: Friday, February 09, 2007 6:57 PM
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > IMO, service identification is different from identifying the tool 
> > that should be used for executing that service on the end 
> device. In 
> > the analogy that you have given, e-mail is the service. 
> > Eudora/gmail/... Are the tools that are used to provide the service.
> 
> The comment below was about identifying the application in 
> the end system, not the protocol.
> 
> In the case of email, the "service" is determined by the 
> protocol and the address/port of the destination. Nobody has 
> suggested adding headers to mail messages to identify the 
> service/application in the end system that should process the 
> mail message. But here we see proposals to add a header to a 
> sip message to identify the service/application in the UAS.

I would not mind if the e-mail that is delivering meeting notification
automatically gets delivered to my calendar application. If I have three
different tools handling it, I would set one of them to preferred
calendar application. Similarly if some one sends me a mail with
contacts, I would like it to be picked up by my Contacts application.
I see gmail/Eudora as just tools to execute certain applications. But
the e-mail being delivered should be able to say if it is a calendar
notification/plain mail/.... Application.

Regards,
Ravi.

> >> Cc: RaviShankar Shiroor (WT01 - Product Engineering Solutions); 
> >> [email-masked]; [email-masked]; 
> >> [email-masked]
> >> It seems to me this is evil - akin to sending an email message and 
> >> identifying that the recipient must use Outlook to receive it, not 
> >> Thunderbird, Eudora, gmail, or whatever.
> >>
> >> service. Chess is too artificial to be believable, and IMO PoC is 
> >> only a service because of the way the implementation has been done.
> >> protocol accompanying a voice session. In that case none of the 
> >> Service mechanism would be needed.
> >>
> >> 	Paul
> >>
> > The information contained in this electronic message and 
> any attachments to this message are intended for the 
> exclusive use of the addressee(s) and may contain 
> proprietary, confidential or privileged information. If you 
> are not the intended recipient, you should not disseminate, 
> distribute or copy this e-mail. Please notify the sender 
> immediately and destroy all copies of this message and any 
> attachments. 
> > 
> > WARNING: Computer viruses can be transmitted via email. The 
> recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any 
> damage caused by any virus transmitted by this email.
> >  
> > www.wipro.com
> > 
>

---

From: <[email-masked]>
Date: Tue, 13 Feb 2007 09:46:17 +0530

Savatore Loreto wrote:

________________________________

	Sent: Friday, February 09, 2007 8:35 PM

	Hi Ravi,

		"...chess game that 
		utilizes voice commands to move pieces.  When one player
says "Queen
		to D7", the software on their phone recognizes this and
moves the
		piece.  At the same time, the user's voice is sent to
the other
		player, where it is both rendered to the user, and
interpreted
		locally in order to move the piece."

	

	I guess that with voice he supposes audio, but nowadays we can
also have voice
	using PoC. Then we need a way to specify which kind of voice we
want: a standard
	full-duplex or a PoC. 
	Maybe the chess game works well with, or it is designed for a
standard audio but 
	not for a PoC audio.
	So we need to address also the voice preference we want.
	
	I like your proposal, having something hierarchical was
something I was thinking too
	I don't know if it is your idea, but with the service urn you
are proposing:

	I imaging you are asking to play a Chess game, that work
utilizing voice commands, 
	but specifically voice over PoC.
	[RAVI>> ] Yes. That is what I am proposing. Thus, I do not see
the need for specifying the communication service identifier separately.
Only the service URN (whatever it is called - service
identifier/application identifier) is sufficient to meet the
requirements of application identification on the end device.
	 
	This is also compliant to the draft-ietf-ecrit-service-urn (see
section 3)

		"Declaration of syntactic structure: The URN consists of
a
		hierarchical service identifier, with a sequence of
labels
		separated by periods.  The left-most label is the most
significant
		one and is called 'top-level service', while names to
the right
		are called 'sub-services'.  The set of allowable
characters is the
		same as that for domain names [1] and a subset of the
labels
		allowed in [5].  Labels are case-insensitive and MUST be
specified
		in all lower-case.  For any given service URN,
service-identifiers
		can be removed right-to-left and the resulting URN is
still valid,
		referring a more generic service.  In other words, if a
service
		'x.y.z' exists, the URNs 'x' and 'x.y' are also valid
service
		URNs."

	Regards
	sal

	On Fri, 2007-02-09 at 13:44 +0530, [email-masked]
wrote: 

		Hi Salvatore,
		
		As an end user, poc is also an application that I use
and chess is also
		an application that I can use. The way I see it, in your
example, it
		will be running chess application on top of PoC
application.

		
		Regards,
		Ravi.
		
		--
		 
		Ravishankar. G. Shiroor

		> > IMO, Service Identification is definitely needed and
should 
		> be taken 
		> > for having a Communication Service Identifier and
another 
		> Application 
		> > > following (expired by now) Internet Draft, which
was 
		> > > identification we have seen during the last year,
we 
		> believe this is 

		The information contained in this electronic message and
any attachments to this message are intended for the exclusive use of
the addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments. 
		
		WARNING: Computer viruses can be transmitted via email.
The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
		 
		www.wipro.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Feb 2007 23:36:46 -0500

Dale,

What you describe is largely consistent with the infrastruction of IMS, 
although there are a million ways that infrastructure could be applied.

> and part on the real phone.

It is interesting to view the partitioning of the function between two 
servers as you suggest. I think it would be much more straightforward if 
such an AS was actually treated as a first class UAS that has registered 
and is selected in the same way that other registered UAs are selected 
for a call. Notably, that callerprefs could be used to make the choice.

Unfortunately, IMS has chosen to use a different algorithm to decide how 
to involve ASs.

> not impelment "immediate connection", there is no way provide PTT

As I noted above, I think this can be handled better by treating the AS 
as the actual target. But I think this is a deviant case, and not a good 
one to generalize into a general purpose architecture.

> network but without the nasty effects of "siloing":

Unless there are more applications that share this problem, it may be 
easier to simply treat it as a special case and wait for technology to 
obsolete it. I suspect that faster networks and more bandwidth will 
solve this, so that it can be handled e2e and viewed simply as special 
floor control and UI. If we could get there then it starts to look just 
like IM.

> ASs before reaching the callee phone.

Actually in IMSs case, the call can in fact be chained to multiple ASs. 
But of course they have to be applied in some order.

Its far from clear that services can in general be composed in this way 
and still work.

> perform more dexterous rerouting tricks.

Lots of things are possible, but it will be a challenge to firgure out 
what to do in a particular circumstance.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Feb 2007 23:46:11 -0500

> notification/plain mail/.... Application.

Well, in this particular case,I would expect the meeting notification to 
be carried as one mime type in the body, and the contacts to be carried 
as another mime type. And its expected that these will be dispatched to 
a suitable application by the receiving email application *after* it is 
received.

Note that the mime type defines the information carried, not the 
application that will process it.

For SIP, the same thing is possible with body types. And further, the 
different types of media streams can be handed off to different 
applications.

	Paul

>>>> should be taken

---

From: <[email-masked]>
Date: Tue, 13 Feb 2007 12:24:43 +0530

Paul Kyzivat wrote:
> protocol and 
> >> the address/port of the destination. Nobody has suggested adding 
> >> headers to mail messages to identify the 
> service/application in the 
> >> end system that should process the mail message. But here we see 
> >> proposals to add a header to a sip message to identify the 
> >> service/application in the UAS.
> > 
> > automatically gets delivered to my calendar application. If I have 
> > three different tools handling it, I would set one of them to 
> > preferred calendar application. Similarly if some one sends 
> me a mail 
> > with contacts, I would like it to be picked up by my 
> Contacts application.
> Well, in this particular case,I would expect the meeting 
> notification to be carried as one mime type in the body, and 
> the contacts to be carried as another mime type. And its 
> expected that these will be dispatched to a suitable 
> application by the receiving email application *after* it is received.
> 
> Note that the mime type defines the information carried, not 
> the application that will process it.
> 
> For SIP, the same thing is possible with body types. And 
> further, the different types of media streams can be handed 
> off to different applications.
> 
> 	Paul

Mime type does not just say it is ascii text; it says it contains
meeting notification - and that's how the application/service is
identified. 
In this example, the payload is being identified as being used for the
calendar service.
In SIP, if the payload was being delivered as an attachment to SIP
message, then the mime type would be sufficient. If SIP is only setting
up the media path, how is the service to be identified? I think the
service identifier would be useful in that case.

> message and 
> communication 
> exclusive use of 
> >> should not disseminate, distribute or copy this e-mail. 
> Please notify 
> >> the sender immediately and destroy all copies of this 
> message and any 
> >> attachments.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Feb 2007 11:23:18 +0100

Hi,

First, the document talks about outbound proxy, home proxy, originating
proxy and terminating proxy, but there is no real
definition/explanation/reference to what those proxies really are.

Second, the draft also uses Jonathan's loose route draft. Have we
decided to work on that draft? I remember there was quite much
discussion at one point, but what happened after that? In any case, a
few words WHY the mechanism is needed would also be useful.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 13 Feb 2007 12:26:46 +0100

Third, why is GRUU mandated?

Regards,

Christer

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 13. helmikuuta 2007 12:23
> To: [email-masked]
> Subject: [Sipping] Service Identification in SIP - proxy types
> 
> 
> Hi,
> 
> First, the document talks about outbound proxy, home proxy, 
> originating proxy and terminating proxy, but there is no real 
> Second, the draft also uses Jonathan's loose route draft. 
> Have we decided to work on that draft? I remember there was 
> quite much discussion at one point, but what happened after 
> that? In any case, a few words WHY the mechanism is needed 
> would also be useful.
> 
> Regards,
> 
> Christer
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 13 Feb 2007 10:18:30 -0800

It must be my lack of imagination for not being able to come up with a
credible usage scenario, given the following:

- Is playing chess by voice a credible usage scenario? :-)
Especially since voice recognition is now so often found in PCs and in
mobile phones as well. In other words, chess playing by voice may also
be an endpoint application, without any network involvement. Actually,
if placed in the endpoint it works just as well on poor bandwidth links
by contrast to chess in the network that may require adequate broadband.

- Is anyone's boss or spouse going to approve extra phone charges above
the flat rate for playing chess at a time when the gaming industry has
pioneered free VoIP?
Will such a service be taxed extra and if yes using by what criteria?
Gambling comes to my mind :-)

- VoIP is reported in the press as a give-away and I have seen no
reports of any VoIP provider recording a profit on VoIP. I assume the
losses are often hidden by bundling in triple play, etc.

Given my lack of imagination, can anyone share a more credible usage
scenario for Service Identification in SIP?

What's the use of a standard without a credible usage scenario?

Thanks, Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Feb 2007 15:31:09 -0500

> meeting notification - and that's how the application/service is

Yep, I know. At least it does if the meeting notification has a well 
defined machine understandable syntax.

> In this example, the payload is being identified as being used for the

Well, for you it might be a calendar service. For me it might be 
something else that processes meeting notifications and perhaps various 
other things as well.

> service identifier would be useful in that case.

Well, the obvious answer, though perhaps not sufficient, is that the 
media description is enough for the recipient to decide. Jonathan has 
used Chess as an example of where the media description is insufficient, 
but it is a very contrived example.

PoC has been offered as another example. But in that case I think it 
would not be hard to come up with an appropriate use of the media 
description to distinguish this case, though it may well require some 
new extension. PoC is clearly distinguished from regular voice by having 
a special floor control. It would be entirely appropriate use of SDP to 
indicate the need for that floor control. So I'm not yet convinced PoC 
is a great example either, though it is better than Chess.

An advantage to using the media description is that potentially each 
media stream can be treated separately, or they can be coupled if that 
is required. Note that in email I can have several attachments of 
differing mime types, and application selection is done separately for 
each. It should be possible to do the same for SIP. For instance, if an 
invite that includes audio and MSRP, it should be possible for those to 
be handled by different applications on the device. (Of course it should 
also be possible for a single application to handle both if it is capable.)

There are already drafts/rfcs that provide for labeling media streams 
for the role they are intended to play for the session. These could 
easily be used by the recipient to make special assignments of media to 
applications.

There may indeed still be cases when something else is needed. But, like 
Henry, I'm looking for some plausible use cases to consider.

	Paul

---

From: "Esteban, Jairo O \(Jairo\)" <[email-masked]>
Date: Tue, 13 Feb 2007 15:34:08 -0600

All,

After reading all the posts in this thread I am wondering if the
difficulty to find use cases has to do with the definition of the
problem and/or proposed solution. For example, one of the motivations
for this draft is the fact that media description is not always enough
to distinguish what the UE wants to do. But there are alternate
solutions besides filling this void using SIP. One possibility would be
to add this power to the SDP body, instead. At least in some of the
examples I have found here, that approach might work well. Do we need a
more powerful (and complex) SIP protocol or a more powerful SDP
body?...or both?

Just from the top of my head: If some involvement of the elements in the
path is required (e.g. dynamic routing), service/capability/feature data
shall be carried by the SIP message. If only the endpoints are involved,
it is up to the SDP body to convey this information and enable the
negotiation between all the participants of the session. 

Just want to explore other possibilities...Would this be crazy?

An initial comment that comes to my mind is that there would be
different approaches to deal with services provided by Application
Servers and services provided by the UE. But, would it be really bad?
Aren't they both fundamentally different?

Jairo

---

From: [email-masked]
Date: Wed, 14 Feb 2007 13:58:42 -0500

From: Paul Kyzivat <[email-masked]>

What I'm trying to do is get a real application in front of us.
Unfortunately, the IMS people have not been very forthcoming
discussing this.

   for a call.

Well, in a sense the AS is -- the call reaches it through the AOR.

   Notably, that callerprefs could be used to make the choice.

Yes, the crux is how the call routing is done.  I'm not as familiar
with callerprefs as I should be.  Could you outline how to use
callerprefs to route, say, PoC calls, to the correct AS to support a
UA that can't handle PoC on its own?

I'd like to see how callerprefs avoids the "siloing" risks that the
current proposal has.

I assume that callerprefs can be set up so that routing can be done on
some priority ordering of the features.

Dale

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Thu, 15 Feb 2007 16:03:32 +0100

Hi,

Firstly to some examples that come to my mind.  I know that the
separation of PoC and from Telephony has been raised.  It has been
stated a few times that "PoC is just a specialised floor control".  I
don't believe that to be correct.  It is true that both Telephony and
PoC use voice as a media; and that in addition PoC uses a floor control.
In addition to that, an operator may wish to prioritise these
differently in a resource constrained access network (e.g. a radio
network).  For example, voice for Multimedia telephony may be
prioritised higher than Push to talk voice - this is also for more
efficient use of resources in a resource constrained access network.  A
further differentiation between them, is that some of the "sub services"
or "features" or <choose your favourite word> for them are different
(e.g. communicate forwarding on subscriber not reachable) which
ultimately results in the service logic being different for them.

An example of another service is (Instant) messaging.  Instant messaging
may use MSRP to transfer text (e.g. "Hello") between users.  However,
MSRP may also be used in the context of other services, such as
telephony, or to transfer information from one device to another device
(e.g. address book information).

Another example could be a SIP push type of service.  A SIP push service
would be the ability to push e.g. data to a device.  The SIP push may be
just a simple MESSAGE message, or an INVITE; however it should be
distinguished from other uses of that as the information may not be
destined for the end-user.  On top of that, then the exact application
to which the information is being pushed would be useful.

These examples of PoC - Telephony; Messaging - Telephony are examples of
different types of communication services where same media can be used
in different contexts.  I should note that the examples of PoC,
telephony and messaging are examples of bundled services, but what is
wrong with that?  It provides a good way to increase the possibility of
mxn interoperability by ensuring that clients will test against at least
those capabilities.

In my understanding, the lack of the ability to identify these
communication services, implies that "basic SIP communication" in itself
is monolithic service.  That can be quite OK in a small, or controlled
network, but I don't see that in a broader context, in particular a
multiservice network.  I would like to point out here, that this does
not imply anything relating to the implementation.  A vendor can build
the support for the different services out of a bunch of common
components; and there is of course a great deal of commonality that
supports such re-use.

This leads me to my next topic, the example of a chess application using
the voice.  While being discredited by some people, I think it does
point out that that context where the media being used needs to be
understood by some applications.  You could as well take the same
example where the Chess application also established a separate control
channel between the two devices, but the rest of the experience required
was as per telephony.  In the 3GPP documentation, there is a
differentiation between a "Communication service" and an "Application".
The idea is that the "Applications" use the basic rules for
communication defined by the "communication service".  The parallel
example here, is Chess is the "application", while the communication
service itself could be telephony.  We can further note here, that
having an application re-use another existing communication is not new -
it has been used with e.g. SMS for a while, where the SMS infrastructure
has been used for delivering messages to the user, as well as to the
device.  We use it in IP all the time as well ;-)

Moving onto the proposed solution draft itself, in addition for
providing for the identification of the "application" and the
"communication service", I have a few additional thoughts.

The draft seems to have the implication that all services (communication
services in other terminology) that are to be identified have to be
standardised within the IETF.  This is clearly an restriction that will
not be acceptable to the industry as a whole.  My guess is that if such
a statement is mandated by the IETF, it will just be words on paper
which would likely be ignored in practice by other standardisation
organisations.

The draft also only recognises the case where all explicitly knowledge
of the service is required.  I think it would also be good to allow the
case where knowledge of the service would be helpful, but not explicitly
required.  This could be a case where the service to the end-user would
not be degraded if this was not supported.  This functionality seems to
be missing.

The draft seems to indicate that that application servers in the network
are involved only at the request of the originating terminal.  This
seems a strange restriction.  For some network support that supports the
originating user, such as the one provided in the example "I would like
this call recorded for later retrieval", such mechanisms may make sense,
however as a general approach it seems a bit limited.  For example, in
3GPP networks there is the need to invoke application logic in the
originating side and terminating side, not only at the request of the
originating terminal, but as a consequence of the requested service.  If
there is an SIP message contains indication of the requested service, a
proxy can do this (or loose route to an AS that contains the necessary
service logic).  I note here that the proposed service URN does not
contain the address of a specific server containing the application
logic.  An AS can look at that, and loose route to an application server
that does contain such logic (If it is separated from the proxy),
however I fail to see the difference for that proxy if it looks at a
feature tag, or it looks at the service URN for this.  In both cases, it
has to parse the message for the data, and modify the routing
information.  Further, the route header could be removed in the
originating network; and it is still required to identify the service in
the terminating network.  As proxies may remove the route, it can't be
used to transport the requested service.  From this perspective it is
not clear to me the advantage of using a service URN in a route header
compared to the use of a feature tag.

The draft seems to mandate GRUU - is this really so, is that really
necessary.  It seems strange to place such a dependency, it also starts
to move the GRUU as being the primary means of which to contact a user.
This implies that the originating user decides which terminal I should
receive my requested service on, even if I have two devices for that.
As such, I don't believe that there should be a dependency on GRUU.

Parts of the draft seems to rely on the use of presence.  While presence
could be a supportive mechanism, I doubt that we can mandate that the
number you want to dial has be available in presence as I assume not all
entities are available in presence (diallable network services, users in
the PSTN).  This would be strange to mandated.

Moving on from the draft I have seen the questioned raised about "why
can't we expand the power of SDP".  Such an approach would mandate that
SIP methods use SDP, I don't think that is appropriate. 

I hear the appeals that the mechanisms should not be abused, and that we
should not have 1000s of separate "communication services", and I fully
agree with this. I see a smaller number of communication services, not a
larger number; where those communication services are used to access
other end-user-services.

*flame away*

Regards,

Steve

---

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, February 11, 2007 5:50 AM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

I've attempted to re-read the threads that Gonzalo referred to, and the
major limitation that I see is the lack of any concrete example of why
these identifiers are needed.  Probably the IMS people have discussed
this so many times that they've forgotten the detailed rationale behind
the requirement.  But I'm a net-head, (and most of the people here are
net-heads) and the SIP systems that I've dealt with show no evidence of
needing "service identification", they're pure proxies, and requests are
passed transparently end-to-end.

In regard to identifying an "application" to process the dialog (and I
use "application" in a standard computing way), I see no reason that a
user cannot select URI-parameters to append to his AOR, and arrange for
his UA to route invites with those URI-parameters to the appropriate
application.  (And given the rich mechanisms for redirection in SIP, the
application need not even reside at a UA which is registered for the
AOR.)  These URI-parameters can be formally or informally standardized,
or established ad-hoc by each user.

In regard to PoC (as someone said, "a specialized floor-control
protocol") and similar features, SIP currently has mechanisms for
indicating support of features and requiring that a recipient support a
feature before accepting a call (the Supported and Requires headers, and
simply using the feature).  The only limitation I can see that might
need to be addressed is that there is no way to create an option tag for
a new feature that one has invented that is not yet thoroughly
standardized.

So I see that as a fundamental architectural decision, SIP does not
permit sending INVITEs that require specialized recipients, excepting if
the specialization is standards-track.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Feb 2007 11:40:15 -0500

Steve,

Thank you for providing some insight here. I know you are deeply into 
IMS, so I'm hoping we can take these as representative of the intended 
usage by those asking for service identification in SIP.

I think now it will be helpful to discuss each of these in more depth, 
to understand them better and that plausible ways to achieve these ends. 
(Or perhaps to consider if these ends are consistent with internet goals.)

I can't start that right this minute, but will post something before long.

	Thanks,
	Paul

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Thu, 15 Feb 2007 18:56:28 +0100

Hi Paul,

Thanks.  On ... "as representative of the intended usage by those asking
for service identification in SIP" .. Each community is made up of
participants, so of course I can't speak for everyone, but it gives at
least my understanding.  Maybe I have overlooked something -> for that,
time will tell.

BR,

..//Steve 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 5:40 PM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

Steve,

(Or perhaps to consider if these ends are consistent with internet
goals.)

I can't start that right this minute, but will post something before
long.

	Thanks,
	Paul

Stephen Terrill (MI/EEM) wrote:
> efficient use of resources in a resource constrained access network.  
> A further differentiation between them, is that some of the "sub
services"
> An example of another service is (Instant) messaging.  Instant 
> messaging may use MSRP to transfer text (e.g. "Hello") between users.

> However, MSRP may also be used in the context of other services, such 
> as telephony, or to transfer information from one device to another 
> device (e.g. address book information).
> 
> Another example could be a SIP push type of service.  A SIP push 
> service would be the ability to push e.g. data to a device.  The SIP 
> push may be just a simple MESSAGE message, or an INVITE; however it 
> should be distinguished from other uses of that as the information may

> not be destined for the end-user.  On top of that, then the exact 
> application to which the information is being pushed would be useful.
> 
> These examples of PoC - Telephony; Messaging - Telephony are examples 
> of different types of communication services where same media can be 
> used in different contexts.  I should note that the examples of PoC, 
> wrong with that?  It provides a good way to increase the possibility 
> of mxn interoperability by ensuring that clients will test against at 
> least those capabilities.
> 
> communication services, implies that "basic SIP communication" in 
> itself is monolithic service.  That can be quite OK in a small, or 
> controlled network, but I don't see that in a broader context, in 
> particular a multiservice network.  I would like to point out here, 
> that this does not imply anything relating to the implementation.  A 
> vendor can build the support for the different services out of a bunch

> of common components; and there is of course a great deal of 
> commonality that supports such re-use.
> 
> This leads me to my next topic, the example of a chess application 
> using the voice.  While being discredited by some people, I think it 
> does point out that that context where the media being used needs to 
> be understood by some applications.  You could as well take the same 
> example where the Chess application also established a separate 
> control channel between the two devices, but the rest of the 
> experience required was as per telephony.  In the 3GPP documentation, 
> there is a differentiation between a "Communication service" and an
"Application".
> having an application re-use another existing communication is not new

> - it has been used with e.g. SMS for a while, where the SMS 
> infrastructure has been used for delivering messages to the user, as 
> well as to the device.  We use it in IP all the time as well ;-)
> 
> The draft seems to have the implication that all services 
> (communication services in other terminology) that are to be 
> identified have to be standardised within the IETF.  This is clearly 
> an restriction that will not be acceptable to the industry as a whole.

> My guess is that if such a statement is mandated by the IETF, it will 
> just be words on paper which would likely be ignored in practice by 
> other standardisation organisations.
> 

> of the service is required.  I think it would also be good to allow 
> the case where knowledge of the service would be helpful, but not 
> explicitly required.  This could be a case where the service to the 
> end-user would not be degraded if this was not supported.  This 
> functionality seems to be missing.
> 
> The draft seems to indicate that that application servers in the 
> network are involved only at the request of the originating terminal.

> This seems a strange restriction.  For some network support that 
> supports the originating user, such as the one provided in the example

> "I would like this call recorded for later retrieval", such mechanisms

> may make sense, however as a general approach it seems a bit limited.

> For example, in 3GPP networks there is the need to invoke application 
> logic in the originating side and terminating side, not only at the 
> request of the originating terminal, but as a consequence of the 
> requested service.  If there is an SIP message contains indication of 
> the requested service, a proxy can do this (or loose route to an AS 
> that contains the necessary service logic).  I note here that the 
> proposed service URN does not contain the address of a specific server

> containing the application logic.  An AS can look at that, and loose 
> route to an application server that does contain such logic (If it is 
> separated from the proxy), however I fail to see the difference for 
> that proxy if it looks at a feature tag, or it looks at the service 
> URN for this.  In both cases, it has to parse the message for the 
> data, and modify the routing information.  Further, the route header 
> could be removed in the originating network; and it is still required 
> to identify the service in the terminating network.  As proxies may 
> remove the route, it can't be used to transport the requested service.

> From this perspective it is not clear to me the advantage of using a 
> service URN in a route header compared to the use of a feature tag.
> 
> necessary.  It seems strange to place such a dependency, it also 
> starts to move the GRUU as being the primary means of which to contact
a user.

> Parts of the draft seems to rely on the use of presence.  While 
> presence could be a supportive mechanism, I doubt that we can mandate 
> that the number you want to dial has be available in presence as I 
> assume not all entities are available in presence (diallable network 
> services, users in the PSTN).  This would be strange to mandated.
> 
> can't we expand the power of SDP".  Such an approach would mandate 
> that SIP methods use SDP, I don't think that is appropriate.
> 
> I hear the appeals that the mechanisms should not be abused, and that 
> we should not have 1000s of separate "communication services", and I 
> fully agree with this. I see a smaller number of communication 
> services, not a larger number; where those communication services are 
> used to access other end-user-services.
> 
> *flame away*
> 
> Regards,
> 
> Steve
> 
> ---
> 
> 

> the people here are
> net-heads) and the SIP systems that I've dealt with show no evidence 
> of needing "service identification", they're pure proxies, and 
> requests are passed transparently end-to-end.
> 

> is registered for the
> AOR.)  These URI-parameters can be formally or informally 
> standardized, or established ad-hoc by each user.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Feb 2007 20:48:24 -0500

I think its a fair point that the example is contrived. Really, the main 
use case being targeted is IMS PoC. So, let me talk a bit about that.

One would think that PoC is just a regular SIP call that has floor 
control added to it as another media type, and so one could indicate 
that a call is a PoC call just because of the presence of this new media 
type in the SDP. Sadly, I wish that were true. If it was, we would not 
need a mechanism here.

Unfortunately, PoC has layered a whole bunch of additional behaviors 
into the way SIP requests are handled. Dale has indicated one of them - 
that a 200 OK is returned on the terminating side priod to the call 
actually being completed. PoC also *requires* the insertion of servers 
into the SIP signaling path to make the system work. Consequently, 
though the messages that PoC uses *look* like SIP messages with a new 
media type, there is a hidden 'extension' in place that changes the 
fundamental semantics of INVITE. The fact that this extension is not 
visible as a specific header in a well defined way does not change the 
fact that PoC CHANGES THE BEHAVIOR OF SIP AND IS THUS A SIP EXTENSION.

To convince yourself of this, consider what would happen if a PoC client 
calls a regular SIP phone. The regular SIP phone would see the PoC floor 
control stream and reject it as unknown. If PoC were just SIP as we've 
specified it, then everything would be fine, and the call would proceed 
but without floor control.

But alas, it is not so.

Because PoC makes all kinds of assumptions about the behaviors of its 
participants, and what the real meaning is for various SIP messages, the 
entire thing just won't work when a call terminates on a non-PoC device. 
This is because PoC is, effectively, a fairly significant and 
non-backwards-compatible extension to SIP.

So, my proposal is, if you are going to go and DO something like that, 
you better use the SIP techniques that we've defined to deal with it. 
And when you extend SIP in a way that doesn't work with a SIP endpoint 
that doesn't understand an extension, you use a Require header. And that 
is exactly what I'm proposing that 3gpp should do. Use Require because 
you have made a non-backwards-compatible extension to SIP.

The general problem here is that there are other places where people are 
layering additional 'context', as Loreto has called it, ontop of SIP 
signaling. This is a worrisome trend because this context is subtle and 
not explicitly signaled. Its just assumed. And that is dangerous, since 
it leads to the kind of balkanization and non-interoperability that 
myself, Paul, Dale and others have complained about in this thread.

The current 3gpp specs, instead of using Require to signal this 
extension, put a tag into the Accept-Contact header field. I find this 
extremely worrisome, because it is really just masking the reality of 
what has happened. If you've got a situration where a SIP call *cannot 
be processed* without going through application servers, then this is 
not something that is signaled with Accept-Contact. Its signaled with 
Require or Proxy-Require as appropriate.

Thanks,
-Jonathan R.

Henning Schulzrinne wrote:

> bit peculiar, particularly since the example is rather contrived.  (Why 
> would you use voice, plus speech-to-text presumably, to talk to  a chess 
> application?)
> 
> In a networking sense, the issue seems to be that we're using voice  as 
> a transport protocol to carry different distinct applications. (In  the 
> old days, a modem would have been such an application.)
> 
> reasonable as "modern" replacements for tel URIs, essentially  extending 
> the concept of 800 numbers. But that's a different problem  from what I 
> understand this discussion to be about. (In that usage,  service URNs 
> would be mapped to SIP AORs based on geography, time-of- day and other 
> factors.)
> 
> Henning
> 
> 
>> "...chess game that utilizes voice commands to move pieces.  When  one 
>> player says "Queen to D7", the software on their phone  recognizes 
>> this and moves the piece.  At the same time, the user's  voice is sent 
>> to the other player, where it is both rendered to the  user, and 
>> interpreted locally in order to move the piece."
>> voice we want: a standard full-duplex or a PoC. Maybe the chess  game 
>> works well with, or it is designed for a standard audio but  not for a 
>> PoC audio. So we need to address also the voice  preference we want. I 
>> like your proposal, having something  hierarchical was something I was 
>> thinking too I don't know if it is  your idea, but with the service 
>> urn you are proposing:  Urn:service:voice.poc.chess I imaging you are 
>> asking to play a  Chess game, that work utilizing voice commands, but 
>> specifically  voice over PoC. This is also compliant to the 
>> draft-ietf-ecrit- service-urn (see section 3) "Declaration of 
>> syntactic structure:  The URN consists of a hierarchical service 
>> identifier, with a  sequence of labels separated by periods.  The 
>> left-most label is  the most significant one and is called 'top-level 
>> service', while  names to the right are called 'sub-services'.  The 
>> set of allowable  characters is the same as that for domain names [1] 
>> and a subset of  the labels allowed in [5].  Labels are 
>> case-insensitive and MUST be  specified in all lower-case.  For any 
>> given service URN, service- identifiers can be removed right-to-left 
>> and the resulting URN is  still valid, referring a more generic 
>> service.  In other words, if  a service 'x.y.z' exists, the URNs 'x' 
>> and 'x.y' are also valid  service URNs." Regards sal
>>> Hi Salvatore, As an end user, poc is also an application that I  use 
>>> and chess is also an application that I can use. The way I see  it, 
>>> in your example, it will be running chess application on top  of PoC 
>>> application. So the service urn for this would be something  like: 
>>> Urn:service:voice.poc.chess Regards, Ravi. -- Ravishankar.  G. 
>>> Shiroor Wipro Technologies, Bangalore.  [email-masked] 
>>> -- > -----Original Message----- >  From: Salvatore Loreto (JO/LMF) >  
>>> [email-masked]; > [email-masked] > Subject: RE:  [Sipping] 
>>> Service Identification in SIP > > hi Ravi, > > in IMS a  Service is a 
>>> "type of communication defined by a > service  definition that 
>>> specifies the rules and procedures > and allowed  media, if any, for 
>>> a specific type of > communication and that  utilises the IMS 
>>> enabler. An IMS > communication service defines  what is possible 
>>> within a > single SIP session or standalone  transaction." > So a 
>>> Service implies some combination of  capabilities and > ways to use 
>>> those capabilities. > If you want  the Service specifies the context 
>>> for a communication. > > Instead  the Application define the specific 
>>> communication (or > if you  want application) that you want run in 
>>> the specific > context. So  you should have several different 
>>> applications > designed to run  on a specific environment or that 
>>> have > different performance or  behavior in different context > 
>>> (running on top of different  service). > > Lets go to Jonathan's 
>>> example of the Chess. > In his  example the Chess is a service, for 
>>> IMS instead is an >  application that you can run on top of different 
>>> service. > For  example you can run Chess application on top of PoC > 
>>> service or  on top of the "standard" service. So let say you > run 
>>> Chess on  top of PoC service, then you can use only voice > in the 
>>> way that  PoC specifies. > > /sal > > > > > On Thu, 2007-02-01 at 
>>> 16:39  +0530, > [email-masked] wrote: > > Hello, > > > 
>>> Service Identification scope should be as per the > > requirement  in 
>>> Jonathan's draft, as I still do not > understand the need > >  for 
>>> having a Communication Service Identifier and another >  Application 
>>> > > Identifier as given in the 3gpp-ics-requirements  document. > > > 
>>> > Regards, > > Ravi. > > > > -- > > > >  Ravishankar. G. Shiroor > > 
>>> Wipro Technologies, Bangalore. > > > >  [email-masked] 
>>> > > -- > > > > > > > -----Original  Message----- > > > From: Gonzalo 
>>> Camarillo  [mailto:[email-masked]] > > > Sent: 
>>> Wednesday,  January 31, 2007 8:30 PM > > > To: sipping > > > Cc: Mary 
>>> Barnes >  > > Subject: [Sipping] Service Identification in SIP > > > 
>>> > > >  Folks, > > > > > > during the last year, there have been a 
>>> number  of threads on the > > > mailing list discussing service  
>>> http://www1.ietf.org/mail-archive/web/sipping/current/ msg10562.html 
>>> > > > > > > At a later point, those 3GPP  requirements were 
>>> documented in the > > > following (expired by  now) Internet Draft, 
>>> which was > presented in a > > > face-to-face  IETF meeting. > > > > 
>>> > > http://www.watersprings.org/pub/id/draft- loreto-sipping-3gpp-i > 
>>> > > cs-requirements-00.txt > > > > > >  Lately, the following draft 
>>> has been submitted to the archives: >  > > > > > 
>>> http://www.ietf.org/internet-drafts/draft-rosenberg- sipping-se > > > 
>>> rvice-identification-00.txt > > > > > > This  draft proposes a 
>>> solution that intends to meet known > > >  requirements in this area. 
>>> > > > > > > Given the amount of  discussions on issues related to 
>>> service > > > identification we  have seen during the last year, we > 
>>> believe this is > > > a  fairly important topic for the SIPPING WG to 
>>> tackle. At some > > >  point, we would like to have a milestone with 
>>> its > associated WG  item > > > dealing with this issue. > > > > > > 
>>> Therefore, we  would like to encourage people to read this > draft 
>>> and > > > send  comments to the list. Additionally, if you believe 
>>> that this > > >  work is (or is not) important, we would like to hear 
>>> that as well.  > > > > > > Cheers, > > > > > > Gonzalo > > > SIPPING 
>>> co-chair > >  > > > > > > > 
>>> _______________________________________________ > >  > 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 new developments of core  SIP > > > > > > > 
>>> _______________________________________________  > > Sipping mailing 
>>> list https://www1.ietf.org/mailman/listinfo/ sipping > > This list is 
>>> for NEW development of the application of  SIP Use > > 
>>> [email-masked] for questions on  current sip Use > 
>>> > [email-masked] for new developments of core SIP  > > The information 
>>> contained in this electronic message and any  attachments to this 
>>> message are intended for the exclusive use of  the addressee(s) and 
>>> may contain proprietary, confidential or  privileged information. If 
>>> you are not the intended recipient, you  should not disseminate, 
>>> distribute or copy this e-mail. Please  notify the sender immediately 
>>> and destroy all copies of this  message and any attachments. WARNING: 
>>> Computer viruses can be  transmitted via email. The recipient should 
>>> check this email and  any attachments for the presence of viruses. 
>>> The company accepts  no liability for any damage caused by any virus 
>>> transmitted by  this email. www.wipro.com
>>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Feb 2007 12:26:34 -0500

I think we're in general agreement; in particular, Require seems like  
the right approach. (service URNs do not, in my opinion).

Stepping back, I don't think we should generalize this problem since  
it essentially "blesses" a particular design approach that is  
undesirable. The right approach, from a SIP perspective, for IMS PoC  
would have been to come up with a solution that is backwards- 
compatible. If that's not possible, getting "branded" with Require  
seems like the right penalty.

In general, we have probably two requirements:

(1) When contacting an AOR, a UAC that needs a special UAS to work  
properly needs to get routed to that UAS only. Callee caps and caller  
preferences seem to be the right tools for that, as it involves call  
routing and capability matching.

(2) If, despite doing (1), a SIP request accidentally reaches a UAS  
that can't do anything useful with it, Requires minimizes the damage  
(and allows a proxy to serially-fork to something else that might  
have a chance of working).

Henning

On Feb 16, 2007, at 8:48 PM, Jonathan Rosenberg wrote:

> I think its a fair point that the example is contrived. Really, the  
> main use case being targeted is IMS PoC. So, let me talk a bit  
> about that.
>
> control added to it as another media type, and so one could  
> indicate that a call is a PoC call just because of the presence of  
> this new media type in the SDP. Sadly, I wish that were true. If it  
> was, we would not need a mechanism here.
>
> Unfortunately, PoC has layered a whole bunch of additional  
> behaviors into the way SIP requests are handled. Dale has indicated  
> one of them - that a 200 OK is returned on the terminating side  
> priod to the call actually being completed. PoC also *requires* the  
> insertion of servers into the SIP signaling path to make the system  
> work. Consequently, though the messages that PoC uses *look* like  
> SIP messages with a new media type, there is a hidden 'extension'  
> in place that changes the fundamental semantics of INVITE. The fact  
> that this extension is not visible as a specific header in a well  
> defined way does not change the fact that PoC CHANGES THE BEHAVIOR  
> OF SIP AND IS THUS A SIP EXTENSION.
>
> To convince yourself of this, consider what would happen if a PoC  
> client calls a regular SIP phone. The regular SIP phone would see  
> the PoC floor control stream and reject it as unknown. If PoC were  
> just SIP as we've specified it, then everything would be fine, and  
> the call would proceed but without floor control.
>
> But alas, it is not so.
>
> Because PoC makes all kinds of assumptions about the behaviors of  
> its participants, and what the real meaning is for various SIP  
> messages, the entire thing just won't work when a call terminates  
> on a non-PoC device. This is because PoC is, effectively, a fairly  
> significant and non-backwards-compatible extension to SIP.
>
> So, my proposal is, if you are going to go and DO something like  
> that, you better use the SIP techniques that we've defined to deal  
> with it. And when you extend SIP in a way that doesn't work with a  
> SIP endpoint that doesn't understand an extension, you use a  
> Require header. And that is exactly what I'm proposing that 3gpp  
> should do. Use Require because you have made a non-backwards- 
> compatible extension to SIP.
>
> The general problem here is that there are other places where  
> people are layering additional 'context', as Loreto has called it,  
> ontop of SIP signaling. This is a worrisome trend because this  
> context is subtle and not explicitly signaled. Its just assumed.  
> And that is dangerous, since it leads to the kind of balkanization  
> and non-interoperability that myself, Paul, Dale and others have  
> complained about in this thread.
>
> extension, put a tag into the Accept-Contact header field. I find  
> this extremely worrisome, because it is really just masking the  
> reality of what has happened. If you've got a situration where a  
> SIP call *cannot be processed* without going through application  
> servers, then this is not something that is signaled with Accept- 
> Contact. Its signaled with Require or Proxy-Require as appropriate.
>
> Thanks,
> -Jonathan R.
>

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 17 Feb 2007 21:21:52 +0200

> you have made a non-backwards-compatible extension to SIP.

i have said many times, let 3gpp people shoot their feet as long as they
don't bother ietf mailing lists with their incompatibilities.

-- juha

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sat, 17 Feb 2007 20:56:49 +0100

>From the proceedings of the IETF#67 for SIP:

"Consensus noted that we do need some sort of solution for the general  
problem of delivery of URI parameters across contact-routing
operations."

"Question: Adopt this draft as baseline text for a WG effort, should  
the ADs approve the milestone? Consensus to adopt noted by chairs. To- 
do: Chairs to work with AD to set new milestone."

Now I admit that the SIP chairs have been somewhat dilatory in updating
the milestones from the last meeting, but the proceedings went to the
list - and nobody said these were wrong.

Keith

> Sent: 13 February 2007 10:23
> To: [email-masked]

---

From: Göran Eriksson AP (KI/EAB)<[email-masked]>
Date: Sun, 18 Feb 2007 01:37:38 +0100

Jonathan,

You wrote:

	The general problem here is that there are other places where people are layering additional 'context', as Loreto 
	has called it, ontop of SIP signaling. This is a worrisome trend because this context is subtle and not explicitly signaled. 
	Its just assumed. And that is dangerous, since it leads to the kind of balkanization and non-interoperability that myself, 
	Paul, Dale and others have complained about in this thread.

I understand You to mean that what is worrisome is not that "people" thinks that handling "contexts" is needed but rather the way to do it.
Have I understood Your correctly?

I think this Service instance URI is a good idea; the URN I would like to understand the consequences of a bit better. The Service Id draft state that 
service URN's should be used for "well known services" and in the Service Id draft, "SMS" as a well known service- does this mean "SMS" must be defined
in a standard track RFC? 

Perhaps You could expand on this one a bit?

Finally, I would to say that I sympathize with the view that the PoC realisation on SIP is a very special case and would qualify for Require.

Thanks
-Göran

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: den 17 februari 2007 02:48
To: Henning Schulzrinne
Cc: sipping
Subject: Re: [Sipping] Service Identification in SIP

I think its a fair point that the example is contrived. Really, the main use case being targeted is IMS PoC. So, let me talk a bit about that.

One would think that PoC is just a regular SIP call that has floor control added to it as another media type, and so one could indicate that a call is a PoC call just because of the presence of this new media type in the SDP. Sadly, I wish that were true. If it was, we would not need a mechanism here.

Unfortunately, PoC has layered a whole bunch of additional behaviors into the way SIP requests are handled. Dale has indicated one of them - that a 200 OK is returned on the terminating side priod to the call actually being completed. PoC also *requires* the insertion of servers into the SIP signaling path to make the system work. Consequently, though the messages that PoC uses *look* like SIP messages with a new media type, there is a hidden 'extension' in place that changes the fundamental semantics of INVITE. The fact that this extension is not visible as a specific header in a well defined way does not change the fact that PoC CHANGES THE BEHAVIOR OF SIP AND IS THUS A SIP EXTENSION.

To convince yourself of this, consider what would happen if a PoC client calls a regular SIP phone. The regular SIP phone would see the PoC floor control stream and reject it as unknown. If PoC were just SIP as we've specified it, then everything would be fine, and the call would proceed but without floor control.

But alas, it is not so.

Because PoC makes all kinds of assumptions about the behaviors of its participants, and what the real meaning is for various SIP messages, the entire thing just won't work when a call terminates on a non-PoC device. 
This is because PoC is, effectively, a fairly significant and non-backwards-compatible extension to SIP.

So, my proposal is, if you are going to go and DO something like that, you better use the SIP techniques that we've defined to deal with it. 
And when you extend SIP in a way that doesn't work with a SIP endpoint that doesn't understand an extension, you use a Require header. And that is exactly what I'm proposing that 3gpp should do. Use Require because you have made a non-backwards-compatible extension to SIP.

The general problem here is that there are other places where people are layering additional 'context', as Loreto has called it, ontop of SIP signaling. This is a worrisome trend because this context is subtle and not explicitly signaled. Its just assumed. And that is dangerous, since it leads to the kind of balkanization and non-interoperability that myself, Paul, Dale and others have complained about in this thread.

The current 3gpp specs, instead of using Require to signal this extension, put a tag into the Accept-Contact header field. I find this extremely worrisome, because it is really just masking the reality of what has happened. If you've got a situration where a SIP call *cannot be processed* without going through application servers, then this is not something that is signaled with Accept-Contact. Its signaled with Require or Proxy-Require as appropriate.

Thanks,
-Jonathan R.

Henning Schulzrinne wrote:

> a chess
> day and other
>> if you consider the Jonathan draft, he says that "...chess game that 
>> works well with, or it is designed for a standard audio but  not for 
>> a PoC audio. So we need to address also the voice  preference we 
>> want. I like your proposal, having something  hierarchical was 
>> something I was thinking too I don't know if it is  your idea, but 
>> with the service urn you are proposing:  Urn:service:voice.poc.chess 
>> I imaging you are asking to play a  Chess game, that work utilizing 
>> voice commands, but specifically  voice over PoC. This is also 
>> compliant to the
>> and 'x.y' are also valid  service URNs." Regards sal On Fri, 
>> 2007-02-09 at 13:44 +0530, [email-masked]  wrote:
>>
>>> Service Identification in SIP > > hi Ravi, > > in IMS a  Service is 
>>> a "type of communication defined by a > service  definition that 
>>> for a communication. > > Instead  the Application define the 
>>> specific communication (or > if you  want application) that you want 
>>> run in the specific > context. So  you should have several different 
>>> IMS instead is an >  application that you can run on top of 
>>> different service. > For  example you can run Chess application on 
>>> top of PoC > service or  on top of the "standard" service. So let 
>>> say you > run Chess on  top of PoC service, then you can use only 
>>> voice > in the way that  PoC specifies. > > /sal > > > > > On Thu, 
>>> 2007-02-01 at
>>> 16:39  +0530, > [email-masked] wrote: > > Hello, > > 
>>> >
>>> > > Identifier as given in the 3gpp-ics-requirements  document. > > 
>>> > > >
>>> Wednesday,  January 31, 2007 8:30 PM > > > To: sipping > > > Cc: 
>>> Mary Barnes >  > > Subject: [Sipping] Service Identification in SIP 
>>> > > >
>>> > > http://www.watersprings.org/pub/id/draft- loreto-sipping-3gpp-i 
>>> http://www.ietf.org/internet-drafts/draft-rosenberg- sipping-se > > 
>>> service > > > identification we  have seen during the last year, we 
>>> > believe this is > > > a  fairly important topic for the SIPPING WG 
>>> to tackle. At some > > >  point, we would like to have a milestone 
>>> with its > associated WG  item > > > dealing with this issue. > > > 
>>> > > > Therefore, we  would like to encourage people to read this > 
>>> draft and > > > send  comments to the list. Additionally, if you 
>>> believe that this > > >  work is (or is not) important, we would 
>>> like to hear that as well.  > > > > > > Cheers, > > > > > > Gonzalo 
>>> > > > SIPPING co-chair > >  > > > > > > > 
>>> list https://www1.ietf.org/mailman/listinfo/ sipping > > This list 
>>> is for NEW development of the application of  SIP Use > > 
>>> immediately and destroy all copies of this  message and any attachments. WARNING:

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 19 Feb 2007 07:03:50 +0100

Hi Jonathan, 

>If you've got a situration where a SIP call *cannot be processed*
without 
>going through application servers, then this is not something 
>that is signaled with Accept-Contact. Its signaled with 

Just for my clarification, where is it said that Require and
Proxy-Require are used, or at least more appropriate, for routing? 

As far as I know, they are only used to require capabilities by the
nodes that receive a SIP request (as you said yourself earlier) - but
not to make routing decissions based upon.

Regards,

Christer

> utilizing 
>  [Sipping] 
> >>> voice > in the way that  PoC specifies. > > /sal > > > > 
> > On Thu, 
> >>> 2007-02-01 at
> should > be
> msg10562.html
> sipping-se > > 
> >>> like to hear that as well.  > > > > > > Cheers, > > > > > 
> > Gonzalo 
> Sipping mailing

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 19 Feb 2007 12:07:21 +0100

Hi,

Besides the discussion that PoC is "only the addition of floor control"
as there is more to it than that ...  The idea of being able to use a
Require header for some applications is not bad(though should not be
mandeated, i.e it should be possible to not use it as well while still
identifying the service).  I think that the implication that the use of
the the requires header then requires that the related specification
activity is constrained to the IETF is problematic for other forums - is
there a way around that?

Best Regards,

Steve.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, February 17, 2007 2:48 AM
To: Henning Schulzrinne
Cc: sipping
Subject: Re: [Sipping] Service Identification in SIP

But alas, it is not so.

Thanks,
-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 19 Feb 2007 09:06:27 -0500

RFC 3840, Section 10.15 ("Extensions") would be the mechanism to  
route according to capabilities.

---

From: [email-masked]
Date: Tue, 20 Feb 2007 14:00:23 -0500

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>

And it seems to me that the ability to indicate support of a feature,
but not mandatory use, would greatly help prevent the "silo-ization"
problem.

   From: Jonathan Rosenberg <[email-masked]>

   But alas, it is not so.

But why is it not so?  OK, I know nothing about PoC, but naively it
seems that a PoC [here I assume that PoC means "push-to-talk over
cellular"] UAC, if it did not see an immediate 200 would know that the
far end did not support PoC functionality and could fall back to
acting like an ordinary UAC.  (Indeed, it could quickly warn the user
that PoC is not in effect by playing a ring tone!)

Assuming that SIP-based PoC was designed with upward-compatibility in
mind, a PoC UA could reliably determine whether the far end supported
PoC on a call-by-call basis.

OTOH, if PoC changes the meanings of SIP messages so much that,
without a specified service context, they cannot be interpreted enough
to determine if PoC is in effect or not, um, well, what *were* they
thinking when they designed it?  And why haven't they fixed it?

Now, I suspect I've just revealed a large gap in my knowledge, but I
suspect that many other readers have the same gap, and it would
advance the discussion if you could reduce our ignorance.

   From: Henning Schulzrinne <[email-masked]>

   A robust and distributed allocation mechanism for identifiers makes
   sense if you expect hundreds of entities to independently need to
   allocate such identifiers. This is clearly undesirable in this
   case, based on the examples presented, so the IANA registration
   mechanism for Require tags seems to be both sufficient and
   sufficiently onerous to prevent gratuitous incompatibility.

Naively, it seems that having more than a few defined services would
be useless in regard to the business of the cellular industry, as it
would balkanize the cellular PSTN, and customers would fall back to
using only the simplest modes of operation.

Dale

---

From: [email-masked]
Date: Tue, 20 Feb 2007 14:01:26 -0500

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

Surely a proxy can make routing decisions based upon Require if it
desires to.

Dale

---

From: Eric Burger <[email-masked]>
Date: Wed, 21 Feb 2007 10:29:27 -0800

How about this as a different way of saying "+1":

If PoC is broken, why are we breaking SIP to fix it?

On 2/17/07 12:26 PM, "Henning Schulzrinne" <[email-masked]> wrote:

>> indicate that a call is a PoC call just because of the presFrom [email-masked] Wed Feb 21 16:57:50 2007
Date: Wed, 21 Feb 2007 10:29:27 -0800
Subject: Re: [Sipping] Service Identification in SIP
From: Eric Burger <[email-masked]>
To: Henning Schulzrinne <[email-masked]>,
	Jonathan Rosenberg <[email-masked]>
Cc: sipping <[email-masked]>

How about this as a different way of saying "+1":

If PoC is broken, why are we breaking SIP to fix it?

>> Henning Schulzrinne wrote:

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

Use sip@ence of
>> Henning Schulzrinne wrote:

_______________________________________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Feb 2007 16:34:07 -0600

Jonathan,

You've got it all wrong. 

PoC is not a non-backwards-compatable extension to SIP, it's a backwards
non-compatable extension to SIP.

The introduction of functions within the IMS architecture that
differentiate and interwork between 3GPP IMS SIP and IETF SIP (being
that, last I checked SIP was still an IETF RFC) at peering points shows
(to me) that solving IMS problems using the mechanisms that already
exist in IETF drafts (although the solution may not be apparent at the
time) is not always a top priority for a variety of reasons. 

A commonly heard complaint/stated reason for this is the lack of the
IETF working groups to meet the milestones for solutions set by 3GPP. 

Since we not only must agree upon a technical solution, but find it
desirable to convince 3GPP and others to use the solution recommended by
the IETF; getting agreement on producing a stable, referencable document
within the IETF within the 3GPP R7 timeline is critical. Otherwise, R7
will go out the door with what it has today for service identification,
and we'll wind up with an even bigger mess on our hands.

Regards,
Brian

> Sent: Friday, February 16, 2007 7:48 PM
> To: Henning Schulzrinne
> Cc: sipping
> I think its a fair point that the example is contrived. 
> Really, the main use case being targeted is IMS PoC. So, let 
> me talk a bit about that.
> 
[SNIP]
> 
> But alas, it is not so.
> 
> Because PoC makes all kinds of assumptions about the 
> behaviors of its participants, and what the real meaning is 
> for various SIP messages, the entire thing just won't work 
> when a call terminates on a non-PoC device.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 22 Feb 2007 14:21:08 +0100

Hi Henning, 

>RFC 3840, Section 10.15 ("Extensions") would be the mechanism to route
according to capabilities.

I am not sure how that answers my question. Could you please clarify?

Regards,

Christer

> >> going through application servers, then this is not 
> something that is 
> >> signaled with Accept-Contact. Its signaled with Require or 
> >> Proxy-Require as appropriate.
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Feb 2007 08:33:51 -0500

Proxies can choose next hops based on RFC 3840, which is another way  
of saying "routing".

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 22 Feb 2007 16:05:27 +0100

Hi,

I am sure a proxy can make routing decissions based on whatever.

My question was simply where it is said that Require/Proxy-Require is
more appropriate.

Regards,

Christer 

> Sent: 20. helmikuuta 2007 21:01
> To: [email-masked]
> Subject: Re: [Sipping] Service Identification in SIP - 
> Routing decissionsbased on Require/P-R
> 
> Surely a proxy can make routing decisions based upon Require 
> if it desires to.
> 
> Dale
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 22 Feb 2007 16:10:42 +0100

Hi, 

>Proxies can choose next hops based on RFC 3840, which is another way of
saying "routing".

Yes. But, where in RFC 3840 is it mentioned that the routing is based on
the Require/Proxy-Require header?

Regards,

Christer

---

From: [email-masked]
Date: Thu, 22 Feb 2007 10:20:01 -0500

More appropriate than what?

Dale

---

From: [email-masked]
Date: Thu, 22 Feb 2007 10:34:58 -0500

RFC 3261 allows a proxy unlimited latitude in choosing targets to
which to forward a request, if the proxy is authoritative for the
request-URI:

"[T]he element is responsible for the domain in the Request-URI, and
the element MAY use whatever mechanism it desires to determine where
to send the request."

Within that framework, it seems to me quite reasonable for a service
provider's proxy to examine Require or Proxy-Require headers to
determine which application server would be best for handling a call,
and routing the call to it.

Dale

---

From: [email-masked]
Date: Thu, 22 Feb 2007 10:53:14 -0500

From: "Brian Stucker" <[email-masked]>

   Since we not only must agree upon a technical solution, but find it
   desirable to convince 3GPP and others to use the solution
   recommended by the IETF; getting agreement on producing a stable,
   referencable document within the IETF within the 3GPP R7 timeline
   is critical. Otherwise, R7 will go out the door with what it has
   today for service identification, and we'll wind up with an even
   bigger mess on our hands.

That is a problem.

But on the other hand, OSI and SS7 didn't have any IETF input, and
that hasn't delayed the growth of the Internet.

And it seems the cellular industry devised some sort of PoC-using-SIP
without worrying about upward-compatibility with pre-existing SIP.
They can reasonably complain that the IETF wouldn't or couldn't get
PoC standardized in time for their business needs, but in the face of
the fact that they designed a solution that violates the fundamental
principles of good protocol design, they can't complain that the IETF
isn't interested in it.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Feb 2007 11:12:39 -0500

I think two different things have been confused in this discussion.

1) AFAIK, *any* proxy is free to look at the Require header, and
    use that to choose a next hop proxy.

    (A proxy that is responsible for the domain of the R-URI *could*
    use such logic to choose a translation for the R-URI, though I
    think that would be an unusual thing to do.)

2) RFC 3840 defines the "extensions" feature tag that allows a
    UAS to declare a capability for an extension when registering.
    If this is done, it in effect says: "a request containing
    a Require header with this extension will be accepted if sent
    to this contact address."

    Requests addressed to an AOR can express a preference for a
    UAS that has indicated a capability for an extension. Or it can
    reject contacts that haven't indicated that capability. And of
    course the request could also contain a Require for the same
    capability. This can be used to avoid delivering a request to
    a UAS that doesn't support a required extension.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 23 Feb 2007 12:29:32 +0100

Hi, 

>>My question was simply where it is said that 
>>Require/Proxy-Require is more appropriate.
> 

Accept-Contact, for example.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 23 Feb 2007 12:29:36 +0100

Hi, 

> Sent: 22. helmikuuta 2007 17:35
> To: [email-masked]
> RFC 3261 allows a proxy unlimited latitude in choosing 
> targets to which to forward a request, if the proxy is 
> authoritative for the
> request-URI:
> 
> "[T]he element is responsible for the domain in the 
> Request-URI, and the element MAY use whatever mechanism it 
> desires to determine where to send the request."
> 
> Within that framework, it seems to me quite reasonable for a 
> service provider's proxy to examine Require or Proxy-Require 
> headers to determine which application server would be best 
> for handling a call, and routing the call to it.

Why can't Accept-Contact be used for the same purpose?

My issue is the statement that Require/Proxy-Require is the most
appropriate way of doing the routing decisson, and I am wondering where
that is specified.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Feb 2007 08:07:35 -0500

The difference here is that the Require header is definitive that the 
caller doesn't want to reach a UAS unless that UAS supports the stated 
options. Callerprefs is not so definitive. There are some uses of 
callerprefs that can be considered fairly definitive, but in general 
that is not the case.

Jonathan proposed extending 3841 so that the use of Require generates an 
implicit callerpref. And that in turn would influence the selection of 
the registered contacts to try. I can't see a plausible way to infer any 
implicit callerpref from Accept-Contact headers.

In any case, that is all about selecting how to translate the R-URI. It 
is not about selecting intermediate proxies. As Dale has stated, you are 
free to use most anything to select an intermediate proxy. If you want 
to use Require, or Accept-Contact to do that you may do so. But while 
you are free to do so, it is less clear that it is useful or wise to do 
so. If the intent is to select a proxy that is consistent with the 
capabilities of the UAS that will eventually be accepted (as seems to be 
the case with PoC), then it only makes sense if the thing you are 
testing is definitive for the capabilities of the UAS. So again, Require 
may make sense for this, while Accept-Contact is not.

	Paul

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 23 Feb 2007 07:21:07 -0600

Hi, Christer,

I may be misunderstanding the point, but I thought the topic under 
discussion was not general proxy routing, but proxy routing for calls that 
could not be handled correctly without special knowledge - for example, 
PTT/POC.

In this case, Require/Proxy-Require seems appropriate, because the proxy 
really is "required" to do something, or the INVITE will either fail or 
succeed resulting in some strange and unusable state.

Thanks,

Spencer

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, February 23, 2007 5:29 AM
Subject: RE: [Sipping] Service Identification in SIP - Routing 
decissionsbasedon Require/P-R

Hi,

Regards,

Christer

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 23 Feb 2007 07:22:56 -0600

Hi, Paul,

What I was trying to say, but clearer than my attempt. Thanks.

Spencer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 23 Feb 2007 15:37:50 +0100

Hi,

>The difference here is that the Require header is definitive 
>that the caller doesn't want to reach a UAS unless that UAS 
>supports the stated options. Callerprefs is not so 
>definitive. There are some uses of callerprefs that can be 
>considered fairly definitive, but in general that is not the case.
> 
>Jonathan proposed extending 3841 so that the use of Require 
>generates an implicit callerpref. And that in turn would 
>influence the selection of the registered contacts to try. I 
>can't see a plausible way to infer any implicit callerpref 
>from Accept-Contact headers.
> 
>In any case, that is all about selecting how to translate the 
>R-URI. It is not about selecting intermediate proxies. As 
>Dale has stated, you are free to use most anything to select 
>an intermediate proxy. If you want to use Require, or 
>Accept-Contact to do that you may do so. But while you are 
>free to do so, it is less clear that it is useful or wise to 
>do so. If the intent is to select a proxy that is consistent 
>with the capabilities of the UAS that will eventually be 
>accepted (as seems to be the case with PoC), then it only 
>makes sense if the thing you are testing is definitive for 
>the capabilities of the UAS. So again, Require may make sense 
>for this, while Accept-Contact is not.

Don't you get the same effect by including explicit require in the
Accept-Contact and adding "pref" to the Require Header? 

Regards,

Christer

> >> Subject: Re: [Sipping] Service Identification in SIP - Routing 
> >> decissionsbased on Require/P-R
> >>
> >>    Proxies can choose next hops based on RFC 3840, which 
> is another 
> >> way
> >>    of saying "routing".
> >>
> Request-URI, and 
> > appropriate way of doing the routing decisson, and I am wondering 
> > where that is specified.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> >> Dale
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Feb 2007 09:45:32 -0500

Some further thoughts on this subject:

Typically, some of the capabilities used in a call are *negotiated* 
between the caller and the callee. As a result, those that will be used 
are not known for certain at the time the request is sent. And the 
results of that negotiation may differ depending on which of various 
candidate targets is selected.

Apparently one key intended use of the service id is to bring in one or 
more intermediate nodes that are specific to the capabilities that will 
be used in the call. These intermediate nodes must be selected *before* 
the UAS is selected and the negotiation is done. For that to work, one 
of two things must happen:

- the proxy that selects those intermediate nodes
   must be prescient about what capabilities will be negotiated

- or the selection of UAS and the negotiation of capabilities to be
   used must be somehow constrained to be consistent with the
   capabilities supported by the selected intermediate nodes.

If we agree that prescience is infeasible, I guess we must assume that 
the selection and negotiation will be constrained. We of course have a 
mechanism for that: it is the Require header. There are also other 
mechanisms that provide constraints of some sort. For instance the SDP 
offer constrains what is permitted in the answer. (It does *not* however 
constrain subsequent offers and answers in the same session.)

If the request is already sufficiently constraining for the purposes of 
the intermediate nodes then nothing more need be done. But if the 
request isn't sufficiently constraining, then the intermediate node 
ought to add a constraint to the request, to ensure its requirements are 
satisfied. E.g. it could add a Require header to the request. Or, if it 
is a B2BUA, it might adjust the offer in the request to be suitably 
restrictive.

How does all this relate to the discussion?

If the service id is indicated by an Accept-Contact, then it is not in 
general definitive for what capabilities will eventually be used in a 
call. (This is true because honoring of callerprefs by proxies is 
*optional*, and because in general callerprefs involves the 
*prioritzation* of contacts rather than being a strict acceptance test.

If the Accept-Contact is used to select an intermediate node that makes 
some assumptions about the nature of the resulting call, then it needs 
to somehow ensure that the UAS ultimately selected will be consistent 
with those assumptions. It will need to use something other than 
Accept-Contact to do that. So at a minimum A-C is not a complete 
solution to this problem.

	Paul

Paul Kyzivat wrote:
>>> From: [email-masked] [mailto:[email-masked]] Sent: 
>>> 22. helmikuuta 2007 17:35
>>> To: [email-masked]
>>>    Proxies can choose next hops based on RFC 3840, which is another 
>>> way     of saying "routing".
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Feb 2007 10:16:52 -0500

> Accept-Contact and adding "pref" to the Require Header? 

Not quite.

Require applies to the UAS, not proxies. Proxy-Require:pref would be 
closer. But Proxy-Require:pref only requires that the proxy *understand* 
callerprefs. It can still ignore those preferences based on its own 
policy. And it requires that *all* the proxies on the path understand 
callerprefs, not just the one that is responsible for the domain of the 
R-URI, where the preferences should be acted upon.

	Paul

---

From: [email-masked]
Date: Sat, 24 Feb 2007 08:09:16 -0500

Well, it isn't going to be *specified* anywhere, it can only arise as
an implication based on examining the implementation mechanisms we
have at our disposal.

In regard to this sort of routing, my impression from what others have
said is that Accept-Contact (or "callerprefs") is advisory, that a
proxy is allowed to disregard its statements based on local policy,
whereas Require is mandatory (though it is in principle implemented
only at the destination UA, and ignored by proxies).

So from the point of view of the semantics alone, Require is closer to
what we want.

Of course, Proxy-Require is Not A Good Idea, because it requires that
all intermediate proxies believe that they understand the extension,
and (assuming that the service is implemented in a way that does not
require special service in the truly WAN link), that is not what we
want.

And of course, a proxy at the destination domain is free to examine
the Require header and omit forwarding the request to UAs that it
*knows* do not support the requested extension, as the UAC can not
discover that such a shortcut has been taken.

But the discussion is rather academic -- In an IMS-like architecture,
the proxies in the destination domain, the application servers, and
the UA aren't really true SIP agents in the way that proxies and UAs
are in a more decentralized system.  Rather, all those agents
cooperate to produce the appearance of a SIP UA to any external
observer.  So all those agents have a great deal of latitude in
exactly how they use SIP, as long as the overall effect is
standard-compliant.

Dale

---

From: [email-masked]
Date: Sun, 25 Feb 2007 09:57:25 -0500

I can't see a plausible way to infer any implicit callerpref from
   Accept-Contact headers.

Am I missing something?  I thought that Accept-Contact *was*
"callerpref".

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Feb 2007 21:30:31 -0500

> Am I missing something?  I thought that Accept-Contact *was*

What *was* I thinking? I clearly didn't say what I meant. :-(

The context was making a routing decision to an application server. What 
I *meant* to say was that I can't see any plausible way to make a 
selection of an application server based on an Accept-Contact header, 
because that isn't definitive for the capabilities of the UAS that will 
be selected. That is in contrast to the Require header, which is 
definitive, so using it to select an application server is plausible.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 26 Feb 2007 09:40:21 +0100

Hi, 

> >> caller doesn't want to reach a UAS unless that UAS supports the 
> >> stated options. Callerprefs is not so definitive. There 
> are some uses 
> >> of callerprefs that can be considered fairly definitive, but in 
> >> general that is not the case.
> >>
> >>generates an implicit callerpref. And that in turn would  influence 
> >>the selection of the registered contacts to try. I  can't see a 
> >>plausible way to infer any implicit callerpref from Accept-Contact 
> >>headers.
> >> In any case, that is all about selecting how to translate 
> the  R-URI. 
> >>It is not about selecting intermediate proxies. As  Dale 
> has stated, 
> >>you are free to use most anything to select  an 
> intermediate proxy. If 
> >>you want to use Require, or  Accept-Contact to do that you 
> may do so. 
> >>But while you are  free to do so, it is less clear that it 
> is useful 
> >>or wise to  do so. If the intent is to select a proxy that is 
> >>consistent  with the capabilities of the UAS that will 
> eventually be  
> makes sense 
> >>if the thing you are testing is definitive for  the capabilities of 
> >>the UAS. So again, Require may make sense  for this, while 
> >>Accept-Contact is not.
> > 
>Require applies to the UAS, not proxies. Proxy-Require:pref 
>would be closer. But Proxy-Require:pref only requires that 
>the proxy *understand* callerprefs. It can still ignore those 
>preferences based on its own policy. And it requires that 
>*all* the proxies on the path understand callerprefs, not 
>just the one that is responsible for the domain of the R-URI, 
>where the preferences should be acted upon.

No matter if you use "Require:service-X" or "Require:pref", the proxy is
not requierd to understand the extension as such.

In both cases the proxy simply performs routing based on the value (in
the "pref" case it also looks at the Accept-Contact).

I do agree that Proxy-Require is not good. It would be good to point
Proxy-Require to specific proxies (as we noted also in the outbound
discussion), but unfortunately that is not possible.

Regards,

Christer

> targets to