Re: [AVTCORE] Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)

[Julius Friedman <[e-mail]>]

Thanks for the update.  I see ice is excluded but if stun etc was also
excluded then it should be indicated in the same place.

Please indicate why this is necessary if I am multiplexing and rtcp is
enabled.  My nat will not timeout.

If I am a translator version 0 will not be ignored.

Senders octet count will be wrong unless the packet is skipped.

All of my previous points still apply and sending a header only repeated
would be more complaint no matter the case of use.

I will follow errata if I need to but first the points need addressing.

Thanks.
On Dec 15, 2014 10:54 AM, <[e-mail]> wrote:
>
> Hello
>
>
>
> I don’t know what version of the draft you are referring to, but this
document was published as RFC 6263 in June 2011. So you may check this
final release.
>
>
>
> In particular the Introduction section states that ICE and STUN are out
of scope.
>
>
>
> Aurelien
>
>
>
> De : Julius Friedman [mailto:[e-mail]]
> Envoyé : lundi 15 décembre 2014 16:37
> À : [e-mail]
> Objet : Mail regarding draft-ietf-avt-app-rtp-keepalive
>
>
>
> Hello guys,
>
> Based on the fact this draft cites keep alive are not recommended I would
to chime in.
>
> I would also like to indicate this process causes detected loss in the
sender report unless the keep alive packet is not counted.
>
> Since rtcp is enabled what is timing out? The port mapping for the rtp
port? What if im multiplexing on the same port then how does this matter?
>
> Specifically for non multiplexing why wouldn't ice or stun have their own
methods of keeping the port mapping alive? And why should a rtp client have
to handle this?
>
> This seems like a ice or stun change more than rtp.
>
> Furthermore couldn't you just send a header only packet with the last
sequence number etc  which should also be Ignored and in a more complaint
way.
>
> Translators may not ignore version 0 packets or dynamic payload types
undefined in the sdp.
>
> Sincerely,
> Julius Richard Friedman
>
>
_________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
> Thank you.