Re: [Sipping] Draft on SIP Interface to VoiceXML

[RJ Auburn <[e-mail]>]

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:[phone]



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”
>
>
> 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: [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


_______________________________________________
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