Re: [AVT] Remaining issues in the Token draft

..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:abegen@cisco.com] 
Sent: donderdag 9 december 2010 17:58
To: Van Caenegem, Tom (Tom); Magnus Westerlund
Cc: avt@ietf.org
Subject: RE: [AVT] Remaining issues in the Token draft

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:

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

   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.

> -----Original Message-----
> From: Van Caenegem, Tom (Tom) 
> [mailto:tom.van_caenegem@alcatel-lucent.com]
> Sent: Thursday, December 09, 2010 10:58 AM
> To: Magnus Westerlund; Ali C. Begen (abegen)
> Cc: avt@ietf.org
> Subject: RE: [AVT] Remaining issues in the Token draft
> 
> 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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of 
> Magnus Westerlund
> Sent: donderdag 9 december 2010 14:40
> To: Ali C. Begen (abegen)
> Cc: avt@ietf.org
> Subject: Re: [AVT] Remaining issues in the Token draft
> 
> Magnus Westerlund skrev 2010-12-03 13:28:
> > Ali C. Begen (abegen) skrev 2010-12-03 04:29:
> >> 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-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
> this or why we are doing it. I will ask Magnus for help (or simply for the text).
> >>
> > 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.
> 
> 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
> 
> ----------------------------------------------------------------------
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt