Re: [Sipping] Draft on SIP Interface to VoiceXML

["Dave Burke" <[e-mail]>]

HI Darshan,

Thanks for the review. Comments inline with DB>

Dave
  ----- Original Message ----- 
  From: Darshan Bildikar 
  To: 'Dave Burke' ; [e-mail] 
  Sent: Wednesday, December 14, 2005 5:03 AM
  Subject: RE: [Sipping] Draft on SIP Interface to VoiceXML


  Dear Dave,



  Some comments

 "On receipt of the INVITE, the VoiceXML Media Server issues a provisional response, 100 Trying, and commences the fetch of the initial VoiceXML document.  The 200 OK response indicates that the VoiceXML document has been fetched and parsed correctly and is ready for execution"



  1)       Many SIP flows rely upon media server answering the INVITE immediately. In my opinion it would be better to begin parsing the VXML after generating the answer to the INVITE request by the Application Server. If there is a problem with the VXML then it the SIP dialog can be ended with a BYE. 



  DB> Please see response from RJ in this thread.



  2)       Instead of using "400 Bad Request" wouldn't it be better to use "488 Not Acceptable Here"?



  DB> The 488 Not Acceptable is specific to session description problems. The 400 Bad Request is specific to a problem with the request e.g. malformed syntax and hence I think it is the better choice. 



  3)       The offer answer exchange in section 3.2 is not as per the offer answer standard. The initial INVITE is without an offer and thus the initial offer is contained in a reliable provisional response. In this case the answer should be in PRACK. Also, Note that RTP will start immediately after the reliable provisional response 



  DB> Good catch - will fix in a future revision.



  4)       I don't think it should be mandatory to support a minimal set of codecs. Interoperability is ensured by the offer answer standard. If the media server doesn't support a particular codec; so be it. The request is rejected based on SDP.



  DB> Gracefully declining service because of incompatible media types is not the same thing as interoperability. A minimal set of codecs facilitates a more open architecture to the benefit of network operators. This is really a "best practice" document and we are stating a best practice of supporting a minimum subset of basic codecs.



  5)       In the REFER flow it doesn't make sense to retrieve and process the XML until the referee(?) has answered the INVITE, it would be a waste of n/w and computing resources to fetch and process the VXML if it wont be used at all.



  DB> Conversely, it would be a waste of resources to place a call if the fetch failed (although I'll concede the call answer will likely "fail" more frequently than the fetch!). However, more importantly, if you do the fetch after the call is placed, you get three side-effects: (1) a potential delay and hence "dead air", (2) the possibility of a fetch error "we are experiencing technical difficulties", (3) no way of detecting the error. The current flows avoid these nasty side-effects.



  Regards,

  Darshan

  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave Burke
  Sent: Tuesday, December 13, 2005 3:52 PM
  To: [e-mail]
  Subject: [Sipping] Draft on SIP Interface to VoiceXML



  Hello,



  I would like to notify folks of a recent I-D:



  http://www.ietf.org/internet-drafts/draft-burke-vxml-00.txt



  The specification is principally concerned with the binding of SIP and VoiceXML behaviours and represents a standardisation of similar but somewhat non-interoperable interfaces in production in many of today's SIP networks.



  Thanks,



  Dave

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP