Subject: [AVT] Port mapping draft

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 22 Feb 2010 17:17:50 +0100

Hi,
 
with the spirit of achieving a "best of breed" solution for the port
mapping draft and accelerating the discussions, as this draft is called
upon to move to WG status, here are some further thoughts/comments on
the port mapping draft.
Any feedback welcome.
Tom

There are now two methods in the draft (server-side cookie generation
and receiver side cookie generation), and in a previous mail I proposed
another method, which can be considered a hybrid one.
I think we should limit the amount of methods and preferrably stick to a
single method. Considering pros and cons of the three methods may result
in selecting one method. Here we go:
 
1)Server-side cookie generation:
-server in control of cookie, hence no cookie conflicts for two
receivers behind same NAT using single public IP address (+)
-delay is minimum two round trip times (-)
-explicit server acknowledgement of port mapping success (+)

2)Client-side cookie generation:
-there can be cookie conflict for  two receivers behind same NAT using
single public IP address (-)
    -but small chance and if it occurs, server will not respond on
subsequent RAMS-R/NACK RTCP FB message
-delay is minimum half the round trip time (+)
-no server acknowledgement for receiver (-)
    -receiver may deduce port mapping failed (messages were dropped)
based on the observation that there is no response on RAMS/NACK RTCP FB
messages that are subsequently sent.
    -receiver can send multiple identical port messages to anticipate on
packet loss (may require message sequence number?)

3)"Hybrid" : in this solution, the receiver generates a single cookie
and this single cookie is provided in both RTCP port mapping messages;
one message has as destination port the RTP port on which the RTP
receiver wants to receive RTP packets in the unicast stream, the other
message has as destination port the RTCP port on which the RTP receiver
wants to receive RTCP packets. The messages then contain a flag whether
the message applies to RTP port mapping, RTCP port mapping or both (
when the receiver supports  RTP/RTCP muxing, signaled  with a single
port mapping message )
The proposal is that the Server then needs to respond with identical
message(s) but where the (single) cookie is in general server-generated
(but can be a copy of the cookie generated by the receiver).
 
In this solution a single cookie at the server side provides state info
both about the RTCP and the RTP port.

-there is no cookie conflict for  two receivers behind same NAT using
single public IP address (+)
    -the difference with client-side cookie generation method (2) is
that server can allocate a different cookie to this second receiver that
used the same cookie as the 1st receiver. If this RTP receiver is a fake
one and a means to attack the other RTP receiver service, this attack
will fail because of the different cookie. If this RTP receiver is
simply an RTP receiver behind same NAT that happened to generate the
same cookie, it can be serviced equally well, without risk of disturbing
the service to the 1st RTP receiver.
-delay is minimum one round trip time (-/+)
-explicit server acknowledgement of port mapping success (+)

So, the hybrid one seems to perform better than the two other methods,
with a delay figure in between the two other delay figures. But there
may be other factors that should be compared.. (please, tell me)

But even with respect to delay, there  is a strong improvement possible:
as the port-mapping solution MUST be supported by an RTP receiver in
situations where a unicast RTP session is coupled to a SSM -as is the
case for RAMS and for unicast Retransmissions coupled to SSM- I see no
reason why we cannot have a (default) port indicated in the SDP (or
whatever signaling means is used for transferring session parameters)
for the unicast RTP stream. The retransmission server uses default this
port mapping for the requesting RTP receivers, unless it receives
(normal) portmapping RTCP messages. However, we still may want to
address NAT traversal in this case. This is possible, when the RTP
receiver sends RTCP Port mapping message(s) from the RTP port/RTCP port
announced in the SDP to the RS. The RS will see that the source port(s)
match the default destination port for the RTP flow, and can ignore
these messages. 
 
This allows an RTP receiver to request the RTP flow from the RS  -which
will traverse the NAT -without any delay as the portmapping messages can
be sent simultaneously with the RTCP FB/NACK, when this RTP receiver
agrees with the proposed default port(s). In particular, when a RTCP
RAMS-R or RTCP FB NACK is received without cookie attached, the RS will
use the default port.

These are some other points that need to be addressed by this draft,
IMO:
 
-how does the RTP receiver send the cookie together with RTCP messages
that address the feedback target (RAMS-R and NACK FB)?  Do we envisage
an app-specific RTCP message or define a new RTCP message? What about
defining a new TLV for the RAMS-R message for containing this cookie
value.  Realising this is only applicable for RAMS, but it would be the
most efficient way, and would also work in deployment like IPTV where
RAMS and retransmissions are used in parallel.
 
-as a port mapping RTCP message  allows NAPT traversal, should there not
be some text indicating that to keep the NAPT open, an RTP receiver may
have to repeat sending a port mapping message, when no RTP/RTCP messages
are received on the unicast RTP session for a long time?  And how does
this affect the server to which the port mapping messages are addressed?
Perhaps it makes sense to include additional field(s) in the port
mapping message, which allows a server to distinguish between such "keep
alive" port mapping messages and "1st" port mapping message(s)?
 
-a comment related to the section 4.2.2 (implications of NAT) in the
draft: the text stipulates when/whether a given RTP receiver needs to
engage in a new portmapping process  when some of the port/address
parameters change in the unicast/multicast flows, depending on whether
the RTP receiver is behind a (specific) NAT device. We should have text
that imposes the most frequent portmapping process when an RTP receiver
does not know anything about this (presence of a) NAT.
 
-how long does the (non-default) port mapping remain valid at the
Retransmission server? I guess the RS cannot remove a cookie entry in
its database when a bye message is received (on the feedback target or
on the RS), as it would require an RTP receiver to do the port mapping
whenever a new multicast channel is joined. Is this based on a time-out
(i.e. no more RTCP messages were received by the RTP receiver with this
cookie embedded)

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 22 Feb 2010 10:28:45 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of VAN CAENEGEM Tom
> Sent: Monday, February 22, 2010 8:18 AM
> To: [email-masked]
> Subject: [AVT] Port mapping draft

[... I had no comments on the hybrid cookie approach ...]

> But even with respect to delay, there  is a strong 
> improvement possible:  as the port-mapping solution MUST be 
> supported by an RTP receiver in situations where a unicast 
> RTP session is coupled to a SSM -as is the case for RAMS and 
> for unicast Retransmissions coupled to SSM- I see no reason 
> why we cannot have a (default) port indicated in the SDP (or 
> whatever signaling means is used for transferring session 
> parameters) for the unicast RTP stream. The retransmission 
> server uses default this port mapping for the requesting RTP 
> receivers, unless it receives (normal) portmapping RTCP 
> messages. However, we still may want to address NAT traversal 
> in this case. This is possible, when the RTP receiver sends 
> RTCP Port mapping message(s) from the RTP port/RTCP port 
> announced in the SDP to the RS. The RS will see that the 
> source port(s) match the default destination port for the RTP 
> flow, and can ignore these messages. 
>  
> This allows an RTP receiver to request the RTP flow from the 
> RS  -which will traverse the NAT -without any delay as the 
> portmapping messages can be sent simultaneously with the RTCP 
> FB/NACK, when this RTP receiver agrees with the proposed 
> default port(s). In particular, when a RTCP RAMS-R or RTCP FB 
> NACK is received without cookie attached, the RS will use the 
> default port.

I worry about default ports, because it changes the behavior for
the 1st RTP receiver behind a NAT (which might be able to get the 
NAT to assign it that same port) versus the behavior for the 
2nd or 3rd RTP receiver.  This complicates code (rather than
simplifying it) and complicates testing/validation.  

I admit I don't fully understand the proposal for a default port,
but it seems it could cause a RS to believe it is helping an
RTP receiver when it is helping the wrong RTP receiver (or helping
no RTP receiver at all).
  
> These are some other points that need to be addressed by this 
> draft, IMO:
>  
> -how does the RTP receiver send the cookie together with RTCP 
> messages that address the feedback target (RAMS-R and NACK 
> FB)?  Do we envisage  an app-specific RTCP message or define 
> a new RTCP message? What about defining a new TLV for the 
> RAMS-R message for containing this cookie value.  Realising 
> this is only applicable for RAMS, but it would be the most 
> efficient way, and would also work in deployment like IPTV 
> where RAMS and retransmissions are used in parallel.
>  
> -as a port mapping RTCP message  allows NAPT traversal, 
> should there not be some text indicating that to keep the 
> NAPT open, an RTP receiver may have to repeat sending a port 
> mapping message, when no RTP/RTCP messages  are received on 
> the unicast RTP session for a long time? 

To keep the NAPT open, most NAPTs need to see occasional
messages from the inside (RTP receiver) to outside (RS).

There is existing text in Section 4.3.1 (receiver-generated cookie),

   4.  The client sends separate RTCP packets from its ports c2 and c3
       to the server port P3 to setup the NAT.  Each RTCP packet
       indicates through a bit/field whether it source port will be used
       for RTP or RTCP traffic by the client.  The client repeats this
       step as deemed necessary to keep the NAT bindings alive.

but I don't see similar text in the server-generated cookie section.

I agree there should be text discussing the RTP receiver needs to keep the
NAPT mapping alive, most likely in the Implication of NATs section.

> And how does this 
> affect the server to which the port mapping messages are 
> addressed? Perhaps it makes sense to include additional 
> field(s) in the port mapping message, which allows a server 
> to distinguish between such "keep alive" port mapping 
> messages and "1st" port mapping message(s)?

Yeah, something like a 0-byte UDP packet could keep the
NAPT mapping alive and be easily and quickly discarded 
by the RS -- or even in a device before the RS (e.g., a
router or firewall).

> -a comment related to the section 4.2.2 (implications of NAT) 
> in the draft: the text stipulates when/whether a given RTP 
> receiver needs to engage in a new portmapping process  when 
> some of the port/address parameters change in the 
> unicast/multicast flows, depending on whether the RTP 
> receiver is behind a (specific) NAT device. We should have 
> text that imposes the most frequent portmapping process when 
> an RTP receiver does not know anything about this (presence of a) NAT.
>  
> -how long does the (non-default) port mapping remain valid at 
> the Retransmission server? I guess the RS cannot remove a 
> cookie entry in its database when a bye message is received 
> (on the feedback target or on the RS), as it would require an 
> RTP receiver to do the port mapping whenever a new multicast 
> channel is joined. Is this based on a time-out  (i.e. no more 
> RTCP messages were received by the RTP receiver with this 
> cookie embedded)

Timeout seems best.  Can't rely on BYE (RTP receiver might crash,
be unplugged, network failure, in-home power failure, ...).

The RTP receiver should send a keepalive to the RS to keep the
RS's state active.  That keepalive is not, necessarily, the same 
keepalive the RTP receiver sends to keep its NAPT mapping alive.

-d

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Feb 2010 12:52:28 -0800

Hi Tom, Dan,

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Monday, February 22, 2010 11:18 AM
> To: [email-masked]
> Cc: Ali C. Begen (abegen)
> Subject: Port mapping draft
> 
> 
> Hi,
> 
mapping draft and accelerating
> the discussions, as this draft is called upon to move to WG status,
here are some further
> thoughts/comments on the port mapping draft.
> Any feedback welcome.
> Tom
> 
> 
and receiver side cookie
> generation), and in a previous mail I proposed another method, which
can be considered a hybrid one.
> I think we should limit the amount of methods and preferrably stick to
a single method. Considering
> pros and cons of the three methods may result in selecting one method.
Here we go:

I tend to agree that sticking with one approach is a good idea.
 
> -server in control of cookie, hence no cookie conflicts for two
receivers behind same NAT using single
> public IP address (+)

If the NAT is doing endpoint-independent mappings (definition is from
RFC 4787), there is no delay penalty. The client gets the necessary
cookies at the beginning and uses them whenever necessary. If the
mappings are endpoint-dependent, the client needs to generate specific
cookies for each port on RS and different RS addresses (Section 4.2.2).

>     -but small chance and if it occurs, server will not respond on
subsequent RAMS-R/NACK RTCP FB
> message
based on the observation that
> there is no response on RAMS/NACK RTCP FB messages that are
subsequently sent.
>     -receiver can send multiple identical port messages to anticipate
on packet loss (may require
> message sequence number?)

This approach has more issues and is less reliable especially if client
is not doing port muxing. If we mandate port muxing for the client (the
server already has to port-mux), this approach becomes a lot more
reliable.

> 3)"Hybrid" : in this solution, the receiver generates a single cookie
and this single cookie is
> provided in both RTCP port mapping messages; one message has as
destination port the RTP port on which
> the RTP receiver wants to receive RTP packets in the unicast stream,
the other message has as
> destination port the RTCP port on which the RTP receiver wants to
receive RTCP packets. The messages
> then contain a flag whether the message applies to RTP port mapping,
RTCP port mapping or both ( when
> the receiver supports  RTP/RTCP muxing, signaled  with a single port
mapping message )
> The proposal is that the Server then needs to respond with identical
message(s) but where the (single)
> cookie is in general server-generated (but can be a copy of the cookie
generated by the receiver).
> 
> In this solution a single cookie at the server side provides state
info both about the RTCP and the
> RTP port.
>     -the difference with client-side cookie generation method (2) is
that server can allocate a
> different cookie to this second receiver that used the same cookie as
the 1st receiver. If this RTP
> receiver is a fake one and a means to attack the other RTP receiver
service, this attack will fail
> because of the different cookie. If this RTP receiver is simply an RTP
receiver behind same NAT that
> happened to generate the same cookie, it can be serviced equally well,
without risk of disturbing the
> service to the 1st RTP receiver.

The server seems to keep state for the previously assigned cookies. Is
that correct?
 
> So, the hybrid one seems to perform better than the two other methods,
with a delay figure in between
> the two other delay figures. But there may be other factors that
should be compared.. (please, tell
> me)
> 
> 
> But even with respect to delay, there  is a strong improvement
possible:  as the port-mapping solution
> MUST be supported by an RTP receiver in situations where a unicast RTP
session is coupled to a SSM -as
> is the case for RAMS and for unicast Retransmissions coupled to SSM- I
see no reason why we cannot
> have a (default) port indicated in the SDP (or whatever signaling
means is used for transferring
> session parameters) for the unicast RTP stream. The retransmission
server uses default this port
> mapping for the requesting RTP receivers, unless it receives (normal)
portmapping RTCP messages.
> However, we still may want to address NAT traversal in this case. This
is possible, when the RTP
> receiver sends RTCP Port mapping message(s) from the RTP port/RTCP
port announced in the SDP to the
> RS. The RS will see that the source port(s) match the default
destination port for the RTP flow, and
> can ignore these messages.

Not sure whether this would reliably work in cases where multiple
clients behind the same NAT wanted to communicate with the same server.
 
> This allows an RTP receiver to request the RTP flow from the RS
-which will traverse the NAT -without
> any delay as the portmapping messages can be sent simultaneously with
the RTCP FB/NACK, when this RTP
> receiver agrees with the proposed default port(s). In particular, when
a RTCP RAMS-R or RTCP FB NACK
> is received without cookie attached, the RS will use the default port.
> 
> 
> 
> -how does the RTP receiver send the cookie together with RTCP messages
that address the feedback
> target (RAMS-R and NACK FB)?  Do we envisage  an app-specific RTCP
message or define a new RTCP
> message? What about defining a new TLV for the RAMS-R message for
containing this cookie value.

I believe we need to define a new RTCP message that will be bundled with
RAMS-R or NACK. A TLV is no use for NACKs.

> Realising this is only applicable for RAMS, but it would be the most
efficient way, and would also
> work in deployment like IPTV where RAMS and retransmissions are used
in parallel.

In RAMS, we can do a TLV for it. But, I don't think it will save us
anything since different RTCP messages going to the same port can be
bundled in the same RTCP packet.
 
> -as a port mapping RTCP message  allows NAPT traversal, should there
not be some text indicating that
> to keep the NAPT open, an RTP receiver may have to repeat sending a
port mapping message, when no
> RTP/RTCP messages  are received on the unicast RTP session for a long
time?  And how does this affect

The client needs to keep the NAT bindings open and to do that keepalive
messages are needed. We will add more explicit text for this.

> the server to which the port mapping messages are addressed? Perhaps
it makes sense to include
> additional field(s) in the port mapping message, which allows a server
to distinguish between such
> "keep alive" port mapping messages and "1st" port mapping message(s)?

The keepalive messages do not have to be a portmapping message.

> -a comment related to the section 4.2.2 (implications of NAT) in the
draft: the text stipulates
> when/whether a given RTP receiver needs to engage in a new portmapping
process  when some of the
> port/address parameters change in the unicast/multicast flows,
depending on whether the RTP receiver
> is behind a (specific) NAT device. We should have text that imposes
the most frequent portmapping
> process when an RTP receiver does not know anything about this
(presence of a) NAT.

I am not sure which part you are referring to. If the client knows there
is no NAT between itself and the server, it needs one cookie per server
(if muxing), or two cookies per server (if not muxing). The port on the
server does not impact the cookie and the client can use the same cookie
for any port on that specific server.

If there is a NAT though, depending on whether the mappings are
endpoint-dependent or not, the client may need separate cookies for each
different port on the server.

If the client does not know whether there is NAT or not or what type of
NAT is that, I believe it must assume the worst case scenario (which is
a NAT doing endpoint-dependent mappings) to be on the safe side.
 
> -how long does the (non-default) port mapping remain valid at the
Retransmission server? I guess the
> RS cannot remove a cookie entry in its database when a bye message is
received (on the feedback target
> or on the RS), as it would require an RTP receiver to do the port
mapping whenever a new multicast
> channel is joined. Is this based on a time-out  (i.e. no more RTCP
messages were received by the RTP
> receiver with this cookie embedded)

Why is there a need for a timeout mechanism? The cookies are not stored
on the server. The needed cookies can be generated when the client is
booted and be used later as long as client uses the same local ports and
client's public address and ports do not change. I believe we need to
consider what happens when NAT fails and restarts, though since public
IP address may change and mappings may change.

When a cookie is received by the server, it simply does the inverse
transform to get what it needs (client's addressing information). This
is the case for server-side cookie approach.

In the client-side approach, client sends a random cookie and server
does the correlation among different messages based on this random
value. Once the unicast session is established, the random cookie
generated by the client is kept as part of the state information (in
addition to clients' rtp and rtcp ports, address, and other stuff needed
during an RTP session). Until this session is terminated, the same
cookie value cannot be used for another client sharing the same public
IP address. That is, if a BYE is received, the cookie becomes available.
If a BYE is never received, normal RTP rules from 3550 should be
followed by the server to determine when the session can be assumed
ended and at that time, the cookie becomes available. I don't think we
should impose any different timeout rules for cookies.

-acbegen

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 25 Feb 2010 10:42:20 +0100

Ali, Dan

Thanks for sharing your thoughts. I think at least one point still needs
to be clarified, related to the state information of the cookie. 
See below (Tom) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: maandag 22 februari 2010 21:52
To: VAN CAENEGEM Tom; [email-masked]
Cc: Dan Wing (dwing)
Subject: Re: [AVT] Port mapping draft

Hi Tom, Dan,

here are some further
and receiver side cookie
Here we go:

TOM: With "delay" I meant the delay for the RTP receiver between being
able to send its 1st RTCP FB message (NACK or RAMS-R for the considered
example applications) with embedded cookie and the sending of the 1st
port mapping message. I agree this delay implies only "at the beginning"
: for instance mapping to the IPTV use case, if I switch on the STB, it
first needs to go through the port mapping before it can send the RAMS-R
message. After that, if the same port mapping can be used, it does not
matter anymore (no delay).  

> message
> -delay is minimum half the round trip time (+) -no server 
> acknowledgement for receiver (-)
subsequently sent.

the other message has as
mapping message )
> -delay is minimum one round trip time (-/+) -explicit server 
> acknowledgement of port mapping success (+)

