Subject: RE: [SIP] DTMF digit handling

From: "Girzon, Gary" <[email-masked]>
Date: Mon, 10 Jul 2000 16:39:40 -0400

An example of where "DTMF over RTP" and "DTMF over SIP INFO" methods
can be both used is a pre-paid application. Pre-paid falls into a general
category 
of 3rd party call-control apps in which a controlling party typically does
not care 
about audio between the other 2 parties but wishes to be notified about
certain 
in-band audio events such as DTMF.  Initially, the controlling party
receives 
DTMF over RTP. After the transfering a call, there is no need for 
the controlling party to remain in the RTP or media "loop" and waste
connection resources.

Again, I don't think anyone is proposing tunneling MGCP or Megaco over SIP,
just recycling some of the already defined packages for syntax defining DTMF
events.
 
Gary

PS: The usual disclaimers about this being a legacy PSTN type application
apply...

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, July 10, 2000 3:43 PM
> To: Culpepper, Bert
> Cc: Michael Thomas; Jonathan Rosenberg; Igor Slepchin; Shankar,
> Krishnakumar; [email-masked]'
> Subject: Re: [SIP] DTMF digit handling
> 
> 
> "Culpepper, Bert" wrote:
> > 
> 
> > 
> > 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.
> > 
> >
> 
> 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
> 
> 
> _______________________________________________
> 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 16:35:47 -0400

> the controlling party to remain in the RTP or media "loop" and waste

That party should then disconnect the DTMF RTP stream, using existing
SIP "drop media" mechanisms. (I actually doubt this works in practice,
since most such prepaid applications allow the user to "hang up" and
redial by holding down the # key for two seconds, compensating for the
lack of cookies in payphones.)

> just recycling some of the already defined packages for syntax defining DTMF
The person(s) doing the proposing can speak for themselves :-)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 Jul 2000 01:26:13 -0400

> the controlling party to remain in the RTP or media "loop" and waste

Part of the confusion are the different pictures people have in their
heads about the architecture for providing these services. Pre-paid is a
classic example of an app where the media stream must be terminated by a
SIP UA anyway, for generating prompts and the like. Let me draw a
picture of how I view this service being architected:

       +-----------+
       | media     |
       | server    |
       |           | x   control
       +-----------+  xx
                        x
            .            x
            .       +---------+
           .        | app     |
           .        | server  | \
       RTP.      /  |         |  \
          .     /   +---------+  \ SIP
         .     /                  \
         .    / SIP                \
        .    /                      +-------+
    +-------+                       |       |
    |       |                       |       |
    |       |                       | UAS   |
    | UAC   |...................... |       |
    |       |                       |       |
    +-------+         RTP           +-------+

The UAC makes a call (a gateway, typically), and its SIP INVITE arrives
at an app server handling the pre-paid calling application. Using 3pcc,
this app server sends a 183, and includes in it SDP corresponding to the
address of some media server. The media server terminates the RTP from
the UAC; its the one thats going to play the prompts and extract DTMF.
Now, once the credit card information has been collected, you'd like
that information to be sent back to the app server via some control
protocol, X, to be determined. Once thats done, the app server sends the
INVITE the the UAS, which sends 200 OK, and the UAC now sends RTP
directly to the UAS.

In this model, the app server never sees media. Media is always directly
sent between the entities communicating. There are no extra delays. We
do not need DTMF in SIP, since the media server is terminating  and
originating RTP.

What we do need is some sort of control protocol between the app server
and the media server. This would be used to control the IVR prompts,
collect the credit card, and get it back. Many people like megaco/mgcp
here. I, frankly, much prefer VoiceXML as it is oodles easier to program
and plays very nicely with SIP. Anyway, whatever it is, that control
protocol reports the DTMF as needed. Note that this interface is NOT
SIP. 

If someone has a different architecture in mind for this service, speak
up.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com