Subject: RE: [Sipping] Service Identification Model

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 5 Mar 2007 11:07:02 +0100

Hi,

Just a comment that may assist in illustrating the differences in the
services.  In my understanding the "call screening" is actually not the
same in Mulimedia telephony and  Messaging as defined in OMA, in that
there are different XCAP descriptions for them and there are seperate
service descriptions. 

BR,

..//Steve

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

Stephen Terrill (MI/EEM) wrote:
> Hi Paul,
> 
> Doesn't this assume that if I use MSRP, thete).  Such interworking is nothing new.  As such, I do not see 
> that this reduces interworking at all.
> </Steve>

Lets talk about how one goes about doing this 'guessing'.

It would do guessing by looking at the SDP, SIP headers, option tags in
Require and so on, and figure out what service was intended. Now, there
are two cases. In one case, the information in the SIP/SDP is sufficient
to match exactly to the operator definition of services, and the overall
user experience remains good. In the other case, the information is not
sufficient, and the user experience of calls inter-provider will
fundamentally and forever be worse than intra-provider. I assert, we
don't want to go down the latter route. That means that you must always
be able to accurately determine the service from inspection of the
SIP/SDP.

<Steve>
Since we link in ASs in the network anyway, the above "issue" exists
even without the existance of identified services.  I don not see how
identifying the service can make it worse, but I see that it can make it
better.  It leaves the possibility that the downstream SIP elements can
now to behave in accordance with the service. As a worste case - it is
usually possible to perform "interworking" between service definitions.
</Steve>

And this is my point.

Let me also add that this balkanization comes from sevearl specific
problems which have been explicitly stated, despite your claim above
that they have not. They are:

1. if caller and called party support services which overlap but are not
the same (for example, both endpoints do video but one does IM too and
the other doesn't), you will not be able to properly deal with this,
since you are deriving service definitions from this one header, rather
than inspecting the individual SDP and SIP headers that are negotiated
to determine the actual session contents.

<Steve>
This is the situation we have today without a means to identify the
service.  Now, if we start with an overlapping media (noting that the
media is *not* the service), which service will be followed.  I will
again here clarify that messaging (as defined by OMA) and Telephony are
seperate service with separate supplemenatary services.
</Steve>

2. it will not work with non-3gpp providers that have no notion of what
these services are - this is the discussion above

<Steve>
Disagree - see above.   
</Steve>

3. for providers that do have a notion of these service identifiers, it
will require global agreement on what the services are and what they
mean in order to properly interoperate. THis stifles innovation by
moving us back to the old model where everyone had to agree on the
services in every network before they could be deployed. One of the
stated goals of IMS is to enable feature velocity and innovation. You
are going to kill that.

<Steve>
It is true that this requires global agreement on what the services are
- this has been a successful model for global communication so far.
There are two ways that this is usually achieved - one is that there is
one vendor providing all (e.g. skype example) the other is that a number
of players in the industry have the same understanding of the service.
I see that what is being argued for with the support of the
identification of the services, is to allow multiple services on SIP,
where as alternatively it is one big service supporting many "features".

There is still plenty of room for innovation.  The basic communication
service can be used to access other services that are reached by a SIP
URN.  Further, the 3GPP requirements describe a two layer archtecture -
the communication service, an applications that use the communication
service.  The area in the applications leaves plenty of room for
inovation.

Returning to the topic of the Require header.  If I understood correctly
earlier, this implies a RFC - I don't think that is acceptable.  Is this
still on the table?  Is there a way around that?

While I am writting this email, although not on the topic I just wanted
to say I liked the rant from Eric.

</Steve>

-Jonathan R.

-- 
Jonathan D. Rosn 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 in some 
> cases), then it would be natural that the alerting is applied to that 
> as well.

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.

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

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

> 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
> 
>> defined as a seperate service to telephony.  SMS->MMS->Instant 
>> messaging.
> 
> 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 andenberg, 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

_______________________________________________
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: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Mon, 5 Mar 2007 11:07:02 +0100

Hi,

BR,

..//Steve

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

Stephen Terrill (MI/EEM) wrote:
> Hi Paul,
> 
> Doesn't this assume that if I use MSRP, the 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".
> 
>> Cheers,
>>
>> ..//Steve
>>
>> Sent: Friday, February 23, 2007 4:12 PM
>> To: Byron Campen
>> Cc: Andrew Allen; [email-masked]
>> Byron Campen wrote:
>>>> 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)
>> 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.)
>>
>>>> 4. SMS
>>>> 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)
>> Wen I want avoid the "alter

I don't know about that.

	Paul