Tom: keeping state is a common aspect when the server generates the
cookie or the receiver generates a cookie: whenever the RS receives a
cookie in a RTCP FB message, it needs to look-up what are the port(s)
for the RTP/RTCP flow associated with that cookie. When the RS receives
a port mapping message (with a (receiver generated) cookie), it needs to
make sure it assigns a cookie to that receiver that is unique for the
specific public IP address (this is valid for all approaches), so it
must do a look-up in the cookie table, to see if the cookie already
exists for the given public IP address to look after  the case with
multiple receivers behind the same public IP address. If the cookie
already exists, the newly generated cookie must be different. 

Tom: good point, but would a NAT do the same mapping to the same
external source port (and same public IP address) for two receivers in
the local network issuing messages with same ports (source and public)
and same destination IP address? I do not think so, as there would be a
null effect of the NAT, i.e. the NAT would not do what it is supposed to
do (and it would hence not know to which receiver on the local network
it should forward any packets sent by the RS to one of the two
receivers) . However, the big problem with the default port approach is
that the NAT traversal will not work, independent from the fact if one
or multiple receivers are behind this NAT, because the receiver does not
know which local port maps to the advertised default public port (so my
explanation in previous mail (above) to address NAT traversal was wrong)

in parallel.

Tom: they can be any RTCP messages related to the unicast RTP flow, is
that what you mean, like SDES, RR (which can be empty)?

process  when some of the
(presence of a) NAT.

Tom: right

TOM: this is what I do not get (see my pre-previous comment): when a
FT/RS receives a NACK/RAMS-R/whatever with a cookie, how does the server
deduce the port for the unicast RTP stream? By looking up which cookie
corresponds with which port, no? Hence cookies must be stored at the
server-side. This is valid for all approaches, IMO.

-acbegen

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 25 Feb 2010 09:44:43 -0800

Hi Tom, All,

...
> matter anymore (no delay).

Yes.
 
... 
> explanation in previous mail (above) to address NAT traversal was
wrong)

OK. In our initial pubports proposal, we used a stun server co-located
with RS to figure out the external ports and these ports were reported
back to RS in an RTCP message but as you know this idea was not favored
in the breakout session.

> that what you mean, like SDES, RR (which can be empty)?

I believe so.

> IP address may change and mappings may change.

Update: If NAT fails, the public IP/port information will likely change
and the reverse transform will fail. Eventually the client will get
suspicious and will need to request new cookie(s).
 
> server-side. This is valid for all approaches, IMO.

That information is built into the cookie by using a processing only
known to the server. When the server receives a NACK with a cookie, it
will "decode" the cookie and know which port(s) the client wants to use
in the unicast session. 

In the current draft, in Figure 4, only one cookie (for c2) is included
with the NACK message. But, the cookie for c3 also needs to be included
with the NACK, otherwise the server cannot send sender reports to the
right port.

It is easy to see that not doing port-muxing complicates either approach
(server or client-based). In particular, the client-based approach is
pretty heavily impacted in terms of reliability. Does the WG think
mandating port muxing on the client side will be useful?

Please share your comments.

