Re: [rtcweb] DTMF resolution proposal

[Roman Shpount <[e-mail]>]

On Wed, Mar 9, 2016 at 4:46 AM, Asveren, Tolga <[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