Subject: Re: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2010 19:33:08 +0100

Ali C. Begen (abegen) skrev 2010-03-01 04:18:
>> Ali C. Begen (abegen) skrev 2010-03-01 02:37:
>>>
>>>> 6. Section 3: I am missing a firewall goal. Here one needs to be clear
>>>
>>> Would you specify the firewall goal you have in mind? We will be glad to add it.
> 
> Forget to mention something here?
>  

I was thinking about providing some text, but run out of time. But here
is an attempt:

Basic Firewall traversal: A common basic rule in stateful firewalls are
block all incoming traffic unless the client on the internal side of the
firewall sends traffic of the same transport protocol to the external
side first. This type of filtering needs to be taken into account.

>>>
>>>> that firewall might be setup to prevent these flows as at all which
>>>> shouldn't be circumvented. However, for simple firewalls rules that
>>>> block incomming traffic flows but not bi-directional flows that has been
>>>> initiated from the inside. In regards to the NAT cases where port and
>>>> address translation is happening this provides different requirements.
>>>> Although a solution that handles NAPT will most likely solve this use
>>>> case also. But firewalls will continue to exist also in IPv6 networks
>>>> even if NAPTs are not present anymore.
>>>>
>>>> 7. Figure 2:
>>>>
>>>> a. The port identifier P2 is used twice in different contexts.
>>>
>>> That is intentional, which port could we use else?
>>
>> Well, the P2 on the left side is the RTCP port in the multicast address.
>> While P2 on the right side of the RS is the feedback target address for
>> RTCP. They are clearly two different addresses even if they are related.
>> Thus unless your prefix them I find it confusing.
> 
> But at the end they are the same port. 
> 
> The 'a=rtcp:41001 IN IP4 192.0.2.1' line in the SDP specifies the RTCP port of the feedback target. That is also the port where RTCP of the primary session is multicast to.
>   

No, according to RFC 5760 ( yes it is finally published) the SSM RTCP
port is derived from the m= line and the a=rtcp specifies the feedback
target:

Section 10.2 says:

   There SHOULD be exactly one "a=source-filter:incl" attribute listing
   the address of the Distribution Source.  The RTCP port MUST be
   derived from the m= line of the media description.

   An alternative Feedback Target Address and port MAY be supplied using
   the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4 192.0.2.1.
   This attribute only defines the transport address of the Feedback
   Target and does not affect the SSM group specification for media
   stream reception.

I think it is important to notice that they are two separate flows and
do not need to use the same port.

>>>> 13. Section 4.2.1, step 6: I personally think sending the answers to the
>>>> RTP portmapping response back in the RTCP return channel is a bad idea.
>>>> This as it doesn't test the return routability of that specific port. It
>>>> is important that the reverse path is checked for each port. Now you can
>>>> have the RTCP RS to client path work but not the RTP one. If you send
>>>> response symmetrically then the client will know that the path works
>>>> prior to sending a retransmission request.
>>>
>>> What does "sending response symmetrically" mean here? I wanna make sure I understand it right.
>>
>> That the RTCP port mapping response is sent with a destination address
>> and port that is equal to the source address and port of the request and
>> with a source address and port that is equal to the destination address
>> and port of the request. What I understand of the current solution the
>> response to the RTP port request is sent back over the RTCP port. Thus
>> never testing the return path from the RTP port.
> 
> Right, but that is the only way if client is not port muxing. If it is port muxing, this won't be an issue.
>  

Lets come to consensus if MUX is mandatory or not. If not this needs
more discussion.

>  
>>>
>>>
>>>> 15. Section 4.2.1, step 9: What about keep alive for the RS to client
>>>> RTP flow to c2? To keep that flow open the client will need to send
>>>> occational traffic from client to RS.
>>>
>>> Yes. In any approach, both ports need to be kept alive.
>>
>> I forgot to ask which mechanism you forsee using here, RTCP port mapping
>> requests or something else?
> 
> There is a draft for rtp keepalive. 
> http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-07.html 
> 
> we should probably pick the best one and mandate it?
> 

One could also use the port mapping request as keep alive message. That
has advantage from the perspective of detecting mapping failures.
However it clearly will have undesired high load on the server as it
would need to create a new cookie for each request.

