Subject: RE: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Thu, 3 Jan 2008 16:36:41 +0100

Colin, thanks for you review.

We, authors, agree that it is better sending meaningful RTCP packet than dummy RTP packets. Your approach is OK, since endpoints can detect RTP-RTCP-mux support through the signalling.

We were asked to "pick one", so we did. But we can propose 2 that are clearly ordered and exclusive.
So if there is no objection in the WG, we will update the draft following your suggestion.

I don't know if it is enough to encourage massive migration to multiplexed RTCP but it may help.

Regards,
Aurelien

-----Message d'origine-----
De : Colin Perkins [mailto:[email-masked]] 
Envoyé : dimanche 30 décembre 2007 12:25
À : SOLLAUD Aurelien RD-TECH-LAN
Cc : MARJOU Xavier RD-CORE-LAN; AVT WG
Objet : Re: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01

Aurelien,

I'm very happy to see some concrete recommendations in this version of the draft, however I'm concerned that the final recommendation (to use RTP packets with unknown payload type as a keep alive mechanism) leads implementers in an undesirable direction.

The desired solution to keep alive the session is to send RTCP packets multiplexed on the RTP port. This is desirable because it reduces the number of ports used, and also because the keep alive packets provide some useful functionality, in addition to keeping middlebox bindings open. The issue, as your draft points out, is moving implementations to use multiplexed RTCP, since it must be signalled. To encourage this, I suggest the draft recommends implementations "SHOULD use multiplexed RTP and RTCP" as the main keep alive mechanism, explaining why its desirable to do so, but then recommends the use of RTP packets with unknown payload type number as a fallback if multiplexed RTCP cannot be negotiated.

Cheers,
Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 26 Jan 2008 08:48:26 +0100

I see a slight problem with the recommended method described in section 4.8
of this draft.

The text/t140 and text/red payloads described in RFC 4103 rely on inspecting
the RTP sequence numbers for detection and repair of loss. 
The sequence numbers roll on in one sequence for all payload types per RTP
stream.
Inserting other payload types in the same stream will disturb the loss
detection. 
It will not be possible to detect what payload type was lost.
This is noted in RFC 4103.

Therefore, the solution I see is to send the keep-alive RTP packets as a
separate stream within the same RTP session, thus using separate SSRC from
the main stream.

I suggest to add the following wording of section 4.8:
"The packet should also have an SSRC unique for the
 keep-alive traffic."

Resulting in the following:

-------------------------------------------------------------------

4.8.  RTP Packet with Unknown Payload Type

   The application sends an RTP packet of 0 length with a dynamic
   payload type that has not been negotiated by the peers (e.g. not
   negotiated within the SDP offer/answer, and thus not mapped to any
   media format). The packet should also have an SSRC unique for the
   keep-alive traffic.
---------------------------------------------------------------------- 

Regards
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

---

From: Randell Jesup <[email-masked]>
Date: Sat, 26 Jan 2008 09:37:17 -0500

Gunnar Hellström <[email-masked]> writes:
>The text/t140 and text/red payloads described in RFC 4103 rely on
>inspecting the RTP sequence numbers for detection and repair of loss.  The
>sequence numbers roll on in one sequence for all payload types per RTP
>stream.  Inserting other payload types in the same stream will disturb the
>loss detection.  It will not be possible to detect what payload type was
>lost.  This is noted in RFC 4103.

RFC 4103 appears to have an implicit assumption that the RTP stream is
unicast with only two participants.  There's no mention of 'unicast',
'multicast', multiple participants (modulo one sideways reference under the
congestion).  There's no mention of SSRC except in the format layout
diagrams.  Lack of consideration/discussion of these issues in the RFC is
part of the problem.  It does state that it expects related "multimedia"
streams to be in other RTP sessions.

I should note that because of how RFC 4103 is written and the redundancy
mechanism, it would be easy to define an RFC 4103-specific keepalive,
obviating the need to use this draft with it.  Or language could be
inserted in this draft specifying how to do it for RFC 4103.

>separate stream within the same RTP session, thus using separate SSRC from

