Subject: RE: DTMF signaling between media gateways - ouch!

From: "Tom-PT Taylor" <[email-masked]>
Date: Sat, 13 Nov 1999 18:36:09 -0600

Let's step back and look at the RTP DTMF payload type vs. SIP INFO transport
methods in more abstract architectural terms.

What the two methods have in common: 
(1) They are both "out of band" compact encodings of the information
concerned, so the amount of effort required to understand them at the
receiving end is roughly the same.
(2) The transport options are the same for both methods -- there is no
reason you can't run RTP over a reliable transport if you want.
(3) Both methods require prior signalling to set up the necessary
relationship between the source and destination.

How the two methods differ:
(1) The SIP INFO  message must pass along the signalling path, and in
particular must have the same endpoints as the rest of the SIP session.  The
RTP stream can take a different path from the signalling; it can therefore
originate at the point of extraction from an audio stream, and terminate at
the point of consumption of the digit information.

Somewhat to my surprise, it looks like RTP is probably always the best
answer.  There are two possibilities that come to mind that might contradict
that conclusion:
(a) A number of entities along the signalling path need to know the digits.
(b) The receiver of the digits is one end of the SIP session and neither
sends nor receives media.  In this case it ends up having to support a
second protocol (RTP) where otherwise it could just use SIP.  In addition,
there could be coordination problems between SIP messaging and the
independently-received RTP packets.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 13 Nov 1999 23:55:27 -0500

> Tom-PT Taylor wrote:
> particular must have the same endpoints as the rest of the SIP
> session.  The RTP stream can take a different path from the
> signalling; it can therefore originate at the point of extraction from
> an audio stream, and terminate at the point of consumption of the
> digit information.
> 
> answer.  There are two possibilities that come to mind that might
> contradict that conclusion:
> 

But why? SIP is *not* a stimulus signaling protocol. Protocol features
are not invoked by DTMF. I feel strongly about this since once you start
doing this, you mandate a proxy server for call completion and possibly
certain features which otherwise don't need one. This isn't megaco,
after all. I believe it funamental to the SIP architecture that the
operation of basic call completion and certain features (where
appropriate) is independent of the presence of a proxy. 

What services could proxies provide in the SIP model by receiving DTMF?
Nearly every application of DTMF I have heard brought up required the
entity receiving the DTMF to be a UA, in which case it could get the RTP
stream instead.

> (b) The receiver of the digits is one end of the SIP session and
> neither sends nor receives media.  In this case it ends up having to
> support a second protocol (RTP) where otherwise it could just use
> SIP.  In addition, there could be coordination problems between SIP
> messaging and the independently-received RTP packets.

These coordination problems arise only when the DTMF is sent in INFO.
When the DTMF is sent in RTP, its easy to reconstruct the timing, so you
can put back the DTMF if need be. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 17 Nov 1999 09:17:45 -0600

Jonathan wrote:
> Dean Willis wrote:
> > See my previously posted example of an IVR which participates as a SIP
> > signaling system but has all of its media paths terminated on
> set of media
> > servers somewhere else.
> >
> > Yeah, I suppose we could have the detected tones schlepped back from the
> > media server to the IVR over yet-another-potocol, but that doesn't seem
> > particularly efficient.
>
> My point in previous posts is that in a real system, this is
> unavoidable. You
> will need input from the media server back to the controller to indicate
> (1)
> status of playbacks of announcements, (2) speech recognition, (3) dtmf
> not
> sent using a dtmf codec (i.e., g.711), (4) error conditions. I'm sure
> there are other pieces of data as well.

I believe that the start, stop, and status controls of a media server can be
provided via RTSP. It doesn't even have to understand SIP -- just has to be
able to generate an RTP stream.

> I really want to emphasize that SIP is *not* meant to be a stimulus
> signaling protocol. If that were the case, we could have ditched every
> single request method, and just had an INFO method that sends digits to
> the proxy. This would be nothing more than a poor version of megaco. It,
> of course, would also mean clients can't call each other directly.
> Simply put, stimulus signaling *does not work* for direct client to
> client calling. Our aim with SIP is not to replicate the phone network
> all over again, but to do things in way that match the end-to-end
> architecture of the Internet.

