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

> -----Original Message-----
> From: Gunnar Hellström [mailto:gunnar.hellstrom@omnitor.se] 
> Sent: Saturday, January 26, 2008 11:46 PM
> To: 'Dan Wing'; 'Colin Perkins'; 'Randell Jesup'
> Cc: 'MARJOU Xavier RD-CORE-LAN'; 'AVT WG'
> Subject: RE: [AVT] RE: draft-ietf-avt-app-rtp-keepalive-01
> 
> 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?

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

> Gunnar    
> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> 
> > From: Gunnar Hellström [mailto:gunnar.hellstrom@omnitor.se]
> > 
> > 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
> 
> > 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
> > -------------------------------------------------------------------
> > Gunnar Hellström
> > Omnitor
> > gunnar.hellstrom@omnitor.se
> > Tel: +46708204288
> > www.omnitor.se
> > 
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp@csperkins.org]
> > 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
> > 
> > On 26 Jan 2008, at 17:35, Randell Jesup wrote:
> > > Colin Perkins <csp@csperkins.org> 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.
> > >
> > > 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.
> > 
> > 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/
> > 
> 

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