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

[<[e-mail]>]

But I don’t understand your sentence “so the why is this required”? What are you referring to? Nothing is required in this RFC.

The sending of a packet repeating previous header is a possibility yes, not listed in the RFC, but the RFC does not claims to be exhaustive. Any way it does not change the Section 5 recommendation.


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


ExactLy,  so then why is this required?

Comfort noise is defined.

And why couldn't I send a header only packet with the previous sent header data?

What about counting that packet in reports?

There is already a spec for feedback could we not have just enforced that with use of a unsolicited nack of the last frame.

My issues are still the same with this draft/rfc and im close to filling errata for the reasons given.

Can we please address them?

Sincerely,
Julius
On Dec 17, 2014 4:56 AM, <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>]
Envoyé : lundi 15 décembre 2014 17:03
À : SOLLAUD Aurélien IMT/OLN
Cc : [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
> Envoyé : lundi 15 décembre 2014 16:37
> À : [e-mail]<mailto:[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.

_________________________________________________________________________________________________________________________

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.