Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)

From: "David R. Oran" <[email-masked]>
Date: Fri, 1 Mar 2002 10:00:27 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Petri K. Koskelainen
> Sent: Thursday, February 28, 2002 12:24 PM
> To: [email-masked]
> Subject: [Simple] Re: 
> draft-rosenberg-simple-components-00.txt (threading)
> 
> 
> 
> Hi,
> 
> The draft proposes that In-Reply-To header should
> be used for message threading in paging mode,
> and the draft also states that in message session 
> mode threading is already provided.
> 
> I don't fully agree here. It works for two-party messaging
> but not well in group messaging scenarios.
>
> Problem 1: Message session supports only one discussion thread 
> per session.
> This does not well reflect real-life scenarios. 
> For example, there may be a group chat session with 20 people. 
> It is very likely that they have different
> conversation topics going-on at the same time although they 
> are in the same group. It is also likely that smaller 
> sub-threads emerge and it would be nice if these can be 
> somehow shown in the user interface similarly to current 
> network news UIs. For example, if there are several questions 
> asked in the group and users respond with "yes!" or "no" in 
> the message body it is 
> quite difficult to know to which question they were intended. 
> User Interface could show them nicely if there were header support 
> for it.
>
Actually, I think there are two related, but not identical problems to
be solved here. One is the logical grouping of messages by thread/topic,
for which In-reply-to: is helpful but not completely adequate. The
second is constructing a causal order of the messages in a multi-party
chat session. In-reply-to can in fact be used for this, as long as each
message is in fact tagged with the message-id of the message that
provoked it (some UI support is of course needed to identify this).
However, this usage would conflict with the classical threading usage we
see in newsgroups.

I think the threading/topic stuff would best be solved with adding a
hierarchical structure to the Subject: (or In-reply-to) header, or a new
header, such as "context:"  and some conventions thereto, as was
suggested. However, that leaves the problem of how to establish the
causal order if the In-reply-to header is used. For that, I believe a
new header would be called for.

I frankly find a causal order more useful than a threading feature, but
that may just be me...
 
> 
> Problem 2: Group messaging server creates new Call-IDs for 
> each call-leg. In-Reply-To has also problems in group IM 
> paging mode since the server creates new Call-IDs for each 
> participant. One call-id is valid only between one user and 
> the server. The server has to remember all previous Call-IDs 
> so it can change Call-IDs in In-Reply-To accordingly when somebody 
> is responding to group message. 
> It must have the history and know that a message it sent to Bob 
> a day ago with Call-ID=X is in fact the same message than 
> message sent to Alice with Call-ID=Y. This becomes quite complicated.
>
This would argue for "in-reply-to" (and whatever we use for causal
order) having a global scope as opposed to a dialog/call scope, right.
If we did this and tied the context to the URI of the group chat and not
the dialog, this problem would go away, right?

>  
> Problem 3: Lack of global and common ID for each group 
> message. Now it is difficult to reference a specific group 
> instant message afterwards so that everybody understands it. 
> Only the server has the knowledge (if it keeps the history). 
> The recipients don't know that group IM sent to me with 
> Call-ID=X is the same than group IM sent to Alice with 
> Call-ID=Y. In some cases it would be useful to have the 
> information available in the message.
> 
> 
> These problems can be solved if new header (Message-ID)
> is defined and References header is used (like in NNTP messages).
>
This would work, I think, and if my proposal for causal orders used this
as the referent we could get a long way toward a nice system model.
 
> 
> BR,
> --
> Petri
> _______________________________________________
> simple mailing list
> [email-masked] 
> http://mailman.dynamicsoft.com/mailman/listinf> o/simple
> 

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Mar 2002 01:26:33 -0500

> but not well in group messaging scenarios.

It is good that we are finally having some discussion on this.
Do note that draft-ietf-sip-message does actually talk about 
In-Reply-To as the threading mechanism...

> are in the same group. It is also likely that smaller sub-threads
> emerge and it would be nice if these can be somehow shown
> in the user interface similarly to current network news UIs.
> For example, if there are several questions asked in the group
> and users respond with "yes!" or "no" in the message body it is

I'll buy that this would be handy, although not super critical. 
If MESSAGE were used for messaging within the session model,
wouldn't In-Reply-To be sufficient for it?

> 
> Problem 2: Group messaging server creates new Call-IDs for each call-leg.
> In-Reply-To has also problems in group IM paging mode
> since the server creates new Call-IDs for each
> participant. One call-id is valid only between one user and the server.
> The server has to remember all previous Call-IDs so
> it can change Call-IDs in In-Reply-To accordingly when somebody
> message sent to Alice with Call-ID=Y. This becames quite complicated.

No doubt.

A discussion we REALLY need to have, is whether we think that the paging
model even makes sense for multiparty. I am really not convinced. It
seems that multiparty paging model is really more like email, and that
is not what IM is supposed to be. If group IM is supposed to be real
time, It just works so much better in the session model. So many
problems (like this one above) just evaporate.

Can anyone suggest a reason why the paging model is preferrable for
group chat? Simplicity is one, but that simplicity might be elusive as
you try to fill in all the missing pieces.

> 
> 
> Problem 3: Lack of global and common ID for each group message.
> Now it is difficult to reference a specific group instant message
> afterwards so that everybody understands it. Only the server
> has the knowledge (if it keeps the history). The recipients
> don't know that group IM sent to me with Call-ID=X is the same than
> group IM sent to Alice with Call-ID=Y. In some cases it would
> be useful to have the information available in the message.

Agree that a unique message ID is needed. For session model, if MESSAGE
is used, it is NOT clear to me that Call-ID would have to change for
each leg of the conference.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Mar 2002 01:33:40 -0500

"David R. Oran" wrote:

> chat session.

Good observation. I think you are right.

 In-reply-to can in fact be used for this, as long as each
> However, this usage would conflict with the classical threading usage we

