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

Fri Apr 17 14:04:30 EDT 2009

Spencer,

You're correct.  The "something else" is in-band audio tones via G.711.

I think the important thing to make clear is that endpoints that rely upon SIP-Info will not get SIPConnect support, and that if an endpoint supports 4733, SIPconnect will make sure that it is used that way.

-Jack

>>> "Spencer Dawkins" <spencer at wonderhamster.org> 4/17/2009 13:57 >>>
Just making sure that I'm in sync here.

Is the intention to require Media Endpoints to use RFC 4733? If so, we can 
say this more clearly.

I'm guessing not (since peer Media Endpoints may not conform to 
SIPconnect/1.1), and if not, I think we do need some words that allow Media 
Endpoints to use "something else" if the peer Media Endpoint doesn't 
advertise RFC 4733 support...

Thanks,

Spencer

----- Original Message ----- 
From: "Bernard Aboba" <Bernard_Aboba at hotmail.com>
To: "'DOLLY, MARTIN C, ATTLABS'" <mdolly at att.com>; <blindsay at nortel.com>; 
<audet at nortel.com>; <john.elwell at siemens-enterprise.com>; 
<spencer at wonderhamster.org>; <techwg at sipforum.org>
Sent: Thursday, April 16, 2009 6:40 PM
Subject: RE: [SIPForum-techwg] Comment on section 16.3 (DTMF)

