Subject: RE: [Sipping] Service Identification in SIP

From: "Andrew Allen" <[email-masked]>
Date: Thu, 15 Feb 2007 23:43:20 -0500

Paul

Comments inline

Andrew 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, February 15, 2007 8:41 PM
To: Andrew Allen
Cc: Salvatore Loreto (JO/LMF); [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

Andrew Allen wrote:
> I agree with Salvatore that IM is a better example of where service 
> identification may have a role in expressing a preference for a 
> particular application. Certainly there are different emoticons and 
> other value added features proprietary to different messaging 
> applications so having the ability to express preferences to use a 
> preferred application seems to me to have value. I think that email is

> a bad counter example as with email the email client interfaces to the

> email server not directly to the other email client.

If the kind of usage above were to take hold in any significant way, it
would be a huge step towards balkanizing the internet. Part of agreeing
on a common protocol is actually supporting interoperation.

[AA] My thinking is the opposite. Currently today with several non
interoperable proprietary IM systems we have balkanizing of the
internet. SIMPLE hopefully will lead to inteoperable IM systems however
I think it likely that many of these different systems will still retain
some proprietary value added features even when they have
inteoperability for basic messaging exchange. Having the ability to
express a preference for an application that supports the same value
added features I think aids inteoperability and removes an excuse for
maintaining a totally proprietary non inteoperable system.

But I agree with what Andrew says below.

	Paul

> Where I disagree with Salvatore is that the fact that the use of 
> callerprefs doesn't support well, if at all, the inclusion of 
> intermediate servers into the call path is not a problem for 3GPP as 
> well. From my viewpoint 3GPP needs to make use of Callerprefs in the 
> same way as was intended in RFC 3840/3841 and not extend this with an 
> entire bunch of semantics that were not defined for Accept-Contact. To

> do otherwise is only likely to create problems with services that work

> in the internet but do not work with mobile and other devices in IMS 
> networks. Also service identification needs to work in both IMS 
> networks and non-IMS networks so that the the same services can be 
> deployed in both environments. The fact that IMS filter criteria 
> enables routing on just about anything (Using iFC I could route based 
> on my favourite number appearing in a Call-ID or Cseq etc) doesn't 
> mean that it's Ok or a good idea to simply add a new token anywhere 
> you can and route based on that. Services should not depend on the use

> of filter criteria and the IMS architecture and routing decisions 
> should be based on the SIP routing mechanisms that use the contents of

> the Route header and Request-URI for routing decisions. IMHO 
> Accept-Contact is not a routing header per say but simply allows a 
> filter to be specified that filters the list of registered contacts in

> order to determine which contacts of the AOR to fork the request to. 
> Building additional semantics on top of this filter potentially 
> significantly restricts the use of this filter mechanism as originally
intended.
> 
> I think it is in the interest of both 3GPP and the internet that a 
> general mechanism that works also in a pure SIP environment is 
> developed.
> 
> Andrew
> 
> 
> -----Original Message-----
> From: Salvatore Loreto (JO/LMF) [mailto:[email-masked]]
> Sent: Friday, February 09, 2007 9:39 AM
> To: Paul Kyzivat
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] Service Identification in SIP
> 
> 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
> 
> 
> 
> 
> 
> 
> On Fri, 2007-02-09 at 08:26 -0500, Paul Kyzivat wrote:
>> [email-masked] wrote:
>>> 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.
>> 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
>>
>>> Regards,
>>> Ravi.
>>>
>>>
>>> --
>>>  
>>> Ravishankar. G. Shiroor
>>> Wipro Technologies, Bangalore.
>>>  
>>> [email-masked]
>>> --
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:[email-masked]]
>>>> Sent: Wednesday, February 07, 2007 10:43 PM
>>>> To: Salvatore Loreto (JO/LMF)
>>>> Cc: RaviShankar Shiroor (WT01 - Product Engineering Solutions); 
>>>> [email-masked]; [email-masked]; 
>>>> [email-masked]
>>>> Subject: Re: [Sipping] Service Identification in SIP
>>>>
>>>> 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
>>>>
>>>> Salvatore Loreto (JO/LMF) wrote:
>>>>> 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
>>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>>
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.

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

_______________________________________________
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: "Andrew Allen" <[email-masked]>
Date: Wed, 21 Feb 2007 22:12:36 -0500

Steve, Spencer

There is nothing that prevents operators from agreeing to use the same
identifiers for the same or similar services in their networks. However
the technical solution should not impose that as a constraint.

Andrew 

-----Original Message-----
From: Stephen Terrill (MI/EEM) [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 8:49 AM
To: [email-masked]
Subject: RE: [Sipping] Service Identification in SIP

Hi Spencer,

I was a little suprised to understand that this was a difference of view
on this point.  Maybe it is confusing a little the User interface from
the "communication service" being identified.  In my understanding,
however, it is the same service identifer that should be used in the
originating network and terminating network - and indeed there was a
liaison from an operator community that see that want to use this for
identifiying the requested service between operators as well.  Of
course, nothing can prevent an operator from
inteworking/upgrading/downgrading in their own network ...

Best Regards,

Steve.

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 2:33 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

Hi, Steve,

The distinction you're making here seems to capture the the biggest
question - are we expecting service identifiers to be end-to-end, if not
interworked, or are we expecting them to be different for the same
service in originating and terminating networks.

Thanks,

Spencer

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

Hi Andrew,

I see that in your assumptions, the originating and terminating networks
use different service identifiers, and I presume that this is for the
same service.  In my understanding, it is the same service identifier
that is used end-to-end (if not it is interworked).  That is why I do
not see the reliance on Presence being necessary.  In my opionion this
totally within the requirements of TS 23.228 (I think that different
service identifiers in different networks for the same service is
against TS 23.228).

---

From: "Andrew Allen" <[email-masked]>
Date: Wed, 21 Feb 2007 23:47:55 -0500

Dale,

PoC is a not simply a peer to peer protocol. It is very network server
centric with a network PTT Server that controls the floor for the
clients using a proprietary media control protocol that uses on RTCP.
The PTT server acts as master in a master-slave relationship with the
client. PoC sessions can be established with two or more PTT Servers in
the path of the signaling. 

PTT also has a particular user experience because it mimics the half
duplex walkie talkie radio experience. The user pushes a button and
expects to be connected to the called party and then speak almost
immediately. Negotiating "down" to a regular full duplex VoIP call
without floor control would be completely unexpected. There are even
optimizations that grant the caller the right to speak before the called
party has answered in order to provide the user that almost
instantaneous Push Talk experience.

Some more information on some of this can be obtained by reading:

http://www.ietf.org/internet-drafts/draft-allen-sipping-poc-p-answer-sta
te-header-04.txt

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 2:00 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification in SIP

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

   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.

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

   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.

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