-acbegen

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 25 Feb 2010 10:12:04 -0800

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Thursday, February 25, 2010 9:45 AM
> Subject: RE: [AVT] Port mapping draft
...
> Does the WG think mandating port muxing on the client side 
> will be useful?

It would reduce a lot of complexity.  The client already 
needs to do a lot of "new stuff", so requiring it support
RTP and RTCP on the same port can be added to the list of
"new stuff". 

"KISS."

-d

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 25 Feb 2010 14:01:57 -0500

Is this TCP only? Is this implicit or explicit?
Is use of UDP explicitly constrained out?

Art
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 Dan Wing
|Sent: Thursday, February 25, 2010 1:12 PM
|To: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; [email-masked]
|Subject: Re: [AVT] Port mapping draft
|
|> -----Original Message-----
|> From: Ali C. Begen (abegen) [mailto:[email-masked]]
|> Sent: Thursday, February 25, 2010 9:45 AM
|> To: VAN CAENEGEM Tom; [email-masked]
|> Cc: Dan Wing (dwing)
|> Subject: RE: [AVT] Port mapping draft
|...
|> Does the WG think mandating port muxing on the client side will be 
|> useful?
|
|It would reduce a lot of complexity.  The client already needs 
|to do a lot of "new stuff", so requiring it support RTP and 
|RTCP on the same port can be added to the list of "new stuff". 
|
|"KISS."
|
|-d
|
|
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 26 Feb 2010 11:23:34 -0800

Not sure if I understand your question. There is no tcp involvement
here. The applications we are considering are using UDP ports.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Allison, Art
> Sent: Thursday, February 25, 2010 2:02 PM
> To: [email-masked]

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 26 Feb 2010 14:53:30 -0500

Thanks, I got an off list response that clarified. 
I thought that the dual mode client's unicast aspect involved TCP for
the signaling related to the UDP flow.

Notwithstanding the current 'modern' thinking about port multiplexing;
ATSC mandates that separate ports be used for RTP and RTCP for the
content sent over UDP. But the ATSC Mobile IP system would not benefit
from RAMS, much less this port sharing anyway.

Sorry for the uninformed diversion.

Art Allison

www.nab.org

|-----Original Message-----
|From: Ali C. Begen (abegen) [mailto:[email-masked]] 
|Sent: Friday, February 26, 2010 2:24 PM
|To: Allison, Art; [email-masked]
|Subject: RE: [AVT] Port mapping draft
|
|Not sure if I understand your question. There is no tcp 
|involvement here. The applications we are considering are 
|using UDP ports.
|
|-acbegen
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On Behalf Of
|Allison, Art
|> Sent: Thursday, February 25, 2010 2:02 PM
|> To: [email-masked]
|> Subject: Re: [AVT] Port mapping draft
|> 
|> Is this TCP only? Is this implicit or explicit?
|> Is use of UDP explicitly constrained out?
|> 
|> Art
|> 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 
|> |Dan Wing
|> |Sent: Thursday, February 25, 2010 1:12 PM
|> |To: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; [email-masked]
|> |Subject: Re: [AVT] Port mapping draft
|> |
|> |> -----Original Message-----
|> |> From: Ali C. Begen (abegen) [mailto:[email-masked]]
|> |> Sent: Thursday, February 25, 2010 9:45 AM
|> |> To: VAN CAENEGEM Tom; [email-masked]
|> |> Cc: Dan Wing (dwing)
|> |> Subject: RE: [AVT] Port mapping draft
|> |...
|> |> Does the WG think mandating port muxing on the client 
|side will be 
|> |> useful?
|> |
|> |It would reduce a lot of complexity.  The client already 
|needs to do 
|> |a lot of "new stuff", so requiring it support RTP and RTCP on the 
|> |same port can be added to the list of "new stuff".
|> |
|> |"KISS."
|> |
|> |-d
|> |
|> |
|> |_______________________________________________
|> |Audio/Video Transport Working Group
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/avt
|> |
|> _______________________________________________
|> Audio/Video Transport Working Group
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/avt
|