RE: [Sipping] Service Identification in SIP

["Salvatore Loreto (JO/LMF)" <[e-mail]>]

Hi Henry,

thank you for point out this two drafts, I didn't know the dccp one, it
is interesting that there is a similar idea going on also at transport
level. I'll read the draft immediately.

/sal



On Thu, 2007-02-15 at 18:03 -0800, Henry Sinnreich wrote:
> 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