RE: [Sipping] Draft on SIP Interface to VoiceXML

[Darshan Bildikar <[e-mail]>]

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