[SIPForum-techwg] Comment on section 16.3 (DTMF)

Francois Audet audet at nortel.com
Fri Apr 17 17:43:02 EDT 2009 

I just think leaving out this sentence altogether is fine:
"Utilization of the INFO or inband mechanisms is NOT RECOMMENDED as there is no assurance that an IP-PBX or SSE will employ equipment or CODECs that will support these methods."



________________________________

	From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Jack Burton
	Sent: Friday, April 17, 2009 14:00
	To: techwg at sipforum.org
	Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
	
	
	I think in-band via G.711 works very well if you have little or no packet loss, but that's not important.
	 
	Is there another way to make it clear that NOT RECOMMENDED implies "NOT SUPPORTED" or "WILL NOT WORK" in many instances?  For example:
	- SSE does not transcode
	- G.729 is used (or another compression codec)
	- SSE peers with someone that does not transcode
	- PBX voice mail does not decode in-band DTMF
	- SSE voice mail does not decode in-band DTMF
	- packet loss in network
	etc.
	 
	I want to strengthen the RFC4733 requirement, not weaken it.
	 
	-Jack


	>>> "Francois Audet" <audet at nortel.com> 4/17/2009 16:49 >>>
	
	Do we evven need to say that?
	 
	PS: As a side not, the problem with in-band is not that the other end's codec may not support it, it's that it may not be decoded properly because of lots of reasons.


________________________________

		From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Jack Burton
		Sent: Friday, April 17, 2009 13:40
		To: techwg at sipforum.org
		Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
		
		
		Oops, Typo.  Corrected below.
		
		>>> "Jack Burton" <JSBURTON at cablevision.com> 4/17/2009 16:36 >>>
		
		That works for me.
		 
		Would it help to further qualify "NOT RECOMMENDED" as follows?

		"Utilization of the INFO or inband mechanisms is NOT RECOMMENDED as there is no assurance that an IP-PBX or SSE will employ equipment or CODECs that will support these methods."
		
		-Jack
		 
		>>> "Bernard Aboba" <Bernard_Aboba at hotmail.com> 4/17/2009 16:23 >>>
		

		I agree with your concern.   The “on behalf of” language in the proposed text is problematic. 

		How about this?

		"RFC 4733 is the REQUIRED mechanism for communication of DTMF between a SIP-PBX and an SSE.  Utilization of the INFO or inband mechanisms is NOT RECOMMENDED.

		 

		So as to ensure that RFC 4733 can be used successfully, Media Endpoints that support receiving DTMF digits MUST advertise support for RFC 4733 in SDP. A Media Endpoint that supports sending DTMF MUST use the RFC 4733 procedures provided that the other side advertises support for receiving RFC 4733 in the off/answer exchange.”

		 

		From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Jack Burton
		Sent: Friday, April 17, 2009 12:58 PM
		To: techwg at sipforum.org
		Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)

		 

		Bernard,

		 

		I agree, but I don't think I ever want a PBX advertising 4733 support where none exists.  That would make the other end of the call send 4733, and the device behind the endpoint gets silence instead of tones.  Or, are we requiring the PBX to transcode?  That's not within the capabilities of any existing ones I know of.

		 

		It should be simpler to say that 4733 is the SIP Connect way:  If an endpoint advertises 4733, then the IP-PBX must do so on its behalf.  (Perhaps all other cases are out of scope.)

		 

		-Jack
		
		>>> Bernard Aboba <bernard_aboba at hotmail.com> 4/17/2009 15:40 >>>
		What we're trying to achieve is to ensure that only 4733 is used across the PBX-SSE interface.   That's something that would appear to be within the scope of SIPConnect 1.1, so I think that we could insert normative language relating to that. 
		
		We can get to that in multiple ways.  One way is if the enterprise configures all the media endpoints capable of receiving DTMF to advertise 4733.  I'm not sure that we can require this SIPConnect 1.1, but we could include mention of this approach in an informative statement explaining how to meet the normative requirement (only use 4733 across the PBX-SSE interface). 
		
		The question is what we do if there are endpoints that can do DTMF but aren't configured for or can't support 4733.   The text that was proposed is requiring the SIP-PBX to advertise RFC 4733 "on behalf" of the media endpoints that support DTMF but don't do 4733.   This relates to the SIP-PBX so it is also within scope of SIPConnect 1.1.  However, some SIP-PBXes can do that, some can't.  Two ways to get around this come to mind:
		
		a. Focus on the overall normative requirement (only 4733 across the PBX-SSE interface)
		b.  Make the "behalf of" requirement conditional (e.g. only required if there are media endpoints that are DTMF capable but can't advertise 4733).  

	

		 

		
________________________________


		From: HKaplan at acmepacket.com
		To: bernard_aboba at hotmail.com; spencer at wonderhamster.org; mdolly at att.com; blindsay at nortel.com; audet at nortel.com; john.elwell at siemens-enterprise.com; techwg at sipforum.org
		Date: Fri, 17 Apr 2009 15:09:04 -0400
		Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)

		I don’t disagree not all media endpoints do 4733, but once you say “what if some endpoints don’t do this thing we expect in SIP Connect”, then the next question would be where to stop.  Because not all endpoints send DTMF inband either; and for some codecs they couldn’t even if they wanted to; and even if they do their DTMF won’t work in some call scenarios if they send it inband in audio. (some calling card applications require out-of-band DTMF, for example)

		 

		I guess my point is that while the endpoints don’t fall under SIP-Connect’s interface, we basically have to treat the Enterprise as a logical single black box to a large degree, and thus have to expect the whole IP-PBX “system” to support SIP-Connect, no?  

		 

		-hadriel

		 

________________________________

		From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Bernard Aboba
		Sent: Friday, April 17, 2009 2:44 PM
		To: spencer at wonderhamster.org; mdolly at att.com; blindsay at nortel.com; audet at nortel.com; john.elwell at siemens-enterprise.com; techwg at sipforum.org
		Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)

		 

		Requiring all media endpoints to support RFC 4733 seems like a stretch... which leads to the need for an alternative if the media endpoint doesn't advertise RFC 4733 support. 

		 

________________________________

		The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.

		
________________________________


________________________________

		The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. 
________________________________


________________________________

		The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. 
________________________________



________________________________

	The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. 
________________________________


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090417/01f96924/attachment-0001.html

More information about the techwg mailing list