Subject: RE: [SIP] DTMF digit handling

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 10 Jul 2000 15:49:08 -0500

I'm reminded (by Colin) that RFC2833 supports re-transmission.  This
works for me.

Additional delay (when in the media path between two endpoints) is a
problem for me.  I don't have the luxury of building my own RTP/
network interfaces.  I suppose I can "turn off" the jitter buffer on the
commercially available network interfaces I'm aware of and pass
RTP to the other end, resulting in minimal delay.  But then I'd have
to build my own packet sequencer.  This is do-able, I have to look
at the packet timestamps and event duration anyway.  But if
transported in an INFO message, all I have to do is analyze the
RTP packets containing the DTMF and stay out of the media
path altogether.  Delay is a non-issue then.

Bert

> -----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

---

From: "Bratakos, Maroula" <[email-masked]>
Date: Tue, 11 Jul 2000 09:05:15 -0700

The UAC would actually have to support forking the DTMF stream to both the
media server and the UAS because the UAS may want to receive DTMF also.  For
example, a user accessing a UAC may use their calling card to place a call
to their local bank (accessed through the UAS) which requires the user at
the UAC to enter their account number.

-----Original Message-----
From: Culpepper, Bert [mailto:[email-masked]]
Sent: Tuesday, July 11, 2000 8:30 AM
To: Jonathan Rosenberg; Girzon, Gary
Cc: 'Henning Schulzrinne'; Michael Thomas; Igor Slepchin; Shankar,
Krishnakumar; [email-masked]'
Subject: RE: [SIP] DTMF digit handling

The architecture shown matches my view of how a service like pre-paid
calling card would be deployed in a SIP network.  The call setup scenario
also matches my view of the signaling.  What is not described,
for a service like pre-paid, is how the calling party notifies the app
server
that it wishes to end the current call and originate a second call without
disconnecting completely from the app server and making a new call and
going through the credit card validation a second time.  I know we're not
in the PSTN anymore but this is typically done by pressing and holding
the # key for two seconds.

What appears to be an acceptable solution to mimic this behavior in a SIP
network is to "subscribe" to the DTMF stream (RFC 2833) of the UAC.
The RE-INVITE to the UAC will include two media descriptions in the SDP.
One for the DTMF to be sent to the media server and the second for the
audio to be sent to the UAS.

Mid-call event notification in SIP would allow the release of the media
server's resource during the conversation portion of the call.  One of the
DTMF/event reporting proposals (or an equivalent) would allow this.

Bert Culpepper
Staff Engineer, Systems Design
InterVoice-Brite, Inc.
http://www.intervoice-brite.com

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 11, 2000 1:26 AM
> To: Girzon, Gary
> Cc: 'Henning Schulzrinne'; Culpepper, Bert; Michael Thomas; Igor
> Slepchin; Shankar, Krishnakumar; [email-masked]'
> "Girzon, Gary" wrote:
> > 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.
> 
> 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
>