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

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

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

__________ NOD32 2825 (20080127) 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