Subject: Re: [Sipping] What is the User Agent (Service Indicator Draft)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 23:57:49 -0400

sorry for never responding to this directly, Eric.

I think one problem is the register load. But as you say, that is a 
matter of implementation scale. In my mind, the main problem is 
discovery. If an originating UA wants to send a MESSAGE to a UA, and on 
that particular UA, the messaging app is a separate app on the phone 
with its own URI, then how does the originator learn the URI to target 
that specific app?

Now, I will answer my own question - presence. Indeed, a prior 
incarnation of the draft advocated using presence to learn URI for 
specific services and targeting them directly. Indeed I still think that 
is a good thing to do. However I am convinced it is not the ONLY thing 
we should do. I still think we will have the case that all I have for a 
user is their AOR, and it should be possible for me to send a MESSAGE 
request and have it dispatched properly in the terminating UA. I don't 
think we should say that, the ONLY way to properly send an IM or do a 
video call, is if we have presence also deployed everywhere and 
federated and so on. If we do, great. But its not required for SIP to 
basically work.

I do think it is reasonable to dispatch SIP requests in a UA or in 
proxies based on various message properties, beyond just the Request-URI.

-Jonathan R.

Eric Burger wrote:
>
> 
> Let me reiterate my fundamental disagreement with the following statement
> (see Section 5.1).  I believe it is the source of many problems that we are
> trying to fix:
> 
>    The role of the SIP layer is to parse incoming messages, handle the
>    SIP state machinery for transactions and dialogs, and then dispatch
>    request to the appropriate service.  For the example services in
>    Section 4.2, an incoming INVITE for the gaming service would be
>    delivered to the gaming application software.  An incoming INVITE for
>    the voice chat service would be delivered to the voice chat
>    application software.  For the examples in Section 4.3, a MESSAGE
>    request for user to user messaging would be delivered to the
>    messaging or SMS app, and a MESSAGE request containing configuration
>    data would be delivered to a configuration update application.
> 
> 
> I would offer that each service MUST have its own Request-URI.  RFC 3261
> states, "A SIP or SIPS URI identifies a communications resource."  In
> particular:
> 
>    Examples of communications resources include the following:
>       o  a user of an online service
>       o  an appearance on a multi-line phone
>       o  a mailbox on a messaging system
>       o  a PSTN number at a gateway service
>       o  a group (such as "sales" or "helpdesk") in an organization
> 
> 
> Let me highlight: an APPEARANCE on a multiline phone, a MAILBOX on a
> messaging system.  Note we do not have a Request-URI for the multiline
> phone, and then have a sub-address for the line appearance.  We do not have
> a Request-URI for a messaging system, and then have a sub-address for the
> mailbox.
> 
> I am listening: I hear and understand the *FEAR* over the statement, "Every
> addressable element on a device needs to register."  To recapitulate the
> argument, take the event of massive re-registrations, like someone blows up
> an HSS and everyone's handset registers with a redundant HSS at the same
> time.  By having the handset register five services, like telephony, game 1,
> game 2, short message service, and PoC, instead of registering the device,
> with some sort of magic sub-addressing, for a network of a million handsets
> we would have five million REGISTER requests instead of a million REGISTER
> requests.
> 
> I STILL OFFER THIS IS NOT A REAL PROBLEM.  IF YOU CAN DEAL WITH ONE MILLION
> SIMULTANEOUS REGISTER REQUESTS, YOU CAN PROBABLY DEAL WITH TEN MILLION.  Why
> do I assert this?  Because if you have the technology to scale to deal with
> one million requests in a minute, you probably have the technology to do ten
> times as much.  Conversely, most networks could not hope to deal with it, so
> the factor of ten is moot.
> 
> Taking away the desire to have ISDN sub-addressing in SIP to address the
> PERCEIVED issue of registering every user agent in the endpoint as a user
> agent in the network takes away a ton of the, "But how am I to determine
> which user agent to use when I get a SIP INVITE or MESSAGE method?" whines.
> The answer is clear, "The user agent to use when you get a SIP INVITE is the
> user agent addressed by the SIP INVITE."  Do as I say, not what I mean.
> 
> Let us fix the problem and not the symptom!
> 
> 
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Eric Burger <[email-masked]>
Date: Thu, 05 Jul 2007 13:24:07 -0400