Any input that doesn't have a semantic meaning in SIP is just a
"stimulus" -- something to be passed along the nervous system in hopes that
a ganglia can process it. That would seem to include mid-call telephony
events. It's a distributed model very different from the Megaco centralized
control model. I think of the SIP proxy chain as a sort of bus that
reconfigures between and during calls as needed.

And why would arbitrary client-to-client messages "not work for direct
client to client calling"? It simply requires that the two clients share a
semantic understanding of the messages. The "requires, desires, supports"
behviors give us semantics needed to determine a shared understanding . . .

I could, for example, see an application wherein each end point periodically
snaps a jpeg image of the speaker, mimes it, and ships it via INFO to the
other end for display as a "speaker icon". The proxies in between don't
care, they just ship the message along. Yeah, you could do it in RTP. You
could do it a lot of ways -- but INFO is easy for asynchronous stuff.

--
Dean

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 1999 08:40:05 -0500

Dean Willis wrote:
> 
> Jonathan Rosenburg wrote:
> signaling system but has all of its media paths terminated on set of media
> servers somewhere else.
> 

> If that isn't enough, let me propose another application.
> 
> User A completes all calls through proxy P.
> 
> P provides additional services, along the lines of a "personal assistant".
> One of these services is a "voice recorder" ala President Nixon.
> 
> A uses an analog phone connected to a generic UA gateway.
> A calls party B, leaving P in the proxy path.
> A decides B is saying something interesting and wants B recorded.
> A presses the "R" key.
> P uses call control to add a voice recorder and recording announcement tone
> generator and conference bridge to the call.
> P never saw a single byte of media.

As has been pointed out, this kind of thing takes us down a long nasty
road
of stimulus signaling based feature interaction problems. 

This service is readily provided functionally by having the gateway
figure out (somehow; there are many ways to do this without overloading
the gateway) what pressing "R" means, and then signal the call control
you describe above. In a decomposed gateway, the MGC would receive the
"R" and then figure out what to do. 

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 16 Nov 1999 13:28:47 -0600

Consider also that the end goal is NOT to ship DTMF, but to ship user input
notifications. Today, a user input notification is DTMF because that's what
the phones have, but it isn't going to stay that way.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Nov 1999 16:06:39 -0800 (PST)

> media server to the IVR over yet-another-potocol, but that doesn't seem

   Why not? In the end we're probably talking
   about IP transport in both cases, assuming
   that SIP is transported over IP. An RTP
   sink at the IVR for *just* RTP NSE's seems
   like a pretty easy thing to implement if you
   ask me. All the INFO with digits is doing is 
   transporting NSE's in disguise -- with less
   information and less flexibility -- back to
   the SIP. All to save having the IVR from having
   to understand RTP?
   
   This just doesn't seem sensible to me. Is
   it really all that hard to listen on a
   different socket for these events?  
 
 > the phones have, but it isn't going to stay that way.

   Right, but what that says is that the SIP
   is going to either have local intelligence
   to understand what the keys mean and initiate
   action based on them, or it will delegate 
   handling of the keys and/or display to a 
   foreign application which may drive them 
   with something completely different (eg, 
   http/html or telnet/ansi).

 > P never saw a single byte of media.

   I don't understand what this has to do with
   DTMF delivery.

   The "R" button sounds like it's locally
   intercepted by "A" which causes it to do
   some signaling to P to start a record
   function. This doesn't seem much different
   than local digit collection for the telephone
   number in the first place (putting aside that
   a naive implementation like this might conflict
   with an IVR system's digit collection if "B"
   were an IVR).

   I'm having a pretty hard time understanding
   why if a SIP-anything is interested in DTMF
   digits, it cannot set itself up as being the
   recipient of NSE's over RTP (or some other
   means). Even if the bearer is normally over
   ATM or FR or something else, that doesn't
   preclude that an IVR SIP cannot receive DTMF over
   whatever choice of media bearer it needs to
   see it over (eg, RTP). The source SIP just needs
   to support more than one media bearer network
   type is all which is signaled in the SDP
   announcement. And in fact, those could be split
   or even "three way" such that the IVR got the
   NSE's, and the normal bearer got it's own
   version of NSE's (or not).

   Am I missing something here? Things seem quite
   a bit more flexible than some people are giving
   credit for.

		Mike

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Nov 1999 16:40:51 -0600

