Subject: [Sipping] Draft on SIP Interface to VoiceXML

From: "Dave Burke" <[email-masked]>
Date: Tue, 13 Dec 2005 10:21:37 -0000

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Darshan Bildikar <[email-masked]>
Date: Wed, 14 Dec 2005 10:33:33 +0530

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. 

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

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 

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.

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.

Regards,

Darshan

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

Hello,

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

---

From: RJ Auburn <[email-masked]>
Date: Wed, 14 Dec 2005 09:37:21 -0500

Darshan,

I wanted to take a moment and address your questions about fetching  
the document before returning a 200 OK to the user. The reason for  
this is that with VoiceXML it's critical that the Media server be  
able to fetch and load the application document before answering the  
call so that the SIP Application Server is able to make a decision on  
what to do if the document is unavailable. If the Media server is  
unable to fetch the document there is no reason for the call to be  
sent there and alternative routing should be selected.

Does that help explain the issue?

Regards,

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Dec 14, 2005, at 24:03 AM, Darshan Bildikar wrote:

> 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”
>
>
> 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.
>
> 2)       Instead of using “400 Bad Request” wouldn’t it be better  
> to use “488 Not Acceptable Here”?
>
> 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
>
> 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.
>
> 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.
>
>
> Regards,
>
> Darshan
>
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Dave Burke
> 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
>
>

---

From: "Dave Burke" <[email-masked]>
Date: Wed, 14 Dec 2005 17:18:32 -0000

HI Darshan,

Thanks for the review. Comments inline with DB>

Dave
  ----- Original Message ----- 
  From: Darshan Bildikar 
  To: 'Dave Burke' ; [email-masked] 
  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: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Burke
  Sent: Tuesday, December 13, 2005 3:52 PM
  To: [email-masked]
  Subject: [Sipping] Draft on SIP Interface to VoiceXML

  Hello,

  Thanks,

  Dave