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

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:rjesup@wgate.com] 
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 <gunnar.hellstrom@omnitor.se> 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:
>
>"   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?

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>

>From: Dan Wing [mailto:dwing@cisco.com]
>
>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.

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

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS
team rjesup@wgate.com "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 2831 (20080129) Information __________

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt