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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Gunnar Hellström [mailto:[e-mail]] 
> Sent: Sunday, January 27, 2008 9:37 AM
> 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
> 
> 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.

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.

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

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


> Gunnar
> 
> From: Dan Wing [mailto:[e-mail]] 
> > 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:[e-mail]]
> > 
> > > From: Gunnar Hellström [mailto:[e-mail]]
> > > 
> > > 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
> > > [e-mail]
> > > Tel: [phone]
> > > www.omnitor.se
> > > 
> > > -----Original Message-----
> > > From: Colin Perkins [mailto:[e-mail]]
> > > 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 <[e-mail]> 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
> [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt