Subject: RE: [SIP] DTMF digit handling

From: "Culpepper, Bert" <[email-masked]>
Date: Tue, 11 Jul 2000 10:30:14 -0500

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

> -----Original Message-----
> 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]'
> Subject: Re: [SIP] DTMF digit handling
> 
> 
> 
> 
> "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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Jul 2000 00:07:08 -0400

> audio to be sent to the UAS.

No subscription is needed at all. This is, as you suggest, a simple
re-INVITE from
the application server to the originating UA, asking to add a media
stream. That media stream
would be listed as supporting a single codec - dtmf. This would tell the
originating UA to send DTMF only to the application server. An app
server that does speech recognition would add a media stream that uses a
normal codec. Now there are two full media streams, one from the
originating UA to the terminating, and
another from the originating to the app server. 

The nice thing here is that this mechanism of using reINVITE to add a
media stream is the same for DTMF driven applications and speech
recognition. This would not have been the case if INFO was used.

-Jonathan R.