Subject: [SIP] Re: SIP digest, Vol 1 #180 - 7 msgs

From: Michelle Kitchings <[email-masked]>
Date: Tue, 11 Jul 2000 11:36:39 -0500

Ok, I'll take a shot at this...

In Jonathon's architecture, once the RTP is established between the UAC & UAS,
yes, the UAC can break the connection to the media server.  Later, when the
UAC gets an indication from the user to terminate the current call (UAC-UAS),
it will send a BYE to the UAS.

At that point, the UAC can re-establish a connection to the media server to
monitor for  the long '#' and start over with prompt/collect.  If no '#' is
received after X amount of seconds, the UAC-Media connection is terminated and
the pre-paid call is over.  There is no reason I can see why the '#' digit has
to be collected while the UAC-UAS connection is still ongoing.

Cheers,
Michelle Kitchings

> 
> Subject: RE: [SIP] DTMF digit handling
> Date: Tue, 11 Jul 2000 08:29:43 -0700 (PDT)
> From: Michael Thomas <[email-masked]>
> To: "Girzon, Gary" <[email-masked]>
> CC: "'Jonathan Rosenberg'" <[email-masked]>,
>      "[email-masked]'" <[email-masked]>
> References: <[email-masked]>
> 
> 
>    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
>
> Subject: RE: [SIP] DTMF digit handling
> Date: Tue, 11 Jul 2000 11:28:12 -0400
> From: "Girzon, Gary" <[email-masked]>
> To: "'Jonathan Rosenberg'" <[email-masked]>
> CC: "[email-masked]'" <[email-masked]>
> 
> 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
...
> 
> > -----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
> >
> > 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.
...

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

---

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

This requires that the UAC have the smarts to know that it was previously
connected to some sort of an application server and that it must reconnect
after it sends a BYE to the UAS.  I don't think that the UAC should have to
know, based on a number a user dialed, whether the (initial) destination is
an application server that will require re-connection when the call is over.

Regards,
Maroula Bratakos

-----Original Message-----
From: Michelle Kitchings [mailto:[email-masked]]
Sent: Tuesday, July 11, 2000 9:37 AM
To: [email-masked]
Subject: [SIP] Re: SIP digest, Vol 1 #180 - 7 msgs

In Jonathon's architecture, once the RTP is established between the UAC &
UAS,
yes, the UAC can break the connection to the media server.  Later, when the
UAC gets an indication from the user to terminate the current call
(UAC-UAS),
it will send a BYE to the UAS.

At that point, the UAC can re-establish a connection to the media server to
monitor for  the long '#' and start over with prompt/collect.  If no '#' is
received after X amount of seconds, the UAC-Media connection is terminated
and
the pre-paid call is over.  There is no reason I can see why the '#' digit
has
to be collected while the UAC-UAS connection is still ongoing.

Cheers,
Michelle Kitchings

...
...