Subject: RE: [Sipping] Service Identification Model

From: "Andrew Allen" <[email-masked]>
Date: Thu, 22 Feb 2007 21:22:52 -0500

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

---

From: Byron Campen <[email-masked]>
Date: Fri, 23 Feb 2007 08:34:40 -0600

> all those are existing services or those already envisioned.

	I only see 10 here that would need to ever send a register request.  
(11-15 are strictly client-server) 4-6 will have distinct Content- 
Type headers and payloads. You would need only 1 UA for these. So  
we're down to 8. 8-10 will, once again, be distinct when you look at  
the payload and Content-Type. So we're down to 6. There is no reason  
at all that the UA that handles voice is incapable of handling IM,  
and you can tell the difference by looking at the request type, so  
we're down to 5. As for the voice stuff, you can distinguish 2 from  
anything else through the payload. So, we could quite easily roll 1-2  
together. (4) 3 can be distinguished by watching for any in-dialog  
call-control stuff. (Having a service identifier that essentially  
says "I promise not to use any fancy telephony features on this call.  
No, really, I promise!" is never going to work) So we're down to 3.

	SIP is more than flexible enough to handle all of this stuff in a  
single UA. The UAs are perfectly capable of figuring out what  
"service" the other wants to use; why are your middleboxes unable to  
do the same? Adding a parallel method to make things easy on the  
middleboxes is just asking for trouble, because you're conveying the  
same information twice. It is ripe for abuse. Of course, the easy way  
to do all this is to just let UAs send what they want, and charge per  
KB, but hey, what do I know about simplicity, flexibility,  
scalability, ease-of-deployment, and customer satisfaction? I'm just  
a IETFer.

Best regards,
Byron Campen

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Feb 2007 10:12:17 -0500

>> media streams with telephony feature set)

Why are 1 & 2 different services? 1 is a proper subset of 2.

>> 3. VoIP (Background QoS with no telephony features)

And why is 3 different from 1 and 2? Are you saying that to be able to 
use a feature I must decide *before* I make the call that I might want to?

Even if that is the case, that sounds like a policy issue between a user 
and his own provider, rather than an e2e negotiation. (My features are 
provided by my UA and/or my provider.)

>> 5. MMS

Why are 4 and 5 different services? They are both datagrams. The 
difference in media types is irrelevant. If its delivered via MESSAGE, 
then it is already distinguishable from calls. This should be able to be 
part of the same service as IM.

>> 6. Instant Messaging

Is just another media type. Like voice and video, these can be 
negotiated for the session. Why balkanize as a different service?

>> 7. Push to Talk (PoC)

We've beaten this one to death already. Current implementation forces 
need for essentially an overlay network to support it. But its far from 
an exemplar of how to do it.

>> 10. Network Game 3 (e.g Dungeons & Dragons)

I tend to agree with Eric that service URIs are good for these if there 
is no better way. But in practice I think these could easily be 
distinguished in SDP using o/a.

>> 14. Push Service 4 (e.g  Stock information service)

There may be *something* here. I need to know more about the 
characteristics of these. If they consist of human intelligible media, 
then I think they could adequately be dealt with via callerprefs. (This 
may be a bit like the Actor feature tag.) Specifically, callerprefs are 
fine if its ok that the call end up elsewhere if the callerprefs 
selection doesn't happen or there isn't any target with that capability.

If the information isn't intelligible media, then it ought to be 
distinguishable as a special media type in the offer.

>> 15. Mobile TV service

AFAIK, the station doesn't call me to deliver me tv service. I would be 
initiating the call. And presumably it will be to a target service URI 
or URN. So I see no need for a service id here.

>> all those are existing services or those already envisioned.

So I only see:

- 1 for basic telephony, multimedia telephony, SMS, MMS, IM

- *maybe* something for games

- *maybe* something for push services

	Paul

