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

[Julius Friedman <[e-mail]>]

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]> 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]]
> 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.
>
>