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

From: Julius Friedman <[email-masked]>
Date: Mon, 15 Dec 2014 11:02:51 -0500

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, <[email-masked]> 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:[email-masked]]
> Envoyé : lundi 15 décembre 2014 16:37
> À : [email-masked]
> 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.

---

From: Julius Friedman <[email-masked]>
Date: Wed, 17 Dec 2014 08:35:17 -0500

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, <[email-masked]> wrote:

> 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
>
> Envoyé : lundi 15 décembre 2014 17:03
> À : SOLLAUD Aurélien IMT/OLN
> Cc : [email-masked]
> Objet : RE: Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)
>
> > Based on the fact this draft cites keep alive are not recommended I
> would to chime in.
> >
> > 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?
> >
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>

---

From: <[email-masked]>
Date: Wed, 17 Dec 2014 09:56:51 +0000

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

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, <[email-masked]> 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
>
>  
>
> 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?
>
> 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;
> 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.

---

From: <[email-masked]>
Date: Wed, 17 Dec 2014 13:47:20 +0000

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:[email-masked]]
Envoyé : mercredi 17 décembre 2014 14:35
À : SOLLAUD Aurélien IMT/OLN
Cc : [email-masked]
Objet : RE: Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)

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

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.

Sincerely,
Julius
On Dec 17, 2014 4:56 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hello

Aurelien

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

On Dec 15, 2014 10:54 AM, <[email-masked]<mailto:[email-masked]>> wrote:
> De : Julius Friedman [mailto:[email-masked]<mailto:[email-masked]>]
> À : [email-masked]<mailto:[email-masked]>