Subject: [avtext] RTP stream pause and keepalives

From: Christian Groves <[email-masked]>
Date: Wed, 10 Sep 2014 10:19:46 +1000

Hello Bo,

A colleague mentioned there might be an issue with regards to heartbeats 
keeping NAT resources open, i.e. as per clause 10/RFC5245 when an RTP 
stream is paused. We probably need to add some text to the draft to 
indicate what happens when an RTP stream is paused. I take it that 
normal media should be paused but that any RTP keepalive (e.g. comfort 
noise, No-Op or incorrect version) should still be transmitted.

Regards, Christian

---

From: Bo Burman <[email-masked]>
Date: Wed, 10 Sep 2014 07:35:27 +0000

Hi Christian,

You are entirely right, the intent is that RTP stream pause does not affect keepalive. I have no problem with adding some clarifying statement.

I also think sec 10 / RFC 5242 text is pretty clear on this: "These keepalives MUST be sent regardless of whether the media stream is currently inactive, sendonly, recvonly, or sendrecv...", and even "...keepalives MUST be sent even if ICE is not being utilized for the session at all". I see RTP stream pause as being even more "temporary" than setting a stream inactive, so a paused RTP stream should definitely be "live" enough to make the above RFC 5245 statements apply.

Do you think that a reference to RFC 5245 from the pause draft is appropriate and sufficient?

Tentative text, possibly after second clause of sec 6.3 ("Paused State"):
"Pausing an RTP stream MUST NOT affect the sending of RTP keepalive [RFC5245] applicable to that RTP stream",
as well as adding RFC 5245 as a normative reference. Is it correct to have it as a normative reference, even if it is not mandated by this draft to actually implement RFC 5245, but just referencing it in a normative statement?

I don't think that referencing RFC 5245 opens up to allowing RTP stream pause affect "non-RFC 5245 keepalive", because the text in RFC 5245 seems generic enough to cover any perceivable RTP keepalive procedure. Do you agree?

I think including "applicable to that RTP stream" should also cover the case when BUNDLE is used, because then a single keepalive can "apply" to multiple RTP streams. OK?

Comments to text formulation and placement are welcome.

Cheers,
/Bo

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: den 10 september 2014 02:20
> To: [email-masked]
> Subject: [avtext] RTP stream pause and keepalives
> 
> Hello Bo,
> 
> A colleague mentioned there might be an issue with regards to heartbeats keeping NAT resources open, i.e. as per
> clause 10/RFC5245 when an RTP stream is paused. We probably need to add some text to the draft to indicate what
> happens when an RTP stream is paused. I take it that normal media should be paused but that any RTP keepalive (e.g.
> comfort noise, No-Op or incorrect version) should still be transmitted.
> 
> Regards, Christian
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: "Roni Even" <[email-masked]>
Date: Wed, 10 Sep 2014 12:02:50 +0300

Hi Bo,
I think the text you propose make sense. Wondering if we should reference
RFC6263 and not RFC 5245
 
Roni

> From: avtext [mailto:[email-masked]] On Behalf Of Bo Burman
> Sent: 10 September, 2014 10:35 AM
> To: Christian Groves; [email-masked]
> Subject: Re: [avtext] RTP stream pause and keepalives
> 
> Hi Christian,
> 
> You are entirely right, the intent is that RTP stream pause does not
affect
> keepalive. I have no problem with adding some clarifying statement.
> 
> I also think sec 10 / RFC 5242 text is pretty clear on this: "These
keepalives
> MUST be sent regardless of whether the media stream is currently inactive,
> sendonly, recvonly, or sendrecv...", and even "...keepalives MUST be sent
even
> if ICE is not being utilized for the session at all". I see RTP stream
pause as
> being even more "temporary" than setting a stream inactive, so a paused
RTP
> stream should definitely be "live" enough to make the above RFC 5245
> statements apply.
> 
> Do you think that a reference to RFC 5245 from the pause draft is
appropriate
> and sufficient?
> "Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
> [RFC5245] applicable to that RTP stream", as well as adding RFC 5245 as a
> normative reference. Is it correct to have it as a normative reference,
even if it
> is not mandated by this draft to actually implement RFC 5245, but just
> referencing it in a normative statement?
> 
> I don't think that referencing RFC 5245 opens up to allowing RTP stream
pause
> affect "non-RFC 5245 keepalive", because the text in RFC 5245 seems
generic
> enough to cover any perceivable RTP keepalive procedure. Do you agree?
> 
> I think including "applicable to that RTP stream" should also cover the
case
> when BUNDLE is used, because then a single keepalive can "apply" to
multiple
> RTP streams. OK?
> > A colleague mentioned there might be an issue with regards to
> > heartbeats keeping NAT resources open, i.e. as per clause 10/RFC5245
> > when an RTP stream is paused. We probably need to add some text to the
> draft to indicate what happens when an RTP stream is paused. I take it
that
> normal media should be paused but that any RTP keepalive (e.g.

---

From: Bo Burman <[email-masked]>
Date: Wed, 10 Sep 2014 11:07:53 +0000

Agree, 6263 seems more applicable to this very RTP-specific scope, but 6263 says it is specifically not applicable to ICE clients, so maybe there's no harm in referencing both 6263 and 5245, since what keepalive method is used does not matter as long as it is not impacted by pause?

> From: Roni Even [mailto:[email-masked]]
> Sent: den 10 september 2014 11:03
> To: Bo Burman; 'Christian Groves'; [email-masked]
> Subject: RE: [avtext] RTP stream pause and keepalives
> 
> Hi Bo,
> > MUST be sent regardless of whether the media stream is currently
> > inactive, sendonly, recvonly, or sendrecv...", and even "...keepalives
> > MUST be sent
> even
> > [RFC5245] applicable to that RTP stream", as well as adding RFC 5245
> > as a normative reference. Is it correct to have it as a normative
> > reference,
> even if it

---

From: "Roni Even" <[email-masked]>
Date: Thu, 11 Sep 2014 01:04:01 +0300

Hi Bo,
Agree
Roni

> From: Bo Burman [mailto:[email-masked]]
> Sent: 10 September, 2014 2:08 PM
> To: Roni Even; 'Christian Groves'; [email-masked]
> Agree, 6263 seems more applicable to this very RTP-specific scope, but
6263
> says it is specifically not applicable to ICE clients, so maybe there's no
harm in
> referencing both 6263 and 5245, since what keepalive method is used does
not
> matter as long as it is not impacted by pause?
> 
> > > inactive, sendonly, recvonly, or sendrecv...", and even
> > > "...keepalives MUST be sent
> > even
> > > is not mandated by this draft to actually implement RFC 5245, but
> > > just referencing it in a normative statement?
> > >
> > > > heartbeats keeping NAT resources open, i.e. as per clause
> > > > 10/RFC5245 when an RTP stream is paused. We probably need to add
> > > > some text to the

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Sep 2014 09:27:13 +1000

Hello Bo,

Sounds good to me also.

Regards, Christian