RE: [Sipping] Service Identification in SIP

["Henry Sinnreich" <[e-mail]>]

Andrew,

It is interesting to note that there is similar thinking going on in
other WGs, see for example:

http://www.ietf.org/internet-drafts/draft-fairhurst-dccp-serv-codes-02.t
xt 

and

http://www.ietf.org/internet-drafts/draft-andreasen-sipping-rfc3603bis-0
2.txt 

Along with your correct observation:

> with an increasing number of competing service providers in the market

 One has to wonder about the scalability and complexity all levels of
defining so many services for so many providers, not only for SIP but
also in the transport area. 

Coming back to scalability, even plain services could have promotions,
coupons "free video for frequent flyers", etc. that interestingly enough
may not be a good idea to trumpet to the competition or get the
agreement first from the competition. Perish the thought...

It is also correct that 

> this argument will be settled by market competition and is not really 
> the role of engineering to settle.  

Internet engineers may however share the discomfort that service
identification facilitates the following on the Internet:

- Possible discrimination of unwanted services by the competition,
- Restricting the freedom of development for edge devices and apps,
- Charging for the two above, to top it off.

Thanks again to all for the thoughtful contributions to this discussion.

Henry


-----Original Message-----
From: Andrew Allen [mailto:[e-mail]] 
Sent: Thursday, February 15, 2007 2:17 PM
To: Henry Sinnreich; Paul Kyzivat; Salvatore Loreto (JO/LMF)
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]; Andrew Allen
Subject: RE: [Sipping] Service Identification in SIP


 
IN response to Henry:

RFC 4485 also states:

   Session initiation also depends on the ability of the called party to
   have enough information about the session itself to make a decision
   on whether to join.  That information includes data about the caller,
   the purpose for the invitation, and parameters of the session itself.
   For this reason, SIP includes this kind of information.

IMHO "the purpose for the invitation" also includes information about
what type of service or application this session initiation request is
related to and SDP doesn't provide sufficent information to definitively
determine this.

I think we can all debate the advantages and disadvantages of building
intelligence in the network as opposed to distributing it to the
endpoints and I feel that I am also generally on the distributed side of
that particular argument however SIP allows for both models and many
services/applications utilise both intelligence in the endpoint and
intelligence in Application Servers in the network. A prime example is
Presence where Presence can be provided with SIP using only SIP
endpoints however many practical implementations make use of network
based Presence Servers and Resource List Servers in order to create a
scalable Presence Service and significant IETF work has been done on
creating SIP based and other related mechanisms (e.g XCAP) to support
Presence using Presence Servers and Resource List Servers. Being purist
philosophical about moving all intelligence to the very edge doesn't
always result in the most optimal solution as the scalability advantages
of having all the intelligence in the endpoints has to be considered
along with the scalability disadvantages of having all the signalling
transported to the endpoints. In limited and high cost bandwidth access
networks like cellular the scalability disadvantages of having all
signaling transported to the endpoint can sometimes outweigh the
advantages of distributed intelligence. 

My understanding is that SIP doesn't take any position on the business
models used for communication service provision and IETF has been
cooperating closely with those who are using SIP for carrier based
services. Some people may not think that the carrier centric service
model is the way to go in the future but with an increasing number of
competing service providers in the market this argument will be settled
by market competition and is not really the role of engineering to
settle. 

Also don't think that failing to develop or delaying an IETF based
solution will stop 3GPP from developing their own solution. There are
already proposals being agreed within 3GPP based on Accept-Contact
header and feature tags to implement this in what I believe is a way
that potentially breaks interoperability between IMS and other SIP
networks. This is because ithis proposalt requires pre knowledge of
these service identifiers and their use in all networks for
communication without providing a mechanism to obtain them and also
through its use of Accept-Contact potentially signiifcantly limits the
flexibility use of that header for its intended purpose. However RFC
3427 doesn't require that new feature tags be discussed in SIPPING even
when the proposed usage is required for interoperability. So basically
we have a choice between working on an open internet friendly solution
to service identification or allowing by default a 3GPP specific
solution that potentially will create interoperability issues between
internet users and about 2 Billion Mobile users and several hundred
million fixed carrier device users. Jonthan's proposal addresses these
issues.

Something else from RFC 4485:

   Proxies can ignore bodies:  In order for proxies to scale well, they
      must be able to operate with minimal message processing.  SIP has
      been engineered so that proxies can always ignore bodies.
      Extensions SHOULD NOT require proxies to examine bodies.

As already stated I don't believe that SDP always provides sufficent
information to definitively determine the application or service that
the session initiation request is related to and even when it does this
requires that a Proxy examine the body in order to determine whether the
request needs to be routed to some intermediate server that performs
service logic or make other service based routing decisions. I think it
is far preferable to have some kind of service identifier that
specifcally identifies the service logic processing needed included in
an appropriate place in the request as proposed by Jonathan and make
route decisions based on that than to have proxies attempt to do this
based on examing SDP or based on the content type. As well as being more
efficient in terms of proxy processing this avoids routing failures due
to encrypted bodies or unexpected multipart MIME content types or new
alternative content types not yet understood by the proxy causing the
service routing to fail.

So you can count me in the supporting the work on service identification
based on Jonathan's draft column.

Andrew



-----Original Message-----
From: Henry Sinnreich [mailto:[e-mail]] 
Sent: Wednesday, February 07, 2007 12:34 PM
To: Paul Kyzivat; Salvatore Loreto (JO/LMF)
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
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.

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:[e-mail]]
Sent: Wednesday, February 07, 2007 11:13 AM
To: Salvatore Loreto (JO/LMF)
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
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, [e-mail]
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.
>>  
>> [e-mail]
>> --
>>  
>>
>>> -----Original Message-----
>>> From: Gonzalo Camarillo [mailto:[e-mail]]
>>> 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 
>>> [e-mail] for questions on current sip Use 
>>> [e-mail] 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 
>> [e-mail] for questions on current sip Use 
>> [e-mail] 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 
> [e-mail] for questions on current sip Use 
> [e-mail] 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
[e-mail] for questions on current sip Use
[e-mail] 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
[e-mail] for questions on current sip Use
[e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP