Subject: Re: [Sip] INFO

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 13:23:12 -0700

I have not checked, but I think IEEE journal papers run about US $5.  You
can get a monthly subscription that makes the rate way lower.  Your company
probably has a corporate subscription, or someone there most likely has an
IEEE Digital Library subscription, so again, the papers should be paid for.

Since the IEEE has a serious self-plagiarism policy, here is a *different*
way for seeing how KPML wins.

The vast bulk of a SIP message in a non-trivial network (i.e., with one or
more proxies) is the routing information (URI's, Via's, Route's, etc.).
Sure, a Zebarth INFO (the absolute smallest encoding for a DTMF digit) of 2
bytes is much smaller than a KPML NOTIFY, which can easily be 70 bytes.
However, when you have 1000 bytes of headers, 1002 and 1070 are pretty much
the same.

Given that, let us look at the counts.

KPML:
SUBSCRIBE (SIP Message)
Immediate NOTIFY (SIP Message)
Digit NOTIFY's...

DTMF:
Digit INFO's...

What does this mean?  It means that if you are on a shared media network
(wireless or 5BaseT), where each direction counts, we have:

               DTMF          KPML
# digits    # packets     # packets
    1            1            3
    2            2            3
    3            3            3       Common Star Codes (e.g., *69)
    4            4            3       Common PINs
    5            5            3
    6            6            3       Also common PINs
    7            7            3
    8            8            3
    9            9            3
   10           10            3       Common Supplementary Phone Number
   11           11            3       Common Supplementary Phone Number

One can quibble as to whether the cross over is at 3 or 4 digits, since KPML
packets are slightly larger than INFO packets.  However, at 3 digits the
argument goes in favor of a mechanism with negotiation, content security,
dialog security, works for HERFP, etc., etc.

At 4 digits, KPML unquestionably uses less bandwidth.

Of course, the numbers are even better for KPML on non-shared media
networks.

On 8/31/07 1:41 AM, "Hadriel Kaplan" <[email-masked]> wrote:

> Hey Eric,
> I read the draft and was especially interested in the claim that KPML
> consumed less bandwidth than INFO for DTMF.  You cite an IEEE paper, but I
> don't think that's freely available.  Can you summarize how you came to such
> a conclusion?  When I do the numbers, KPML often loses... in some scenarios
> by a LOT.  And it's not even just the extra bandwidth/messages, but also the
> state and processing horsepower.  There is one scenario where KPML wins, for
> some SIP boxes but not others.
> Although that could all be because I either don't correctly understand the
> actual way KPML would be used, or because the use cases I am concerned with
> are not the same as those in your paper's analysis.
> 
> -hadriel
> 
> 
>> -----Original Message-----
>> From: Eric Burger [mailto:[email-masked]]
>> Sent: Tuesday, August 21, 2007 5:37 PM
>> To: 'sip'
>> Subject: [Sip] INFO
>> 
>> Since list traffic is down, how about something to spice things up?
>> 
>> 
>> Any thoughts on
>> 
>> http://www.ietf.org/internet-drafts/draft-burger-sip-info-01.txt
>> 
>> ???
>> 
>> If you like it, say so.  If you hate it, say so.
>> 
>> Text welcome.
>> 
>> 
>> 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.
>> 
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip
> 
> 

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.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 13:23:12 -0700

KPML:
SUBSCRIBE (SIP Message)

DTMF:
Digit INFO's...

               DTMF          KPML

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 13:23:12 -0700

KPML:
SUBSCRIBE (SIP Message)

DTMF:
Digit INFO's...

               DTMF          KPML

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 4 Sep 2007 19:30:01 -0500

Well, that's because you use the worst-case for INFO, and the best case
for 
KPML. Namely:

- Your example uses 1 message per digit for INFO. There is nothing that
  prevents you from sending *69 in one INFO message.

- Your example also uses the pattern mapping feature of KPML to
"optimize"
  the number of message.

My best guess is that in common deployment, what people are likely to
use is:

- INFO with 1 digit per message (as per your example)

- KPML with reporting of every digit pressed (unlike your example)

So in this case INFO actually wins in all cases.

Now, don't get me wrong: I'm not advocating the use of INFO for digit
mapping. I just
think this analysis is more theoretical than real.

And I'm quite unconvinced that digit pressing is a big factor in 
"computing power requirement" for the servers providing those services.

In short, I don't think "efficiency" is the main factor here.

> Sent: Tuesday, September 04, 2007 13:23
> To: Hadriel Kaplan
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> I have not checked, but I think IEEE journal papers run about 
> US $5.  You can get a monthly subscription that makes the 
> rate way lower.  Your company probably has a corporate 
> subscription, or someone there most likely has an IEEE 
> Digital Library subscription, so again, the papers should be paid for.
> 
> Since the IEEE has a serious self-plagiarism policy, here is 
> a *different* way for seeing how KPML wins.
> 
> The vast bulk of a SIP message in a non-trivial network 
> (i.e., with one or more proxies) is the routing information 
> (URI's, Via's, Route's, etc.).
> Sure, a Zebarth INFO (the absolute smallest encoding for a 
> DTMF digit) of 2 bytes is much smaller than a KPML NOTIFY, 
> which can easily be 70 bytes.
> However, when you have 1000 bytes of headers, 1002 and 1070 
> are pretty much the same.
> 
> What does this mean?  It means that if you are on a shared 
> media network (wireless or 5BaseT), where each direction 
> counts, we have:
> 
>                DTMF          KPML
> One can quibble as to whether the cross over is at 3 or 4 
> digits, since KPML packets are slightly larger than INFO 
> packets.  However, at 3 digits the argument goes in favor of 
> a mechanism with negotiation, content security, dialog 
> security, works for HERFP, etc., etc.
> 
> Of course, the numbers are even better for KPML on non-shared 
> media networks.
> 
> 
> > consumed less bandwidth than INFO for DTMF.  You cite an 
> IEEE paper, 
> > but I don't think that's freely available.  Can you 
> summarize how you 
> > came to such a conclusion?  When I do the numbers, KPML 
> often loses... 
> > in some scenarios by a LOT.  And it's not even just the extra 
> > bandwidth/messages, but also the state and processing horsepower.  
> > There is one scenario where KPML wins, for some SIP boxes 
> but not others.
> > Although that could all be because I either don't correctly 
> understand 
> > the actual way KPML would be used, or because the use cases I am 
> > concerned with are not the same as those in your paper's analysis.
> > 
> > -hadriel
> > 
> > 
> >> 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.
> >> 
> >> 
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> > 
> > 
> 
> 
> 
> 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.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 22:17:17 -0700

I would offer this is "apples-to-apples":

If INFO is buffering digits, you have to tell it to, e.g., register a digit
map.  In that case, INFO loses a packet round-trip, KPML is all of one extra
round trip.  Small price to pay for interoperability.

If one uses the pattern <regex>.</regex>, then KPML is all of two extra
round trips.  I agree, that could be "bad" if you have a VERY large volume
of instances where one is polling for a single digit.  However, if you do
not have a large volume of instances of a single digit, the overhead is
insignificant.  On the contrary, if you have any decent number of digits
being collected one-by-one, then I would offer the two subscription
round-trips get swamped by the number of digit reports, and the fact a KPML
digit report is 7% larger than the most ideal INFO message (which, by the
way, I don't think anyone has implemented), that is noise, as well.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 7 Sep 2007 16:21:32 -0400

But there are cases where the KPML model is vastly greater overhead.  

Consider a typical voicemail server.  For calls to the voicemail server to
retrieve messages, KPML is probably good because you can define a digit map
for the mailbox number and password which would reduce overall message
counts.  But for calls to leave a voicemail (which I assume greatly
outnumber those to retrieve them, but you would know more about that than
I), KPML has to create a subscription for every single call, just in case
the caller happens to press some optional dtmf that the voicemail app
supports.  For each and every call, a subscription has to be routed and its
state saved by stateful proxies along the path to the UAs, even though only
a small fraction of the calls ever press a DTMF button.  

But of course that voicemail server could just do 2833/4733 instead, if the
UA's supported it.  So then consider a SIP to PSTN or H.323 gateway.  The
PSTN or H.323 gateway has no knowledge that one call needs DTMF vs. another
- it has to send and receive them for all calls.  It could use 2833/4733,
but very few H.323 devices support 2833, and for whatever reason some PSTN
gateways don't either. (MGCP-controlled ones I think)  So the gateway or its
controller would have to KPML-subscribe for every single call from SIP to
the PSTN or H.323 side, with no real digit map possible.  The amount of
dialog state and messaging for DTMF would actually get somewhere near that
required for the actual call signaling, and yet only a fraction of the calls
would ever send a single DTMF tone!

And that's the basic issue.  For applications where the probability of DTMF
actually being sent is very high, and for which digit mapping can save
messages, KPML makes sense (if everyone supported it).  But those are the
kind of applications where the extra cost of additional messaging caused by
INFO is actually warranted - you have an app that needs a lot of messaging,
then you pay the price for it.  But conversely for other apps, ones which
don't need much dtmf, expecting them to pay the overhead penalty for a KPML
model makes no sense. 

-hadriel

> Sent: Wednesday, September 05, 2007 1:17 AM
> To: Francois Audet
> Cc: sip
> Subject: Re: [Sip] INFO
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 7 Sep 2007 15:51:39 -0500

Exactly.

Or almost any Enteprise scenario. 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 13:22
> To: 'Eric Burger'; Audet, Francois (SC100:3055)
> Cc: 'sip'
> Subject: RE: [Sip] INFO
> 
> Consider a typical voicemail server.  For calls to the 
> voicemail server to retrieve messages, KPML is probably good 
> because you can define a digit map for the mailbox number and 
> password which would reduce overall message counts.  But for 
> calls to leave a voicemail (which I assume greatly outnumber 
> those to retrieve them, but you would know more about that 
> than I), KPML has to create a subscription for every single 
> call, just in case the caller happens to press some optional 
> dtmf that the voicemail app supports.  For each and every 
> call, a subscription has to be routed and its state saved by 
> stateful proxies along the path to the UAs, even though only 
> But of course that voicemail server could just do 2833/4733 
> instead, if the UA's supported it.  So then consider a SIP to 
> PSTN or H.323 gateway.  The PSTN or H.323 gateway has no 
> knowledge that one call needs DTMF vs. another
> - it has to send and receive them for all calls.  It could 
> use 2833/4733, but very few H.323 devices support 2833, and 
> for whatever reason some PSTN gateways don't either. 
> (MGCP-controlled ones I think)  So the gateway or its 
> controller would have to KPML-subscribe for every single call 
> from SIP to the PSTN or H.323 side, with no real digit map 
> possible.  The amount of dialog state and messaging for DTMF 
> would actually get somewhere near that required for the 
> actual call signaling, and yet only a fraction of the calls 
> And that's the basic issue.  For applications where the 
> probability of DTMF actually being sent is very high, and for 
> which digit mapping can save messages, KPML makes sense (if 
> everyone supported it).  But those are the kind of 
> applications where the extra cost of additional messaging 
> caused by INFO is actually warranted - you have an app that 
> needs a lot of messaging, then you pay the price for it.  But 
> conversely for other apps, ones which don't need much dtmf, 
> expecting them to pay the overhead penalty for a KPML model 
> makes no sense. 
> 
> -hadriel
> 
> > If INFO is buffering digits, you have to tell it to, e.g., 
> register a 
> > digit map.  In that case, INFO loses a packet round-trip, 
> KPML is all 
> > of one extra round trip.  Small price to pay for interoperability.
> > 
> > If one uses the pattern <regex>.</regex>, then KPML is all of two 
> > extra round trips.  I agree, that could be "bad" if you have a VERY 
> > large volume of instances where one is polling for a single digit.  
> > However, if you do not have a large volume of instances of a single 
> > digit, the overhead is insignificant.  On the contrary, if you have 
> > any decent number of digits being collected one-by-one, 
> then I would 
> > offer the two subscription round-trips get swamped by the number of 
> > digit reports, and the fact a KPML digit report is 7% 
> larger than the 
> > most ideal INFO message (which, by the way, I don't think 
> anyone has 
> > implemented), that is noise, as well.
> > 
> > 
> > > Well, that's because you use the worst-case for INFO, and 
> the best 
> > > case for KPML. Namely:
> > >
> > > My best guess is that in common deployment, what people 
> are likely 
> > > to use is:
> > >
> > > Now, don't get me wrong: I'm not advocating the use of INFO for 
> > > digit mapping. I just think this analysis is more 
> theoretical than 
> > > real.
> > >
> > >> I have not checked, but I think IEEE journal papers run about US 
> > >> $5.  You can get a monthly subscription that makes the rate way 
> > >> lower.  Your company probably has a corporate subscription, or 
> > >> someone there most likely has an IEEE Digital Library 
> subscription, 
> > >> so again, the papers should be paid for.
> > >>
> > >> Since the IEEE has a serious self-plagiarism policy, here is a 
> > >> *different* way for seeing how KPML wins.
> > >>
> (i.e., with 
> > >> one or more proxies) is the routing information (URI's, Via's, 
> > >> Route's, etc.).
> > >> Sure, a Zebarth INFO (the absolute smallest encoding for a DTMF 
> > >> digit) of 2 bytes is much smaller than a KPML NOTIFY, which can 
> > >> easily be 70 bytes.
> > >> However, when you have 1000 bytes of headers, 1002 and 1070 are 
> > >> pretty much the same.
> > >>
> > >> What does this mean?  It means that if you are on a shared media 
> > >> network (wireless or 5BaseT), where each direction 
> counts, we have:
> > >>
> > >>                DTMF          KPML
> > >> One can quibble as to whether the cross over is at 3 or 
> 4 digits, 
> > >> since KPML packets are slightly larger than INFO 
> packets.  However, 
> > >> at 3 digits the argument goes in favor of a mechanism with 
> > >> negotiation, content security, dialog security, works for HERFP, 
> > >> etc., etc.
> > >>
> > >>>> copyrighted  and/or legally privileged, and is intended solely 
> > >>>> for the use of the individual or entity named in this message.
> > >> If you are
> > >> the use of the individual or entity named in this 
> message. If you 
> > >> are not the intended recipient, and have received this 
> message in 
> > 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,

---

From: "Jackson, James" <[email-masked]>
Date: Fri, 7 Sep 2007 15:53:49 -0500

For the majority of call flows, I would expect RFC2833/4733 to be
sufficient, especially for applications like voicemail. However, it is
insufficient when you get into more complex scenarios like attended call
transfers where the media is ideally released but the App must still
process DTMF (ex. transferee hits key to disconnect transfer target and
return to menu). It seems that the best solution would be to use RFC2833
and only subscribe to KPML as needed.

James

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 3:22 PM
To: 'Eric Burger'; 'Francois Audet'
Cc: 'sip'
Subject: RE: [Sip] INFO

Consider a typical voicemail server.  For calls to the voicemail server
to
retrieve messages, KPML is probably good because you can define a digit
map
for the mailbox number and password which would reduce overall message
counts.  But for calls to leave a voicemail (which I assume greatly
outnumber those to retrieve them, but you would know more about that
than
I), KPML has to create a subscription for every single call, just in
case
the caller happens to press some optional dtmf that the voicemail app
supports.  For each and every call, a subscription has to be routed and
its
state saved by stateful proxies along the path to the UAs, even though
only
a small fraction of the calls ever press a DTMF button.  

But of course that voicemail server could just do 2833/4733 instead, if
the
UA's supported it.  So then consider a SIP to PSTN or H.323 gateway.
The
PSTN or H.323 gateway has no knowledge that one call needs DTMF vs.
another
- it has to send and receive them for all calls.  It could use
2833/4733,
but very few H.323 devices support 2833, and for whatever reason some
PSTN
gateways don't either. (MGCP-controlled ones I think)  So the gateway or
its
controller would have to KPML-subscribe for every single call from SIP
to
the PSTN or H.323 side, with no real digit map possible.  The amount of
dialog state and messaging for DTMF would actually get somewhere near
that
required for the actual call signaling, and yet only a fraction of the
calls
would ever send a single DTMF tone!

And that's the basic issue.  For applications where the probability of
DTMF
actually being sent is very high, and for which digit mapping can save
messages, KPML makes sense (if everyone supported it).  But those are
the
kind of applications where the extra cost of additional messaging caused
by
INFO is actually warranted - you have an app that needs a lot of
messaging,
then you pay the price for it.  But conversely for other apps, ones
which
don't need much dtmf, expecting them to pay the overhead penalty for a
KPML
model makes no sense. 

-hadriel

> If one uses the pattern <regex>.</regex>, then KPML is all of two
extra
> > Now, don't get me wrong: I'm not advocating the use of INFO for
digit
for
> Notice:  This email message, together with any attachments, may
contain

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 7 Sep 2007 13:59:58 -0700

Ding, ding, ding!!!

KPML is NOT for IVR.  INFO and KMPL lose terribly to VoiceXML (or MSCML
or MSML).

However, if you really want to recreate the PSTN...

Consider a PSTN call.  The call goes from the gateway to softswitch /
Proxy.  Proxy routes to VM App Server.  INFO has to pass through
softswitch / Proxy.  In KPML-land, VM App Server *directly* subscribes
to UAC key press state, bypassing the softswitch.  KPML and INFO have
the same number of messages for a SINGLE digit; KPML wins hands-down for
multiple digits or reports.

More importantly, let's take a Call Management (CM) application that
calls a VM application when they cannot find the subscriber.  INFO has
to pass through the softswitch / Proxy to the CM application.  Cool - it
is a proxy, so it knows to relay.  But OOPS!  The CM application has to
proxy the INFOs to the VM application.  Yes - you could be a good
programmer and remember to do that EVERYWHERE you place an outbound
call, but it is really easy to get wrong.  In KPML-land, the VM
application server not only *directly* subscribes to the UAC key press
state, but it will NOT get the key presses (like the ubiquitous long-#)
that are for the CM application.  Likewise, the CM application, which is
ONLY looking for long-#, won't get all of the VM key presses.  That
scenario is where KPML really kicks-butt.

By the way, I am deliberately using the provocative "softswitch" term
:-)

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 4:22 PM
To: Eric Burger; 'Francois Audet'
Cc: 'sip'
Subject: RE: [Sip] INFO

Consider a typical voicemail server.  For calls to the voicemail server
to retrieve messages, KPML is probably good because you can define a
digit map for the mailbox number and password which would reduce overall
message counts.  But for calls to leave a voicemail (which I assume
greatly outnumber those to retrieve them, but you would know more about
that than I), KPML has to create a subscription for every single call,
just in case the caller happens to press some optional dtmf that the
voicemail app supports.  For each and every call, a subscription has to
be routed and its state saved by stateful proxies along the path to the
UAs, even though only a small fraction of the calls ever press a DTMF
button.  

But of course that voicemail server could just do 2833/4733 instead, if
the UA's supported it.  So then consider a SIP to PSTN or H.323 gateway.
The PSTN or H.323 gateway has no knowledge that one call needs DTMF vs.
another
- it has to send and receive them for all calls.  It could use
2833/4733, but very few H.323 devices support 2833, and for whatever
reason some PSTN gateways don't either. (MGCP-controlled ones I think)
So the gateway or its controller would have to KPML-subscribe for every
single call from SIP to the PSTN or H.323 side, with no real digit map
possible.  The amount of dialog state and messaging for DTMF would
actually get somewhere near that required for the actual call signaling,
and yet only a fraction of the calls would ever send a single DTMF tone!

And that's the basic issue.  For applications where the probability of
DTMF actually being sent is very high, and for which digit mapping can
save messages, KPML makes sense (if everyone supported it).  But those
are the kind of applications where the extra cost of additional
messaging caused by INFO is actually warranted - you have an app that
needs a lot of messaging, then you pay the price for it.  But conversely
for other apps, ones which don't need much dtmf, expecting them to pay
the overhead penalty for a KPML model makes no sense. 

-hadriel

> If INFO is buffering digits, you have to tell it to, e.g., register a 
> digit map.  In that case, INFO loses a packet round-trip, KPML is all 
> any decent number of digits being collected one-by-one, then I would 
> digit reports, and the fact a KPML digit report is 7% larger than the 
> most ideal INFO message (which, by the way, I don't think anyone has 
> > Well, that's because you use the worst-case for INFO, and the best 
> > case for KPML. Namely:
> >
> > My best guess is that in common deployment, what people are likely 
> > to use is:
> >
> > digit mapping. I just think this analysis is more theoretical than 
> > real.
> >
> >> someone there most likely has an IEEE Digital Library subscription,

> >> The vast bulk of a SIP message in a non-trivial network (i.e., with

> >> network (wireless or 5BaseT), where each direction counts, we have:
> >>
> >>                DTMF          KPML
> >> One can quibble as to whether the cross over is at 3 or 4 digits, 
> >> since KPML packets are slightly larger than INFO packets.  However,

> >> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and

> >> the use of the individual or entity named in this message. If you 
> >> are not the intended recipient, and have received this message in 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
> 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

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 7 Sep 2007 14:01:27 -0700

RFC 4733 requires a media path to the application.  As a former Media
Server vendor, I think that is a great idea.  However, as a current
Application Server vendor, I am not looking to raise the cost of
deployment. 

-----Original Message-----
From: Jackson, James [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 4:54 PM
To: Hadriel Kaplan; Eric Burger; Francois Audet
Cc: sip
Subject: RE: [Sip] INFO

James

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Friday, September 07, 2007 3:22 PM
To: 'Eric Burger'; 'Francois Audet'
Cc: 'sip'
Subject: RE: [Sip] INFO

-hadriel

extra
> round-trips get swamped by the number of digit reports, and the fact a

> KPML digit report is 7% larger than the most ideal INFO message 
> (which, by
the
case
to
digit

for

contain

---

From: "Brian Stucker" <[email-masked]>
Date: Sun, 9 Sep 2007 23:15:38 -0500

> a small fraction of the calls ever press a DTMF button. 

Unless your voicemail users have a severe case of obsessive-compulsive
voicemailbox checking syndrome, and the users aren't checking their
mailboxes when they have no MWI indication, the number of deposits is
guaranteed to at least equal, and certainly exceed the number of
retrievals for any non-trivial population of subscribers. Otherwise,
you'd only need space for one voicemail in your mailbox. The fact that I
doubt anyone has ever heard of such a ridiculous voicemail limit seems
to confirm my assumptions.

Regards,
Brian

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Sep 2007 11:59:02 -0500

Hadriel, I don't get your example.

You would only get a KPML subscription for calls that actually terminate
to 
the voicemail server. And I would imagine that MOST calls to a voicemail
server
would actually use DTMF and therefore require a subscription. 

> From: Stucker, Brian (RICH1:AR00) 
> Sent: Sunday, September 09, 2007 21:16
> To: Hadriel Kaplan; 'Eric Burger'; Audet, Francois (SC100:3055)
> Cc: 'sip'
> Subject: RE: [Sip] INFO
> 
>  
> 
> > Consider a typical voicemail server.  For calls to the voicemail 
> > server to retrieve messages, KPML is probably good because you can 
> > define a digit map for the mailbox number and password which would 
> > reduce overall message counts.  But for calls to leave a voicemail 
> > (which I assume greatly outnumber those to retrieve them, but you 
> > would know more about that than I), KPML has to create a 
> subscription 
> > for every single call, just in case the caller happens to 
> press some 
> > optional dtmf that the voicemail app supports.  For each and every 
> > call, a subscription has to be routed and its state saved 
> by stateful 
> > proxies along the path to the UAs, even though only a small 
> fraction 
> > of the calls ever press a DTMF button.
> 
> Unless your voicemail users have a severe case of 
> obsessive-compulsive voicemailbox checking syndrome, and the 
> users aren't checking their mailboxes when they have no MWI 
> indication, the number of deposits is guaranteed to at least 
> equal, and certainly exceed the number of retrievals for any 
> non-trivial population of subscribers. Otherwise, you'd only 
> need space for one voicemail in your mailbox. The fact that I 
> doubt anyone has ever heard of such a ridiculous voicemail 
> limit seems to confirm my assumptions.
> 
> Regards,
> Brian
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 10 Sep 2007 15:42:12 -0400

But most calls to a voicemail server DON'T actually use DTMF, I've been told
- since most calls to a vmail server are to leave messages.  Calls to
retrieve voicemail do always use dtmf, but calls to leave voicemail don't.
However calls to leave voicemail usually have the optional ability for the
caller to send DTMF - for example pressing "*" and then the passcode to
retrieve voicemail, or "0" to reach an attendant, or some button to cancel
the recording, etc.  Only a fraction of those calls actually end up with
someone pressing a dtmf button, but because you *could* press dtmf, the
vmail server would have to KPML subscribe for all calls.

-hadriel

> From: Francois Audet [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 12:59 PM
> To: Brian Stucker; Hadriel Kaplan; Eric Burger
> Cc: sip
> Subject: RE: [Sip] INFO
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Sep 2007 15:08:58 -0500

Ah.... Good point. Hadn't tought of that.

In any case, I'm not sure voicemail is the best example. Seems to me
you are more likely to use RFC 2833 for voicemail, since it's a 
media server. Furthermore, you'll for sure be dealing with people 
leaving voicemails that are NOT SIP users and would be going through
a generic PSTN-SIP gateway (which would do RFC 2833).

I'd think that KPML is more useful for features that don't terminate
media, like the Calling card example, or *gasp* invocation of feature 
codes, and where the end-user device is known to be a SIP phone.

> Sent: Monday, September 10, 2007 12:42
> To: Audet, Francois (SC100:3055); Stucker, Brian 
> (RICH1:AR00); 'Eric Burger'
> Cc: 'sip'
> Subject: RE: [Sip] INFO
> 
> - since most calls to a vmail server are to leave messages.  
> Calls to retrieve voicemail do always use dtmf, but calls to 
> leave voicemail don't.
> However calls to leave voicemail usually have the optional 
> ability for the caller to send DTMF - for example pressing 
> "*" and then the passcode to retrieve voicemail, or "0" to 
> reach an attendant, or some button to cancel the recording, 
> etc.  Only a fraction of those calls actually end up with 
> someone pressing a dtmf button, but because you *could* press 
> dtmf, the vmail server would have to KPML subscribe for all calls.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 10 Sep 2007 16:06:04 -0400

Inline...

> Sent: Friday, September 07, 2007 5:00 PM
> 

Not exactly - for a single digit, KPML would generate a
Subscribe/200/Notify/200 before the single DTMF was even pressed - before
the actual Notify with the digits in it.  And of course there is now also a
subscribe dialog involved.  Assuming a one-shot single digit type, then,
we're talking 6 SIP messages for KPML vs. 2 for Info.  

> call, but it is really easy to get wrong.  

I'm not sure I understand the scenario.  The VM learned about this call how?
By being in the signaling path, no?  So why wouldn't the CM forward INFO
along the path? (I mean it is in the same dialog, after all)  Now I don't
doubt it could screw that up, and eat the info thinking it was for itself,
but lots of things can get screwed up - my guess is KPML will not be
impervious to screw ups.

> In KPML-land, the VM

The VM will probably NOT *directly* subscribe to the UAC.  It will need to
go through the UAC's outbound proxy.  And if the VM is outside the UAC's
enterprise or service provider domain, my guess is the VM will need to go
through some other boxes too.  A stand-alone UAC has virtually no way to
verify the identity of a subscribing VM, so I hope they don't just accept
direct subscriptions.

Also, this only works if the UAC supports multiple KPML subscribes, right?
Which were only optional in the spec, no?

> By the way, I am deliberately using the provocative "softswitch" term

Well, I'm not sure how the "softswitch" term makes a difference - I would
think a "softswitch" would need to be in the path for all signaling, and
will not be bypassed even by KPML.  But then "softswitch" is an ambiguous
term.  :)

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 10 Sep 2007 16:31:21 -0400

Ya, voicemail isn't the strongest - I noted in that email that a VM would
probably (hopefully) do 2833.  But there are plenty of PSTN gateways which
don't do 2833.  In fact I've heard that's where the INFO usage for dtmf got
born.  There are also plenty of Enterprise hard-phones that apparently don't
do 2833.  Nor do most H.323 devices.  Considering how much INFO-dtmf is
demanded and used, I assume it must be a large set of devices or apps that
don't do 2833.

But yeah the credit-card-style apps are the obvious users.  For some of them
KPML could save a lot, for example to reduce a 16-digit credit card number
to one Notify.  Ironically KPML rewards apps which use a lot of DTMF digits
all the time, and penalizes those that use only a few or uses them
infrequently. 

-hadriel

> Sent: Monday, September 10, 2007 4:09 PM
> To: Hadriel Kaplan; Brian Stucker; Eric Burger
> Cc: sip
> Subject: RE: [Sip] INFO
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 10 Sep 2007 15:50:41 -0500

> Sent: Monday, September 10, 2007 13:31
> Ya, voicemail isn't the strongest - I noted in that email 
> that a VM would probably (hopefully) do 2833.  But there are 
> plenty of PSTN gateways which don't do 2833.  In fact I've 
> heard that's where the INFO usage for dtmf got born.  There 
> are also plenty of Enterprise hard-phones that apparently 
> don't do 2833.  Nor do most H.323 devices.  Considering how 
> much INFO-dtmf is demanded and used, I assume it must be a 
> large set of devices or apps that don't do 2833.

My expectation is that most systems have (or will soon) support
RFC 2833, and be migrating to it soon.

INFO worked relatively well in a single-vendor network, but it really
was pretty useless when trying to interoperate with other vendors.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 10 Sep 2007 16:56:26 -0400

> Sent: Monday, September 10, 2007 4:51 PM

I would hope so.  Then we can get back to arguing about sips on this mailing
list... I'm starting to get withdrawal symptoms. :)

> was pretty useless when trying to interoperate with other vendors.

It works better than KPML so far.  ;)

-hadriel

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 10 Sep 2007 16:28:30 -0500

> Sent: Monday, September 10, 2007 3:56 PM
> > My expectation is that most systems have (or will soon) support RFC 
> > 2833, and be migrating to it soon.
> 
> I would hope so.  Then we can get back to arguing about sips 
> on this mailing list... I'm starting to get withdrawal symptoms. :)

Except 2833 doesn't go to all those lovely application servers we keep
talking about that want to see what the digits are. :(

Since they're typically BBUAs anyhow, maybe we could define an extension
to SDP that application servers can say "send me KPML" or "send me INFO
with this MIME type" should the media path receive a digit. Then the
media server can battle to the death with the application servers as to
whom the digit was intended for.

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 11 Sep 2007 08:28:10 +0300

> probably (hopefully) do 2833.  But there are plenty of PSTN gateways which

then you don't buy such a gw.  in my gws 2833 works fine and there is no
need for yet another protocol for this purpose.

-- juha

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 11:27:00 +0200

Hi, 

>>softswitch / Proxy. 
>>In KPML-land, VM App Server *directly* subscribes to UAC key press
state, bypassing the softswitch.

[Christer] As I've said before, there are environments where some
proxies must (for whatever reason) be passed through. I guess an
outbound proxy is a good example.

>>KPML and INFO have the same number of messages for a SINGLE digit;
KPML wins 
>>hands-down for multiple digits or reports.
> 
>Subscribe/200/Notify/200 before the single DTMF was even 
>pressed - before the actual Notify with the digits in it.  
>And of course there is now also a subscribe dialog involved.  
>Assuming a one-shot single digit type, then, we're talking 6 
>SIP messages for KPML vs. 2 for Info.  

[Christer] And, in cases where you need to send DTMFs (or whatever
information) in both directions you actually need 2 subscription dialogs
- one in each direction, and maintaining dialog state also consumes
resources. And, in some cases you may not even know whether you will
ever have to use the dialog.

>>to pass through the softswitch / Proxy to the CM application.  Cool - 
>>it is a proxy, so it knows to relay.  But OOPS!  The CM application 
>>has to proxy the INFOs to the VM application.  Yes - you could be a 
>>good programmer and remember to do that EVERYWHERE you place an 
>>outbound call, but it is really easy to get wrong.
> 
>By being in the signaling path, no?  So why wouldn't the CM 
>forward INFO along the path? (I mean it is in the same 
>dialog, after all)  Now I don't doubt it could screw that up, 
>and eat the info thinking it was for itself, but lots of 
>things can get screwed up - my guess is KPML will not be 
>impervious to screw ups.

[Christer] I also have problems understanding the scenario. INFO is
routed to wherever the INVITE that initiated the dialog was routed...

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 11:30:36 +0200

Hi,

Let's also keep in mind that DTMF may not be the only information users
want to send to each other during a session. So, you will need to
establish subscription dialogs for every type of event that the users
may want to send during the session...

Regards,

Christer 

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 11. syyskuuta 2007 12:27
> To: Hadriel Kaplan; Eric Burger
> Cc: sip
> Subject: RE: [Sip] INFO
> 
> 
> Hi, 
>