Subject: RE: [Sipping] Service Identification Model

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Feb 2007 13:48:29 +0000

Andrew,

There is nothing said here about how the S-CSCF or AS prevents abuse of the
service identifier. Surely an astute user will just include whatever service
identifier allows the request to be authorised and charged at the lowest
rate. Provided the network is not adding value that is necessary to make the
desired service work, the caller can lie in the SIP request.

John 

> -----Original Message-----
> From: Andrew Allen [mailto:[email-masked]] 
> Sent: 23 February 2007 02:23
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: RE: [Sipping] Service Identification Model
> 
> 
> Paul
> 
> I think there are more than those 2. I listed several 
> potential services
> in my earlier email which you responded to with some points that I
> haven't had a chance to respond back to you on that yet (it 
> was a rather
> long list). However I still think those are all valid from the 3GPP
> point of view of services. As well as the issues of identifying the
> service related to the request for routing to Application Servers, and
> routing to the correct UAS and identifying the correct application at
> the UAS there are also the operator related requirements for
> classification of requests for charging, QoS Authorization and
> subscription based authorization purposes and for identifying,
> accounting and understanding the type of traffic in their network. The
> following such requirements exist in the 3GPP stage 2 TS 23.228:
> 
> 
> 2.   Based on operator policy the S-CSCF or an AS shall be able to
> validate an IMS communication service identifier in a SIP 
> request. This
> includes e.g. to check the syntactical correctness of a service
> identifier, and policing the usage of a communication service
> identifier.
> 
> 8.   Based on operator policy S-CSCF and AS shall consider the IMS
> communication service identifier for online and offline charging, e.g.
> put appropriate data into call detailed records.
> 
> 9.   The communication service identifier shall be capable of being an
> input into the policy control and charging rules.
> 
> 10. It shall be possible to use the IMS communication service 
> identifier
> as a means to authorise whether a subscriber is allowed to initiate or
> receive request for a communication service.
> 
> 
> So even when there are other various means to discriminate between one
> type of request and another in order to choose the appropriate
> Application Server or to choose the appropriate application the
> mechanism to identify the request are service specific and therefore
> cannot meet the requirements of a common mechanism that meets
> requirements 2,8,9 and 10 above.
> 
> So to list at least 10 hypothetical services that could be implemented
> using SIP that may be present on a mobile handset:
> 
> 1. Basic Telephony (Conversational QoS Voice only with 
> telephony feature
> set)  
> 2. Multimedia Telephony (Conversational QoS Voice plus video and other
> media streams with telephony feature set)
> 3. VoIP (Background QoS with no telephony features)
> 4. SMS
> 5. MMS
> 6. Instant Messaging
> 7. Push to Talk (PoC)
> 8. Network Game 1 (e.g Chess)
> 9. Network Game 2 (e.g Martial arts game)
> 10. Network Game 3 (e.g Dungeons & Dragons)
> 11. Push Service 1 (e.g. Traffic information service)
> 12. Push Service 2 (e.g. Weather information service)
> 13. Push Service 3 (e.g  News information service)
> 14. Push Service 4 (e.g  Stock information service)
> 15. Mobile TV service
> 
> So there's 15 which may all be different applications on a handset and
> all those are existing services or those already envisioned.
> 
> Andrew
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, February 22, 2007 7:05 PM
> To: Andrew Allen
> Cc: Eric Burger; [email-masked]
> Subject: Re: [Sipping] Service Identification Model
> 
> 
> 
> Andrew Allen wrote:
> > Hi Eric,
> > 
> > It seems your prefer the approach of using URIs to identify services
> > which is part of Jonathan's draft as is the use of Require for those
> > services which simply do not interoperate unless the UAS understands
> the
> > service.
> > 
> > Where I am concerned is that you seem to be suggesting that the UA
> > separately register an AoR for each service it supports using
> REGISTER.
> > Certainly for cellular that wouldn't be acceptable as 10 or more
> > services could easily be supported by a single device.
> 
> Andrew, can you give me an example of 10 "services" on the 
> device that 
> need to be distinguished from one another in this way - that 
> aren't just
> 
> optional behavior of a particular service? (E.g. I see no reason why 
> "audio" and "audio/video" need to be separate services.)
> 
> I guess as things stand, PoC must be a separate service. And 
> apparently 
> Chess. What else?
> 
> 	Paul
> 
> > Registrations
> > create a significant load in the IMS network because its not just a
> SIP
> > REGISTER but also requires a lot of interactions with other network
> > elements such as the HSS and Notifications for reg-events etc. Also
> > having an order of magnitude increase in multiple registrations is
> going
> > to be a big issue for the avalanche restart problem for 
> example when a
> > cell site goes down and comes back into service.
> > 
> > I think Jonathan's approach gives us the possibility for 
> the registrar
> > to create the Service URIs based on the feature parameters 
> included in
> > the Contact of the REGISTER. 
> > 
> > I think the argument over whether the model is one UA with multiple
> > services or multiple UAs each representing a separate service is
> > somewhat academic. As I understand a UA can register 
> multiple AoRs and
> > can have other AoRs configured or otherwise provided by the service
> > provider. 
> > 
> > Andrew
> > 
> > -----Original Message-----
> > From: Eric Burger [mailto:[email-masked]] 
> > Sent: Wednesday, February 21, 2007 1:29 PM
> > To: [email-masked]
> > Subject: [Sipping] Service Identification Model 
> > 
> > Folks have been pestering me for a while to look at the Service
> > Identification issue.  I finally have gotten around to it.
> > 
> > 
> > I guess I have a fundamental problem with the principal assertion of
> the
> > service-identification draft.  Namely, the assertion that there is a
> > single
> > SIP Layer, separate and distinct from two services.  Here 
> is Figure 2
> > from
> > the draft:
> > 
> >                            +---------------------------------+
> >                            |                                 |
> >                            | +-------------+ +-------------+ |
> >                            | |      UI     | |      UI     | |
> >                            | +-------------+ +-------------+ |
> >                            | +-------------+ +-------------+ |
> >                            | |             | |             | |
> >                            | |  Service 1  | |  Service 2  | |
> >                            | |             | |             | |
> >                            | +-------------+ +-------------+ |
> >                            | +-----------------------------+ |
> >                            | |                             | |
> >                            | |             SIP             | |
> >                            | |            Layer            | |
> >                            | |                             | |
> >                            | +-----------------------------+ |
> >                            |                                 |
> >                            +---------------------------------+
> > 
> >                                      Physical Device
> > 
> > I would offer this drawing confuses a common SIP Stack with a common
> > User
> > Agent.  To wit, consider Andrew Allen's (2/16/07 4:26 AM ) use case:
> > 
> >> ... In addition users may have
> >> multiple devices only one of which has the application that
> > understands
> >> the game. Other devices that the user has registered 
> against his AoR
> > may
> >> handle audio for telephony and other voice applications 
> but if Alice
> >> invites Bob to play her favourite game it is not very 
> interesting if
> > Bob
> >> accepts the gaming session on a device that can only 
> accept the audio
> >> stream. Also even when the terminal that has the game application
> >> receives the INVITE the correct application in that 
> terminal needs to
> > be
> >> identified to accept the session.
> > 
> > I would offer that this is the clinching argument that the 
> request is,
> > in
> > fact, addressing a SEPARATE USER AGENT, not a special SERVICE at a
> User
> > Agent.
> > 
> > Same argument for PoC versus a regular voice call: One is 
> looking for
> a
> > PoC
> > User Agent, NOT the PoC service at a given User Agent.
> > 
> > Thus, the picture really looks like the following:
> > 
> >                            +---------------------------------+
> >                            |                                 |
> >                            | +-------------+ +-------------+ |
> >                            | |    UI       | |    UI       | |
> >                            | +-------------+ +-------------+ |
> >                            | +-------------+ +-------------+ |
> >                            | |             | |             | |
> >                            | |    UAS 1    | |    UAS 2    | |
> >                            | |             | |             | |
> >                            | +-------------+ +-------------+ |
> >                            | +-----------------------------+ |
> >                            | |                             | |
> >                            | |             SIP             | |
> >                            | |            Stack            | |
> >                            | |                             | |
> >                            | +-----------------------------+ |
> >                            |                                 |
> >                            +---------------------------------+
> > 
> >                                      Physical Device
> > 
> > 
> > Another argument for different User Agents is the whole "route based
> on
> > SDP"
> > argument.  As the author of RFC 3458, I think I was first 
> to make the
> > assertion that knowing the media type did NOT mean you know the
> > application
> > to use.  I don't want your phone or proxy or B2BUA to guess that
> because
> > I
> > have Chess Media, I want the Chess Application; I want to talk with
> your
> > Chess Application.
> > 
> > Now, is the Chess Application a Preference, Requirement, or 
> the thing
> > that I
> > am addressing?  The answer drives one towards using caller 
> prefs, the
> > Require header, or the Request-URI.
> > 
> > I would offer that it is not a preference: I really want the chess
> > application; I probably do not want to talk to you.
> > 
> > That leaves us with the Require header or a Request-URI.  
> My leanings
> > are
> > not surprisingly towards the RFC 4240 approach.  Frankly, if you are
> > building an IMS (as an example) that can handle 10,000,000
> subscribers,
> > you
> > should be able to handle 100,000,000 registrations.  That order of
> > magnitude
> > is way easier than the 10,000 to 10,000,000 jump.  I don't buy the
> > "registering each service is too much of a burden on the operator"
> > argument,
> > because it is not that much of a burden, and the network 
> actually does
> > the
> > right thing.  Better yet, all of the corner cases work.  
> Best of all,
> > the
> > IETF doesn't have to build an IANA Registry and process a 
> thousand PS
> > documents to register urn:service:myco:widget.
> > 
> > I suppose I could live with Require:, only if you are way 
> too lazy to
> > register each application instance.  It does semantically work,
> because
> > if I
> > want to do PoC and you do not do PoC, I'll get a 4xx response, to
> which
> > I
> > could try a regular call.
> > 
> >
> ______________________________________________________________
> _________
> > 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.
> > 
> > _______________________________________________
> > 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
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 

