Subject: Re: [AVT] Session establishment in draft-ietf-avt-ports-for-ucast-mcast-rtp-01

From: Roni Even <[email-masked]>
Date: Tue, 04 May 2010 09:57:04 +0300

Hi,

?
> 
> > In the figure 3, the session between burst/retransmission source
> entity
> > of the RS and the RTP receiver is established after the NACK (or
> RAMS-R,
> > or whatever future app message that will be defined), ....but is the
> > session not established when the port mapping request is sent out
> first?
> > It uses the same transport addresses.
> 
> I believe the session is established upon receiving a nack, rams-r,
> etc. since the server will not allocate resources before it receives
> such messages. The previous one is just a cookie request. And at that
> time, it is not clear when the client will actually use it or not.
> 

The solution as written now, in my understanding, is for UDP and maybe we
should mention it. TCP will probably require a connection establishment from
the RTP receiver to the RS and if we want to address it we need to add text
and reference RFC 4145.
For the UDP case I think that once the RTP receiver sends the PMReq (maybe
after receiving the PMRreq) the UDP port is open and kept alive and media
can flow in.

Roni Even
As individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 5 May 2010 10:28:00 -0700

> the RTP receiver to the RS and if we want to address it we need to add text

Yes, the intro I believe says this is for UDP. I will make sure this is clear. IMO, we should not get involved with TCP in this draft since it has other requirements and RFC 4145 probably addresses them well.

> after receiving the PMRreq) the UDP port is open and kept alive and media

Hoping that the cookie request message will make it, the client will receive a cookie. For that cookie to work, the binding needs to stay valid. So, I guess this means after sending the request, the client has to keep the binding open until it decides not to use that cookie any more.

In a negative answer is received from the server (request is not accepted, no cookies, etc.), then there is no need for the keep-alives of course.

-acbegen