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

From: Steve Gardell <[email-masked]>
Date: Tue, 20 Mar 2001 08:51:30 -0500

These comments would apply equally well to the first
draft of the document. Apologies to the authors for
the delay.

The draft document describes a sensible and open 
SIP-based component model for enhanced services. As 
the authors correctly note, some services such as 
unified messaging might be developed in a more 
integrated fashion for cost or security reasons. The 
following are a few specific comments focusing on 
the alternative approach outlined in the draft.

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.

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.

The URI naming discussion in section 6.1 identifies 3 
approaches. Given the nature of VXML, the second two 
are almost functionally equivalent; I agree with the authors 
that #3 is preferable. It also seems a bit safer 
from a service provider's perspective. 

The discussion of VoiceXML call control separation later 
in this same section makes sense in a strictly SIP 
world, but it is unreasonable to expect VoiceXML to be 
strictly "SIP-focused." I would argue that, if anything, 
VoiceXML probably needs richer call control primitives.
But that is for another mailing list...
 
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.

Steven Gardell
Principal Engineer, Iperia Inc. 
781-993-3544

_______________________________________________
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: Wed, 21 Mar 2001 00:45:55 -0500

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

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

[snip]
> 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.