But does that not presuppose there is no ambiguity in the first place?
Hence, no need for a service indicator?  If there is a need for a service
indicator, then there is a need for service indicator discovery, which is
the identical problem to discovering the URI.

On 7/3/07 11:57 PM, "Jonathan Rosenberg" <[email-masked]> wrote:

>> Notice:  This email message, together with any attachments, may contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted  and/or
>> legally privileged, and is intended solely for the use of the individual or
>> entity named in this message. If you are not the intended recipient, and have
>> received this message in error, please immediately return this by email and
>> then delete it.
>> 
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 15:41:49 -0400

I agree that the problems of:

  1. determination of the service by inspection of the sip message at 
the terminating UA (or proxy or whatever)
  2. determination of a URI for reaching the service, by comparing the 
SIP message to a set of tuples learned from a presence document, each of 
which has some kind of characteristic that defines the service, and 
finding the matching tuple and its associated URI

are identical. #2 basically transfers the service identification problem 
to the originator. However, that transfer is a problem itself. Lets say 
that there is a rule T(), whose input is a SIP request, and whose output 
is a service identifier. T() is a function of the SIP message. WIth 
presence, we're basically taking T() and encoding it in to the 
characteristics and markup around the tuples in a presence document, so 
that the originator of the request performs this mapping. In #1, T() is 
a local function, performed only in the place where it is needed.

I'd assert that, we're always better off implementing T() in the place 
where we need the service identity, rather than encoding the rules and 
sending them to someone else. This is because encoding and sending them:

   a. requires a standardized format to be defined,
   b. limits service definitions to what can be represented in that format,
   c. requires worldwide deployment and agreement upon a system for 
distributing these rules

b is a pretty fundamental architectural problem. c is a pretty big 
practical one.

So, while the two models are, strictly speaking, isomorphic, they are 
done with fundamentally different architectures, one of which has 
limitations that are quite serious.

Thanks,
Jonathan R.

---

From: Eric Burger <[email-masked]>
Date: Thu, 05 Jul 2007 15:45:58 -0400

I think we agree.  What prompted me was the statements that one could use
presence to determine the URI, but that somehow that would not work and thus
the client would have to figure out the URI on its own, e.g., by inserting a
service indicator.

The text you have below, that T() is a function of the server, is 100% in
line with my thinking.  However, from an implementation perspective, does
this mean some kind of query mechanism?

---

From: "Nasir Khan" <[email-masked]>
Date: Thu, 5 Jul 2007 15:40:11 -0700

I agree with the view points expressed in the
draft-rosenberg-sipping-service-identification-02.txt. The issues raised in
this draft are even more relevant in the case when an application server
provides a number of these network service besides the user devices.

An application server usually has a rich framework to allow the deployer of
these services to configure complex rules allowing invocation of services.
In my experience with service composition, one of the most important
criteria in this selection is order of invocation. Some services are always
invoked before others and vice versa.
One big issue if a service is directly addressable (by service ID, feature
tag or even request-uri) is that it can be accessed directly *bypassing* any
service that must be invoked "before" it for correct operation, which will
obviously lead to breaking of the overall service. This could be another
reason by service ID is not such a good idea for service selection.

I have a few additional minor comments on the draft -

<quote>"Essentially, the service is the user-visible use case that is
driving
   the behavior of the user-agents and servers in the SIP network"</quote>

Sometimes the behavior is not user visible - e.g an intelligent routing
application (maybe a proxy) routes the request based upon least cot criteria
saving user money but there is nothing discernible beyond a lighter bill :-)

<quote>"However, a MESSAGE for configuration
   purposes might contain an XML document that uses the token "stock" as
   some kind of attribute.  This configuration update would be discarded
   by the filtering server, when it should not have been." </quote>

 This is precisely what the application selection logic is for, e.g. SIP
Servlets JSR 289 Application Router component.

<quote>"A service is the by-product of the signaling - the effects of the
      signaling message once launched into the network.  The service
      identity is therefore always derivable from the signaling without
      additional identifiers." </quote>

 Is this definition completely correct?  What about environmental inputs