In-Reply-To can play either role, depending on what you think should go
in there. If, when you respond to a message, you place into In-Reply-To,
the value of In-Reply-To from the message you are responding to, you get
threading. You change threads by basically deleting In-Reply-To when you
create a new thread. If you place into In-Reply-To, the Call-ID of the
message you are responding to, you get causal order. Its not clear which
is a "more correct" usage of In-Reply-To. If I had to guess, its
probably the latter usage, which would get you causal order.

> new header would be called for.

Why is a new header needed for causal order if you use In-Reply-To?

Theading may very well better be handled by Subject. I hadn't thought
about that....

-Jonathan R.

---

From: Billy Biggs <[email-masked]>
Date: Fri, 8 Mar 2002 01:07:31 -0600

Jonathan Rosenberg ([email-masked]):

> A discussion we REALLY need to have, is whether we think that the
> paging model even makes sense for multiparty. I am really not
> convinced. It seems that multiparty paging model is really more like
> email, and that is not what IM is supposed to be. If group IM is
> supposed to be real time, It just works so much better in the session
> model. So many problems (like this one above) just evaporate.
> 

  The session model for group messaging implies the existance of a
centralized server, otherwise it becomes unmanageable (all the
complexities of distributed state in a full mesh).  If all messaging is
done through paging, it seems like you could build an end-to-end
conference on the fly with transparent migration from point-to-point and
multi-recipient messages.

  I believe that the simplicity remains only if you allow membership
inconsistencies, like email.  Each group member retains their own
membership state which may or may not match the other recipients, and
while optional membership add/drop requests may be sent by members, each
client is ultimately free to make their own decisions as to who they
send messages to.  This allows for 'bcc' functionality as well.

  However, if messages are not autonomous and themselves contain state,
this would break the model.

-- 
Billy Biggs
[email-masked]

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 8 Mar 2002 10:34:17 -0500

Clarifying a couple of points for Jonathan:

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, March 08, 2002 1:34 AM
> To: David R. Oran
> Cc: [email-masked]
> Subject: Re: [Simple] Re: 
> > > Problem 1: Message session supports only one discussion 
> thread per 
> > > session. This does not well reflect real-life scenarios.
> > be solved here. One is the logical grouping of messages by 
> > thread/topic, for which In-reply-to: is helpful but not completely 
> > adequate. The second is constructing a causal order of the 
> messages in 
> > a multi-party chat session.
> 
> > However, this usage would conflict with the classical 
> threading usage 
> > we see in newsgroups.
> 
> In-Reply-To can play either role, depending on what you think 
> should go in there. If, when you respond to a message, you 
> place into In-Reply-To, the value of In-Reply-To from the 
> message you are responding to, you get threading. 
Yup. 

> You change 
> threads by basically deleting In-Reply-To when you create a 
> new thread. 
Well, news systems allow you to have "hierarchical" threading, which
would not be easy/possible unless you either have some hierarchy in
In-Reply-To: and/or a way to explicitly start a sub-thread, perhaps by
using Subject: in a clever way as you allude to below. The mixing of
this not-quite-right causal ordering results in annoying structures like
the cascading-thread with each message indented further. Such threads
are very hard to follow which is why both threading and causal ordering
is needed.

> If you place into In-Reply-To, the Call-ID of the 
> message you are responding to, you get causal order. 
Yes, either the Call-ID itself or some other global identifier. I
suppose Call-ID can be used without usage confusion, but I haven't
thought about it long enough to be sure.

> Its not 
> clear which is a "more correct" usage of In-Reply-To. If I 
> had to guess, its probably the latter usage, which would get 
> you causal order.
> 
I'm inclined to agree. Again though, I'd need to ponder a bit more to
see if this is indeed the way to go.

> > hierarchical structure to the Subject: (or In-reply-to) 
> header, or a 
> > new header, such as "context:"  and some conventions 
> thereto, as was 
Sorry, my ruminations were sloppy. I meant that if you used In-Reply-To:
for threading you'd need a new header for establishing causal order.
 
> Threading may very well better be handled by Subject. I hadn't 
> thought about that....
>
Definitely worth considering. Given the general history and sloppiness
around Subject:, it might be better to have an explicit "Threading:"
header than try to figure out what to put in subject, which today simply
does "approximate pattern match using the natural intelligence engine".
There are also the issues around the (inconsistent) conventions for
manipulating Subject: headers with things like "Re:" "Fwd:" etc.

Dave.

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 8 Mar 2002 11:56:04 -0500 (EST)

> you try to fill in all the missing pieces.

There are one-shot scenarios which require realtime delivery
to a group. It is quite heavy operation to set up a session,
send one IM, and then close the session. 
Example usage might be an urgent realtime announcement to a 
pre-defined group.

BR,
--
Petri

---

From: Sean Olson <[email-masked]>
Date: Fri, 8 Mar 2002 09:56:49 -0800 (PST)

Group chat is of course a better fit for the
session model. One-time delivery of messages to
a group is a better fit for paging as Petri points
out. How common is this? I can think of a TON of
applications that fit this scenario. What features
of group messaging can't be implemented in a paging
mode?

/sean

--- "Petri K. Koskelainen" <[email-masked]>

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2002 16:35:30 -0500

> of group messaging can't be implemented in a paging

- combining different media in the same group/conference
- floor control
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Fri, 8 Mar 2002 14:23:18 -0800 (PST)

> - combining different media in the same

I don't see this limitation. What about entity
headers?

> - floor control
This is a bit odd for IM

=====

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2002 17:40:06 -0500

> I don't see this limitation. What about entity

I don't understand what you mean.

What I meant is that session oriented messaging is needed if you want to have a conference that includes messaging as well as other media, like voice or video. That way
they are associated with one another via a common INVITE, with multiple m= lines in the SDP.

If you use page mode messaging, you have to invent an entirely new mechanism to tie it to the session for the other media.

> This is a bit odd for IM

Perhaps so if it is text mode IM. But suppose you are using this for some other purpose, like gaming, or pushing URLs that are to be rendered in a window.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Fri, 8 Mar 2002 15:27:49 -0800 (PST)

> I don't understand what you mean.

I was referring to mixing media within an IM 
"session" -- not the problem you were referring to :)

> What I meant is that session oriented messaging is
> needed if you want to have a conference that
> includes messaging as well as other media, like
> voice or video. That way
> they are associated with one another via a common
> INVITE, with multiple m= lines in the SDP.

Absolutely. And for a group conference that makes
a lot of sense. For ad-hoc groups which are
essentially a collection of point-to-point
connections, there may not be a need or occassion
to use a INVITE-based session. An example is a
IM sidebar to a regular group conference. You don't
want to re-negotiate (via INVITE) the overall
conference, but instead what to exchange a few simple
IMs among an ad-hoc group. 

[I'm not against the session model for multiparty IM.
If the WG would prefer to focus only on session model
for multiparty scenarios, that's fine. But I expect
this will only mean people will go off and implement
their own paging model for multiparty IM. It's just
too intuitive to pass up.]

> 
> If you use page mode messaging, you have to invent
> an entirely new mechanism to tie it to the session
> for the other media.

In-Reply-To would not work?

> > 
> > > - floor control
> > This is a bit odd for IM
> 
> Perhaps so if it is text mode IM. But suppose you
> are using this for some other purpose, like gaming,
> or pushing URLs that are to be rendered in a window.

Floor control would be useful here if the group
accepts a moderator/floor notion of control. Chaotic
as it may seem, there may be good reason to not have
floor control in a multiparty IM environment. The
social dynamics seem to argue for it for one. Note
that I am not including "group chat" or chatroom 
scenarios. I am talking more about ad-hoc scenarios.

/sean

=====

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 9 Mar 2002 15:42:27 -0600

> you try to fill in all the missing pieces.

Well, if some of your participants are coming and going, you have an open
question about whether store-and-forward delivery to those paticipants is
appropriate.

If we do store-and-forward, then it really IS like fast email, and I would
posit that the paging model makes excellent sense. If on the other hand the
model is a "chat room" where unless you are in the room, you never see the
message, then a session model makes more sense.

So I suggest that we may wish to consider distinguishing these two models
from a requirements analysis perspective.

I believe if we follow this to a logical conclusion that we'll end up with
two very different implementations serving the different modalities, and a
couple of logical "transition points" where messaging sequence move from one
mode to the other.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2002 08:59:35 -0500

I am not opposed to page-mode conferences.
I was simply responding to your message that implied
(I thought) that page-mode might be sufficient, without
session-mode.

The other problem with page-mode conferences is of course
the issue of sending them over the SIP signalling channel.
There is the general objection to doing this for fear of
saturating the channel.

	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 11 Mar 2002 13:40:22 -0600

> There is the general objection to doing this for fear of 

Of course, meeting the European (and probably elsewhere) regulatory
requirements for privacy is going to require running EVERYTHING over the
signaling chanel or through an intermediary "anonymizer" box anyhow, so
I fail to see this as a real issue. One simply has to design one's
signaling network appropriately. One also has to design the business
model in such a way that the costs can be accounted for and offset by
revenue . . .

I keep seeing this "Oh no, they're asking us to actually carry TRAFFIC
on our network!" response from mobile operators that are still stuck in
GSM circuit mindsets. What they fail to realize is that it is the
value-added service (such as privacy management) built into that
carriage that provides the value-add which distinguishes the service
operator from a commodity bit-pipe provider.

At the "most protective" end of the spectrum (I get this from people in
Germany building wireless systems), the communication between two users
cannot be allowed to reveal the actual IP address of any user, nor can
it reveal anything about the geographic location or business
relationships (who's your carrier?) of any user. The ONLY piece of
information that can be revealed is the "identity" of a user as
indicated by a network "address of record", and then only to the extent
thet the user has specifically requested dislcosure of that mechanism
AND a contractual relationship between operators provides for the
controlled release of only that information. This means that each
service operator has to operate a bidirectional anonymization service.
For short sequences of messages, the SIP proxy network (with a few
"hiding" tweaks) seems to be an efficient mechanism for doing this,
certainly more efficient than allocating two session-level anonymizer
boxes and using INVITE session signaling semantics to instantiate a
protected session.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2002 15:13:09 -0500

Dean Willis wrote:
> controlled release of only that information. 

Ugh!

Seems nasty to require such by default. Providing that level of anonymity is costly. Ought not to be mandated. While I may want it, I often don't need it.

Nevertheless, this seems to be largely irrelevant to the subject at hand.

> operator from a commodity bit-pipe provider.

My impression is that the force behind keeping IM off of the SIP signalling channel is IETF rather than regulatory agencies or mobile operators. I thought it had to do with
UDP not be flow controlled.

The proposals to use a SIP-like protocol over TCP or TLS resolves that problem. And if it transits a proxy then it can handle the anonymization as well. But I believe doing
those things will require session oriented messaging.

	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 11 Mar 2002 16:18:11 -0600

Paul said:
> My impression is that the force behind keeping IM off of the 
> SIP signalling channel is IETF rather than regulatory 
> agencies or mobile operators. I thought it had to do with UDP 
> not be flow controlled.
> 
> The proposals to use a SIP-like protocol over TCP or TLS 
> resolves that problem. And if it transits a proxy then it can 
> handle the anonymization as well. But I believe doing those 
> things will require session oriented messaging.

Well, there are serveral forces toward keeping user messages off of the
"signaling" path.

1) We've justified use of questionable flow control techniques for SIP
by calling it "signaling", which implies a requirement for low-latency
transmission using relative short messages delivered in an independently
atomic fashion (no head-of-line blocking).  Since this is somehow
different than "bulk data", i.e. emails, etc. it is "sort of" ok,
although SCTP is seen as the direction-of-choice for compliance with
proper Internet architecture. The odd thing is that "pager" mode
messages have exactly the same sort of requirements.

2) Some people have a "purity of model" approach and are offended by
mixing information with meta-information. That is, the putting of any
information into SIP besides that needed for the negotiation of sessions
external to SIP offends them. Of course, they also find the REGISTER
message, the INFO message, user-supplied bodies that are not SDP, and
other such mechanisms offensive in the same way. They may be right, but
SIP already mixes user and session-description information.

3) Some operators are concerned about a re-occurrence of the fundamental
signaling problem with SMS. As currently implemented, wireless
short-message-service transits user datagrams over SS7 links which also
transport the signaling for circuit-switced call establishement and
teardown. SS7 links are also very expensive and have to be highly
protected. As a result, these scarce resources get overloaded and
congest, and there's not efficient way to do prioritization between SMS
and other signaling over those links. Newer research in SMS has sought a
means to allocate transport outside of the primary SS7 path for moving
message bodies.

Some people see an an analog between the SS7 network and the role of SIP
proxies as signaling elements. Since the SIP proxies get mixed up in the
transference of SIP messages, they are seen as roughly similar to the
STPs and SMSCs in the SS7 network.

Warning: Philosophical Rant Follows

The key issue is buried deep in the underlying business model. In the
Internet world, you pay the same for the bits used to signal a
multimedia session as for the bits used by the multimedia session
itself. In the PSTN, the carriers pay for the signaling used to set up
the multimedia session. In other words, there is NO signaling, as
signaling is used in the PSTN sense, on the Internet -- just application
traffic. There might be messaging applications, routing applications,
management applications, or multimedia applications, but they're just
all applications as far as the underlying network in concerned. In the
PSTN, signaling actually traverses a separate, specialized network,
driven by its own economic laws.

In the Internet world view, if an application generates profits and
adding more servers allows it to generate more profit, then the
application gets more servers. But in the PSTN model, signaling is COST
and never actually generates profit -- it merely allows the
establishment of sessions or the delivery of messages, and it is the
sessions or messages which generate the profit. Signaling is just a cost
of doing business, and there's no good way to pass it directly on to the
consumer or even charge it back to the application, so it always gets
shorted. Given the fundamental laws of economics, the shortage of a
useful resource increases its value, so signaling traffic becomes much
more highly-protected and the efficiency of the signaling paramount.
Running on its separate, tightly-controlled and carefully managed
network, PSTN signaling takes on an almost religious significance. It's
DIFFERENT from user or application data, and SPECIAL. I seem to remember
from my days in PSTN design that it took "two years and two million
dollars" to get clearance to connect to the core SS7 network. Of course,
this mean that no new applications git built, but it's the model the
phone-types understand.

But there's really a deep fundamental difference between PSTN and
Internet models. In a pure SIP network, we expect Internet-like
end-to-end routability at layer 3. Once I know your contact information,
I can send messages directly to you. This doesn't really exist in SS7.
SIP proxies provide "layer 4 routing" functions like STPs, but only if
needed by the endpoints. However, circuit-switched mindsets are leading
to the development of SS7-like networks using SIP and IP, where the
end-to-end- path at layer 3 is established ONLY if authorized by
higher-layer (SIP) traffic which has transited the "trunking points" of
operator proxies operating from within "walled gardens". In other words,
they're insisting on reinventing the entire SS7 problem, and shouldn't
be at all surprised when the issues that were so constraining in the SS7
world strike again. 

One of the issues that comes out is that PSTN types don't know how to
charge for signaling -- they only know how to charge for the RESULTS of
signaling. Therefore, it is important to them to tightly control the
sorts of signaling that a user can do, because if a user does some kind
of signaling that does something besides set up a session that they know
how to charge for, that user is "stealing resources". As a consequence,
PSTN-logic requires that the operator UNDERSTAND all signaling, and
anything that isn't understood signaling needs to be relegated to
transport controlled-by-signaling or just plain blocked.

I'm continually approached by phone operators who start out by saying
something like "We'll never implement the SIP MESSAGE method. Since it
goes over our proxy network with user-supplied data, we have no way to
charge for it and it allows users to steal network resources." I respond
with something like "Well, the charging model of 3GPP/3GPP2 allows us to
write a charging record indicating who sent the message, who received
it, and how big it was. Given that, you should be able to charge for
each one of these messages at whatever rate the business will bear." The
first response is something like "We can't do that, this is the
SIGNALING network. What if we run out of capacity?" Then they stop and
think about it. Sometimes, virtual dollar signs ($^$) light up in their
eyes. Other times they wander off mumbling at/about me. But it's clearly
an alien philosophy.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2002 17:43:36 -0500

Dean,

Thank you for the informative "Philosophical Rant". What you say makes a lot of sense to me. But in the end I don't much care, as long as the people who do care settle
their differences so we can decide on *something*.

My need is for session oriented IM, in the sense that it can be negotiated as one of possibly many media in a call, that may or may not be conferenced. What channel it gets
transmitted over is not important to me as long as it works and has reasonable latency. I have no objection to the presence of page mode IM as well, and have some uses in
mind for it too. I also have no objection to page mode and session mode IM using the same paths, if all the flow control issues can be resolved.

To me the main problem is having some closure on how session mode IM is specified in SDP.

	Paul

---

From: Vasilis Polychronidis <[email-masked]>
Date: Mon, 11 Mar 2002 20:28:14 -0800

Dear Dean,
I would have agreed with your thinking if:
1. buying a SIP proxy costs as much as to buy a HTTP proxy
2. messaging traffic had the same Quality of Service (QOS) requirements and
signaling (setting up IP calls).
Since none of the above statements are true I do not agree with your
thinking.

For example in order to guarantee that you get 0.1% blocking on IP call
signaling you will have to over provision
your SIP proxies in order to handle the additional messaging traffic.
However since the messaging traffic does not
require the same QOS as signaling you will be wasting a lot of capacity.
In other words your cost for transporting messaging data will be the same as
the signaling one.