> (11-15 are strictly client-server) 4-6 will have distinct Content-Type 
> headers and payloads. You would need only 1 UA for these. So we're down 
> to 8. 8-10 will, once again, be distinct when you look at the payload 
> and Content-Type. So we're down to 6. There is no reason at all that the 
> UA that handles voice is incapable of handling IM, and you can tell the 
> difference by looking at the request type, so we're down to 5. As for 
> the voice stuff, you can distinguish 2 from anything else through the 
> payload. So, we could quite easily roll 1-2 together. (4) 3 can be 
> distinguished by watching for any in-dialog call-control stuff. (Having 
> a service identifier that essentially says "I promise not to use any 
> fancy telephony features on this call. No, really, I promise!" is never 
> going to work) So we're down to 3.
> 
> single UA. The UAs are perfectly capable of figuring out what "service" 
> the other wants to use; why are your middleboxes unable to do the same? 
> Adding a parallel method to make things easy on the middleboxes is just 
> asking for trouble, because you're conveying the same information twice. 
> It is ripe for abuse. Of course, the easy way to do all this is to just 
> let UAs send what they want, and charge per KB, but hey, what do I know 
> about simplicity, flexibility, scalability, ease-of-deployment, and 
> customer satisfaction? I'm just a IETFer.
> 
> Best regards,
> Byron Campen
> 
> 
>> 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.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Feb 2007 10:12:17 -0500

So I only see:

	Paul

---

From: Byron Campen <[email-masked]>
Date: Fri, 23 Feb 2007 09:47:51 -0600

> - *maybe* something for push services

	Seems like push services would be handled by SUBSCRIBE/NOTIFY, with  
appropriate event packages. Nothing fancy there. Certainly doesn't  
warrant a service identifier, Require header, or an AOR (at all).

Best regards,
Byron Campen

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 25 Feb 2007 11:22:01 -0500

Paul's analysis is reasonable. Basically, starting with Andrew's list, I 
see service identification as a business issue. To optimize operation in 
the IMS architecture, it would seem reasonable in several cases for the 
originating S-CSCF to identify the tariffed service(s) implied by the 
messaging from the UA and add the appropriate administrative header 
fields so downstream elements don't have to repeat the analysis.

---

From: Byron Campen <[email-masked]>
Date: Sun, 25 Feb 2007 11:11:31 -0600

This is more palatable than having the UAs provide these  
identifiers. I can still see interop problems down the road where UAs  
could confuse (or deliberately mislead) the S-CSCF by trying to do  
something with which it is not familiar. It seems to me that  
approaching this from the angle of "we have a fixed set of services,  
with individual pricing" is fundamentally and unavoidably at odds  
with the basic structure of SIP. Pricing should be based on the  
amount of work that the provider has to do. This is extremely easy to  
figure out. Bandwidth costs x, location service (ie, call  
establishment) costs y, other functionality (that your servers have  
to do work to accomplish) will cost whatever you feel is appropriate,  
etc. Putting in all the extra infrastructure/logic to simulate the  
charging for old 2G networks, or even the PSTN, seems pointless to  
me. You end up wasting money, time(ie, money), and effort(ie, more  
money). Why not use a charging system that isn't a total pain to  
implement? If you base your charging on the actual work you're doing,  
there is less to exploit in your system, and you can make _more_  
money because you don't have all the overhead from the PSTN billing  
emulation layer! Adopting this strategy does not impede your ability  
to set your pricing to any level you want. It in no way impedes your  
ability to make money.

Best regards,
Byron Campen

> Paul's analysis is reasonable. Basically, starting with Andrew's  
> list, I see service identification as a business issue. To optimize  
> operation in the IMS architecture, it would seem reasonable in  
> several cases for the originating S-CSCF to identify the tariffed  
> service(s) implied by the messaging from the UA and add the  
> appropriate administrative header fields so downstream elements  
> don't have to repeat the analysis.
>

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 26 Feb 2007 09:08:16 +0100

Hi,

Just a comment on the Messaging here;  While I fully understand the view
that isntant messaging is another media, I also understand that the
evolution of messaging in OMA is that instant messaging is actally
defined as a seperate service to telephony.  SMS->MMS->Instant
messaging.

