| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
> I can understand this position. However, wasn't RTCP thought
> of a means to communicate packet loss rates? If I put this
> in context with the IAB problem statement on congestion
> control, I doubt it is a good idea to just silently prevent
> RTCP from working.
Agreed: the question is do we do anything on the NAT, or do we
leave it strictlly to the application itself (e.g., in SDP-based protoctols
like SIP, use RFC 3605 plus STUN-type discovery for both RTP and
RTCP), or do also try to load the dice so the NAT will use consecutive
ports.
> Well, there are developers working on a SIP ALG for
> netfilter, and they asked us to include infrastructure for
> consecutive port number reservation into the netfilter NAT
> core. Our current position on this is
>
> 1) consecutive port numbers are a bad idea, somebody should LART the
> protocol designers
> 2) now that we are facing the problem, we have to come up with a
> solution (i.e. implement it).
>
> > I think that there is a very good chance based on past
> experience that
> > if NAT vendors use different algorithms for preserving consecutive
> > port numbers, we will end-up in trouble.
>
> We'd just chose any two (or even four in the case of A/V
> streams?) consecutive port numbers that are available. Just
> like we would chose any single available port number.
That works well with ALGs, but not so well with the non-ALG based
BEHAVE is addressing.
> > So I think that we need to discuss the issue in the document.
> >
> > Perhaps it's as simple as saying that we don't recommend
> putting hacks
> > in the NAT to address the issue because of reasons X, Y, Z.
>
> I would definitely like that. It saves us from those hacks
> in the code. However, it should then be considered to alter
> the RTP/RTCP specification to not require those consecutive
> port numbers in the first place.
>
> Either the protocol changes, or the NAT's will have to adress
> it. I don't see any way in between.
So I'm counting this as a vote for "don't attempt to do complicated
consecutive port preservation algorithms on the NAT"?
Is this correct?