Another example: Since SIP proxies and especially CSCFs (3GPP term for
specialized SIP proxies) costs more than
plain HTTP proxies (for the conferencing case) or IP routers (for the end to
end case) then IM service providers will
have to incur all this extra cost for doing IM via SIP proxies.

There are no philosophical differences here just basic engineering and
economics.

-Vasilis

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 12 Mar 2002 00:10:20 -0600

Hey, it's not MY fault that 3GPP made their proxies too complicated and therefore expensive.

Do you have a better answer for meeting the European privacy requirements?

--
Dean
  ----- Original Message ----- 
  From: Vasilis Polychronidis 
  To: Dean Willis 
  Cc: 'Paul Kyzivat' ; 'Sean Olson' ; 'Petri K. Koskelainen' ; 'Jonathan Rosenberg' ; [email-masked] 
  Sent: Monday, March 11, 2002 10:28 PM
  Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading)

  Dear Dean, 
  I would have agreed with your thinking if: 
  1. buying a SIP proxy costs as much as to buy a HTTP proxy 
  2. messaging traffic had the same Quality of Service (QOS) requirements and signaling (setting up IP calls). 
  Since none of the above statements are true I do not agree with your thinking. 
  For example in order to guarantee that you get 0.1% blocking on IP call signaling you will have to over provision 
  your SIP proxies in order to handle the additional messaging traffic. However since the messaging traffic does not 
  require the same QOS as signaling you will be wasting a lot of capacity. 
  In other words your cost for transporting messaging data will be the same as the signaling one. 

  Another example: Since SIP proxies and especially CSCFs (3GPP term for specialized SIP proxies) costs more than 
  plain HTTP proxies (for the conferencing case) or IP routers (for the end to end case) then IM service providers will 
  have to incur all this extra cost for doing IM via SIP proxies. 

  There are no philosophical differences here just basic engineering and economics. 

  -Vasilis 

  Dean Willis wrote: 

    -- 
    Dean

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 12 Mar 2002 16:29:58 -0600

> The key issue is buried deep in the underlying business 
> model. In the Internet world, you pay the same for the bits 
> used to signal a multimedia session as for the bits used by 
> the multimedia session itself. In the PSTN, the carriers pay 
> for the signaling used to set up the multimedia session. In 
> other words, there is NO signaling, as signaling is used in 
> the PSTN sense, on the Internet -- just application traffic. 
> There might be messaging applications, routing applications, 
> management applications, or multimedia applications, but 
> they're just all applications as far as the underlying 
> network in concerned. In the PSTN, signaling actually 
> traverses a separate, specialized network, driven by its own 
> economic laws.
> 

Reference remaining rant elsewhere.

Here's an example.

-----------
From last year's Next Steps in Signaling BOF:

6.5 James Kempf
   Radio access networks - air is expensive.  Optimize by using less
   bandwidth and more (for example) CPU cycles. Whatever the signaling
   protocol is, it must be very efficient for mobility. Providers pay
   big $$ for the airwaves, they don't want  to use it for signaling,
   but for user data.  Best: do the signaling through the backbone, and
   not over the air if possible.  The signaling must be efficient for
   mobility to minimize signaling while moving from area to area.
   Mobility signalling should be directly coupled to the traffic.
-------------

See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt

Clearly from the provider perspective, user data and signaling are two
different things. Therein lies the debate. For if a user were to do
something that "looks like" signaling, they would intrude on the
territory of the operator.

The problem here: is Messaging the same as signaling? Is Presence the
same as signaling? Is anything we do with SIP really "signaling" or is
it user data?

--
Dean

---

From: Michael Hammer <[email-masked]>
Date: Wed, 13 Mar 2002 10:40:40 -0500

Dean,

There are some things users care about and will pay for, and other things
they won't.  For connection oriented services, they consider the
"air time" when they have full cut-through to when they get
disconnected to be the value.  In connectionless services, they care
about data packets getting through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them
to pay for signaling as well as data-bearing messages.  This is
analogous to making customers pay for packaging, when all they want is
the handful of tablets in the little bottle inside the big box.

Near where I live there is an ice-skating rink that charges by the
hour.  Most people won't put up including in that hour the time
taken to fill out forms and select skates.  Nor would they pay for
time where they are standing in line for that process.  Not standing
in line, getting to the rink sooner, and skating a full hour have
value.

This is not just the service provider perspective, but the customer
perspective.

It's OK to get philosophical, just keep it real. :)

Mike

Here's an example.

-----------

6.5 James Kempf

Radio access networks - air is expensive.  Optimize by
using less

bandwidth and more (for example) CPU cycles. Whatever the
signaling

protocol is, it must be very efficient for mobility.
Providers pay

big $$ for the airwaves, they don't want  to use it for
signaling,

but for user data.  Best: do the signaling through the
backbone, and

not over the air if possible.  The signaling must be
efficient for

mobility to minimize signaling while moving from area to
area.

Mobility signalling should be directly coupled to the
traffic.

-------------

See
http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt

Clearly from the provider perspective, user data and signaling are
two

something that "looks like" signaling, they would intrude on
the

The problem here: is Messaging the same as signaling? Is Presence
the

same as signaling? Is anything we do with SIP really
"signaling" or is

it user data?

--

Dean

simple mailing list

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 13 Mar 2002 11:18:57 -0600

----- Original Message -----
From: Michael Hammer
...
There are some things users care about and will pay for, and other
things they won't.  For connection oriented services, they consider the
"air time" when they have full cut-through to when they get disconnected
to be the value.  In connectionless services, they care about data
packets getting through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them to
pay for signaling as well as data-bearing messages.  This is analogous
to making customers pay for packaging, when all they want is the handful
of tablets in the little bottle inside the big box.
--------------------------

No. Actually, I think time-based services, especially in a messaging
context, are a silly idea.

This is the Internet. People CHOOSE what applications they are going to
run. One of the reasons they choose A over B might be that A is more
efficient in the way it signals.

In your model, people are still paying for the packaging (it's ALWAYS
wrapped up in the cost of the product) but since you're hiding it from
them and mandating the format, they have no incentive and no mechanism
to encourage efficiency.

Here's an example. I read my mail frequently over GSM circuit-switched
data at 9600 bps. This is expensive. So I use SSH with compression,
which beefs up the security immensely and generally saves me about 25%.
Now, what part of that traffic was signaling, and what part application?
I'd say only the GSM control traffic that set up the call was
"signaling" and everything I sent over the circuit, i.e. all my IP data,
was application.How is this different from what we're talking about with
SIMPLE?

The INTERNET is not a circuit switched phone network, and it's not so
simple as phone people assume to differentiate signaling from
application data.

But this has gotten rather far afield for this list.

--
Dean

---

From: Michael Hammer <[email-masked]>
Date: Wed, 13 Mar 2002 14:05:35 -0500

Dean,

Agree with the general sentiment of your reply.  But, inherent in
your previous emails was the idea that the service provider could somehow
get revenue from the IMs intermingled with the session setup messages to
cover the cost of over-provisioning the proxies to cover peak IM storms,
yet keep signaling message delay low.

This lead to the thought that you must charge per message for both IM
(data) and for SIP messages (signaling).  All I was questioning was
whether the user will see the value in paying for the signaling, that for
the most part is invisible to him, and perhaps beyond his control to
account for.  I see that as problematic.

Simply redesigning to make something that once was network internal to be
user-provided does not mean the user will appreciate why he pays
more.

Mike

At 11:18 AM 3/13/2002 -0600, Dean Willis wrote:

----- Original Message -----

From: Michael Hammer

...

things they won't.  For connection oriented services, they consider
the

disconnected

to be the value.  In connectionless services, they care about
data

You seem to be suggesting that the customer pay for the time they
spend

to

pay for signaling as well as data-bearing messages.  This is
analogous

to making customers pay for packaging, when all they want is the
handful

No. Actually, I think time-based services, especially in a
messaging

This is the Internet. People CHOOSE what applications they are going
to

run. One of the reasons they choose A over B might be that A is
more

In your model, people are still paying for the packaging (it's
ALWAYS

wrapped up in the cost of the product) but since you're hiding it
from

them and mandating the format, they have no incentive and no
mechanism

to encourage efficiency.

Here's an example. I read my mail frequently over GSM
circuit-switched

which beefs up the security immensely and generally saves me about
25%.

Now, what part of that traffic was signaling, and what part
application?

"signaling" and everything I sent over the circuit, i.e. all my
IP data,

was application.How is this different from what we're talking about
with

SIMPLE?

The INTERNET is not a circuit switched phone network, and it's not
so

application data.

--

Dean

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 Mar 2002 14:47:15 -0600

You example only works when you apply a billing model (per minute billing)
to a medium (IP applications) where it doesn't make sense. Indeed, I think
the per-minute model is not so much expected by users--it is just the
carriers don't know how to bill any other way.

If you applied a more IP Centric billing model (charge per byte), then you
can easily charge for signal and user data the same way. My GPRS service
provider charges for GPRS data in exactly this manner--if I run a SIMPLE
service across it, they just see bytes. A signal byte and a user byte are
indistinguishable.

My personal nightmare is hearing that carriers want to charge X per byte,
except for bytes that were in SIP messages.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Michael Hammer
Sent: Wednesday, March 13, 2002 9:41 AM
To: Dean Willis
Cc: 'Dean Willis'; 'Paul Kyzivat'; [email-masked]
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to
do wit message threading)

Dean,

There are some things users care about and will pay for, and other things
they won't.  For connection oriented services, they consider the "air time"
when they have full cut-through to when they get disconnected to be the
value.  In connectionless services, they care about data packets getting
through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them to pay
for signaling as well as data-bearing messages.  This is analogous to making
customers pay for packaging, when all they want is the handful of tablets in
the little bottle inside the big box.

Near where I live there is an ice-skating rink that charges by the hour.
Most people won't put up including in that hour the time taken to fill out
forms and select skates.  Nor would they pay for time where they are
standing in line for that process.  Not standing in line, getting to the
rink sooner, and skating a full hour have value.

Mike

Here's an example.

-----------

6.5 James Kempf

--
Dean

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________ simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 Mar 2002 14:58:26 -0600

I think think I agree with Dean in that it is not so much the _group_ aspect
as the _chat_ aspect that indicates the use of a session. There are
perfectly good page mode applications for groups.

It is the _conference_ aspects that make sessions interesting--things like
knowing who is participating at any time, association with other media
streams, etc.

If all I want to do is send a quick, short message to multiple people, I
rather hope I do not have to set up a session to do it.

> [mailto:[email-masked]]On Behalf Of Dean Willis
> Sent: Saturday, March 09, 2002 3:42 PM
> To: Jonathan Rosenberg; Petri K. Koskelainen
> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt
> (threading)
>
>
> Jonathan asked:

---

From: Michael Hammer <[email-masked]>
Date: Wed, 13 Mar 2002 17:42:28 -0500

Ben,

When you consider RTP over IP, which fits your "IP application" definition, 
whether you charge per packet or realize that statistically X packets and Y 
minutes is "six of one, half a dozen of the other" then there are some 
models where per minute works out to be the same value.

How do you reconcile volume charging with the two things that I noticed 
about my two services:  ISP:  Bills me a flat monthly fee for data 
service.  Mobile phone:  Bills me flat monthly fee for phone service, with 
per minute charges above an agreed on number of "free" minutes.  It didn't 
used to be like that.  Seems you are suggesting a trend-reversal or at 
least an exception to the rule.

