Re: [AVT] Open issues in the PortMapping draft

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Hi Ali,

Some comments :
-related to your question 5: it makes more sense to include in the portmapping response message a response field that could be used to contain error codes similar as was defined for RAMS-I. I do not think you can impose timing requirements to an RS when responding to a port mapping response, other than the usual RTP AVPF timing rules.
-I would favour to keep "port mapping response" message as a name, whereas  a new message is defined, entitled e.g. "port mapping cookie" , to transfer the cookie along with a RAMS-R or NACK.  The only difference may be the response field presence, but it makes it easier to present this solution.
-If the port mapping request is sent several times by the RTP receiver (redundancy reasons), how should the RS react? You should also state that the random number inside the port mapping request must then be kept the same.
 
Then a comment with the risk of being criticised as counter-productive.;-)

I notice that you know stipulate that the SSRC name in SDES message accompanying RTCP messages in the primary RTP ssm session and accompanying the RTCP messages in the unicast RTP retransmission sessions must be used by the RS to associate them together. For this reason you also submitted the draft-begen-avt-rtp-cnames, an effort I applaude!

But... The reason why the simpler non-cookie solution I proposed  to enable the port mapping, was turned down in Anaheim was exactly because the association of the RTCP messages in the two sessions had to be done via C-NAME, but as it could not be guaranteed that C-NAMES were unique, the solution could not be guaranteed to work well in all cases.

Because the cookie-based solution clearly has some disadvantages compared to not using cookies (additional RTT impacting channel change time, server that needs to generate cookies, need for a keep-alive mechanism and additional security threats like stealing cookies etc ) I wonder what the remaining rationale is for not defining the non-cookie approach in IETF for RAMS and retransmissions.

Regards
Tom




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ali C. Begen (abegen)
Sent: woensdag 19 mei 2010 15:57
To: IETF AVT WG
Subject: Re: [AVT] Open issues in the PortMapping draft

Here is the new version (addressing the earlier comments raised in the list):
https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avt-ports-for-ucast-mcast-rtp-02

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> Ali C. Begen (abegen)
> Sent: Tuesday, May 18, 2010 5:27 PM
> To: IETF AVT WG
> Subject: [AVT] Open issues in the PortMapping draft
> 
> All,
> 
> Here is a list of open issues. We need your input to figure out the 
> best way to address them. A revision is shortly coming up, and we will 
> make frequent updates as necessary to make progress as fast as we can before the July meeting.
> 
> http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp
> 
> 1- Message formats: There are a few reasons why the 4585 feedback 
> message format is not particularly a good fit for requesting a 
> PortMapping (PM) or responding to a PM request or including the Cookie 
> in subsequent RTCP packets. One such reason is that the media sender SSRC field is not well defined in those messages.
> 
> We had similar concerns in the RAMS draft, yet we still used the 4585 
> format. Any objections if we do the same for this draft? If not, I 
> suggest the client uses its own SSRC in both SSRC fields and the 
> server does not change those values in its responses. That is, in both PM request and response messages, packet sender ssrc <- media sender ssrc <- client's SSRC.
> 
> 2- Sub-message-type fields: Should we rather register one FMT value 
> but multiple sub-FMT values for the PM request and response messages? Do you think we may need further message types in the future?
> 
> 3- Client's CNAME/SSRC choices: The RTCP ports on the server (p3 and 
> p4) MUST be different and the client MUST use the same SSRC and CNAME 
> in the multicast and unicast sessions (to be consistent with session 
> multiplexing as explained in the RAMS draft and 4588). This way, 
> reports sent to ports p3 and
> p4 can be still linked together.
> 
> Any objections?
> 
> 4- Keeping the NATs alive: Are RTCP receiver/extended reports enough 
> to keep the bindings alive? Or, should we choose an option from 
> I-D.ietf-avt-app-rtp-keepalive? Note that the client will have to keep 
> the bindings open until a session is established and data flow starts. So, in addition to RTCP reports, we will most likely need something else as well.
> 
> 5- Server's response to PM request messages: Does it have to be right 
> away? If the request is rejected, could the server send a PM response message with an empty Cookie field?
> 
> Comments, thoughts are welcome.
> -acbegen
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt