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

From: Eric Burger <[email-masked]>
Date: Mon, 14 May 2007 14:57:25 -0400

First, let me say I have the luxury of waiting a week and seeing the
comments fly by.  That saved me a megabyte of typing.  Please do not take
these comments to mean I do not fully agree with the draft.  Maybe it is
that I am ticked off about the non-attribution of the value of caching the
service indicator within a domain as a way of significantly reducing the
requirements for resources to perform redundant calculations within a
domain, and that the use of a service indicator for signaling was begging
for fraud [hint]...

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 15 May 2007 08:52:38 +0200

Hi,

Then, when you use outbound, need need to multiply the number of
registrations with the number of flows for each registration. In
addition to that you will have the keep-alive messages for each flow...

Regards,

Christer

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: 14. toukokuuta 2007 21:57
> To: [email-masked]
> Subject: [Sipping] What is the User Agent (Service Indicator Draft)
> 
> First, let me say I have the luxury of waiting a week and 
> seeing the comments fly by.  That saved me a megabyte of 
> typing.  Please do not take these comments to mean I do not 
> fully agree with the draft.  Maybe it is that I am ticked off 
> about the non-attribution of the value of caching the service 
> indicator within a domain as a way of significantly reducing 
> the requirements for resources to perform redundant 
> calculations within a domain, and that the use of a service 
> indicator for signaling was begging for fraud [hint]...
> 
> 
> 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:
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>