Subject: Re: User signaling -- was DTMF signaling between media gateways -ouch!

From: Sean Olson <[email-masked]>
Date: Tue, 14 Dec 1999 09:30:07 -0600 (CST)

> >We have no control over H.xxx in the IETF, so need to look here what works
> >best in the Internet conferencing architecture.
> >SIP INFO seems to the job. What specifically does it not do? (If we keep the
> >required SIP servers in the signaling path)
> 
> It does not allow trivial synchronized re-insertion of DTMF at the 
> far end of a PSTN-SIP-PSTN connection using an voice compression codec
> (e.g. GSM 6.10 or G.723) in the middle.
> 
> That is the key argument for RTP based DTMF encoding.
> 
> --
> 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
> 

Actually, it does. It all depends on the encoding you choose for the 
DTMF in the INFO payload. Although it is taboo, you could even carry the
AVT tones RTP packet in the payload. There, I said it, let the flame wars 
begin (keep in mind that this has already been hashed over many many times)

I believe the key argument for RTP based DTMF
encoding is that it is something everyone is doing anyways, so why not
re-use it. I think the more important question is why not allow both?
I've heard excellent arguments from both sides. One thing to keep in mind
is that the INFO method is not specifically designed for DTMF transit. There
are many other applications for it. To get hung up on this issue detracts
from more meaningful discussions on what INFO can provide.

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Wed, 15 Dec 1999 10:51:21 +0100

Hi all,

Some cross polenization here:

H.323 people are developping a new annex, annex F,
called SET (Simple Endpoint Type).

It is designed to run in low cost IP phones.

------------
DTMF & other user input (soft-keys, feature keys,
function keys, keypad...) are put in the Signaling Channel.

DTMF can optionnaly use RTP DTMF payload.
-----------

I guess that this design meet 2 requirements:
	- Accurate transmission of DTMF at media level, as
	required to interoperate with existing circuit 
	switched IVRs.
	- Separation of concern between media plane and
	control plane to enable decomposed IVR architectures.

SET is also UDP based and GateKeeper friendly. You
may consider SET/GK as a competitor to MGCP's MGW/MGC
architecture or SIP's UA/Proxy architecture.

Jean-Hugues Robert

--------------------------------------------------------------------
[email-masked]        - We Serve Providers -          "Think globally.
www.8x8.com      - iPBX Hosting solutions -            Act locally."

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 15 Dec 1999 06:31:06 -0600

>called SET (Simple Endpoint Type).

This may be a good reality check to see the size of H.323 and SIP clients if
compared for similar capabilities!

Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081
USA

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jean-Hugues
ROBERT
Sent: Wednesday, December 15, 1999 3:51 AM
To: [email-masked]
Subject: Re: User signaling -- was DTMF signaling between media gateways
-ouch!

Hi all,

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

Jean-Hugues Robert