Re: [AVT] Port mappings, NAT, and RAMS

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Tom,

[snip]
> The reason why we need pubports is that it indicates "explicitly" the
> port the client wants to use to receive the burst is the port it used to
> send the RAMS-R/pubports message. I believe we need this explicit
> indication, ow, we will be making an implicit assumption. Note that the
> rams-r/pubports is in the primary session and burst/ret packets are in
> the retransmission session, which is different than the primary.
> 
> As far as I can see, not everybody agrees on this point, but we need to
> make a decision here before we mandate anything.
> 
> TOM: I agree with your last line, but I do not completely agree when you
> mention "implicit" assumption, especially for option 3, where RAMS-R (or
> NACK) and the Pub-port message are in the same compound message. If we
> "define" that if no pub-report message is sent by the RR, the
> information towards the Retransmission server is exactly the same as
> when an RTP receiver sends an RTCP compound message made up of an RTCP
> NACK/RAMS-R together with a pub-port message where the ports are "zero"

We "may" be able to say it from RAMS-R but not for NACK since we are not defining it, we will be overloading its meaning, IMO. And as you/Bill pointed out in other emails, I also believe that this is more general problem than just RAMS. We need something like pubports for NACKs as well.


> -as currently proposed in the RAMS draft now.  I agree that this is not
> true for option 4, where pub-port and RAMS-R or NACK are separate
> messages, but I do not favour the solution of option 4 for the same
> reason you mention in your reply (a new failure mode). So, if option 4
> is -for that reason- no longer considered, I do not see a problem with
> defining this rule/clause as expressed above. In other words, there is
> no need for a pub-report message in this scenario and this results NOT
> in an "assumption" what-so-ever.
> 
> 
> > supports RTP/RTCP muxing itself, and if it knows the RS supports
> > RTP/RTCP muxing too (as indicated in the declarative sdp received by
> > the
> > RR)
> >
> > -Don't we also allow that for option 3, the port P2 actually equals
> > port P4? This is a kind of hybrid of session and SSRC multiplexing of
> > the primary multicast RTP stream and the retransmission/acceleration
> > session
> > :  on the unidirectional RTP layer, the primary MC packets and the
> > unicast retransmission packets are clearly session muxed, but the RTCP
> 
> > "return" channel for both streams have exactly the same transport
> > addresses, but are distinguished by means of a different SSRC.  In
> > that
> 
> How? Since SSM and retransmission sessions are session muxed, they have
> the same SSRC. When a client is sending a receiver report, how do we
> identify which session it belongs to? So, I believe P2 should be
> different than P4.
> 
> TOM: you are right. But notice this: RFC 4588 mandates that when session
> muxing is used for retransmission, than the SSRC should be the same.
> However the RFC 4588 does not give arguments why it needs to be like
> that. So I ask you: what would or can happen if there is a different
> SSRC used?  If there are no convincing arguments why we must stick to

Good question. If we don't use the same SSRC in session-muxed RTP sessions, it will introduce correlation problems. Receiver/XR reports coming from a larger number of receivers will be difficult to identify and match at the server side. There will be SSRC collisions, which will complicate things further.

> the same SSRC, then, if we have a good use case to depart from that
> "rule" -and the use case we are discussing here is IMO indeed a valid
> use case- I do not see why we should be limited by such a "rule". The
> "valid" use case is here that RAMS and Retransmission for SSM sessions
> operates fine through any NAPT and without any dedicated RTCP message.

-acbegen