If we are using RTP/RTCP Mux then RTCP is clearly the best choice. If
not then I think the picture is significantly more complex.

>>>
>>>> 17. Section 4.2.2: If there are no NAT devices between the server and
>>>> client, the client
>>>>    MUST acquire a cookie for each distinct 2-tuple of (S, c2) and (S,
>>>>    c3).
>>>>
>>>> I think this should be the 5-tuple. It is important that the same local
>>>> address is used and also the same server port and over the right
>>>> protocol. Hosts with weak addressing models could get in to trouble here.
>>>
>>> I am fine with protocol, but including local server ports may not be a good idea. It limits the
>> usability of the cookie, meaning that in RAMS context for example, the client will have to acquire a
>> different cookie for every FT running on the same server (which could be 100s or 1000s). Oppositely,
>> if the same cookie can be used for every FT, this greatly reduces the cookie-acquisition delay or RAMS
>> delay.
>>
>> I think this is something that will need to be discussed. However,
>> different RTP unicast target address + port on the RS will require
>> different port mapping requests. Then there is a question if you can
> 
> Only if you use a 2/3-tuple instead of 4/5-tuple.

No, that doesn't work Ali. Both address mapping behavior and filtering
will prevent one from reusing a clients address as seen from the server
read on one port to be reused on another port on the RS. You will need
to do port mappings over each address port pair.

>>>
>>>> 18. Section 4.2.2, second paragraph. As the NATs behavior may be varying
>>>> over time, relying on a NAT to keep being endpoint independent mapping
>>>> is not recommended at all. There is also the filtering rules of the
>>>> firewall that commonly are endpoint dependent. Thus designing for the
>>>> strictest case is the simplest and requires least amount issues.
>>>
>>> I agree but if there are certain optimization a client can do, why not benefit from them? We can be
>> conservative and assume the worst, or we can be optimistic and switch to the worst case if better
>> alternatives do not work.
>>
>> The first part is that it creates implementation complexities that
>> likely are not motivated.
>>
>> When you take the filtering behavior and the DoS angle into account and
>> you anyway need to send client to server traffic and have a server to
>> client verification path then I don't see any gain, only complexities.
> 
> I guess I agree.
>   
>>>
>>>> RAMS burst request to generate a large amount of traffic towards its
>>>> intended target. In other word this is a nice little DoS attack tool
>>>> that only is mitigated by source address filtering. Something that isn't
>>>> deployed for more than a quarter of the total used unicast addresses.
>>>>
>>>> This is mitigated in the server side cookie mechanism by the having the
>>>> server side cookie be hashed using a server secret key. The client
>>>> requesting RAMS service needs to get the response from the server with
>>>> this cookie and include it in its RAMS burst request. The only weakness
>>>
>>> Right.
>>>
>>>> in this method is the timing aspects. That is why I think the server
>>>> needs to include a timestamp and only allow cookies that aren't to old.
>>>
>>> Why can't a client use a cookie it acquired say 24 hours ago? Why would the cookie expire? The
>> client should be able to use it as long as its public address/ports have not changed.
>>
>> And how does the server or the client know that the external address of
>> the client hasn't changed? A NAT with multiple hosts inside it can
>> clearly have the issue that one binding times out and is replaced by a
>> binding own by another host. Thus the cookie shouldn't be valid for much
>> longer than what can be expected that the binding is valid. There is a
> 
> The client might keep such bindings alive.
> 

Yes. this was to have people think about it. I do think if we specify
things well enough that you can do the port mapping just ahead of the
need to use it and then keep it alive. Then a recommended procedure how
to handle apparent failures.

>> trade off here, between the load for generating new cookies and updating
>> the unicast session binding with new cookies. I think that will need
>> some analysis.
> 
> Fair enough.
>  
>> The second angle is the replay attack you can do if the cookie doesn't
>> expire. If you at some point manage to snoop the cookie from a
>> transaction between the target and an RS, then an attacker could resuse
>> that cookie for periodic new rams request to a client that is no longer
>> interested in rams requests.
>>
>> These are the two reasons I see that the cookie should expire. I think a
>> lifetime of no more than 60 min seems appropriate here. Although this is
>> just my initial guess.
> 
> Coming up with a magical number is difficult here. We either allow the cookies to be used as long as the bindings are still valid, or require the client to acquire a new port mapping cookie every time there is a need (very short-duration cookies). I am inclined towards the former.
> 

As you will likely need one mapping per RTP session, i.e. at least one
per TV channel in IPTV. I think having short lived and just get them
when you need them might be the one that has least load.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 1 Mar 2010 10:54:22 -0800

Hi Magnus,

>    derived from the m= line of the media description.

Hmm, is it RTP port + 1? I thought that behavior was obsoleted.
 
> do not need to use the same port.

Based on the text you provide above, we better update the figure. But,
let me know how one must derive the rtcp port from the m line.
 
Remaining issues are important and we should discuss them in the
breakout session.

Cheers, acbegen

---

From: "Allison, Art" <[email-masked]>
Date: Mon, 1 Mar 2010 14:18:41 -0500

WRT the Port +1 being obsolete, deprecated, old fashioned or whatever; I
know ATSC's A/153 mandates explicit even/odd adjacent port assignments
for RTP and RTCP.

So, perhaps language such as ".... devices that use port multiplexing
shall .... and if so then...."
is preferable?

Or remain silent on the explicit port mapping schemes to perhaps
mitigate some confusion by an uninformed reader sometime in the future.

Art Allison

Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981

www.nab.org

Advocacy  Education  Innovation

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Ali C. Begen (abegen)
|Sent: Monday, March 01, 2010 1:54 PM
|To: Magnus Westerlund
|Cc: IETF AVT WG
|Subject: Re: [AVT] My comments on 
|draft-ietf-avt-ports-for-ucast-mcast-rtp-00
|
|Hi Magnus,
|
|> No, according to RFC 5760 ( yes it is finally published) the 
|SSM RTCP 
|> port is derived from the m= line and the a=rtcp specifies 
|the feedback
|> target:
|> 
|> Section 10.2 says:
|> 
|>    There SHOULD be exactly one "a=source-filter:incl" attribute
|listing
|>    the address of the Distribution Source.  The RTCP port MUST be
|>    derived from the m= line of the media description.
|
|Hmm, is it RTP port + 1? I thought that behavior was obsoleted.
| 
|>    An alternative Feedback Target Address and port MAY be supplied
|using
|>    the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4 192.0.2.1.
|>    This attribute only defines the transport address of the Feedback
|>    Target and does not affect the SSM group specification for media
|>    stream reception.
|> 
|> I think it is important to notice that they are two separate 
|flows and 
|> do not need to use the same port.
|
|Based on the text you provide above, we better update the 
|figure. But, let me know how one must derive the rtcp port 
|from the m line.
| 
|Remaining issues are important and we should discuss them in 
|the breakout session.
|
|Cheers, acbegen
|
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2010 20:47:42 +0100

> Remaining issues are important and we should discuss them in the

The +1 rule works fine for multicast. There are no issues there as the
port range is on a per multicast address scope. Thus getting the +1 port
is not difficult. While it definitely is difficult for unicast and where
the deprecation of that rule makes all the sense.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 1 Mar 2010 12:43:59 -0800

Could the authors of rfc 5760 explain how one must derive the rtcp port from the m line (Section 10.2)? Is the rtcp port always equal to rtp port + 1? If so, I wonder why this was not explicitly mentioned in the text. Any input would be appreciated.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, March 01, 2010 2:48 PM
> To: [email-masked]
> Subject: Re: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Mon, 1 Mar 2010 16:55:33 -0500

On Mar 1, 2010, at 2:47 PM, Magnus Westerlund wrote:

> The +1 rule works fine for multicast.
It may but I really dislike things that work differently for unicast and multicast for no good reason. Not to mention all the broken middlebox stuff that locked onto this convention and made the whole system for RTP brittle. Things like rewriting DSCPs based on assumed port ranges and shit.

DaveO.

> There are no issues there as the

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2010 23:35:46 +0100

> It may but I really dislike things that work differently for unicast and multicast for no good reason. Not to mention all the broken middlebox stuff that locked onto this convention and made the wh…

I think explicit signaling had been best here. However, requiring the
same port number between the feedback target address and the multicast
seems to only provide unnecessary restriction.

Do you see any simple solution for how to be explicit here? Two a=rtcp
lines, one with a ip address and the other without?

Cheers

Magnus Westerlund

---

From: David R Oran <[email-masked]>
Date: Tue, 2 Mar 2010 10:32:24 -0500

> seems to only provide unnecessary restriction.
Well, until now it's been a degree of freedom we didn't seem to need, so I can see why RTCPSSM didn't address this. Given our use cases for RAMS it does seem prudent to allow the FBT RTCP port to be different from the Multicast RTCP port.

> lines, one with a ip address and the other without?
I *think* that would work but I'm not confident enough to say for sure.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 3 Mar 2010 09:40:55 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Oran (oran)
> Sent: Tuesday, March 02, 2010 10:32 AM
> To: Magnus Westerlund
> Cc: [email-masked]
> >> It may but I really dislike things that work differently for unicast and multicast for no good
> reason. Not to mention all the broken middlebox stuff that locked onto this convention and made the
> whole system for RTP brittle. Things like rewriting DSCPs based on assumed port ranges and shit.
> >
> Well, until now it's been a degree of freedom we didn't seem to need, so I can see why RTCPSSM didn't
> address this. Given our use cases for RAMS it does seem prudent to allow the FBT RTCP port to be
> different from the Multicast RTCP port.
> 

I checked RFC 3605 again and did not find anything that restricted using two or more a=rtcp lines for the same media description.

However, if there are two a=rtcp lines for an SSM media description, it might not be possible to infer which port is for the multicast rtcp and which is for the FT rtcp when the FT resides on the distribution source.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Mar 2010 09:09:32 -0800

> However, if there are two a=rtcp lines for an SSM media description, it might not be possible to infer which port is for the multicast rtcp and which is for the FT rtcp when the FT resides on the d…

But the FT address will have a unicast address as part of the line and
the other will only be a port. So I think it is possible to define that
clearly in this context. I have to say that I am a bit worried for more
esoteric cases, like if one started using a multicast address as the
feedback target.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 4 Mar 2010 09:17:00 -0800

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, March 04, 2010 12:10 PM
> To: Ali C. Begen (abegen)
> Cc: Dave Oran (oran); [email-masked]
> > However, if there are two a=rtcp lines for an SSM media description, it might not be possible to
> infer which port is for the multicast rtcp and which is for the FT rtcp when the FT resides on the
> distribution source.
> >
> 

>From what I understand the rtcp ssm spec allows to specify only the port for the FT as well if FT is running on the same box with the source (i.e., the unicast address for FT does not look like a "must") since the address of the source is already specified in the a=source-filter line.

Then, we will have two lines with the port information only. No?

-acbegen

---

From: Joerg Ott <[email-masked]>
Date: Thu, 11 Mar 2010 16:58:13 +0200

Yes, 5760 follows basic RTP and hence the port+1 rule is assumed
to be applied.  From a practical perspective, this is did not
appear to be an issue for multicasting.  AFAIR, this was never
raised before unicast RTP became popular.

RFC3605 was designed for unicast communications in cases in which you
NATed; in those cases, you will need to run a handshake protocol
(such as STUN) to determine your port number and this seems rather
unlikely for SSM sessions, especially since all receivers would
need to come up with the same port.

 From this perspective, it was a logical choice to use RFC3605
to indicate a different feedback target since this is also unicast.
Had we assumed that we would need to modify the forward port, too,
then re-using RFC3605 for the SSM direction and coming up with
something new for the reverse direction.

(the fundamental problem seems to be that SDP lacks the notion
  of directionality with attributes and they get only incompletely
  introduced if the o/a model is used)

I haven't been able to follow all of the discussion, but: do we
really need this?

If so, Ali's proposal (the new draft) would work but we should make
sure that we don't miss some of the cases.

Btw, shouldn't the attribute also allow for a different mc group
and src address to be complete?

Joerg

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 11 Mar 2010 16:40:34 +0100

