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

[<[e-mail]>]

Hello

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

Exactly. There is no trick here, the only RECOMMENDED method in the RFC 6263 is RTP-RTCP multiplexing, where regular RTCP traffic will maintain the NAT binding alive.

Aurelien

De : Julius Friedman [mailto:[e-mail]] 
Envoyé : lundi 15 décembre 2014 17:03
À : SOLLAUD Aurélien IMT/OLN
Cc : [e-mail]
Objet : RE: Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)

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.

_________________________________________________________________________________________________________________________

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.