Subject: [AVT] Remaining issues in the Token draft

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Dec 2010 19:29:23 -0800

Here are the open issues in the Token draft. For the latest (-05 version), refer to:
https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp/ 

1- O/A model for the 'portmapping-req' attribute. Magnus thinks we should define this but I am still not clear how to do this or why we are doing it. I will ask Magnus for help (or simply for the text).

2- Is there a need to allow address field in the 'portmapping-req' attribute? Magnus thinks "yes". Is there any strong opinion here? Right now, the address is implied from the c line in the unicast session or the a=rtcp line in the multicast session.

If we missed other issues, please speak up.

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 3 Dec 2010 11:33:30 +0100

(As WG cochair)

Please note this is an open question to the working group as a whole.

While Magnus and the editor have been discussing this so far on list, the working group as a whole needs to say what they want in the resultant RFC.

The chairs are trying to close all open issues on this document to allow what we believe is an open issue free version of the draft to exist by 10th December - at that point we want to start a 2 week WGLC on the document. So please treat this request with some urgency.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Friday, December 03, 2010 3:29 AM
> To: [email-masked]
> Subject: [AVT] Remaining issues in the Token draft
> 
> 1- O/A model for the 'portmapping-req' attribute. Magnus 
> thinks we should define this but I am still not clear how to 
> do this or why we are doing it. I will ask Magnus for help 
> (or simply for the text).
> 
> 2- Is there a need to allow address field in the 
> 'portmapping-req' attribute? Magnus thinks "yes". Is there 
> any strong opinion here? Right now, the address is implied 
> from the c line in the unicast session or the a=rtcp line in 
> the multicast session.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Dec 2010 13:28:40 +0100