The earlier models of charging per data connection minute or per minute of 
call did not encourage usage and therefore generate enough revenue.  Per 
byte charges can generate revenue, but only if it doesn't discourage use.

Will the per-byte prices be low enough to encourage use, yet still cover 
the cost of over-provisioning the network to keep setup delay low?  Will 
connection-less IM users pay a premium to make sure that 
connection-oriented RTP-flow users don't experience setup delays?  Tell me, 
who pays for excess capacity?  This could be a competitive discriminator.

Mike

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 13 Mar 2002 17:04:06 -0600

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2002 4:42 PM
> To: Ben Campbell
> Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat';
> Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something
> to do wit message threading)
>
>
> Ben,
>

But this only works for rtp type applications, and I fully expect to run
other IP applications as well. You very quickly fall into the twilight zone
of cross-layer usage counting, where you charge per minute for RTP traffic,
but per byte for others.
> least an exception to the rule.

Yes, it is a trend reversal. Your ISP charges you flat rate because that is
what the market pretty much requires. But, if you have a residential level
of service, they probably also have policies that let them harrass you if,
in their sole opinion, you are using to many bytes in your so-called
unlimited flat rate service--creating a whole new class of double-speak
about limited unlimited service. A per-byte usage, where the per byte cost
for the average user added up to the same as the flat rate price would do
much to rationalize these plans. (And of course, flat rate plans are a bit
of a red-herring in this discussion--if you aren't billing for bytes
_or_minutes_ then who cares if they are user data or signal data?)

As for the mobile phone, they are charging per-minute for holding up
wireless network resources. I am glad to see that the GPRS carriers in the
US are _not_ trying to shoehorn per-minute billing for GPRS data. (Their
per-byte charges are rediculously high, but that is another problem)

> who pays for excess capacity?  This could be a competitive discriminator.

These are all business model issues that are equally true in flat-rate and
per-minute models. I assert that an IP carrier that can figure out how to
price and market a per-byte service will have a significant competitive
advantage over an IP carrier that tries to perserve a legacy per-minute
model--even if the average revenue per subscriber is identical. This is due
to simpler network accounting and management if for no other reason.

Figuring out how to price and market it such a service is business magic,
not engineering magic.

> "air time"

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Mar 2002 18:09:35 -0500

While it is nice to get something for nothing, in the long term somebody has to pay for the infrastructure that provides the bandwidth. Personally, I would not mind paying
for usage based on a fair metric. Charging per byte makes sense, while charging for elapsed time does not. Charging for guaranteed bandwidth over some time period might
make sense, but more likely it would make sense to charge more per byte for higher priority bytes.

What would be really unfair would be to use the same channel, with the same bandwidth guarantees and charge one price for IM bytes and a different price for voice bytes.

If you are charging by the byte, people have an incentive to balance better quality against the cost of the extra bytes needed to deliver that quality.

Charged by the byte, IM won't be free, but may seem to be because it uses vastly fewer bytes than even a short voice message, and can get by with with lower priority
service as well.

As long as signalling bytes used for call setup travel the same network as the voice bytes, and are billed at the same rate, it is unlikely that callers would notice much
effect on their bills because the quantities are so much smaller than for voice content. The most noticable factor might be due to roundoff - an unsuccessful call might be
charged at $0.01 rather than being free. 

The excess capacity required to provide good service can hopefully be recovered in the surcharge for priority service.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Mar 2002 18:20:28 -0500

> Figuring out how to price and market it such a service is business magic,

To me the attractiveness of this model is that it is a fairer model - more consistent with resources consumed.

The trick is that this has to be perceived as fair by the people purchasing the service. I can be comfortable with per-byte billing once I figure out how much a typical
phone call will cost me. But my mother will probably never perceive per-byte billing as fair because she will never understand what it means.

I can imagine two pricing models coexisting. Some people might simply have per-byte network access charges, and be free to run voice, data, whatever over them using
equipment of their choice. Others might contract for by-the-minute or flat-rate phone service, with the service provider providing the network access and the devices that
use it.

	Paul

---

From: Michael Hammer <[email-masked]>
Date: Wed, 13 Mar 2002 19:04:02 -0500

Paul,

As long as signaling gets priority over IM and doing session setup doesn't 
turn into a world wide wait, I can go along with running the packets over 
the same infrastructure.

Mike

At 06:09 PM 3/13/2002 -0500, Paul Kyzivat wrote:
>While it is nice to get something for nothing, in the long term somebody 
>has to pay for the infrastructure that provides the bandwidth. Personally, 
>I would not mind paying
>for usage based on a fair metric. Charging per byte makes sense, while 
>charging for elapsed time does not. Charging for guaranteed bandwidth over 
>some time period might
>What would be really unfair would be to use the same channel, with the 
>same bandwidth guarantees and charge one price for IM bytes and a 
>different price for voice bytes.
>
>If you are charging by the byte, people have an incentive to balance 
>better quality against the cost of the extra bytes needed to deliver that 
>quality.
>
>Charged by the byte, IM won't be free, but may seem to be because it uses 
>vastly fewer bytes than even a short voice message, and can get by with 
>with lower priority
>service as well.
>
>As long as signalling bytes used for call setup travel the same network as 
>the voice bytes, and are billed at the same rate, it is unlikely that 
>callers would notice much
>effect on their bills because the quantities are so much smaller than for 
>voice content. The most noticable factor might be due to roundoff - an 
>unsuccessful call might be
>The excess capacity required to provide good service can hopefully be 
>recovered in the surcharge for priority service.
>
>         Paul
>
>Michael Hammer wrote:
> >
> > Ben,
> >
> to pay

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Mar 2002 19:15:29 -0500

Talking about charging: cost-per-byte has very little relationship to
real costs. After all, the incremental cost of sending a byte in a
network that is not fully loaded is very close to zero, wireless or
otherwise, since almost all the costs are fixed costs. From a provider
perspective, you want to charge according to willingness to pay, not
cost. There is a reason airlines don't charge per hour flight time or
per mile flown.

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 13 Mar 2002 21:50:03 -0800

