Re: [MEDIACTRL] [OPS-DIR] FW: Evaluation: draft-ietf-mediactrl-vxml-04.txt toProposed Standard

["Romascanu, Dan (Dan)" <[e-mail]>]

Tina,
 
Thanks for the review. 
 
I will enter a COMMENT in the tracker prior to the IESG telechat. I do
not consider these issues blocking, but it would be good for the editors
to address them. 
 
Regards,
 
Dan
 


________________________________

	From: Tina TSOU [mailto:[e-mail]] 
	Sent: Thursday, February 26, 2009 6:27 AM
	To: Romascanu, Dan (Dan)
	Cc: [e-mail]; [e-mail];
[e-mail]
	Subject: Re: [OPS-DIR] FW: Evaluation:
draft-ietf-mediactrl-vxml-04.txt toProposed Standard
	
	

	Hi,

	  This is a review of draft-ietf-mediactrl-vxml-04.txt for its

	  operational impact.

	

	  Summary: This document specifies a SIP interface to VoiceXML
media

	   services.  Commonly, application servers controlling media
servers

	   use this protocol for pure VoiceXML processing capabilities.


	.

	

	  Review summary: 

	This document should consider the compatibility with other
protocols between application servers and media servers

	  -----------

	

	  Possible Operational Issues: Below are listed a number of
issues that may

	  have significant operational impact.  Further explanation or

	  investigations is warranted on each of these.

	

	  ---------

	

	  Review Questions:

	

	  Is the document readable?

	1. In section 9 Security Considerations, it says SRTP should be
supported to provide confidentiality, authentication, and replay
protection for RTP media streams (including RTCP control traffic).
However, in above use cases, all the message types are RTP/SRTP. In RTP
case, how to guarantee security? So I suggest change "RTP/SRTP" to "RTP
and SRTP" in all the use cases or to any other expressions to well
express the problem.

	

	2. The authentication procedures should also be considered in
the document.

	  

	Does it contain nits?

	

	     Yes, some.

	4.2.  SIP Mechanism

	Note that sending expr/namelist data in the 200 OK response
requires

	   that the VoiceXML Media Server delay the final response to
the

	   received BYE request until the VoiceXML Application's
post-disconnect

	final processing state terminates.

	

	Should be changed to 

	Note that sending expr/namelist data in the 200 OK response
requires

	   that the VoiceXML Media Server delays the final response to
the

	   received BYE request until the VoiceXML Application's
post-disconnect

	final processing state terminates.

	

	If the expr attribute is specified on the <exit> element instead
of the

	   namelist attribute, the reserved name __exit is used.

	Should be changed to 

	If the expr attribute is specified in the <exit> element instead
of the

	   namelist attribute, the reserved name -- exit is used.

	

	

	6.2.  Bridge

	Once the transfer is established, the VoiceXML Media Server can

	   "listen" to the media stream from User Agent 1 to perform
speech or

	   DTMF hotword, which when matched results in a near-end
disconnect,

	   i.e. the VoiceXML Media Server issues a BYE to User Agent 2
and the

	   VoiceXML Application continues with User Agent 1.  A BYE will
also be

	   issued to User Agent 2 if the call duration exceeds the
maximum

	   duration specified in the maxtime attribute on <transfer>.

	   

	Should be changed to 

	Once the transfer is established, the VoiceXML Media Server can

	   "listen" to the media stream from User Agent 1 to perform
speech or

	   DTMF hotword when matched results in a near-end disconnect,

	   i.e. the VoiceXML Media Server issues a BYE to User Agent 2
and the

	   VoiceXML Application continues with User Agent 1.  A BYE will
also be

	   issued to User Agent 2 if the call duration exceeds the
maximum

	   duration specified in the maxtime attribute on <transfer>.

	

	

	  Is the document class appropriate?

	

	        Yes, the document class seems appropriate.

	

	  Is the problem well stated?

	

	        The document does not state clearly why we need to use
VoiceXML between Application Server and Media server.

	

	  Is the problem really a problem?

	

	        The problem described by this document is not clear
enough.

	  Does the document consider existing solutions?

	

	       No.

	

	  Does the solution break existing technology?

	

	        To the best of my understanding, this will not break
existing

	        Technology because This protocol is an adjunct to the
full MEDIACTRL protocol and packages mechanism.

	

	

	  Does the solution preclude future activity?

	

	        No, this attribute is easily applicable in future
situations.

	

	  Is the solution sufficiently configurable?

	

	        Yes, the solution is very flexible.

	

	  Can performance be measured?  How?

	

	  Not sure, because other protocols may have the same
performance.       

	

	  Does the solution scale well?

	

	No knowledge.  

	

	

	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	
	B. R.
	Tina

	http://tinatsou.weebly.com/contact.html
	

	
	



	On Feb 22, 2009, at 11:59 PM, Romascanu, Dan (Dan) wrote:




		A URL of this Internet-Draft is:
	
http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-vxml-03.txt
		
		Technical Summary
		
		his document describes a SIP interface to VoiceXML media
services.
		Commonly, application servers controlling media servers
use this
		protocol for pure VoiceXML processing capabilities. This
protocol is an
		adjunct to the full MEDIACTRL protocol and packages
mechanism.
		
		Working Group Summary
		
		There is consensus in the WG to publish this document.
		
		Document Quality
		
		This document has had sufficient work group review. In
addition, it had
		external review by the SIP Work Group. There are
multiple known
		interoperable client and server implementations.
		
		The document has been checked using idnits and an ABNF
checker and
		passed both checks.
		
		Personnel
		
		Eric Burger shepherds this document, has reviewed this
document, and
		believes that the -01 version is ready for forwarding to
the IESG for
		publication. The responsible Area Director is Jon
Peterson. Gen-ART
		review was provided by Scott Brim.
		
		RFC Editor Note
		
		 (Insert RFC Editor Note here or remove section)
		
		IRTF Note
		
		 (Insert IRTF Note here or remove section)
		
		IESG Note
		
		 (Insert IESG Note here or remove section)
		
		IANA Note
		
		 (Insert IANA Note here or remove section)
		
		
		
		
		
		
		_______________________________________________
		OPS-DIR mailing list
		[e-mail]
		https://www.ietf.org/mailman/listinfo/ops-dir