Cheers,

..//Steve

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 23, 2007 4:12 PM
To: Byron Campen
Cc: Andrew Allen; [email-masked]
Subject: Re: [Sipping] Service Identification Model

Byron Campen wrote:
>> 2. Multimedia Telephony (Conversational QoS Voice plus video and 
>> other media streams with telephony feature set)

And why is 3 different from 1 and 2? Are you saying that to be able to
use a feature I must decide *before* I make the call that I might want
to?

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

>> So there's 15 which may all be different applications on a handset 
>> and all those are existing services or those already envisioned.

So I only see:

	Paul

> headers and payloads. You would need only 1 UA for these. So we're 
> down to 8. 8-10 will, once again, be distinct when you look at the 
> payload and Content-Type. So we're down to 6. There is no reason at 
> all that the UA that handles voice is incapable of handling IM, and 
> you can tell the difference by looking at the request type, so we're 
> down to 5. As for the voice stuff, you can distinguish 2 from anything

> else through the payload. So, we could quite easily roll 1-2 together.

> (4) 3 can be distinguished by watching for any in-dialog call-control 
> stuff. (Having a service identifier that essentially says "I promise 
> not to use any fancy telephony features on this call. No, really, I 
> promise!" is never going to work) So we're down to 3.
> 
"service"
> Adding a parallel method to make things easy on the middleboxes is 
> just asking for trouble, because you're conveying the same information
twice.
> It is ripe for abuse. Of course, the easy way to do all this is to 
> just let UAs send what they want, and charge per KB, but hey, what do 
> I know about simplicity, flexibility, scalability, ease-of-deployment,

> and customer satisfaction? I'm just a IETFer.
> 
> Best regards,
> Byron Campen
> 
> 

>> 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
>>
>> I guess as things stand, PoC must be a separate service. And 
>> apparently Chess. What else?
>>
>>     Paul
>>
>>> Registrations
>>> 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.
>>>
>>> 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
>>>

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

>>> 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
>>>
>>
>>
>>
>> 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 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: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Feb 2007 10:06:01 -0500

> defined as a seperate service to telephony.  SMS->MMS->Instant

There's that "S" word again!  In this case, by "different service" do 
you mean "different UI", or "different billing model", or "different 
implementation model"?

I can understand that user expectations will be for a different UI, 
though I think providers who can support both the traditional UIs and a 
unified UI will be more popular in the long run.

I can also understand "different billing model", although I am afraid 
what that really means is an intent to gouge the user for more $$$ than 
is justified by what the provider actually provides. But I am not 
convinced anything special is needed to support whatever billing model 
is desired.

Its the "different implementation model" that is most distressing. The 
users don't care about the implementation model, so any history in that 
regard is irrelevant.

Regarding the UI, I see the following key differences:
- telephony traditionally uses an "alert first" model, and exchanges
   media only after the recipient as accepted the incoming call.
   This is presumed to be applicable to video as well.

- in contrast, with traditional UIs for IM, presence may be
   used as a hint whether the target will accept the message,
   and the first message is sent without any *guarantee* that it
   will be accepted, or seen immediately. Depending on which IM
   model you adhere to, the message may be rejected if the recipient
   isn't ready to receive, or it may be stored for later delivery.
   With SMS/MMS and page mode SIP messaging, every message is a
   "first" message, but this may be disguised with a session oriented
   UI, or not. On the receiving side, there may be an implicit "auto
   answer" that accepts the message and displays it without alerting.
   Or there may be an "alert" that messages are present, but viewing
   them is more like viewing emails.

- The UI for PoC is in many ways similar to IM.

It is clear that people would be upset if their familiar UI paradigms 
were changed. The question is whether that has anything to do with the 
signaling. Ideally this would be strictly a local issue for a UA to 
implement.

In the case of page mode SIP messaging, using MESSAGE out of dialog, 
this is straightforward. MESSAGE can also be used in-dialog, though the 
occasions when this is appropriate are not so clear. From a UI 
perspective, having a separate UI for page mode IM vs voice is obviously 
straightforward. Some innovation in UI design is required to handle page 
mode IM within a dialog set up for other reasons - i.e. voice. But no 
"service" is needed in either case. A UI that doesn't support 
origination of page mode messages in-dialog could nevertheless support 
them on receipt simply by treating them the same as out-of-dialog messages.

IMO there remains work to do on session mode IM using MSRP, in terms of 
mapping it to expected UIs. Mapping to the model where there separate 
alerting before the first message is delivered is not straightforward. 
It could be done in at least a couple of ways:
- the UI could be set up to "auto answer" INVITEs with MSRP,
   and then present the first message in the traditional way.
   The sender would collect the first message before sending
   the invite, and then send it as soon as an MSRP session is
   established.

- the first message could be sent as "early media", and that
   early media could be displayed in lieu of some other form of
   alerting. Sending a response from the UI could be treated as
   an indication to answer the incoming call.

My point here is that there is work to be done, but I don't see why 
there is need for "service identification" to make it work. In fact, the 
similarity between PoC and IM on one hand, and PoC and voice on the 
other hand, suggests that there is a lot of value in figuring out how to 
unify these rather than partitioning them.

After all, who here hasn't been having an IM session and wanted to 
expand it to a voice session as well? This is natural in SIP if the two 
media are not partitioned into different "services".

	Paul

When received, the display of the message
   serves as its own "alert".

---

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

inline.

Andrew Allen wrote:

> The

I would say that I have to disagree with these requirements as stated. I 
  would propose:

2. The IMS communications service shall be determined entirely from 
fields within the SIP message that identify the functionality being 
requested, such as media types, option tags, SIP headers and so on

8. Based on operator policy, S-CSCF and AS shall consider the IMS 
communications service for online and offline charging...

9. The communications service shall be capable of being an input into 
the policy control and charging rules.

10. It shall be possible to use the IMS communications service as a 
means to authorize whether a subscriber is allowed to initiate or 
receive a request for that service

In other words, I am not disagreeing that IMS providers should be able 
to treat different services differently in every way; I just think that 
the notion of the service is entirely a function of what is already 
being said in the SIP message, not something new.

I think another way of expressing this is that the service identifier is 
really a 3gpp vehicle for DWIM - "Do What I Mean" 
(http://en.wikipedia.org/wiki/DWIM). I would prefer DWIS - "Do WHat I 
Say", where "Say" is stuff already in the SIP message.

-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

---

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

Ahh, this is a great insight.

There is a huge difference between:

1. a service identifier inserted by the network based on inspecting 
fields in the SIP message, such as SDP, Require option tags, and header 
fields

2. a service identifier inserted by endpoints which declares the 
specific service being requested

The reason is that #1 can be defined locally within a specific domain or 
service provider network without agreement between domains. As Tom says, 
it would just be a convenience so that once a server in the domain has 
performed this 'analysis', other servers don't have to redo it. You'd 
strip off this identifier prior to a request leaving the domain, and 
when it arrives in the terminating network, redo the analysis, possibly 
getting a different result. That has none of the interoperability 
problems I've been warning about.

#2 requires agreement amongst all parties on what the services are, in 
order to interoperate. That is badness.

I would not be opposed to defining a P-Asserted-Service that contains 
opaque tokens (not service URN) for use within an administrative domain, 
as long as the spec was clear that such a header was optional and always 
had its value computed by examining the rest of the sip message.

-Jonathan R.

Tom-PT Taylor wrote:

>> Even if that is the case, that sounds like a policy issue between a 
>> user and his own provider, rather than an e2e negotiation. (My 
>> features are provided by my UA and/or my provider.)
>>
>>>> 4. SMS
>>>> 5. MMS
>>
>>
>> then it is already distinguishable from calls. This should be able to 
>> be part of the same service as IM.
>>
>>>> 6. Instant Messaging
>>
>>
>> need for essentially an overlay network to support it. But its far 
>> from an exemplar of how to do it.
>>
>> I tend to agree with Eric that service URIs are good for these if 
>> there is no better way. But in practice I think these could easily be 
>> then I think they could adequately be dealt with via callerprefs. 
>> (This may be a bit like the Actor feature tag.) Specifically, 
>> callerprefs are fine if its ok that the call end up elsewhere if the 
>> callerprefs selection doesn't happen or there isn't any target with 
>> that capability.
>>
>> AFAIK, the station doesn't call me to deliver me tv service. I would 
>> be initiating the call. And presumably it will be to a target service 
>> URI or URN. So I see no need for a service id here.
>>
>>>     I only see 10 here that would need to ever send a register 
>>> request. (11-15 are strictly client-server) 4-6 will have distinct 
>>> Content-Type headers and payloads. You would need only 1 UA for 
>>> these. So we're down to 8. 8-10 will, once again, be distinct when 
>>> you look at the payload and Content-Type. So we're down to 6. There 
>>> is no reason at all that the UA that handles voice is incapable of 
>>> handling IM, and you can tell the difference by looking at the 
>>> request type, so we're down to 5. As for the voice stuff, you can 
>>> distinguish 2 from anything else through the payload. So, we could 
>>> quite easily roll 1-2 together. (4) 3 can be distinguished by 
>>> watching for any in-dialog call-control stuff. (Having a service 
>>> identifier that essentially says "I promise not to use any fancy 
>>> telephony features on this call. No, really, I promise!" is never 
>>>> than
>>>> delete
>>>> or constitute non-public information. Any use of this information by

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 26 Feb 2007 18:49:43 +0100

Hi Paul,

Doesn't this assume that if I use MSRP, then I want avoid the "alter
first" model.  If messaging was just another media (which I think it is
in some cases), then it would be natural that the alerting is applied to
that as well.

Moving on from that, I agree on your observation of the key differences
- between the "alert first model" and the "tradition IM model".
Further, my understanding is that the services applied to the model
differ in both cases as well ...

Regards,

Steve.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 4:06 PM
To: Stephen Terrill (MI/EEM)
Cc: [email-masked]
Subject: Re: [Sipping] Service Identification Model

Stephen Terrill (MI/EEM) wrote:
> Hi,
> 
> Just a comment on the Messaging here;  While I fully understand the 
> view that isntant messaging is another media, I also understand that 
> the evolution of messaging in OMA is that instant messaging is actally

them on receipt simply by treating them the same as out-of-dialog
messages.

	Paul

that capability.
> request. 

>>> ____________________________________________________________________
>>> _
>>> __
>>>> Sipping mailing list  
>>>> https://www1.ietf.org/mailman/listinfo/sipping

>>>> Sipping mailing list  
>>>> https://www1.ietf.org/mailman/listinfo/sipping
>>> or

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Feb 2007 13:12:16 -0500

> Doesn't this assume that if I use MSRP, then I want avoid the "alter
I don't think you meant "alter". Maybe "alert" or "answer"?
> first" model. 

I think there is a challenge here to make the decision independent on 
the two ends. You, or the UI you choose, may prefer to just display the 
first message as the alert. I may choose to be alerted first, so I can 
reject before being exposed to potentially offensive content.

PoC has managed to allow both.

> If messaging was just another media (which I think it is

It seems to me that the alerting behavior is only loosely connected to 
the media available, and more tightly coupled to the capabilities of the 
device and the preferred UI style of the user of the device.

I think a better, and more unified, result may come from considering 
this more broadly, rather than just splitting into separate services and 
attempting to make a choice for each.

> differ in both cases as well ...

I don't know about that.

Consider message taking when there is no other UA willing to answer. It 
seems to me that capturing IM for someone not online, and recording VM 
for someone not online are really two aspects of the same service. (In 
3840 this was called msg-taker in order to make it media independent.)

Transfer and hold and conference all apply uniformly. As does call 
screening.

And in any case, those are not "services" in the same sense.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Sun, 25 Feb 2007 19:11:23 -0800

I would offer that it is very much NOT our place to dictate pricing models
on service providers or anyone else, for that matter.

For example, I am composing this message on an airplane.  I have a
polarizing security filter to reduce the ability of someone sitting next to
me from reading my screen.  Why do I have such a filter?  Because once I was
sitting next to a distributor for a very, very, very large, public, network
equipment company.  He happened to be reviewing that company's sales
forecast for the Eastern region, including sales prospects.  At first, I
thought, "Wow - that's cool!  If I were so inclined, I could mine his
prospects."  Then I realized, if I can read his super-secret stuff, he could
read mine.

That's when I went out and bought the filter.

What is the point of the story?  I would be surprised if the filter costs
more than USD 3 to manufacture.  Cost-based pricing would place the ASP
between $10 - $20 each.  However, they go for $50.  Why?  Because the VALUE
of the product far outweighs what the cost-based price would indicate.

Same goes for telecommunication services.   Back in the day, I had a
platform that, from a single number, would find the subscriber, let the
subscriber know *really* who called, and let the subscriber control ultimate
call treatment (connect call, send to voice mail, offer a polite Get Lost,
etc.).  If you called the offering a single-number service, you could hope
to charge $25/month + $0.50/min.  However, if you organized it to be a
personal assistant, given that you were replacing a (in those days)
$35,000/year assistant, you could easily charge a flat $1,000/month.  I'm
happy, because I'm making way better than 65% gross margin.  Subscriber is
happy, because they are saving 60% of their costs, and getting a better
service.

If I were only allowed to create business models on cost, the world would be
worse off.

THAT SAID, part of our special sauce was that we did NOT rely on the
telephone network for our billing.  Price is something entirely in the
service provider's control (barring governmental intervention, like
tariffs).  We could do our cool services BECAUSE we did not confuse
signaling with billing.

That has been the IETF lesson for at least 20 years.  Thus, I will push back
when one group says, "we have to put in this feature into a session protocol
for billing" -or- when another group says, "service providers must use my
model for billing."

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

---

From: Byron Campen <[email-masked]>
Date: Tue, 27 Feb 2007 14:02:48 -0600

I was not trying to say that telcos must ignore value when making  
their charging decisions. None of my message is normative in any way;  
I was just giving an example of how simple/easy things really become  
when you treat bandwidth and the purpose the bandwidth is being used  
for as orthogonal issues.

	That said, I do think that the pattern of charging a special price  
on say, SMS, and then getting bent out of shape when someone puts a  
third-party IM client on their smartphone so they can do IM for  
cheap, seems dangerous to me. The fact is, in the world of software,  
the stuff with high value (to individuals) almost always ends up  
being free. It is also true that every time providers use this  
pattern, they are forcing themselves into a situation where they will  
have to disable all third-party applications by locking down their  
network, because their alternative is to try competing with a free  
product. This is just how things are. There is nothing that they (or  
the IETF) can do to prevent it. And when they take the obvious choice  
of locking down their network, everyone loses; the customers lose  
useful third-party applications for which there is no substitute, and  
the provider loses customers and profits from data plans, since their  
customers aren't using the nifty third-party apps anymore.

	Once again, there is not a single normative statement in here. I am  
just pointing out the reality of the situation. Take it for what you  
will.

Best regards,
Byron Campen

---

From: [email-masked]
Date: Tue, 27 Feb 2007 16:48:47 -0500

Let me try to compose a version of this rant, which I think will be
helpful in (1) getting IETF folks to understand where the telco folks
are coming from, and (2) getting the telco folks to see that they have
been bundling several concepts together.  I am making some guesses as
to how the telcos do things, not based on insider knowledge, but by
connecting a bunch of dots that I've seen over the years.
Nonetheless, it assembles a picture that needs to be examined more
carefully than people have been.

I think the crux of the situation is that the telcos look at what
their network does as a series of "silos", services, that actually are
largely independent and parallel to each other.  That is, each of the
following is separate for each service:

- user agent facilities
- application servers
- network transmission facilities (if the recent BT announcement is typical)
- price structure
- return-on-investment analysis
- regulatory approval
- vendor of the equipment
- perhaps even organizational departments

That is, the fundamental unit of, well, *everything* is the "service".

On the other hand, from the IETF point of view, "services" are just
specialized functionality in the user agents, there are no application
servers, and the network transmission facilities treat all packets the
same under a simple billing scheme.  Silo-ization is an evil to be
fought.

But the IETF model does break down in a lot of real-world cases:

- If the UA cannot support all the processing needed, or the last-mile
  link is bandwidth-constrained, you need application servers.

- Network transmission doesn't have a simple price structure if you
  have high utilization and you do real QoS.  Real competition tends
  to make prices match costs, but when QoS matters, costs are nowhere
  near uniform, and capacity management and billing become
  "interesting" problems.

- In the real world there are regulators when you're rolling out
  services for the masses, and regulators worry about things in a way
  that does not neatly correspond to network engineering.  (I've long
  suspected that the real difference between PoC and "telephony" is
  that by not being full-duplex, PoC escapes some mandated charge that
  ordinary cellular is subject to, and the savings are in part passed
  on to the customers.)

>From the IETF side, we're going to have to start thinking about the
implications of these facts, and ensure that SIP copes with them.

>From the telco side, people should realize that even if the world is
partitioned into "services" in one respect, that it isn't necessarily
a good thing to partition it into services in another respect.  (In
particular, we've discovered that dividing the long-haul network
protocol is not a good thing -- there is only one TCP, for instance,
and the meaning of the data stream is imposed only by the endpoints.)

Dale

---

From: Byron Campen <[email-masked]>
Date: Tue, 27 Feb 2007 16:54:04 -0600

Alright, I do want to make it clear that I have no problem with  
service differentiation that reflects differing responsibilities of  
the provider. The example cases you mention all entail additional/ 
different responsibilities on the part of the provider, and so I have  
no problem with classifying these as distinct services. A call with  
QoS is a very different animal than one without, and a provider is  
completely justified in charging extra for the QoS. Also, cases where  
an application server needs to do extra work are perfectly  
justifiable as separate services.

	What I object to is the cases where there is service differentiation  
that is not motivated by differing provider responsibilities. If  
service A requires you to forward packets P, and service B requires  
you to forward similar packets Q in exactly the same way, A and B  
probably shouldn't be different services. By breaking these up, at  
the very least you invite attacks where sneaky UAs will pretend to  
use the cheaper service A (wink wink, nudge nudge), but really end up  
using service B (imagine a case where, in the SDP offer, a  
proprietary attribute would indicate 'and by "A", I mean "B"'). By  
keying your service differentiation on whether your responsibilities  
differ, your infrastructure becomes much harder to trick.

Best regards,
Byron Campen

---

From: [email-masked]
Date: Wed, 28 Feb 2007 11:23:36 -0500

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

As Byron said, it's hard to see how 1 and 2 are different.  But 3
vs. 1 is an interesting matter -- the user can request different
grades of QoS and pay appropriately.

(My position on QoS is that in truly congested networks, QoS matters,
because different users, depending on what sort of service they
demand, put different pressures on the infrastructure, and they should
be charged accordingly.)

   > 14. Push Service 4 (e.g  Stock information service)

Why would you consider these different?  Perhaps that need to be
routed to different UI elements at the very end (though 2 and 3 can
almost certainly be displayed by the same application), but all of
this can be done by tagging the destination address -- there seems to
be no reason that the *network* would distinguish them.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Feb 2007 13:37:12 -0500

> grades of QoS and pay appropriately.

Sure, QoS can matter, and differ from call to call. But calling each QoS 
option a different service is folly. QoS can be *negotiated* rather than 
just declared. And when you can have multiple media streams in the call, 
with differing QoS needs, it would be insane to assign a different 
service name to each combination.

	Paul