Re: [rtcweb] DTMF resolution proposal

["Asveren, Tolga" <[e-mail]>]

 “WebRTC endpoint is specifically different from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN. They just need to interop with full WebRTC endpoints.”
As the bottom line, would a gateway need to comply with the range restrictions for the RFC4733 it is sending toward the WebRTC leg or not? I *think* what you say is that it does not. I strongly would prefer that the text is clear on this issue.

Thanks,
Tolga


From: Roman Shpount [mailto:[e-mail]]
Sent: Wednesday, March 09, 2016 10:52 AM
To: Asveren, Tolga <[e-mail]>
Cc: Ted Hardie <[e-mail]>; Jean-Marc Valin <[e-mail]>; Cullen Jennings <[e-mail]>; [e-mail]
Subject: Re: [rtcweb] DTMF resolution proposal

On Wed, Mar 9, 2016 at 4:46 AM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:
i- I personally would prefer not to leave a grey area (after all, the gap between retransmitted end-packets is another value, which needs to be known/determined/provided).

There are a lot of grey areas in how RFC 4733 tones are generated, including how often tone update packets should be sent when tone is being played, should audio signal be sent during tone generation, should audio packets be sent during the tone generation, should tone duration and start be extended to a regular, non-tone packet boundary, what interval should be used for the end of tone packet. This group indicated that it is not interested in defining any of these things and I would prefer to keep these things out rtcweb-audio draft.

If you think (I definitely think so), that RFC 4733 can be improved with the set of recommendations on how tones should be generated, this should be discussed in a different group (avtcore or avtext) as either RFC 4733 update or an independent information draft. This information would not be rtcweb specific and most likely benefit other VoIP implementations.

ii- I wouldn’t mind if the min-value for retransmission gap is 10ms, or even 0ms, and actually would prefer 0ms as it does not impose any restrictions (this all assuming –which IMHO is not the right choice- that the limits will be specified in rtcweb-audio draft rather than in W3C specification)

I believe anything network protocol related should be specified in one of the IETF groups. If it is rtcweb specific it should go into one of the rtcweb drafts. If it generic (like a general RFC 4733 update) it should be done by the group responsible for this specification.

iii- It is not clear to me whether the use of the word “WebRTC endpoint” by default covers gateways as well. draft-ietf-rtcweb-gateways-02 has the following:
   A WebRTC gateway appears as a WebRTC-compatible endpoint, and will
   thus not be conformant with all requirements for a WebRTC endpoint
   (it does not do everything a WebRTC endpoint does), but is able to
   interoperate with WebRTC endpoints.
I interpret this as “Anything, which is mandated for webrtc-endpoints and not explicitly specified as not applicable for gateways in  rtcweb-gateway document is applicable for gateways too”, in which case I would suggest adding a statement to rtcweb-gateway document that RFC4733 limits do not apply to it (just trying to prevent the possibility of interworking).

WebRTC endpoint is specifically different from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN. They just need to interop with full WebRTC endpoints.

iv- I don’t understand why retransmission gap limit would require RFC4733 update whereas the other limits under consideration don’t.


As I have mentioned above, there is a lot more then just final packet retransmission gap which is left to be implementation specific in RFC4733. I have a feeling this group is tired of DTMF so if you want to discuss this, we should discuss this elsewhere (avtcore or avtext). Whatever is decided there will affect rtcweb as well as other RFC 4733 implementations.

Regards,
_____________
Roman Shpount