Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 17:57:07 +0100

Hi,

I think the change for the SDP attributes "portmapping" and
"portmapping-req" was an improvement. However, I think the semantics and
usage of these SDP Attributes needs clarification.

Lets start with "portmapping", currently it seems vague and not match
the generalize requirements needed. The current semantics appears to be:
Include in the multicast m= block which in relation there might be need
for token verification request. For example if one looks at Section
4.3.1 where BYE messages related to RAMS bursts may need tokens. That is
within the unicast session created if I understand correctly. Thus there
is no indication in this media block. Only in the Multicast session
block. This appears to be rather fuzzy and unclear.

I would like to resuggest the semantics I was considering before:

The "portmapping" attribute SHALL be included in any SDP media block
(m=) that define an RTP session that require the usage of token
verification requests for one or more RTCP message.

Then I frankly have to say that I don't grasp what the semantics are
related to the placement of the "portmapping-req" attribute. Yes, it
conveys the port and possibly address for where to send the Mapping
request. But what is the meaning of its placement on a particular media
block? Why is it placed in unicast blocks? Even if no Token is required
in this RTP session?

To me it appears that this attribute would be better served by becoming
an Session + possibly override in media blocks. At session level it
would server as the port mapping port and possibly address, unless c= at
session level is unicast to the mapping server, that is used for all
tokens used in the RTP sessions indicated by the "portmapping"
attribute. Then it may be included at media level in an media block
containing a=portmapping to override this port and address within that
particular media block.

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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Jan 2011 10:33:05 -0800

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, January 14, 2011 5:57 PM
> To: IETF AVT WG; [email-masked]
> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics
> 
> Hi,
> 

There is indication in the unicast block.

a=portmapping-req:30000

> verification requests for one or more RTCP message.

We discussed this at length in the call and the group decided to propose what we have in the draft now. Your proposal, repeating the same attribute in two blocks, is actually worse, and even more confusing.
 
> block? Why is it placed in unicast blocks? Even if no Token is required

I don’t know what else to add on top of what I have written before. 
 
> containing a=portmapping to override this port and address within that

We decided to have both attributes media-level only. Session-level attributes created a lot of corner cases and confusion, some of which was raised by Roni. 

Overall, I think the current SDP stuff works just fine.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 11:58:50 +0100

> We discussed this at length in the call and the group decided to propose what we have in the draft now. Your proposal, repeating the same attribute in two blocks, is actually worse, and even more c…

Ok, can you then write down the exact semantics of the portmapping-req
and portmapping attribute? Because to me their semantics aren't clear.
And without clear semantics this is going to cause confusion when used
the next time.

> We decided to have both attributes media-level only. Session-level attributes created a lot of corner cases and confusion, some of which was raised by Roni. 

Fine, I can live with that.

> Overall, I think the current SDP stuff works just fine.

I disagree, because in cases where you need token verification requests
also in the unicast client to server RTCP leg C2->P4, then I don't
understand how that is separated from when it is only needed in C1->P3.
This as I don't understand the semantics of the SDP attributes.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 05:58:09 -0800

> And without clear semantics this is going to cause confusion when used

I am not sure what you are looking for in addition to what section 7 says.  they are used in pairs. portmapping is used in the multicast block and portmapping-req is used in the unicast block. Together they mean, certain rtcp messages will require the token. The portmapping-req will tell you where to get the token from. Any confusion or question here?
 
> also in the unicast client to server RTCP leg C2->P4, then I don't

The only thing that travels from c2->p4 is the receiver reports for the unicast session. How would you send a token verification request message on that path? The verification request message goes from c1 to p3.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 15:54:48 +0100

> I am not sure what you are looking for in addition to what section 7 says.  they are used in pairs. portmapping is used in the multicast block and portmapping-req is used in the unicast block. Toge…

I think the confusion is that I believe it will be cases where Token
Verification Requests are going to be need to be sent on C2->P4. If that
is the case one needs semantics to say that token may also be included
in RTCP message related to this session.

In addition the semantics for the portmapping-req that now is mandated
to be on the declaration of the unicast RTP session. If we take your
argument there is no need for token verification in that session. Thus,
can you please explain why it is part of that session declaration?

In my world there could be token verification messages in the RTCP for
the unicast session. However, the declaration of where the Token server
should then either be in all RTP sessions that uses Token Verification
Messages, or at session level and applies to all "portmapping".

> The only thing that travels from c2->p4 is the receiver reports for the unicast session. How would you send a token verification request message on that path? The verification request message goes…

Here we seem to disagree. If one looks at the list in section 4.3.1, i
think that this does contain messages where you would like to attach
token, such as BYE or CCM messages.

