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

From: "Eric Burger" <[email-masked]>
Date: Thu, 5 Jul 2007 15:53:11 -0700

Nothing here prevents intelligent User Agents, Proxies, and B2BUA's from doing whatever transformations, local service invocations, or complex
transaction processing.  However, if that entity needs "more" information to do its routing, that information should be standard SIP information, not a guaranteed-to-be-incompatible service identifier.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

-----Original Message-----
From: Nasir Khan <[email-masked]>
To: Eric Burger
CC: Jonathan Rosenberg <[email-masked]>; [email-masked] <[email-masked]>
Sent: Thu Jul 05 15:40:11 2007
Subject: Re: [Sipping] What is the User Agent (Service Indicator Draft)

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/ <http://groups.google.com/group/sipservlets/> 

On 7/5/07, Eric Burger <[email-masked]> wrote:

	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? 

	On 7/5/07 3:41 PM, "Jonathan Rosenberg" <[email-masked]> wrote:
	
	> 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.
	>
	>
	> Eric Burger wrote:
	>> 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:
	>>
	>>> 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 <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
	>>>
	>>
	>>
	>>
	>> 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.
	>>
	>
	> --
	> 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
	>

	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 <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] <mailto:[email-masked]>  for new developments of core SIP

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

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