Effectively this mimics another sender within the RTP stream, a case which
is never explicitly discussed in the RFC.  This *should* be handled in the
normal RFC 3550 manner, but I'm mildly concerned that given the implicit
assumptions above, some implementations may not have considered the
possibility of multiple senders.

However, there's not much that can be done in that case anyways.

>"The packet should also have an SSRC unique for the

This needs to be more explicit about how the SSRC is chosen and dealt with
(collisions), and how this interacts with RTCP.  (Should there be a sender
report?)  Receivers might not have considered receiving reports for
multiple senders; again there may not anything that can be done.

Or, as above, add an RFC 4103-specific machanism.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 26 Jan 2008 16:37:39 +0100

Randell,
Thanks for good comments.
You may be right that sending keep-alive with another SSRC may cause
unwanted effects in some receivers. But with an undefined PT as recommended
in the keepalive draft, I do not see higher risks than with sending it with
the same SSRC as another stream. 

About the requirement of text/red and text/t140 to be the only payload in
the stream, RFC 4103 says in section 5.3:
-----------------------------------------------------------------------
"The text/t140 format relies on use of the sequence number in the RTP
   packet header for detection of loss and, therefore, is not suitable
   for applications where it needs to be alternating with other payloads
   in the same RTP stream.  It would be complicated and unreliable to
   try to detect loss of data at the edges of the shifts between t140
   text and other stream contents.  Therefore, text/t140 is RECOMMENDED
   to be the only payload type in the RTP stream."
------------------------------------------------------------------
So, it is clear that the method proposed in 4.8 of the keepalive draft is
not directly suitable for RFC 4103. 

It would be good to define a method for RFC 4103 keepalive in the keepalive
draft.

Repetition of the latest transmitted RTP packet without modifying anything
could be another suitable method for RFC 4103 keepalive. Repeating also the
sequence number and time stamp, it will just be handled as a very late
duplicate and discarded by the receiver. Right?

About multi-party for RFC 4103. Yes, it is not explicitly defined in RFC
4103. Generla RTP methods can be applied.
But to be clear, multi-party session handling of RFC 4103 real-time text is
now described in 
http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-00.txt
 
I think SSRC collissions and allocating SSRCs etc is described sufficiently
in RTP RFC 3550, so I do not see a need for describing that more. Agree?

Thanks
Gunnar

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: Saturday, January 26, 2008 3:37 PM
To: Gunnar Hellström
Cc: 'MARJOU Xavier RD-CORE-LAN'; 'Colin Perkins'; 'AVT WG'
Subject: Re: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01

Gunnar Hellström <[email-masked]> writes:
>inspecting the RTP sequence numbers for detection and repair of loss.  
>The sequence numbers roll on in one sequence for all payload types per 
>RTP stream.  Inserting other payload types in the same stream will 
>disturb the loss detection.  It will not be possible to detect what 
>payload type was lost.  This is noted in RFC 4103.

I should note that because of how RFC 4103 is written and the redundancy
mechanism, it would be easy to define an RFC 4103-specific keepalive,
obviating the need to use this draft with it.  Or language could be inserted
in this draft specifying how to do it for RFC 4103.

>Therefore, the solution I see is to send the keep-alive RTP packets as 
>a separate stream within the same RTP session, thus using separate SSRC 
>from the main stream.

>"The packet should also have an SSRC unique for the  keep-alive 
>traffic."

This needs to be more explicit about how the SSRC is chosen and dealt with
(collisions), and how this interacts with RTCP.  (Should there be a sender
report?)  Receivers might not have considered receiving reports for multiple
senders; again there may not anything that can be done.

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team [email-masked] "The fetters imposed on liberty at home have ever been
forged out of the weapons provided for defence against real, pretended, or
imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

__________ NOD32 2824 (20080126) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

---

From: Colin Perkins <[email-masked]>
Date: Sat, 26 Jan 2008 16:22:49 +0000

On 26 Jan 2008, at 15:37, Gunnar Hellström wrote:
> -

Surely that depends on the implementation? I can envisage ways of  
building an RTP playout buffer that have no problem detecting loss  
when switching between payload type values, and also strategies that  
have trouble with it.

> It would be good to define a method for RFC 4103 keepalive in the  

It would be better to define a single keep-alive mechanism that works  
for all payload formats, and explicitly mark keep-alive mechanisms  
that only work for a subset of payload types as NOT RECOMMENDED.

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Sat, 26 Jan 2008 12:04:04 -0500

>the same SSRC as another stream. 

I'm not sure how to parse what you said.   I think you mean that the risk
of using different SSRCs is no worse than the risk of using non-negotiated
payload types.

I'm not sure I agree, though both have some risks.

>the stream, RFC 4103 says in section 5.3:

Right.

>It would be good to define a method for RFC 4103 keepalive in the keepalive

Probably so, since for 4103 it's easy to do in a payload-specific manner
and the other method won't work.  This can also avoid issues with
implementations that don't expect (and can't handle) multiple senders,
etc. 

>duplicate and discarded by the receiver. Right?

Yes, though I'd suggest for 4103 since it has a built-in ability to send
what are basically "no-change" packets, to simply use those.

>http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-00.txt

In practice I worry about if many/all implemetations handle "General RTP
methods", though of course they should.

>in RTP RFC 3550, so I do not see a need for describing that more. Agree?

Your statement (if it's kept) is still too short, and also the issues with
acting like you're two senders should be discussed (that's not a normal
thing to do within a stream).  As written, an implementer might think they
should generate a new random SSRC for each keep-alive packet, and might
never realize they need to send SR's or process RR's for the alternate
SSRC.  They also have to make sure the other side doesn't interpret this as
an SSRC-collision-induced shift of SSRC.

Overall, I'd lean towards a 4103-specific solution instead of adding the 
complexity of acting as a separate sender.

---

From: Randell Jesup <[email-masked]>
Date: Sat, 26 Jan 2008 12:35:15 -0500

Colin Perkins <[email-masked]> writes:
>Surely that depends on the implementation? I can envisage ways of  building
>an RTP playout buffer that have no problem detecting loss  when switching
>between payload type values, and also strategies that  have trouble with it.

Certainly, however RFC 4103 as written (and if implemented as written)
seems to be incompatible with the proposed mechanism in the draft (payload
switching). Unfortunate, but true I think.

>It would be better to define a single keep-alive mechanism that works  for
>all payload formats, and explicitly mark keep-alive mechanisms  that only
>work for a subset of payload types as NOT RECOMMENDED.

I think in this case, it may be better to not try to handle RFC 4103 with a
generic mechanism, especially when it's simple to define a mechanism within
the existing 4103 design.

If a single generic mechanism will work, great, but I think we may
complicate/hurt other users by trying to stretch it to cover 4103.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 26 Jan 2008 18:19:23 +0000

> Colin Perkins <[email-masked]> writes:
...
>> It would be better to define a single keep-alive mechanism that  
>> works for all payload formats, and explicitly mark keep-alive  
>> mechanisms  that only work for a subset of payload types as NOT  
>> RECOMMENDED.
>
> I think in this case, it may be better to not try to handle RFC  
> 4103 with a generic mechanism, especially when it's simple to  
> define a mechanism within the existing 4103 design.
>

I'd like to encourage either RTCP or STUN multiplexed on the RTP port  
as the preferred keep-alive mechanisms. I don't think there are any  
RFC 4103-specific issues with that.

-- 
Colin Perkins
http://csperkins.org/

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 27 Jan 2008 00:17:39 +0100

Colin,
Yes, I realize that the RTCP method is good, if the other party supports
RTCP multiplexing. And the STUN based method might work when you have ICE.

But all do not have RTCP multiplexing today. In order to maintain
compatibility with all current implementations we need to introduce a kind
of negotiation between these methods. 

Try to negotiate RTCP multiplexing. If it fails, then use an RFC 4103
specific method. 
A bit complex for a simple task, but maybe the way we should recommend.

Gunnar

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Saturday, January 26, 2008 7:19 PM
To: Randell Jesup
Cc: Gunnar Hellström; 'MARJOU Xavier RD-CORE-LAN'; 'AVT WG'
Subject: Re: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01

...
> 4103 with a generic mechanism, especially when it's simple to define a 
> mechanism within the existing 4103 design.
>

I'd like to encourage either RTCP or STUN multiplexed on the RTP port as the
preferred keep-alive mechanisms. I don't think there are any RFC
4103-specific issues with that.

-- 
Colin Perkins
http://csperkins.org/

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 26 Jan 2008 19:24:25 -0800

> From: Gunnar Hellström [mailto:[email-masked]] 
> Sent: Saturday, January 26, 2008 3:18 PM
> To: 'Colin Perkins'; 'Randell Jesup'
> Cc: 'MARJOU Xavier RD-CORE-LAN'; 'AVT WG'
> Subject: RE: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01
> 
> Colin,
> Yes, I realize that the RTCP method is good, if the other 
> party supports RTCP multiplexing. And the STUN based 
> method might work when you have ICE.

STUN packets fail the RTP validity check (Section A.2 of RFC3550)
so even if the remote peer did not indicate support for ICE,
sending the peer a STUN packet should not cause it any harm.  

-d

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 27 Jan 2008 08:45:49 +0100

So you mean that this quite strong recommendation about the STUN method from
the keepalive draft is not right and the STUN method could be wider used:

"   Recommendation:
   o  This method must only be used when negotiated between ICE agents,
      as specified in [5]." 

Should this recommendation be weakened in the draft?

So far we have sent the non-displayable text Unicode character BOM as
keepalive for RFC 4103. It has the slight drawback that loss of a series of
keep-alive transmissions can be falsely be detected as loss of text and
disturb the received text. But it has the clear advantage of being a real
valid RTP transmission that is carried well through all network components
including B2BUAs, SBCs, IP-PBX etc on the same route as the real payload.
Will all the other recommended solutions behave well through such network
components?

Gunnar    
-----Original Message-----
From: Dan Wing [mailto:[email-masked]]

> Yes, I realize that the RTCP method is good, if the other party 
> supports RTCP multiplexing. And the STUN based method might work when 
> you have ICE.

STUN packets fail the RTP validity check (Section A.2 of RFC3550) so even if
the remote peer did not indicate support for ICE, sending the peer a STUN
packet should not cause it any harm.  

-d

> compatibility with all current implementations we need to introduce a 
> kind of negotiation between these methods.
>

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 27 Jan 2008 08:59:08 -0800

> Sent: Saturday, January 26, 2008 11:46 PM
> To: 'Dan Wing'; 'Colin Perkins'; 'Randell Jesup'

Yes, that is my opinion, when the application lacks its
own keepalive mechanism.

> keepalive for RFC 4103.

There are other payload-specific keepalives which work well,
too -- for example, G.729 has its own silence packet.

But, if there isn't one at all, a STUN packet seems to cause
the least harm.  RTP packets with different SSRCs cause 
problems (as described by others); RTP packets re-sent (with
same sequence numbers and timestamps) look like duplicated
packets (because they are) and thus can be interpreted as
re-transmissions (for example, retransmissions caused by 
Ethernet collision detection).

> It has the slight drawback that loss 
> of a series of

For purposes of NAT, such end-to-end carrying of packets
is not needed, though.  

> Will all the other recommended solutions behave well through 
> such network components?

Keeping alive the remote application (the remote RTP
receiver), and, thus, keeping alive _all_ intermediate
nodes (SBCs, etc.), is a different but related problem.

If you want end-to-end keepalives, I agree that you
do not want STUN.

-d

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 27 Jan 2008 18:37:19 +0100

Dan,
Thanks.

I was mainly thinking of NAT keepalive, but going through e.g. an IP-PBX or
other RTP handling middlebox requires either an end-to-end keep-alive
mechanism, or that also the middlebox implements a keepalive mthod on its
RTP sessions.

Another issue:  draft-ietf-avt-app-rtp-keepalive-01 has a reference to
draft-ietf-avt-rtp-no-op. That draft has expired and disappeared from IETF,
so if that is the intention, it needs also to be deleted from the keepalive
draft.