> 1- O/A model for the 'portmapping-req' attribute. Magnus thinks we should define this but I am still not clear how to do this or why we are doing it. I will ask Magnus for help (or simply for the t…
I am willing to contribute text for this. I will do that next week. I
don't have time to do that today. And I don't see this as complex, only
to ensure that both offerer and answer knows how to interpret this
attribute in a O/A context.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
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: Magnus Westerlund <[email-masked]>
Date: Thu, 9 Dec 2010 14:39:32 +0100

> attribute in a O/A context.

Here is a text proposal that I would include in Section 7.1 of
(draft-06) as new paragraph after the currently last one. This is also
written from the perspective that the portmapping-req attribute will be
included in the session where the actual RTCP messages are declared.

When using this SDP attribute in SDP offer/answer [RFC3264] the
following needs to be considered. This attribute is used declarative.
If included on session level this applies to all media lines that uses
RTP. If included on media level, it applies to the RTCP feedback
messages declared by this media block.

An offerer that desires the answerer to use tokens in any RTCP message
sent to the offerer, i.e. received by the offerer, the attribute is
included. In case an offerer desires to declare support for using tokens
as defined in this specification but don't need tokens to be included
for any RTCP messages received by the offerer it can include the
portmapping-req attribute without any parameters, neither port nor
address, either on session or media level.

An answerer receiving an SDP offer with a=portmapping-req with a port
nunber shall use that port number and the address, either explicitly
provided in the attribute or implicitly provided by the c= line, for any
needed token request. If the a=portmapping-req attribute does not
contain a port, the answer shall take note of the capability.

When sending an answer, and the portmapping-req attribute has been
present in the answer including a port number and the answer support
this specification, then the Answer MUST include the attribute in its
answer. The answer may or may not include a port and address. This
depends on the application and the desire of the answer. The answerer
include a port and possibly and address when it want to receive tokens
in any RTCP message creating an unicast session. If it only supports
this specification but don't need tokens to be include the attribute is
included without any port.

----- End of text proposal ------

Please note that the above do require a syntax change of the SDP
attribute from:

portmapping-req-attribute = "a=portmapping-req:" port [nettype space
                                 addrtype space connection-address] CRLF

TO:

portmapping-req-attribute = "a=portmapping-req:" [port [nettype space
                                 addrtype space connection-address]] CRLF

Cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 9 Dec 2010 16:58:17 +0100

Hi Magnus,

Could you be more specific on the use case(s) you have in mind with the offer/answer for port mapping?
I have some problems understanding the offer/answer combined with port mapping....

The port mapping draft basically defines how  a unicast RTP session can be created without offer/answer, where instead there is indirect signaling of the port to be used for a new unicast session, by having the unicast RTP/RTCP destination port of the new session the same as the source port of the RTCP message in an existing RTP session that triggered this new RTP session. We explicitly have that the existing RTP session is a multicast session.

(BTW, I think we should emphasize this aspect more in section 7.1 that defines the port mapping req attribute)

The draft does also include security measures to make this method secure against certain DoS attackes, and hence defines tokens, token port, messages etc.. 

Is the offer/answer model you propose to be applied to the RAMS case as well where there is a multicast session, and unicast sessions are created as defined in the port mapping draft? 

I guess it goes beyond that,  as from your proposed text, I can see that both sender and receiver may indicate they want to receive tokens from the other peer.  Your text mainly is about token usage, but I guess there are  also implications on the ports to be used. Could that be in contradiction with other (port) signaling in the offer/answer SDP signaling? 

For RAMS we mandate support for this port mapping solution (including the token security measures). Can you elaborate (based on your use case) when or when not it would be required/recommended to use the port mapping mechanism when using offer/answer?

Thx
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: donderdag 9 december 2010 14:40
To: Ali C. Begen (abegen)
Cc: [email-masked]
Subject: Re: [AVT] Remaining issues in the Token draft

Magnus Westerlund skrev 2010-12-03 13:28:
> don't have time to do that today. And I don't see this as complex, 
> only to ensure that both offerer and answer knows how to interpret 
> this attribute in a O/A context.

Here is a text proposal that I would include in Section 7.1 of
(draft-06) as new paragraph after the currently last one. This is also written from the perspective that the portmapping-req attribute will be included in the session where the actual RTCP messages are declared.

When using this SDP attribute in SDP offer/answer [RFC3264] the following needs to be considered. This attribute is used declarative.
If included on session level this applies to all media lines that uses RTP. If included on media level, it applies to the RTCP feedback messages declared by this media block.

An offerer that desires the answerer to use tokens in any RTCP message sent to the offerer, i.e. received by the offerer, the attribute is included. In case an offerer desires to declare support for using tokens as defined in this specification but don't need tokens to be included for any RTCP messages received by the offerer it can include the portmapping-req attribute without any parameters, neither port nor address, either on session or media level.

An answerer receiving an SDP offer with a=portmapping-req with a port nunber shall use that port number and the address, either explicitly provided in the attribute or implicitly provided by the c= line, for any needed token request. If the a=portmapping-req attribute does not contain a port, the answer shall take note of the capability.

When sending an answer, and the portmapping-req attribute has been present in the answer including a port number and the answer support this specification, then the Answer MUST include the attribute in its answer. The answer may or may not include a port and address. This depends on the application and the desire of the answer. The answerer include a port and possibly and address when it want to receive tokens in any RTCP message creating an unicast session. If it only supports this specification but don't need tokens to be include the attribute is included without any port.

----- End of text proposal ------

Please note that the above do require a syntax change of the SDP attribute from:

TO:

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 08:57:57 -0800

After a few iterations with Magnus, here is the O/A text to be included in the revision (that will be submitted today). It clears up a few confusing parts and hopefully answers your questions.

-acbegen

7.1.  The portmapping-req Attribute

   This new SDP attribute is used declaratively to indicate the port and
   optionally the address for obtaining a Token.  Its presence indicates
   that a Token MUST be included in the feedback messages sent to the
   server triggering or controlling a unicast session (See Section 4.3
   for details).

   The formal description of the 'portmapping-req' attribute is defined
   by the following ABNF [RFC5234] syntax:

   Here, 'port', 'nettype', 'addrtype' and 'connection-address' are
   defined as specified in Section 9 of [RFC4566].  The 'portmapping-
   req' attribute is used as a session-level or media-level attribute.
   If used at a media level, the attribute MUST be used in a unicast
   media block.  In the optional address value, only unicast addresses
   are allowed; multicast addresses SHOULD NOT be used without
   evaluating the additional security risks such as non-legit servers
   generating fake Tokens.  If the address is not specified, the
   (source) address in the "c" line corresponding to the unicast media
   stream is implied.

   When using this SDP attribute in SDP offer/answer [RFC3264], the
   following needs to be considered.  This attribute is used
   declarative.  If included at session level, this applies to all media
   lines that uses RTP.  If included at media level, it applies to the
   RTCP feedback messages declared by this media block.

   An offerer that desires the answerer to use Tokens in any RTCP
   message sent to the offerer, i.e., received by the offerer, the
   attribute is included.  In case an offerer desires to declare support
   for using Tokens as defined in this specification but do not need
   Tokens to be included for any RTCP messages to be received by the
   offerer, it can include the 'portmapping-req' attribute without any
   parameters, neither port nor address, either at a session or media
   level.

   An answerer receiving an SDP offer with the "a=portmapping-req" line
   with a port number SHALL use that port number and the address, either
   explicitly provided in the attribute or implicitly provided by the
   "c" line, for any needed Token request.  If the "a=portmapping-req"
   line attribute does not contain a port, the answer SHALL take note of
   the capability.

   When sending an answer, if the 'portmapping-req' attribute has been
   present in the offer including a port number and the answerer
   supports this specification, then the answerer MUST include the
   attribute in its answer.  The answer may or may not include a port
   and address.  This depends on the application and the desire of the
   answerer.  The answerer includes a port and possibly an address when
   it requires to receive Tokens in RTCP messages.  If it only supports
   this specification but does not need Tokens to be included, the
   attribute is included without any port or address.

> From: Van Caenegem, Tom (Tom) [mailto:[email-masked]]
> Sent: Thursday, December 09, 2010 10:58 AM
> To: Magnus Westerlund; Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: RE: [AVT] Remaining issues in the Token draft
> 
> Hi Magnus,
> 
> The port mapping draft basically defines how  a unicast RTP session can be created without offer/answer, where instead
> there is indirect signaling of the port to be used for a new unicast session, by having the unicast RTP/RTCP destination port of
> the new session the same as the source port of the RTCP message in an existing RTP session that triggered this new RTP
> session. We explicitly have that the existing RTP session is a multicast session.
> 
> Is the offer/answer model you propose to be applied to the RAMS case as well where there is a multicast session, and unicast
> sessions are created as defined in the port mapping draft?
> 
> I guess it goes beyond that,  as from your proposed text, I can see that both sender and receiver may indicate they want to
> receive tokens from the other peer.  Your text mainly is about token usage, but I guess there are  also implications on the
> ports to be used. Could that be in contradiction with other (port) signaling in the offer/answer SDP signaling?
> 
> For RAMS we mandate support for this port mapping solution (including the token security measures). Can you elaborate
> (based on your use case) when or when not it would be required/recommended to use the port mapping mechanism when
> using offer/answer?
> 
> Thx
> Tom
> 
> 
> >> 1- O/A model for the 'portmapping-req' attribute. Magnus thinks we should define this but I am still not clear how to do
> this or why we are doing it. I will ask Magnus for help (or simply for the text).
> >>
> (draft-06) as new paragraph after the currently last one. This is also written from the perspective that the portmapping-req
> attribute will be included in the session where the actual RTCP messages are declared.
> 
> If included on session level this applies to all media lines that uses RTP. If included on media level, it applies to the RTCP
> feedback messages declared by this media block.
> 
> An offerer that desires the answerer to use tokens in any RTCP message sent to the offerer, i.e. received by the offerer, the
> attribute is included. In case an offerer desires to declare support for using tokens as defined in this specification but don't
> need tokens to be included for any RTCP messages received by the offerer it can include the portmapping-req attribute
> without any parameters, neither port nor address, either on session or media level.
> 
> An answerer receiving an SDP offer with a=portmapping-req with a port nunber shall use that port number and the address,
> either explicitly provided in the attribute or implicitly provided by the c= line, for any needed token request. If the
> a=portmapping-req attribute does not contain a port, the answer shall take note of the capability.
> 
> When sending an answer, and the portmapping-req attribute has been present in the answer including a port number and
> the answer support this specification, then the Answer MUST include the attribute in its answer. The answer may or may not
> include a port and address. This depends on the application and the desire of the answer. The answerer include a port and
> possibly and address when it want to receive tokens in any RTCP message creating an unicast session. If it only supports this
> specification but don't need tokens to be include the attribute is included without any port.
> 
> 
>

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 9 Dec 2010 20:40:00 +0100

..not really, as I just see a copy of the initial proposed text below.
 
Note that I am not against this, I just miss some background here.. Some answers to my questions would be useful..
Tom 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: donderdag 9 december 2010 17:58
To: Van Caenegem, Tom (Tom); Magnus Westerlund
Cc: [email-masked]
Subject: RE: [AVT] Remaining issues in the Token draft

-acbegen

> From: Van Caenegem, Tom (Tom) 
> [mailto:[email-masked]]
> The port mapping draft basically defines how  a unicast RTP session 
> can be created without offer/answer, where instead there is indirect 
> signaling of the port to be used for a new unicast session, by having 
> the unicast RTP/RTCP destination port of the new session the same as the source port of the RTCP message in an existing RTP session that triggered this new RTP session. We explicitly have that the existing RTP session is a multicast session.
> 
> The draft does also include security measures to make this method 
> secure against certain DoS attackes, and hence defines tokens, token port, messages etc..
> 
> Is the offer/answer model you propose to be applied to the RAMS case 
> as well where there is a multicast session, and unicast sessions are created as defined in the port mapping draft?
> 
> I guess it goes beyond that,  as from your proposed text, I can see 
> that both sender and receiver may indicate they want to receive tokens 
> from the other peer.  Your text mainly is about token usage, but I guess there are  also implications on the ports to be used. Could that be in contradiction with other (port) signaling in the offer/answer SDP signaling?
> 
> For RAMS we mandate support for this port mapping solution (including 
> the token security measures). Can you elaborate (based on your use 
> case) when or when not it would be required/recommended to use the port mapping mechanism when using offer/answer?
> 
> Thx
> Tom
> 
> 
> >> https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mca
> >> st
> >> -rtp/
> >>
> >> 1- O/A model for the 'portmapping-req' attribute. Magnus thinks we 
> >> should define this but I am still not clear how to do
> > I am willing to contribute text for this. I will do that next week. 
> > I don't have time to do that today. And I don't see this as complex, 
> written from the perspective that the portmapping-req attribute will be included in the session where the actual RTCP messages are declared.
> 
> RTP. If included on media level, it applies to the RTCP feedback messages declared by this media block.
> 
> included. In case an offerer desires to declare support for using 
> tokens as defined in this specification but don't need tokens to be included for any RTCP messages received by the offerer it can include the portmapping-req attribute without any parameters, neither port nor address, either on session or media level.
> 
> provided in the attribute or implicitly provided by the c= line, for any needed token request. If the a=portmapping-req attribute does not contain a port, the answer shall take note of the capability.
> 
> depends on the application and the desire of the answer. The answerer include a port and possibly and address when it want to receive tokens in any RTCP message creating an unicast session. If it only supports this specification but don't need tokens to be include the attribute is included without any port.
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Dec 2010 10:09:49 +0100

> The port mapping draft basically defines how  a unicast RTP session can be created without offer/answer, where instead there is indirect signaling of the port to be used for a new unicast session,…

The use case I consider is when you use SIP and offer/answer to invite
someone into a multicasted session. Potentially combined with additional
media streams going between the inviter and the invitee.

Thus the media streams related to the multicast and its unicast system
is coming from a media provider. And you aren't performing offer/answer
between the media provider and the invitee. The O/A media negotiation
goes between the inviter and the invitee. Thus you will need the token
solution for some users.

I see token being part of security solutions for a number of these
invitation into existing multi-party sessions.

> I guess it goes beyond that,  as from your proposed text, I can see that both sender and receiver may indicate they want to receive tokens from the other peer.  Your text mainly is about token usag…

as the a=portmapping-req attribute is about the port and address for
where to do the port mapping request and the support for port mapping in
general. Thus the port where the media and RTCP is going to be sent in
relation to the particular media stream is done in method. Thus one can
clearly negotiate these or use a declarative method depending on ones
use case.

> For RAMS we mandate support for this port mapping solution (including the token security measures). Can you elaborate (based on your use case) when or when not it would be required/recommended to u…

As I said above, if one invite a multicast based service into a point to
point session you get these interesting combination cases.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Dec 2010 10:28:50 +0100

>                                 addrtype space connection-address]] CRLF

Actually the above ABNF is broken, it is missing a SPACE separator in
one places. An attempt to fix this is:

portmapping-req-attribute = "a=portmapping-req:" [port [SP nettype SP
                               addrtype SP connection-address]] CRLF

SP = space is defined in RFC 5234

>    message sent to the offerer, i.e., received by the offerer, the

 isn't there a comma to much after i.e.?

>    attribute is included without any port or address.

Otherwise it looks good enough on the general matter. I will continue
discuss the question of explicit indication for which messages that
needs to include tokens.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 10 Dec 2010 04:51:45 -0800

> SP = space is defined in RFC 5234

Right, thanks for catching.
 
...
>  isn't there a comma to much after i.e.?

AFAIK, it is required. RFC editor also uses it if I am not mistaken.
http://hubpages.com/hub/Grammar_Mishaps__ie_ve_eg

Cheers,
-acbegen