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?

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