_______________________________________________
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: "Henry Sinnreich" <[email-masked]>
Date: Fri, 23 Feb 2007 06:05:38 -0800

> Surely an astute user will just include whatever service identifier 
> allows the request to be authorised and charged at the lowest rate.

Wow! Giving the evil user a choice for what he/she wants to pay :-)

> the caller can lie in the SIP request

So shopping is equaled here to lying? 
Is this Alice in Wonderland?

Thanks, Henry

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 7:48 AM
To: Andrew Allen; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [Sipping] Service Identification Model

Andrew,

There is nothing said here about how the S-CSCF or AS prevents abuse of
the
service identifier. Surely an astute user will just include whatever
service
identifier allows the request to be authorised and charged at the lowest
rate. Provided the network is not adding value that is necessary to make
the
desired service work, the caller can lie in the SIP request.

John

---

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

I agree - you will be charged for what you have requested. 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 3:06 PM
To: Elwell, John; Andrew Allen; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [Sipping] Service Identification Model

Thanks, Henry

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Friday, February 23, 2007 7:48 AM
To: Andrew Allen; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [Sipping] Service Identification Model

Andrew,

There is nothing said here about how the S-CSCF or AS prevents abuse of
the service identifier. Surely an astute user will just include whatever
service identifier allows the request to be authorised and charged at
the lowest rate. Provided the network is not adding value that is
necessary to make the desired service work, the caller can lie in the
SIP request.

