Subject: RE: [Sipping] Service Identification in SIP

From: "Andrew Allen" <[email-masked]>
Date: Thu, 15 Feb 2007 18:35:51 -0500

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.

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.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Feb 2007 20:41:21 -0500

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

But I agree with what Andrew says below.

	Paul

---

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

> email server not directly to the other email client.

I am convincing myself that a good way to interpret service, or if you
want "communication service" (in 3GPP terminology) is just as a context 
for the communication. 
So a Communication Service Identifier should not override or hide the
media capabilities but just specify the context or better the preferred
context where the user would like use them.
Whatever will be the mechanism will be chosen, I really think it should
possible for the user for example ask

About the discussion below, I want clarify my opinion, I am not
religiously for CallPref and for the way 3GPP is going to use it.
I share the same concern about the interoperability, and I agree with
Andrew about the interest and the opportunity for both 3GPP and Internet

My intent is just to understand better all the technical aspects.
For example I am curios about the possibility highlighted by Paul
previously in this same thread of considering the ASs as a First class
UASs and using call-pref to select them.

At same time I am also curious about the mechanism proposed by Jonathan.
It is an interesting proposal, but to tell you the truth, 
at the present stage in both the proposal call-pref and Jonathan
mechanism I can identify more or less the same number of issues that
need a lot of discussion and work before reach a robust stage.
For example the Jonathan proposal is based on the louse routing that is
something that has not yet reached a large consensus in the sip
community, and also the re-ordering is something that need a lot of work
and clarification. But as I said it is an interesting proposal.

/sal

> From: Salvatore Loreo (JO/LMF) [mailto:[email-masked]]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 10:36:40 -0500

one clarification in line:

> and clarification. But as I said it is an interesting proposal.

The UA loose routing is there for the following reason. Lets say user B 
publishes a presence document with PoC and telephony, and includes a 
different URI for each. When user A gets that presence document and 
invokes the PoC URI, it would be helpful for user B to know, when it got 
the request, that this URI was used. Loose routing accomplishes that.

Note that the request would still contain Require, since the originating 
app was PoC and will need to include Require since PoC is not backwards 
compatible.

In the absence of loose routing, an IMS endpoint could continue to use 
P-Called-Party-ID and have the same result.

So the loose routing bit is really orthogonal here to the rest of it. 
I'd be fine to reword it to point to loose route or other equivalent 
mechanisms so that there was not a direct dependency.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com