>    http/html or telnet/ansi).

Not that SIP has to understand, but the service node implementing a service
has to have logic for the service . . .

>    with an IVR system's digit collection if "B"

A can't intercept anything. A is a user at an analog phone.
A's gateway decodes the analog DTMF for key 7 (P,R,S key) and sends an
INFO(dtmf-7) to P.
OR, the gateway encodes the 7 in RTP and forks the RTP to P. How it knows to
fork to P remains to be seen . . . something we solve with the proxy path in
SIP.
P has service logic that says "If input is dtmf-7, then execute record."

P might also have service logic that says "if input is string "record" then
execute record suroutine" to support native SIP phones that can send richer
INFO messages.

>    version of NSE's (or not).

Because the INPUT IS NOT NECESARRILY A DTMF DIGIT. We use DTMF for some
applications because that's all analog phones can produce. How would you
encode "exec rm voicemail.au" in an RTP audio stream? Require speech
recognition at every end point?

The alternative is NOT to use RTP to the control plane, but to introduce
some other sort of input mapping protocol that turns an input into a
stimulus. The question is whether that stimulus can be transported as a SIP
INFO, or whether some other approach is needed. Other potential approaches
might include RMI, HTTP, RPC, DCOM, SNMP, RSQL, 3270 LU-2, and so on.A
second question is whether the SIP signaling path represents a useful
service locator, or some external approach like JINI is more useful.

If we use a SIP INFO approach, we can choose whether the DTMF detecting
device transmits out as SIP, RTP, or both. We can choose whether the
recipient of that noification transforms it into some other format before
passing it elsewhere. And you know what? It's not a protocol issue. The
protocols allow all such usages. It's an implementation and application
design issue.

I happen to believe that the open-ended nature of the SIP INFO approach I
have discussed provides for some very powerful and easily implemented
applications. SIP provides arbitrary application messaging support with INFO
and MIME bodies. SIP provides automatic scoping to the nodes contained in
the signaling path, with an opt-out mechanism for nodes that don't want to
play, transparaency for nodes that don't care, and negotiation mechanisms
for nodes that think they might want to care. Feel free to write 3270
applications if you want, but . . .

>    a bit more flexible than some people are giving

I believe you are, but feel assured that you're not the only one. I feel
like I'm preaching in the wilderness here, so I'm going to shut up now.
Besides, the patent lawyers just yelled at me for leaking too much IPR.

From a WG perspective, we have designed a protocol that can be used in many
ways. Given that, can we let the applications implementors explore those
alternatives and let the market decide which approaches are useful and which
aren't?

--
Dean

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 18 Nov 1999 17:56:22 -0600 (CST)

>answer.  There are two possibilities that come to mind that might contradict
...
>independently-received RTP packets.

But this makes no sense. How would a user have any idea what digits 
to enter, or even that an action is expected on his part, if there 
are no prompts?

If there *are* prompts, the node described above must have some sort
of controlling relationship with a media server. The communication
of DTMF can be done from the media server to the controlling box
using whatever protocol they already share.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 21 Nov 1999 20:27:09 -0500

Jonathan,

In reading through this thread on DTMF signalling, this particular message
stands out at me.

When I read Tom's point (a), I immediately thought of the scenario where
User A calls User B.  User B wishes to transfer User A to User C on the
PSTN.  Being the originator of the transfer, I would expect User B to pay
for the call.  This suggests to me that a SIP proxy would want to receive a
signal, send an INVITE to the PSTN gateway to establish the out-bound call,
and send an INVITE message to User A to redirect the media streams.

Call handing is within the scope of SIP, so I am curious about your thoughts
relating to performing such functions commonly seen today, such as call
transfer, park/pick-up, etc.  It seems that SIP would need to be somewhat
stimulus-based in order to carry out many functions.  It would also seem
that proxies would be key to providing such call-related services.

I do not necessarily advocate the usage of DTMF for these functions, but it
seems that proxies and some kind of signaling along the call signaling path
is more important than you suggest here.

Thanks,
Paul