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 devicietf.org for new developments of core SIP

---

From: Byron Campen <[email-masked]>
Date: Wed, 21 Feb 2007 16:12:11 -0600

Yes! _This_ makes sense to me. This seems like the proper way to  
think about and solve this problem.

Best regards,
Byron Campen

>> 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:
>
>                            | |    UAS 1    | |    UAS 2    | |
>                            | |            Stack            | |
> 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

_______________________________________________
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