Gunnar

> So you mean that this quite strong recommendation about the STUN 
> method from the keepalive draft is not right and the STUN method could 
> be wider used:
> 
> "   Recommendation:

Yes, that is my opinion, when the application lacks its own keepalive
mechanism.

> So far we have sent the non-displayable text Unicode character BOM as 

There are other payload-specific keepalives which work well, too -- for
example, G.729 has its own silence packet.

But, if there isn't one at all, a STUN packet seems to cause the least harm.
RTP packets with different SSRCs cause problems (as described by others);
RTP packets re-sent (with same sequence numbers and timestamps) look like
duplicated packets (because they are) and thus can be interpreted as
re-transmissions (for example, retransmissions caused by Ethernet collision
detection).

> keep-alive transmissions can be falsely be detected as loss of text 
> and disturb the received text. But it has the clear advantage of being 
> a real valid RTP transmission that is carried well through all network 
> components including B2BUAs, SBCs, IP-PBX etc on the same route as the 
> real payload.

For purposes of NAT, such end-to-end carrying of packets is not needed,
though.  

> Will all the other recommended solutions behave well through such 
> network components?

Keeping alive the remote application (the remote RTP receiver), and, thus,
keeping alive _all_ intermediate nodes (SBCs, etc.), is a different but
related problem.

If you want end-to-end keepalives, I agree that you do not want STUN.

-d

> the remote peer did not indicate support for ICE, sending the peer a 
> STUN packet should not cause it any harm.
> 
> -d
> 

__________ NOD32 2825 (20080127) Information __________

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 27 Jan 2008 10:45:44 -0800

> Sent: Sunday, January 27, 2008 9:37 AM
> mechanism, or that also the middlebox implements a keepalive 
> mthod on its RTP sessions.

I'm not sure of the architecture you are envisioning, but in
the architecture I envision, if a device did its own hole-punching 
through a NAT (that is, the device did UPnP, NAT-PMP, or ICE), 
then the device is also responsible for maintaining that hole 
through a NAT.  I believe that architecture is the scope of
draft-ietf-avt-app-rtp-keepalive; its Abstract says it is 
intended to apply to NAT keepalives.

However, if the device did not do the hole punching (rather, e.g.,
the hole in the NAT happened as a side effect, via an ALG, or by 
the actions or side-effects of an SBC), then it is not the 
device's responsibility to keep that pinhole open.  I agree 
that a quiescent RTP flow may fool such middle boxes (SBCs, 
ALGs, etc.) into thinking the RTP flow has ended and those
middle boxes might prematurely close the pinhole.

> so if that is the intention, it needs also to be deleted from 
> the keepalive draft.

There may well still be some value in RTP NoOp, for exactly 
the end-to-end situation you describe where STUN might not
survive through various RTP-aware devices (firewalls, RTP
translators) but RTP NoOp could survive through them.

Perhaps the app-rtp-keepalive needs to be slightly expanded
to discuss both NAT keepalives and end-to-end keepalives,
and make recommendations for both?

-d

> too -- for
> the least harm.
> receiver), and, thus,

---

From: Randell Jesup <[email-masked]>
Date: Wed, 30 Jan 2008 00:26:51 -0500

>Will all the other recommended solutions behave well through such network

Why aren't you sending an "Empty" T140Block?  Per the spec, you can send
those, and they're used to lead into "idle periods".  Idle periods are the
ones where you need to prop the port open; my suggestion (without reading
the whole 4103 spec) is to send empty blocks, and for keep-alive, wake up,
and send another empty block (with the M bit set I assume), then go idle
again.

5.2.  Transmission before and after "Idle Periods"

   When valid T.140 data has been sent and no new T.140 data is
   available for transmission after the selected buffering time, an
   empty T140block SHOULD be transmitted.  This situation is regarded as
   the beginning of an idle period.  The procedure is recommended in
   order to more rapidly detect potentially missing text before an idle
   period.

   An empty T140block contains no data.

   <more text for dealing with redundancy>