> I'd argue that we want to encourage Media Endpoints supporting the 
> reception
> of DTMF digits to advertize support for RFC 4733.  However, if they don't
> advertise support for RFC 4733, the logical alternative would be to send 
> it
> inband (this was Francois's suggestion).  This should rule out use of INFO
> for DTMF.
>
> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
> Behalf Of DOLLY, MARTIN C, ATTLABS
> Sent: Thursday, April 16, 2009 4:19 PM
> To: blindsay at nortel.com; audet at nortel.com;
> john.elwell at siemens-enterprise.com; spencer at wonderhamster.org;
> techwg at sipforum.org 
> Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>
> 4733 should still be supported with G711
>
> ----- Original Message -----
> From: techwg-bounces at sipforum.org <techwg-bounces at sipforum.org>
> To: Francois Audet <audet at nortel.com>; Elwell, John
> <john.elwell at siemens-enterprise.com>; Spencer Dawkins
> <spencer at wonderhamster.org>; techwg at sipforum.org <techwg at sipforum.org>
> Sent: Thu Apr 16 19:07:42 2009
> Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>
>
> Hi,
>
>   Regarding the sentence:
>
> "A SIP-PBX or SP-SSE MUST advertize support for RFC 4733 in it's SDP
> on behalf of any Media Endpoint that supports receiving DTMF digits"
>
>   As endpoint could support receiving DTMF inband over G.711, so this
> can only apply if the endpoint supports RCC 4733.
>
>   How about clarifying as:
>
> "A SIP-PBX or SP-SSE MUST advertize support for RFC 4733 in it's SDP
> on behalf of any Media Endpoint that supports receiving DTMF digits
> using RFC 4733 procedures"
>
>   For the following:
>
> "Any Media Endpoint that supports sending DTMF MUST use the RFC 4733
> procedures, provided that the other side has advertized support for
> receiving RFC 4733 in the offer/answer exchange."
>
>  How about adding:
>
> "Otherwise, DTMF MAY be sent inband using a previously negotiated
> codec."
>
>  Regards
>     Brian
>
> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] 
> On Behalf Of Audet, Francois (SC100:3055)
> Sent: Thursday, April 16, 2009 11:02 AM
> To: Elwell, John; Spencer Dawkins; techwg at sipforum.org 
> Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>
> That works for me.
>
>> -----Original Message-----
>> From: Elwell, John [mailto:john.elwell at siemens-enterprise.com] 
>> Sent: Thursday, April 16, 2009 01:18
>> To: Audet, Francois (SC100:3055); Spencer Dawkins; techwg at sipforum.org 
>> Subject: RE: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>>
>> We run up against the architectural problem again when we talk about
>> the Media Endpoint doing SDP offer/answer.
>>
>> I previously proposed the following text and I though Francois agreed,
>
>> so why can't we adopt this?
>>
>> "A SIP-PBX or SP-SSE MUST advertize support for RFC 4733 in it's SDP
>> on behalf of any Media Endpoint that supports receiving DTMF digits.
>>
>> Any Media Endpoint that supports sending DTMF MUST use the RFC 4733
>> procedures, provided that the other side has advertized support for
>> receiving RFC 4733 in the offer/answer exchange."
>>
>> John
>>
>>
>> > -----Original Message-----
>> > From: Francois Audet [mailto:audet at nortel.com] 
>> > Sent: 14 April 2009 23:19
>> > To: Spencer Dawkins; Elwell, John; techwg at sipforum.org 
>> > Subject: RE: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>> >
>> > I don't think the phrase "supports the transport of DTMF
>> tones" makes
>> > any sense.  That whole second paragraph is unclear on who is sender
>> > who is receiver. I would reword the second paragraph as follows:
>> >
>> > "Any Media Endpoint that supports the reception of DTMF tones MUST
>> > support the negotiation via an SDP offer/answer of the supported
>> > method used to transmit the tones. The Media Endpoint
>> transmiting the
>> > RTP payload MUST use the dynamic RTP payload type advertized in the
>> > SDP by the Media Endpoint advertizing support for receiving
>> RFC 4733
>> > packets."
>> >
>> > And the third paragraph:
>> >
>> > "Any Media Endpoint that supports sending DTMF MUST use the
>> RFC 4733
>> > procedures to transmit DTMF tones using the RTP telephone-event
>> > payload format, provided that the other side has advertized support
>> > for receiving RFC 4733 in the offer/answer exchange."
>> >
>> > > -----Original Message-----
>> > > From: Spencer Dawkins [mailto:spencer at wonderhamster.org] 
>> > > Sent: Tuesday, April 14, 2009 15:09
>> > > To: Audet, Francois (SC100:3055); Elwell, John;
>> techwg at sipforum.org 
>> > > Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>> > >
>> > > I think the final text you guys are talking about looks
>> roughly like
>> > > this:
>> > >
>> > > "A SIP-PBX or SP-SSE MUST advertize support for RFC 4733
>> in its SDP
>> > > on behalf of any Media Endpoint that supports receiving
>> DTMF digits.
>> > >
>> > > "Any Media Endpoint that supports the transport of DTMF
>> tones MUST
>> > > support the negotiation via an SDP offer/answer of the supported
>> > > method used to transport the tones. The Media Endpoint
>> MUST support
>> > > the ability to use any dynamic RTP payload type when
>> negotiating the
>> > > use of RFC 4733.
>> > >
>> > >
>> > > "Any Media Endpoint that supports sending DTMF MUST use
>> the RFC 4733
>> > > procedures to transport DTMF tones using the RTP telephone-event
>> > > payload format, provided that the other side has
>> advertized support
>> > > for receiving RFC 4733 in the offer/answer exchange."
>> > >
>> > >
>> > >
>> > > Does this work for  people?
>> > >
>> > >
>> > >
>> > > Thanks,
>> > >
>> > >
>> > >
>> > > Spencer
>> > >
>> > >
>> > >
>> > > ----- Original Message -----
>> > > From: "Francois Audet" <audet at nortel.com>
>> > > To: "Elwell, John" <john.elwell at siemens-enterprise.com>;
>> > > <techwg at sipforum.org>
>> > > Sent: Thursday, April 09, 2009 3:47 PM
>> > > Subject: Re: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>> > >
>> > >
>> > > > Yep.
>> > > >
>> > > >> -----Original Message-----
>> > > >> From: Elwell, John [mailto:john.elwell at siemens-enterprise.com] 
>> > > >> Sent: Thursday, April 09, 2009 13:22
>> > > >> To: Audet, Francois (SC100:3055); techwg at sipforum.org 
>> > > >> Subject: RE: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>> > > >>
>> > > >>
>> > > >>
>> > > >> > -----Original Message-----
>> > > >> > From: Francois Audet [mailto:audet at nortel.com] 
>> > > >> > Sent: 09 April 2009 19:33
>> > > >> > To: Elwell, John; techwg at sipforum.org 
>> > > >> > Subject: RE: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>> > > >> >
>> > > >> > I think the wording is kind of awkward.
>> > > >> >
>> > > >> > The real point is that IF you need to either send or
>> > > >> receive (or both)
>> > > >> > DTMF, it must be done using RFC 4733. Typically, phones
>> > > for example
>> > > >> > don't need to be able to receive DTMF. Some specialized
>> > > devices may
>> > > >> > not have to send them either (e.g., a hot-line phone with
>> > > >> no keypad,
>> > > >> > etc.).
>> > > >> >
>> > > >> > What about:
>> > > >> >
>> > > >> > Any Media Endpoint in the Enterprise network or Service
>> > > Provider's
>> > > >> > network that support receiving DTMF digits MUST advertize
>> > > >> its support
>> > > >> > for RFC 4733 in it's SDP in an Offer or Answer as
>> appropriate.
>> > > >> >
>> > > >> > Any Media Endpoint that supports sending DTMF MUST use
>> > > the RFC 4733
>> > > >> > procedures, provided that the other side has advertize
>> > > support for
>> > > >> > receiving RFC 4733 in the Offer/Answer exchange.
>> > > >> >
>> > > >> > Note that there is no advertizing of the ability to send
>> > > RFC 4733;
>> > > >> > only the ability to receive RFC 4733.
>> > > >> [JRE] Fine, but this is not quite in accordance with the
>> > > >> architecture, where the SIP-PBX or SP-SSE does the
>> > > signalling and the
>> > > >> media endpoint does the RTP. To correct this I would say:
>> > > >>
>> > > >> "A SIP-PBX or SP-SSE MUST advertize support for RFC 4733
>> > > in it's SDP
>> > > >> on behalf of any Media Endpoint that supports receiving
>> > > DTMF digits.
>> > > >>
>> > > >> Any Media Endpoint that supports sending DTMF MUST use the
>> > > RFC 4733
>> > > >> procedures, provided that the other side has advertized
>> > > support for
>> > > >> receiving RFC 4733 in the offer/answer exchange."
>> > > >>
>> > > >> John
>> > > >>
>> > > >> >
>> > > >> >
>> > > >> > > -----Original Message-----
>> > > >> > > From: techwg-bounces at sipforum.org 
>> > > >> > > [mailto:techwg-bounces at sipforum.org] On Behalf Of
>> > Elwell, John
>> > > >> > > Sent: Thursday, April 09, 2009 06:20
>> > > >> > > To: techwg at sipforum.org 
>> > > >> > > Subject: [SIPForum-techwg] Comment on section 16.3 (DTMF)
>> > > >> > >
>> > > >> > > 1. "Any Media Endpoint in the Service Provider's network
>> > > >> MUST also
>> > > >> > > support the ability to transport DTMF tones using the RTP
>> > > >> > > telephone-event payload format as described in RFC 4733
>> > > >> when using
>> > > >> > > any codec.
>> > > >> > > Any Media Endpoint in the Enterprise network that
>> > > >> originates and/or
>> > > >> > > terminates voice traffic MUST support RFC 4733."
>> > > >> > >
>> > > >> > > Why are requirements slightly different for the two sides.
>> > > >> > > Should we combine these statements:
>> > > >> > > "Any Media Endpoint in the Enterprise network or Service
>> > > >> Provider's
>> > > >> > > network MUST also support the ability to transport DTMF
>> > > >> tones using
>> > > >> > > the RTP telephone-event payload format as described in
>> > > >> RFC 4733 when
>> > > >> > > using any codec."
>> > > >> > >
>> > > >> > > 2. Concerning this same text, this doesn't explicitly
>> > > >> make provision
>> > > >> > > for media endpoints that can transport DTMF but do
>> > not need to
>> > > >> > > receive it.
>> > > >> > > So should we add the sentence:
>> > > >> > > "This applies to transmission and, if applicable,
>> > > >> reception of DTMF
>> > > >> > > tones."?
>> > > >> > >
>> > > >> > > 3. "Any Media Endpoint in the Enterprise network that
>> > > >> supports the
>> > > >> > > transport of DTMF tones MUST support the negotiation
>> > > via an SDP
>> > > >> > > offer/answer of the supported method used to transport
>> > > the tones."
>> > > >> > > Shouldn't this apply to SP endpoints too? A text proposal
>> > > >> for this
>> > > >> > > is in an earlier email dealing with architecture.
>> > > >> > >
>> > > >> > > John
>> > > >> > >
>> > > >> > > _______________________________________________
>> > > >> > > techwg mailing list
>> > > >> > > Send mail to: techwg at sipforum.org Unsubscribe or edit
>> > > options at:
>> > > >> > > http://sipforum.org/mailman/listinfo/techwg 
>> > > >> > >
>> > > >> >
>> > > >>
>> > > >
>> > > > _______________________________________________
>> > > > techwg mailing list
>> > > > Send mail to: techwg at sipforum.org Unsubscribe or edit options
>> > > > at:
>> > > > http://sipforum.org/mailman/listinfo/techwg 
>> > > >
>> > >
>> > >
>> > >
>> >
>>
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org 
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg 
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org 
> Unsubscribe or edit options at: 
> http://sipforum.org/mailman/listinfo/techwg 
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org 
> Unsubscribe or edit options at: 
> http://sipforum.org/mailman/listinfo/techwg 
>
> 

_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org 
Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg

--------------------------------------------------------
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/16d4b3e0/attachment-0001.html 