So does this imply that every SIP message that transpires the network will need
introspection to check if it has an embedded mime type? I am sure this will be an
issue with regards to signalling performance.

regards,

Bobby Sardana.
[email-masked]

---

From: Michael Hammer <[email-masked]>
Date: Thu, 14 Mar 2002 10:03:18 -0500

Henning,

Yes, but someone has to pay the debt schedule.  Over what period are you 
amortizing the fixed cost of the network?  15 years like telephone 
switches?  The balance sheet still has to make sense, even if the revenue 
and costs are not directly coupled.

Mike

At 07:15 PM 3/13/2002 -0500, Henning Schulzrinne wrote:
> > While it is nice to get something for nothing, in the long term 
> somebody has to pay for the infrastructure that provides the bandwidth. 
> Personally, I would not mind paying
> charging for elapsed time does not. Charging for guaranteed bandwidth 
> over some time period might
> > Charged by the byte, IM won't be free, but may seem to be because it 
> uses vastly fewer bytes than even a short voice message, and can get by 
> with with lower priority
> > service as well.
> >
> > As long as signalling bytes used for call setup travel the same network 
> as the voice bytes, and are billed at the same rate, it is unlikely that 
> > effect on their bills because the quantities are so much smaller than 
> for voice content. The most noticable factor might be due to roundoff - 
> an unsuccessful call might be
> things

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Mar 2002 10:20:13 -0500

Certainly - just like for airplanes. In both network and airline cases,
you care about getting the most money from your customers. Basic
economics tells you that you want to differentiate charging not just by
volume, but by willingness to pay. If number of bytes used is a
first-order approximation to willingness to pay, it may not be a bad
thing. However, note all the weekend/evening plans that were (are?)
popular for wireless to separate the business vs. consumer spending
willingness, or the various business vs. consumer plans for DSL. An
'empty' byte on a wireless network has the same properties as an empty
seat on an airplane - the owner of that byte or seat is going to do
anything to sell it before it leaves base, as long as they can keep
their existing customers that paid more from grabbing the better deal.

(This has strayed far beyond SIMPLE; if you're interested in the
analysis of this for QOS, I can point you to some papers we have written
on this topic.)

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 14 Mar 2002 10:24:10 -0500

> Michael Hammer
> Sent: Wednesday, March 13, 2002 5:42 PM
> To: Ben Campbell
> Subject: RE: [Simple] Messages: Signaling, Data, or Theft 
> (Was something to do wit message threading)
> 
> 
> Ben,
> 
Huh? What if I adaptively change my packetization perdiod based on
changes in loss patterns an end-to-end delay? If you do that you have to
count both bytes and packets and once you've done that minutes are
irrelevant (unless you want to gouge the user for silence periods). The
only time minutes might be relevant is if you want to charge for
*reserved resources*. If you do that, then you have the converse
situation - the only thing relevant to billing is the time the requested
resources are reserved, and bytes and packets don't matter.

The trap, as others have pointed out is to try to charge based on the
color of the bits, as opposed to what (if anything) the network does
with the bits.
 
> who pays for excess capacity?  This could be a competitive 
All of this completely confounds *accounting* with *billing*. If you
don't account for anything other than the existence of a subscription,
then all you can do is flat-rate bill. If you count something, you can
certainly bill for it, but you don't HAVE to, and the discussion is no
longer technical but marketing, sales, and macro-economics.

As a side note, accounting (but not billing!) falls out of nearly any
QoS capability, since you need to count things in order to police and
shape traffic.

Dave.
> >You example only works when you apply a billing model (per minute 
> >billing) to a medium (IP applications) where it doesn't make sense. 
> >Indeed, I think the per-minute model is not so much expected by 
> >users--it is just the carriers don't know how to bill any other way.
> >
> >If you applied a more IP Centric billing model (charge per 
> byte), then 
> >you can easily charge for signal and user data the same way. My GPRS 
> >service provider charges for GPRS data in exactly this 
> manner--if I run 
> >a SIMPLE service across it, they just see bytes. A signal byte and a 
> >user byte are indistinguishable.
> >
> >My personal nightmare is hearing that carriers want to charge X per 
> >byte, except for bytes that were in SIP messages.
> >
> >
> >handful of tablets in the little bottle inside the big box.
> >
> >hour. Most people won't put up including in that hour the 
> time taken to 
> >fill out forms and select skates.  Nor would they pay for time where 
> >they are standing in line for that process.  Not standing in line, 
> >getting to the rink sooner, and skating a full hour have value.
> >
> > > The key issue is buried deep in the underlying business model. In 
> > > the Internet world, you pay the same for the bits used to 
> signal a 
> > > itself. In the PSTN, the carriers pay for the signaling 
> used to set 
> > > up the multimedia session. In other words, there is NO 
> signaling, as 
> > > signaling is used in the PSTN sense, on the Internet -- just 
> > > application traffic. There might be messaging 
> applications, routing 
> > > applications, management applications, or multimedia 
> applications, 
> > > but they're just all applications as far as the underlying

---

From: Michael Hammer <[email-masked]>
Date: Thu, 14 Mar 2002 10:51:05 -0500

Henning,

Dave is right once you get beyond accounting for the traffic, billing is 
more an arbitrary business issue.

Back to what I perceive as the main technical question though:  Will 
session setup (signaling) packets get priority (within proxy processing) 
over IM packets such that session setup time is not impacted?  Or will 
users re-initiate after a second or two exacerbating the traffic load?  Or 
as some have suggested, does SIP traffic get segregated and travel over 
different proxies?  Does the protocol element exist to discriminate so?

Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Mar 2002 10:57:10 -0500

There are a number of techniques, e.g., I vaguely remember work
published recently related to web servers from folks at IBM, that allow
prioritization for different classes of requests. Thus, I just don't see
this as a protocol issue.