>packet should not cause it any harm.  

Generally yes.  My understanding is that the draft has several methods
because some of them can't work in certain situations (like a proxy in the
media path that would block the "bad" (STUN) packet).

---

From: <[email-masked]>
Date: Wed, 30 Jan 2008 09:43:45 +0100

> >keepalive for RFC 4103. It has the slight drawback that loss of a 
> >series of keep-alive transmissions can be falsely be 
> detected as loss 
> >of text and disturb the received text. But it has the clear 
> advantage 
> >of being a real valid RTP transmission that is carried well 
> through all 
> >network components including B2BUAs, SBCs, IP-PBX etc on the 
> same route as the real payload.
> Why aren't you sending an "Empty" T140Block?  Per the spec, 
> you can send those, and they're used to lead into "idle 
> periods".  Idle periods are the ones where you need to prop 
> the port open; my suggestion (without reading the whole 4103 
> spec) is to send empty blocks, and for keep-alive, wake up, 
> and send another empty block (with the M bit set I assume), 
> then go idle again.
> 

If this works, I like this solution.

We authors are going to revise the draft with the comments received since dec 18th, and we will add text about the RFC4103 issue. The idea is to see it as an exception and to propose a correct solution to it, but not to change the general recommendation (rtcp-mux if available; unknown payload type otherwise).

Aurélien

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 31 Jan 2008 00:13:34 +0100

Randell,
You ask: 'Why aren't you sending an "Empty" T140Block?'

It was mainly historical reasons. The first case when we realised that we
needed a keep-alive, we used a closed RFC 4103/RTP through an API where it
was not possible to provide zero length text to transmit. 

If we really want to be sure to send it through middleboxes to keep their
connections alive, it also should be a real ( non-printable) character. They
might just ignore to send emtpy blocks on.

Gunnar

-----Original Message-----
From: Randell Jesup [mailto:[email-masked]] 
Sent: Wednesday, January 30, 2008 6:27 AM
To: Gunnar Hellström
Cc: 'Dan Wing'; 'Colin Perkins'; 'MARJOU Xavier RD-CORE-LAN'; 'AVT WG'
Subject: Re: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01

Gunnar Hellström <[email-masked]> writes:

>So you mean that this quite strong recommendation about the STUN method 
>from the keepalive draft is not right and the STUN method could be wider
used:
>series of keep-alive transmissions can be falsely be detected as loss 
>of text and disturb the received text. But it has the clear advantage 
>of being a real valid RTP transmission that is carried well through all 
>network components including B2BUAs, SBCs, IP-PBX etc on the same route as
the real payload.

>STUN packets fail the RTP validity check (Section A.2 of RFC3550) so 
>even if the remote peer did not indicate support for ICE, sending the 
>peer a STUN packet should not cause it any harm.

__________ NOD32 2831 (20080129) Information __________

---

From: Randell Jesup <[email-masked]>
Date: Wed, 30 Jan 2008 18:25:32 -0500

>might just ignore to send emtpy blocks on.

They shouldn't, unless they're a real back-to-back agent that re-encodes
media - in which case, they're responsible for detecting and handling
'idle' on the far side.

Suppressing "empty" blocks will break the T140/RFC-4103 redundancy
mechanism, so I really doubt anyone is doing it.

The case you're worrying about is "I have an RFC 4103 stream that I can't
modify, but I need to layer keep-alive on top of it".  A valid case, but
not the case I provided an answer for, and in this case I'd say you had
poor RFC 4103 implementation, since "empty" 4103 blocks are explicitly
used/supported by the spec for handling idle.  (By the way, your case
wouldn't have been solvable with "inserted" non-negotiated-payload packets
anyways, since you weren't controlling the RTP layer, from what you say.)

For your case (opaque 4103 stream, or any stream of RTP packets already
sequenced, etc), I'd say use one of the "external" mechanisms (like
overlaid STUN or RTCP packets, etc), and live with the fact they don't
handle all midbox situations and aren't end-to-end.  When this can be
combined with the application, for 4103 I'd advise to use empty T140 blocks
and the 'Idle' mechanism.