Subject: RE: [SIP] DTMF digit handling

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 10 Jul 2000 14:18:54 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, July 10, 2000 11:41 AM
> To: Jonathan Rosenberg
> Cc: Igor Slepchin; Shankar, Krishnakumar; [email-masked]'
> Subject: Re: [SIP] DTMF digit handling
> 
> 
> 
> Igor Slepchin wrote:
>  > > If some of the systems along signaling path are interested in the
DTMF,
>  > > the INFO method may also be used. There are a few ways to encode DTMF
in
>  > > the body of INFO: by using the payload format described in RFC2833,
> 
>    Yuck.
> 
>  > >  by
>  > > using MGCP/Megaco packages, etc.
> 
>    Double Yuck. 
> 
>    Why is it so difficult to just receive RFC2833 payloads
>    over RFC 1889 transport?
> 

As I understand RTP, there is no guaranteed deliver of RTP packets.
Therefor, the need for a reliable protocol.  Also, requiring a 3rd party
platform to process the media adds delay when it is in the middle
of a session between two other endpoints.

> Jonathan Rosenberg writes:
>  > I should note that this is still an issue of some controversy, both on
>  > whether its needed (a UAS will still get the DTMF through RTP), and on
>  > how to do it. So, you should not take any of the extensions proposed so
>  > far as authoritative or normative. I hope to resolve this at the next
>  > meeting.
> 
>    In the last go-round of this perennial merry-go-round,
>    the main complaint I heard is that interior IVR's might
>    not have the MIPS/whatever to do DTMF detection and that
>    they'd like to have the originator -- who has to have 
>    a DTMF detector anyway -- do the DSP kruft. Fine. We now
>    have RFC 2833. Trying to thread this back through SIP,
>    however, seems like a really bad idea though: why not
>    just use SIP to transport RTP itself? And putting 
>    MGCP/MEGACO into SIP body headers is a gruesome
>    layer violation... it's sort of like the
>    protocol equivalent of an inter-subroutine goto 
>    with none of the careful rationalizations of 
>    setjmp/longjmp.
> 
> 		Mike
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jul 2000 15:43:14 -0400

"Culpepper, Bert" wrote:

> of a session between two other endpoints.

We've had this discussion a few times in the last few years, but this
seems to be a recurring misperception. DTMF-over-RTP is roughly as
reliable as any UDP or TCP-based protocol. All three, SIP-over-UDP, RFC
2833 and SIP-over-TCP, rely on retransmission (ACK-based or
"FEC"-based), just at different layer. All can fail, eventually, if too
many packets are lost in a row. (TCP will retranmsmit for a long time,
but it is not clear whether receiving a DTMF digit an hour or even
thirty seconds after the key was pressed is very useful. You probably
need to have an application-layer timeout in any event, as in "sorry,
your number is incomplete, please redial".) In most cases, RTP-based
retransmission is much faster than TCP-based retransmission, in line
with the real-time requirements of outbound PSTN gateways.

Besides, as discussed here a few times, if you prefer the TCP model of
reliability, you can carry RTP in TCP.

The delay issue is also bogus, since you can forward the voice packet
even before you do the analysis (unless you need to synchronize tones
and audio at the outbound IP-to-PSTN gateway, but then SIP or anything
else that doesn't have precise timing information isn't going to help
you.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Jul 2000 15:48:18 -0400

>of a session between two other endpoints.

RFC 2833 allows for a redundant transmission mechanism, to achieve very
effective loss resilience... 

Colin

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 10 Jul 2000 21:56:05 +0200

> of a session between two other endpoints.

   To recall the reliability discussion (back to November):

   Reliability is obviously desired (consider banking applications).
   RFC 2833 deals with packet loss by redundancy, which is subject
   to burst loss and jitter. SIP INFO uses SIP's exponential retransmission,
   which lacks real-time property. This may have some unpleasant side-effects:

   Exponential retransmission may fool human senders who will 
   beleive, they did not press a digit button thoroughly and 
   will press the digit again resulting in digit duplication. 
   (Jonathan R.) Receiver can be fooled to beleive the retransmission 
   gap indicates end of DTMF sequence. (Michael R.)

   Scott P. proposed to handle packet loss at application layer
   if redundancy is used and fails. (If a banking PC is asked to make
   a transaction it prompts all data before really doing so.)

Jiri

-- 
Jiri Kuthan               Phone: +49-30-3463 7271
GMD FOKUS                 Fax  : +49-30-3463 8271
Kaiserin-Augusta-Allee 31 E-Mail : [email-masked]
D-10589 Berlin, Germany   WWW    : http://www.fokus.gmd.de/usr/kuthan
--
Curious about Internet Telephony? 
Check http://www.fokus.gmd.de/glone/projects/ipt today!