that select a service - like user
profile, subscription information, charging balances, time-of-day,
least-cost-routing DPs, Policy inputs, network conditions etc. ?

One final thing is that the srevice IDs do have a limited usage again in the
SIP Servlet world where there are multiple Servlet containers providing a
distributed service composition. In this case the request inter-container
may carry the services already applied to this request in say History-Info
header.

Nasir Khan
BEA Systems Inc.

Discuss SIP Servlets at http://groups.google.com/group/sipservlets/

On 7/5/07, Eric Burger <[email-masked]> wrote:
> >>>> time.  By having the handset register five services, like telephony,
> game
> >>>> 1,
> >>>> SIMULTANEOUS REGISTER REQUESTS, YOU CAN PROBABLY DEAL WITH TEN
> MILLION.
> >>>> Why
> >>>> one million requests in a minute, you probably have the technology to
> do
> >>>> ten
> >>>> times as much.  Conversely, most networks could not hope to deal with
> it,
> >>>> so
> >>>> The answer is clear, "The user agent to use when you get a SIP INVITE
> is
> >>>> the
> >>>> entities,  that may be
> confidential,  proprietary,  copyrighted  and/or
> >>>> entity named in this message. If you are not the intended recipient,
> and
> >>>> have
> 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.
>
>

-- 
Discuss SIP Servlets at http://groups.google.com/group/sipservlets/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Jul 2007 14:50:20 -0400

inline.

Nasir Khan wrote:
> draft-rosenberg-sipping-service-identification-02.txt. The issues raised 
> in this draft are even more relevant in the case when an application 
> server provides a number of these network service besides the user devices.
>  
> An application server usually has a rich framework to allow the deployer 
> of these services to configure complex rules allowing invocation of 
> services. In my experience with service composition, one of the most 
> important criteria in this selection is order of invocation. Some 
> services are always invoked before others and vice versa.
> One big issue if a service is directly addressable (by service ID, 
> feature tag or even request-uri) is that it can be accessed directly 
> *bypassing* any service that must be invoked "before" it for correct 
> operation, which will obviously lead to breaking of the overall service. 
> This could be another reason by service ID is not such a good idea for 
> service selection.

I don't think anyone had proposed that the service ID would directly 
indicate the app to invoke, bypassing any such logic. But rather, it 
would be the primary or only input to the service selection process at 
an application server.

> application (maybe a proxy) routes the request based upon least cot 
> criteria saving user money but there is nothing discernible beyond a 
> lighter bill :-)

Sure, but that is 'user visible' in a sense - they do see the results. 
I'll try to indicate that this can include visible effects outside of 
the call itself.

> least-cost-routing DPs, Policy inputs, network conditions etc. ?

Right - I'll mention that this context is part of it too. Now says:

<t>A service is the by-product of the signaling and the context around
   it (the user profile, time-of-day and so on) - the effects of the
   signaling message once launched into the network. The service
   identity is therefore always derivable from the signaling and its
   context without additional identifiers.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Jul 2007 15:00:16 -0400

> this mean some kind of query mechanism?

I don't follow. T() is a function that maps from information in the 
request, to a service indicator used to dispatch.

So, for example, a UA might have a rule T() that says:

if(method==MESSAGE)
   service=messaging
else
   service=voice

and then it dispatches to the messaging or voice app on the phone as 
appropriately. There is no query here; this is a local piece of logic.

-Jonathan R.

---

From: Eric Burger <[email-masked]>
Date: Fri, 06 Jul 2007 17:33:01 -0400

Now I get it.  I must be exuding miscommunication, as Nasir also berated me
on the same point.

I was thinking that there was some way of calculating a "final Request URI,"
different than normal proxy or User Agent calculation.  I was saying that
had to be at the server, which is exactly what you are saying.  I was also
thinking two steps ahead, when one would have sufficed, to say if there was
some reason the client had to exactly identify the target, it would have to
query the server.

This is actually not an abstract bizarre thought on my part.  Think GRUU,
that is, an exact Request-URI that lands at a particular instance (virtual
or physical).  GRUU is most definitely something only the server can
calculate.