Why don't we extend the discussion and look for a means by which an offerer can indicate the port on which it wants to receive RTCP (from the answerer) and the (source) port on which it will send RTCP. I.e. not constrain the solution to SSM only as per Ali's draft.
Maybe I missed it, but this decoupling of RTCP ports does not seem possible today with current SDP RFCs..

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joerg Ott
Sent: donderdag 11 maart 2010 15:58
To: Ali C. Begen (abegen)
Cc: Magnus Westerlund; Dave Oran (oran); [email-masked]
Subject: Re: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

Yes, 5760 follows basic RTP and hence the port+1 rule is assumed to be applied.  From a practical perspective, this is did not appear to be an issue for multicasting.  AFAIR, this was never raised before unicast RTP became popular.

RFC3605 was designed for unicast communications in cases in which you NATed; in those cases, you will need to run a handshake protocol (such as STUN) to determine your port number and this seems rather unlikely for SSM sessions, especially since all receivers would need to come up with the same port.

 From this perspective, it was a logical choice to use RFC3605 to indicate a different feedback target since this is also unicast.
Had we assumed that we would need to modify the forward port, too, then re-using RFC3605 for the SSM direction and coming up with something new for the reverse direction.

I haven't been able to follow all of the discussion, but: do we really need this?

If so, Ali's proposal (the new draft) would work but we should make sure that we don't miss some of the cases.

Btw, shouldn't the attribute also allow for a different mc group and src address to be complete?

Joerg

Ali C. Begen (abegen) wrote:
>> Subject: Re: [AVT] My comments on 
>> draft-ietf-avt-ports-for-ucast-mcast-rtp-00
>>
>>> I checked RFC 3605 again and did not find anything that restricted 
>>> using two or more a=rtcp lines
>> for the same media description.
>> infer which port is for the multicast rtcp and which is for the FT 
>> rtcp when the FT resides on the distribution source.
>> But the FT address will have a unicast address as part of the line 
>> and the other will only be a port. So I think it is possible to 
>> define that
> 
>> clearly in this context. I have to say that I am a bit worried for 
>> more esoteric cases, like if one started using a multicast address as 
>> the feedback target.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ---------------------------------------------------------------------
>> - Multimedia Technologies, Ericsson Research EAB/TVM

---

From: [email-masked]
Date: Fri, 12 Mar 2010 11:04:02 +0100

Hi,

Had you a look to RTSP (if it applies to your application target)? For
unicast sessions, SETUP transport attribute allow to advertise ports
and IP addresses between server and receiver to precise information
that cannot be set in SDP.

Moreover, as NAT does not always allow to specify neither port numbers
nor IP addresses, SDP or SETUP transport attribute allow to explicitely
precise the SSRC to identify a session. Then receiving a RTP message or
a RTCP with SSRC of the media source can link IP address and port to
the right real time session (preferably with rtcp multiplexing).

Regards,

Gérard BABONNEAU

Joerg Ott a écrit :

Yes,
5760 follows basic RTP and hence the port+1 rule is assumed

really need this?

Joerg

-----Original Message-----

I checked RFC 3605 again and did not find
anything that restricted using two or more a=rtcp lines

However, if there are two a=rtcp lines
for an SSM media description, it might not be possible to

infer which port is for the multicast rtcp and which is for the FT rtcp
when the FT resides on the

distribution source.

From what I understand the rtcp ssm spec
allows to specify only the port for the FT as well if FT is running on
the same box with the source (i.e., the unicast address for FT does not
look like a "must") since the address of the source is already
specified in the a=source-filter line.

-acbegen

clearly in this context. I have to say that
I am a bit worried for more

feedback target.

Cheers

Magnus Westerlund

[email-masked]

[email-masked]

--

BABONNEAU Gerard RD-MAPS-REN

REN/MAPS/DPC

Tel : +33 299124008

Email:
[email-masked]

R&D Rennes 4, rue du Clos-Courtel - BP 91226 - 35512 Cesson-Sevigne
Cedex - France

Mailer ThunderBird sous Mandriva

Installez simplement votre poste de travail Linux avec
http://web2000.rd.francetelecom.fr

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 15 Mar 2010 16:29:38 +0100

Hi,

On the particular item I addressed in my previous mail, I thought it makes sense to also provide the use case why such signaling may be advantageous. The use case is actually related to the RAMS topic as well (and by extension to the port mapping solution being discussed).

There is no reason why the RS cannot send the retransmission RTP packets on the same port P on which it receives the RTCP messages related to the SSM. This latter port is announced by means of the a=rtcp:<port P> IN IP4 <IP-address> line for the ssm. The source port of the RTP packets transmitted by the RS would hence be P, and when RTP-RTCP packets are single port muxed in the retransmission session, then also the RTCP packets are sent by the RS on this source port P.

On the other hand, the RS needs to receive RTCP packets in the retransmission session from the RTP receiver on a port different from P, otherwise the RS cannot make a distinction between RTCP packets received in the SSM and RTCP packets received in the unicast retransmision session. This is because the SSRC's must be kept the same across the original SSM and the associated retransmission session (RFC 4588) 

But.. As far as I know there is no way to signal in SDP these two different ports, or at least there is some unambiguity created for instance when single port muxing is implemented by the sender. 

Specifically for the RAMS , the signaling that addresses the case I describe above, could be (I borrowed the SDP from the RAMS I-D):

v=0
        o=ali 1122334455 1122334466 IN IP4 rams.example.com
        s=Rapid Acquisition Example
        t=0 0
        a=group:FID 1 2
        a=rtcp-unicast:rsi
        m=video 41000 RTP/AVPF 98
        i=Primary Multicast Stream
        c=IN IP4 233.252.0.2/255
        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
        a=rtpmap:98 MP2T/90000
        a=rtcp:41001 IN IP4 192.0.2.1

(RTP RX will send RTCP NACK etc on destination port P= 41001)

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack rai
        a=ssrc:123321 cname:[email-masked]
        a=rams-updates
        a=mid:1
        m=video 41001 RTP/AVPF 99

( RTP ret packets will be sourced on port 41001)

        i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtcp-mux

(The RTCP packets will be sourced on port 41001 as well)

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

(Does this mean :  RTCP packets will be sent by the RS on source port  41003  -..which is hence in conflict with the port muxing attribute !- , or  the RTP Rx should send its RTCP messages on destination port 41003 ???)

        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:2

...Any input appreciated on this question.
Tom

-----Original Message-----
From: VAN CAENEGEM Tom 
Sent: donderdag 11 maart 2010 16:41
To: 'Joerg Ott'; Ali C. Begen (abegen)
Cc: Magnus Westerlund; Dave Oran (oran); [email-masked]
Subject: RE: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joerg Ott
Sent: donderdag 11 maart 2010 15:58
To: Ali C. Begen (abegen)
Cc: Magnus Westerlund; Dave Oran (oran); [email-masked]
Subject: Re: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

Joerg

Ali C. Begen (abegen) wrote:
>> -

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Mon, 15 Mar 2010 14:19:49 -0500

I am more comfortable on other aspects of this design, as I am not an SDP expert. 

Having said that - if the SDP is not precise in the area of mapping unicast flows associated with multicast flows, it seems that we have license to extend it. As long as we do not change the existing semantics (and the new semantics are consistent with the old semantics), we should be OK.

Can we define a new keyword that boils down to "here is the feedback target port for this flow" and "here is the feedback source port for this flow". I am not real sure when one would try to specify the source port of the feedback, though. It seems that the client should follow the usual convention and ask for a random port number. I guess we could define the semantics of such a configuration for clarity and very rarely use it.

Bvs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN CAENEGEM Tom
Sent: Monday, March 15, 2010 11:30 AM
To: Joerg Ott; Ali C. Begen (abegen)
Cc: Magnus Westerlund; Dave Oran (oran); [email-masked]
Subject: Re: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

Hi,

v=0

        a=rtcp-fb:98 nack
        a=rtcp-fb:98 nack rai

        a=rtpmap:99 rtx/90000
        a=rtcp:41003

-----Original Message-----
From: VAN CAENEGEM Tom 
Sent: donderdag 11 maart 2010 16:41
To: 'Joerg Ott'; Ali C. Begen (abegen)
Cc: Magnus Westerlund; Dave Oran (oran); [email-masked]
Subject: RE: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joerg Ott
Sent: donderdag 11 maart 2010 15:58
To: Ali C. Begen (abegen)
Cc: Magnus Westerlund; Dave Oran (oran); [email-masked]
Subject: Re: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

Joerg