It might be me taking the generalized look on this specification. Then I
do see a need to make sure that it can be used in any RTP session where
indicated.

If the intention to not have any session level attribute, then I don't
understand why we have two SDP attributes, then only portmapping-req is
needed. And I think it should be defined as having the meaning. Shall be
included in the SDP media blocks that define an RTP session that needs
Token Verification messages. Which means that portmapping-req are needed
in the multicast m= block, not the unicast.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Jan 2011 05:29:39 -0800

> Sent: Monday, January 17, 2011 9:55 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG; [email-masked]
> Subject: Re: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics
> 
> > I am not sure what you are looking for in addition to what section 7 says.  they are used in pairs. portmapping is used in the
> multicast block and portmapping-req is used in the unicast block. Together they mean, certain rtcp messages will require the
> token. The portmapping-req will tell you where to get the token from. Any confusion or question here?
> 

Right, the messages that control the unicast session and that are sent in the unicast session (like BYE and CCM) need to be authenticated (as written in 4.3.1).
 
> Messages, or at session level and applies to all "portmapping".

Ok. I guess your concern is that the "portmapping" attribute is defined media level and used in multicast block, yet it means messages triggering or controlling the unicast session might need token authentication. Is this your concern?

I don't think we should define it as session level as I mentioned earlier, it opens other corner cases. So, let's see how we can address this while keeping it media level. 

I guess we have two options here. We either repeat the "portmapping" attribute in both blocks and keep the "portmapping-req:port" in the unicast block only, or repeat "portmapping-req:port" in both blocks and remove the "portmapping" altogether. The latter saves one line from the SDP.
  
BTW, the last part of the 3rd paragraph in section 7.1 needs to be changed to:

  ... (ii) the client MUST receive the
   unicast session's RTP and RTCP packets from the server on the port
   from which it sent the RTCP message triggering the unicast session.

(Removed "or controlling" since that would mean port c2).

...
> > The only thing that travels from c2->p4 is the receiver reports for the unicast session. How would you send a token
> verification request message on that path? The verification request message goes from c1 to p3.
> 

Correct.
 
> in the multicast m= block, not the unicast.

Does putting the attribute only in the mcast block resolve your concerns? I don't think so as it will not cover the unicast session for which the rtcp messages are sent for.
 
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 16:21:04 +0100

> Right, the messages that control the unicast session and that are sent in the unicast session (like BYE and CCM) need to be authenticated (as written in 4.3.1).

Yes,

> Ok. I guess your concern is that the "portmapping" attribute is defined media level and used in multicast block, yet it means messages triggering or controlling the unicast session might need token…

Yes, lets indicate in which RTP session where token verification request
truly are needed.

> I don't think we should define it as session level as I mentioned earlier, it opens other corner cases. So, let's see how we can address this while keeping it media level. 

Media level only is fine.

> I guess we have two options here. We either repeat the "portmapping" attribute in both blocks and keep the "portmapping-req:port" in the unicast block only, or repeat "portmapping-req:port" in both…

I would do the later. Keep portmapping-req and put it in all media
blocks that defines RTP session that uses Token Verification.

> (Removed "or controlling" since that would mean port c2).

Yes, I think you might have to explicit call out where the verification
failed message is sent from the server to the client for any
verification message sent from client at C2->P4.

> Does putting the attribute only in the mcast block resolve your concerns? I don't think so as it will not cover the unicast session for which the rtcp messages are sent for.

Correct, I want it the semantics of the attribute to be. In this RTP
session, there is need to use Token Verification for some RTCP messages.
And here is the server port and address where you can get a token.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 19 Jan 2011 07:32:47 -0800

OK, we will work on these changes and submit a revision after the chairs' go-ahead. I believe wglc ends today anyway.

Thanks again for the detailed review.
-acbegen

> Sent: Wednesday, January 19, 2011 10:21 AM
> > Ok. I guess your concern is that the "portmapping" attribute is defined media level and used in multicast block, yet it means
> messages triggering or controlling the unicast session might need token authentication. Is this your concern?
> 
> > I don't think we should define it as session level as I mentioned earlier, it opens other corner cases. So, let's see how we can
> address this while keeping it media level.
> 
> > I guess we have two options here. We either repeat the "portmapping" attribute in both blocks and keep the "portmapping-
> req:port" in the unicast block only, or repeat "portmapping-req:port" in both blocks and remove the "portmapping"
> altogether. The latter saves one line from the SDP.
> 
> > Does putting the attribute only in the mcast block resolve your concerns? I don't think so as it will not cover the unicast
> session for which the rtcp messages are sent for.
>