[Sip] Re: Requested Expert Review Request: draft-ietf-mediactrl-vxml-00

Paul Kyzivat <pkyzivat@cisco.com> Sun, 30 December 2007 03:21 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8okI-0007pX-Ju; Sat, 29 Dec 2007 22:21:50 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1J8okH-0007pR-TF for sip-confirm+ok@megatron.ietf.org; Sat, 29 Dec 2007 22:21:49 -0500
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8okH-0007p5-6z; Sat, 29 Dec 2007 22:21:49 -0500
Received: from rtp-iport-1.cisco.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8okG-0002He-5S; Sat, 29 Dec 2007 22:21:49 -0500
Received: from rtp-dkim-1.cisco.com ([]) by rtp-iport-1.cisco.com with ESMTP; 29 Dec 2007 22:21:47 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com []) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBU3LltX026970; Sat, 29 Dec 2007 22:21:47 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com []) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBU3LKIU012776; Sun, 30 Dec 2007 03:21:28 GMT
Received: from xfe-rtp-201.amer.cisco.com ([]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Dec 2007 22:21:20 -0500
Received: from [] ([]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Dec 2007 22:21:20 -0500
Message-ID: <47770EA9.3000403@cisco.com>
Date: Sat, 29 Dec 2007 22:21:13 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird (Windows/20071031)
MIME-Version: 1.0
To: Dave Burke <daveburke@google.com>
References: <C389609A.1208D%eburger@bea.com> <3A12F8FF-8623-484C-ABD4-DE00FBD03B87@softarmor.com> <4766DCC6.3030708@cisco.com> <6e608abf0712211617s40a6f974k5d15256100b02130@mail.gmail.com>
In-Reply-To: <6e608abf0712211617s40a6f974k5d15256100b02130@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Dec 2007 03:21:20.0364 (UTC) FILETIME=[0C1882C0:01C84A93]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9630; t=1198984907; x=1199848907; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20Requested=20Expert=20Review=20Request=3 A=20draft-ietf-mediactrl-vxml-00 |Sender:=20 |To:=20Dave=20Burke=20<daveburke@google.com>; bh=1BSHSlsZlG3dddNCVwfOTMgYtvuw6UfIBj7MeJzKqGg=; b=aermRPCSW9C+lLQbeUMsm03OSGJS6c2tTkPYCSYCeF85MHuOY9C8gYfIZF g/aREB+XeNICQ8vwmMqCIG/D5ZAxcj9KHyHkeTx/sRMomgtCRtlDkIzQij8G d5R0qKjona;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc
Cc: sip-chairs@tools.ietf.org, SIP IETF <sip@ietf.org>, Dean Willis <dean.willis@softarmor.com>, mediactrl@ietf.org, Mark Scott <mscott@voicegenie.com>
Subject: [Sip] Re: Requested Expert Review Request: draft-ietf-mediactrl-vxml-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

I think you are in good shape. I noted a couple of little things below.


Dave Burke wrote:
> Hi Paul,
> Thanks a lot for the review. Mark and I have discussed each of these and 
> I've responded to the comments below.
> Cheers,
> Dave
> [snip]
>     Section 2.1:
>     The ABNF of the URI seems excessively rigid in the ordering of
>     parameters - first the init-parameters, then the vxml-parameters, then
>     then any other uri-parameters. It also doesn't note that
>     'uri-parameters' is defined in 3261.
> DB> Good observation - ordering of the parameters was never intended. 
> Your proposal looks good. However, while looking over this again, we 
> found another issue which crept in late in the process related to the 
> addition of JSON support. Specifically, the problem is that it is 
> impossible to differentiate where vxml-params end and uri-parameters 
> begin and hence which parameter values to interpret as JSON values and 
> which as plain strings. We propose a change to limit JSON values to just 
> the named VoiceXML session variables 'ccxml' and 'aai' (these were the 
> two variables for which JSON support was originally sought).
>   dialog-parameters = *(";" dialog-parameter)
>   dialog-parameter  = init-param / url-parameter ; defined in [RFC 3261]
>   init-param        = ";" (dialog-param /
>                            maxage-param /
>                            maxstale-param /
>                            method-param /
>                            postbody-param /
>                            ccxml-param /
>                            aai-param)

You don't want ";" in the def of init-param because it is in the def of 

>   dialog-param      = "voicexml=" vxml-url ; vxml-url follows the URI
>                                            ; syntax defined in [RFC3986]
>   maxage-param      = "maxage=" 1*DIGIT
>   maxstale-param    = "maxstale=" 1*DIGIT
>   method-param      = "method=" ("get" / "post")
>   postbody-param    = "postbody=" token
>   ccxml-param       = "ccxml=" json-value
>   aai-param         = "aai=" json-value
>   json-value        =  false /
>                        null /
>                        true /
>                        object /
>                        array /
>                        number /
>                        string ; see RFC4627
>     I'm confused about postbody:
> [snip]
>     The interaction between these two escaping rules seems potentially
>     confusing. I *think* when this is all put together it means that the
>     body must first be encoded according to the [HTML4] section above. At
>     that point it will already be almost conformant to the 3261 syntax of a
>     token, except for the use of '&'. Then it needs to be encoded again,
>     which will take care of the ampersands, but which will re-encode the
>     '%'
>     characters of the first encoding.
> [snip]
> DB> Your interpretation of the intent is correct. The postbody value is 
> an application/x-www-form-urlencoded string which we subsequenty 
> re-encode (the latter step affecting each & and % character). We will 
> clarify the text that this is the case. Moreover, we'll be more specific 
> and call out which parameter values are subject to this encoding step , 
> namely vxml-url, the postbody token, and the json-value.
>     Section 2.2:
>        The Application Server SHOULD insert its own URI in the Record-Route
>        header so that it remains in the signaling path for subsequent
>        signaling related to the session.  This is of particular importance
>        for call transfers so that upstream Application Servers or proxy
>        servers see signaling originating from the Application Server and not
>        the VoiceXML Media Server itself.
>     I don't understand the purpose of the above. The SHOULD strength of
>     this
>     requirement suggests to me an assumption of a particular operating
>     environment. In the general case, why should this be more than MAY
>     strength?
> DB> Actually, this paragraph is quite problematic. We shoudn't be 
> mandating how the AS behaves (and indeed a B2BUA doesn't Record-Route 
> anyway). This paragraph is also a hang over from before we recommended 
> against using VoiceXML transfer features with application servers. We 
> propose to delete it.
>     Section 2.3:
>     IMO the use of a media-less session is an entirely valid sip usage. The
>     only concern I might potentially have is if it were to catch some UA
>     unaware, because some UAs just aren't prepared to handle this case. But
>     the recommended usage here always puts the choice of doing this in the
>     hands of *other* UA, not the media server. So I see no problem.
>     I do find it disconcerting that the initial invite and subsequent
>     reinvites are handled in different ways. For the initial one you stall
>     the VXML awaiting a media stream, but on subsequent ones you assume the
>     absence of a stream is equivalent to having a stream that doesn't send
>     anything. Why isn't the behavior consistent in these cases? If you need
>     to support both behaviors, then it might be better to explicit and
>     unique signaling for each. For instance, you might define that a media
>     stream with a=inactive or a=sendonly (from the client's perspective -
>     client putting media server "on hold") could be treated as the absence
>     of input but the absence of the stream means you should wait for a
>     stream to be negotiated.
> DB> We're conscious of the inconsistency but we took a judgement call to 
> live with it. Preparing a session is hugely valuable for latency hiding. 
> However, to support this kind of pause/resume feature once the dialog is 
> executing is not practical since VoiceXML has no concept of such 
> semantics and it is difficult to implement especially when external 
> speech recognition and synthesis systems are used and operate on their 
> own timers without pausing capabilities. 

Well, as long as you have thought about it, it is your call.

> [snip]
>           In addition, the array's toString() function returns the full SIP
>           Request-URI.  For example, assuming a Request-URI of sip:dialog@
>           example.com
>     <http://example.com>;voicexml=http://example.com;obj={
>     <http://example.com;obj=%7B>"x":1,"y":true} then
>     I don't believe the above URI is valid. The ',' '{' and '}' aren't
>     syntactically correct in a URI pvalue. You would need to escape them.
> DB> Good catch, will fix
>     Section 2.6.2:
>     IIUC, message (1) contains no offer, (5) contains an offer with media,
>     and (6) accepts the call but rejects the media. If so, then (9) will
>     most likely be invalid. To make it valid, the o-line from (8) needs to
>     be replaced with one consistent to that used in (6), with the version
>     number incremented. And if (5) has more m-lines than (8), then (9)
>     needs
>     to be padded with extra (rejected) m-lines.
> DB> Good catch. The intent here is to that the similarly SDP messages 
> share the same m- and a- lines only. We propose to update the diagram 
> and perhaps using a prime to denote a derivative SDP message, e.g. 
> [offer2'], and clarifying in the text.
>     Section 5.2:
>        On receipt of the REFER request, the VoiceXML Media Server MUST
>     issue
>        a provisional response, 100 Trying.  The 202 Accepted response
>        indicates that the VoiceXML document has been fetched and parsed
>        correctly.  The VoiceXML Media Server proceeds to place the outbound
>        INVITE and will execute the application after the ACK is sent.
>     The rules of RFC 4320 need to be followed here. REFER is a non-invite
>     transaction and so the timing of the 100 must be as specified in 4320.
> DB> Will fix
>     In the call flow, the sending of the initial NOTIFY before the 202 for
>     the REFER, and especially before determining if REFER is going to
>     succeed or fail, is at best unusual and almost certainly incorrect.
>     Sending the NOTIFY and then sending a failure response would certainly
>     be incorrect.
>     I think you have two choices:
>     - wait until the get is complete before sending the NOTIFY, and probably
>     send it after the 202.
>     - send a 202 for the REFER before doing the GET. Inform of a GET
>     failure
>     via a NOTIFY.
> DB> There is currently an ongoing thread on the list about whether we 
> remove this feature (and hence section) altogether. For the sake of 
> argument, I'll assume it stays, in which case we think option 2 is the 
> most conventional (especially since most systems responds to the REFER 
> instantaneously). A GET failure would be conveyed by a NOTIFY with a 500 
> Server Internal Failure sipfrag message (same status used for the INVITE 
> case).
>     Section 6.3:
>     In the call flow I think you probably need another NOTIFY between
>     messages (6) and (7). Its potentially too long until (13).
> DB> This is correct but we note in the text "(provisional responses and 
>    messages corresponding to provisional responses have been omitted for
>    clarity)"

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip