Hi Ali,
When reading through the draft http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01 , including your editor comments, I understand that despite the cookie exchange solution, it does not allow to have a "stateless" server (that is, the server needs to remember the ports). You indeed correctly pointed out that RTCP SR messages are unsollicited, so they cannot be linked to a received cookie. I do not think it makes sense to "forbid" the server (RS in the considered use cases) to send RTCP SR at any moment in time. Hence, as the RS needs to remember anyhow the ports and thus must keep state, the cookie would no longer be needed from that perspective. Is that an appropriate conclusion? Port mapping response message (exchange) is then no longer needed anymore, although I understand this message is also a kind of confirmation of reception of the port mapping request message.
You also mention that NAT tolerance is a design criterium. How was that taken into account in the proposed messaging flow?
The NAT friendly solution IMO is that the port mapping request messages for RTP and RTCP is sent along with a RAMS-R FB by the RR to the RS whereas a port mapping request for RTP is sent along with a NACK FB by the RR to the RS. This is not to inform the RS of the ports it should use each time -as it needs to remember that anyhow and keep state based on the 1st received port maping request by the RR- but to open the NAPT in between. The disadvantage is of course the higher messaging load for the RS (and RR).
I realise the draft wants to provide an answer on how an RR can indicate the UDP ports it wishes to use for RTP unicast sessions without any session-signaling protocol involved, but I do not think all design criteria can be met. I think we can drop the cookie, and just keep the port mapping response/request message (without cookie), meaning the RS needs to keep state of the port allocated to each RR based on acknowledged port mapping request messages, and when receiving RTCP Byes in the retransmission session, it can drop the "state".
In my opinion, the ideal solution is still that we can make the P2 and P3 ports on the RS equal, where a single message (RAMS-R or NACK) by an RR will allow the response (RTP burst or RTP retransmission packet) to pass through NAT, provided the RR supports the RTP/RTCP port muxing. I realise this would require the RS to use an SSRC in the unicast retransmission session that is different from the one used in the primary SSM session- allowing the RS to distinguish RTCP messages based on the media SSRC in the RTCP messages. However, using a different SSRC when retransmission session muxing is used, is forbidden by RFC 4588. But there is no justification in RFC 4588 why this was disallowed, and further inquiries have made me believe that there is really no hard reason why this constraint was imposed.
As you know, in the DVB retransmission solution for linear TV (hence SSM sessions), it is allowed to use a different SSRC even though session muxing is used (as the UNICAST retransmission session is associated with a SSM session), "overruling" RFC 4588 on that aspect. This then allows making P2=P3, with no ambiguities for the RS in resolving which incoming RTCP message belongs to which session (either the unicast retransmission session or the unicast feedback channel of the SSM session). This solution requires no port signaling at all and is NAT friendly.
Regards
Tom