Subject: RE: [SIP] DTMF digit handling

From: "Girzon, Gary" <[email-masked]>
Date: Tue, 11 Jul 2000 11:28:12 -0400

I don't have any issues with the architecture below or
the call flow. Yes, the Media Server initially collects DTMF information 
directly via RTP but once the RTP connection between UAS 
and UAC is set up,  there is no need for the UAC - Media Server 
RTP connection. Maintaining the RTP connection just for DTMF
digit collection (required to collect the long # and any
others) is really a waste of resources on the Media Server,
not to mention extra bandwidth. Typically, there is 1:7 mapping
of Media Server to Caller resources - i.e., the Media Server
plays a prompt, collects a few digits and then dis-engages.
That Media Server port can be re-used for other Media
Applications. Once the Caller hits #, the Media Server gets 
reconnected, plays prompts and collects digits again.

So the real question is how to collect the long # and any
any other DTMF while UAC and UAS are connected. This is
where I think SIP INFO method provides a good solution. 
Does anyone have another method of sending DTMF information
from UAC not requiring an RTP connection to the Media Server?

As for the protocol between the App Server and Media Server,
that's a whole other discussion...

Gary Girzon
Principal Software Engineer
Pactolus Communication Software, Inc.
55 New York Avenue
Framingham, MA 01701
Office: 508-620-5519 x 208
[email-masked]
www.pactolus.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: Michael Thomas <[email-masked]>
Date: Tue, 11 Jul 2000 08:29:43 -0700 (PDT)

> reconnected, plays prompts and collects digits again.

   Assuming the UAC is sending named signaling events,
   it seems to me that it's six of one, half dozen of
   the other of whether the media server monitors the
   call for more digits using RTP or SIP INFO methods.
   Given that the media server needs to deal with things
   like duration (ie long #), NSE's seem like a lot better
   approach, and to my mind fits the SIP architecture a 
   whole lot better: SIP's good at initiating media 
   streams; it's pretty lousy at being a device control
   protocol. Essentially it's just a DTMF multiparty
   conference.

		Mike