>    answer" that accepts the message and'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.
>>
>>>> 8. Network Game 1 (e.g Chess)
>>>> 9. Network Game 2 (e.g Martial arts game) 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.
>>
>>>> 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)
>> 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.
>>
>>>> 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:
>>
>> - 1 for basic telephony, multimedia telephony, SMS, MMS, IM
>>
>> - *maybe* something for games
>>
>> - *maybe* something for push services
>>
>> 	Paul
>>
>>>     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
>>>
>>>
>>>> Sent: Thursday, February 22, 2007 7:05 PM
>>>> To: Andrew Allen
>>>> Cc: Eric Burger; [email-masked]
>>>> 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 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".
> 
>> Cheers,
>>
>> ..//Steve
>>
>> Sent: Friday, February 23, 2007 4:12 PM
>> To: Byron Campen
>> Cc: Andrew Allen; [email-masked]
>> Byron Campen wrote:
>>>> 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)
>> 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.)
>>
>>>> 4. SMS
>>>> 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 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
>>>>>
>>>>> 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 ad'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.
>>
>>>> 8. Network Game 1 (e.g Chess)
>>>> 9. Network Game 2 (e.g Martial arts game) 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.
>>
>>>> 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)
>> 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.
>>
>>>> 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:
>>
>> - 1 for basic telephony, multimedia telephony, SMS, MMS, IM
>>
>> - *maybe* something for games
>>
>> - *maybe* something for push services
>>
>> 	Paul
>>
>>>     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
>>>
>>>
>>>> Sent: Thursday, February 22, 2007 7:05 PM
>>>> To: Andrew Allen
>>>> Cc: Eric Burger; [email-masked]
>>>> 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 fordition 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.
>>>>> 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
>>>>>
>>>>> 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 ad 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 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 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
>> [email-masked] for new developments dition 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.
>>>>>of core SIP
>>
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2007 08:24:22 -0500

> there are different XCAP descriptions for them and there are seperate

This strikes me as a *problem*, not a feature.

	Paul

>> Doesn't this assume that if I use MSRP, then I want avoid the "alter
>>    answer" that accepts the message and displays it without alerting.
>>> We've beaten this one to death already. Current implementation forces
> 
>>>>>> Require for those services which simply do not interoperate unless
> 
>>>>>> the UAS understands
>>>>> the
>>>>>> service.
>>>>>>
>>>>>>> ... In addition users may have

---

From: [email-masked]
Date: Mon, 5 Mar 2007 10:53:32 -0500

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>

OK, but why did they do that?  Assuming that people don't want to
*deliberately* make different services incompatible, why wasn't the
same system used for both?  (Or at least, one is an upward-compatible
extension of the other.)

I know I'm sounding cranky here, but we have to get clear what the
goals are.  Yes, it's a Good Thing to replicate in SIP elements of the
architecture of the PSTN, but only insofar as the PSTN is
well-architected.

It appears to me that the thinking of the PSTN has been so silo-ized
that its architects don't even question the assumption that every
service is effectively a separate and parallel network system, leading
to suboptimal choices like the one you mention.

On the other hand, there may be good reasons for this architectural
decision, and I'd love to hear someone make the case.  But the only
argument I've seen is, essentially, "The PSTN already did it that way,
and SIP must duplicate the architectural decisions of the PSTN."

Dale

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Tue, 6 Mar 2007 15:45:46 +0100

Hi Dale,

I am exposing my own ignorance in that I have not being involved in the
OMA discussions myself, hence I am not updated on the motivation for
final solution.  What I see though is these are all developing their own
way to identify the requested service.   If we don't find a general way,
my assumption is that that will continue.

Regards,

Steve. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 4:54 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification Model

   Just a comment that may assist in illustrating the differences in the
   services.  In my understanding the "call screening" is actually not
the
   same in Mulimedia telephony and  Messaging as defined in OMA, in that
   there are different XCAP descriptions for them and there are seperate
   service descriptions. 

OK, but why did they do that?  Assuming that people don't want to
*deliberately* make different services incompatible, why wasn't the same
system used for both?  (Or at least, one is an upward-compatible
extension of the other.)

I know I'm sounding cranky here, but we have to get clear what the goals
are.  Yes, it's a Good Thing to replicate in SIP elements of the
architecture of the PSTN, but only insofar as the PSTN is
well-architected.

Dale

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 6 Mar 2007 07:58:04 -0800

Stephen,

> If we don't find a general way,

You have just touched a key point. How does one prevent ever new
innovative services and new extensions?

New services cannot be prevented, standardized, regulated (or perish the
thought; colluded) but they are most desirable.

Problem: This is not scalable. And has Juha Heinanen has noticed, most
extensions are not widely used (by the competition, my note).

> it would be a good idea to make an inventory of all sip related rfcs 
> and obsolete all that haven't been widely implemented.  i suspect 
> that very few would be left standing.

Solution: New services are best placed in endpoints. Users buy those
endpoints they like. Just like connecting appliances to the electricity
network.

"applications in the network" are a bad idea for many other reasons and
they go against the Internet e2e principle.

Thanks, Henry

-----Original Message-----
From: Stephen Terrill (MI/EEM) [mailto:[email-masked]] 
Sent: Tuesday, March 06, 2007 8:46 AM
To: [email-masked]
Subject: RE: [Sipping] Service Identification Model

Hi Dale,

Regards,

Steve. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 4:54 PM
To: [email-masked]
Subject: Re: [Sipping] Service Identification Model

Dale

---

From: [email-masked]
Date: Wed, 21 Mar 2007 21:37:42 -0500

What I see though is these [groups] are all developing their own
   way to identify the requested service.  If we don't find a general
   way, my assumption is that that will continue.

That is not necessarily a bad thing.  If the "service concept" is
harmful, then if several different service identifications are
established for different subsets of the SIP universe, when those
subsets start to interconnect (and they will, for business reasons),
the service identifications will tend to get modified, mapped, and
discarded at the boundaries of the subsets.  Eventually, the widest
area networks will become functional without service identification at
all because the interworking elements will have to be able to cope
without properly service-identified requests.

Dale