Re: [Ietf-behave] [AVT] RTCP SSRC collision and draft-ietf-behave-nat-multicast
Magnus,
I am unclear why we need to address this topic at all. I don't
understand why we need to support a napt for multicast. I'd like to
understand this basic requirement.
Mark
On Oct 4, 2006, at 2:25 AM, Magnus Westerlund wrote:
Hi,
During the IETF last call for "Multicast Requirements for a Network
Address Port Translator (NAPT)" (draft-ietf-behave-multicast-03)
some issues have come up. They all evolve about the binding that a
NAT needs to create when a host on the inside of the NAT sends
traffic either to the multicast group or to a feedback receiver in
SSM (such as in draft-ietf-avt-rtcpssm). One issue that exist here
is in relation to RTP and its collision detection mechanism.
draft-ietf-behave-nat-udp does specify that outgoing UDP NAT
binding shall be kept alive for at least 2 minutes. However for a
certain amount of participants and a given RTCP bit-rate the RTCP
reporting interval will become longer than the minimum binding
lifetime. In those cases there is the risk that each message sent
will have a different source IP address and UDP port tuple. That
can trigger the RTP collision detection mechanism as described in
section 8.2 of RFC 3550.
To avoid these issue in most cases when transmitting to ASM
multicast groups we propose that NAT will keep bindings for 1 hour.
To clarify that means no change to the bindings going to unicast
addresses, only packets that has a multicast group as destination
address. The collision issue may now occur for sessions that has
average RTCP reporting interval that is longer than 40 minutes
instead of 80 seconds. We understand that this will not resolve the
issue for sessions that would like to run in this configuration.
For SSM sessions it would be best if the feedback receiver and
media receivers primarily looks at the CNAME for determining SSRC
collision and not network addresses. This seems necessary anyway
for the media receivers in simple feedback mode as all RTCP packets
will seem to come from the distribution source, thus address
checking is useless. Collisions can only be found by checking the
CNAME. In fact I think this is something that is required to be
clarified in draft-ietf-avt-rtcpssm or otherwise all receivers will
constantly detect collisions with there own RTCP packets.
In the RTCP SSM summary mode the situation is somewhat different.
For the feedback target, the address would be useful for
determining that RTCP packet arrives from different sources.
However in the presence of NATs this becomes a source of error. I
wrote primarily look at CNAME in the previous paragraph. The reason
for this is the remaining issue of loop detection. If one
completely skips using the source address one will can't determine
if some packets constantly comes back from another address and
actually should be blocked for that reason. Here I don't have any
brilliant ideas on how to resolve this issue.
Please comment on the proposal
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
_______________________________________________
Audio/Video Transport Working Group
avt@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/avt
