Subject: [AVT] Ports and addresses in RAMS messages ?

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 3 Dec 2009 19:45:36 +0100

Hi

It was discussed in
http://www.ietf.org/mail-archive/web/avt/current/msg12058.html
that addresses should not be conveyed in RAMS messages. I tried to find the reasons to this viewpoint in ealier AVT threads but sofar I have failed. Could you please shed a light on this ?

BR
/Ingemar 

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 3 Dec 2009 10:58:37 -0800

Have you seen the draft http://www.ietf.org/id/draft-begen-avt-ports-for-ucast-mcast-rtp-01.txt ? That draft addresses the issues when the receiver is behind a nat and/or wants to use its desired ports for the unicast session. A revision is due soon.

In your draft, though, I don't think this is an issue since it is multicast-based. You can simply define the port for each multicast-burst session. In other words, clients don't get to choose port numbers, they use whatever the SDP tells them to use.

-acbegen

> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]]
> Sent: Thursday, December 03, 2009 1:46 PM
> To: Roni Even; Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: Ports and addresses in RAMS messages ?
> 
> Hi
> 
> It was discussed in
> that addresses should not be conveyed in RAMS messages. I tried to find the reasons to
> this viewpoint in ealier AVT threads but sofar I have failed. Could you please shed a
> light on this ?
> 
> BR
> /Ingemar
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 3 Dec 2009 14:52:57 -0500

We were trying to avoid the class of problems you get whenever an IP address is carried in the payload of a higher layer protocol. When such behavior is allowed, problems result when you introduce NAT devices or when you change from IPV4 to IPV6. Application Layer Gateways end up getting written to find and fixup the embedded addresses, and things rapidly get complex. There are also security concerns around attack vectors, particularly for denial of service attacks.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Thursday, December 03, 2009 1:46 PM
To: Roni Even; Ali C. Begen (abegen)
Cc: [email-masked]
Subject: [AVT] Ports and addresses in RAMS messages ?

Hi

It was discussed in

BR
/Ingemar 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Dec 2009 11:15:31 +0100

> In your draft, though, I don't think this is an issue since it is multicast-based. You can simply define the port for each multicast-burst session. In other words, clients don't get to choose port…

Hi,

I agree that avoiding carrying addresses in the protocol is a good
thing. I would suggest that actually taking RAMS the whole way in this.
Are there a reason for not requiring RTP/RTCP MUX? That way only a
single binding is needed for both RTP and RTCP. That way you can use
RTCP to open and bind the unicast session and the keep-alive is
automatic for the unicast RTP_Rx to RS session as long as it exist.
Using one port for data and one for RTCP seems to only create extra load
and complexities in the solutions. That also makes the valdidation
easier. The RS only needs to send a cookie that is echoed back by the
RTP_RX if it is present once.

I would point out that STUN would work fine as the validation protocol,
but I guess people will scream over implementing another protocol, and
thus prefer to incorporate similar complexities into RTCP. Yes, RTCP
based solution will be leaner, but I haven't looked into if the reasons
STUN has integrity protection etc doesn't apply to this usage also.

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: Fri, 4 Dec 2009 08:23:03 -0800

Hi Magnus,

> Are there a reason for not requiring RTP/RTCP MUX? That way only a

Part of the complications come from the fact that in RAMS we have two sessions sourced from different sources but end at the same client. Muxing helps with some of the issues but does not avoid all of them.

> RTP_RX if it is present once.

Yeah, we are working on a few alternatives right now and will document them in the revision for the port mapping draft. 

Thanks, acbegen.