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

Fri Apr 17 16:39:37 EDT 2009

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.
--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090417/9d1b8890/attachment-0001.html 