Subject: RE: [Sipping] Service Identification Model

From: "Andrew Allen" <[email-masked]>
Date: Thu, 22 Feb 2007 00:49:05 -0500

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

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Thu, 22 Feb 2007 09:22:15 +0100

Hi,

Isn't relying on a different AoR record for each service a rather
backwards approach?  Today, there have been upto three numbers on the
phones representing different services (Telephony; fax and Data) - which
means business cards which means different numbers for the different
ways I want to contact a person.  In myunderstanding, that would apply
here as a different AoR record for Telephony; PoC and Messaging.  I
think it is much more preferable to have one AoR; and then to be able to
indicate the requested service.

Steve.

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Thursday, February 22, 2007 6:49 AM
To: Eric Burger; [email-masked]
Cc: Andrew Allen
Subject: RE: [Sipping] Service Identification Model 

Hi Eric,

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. 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 regFrom [email-masked] Thu Feb 22 03:22:43 2007
Content-class: urn:content-classes:message
Subject: RE: [Sipping] Service Identification Model 
Date: Thu, 22 Feb 2007 09:22:15 +0100
To: <[email-masked]>

Hi,

Isn't relying on a different AoR record for each service a rather
backwards approach?  Today, there have been upto three numbers on the
phones representing different services (Telephony; fax and Data) - which
means business cards which means different numbers for the different
ways I want to contact a person.  In myunderstanding, that would apply
here as a different AoR record for Telephony; PoC and Messaging.  I
think it is much more preferable to have one AoR; and then to be able to
indicate the requested service.

Steve.

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Thursday, February 22, 2007 6:49 AM
To: Eric Burger; [email-masked]
Cc: Andrew Allen
Subject: RE: [Sipping] Service Identification Model 

Hi Eric,

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 

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:

                                     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

understands
may
Bob
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
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.

                           | +-------------------istrations is going

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 

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:

                                     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

understands
may
Bob
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
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.

                                     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.

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.

_______________________________________________
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 list is for NEW development of the----------+ |

                                     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.

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.

_______________________________________________
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: "Steve Langstaff" <[email-masked]>
Date: Thu, 22 Feb 2007 02:04:54 -0800

If my business card has a FAX number on it, you can be pretty sure that
you can FAX me on it.

If all you have is a generic contact address, you don't know whether you
can FAX me until you try, and possibly fail, to contact me.

So it could be argued, from the "business card" point of view, that a
single AoR is not "preferable", just "different".

> From: Stephen Terrill (MI/EEM) [mailto:[email-masked]] 
> Sent: 22 February 2007 08:22
> To: [email-masked]
> Isn't relying on a different AoR record for each service a 
> rather backwards approach?  Today, there have been upto three 
> numbers on the phones representing different services 
> (Telephony; fax and Data) - which means business cards which 
> means different numbers for the different ways I want to 
> contact a person.  In myunderstanding, that would apply here 
> as a different AoR record for Telephony; PoC and Messaging.  
> I think it is much more preferable to have one AoR; and then 
> to be able to indicate the requested service.
> 
> Steve.
>

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Thu, 22 Feb 2007 11:53:10 +0100

Hi Steve,

I conceed your point with a FAX on a buisiness card as it is often
another (shared) device, however perhaps it may not have been nice if
that practice was carried over to SMS; MMS etc ... 

BR,

..//Steve

-----Original Message-----
From: Steve Langstaff [mailto:[email-masked]] 
Sent: Thursday, February 22, 2007 11:05 AM
To: Stephen Terrill (MI/EEM); [email-masked]
Subject: RE: [Sipping] Service Identification Model 

> phones representing different services (Telephony; fax and Data) - 
> which means business cards which means different numbers for the 
> different ways I want to contact a person.  In myunderstanding, that 
> would apply here as a different AoR record for Telephony; PoC and 
> Messaging.
> I think it is much more preferable to have one AoR; and then to be 
> able to indicate the requested service.
> 
> Steve.
> 
> services which simply do not interoperate unless the UAS understands 
> the service.
> 
> 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 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:
> 

> 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.
> 
> Another argument for different User Agents is the whole "route based 
> on SDP"
> 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.
> 
> that I am addressing?  The answer drives one towards using caller 
> prefs, the Require header, or the Request-URI.
> 
> 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

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

> 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: Thu, 22 Feb 2007 19:04:56 -0500

Andrew Allen wrote:
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Feb 2007 19:04:56 -0500

Paul

---

From: Eric Burger <[email-masked]>
Date: Fri, 23 Feb 2007 11:32:03 -0500

What is the difference between:

sip:[email-masked]

sip:[email-masked]   <message-context: pager> (See RFC 3458)

sip:[email-masked]   <Require: sms>

???