Subject: [Sipping] Service Identification Model

From: Eric Burger <[email-masked]>
Date: Wed, 21 Feb 2007 10:29:09 -0800

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

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