- From: Eric Burger <eburger@brooktrout.com>
- Date: Wed, 21 Apr 2004 11:38:42 -0400
- To: "'Tony Yat-Tung Cheung '" <tony@astri.org>, "'www-voice@w3.org '" <www-voice@w3.org>
Sorry to be jumping in the middle,* without reading the full context, but... On the one hand, SUBSCRIBE/NOTIFY is a reasonable transport mechanism for events, e.g., for CCXML communication. On the other hand, don't even THINK of using NOTIFY for VoiceXML results. Absolutely, positively, uncontroverably, do not even CONSIDER using NOTIFY for transporting VoiceXML documents. That really breaks most SIP semantics, and also means proprietary application servers, as well. -- - Eric * I'm on vacation this month... -----Original Message----- From: Tony Yat-Tung Cheung To: www-voice@w3.org Sent: 4/21/04 8:27 AM Subject: Re: SIP NOTIFY and VoiceXML Technologies @ Phonologies wrote: > > >> >> It is natural to use VoiceXML to drive the behaviour of a SIP user >> agent. Now SIP provides the SUBSCRIBE-NOTIFY mechanism, how does >> VoiceXML and SIP NOTIFY tie together? >> > Also, if u think the SIP platform should be driven by the Application, > then it should better be left to > CCXML instead of VoiceXML. > > raj Hi RJ Auburn, raj, others, Yes, I think it makes sense to use CCXML for this purpose. Since SIP NOTIFY is a rather fundamental element of the SIP functionality, I hope some standard practices may come up eventually. However, I would continue to use VoiceXML for this purpose, as adding CCXML seem an overkill for me for just doing this purpose. I would definitely consider CCXML when other functionalities of CCXML are needed as well. I just thought that the other way to send the SIP/NOIFY is to perform an HTTP request to a remote web server, such as a servlet or CGI and let it handles sending the SIP NOTIFY message. However, it is typical that the VoiceXML browsers actually contain the SIP stack itself, so for the time being I think I would go for the <object> solution. Thank you. Best Regards, Tony Cheung
Received on Wednesday, 21 April 2004 13:35:54 UTC