Subject: RE: [SIP] draft-rosenberg-sip-app-components-01.txt

From: Steve Gardell <[email-masked]>
Date: Wed, 21 Mar 2001 12:14:03 -0500

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 12:46 AM
> To: Steve Gardell
> Cc: SIP List
> Subject: RE: [SIP] draft-rosenberg-sip-app-components-01.txt
> 
> 
> Comments in-line
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Steve Gardell
> > Sent: Tuesday, March 20, 2001 8:52 AM
> [snip]
> > In section 3, the separation of signaling and media
> > phases is motivated by the debit card example. This
> > is actually not that clean an example since many debit
> > cards provide for refreshing in mid-call with the
> > resultant need to barge into a call. A Call flow for
> > the barge-in scenario would be illuminating.
> 
> The application server re-invites the caller to the media 
> server, which does
> the "you've got 1 minute left, press 1 to recharge" script.  
> Either the
> media server will POST that it got the "1", or the 
> application server will
> time out and issue BYE's to the media server and the 
> caller/called parties.
> Note that we can be much fancier in the packet network than 
> the TDM network,
> in that we can much more easily do whisper-in-your-ear, 
> mixing with the
> called party, instead of dropping the called party our for 
> the announcement
> or playing a warning tone.
> 
That certainly helps clarify things, but of course we need to
have the control channel to handle the case where the caller
declines to add value to the call and the call must be terminated 
by the "third party." Don't see that as a real problem.

> > I might be inclined to generalize the DTMF discussion
> > in section 5.4 to indicate the potential to communicate
> > waveform characterizations from a media gateway to a
> > speech recognition engine. Along these same lines a
> > media server that records messages might want to
> > receive both G.711 and RFC2833 streams. Towards that
> > end, the re-invite model appears support 2 RTP streams
> > at (14) in Fig 3... (right?) At any rate, the architecture
> > needs to continue to support a heterogeneous model where
> > sometimes it is sensible to utilize dsp resources at the
> > edge and sometimes at more centrally located servers.
> 
> If the gateway can do tone detection, under what scenario is 
> it useful to
> send both the detected tone and a G.711 stream?  By the way, 
> this implies a
> G.711 stream.  RFC 2833 is most useful for high-compression 
> codecs such as
> G.723.1 or G.729.  Is the intention to switch to G.711 to 
> transport tones to
> a media server?  Although possible, I don't know of any 
> shipping gateways
> that allow codec changing on the fly.
> 

The issue with multiple streams is that the same 
target endpoint device (e.g. a "Integrated Voice 
Messaging Platform") wants to receive both voice content 
and DTMF commands.

The issue with the architecture is that some gateway 
vendors elect not to support mid-call DTMF events 
because it enables them to more economically manage 
a pool of DSP resources. In that, case 7.111 and
local detection is the only available approach. In
situations where the gateway does support mid-call
DTMF detection, we would prefer to use it. If DTMF 
is required via 7.111, our intention would be to 
simply use the 7.111 encoding for everything

> [snip]
> > Section 6.2 discusses conference servers. I argue
> > that conference status may be better communicated to
> > participants via RTP since this is, for some
> > conference management models (e.g. continual display
> > of dominant speaker), near real-time information.
> I would assume that mixers will implement RFC 1889, and thus 
> will identify
> the speakers.  However, what we're talking about here is that 
> conference
> control and reporting goes way beyond the capabilities (and 
> semantics) of
> RTP.  For example, let's say you have a web-based GUI that 
> indicates who the
> speaker is.  How would you suggest implementing this if the 
> only indication
> of the current speaker is embedded in RTCP?  It's very 
> straightforward if
> the mixer communicates with an application server that 
> provides the GUI.
> 
True enough. I was unaware of RFC 1889 which is pretty much
what I had in mind...

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 22 Mar 2001 21:32:00 -0500

Comments in-line
> by the "third party." Don't see that as a real problem.

There's nothing to do here.  The media server POSTs the result of the user
interaction.  If the result is "I don't want to add value", the application
server will terminate the call.  If the result is "I want to add value", the
application server may tell the media server to execute another script to
gather financial authorization information.  In reality, that second step
should be a part of the first script.  The media server only needs to return
the authorization parameters if the caller wants to add value.  Obviously,
this is application specific.

[snip]
> > it useful to send both the detected tone and a G.711 stream?
> > By the way, this implies a G.711 stream.  RFC 2833 is most
> > useful for high-compression codecs such as G.723.1 or G.729.
> > Is the intention to switch to G.711 to transport tones to
> > shipping gateways that allow codec changing on the fly.

As far as I know, media servers do tone detection.  Note that your scenario,
the media server needing to detect tones in G.711, is not the same as a
server needing to detect tones AND process RFC 2833 packets.  Were you
thinking of RFC 2833's suggestion that the media gateway send both an
enumerated signal value (e.g. DTMF 1) and the frequency components?  If so,
that's not the same as sending the actual samples.

[snip]