John 

> I think there are more than those 2. I listed several potential 
> services in my earlier email which you responded to with some points 
> that I haven't had a chance to respond back to you on that yet (it was

> a rather long list). However I still think those are all valid from 
> the 3GPP point of view of services. As well as the issues of 
> identifying the service related to the request for routing to 
> Application Servers, and routing to the correct UAS and identifying 
> the correct application at the UAS there are also the operator related

> requirements for classification of requests for charging, QoS 
> Authorization and subscription based authorization purposes and for 
> identifying, accounting and understanding the type of traffic in their

> network. The following such requirements exist in the 3GPP stage 2 TS 
> 23.228:
> 
> 
> validate an IMS communication service identifier in a SIP request. 
> This includes e.g. to check the syntactical correctness of a service 
> identifier as a means to authorise whether a subscriber is allowed to 
> initiate or receive request for a communication service.
> 
> 

> 1. Basic Telephony (Conversational QoS Voice only with telephony 
> feature
> set)

> media streams with telephony feature set) 3. VoIP (Background QoS with

> no telephony features) 4. SMS 5. MMS 6. Instant Messaging 7. Push to 
> Talk (PoC) 8. Network Game 1 (e.g Chess) 9. Network Game 2 (e.g 
> Martial arts game) 10. Network Game 3 (e.g Dungeons & Dragons) 11. 
> Push Service 1 (e.g. Traffic information service) 12. Push Service 2 
> (e.g. Weather information service) 13. Push Service 3 (e.g  News 
> information service) 14. Push Service 4 (e.g  Stock information 
> service) 15. Mobile TV service
> 

> Andrew, can you give me an example of 10 "services" on the device that

> need to be distinguished from one another in this way - that aren't 
> just
> 
> apparently Chess. What else?
> 
> 	Paul
> 
> > Registrations

> > single SIP Layer, separate and distinct from two services.  Here
> is Figure 2
> > from
> > the draft:
> > 

> > User Agent.  To wit, consider Andrew Allen's (2/16/07 4:26 AM ) use 
> > case:
> > 
> > application to use.  I don't want your phone or proxy or B2BUA to 
> > guess that
> because
> > I

> > magnitude is way easier than the 10,000 to 10,000,000 jump.  I don't

> > buy the "registering each service is too much of a burden on the 
> > operator"
> > argument,
> > 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
> > 
> > 
> > 
> > 
> 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 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

> non-public information.
> 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 
> 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