Subject: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP payload types

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jul 2007 19:12:50 +0200

Hi,

I have finally read the SDP capapbility draft in sufficient detail to 
think I understand it mostly. There is likely some details that I have 
gotten wrong. But I have found some issues that I need to raise for 
discussion. I will split this into separate emails for each topic.

I think the handling of the transport capabilites have to little 
functionality. There is need for specifying which RTP payload types that 
apply to which transport capabilities. I will list some usages of this 
that doesn't seem to work correctly without it or bloody ugly hacks.

1. Usage of RTP retransmission (RFC 4588) using payload type 
multiplexing. In this case the RTP retransmission payload only can be 
used in cases when the session uses a profile that has AVPF 
functionality. If one offers both AVP and AVPF with CAPNEG then one gets 
at least one additional RTP payload type for the AVPF cases.

2. Usage of paylaod types that only make sense over particular 
transport. For example if one requires RTP/AVP/TCP for a particular 
paylaod type to be usable due to reliability requirements.

As I see it this can be only solved by what I consider a hack. Which is 
to overdefine a number of payload types that one doesn't intended to use 
to provide sufficient number for other potential configurations. And I 
think you need to define them, because leaving them undefined would to 
me be against current SDP rules.

I think this is a hack for several reasons.

A. It doesn't clearly define which payload types that are intended to be 
used in a specific transport.

B. It forces one to overwrite the RTP payload types, always. Despite the 
issues with media delivery prior to receiving answer or having performed 
the second round of offer/answer

C. It prevents this mechanism to in the future be upgraded in a 
reasonable way with media cability negotiation. See separate email for 
discussion.

I would recommend that one seriously consider using explicit declaration 
of the payload type used for each transport in the tcap attribute.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 20 Jul 2007 12:24:35 +0200

Magnus,

I really appreciate your comment
If I recall correctly, the design team reached consensus that the
negotiation for attribute in the core spec 
provides a poor man's media capability negotiation. 
It was not the goal to cover all corner case.
Nevertheless your comment points to an oversight for the a=tcap
attribute. 
More inline.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Thursday, July 19, 2007 7:13 PM
> To: mmusic (E-mail)
> Subject: [MMUSIC] SDPCapNeg-06: Transport capabilites and RTP 
> payload types
> 
> Hi,
> 

If I understand correctly you want to be able to negotiate 
an offer for the actual configuration (RTP/AVP, one payload type)
           v=0
           o=- 25678 753849 IN IP4 192.0.2.1
           s=
           c=IN IP4 192.0.2.1
           t=0 0
-->        m=video 49170 RTP/AVP 96                  <-- one PT
           a=rtpmap:96 MP4V-ES/90000
           a=fmtp:96 profile-level-id=8; /
              config=01010000012000884006682C2090A21F
and for the potential configuration (RTP/AVPF, two payload types)
           v=0
           o=- 25678 753849 IN IP4 192.0.2.1
           s=
           c=IN IP4 192.0.2.1
           t=0 0
-->        m=video 49170 RTP/AVPF 96 97              <-- two PTs
           a=fmtp:96 profile-level-id=8; /
              config=01010000012000884006682C2090A21F
           a=rtcp-fb:96 nack
           a=rtpmap:97 rtx/90000
           a=fmtp:97 apt=96;rtx-time=3000

and the core spec does not provide for using a different number of PTs
in the actual/potential configurations.

> paylaod type to be usable due to reliability requirements.

yes, this can result in a similar problem as above.

> reasonable way with media cability negotiation. See separate 

I see the extensibily problem differently.
As a first step the core spec should disallow different numbers of PTs
and 
the media capability negotiation should cope with it. 

> of the payload type used for each transport in the tcap attribute.

As the media capability negotiation already extends the definition of
the a=pcfg attribute,
it could also e.g. extend the a=tcap attribute to allow for inclusion of
payload types as you propose.
However, the ABNF for a=tcap does currently not allow for extensibility.

My proposal would be to provide for such extensibility in the core and
tackle the problem within 
the media capability negotiation.

Regards
Thomas

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 11:38:27 -0400

> discussion. I will split this into separate emails for each topic.
Thanks for taking the time to read the document Magnus - responses below.
> functionality. There is need for specifying which RTP payload types 
> that apply to which transport capabilities. I will list some usages of 
> this that doesn't seem to work correctly without it or bloody ugly hacks.
>
> multiplexing. 
I assume you mean when using session-multiplexing as opposed to
SSRC-multiplexing and hence the issue here is one of requiring
syncrhonized O/A operation over multiple streams.
> In this case the RTP retransmission payload only can be used in cases 
> when the session uses a profile that has AVPF functionality. If one 
> offers both AVP and AVPF with CAPNEG then one gets at least one 
> additional RTP payload type for the AVPF cases.
Can RFC 4588 only be used under AVPF profiles  ? Regardless, I
understand your point, that there are cases where you would like to have
this syncrhonized O/A operation. As mentioned above, SSRC-multiplexing
works, and if you can do RFC 4588 today, then presumably you have
implemented some logic on top of the "pure" O/A procedures to ensure
that you do not accept the redundant stream without the primary stream
being accepted itself. Also, since there is SSRC and payload type
synchronization between the two streams, there is clearly more going on
here than pure per-media stream only O/A procedures. Based on that, I'm
not sure we in practice get into any new scenarios here; you already
have logic in place to accept only potential configuration SDPs that
adhere to the principles effectively required by RFC 4588.

Taking a step back, the question however is whether this type of
functionality should be in scope of the core capabilities negotiation
document or not. We only have "per media stream" requirements in the
requirements document
(draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt).
Furthermore, the "media format negotiation" requirement (REQ-10) as well
as the inter-media stream requirements are (REQ-150 and REQ-160) are all
listed as enchancements, and hence would be covered by an extension
rather than the core. This (fairly reduced) scope was the result of a
lot of discusions and consideration to people that are primarily
interested in addressing the pure transport protocol problem and hence
did not want an overly complicated solution.  I think your comment here
is that you disagree with these requirements, but I think it's a little
late for that and also does not align with the general consensus so far.

> As I see it this can be only solved by what I consider a hack. Which 
> is to overdefine a number of payload types that one doesn't intended 
> to use to provide sufficient number for other potential 
> configurations. And I think you need to define them, because leaving 
> them undefined would to me be against current SDP rules.
>
> A. It doesn't clearly define which payload types that are intended to 
> be used in a specific transport.
That's not an issue with the capability negotiation framework. The
potential configuration, which references capabilities by use of their
capability numbers would be used for this.
>
> B. It forces one to overwrite the RTP payload types, always. Despite 
> the issues with media delivery prior to receiving answer or having 
> performed the second round of offer/answer
Right. I agree that in order to properly address this, you need an
extension.
> reasonable way with media cability negotiation. See separate email for 
I'll have a look - I currently don't see the issue.
>
> I would recommend that one seriously consider using explicit 
> declaration of the payload type used for each transport in the tcap 
> attribute.
>
Your comment could be addressed in many different ways, however we
should probably agree on whether we want to address it in the core
document first, before getting into the actual solution.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 11:42:58 -0400

> As a first step the core spec should disallow different numbers of PTs
I'm not sure what that would actually mean - can you elaborate ?
>> declaration 
> My proposal would be to provide for such extensibility in the core
I'm somewhat reluctant to doing that. The extensibility would need to be 
provided in a way where we have clearly defined rules for what to do if 
you don't support the extentions, don't get into parsing ambiguities, 
etc. The current format doesn't seem well-suited for that, and we'd 
clearly need added procedures. However, we already have an extension 
mechanism defined which would allow you define another kind of 
"transport protocol + payload type" configuration parameter if needed 
(my preference would be actually use capability numbers for such a 
thing, but that's a separate point).

> the media capability negotiation.
Agree the problem should be tackled there.

-- Flemming

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 23 Jul 2007 20:24:09 +0200

Flemming,
 
inline

	  < snip>  

		
		I see the extensibily problem differently.
		As a first step the core spec should disallow different
numbers of PTs

	[Stach Thomas] What I mean is that the scope of the core spec
does not include the scenario mentioned by Magnus. In order to
discourage people
	to implement the hack that Magnus mentioned, some guidance could
be given in the core spec. 
	That should refer people to the media capability  negotiation,
if they want to tackle scenarios where different numbers of payload
types (or m-lines) appear in actual and potential configurations.

		and 

			I would recommend that one seriously consider
using explicit 
			declaration 
			of the payload type used for each transport in
the tcap attribute.

		As the media capability negotiation already extends the
definition of
		the a=pcfg attribute,
		it could also e.g. extend the a=tcap attribute to allow
for inclusion of
		payload types as you propose.
		However, the ABNF for a=tcap does currently not allow
for extensibility.
		
		My proposal would be to provide for such extensibility
in the core

	I'm somewhat reluctant to doing that. The extensibility would
need to be provided in a way where we have clearly defined rules for
what to do if you don't support the extentions, don't get into parsing
ambiguities, etc. The current format doesn't seem well-suited for that,
and we'd clearly need added procedures. However, we already have an
extension mechanism defined which would allow you define another kind of
"transport protocol + payload type" configuration parameter if needed
(my preference would be actually use capability numbers for such a
thing, but that's a separate point). 
	[Stach Thomas] Shortly after writing my comment, I came to the
same conclusion that the already defined extension mechanisn could serve
the same purpose.
	Extensibility of the tcap attribute is not necessary.
	 
	Regards
	Thomas  

		 and

	-- Flemming 

		Regards
		Thomas

			Cheers
			
			Magnus Westerlund

----------------------------------------------------------------------
			Multimedia Technologies, Ericsson Research
EAB/TVM/M
	
----------------------------------------------------------------------
			Ericsson AB                | Phone +46 8 4048287
			Torshamsgatan 23           | Fax   +46 8 7575550
			S-164 80 Stockholm, Sweden | mailto:
[email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 14:32:55 -0400

Stach, Thomas wrote:
>     [Stach Thomas] What I mean is that the scope of the core spec does
>     not include the scenario mentioned by Magnus. In order to
>     discourage people
>     That should refer people to the media capability  negotiation, if
>     they want to tackle scenarios where different numbers of payload
As long as we can do that with a "for example" reference and hence have 
it as an informative reference, I'm fine with that.
>     I'm somewhat reluctant to doing that. The extensibility would need
>     to be provided in a way where we have clearly defined rules for
>     what to do if you don't support the extentions, don't get into
>     parsing ambiguities, etc. The current format doesn't seem
>     well-suited for that, and we'd clearly need added procedures.
>     However, we already have an extension mechanism defined which
>     would allow you define another kind of "transport protocol +
>     payload type" configuration parameter if needed (my preference
>     would be actually use capability numbers for such a thing, but
>     that's a separate point).
>     same conclusion that the already defined extension mechanisn could
>     serve the same purpose.
Sounds good.

Thanks

-- Flemming

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jul 2007 20:51:43 +0200

Hi,

See comments inline.

> syncrhonized O/A operation over multiple streams.

Yes. Sorry for mixing up the language.

> Can RFC 4588 only be used under AVPF profiles  ?

Well, you can use the payload format in AVP but then you lack the NACK 
format to request any retransmissions with.

  Regardless, I
> adhere to the principles effectively required by RFC 4588.

However, that uses grouping of media lines. An without a reasonable 
support of grouping of media lines for potential configuration that will 
not work. Thus, as I see it this is a problem.

> late for that and also does not align with the general consensus so far.

I can understand that you don't want to change the requirements and I 
accept that. However, as I see it you are ready to restrict applications 
to use functionalities that actually the reason for deploying the 
transport negotiation capability. To me it seems that you are arguing 
that the only valid transport negotiation usage that needs to work is 
SRTP. I don't think it is reasonable to disregard solutions that uses 
AVPF from using this mechanism to determine if one can or cannot use for 
example retransmission.

> capability numbers would be used for this.

I think you are missunderstanding my point, or I am completely 
missunderstanding you. My point is that you have different payload types 
for different potential configuration using different transport 
alternatives. For clarity it should be explicit which transport 
alterantives uses which payload type numbers. Instead of forcing one to 
declare a number of payload types that aren't intended to be used, but 
still negotiated.

> I'll have a look - I currently don't see the issue.

The issue I see is that any extension would have to replace the 
transport alternatives with a totally new mechanism. Thus making the 
upgrade path very hard as you need to do a required supported mechanism, 
rather than a optional one for media capability negotiation.

> document first, before getting into the actual solution.

Agreed, lets discuss the general issues. To me it is a choice between 
doing work and complicate the solution, or cripple the functionality.

Cheers

Magnus Westerlund

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 23 Jul 2007 20:53:12 +0200

Flemming,
		 
		inline

			  < snip>  

				
				I see the extensibily problem
differently.
				As a first step the core spec should
disallow different numbers of PTs

			I'm not sure what that would actually mean - can
you elaborate ? 
			[Stach Thomas] What I mean is that the scope of
the core spec does not include the scenario mentioned by Magnus. In
order to discourage people
			to implement the hack that Magnus mentioned,
some guidance could be given in the core spec. 
			That should refer people to the media capability
negotiation, if they want to tackle scenarios where different numbers of
payload types (or m-lines) appear in actual and potential
configurations.

	As long as we can do that with a "for example" reference and
hence have it as an informative reference, I'm fine with that. 
	[Stach Thomas] Sure, or if you want to avoid even the
informative reference, I could live as well with referring people to an
unnamed extension of the core spec.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 15:28:49 -0400

Magnus Westerlund wrote:
>>> I have finally read the SDP capapbility draft in sufficient detail 
>>> to think I understand it mostly. There is likely some details that I 
>>> have gotten wrong. But I have found some issues that I need to raise 
>>> for discussion. I will split this into separate emails for each topic.
>>> that apply to which transport capabilities. I will list some usages 
>>> of this that doesn't seem to work correctly without it or bloody 
>>> ugly hacks.
>>>
>>> In this case the RTP retransmission payload only can be used in 
>>> cases when the session uses a profile that has AVPF functionality. 
>>> If one offers both AVP and AVPF with CAPNEG then one gets at least 
>>> one additional RTP payload type for the AVPF cases.
> support of grouping of media lines for potential configuration that 
> will not work. Thus, as I see it this is a problem.
Actually, I believe this particular scenario is supported as well as 
with RFC 4588 itself. You can define a session level "a=group:FID" 
attribute capability which is only used by the potential configuration 
for the AVPF transport protocol. The per-media stream "mid" attributes 
can always be added to the actual configuration.

> accept that. However, as I see it you are ready to restrict 
> applications to use functionalities that actually the reason for 
> deploying the transport negotiation capability. To me it seems that 
> you are arguing that the only valid transport negotiation usage that 
> needs to work is SRTP.
I'm not. What I am saying however is that there has been significant 
pushback on complicating the core and including functionality that is 
not needed for the SRTP crowd. At the same time, it is also agreed that 
we want a general and extensible solution that can be used to address 
other capability negotiation problems (like the ones you bring up). It's 
not an easy balancing act...
> I don't think it is reasonable to disregard solutions that uses AVPF 
> from using this mechanism to determine if one can or cannot use for 
> example retransmission.
Per the above, I think that scenario actually works without any 
extensions. Are there other specific scenarios you are concerned about 
in the core (e.g. it would be helpful if you can identify scenarios that 
absolutely MUST be supported by the core) ?

>>> A. It doesn't clearly define which payload types that are intended 
>>> to be used in a specific transport.
>
>
> missunderstanding you. My point is that you have different payload 
> types for different potential configuration using different transport 
> alterantives uses which payload type numbers. Instead of forcing one 
> to declare a number of payload types that aren't intended to be used, 
> but still negotiated.
We agree (I think) that a payload type mapping neither is nor should be 
a capability. Support for a particular media format with a specific set 
of parameters however is. Mapping such media formats and their 
associated parameters to a particular payload type is something that 
falls under the realm of a configuration (IMO). Where we differ is on 
whether those features need to provided by the core document or if they 
can be provided by an extension. So far, the consensus has been to 
provide them as extensions (but again, under the assumption that 
extensions that fit within the framework actually can be defined).

>>> reasonable way with media cability negotiation. See separate email 
>>> for discussion.
>
> upgrade path very hard as you need to do a required supported 
> mechanism, rather than a optional one for media capability negotiation.
We are back to discussing scope of the core document and I'm not sure 
how to address that except to note what consensus has been so far and 
we'll probably need additional input on this.

> doing work and complicate the solution, or cripple the functionality.
I don't think we are crippling functionality, but there is clearly 
additional work needed to address some of your requirements.

-- Flemming

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Jul 2007 23:18:44 +0200

Hi,

I had actually missed one of the issues of not providing the FMT strings 
from the m= line. This has to do with how the format string is defined. 
I think one has primarily thought about RTP and different profiles that 
all have the same definition of the FMT part of the m= line. But there 
exist a number of SDP using protocol that doesn't use a list of RTP 
payload type numbers in this field. Some contains only "*" such as MSRP 
or FLUTE, others contain text strings. An example is the UDPTL transport 
for T.38.

Thus clearly, so far one can't handle any case when transport 
alterernatives are not having a common FMT string definition.

Cheers

Magnus Westerlund

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Jul 2007 17:27:55 -0400

Magnus Westerlund wrote:
> Hi,
>
> I had actually missed one of the issues of not providing the FMT 
> strings from the m= line. This has to do with how the format string is 
> defined. I think one has primarily thought about RTP and different 
> profiles that all have the same definition of the FMT part of the m= 
> line. But there exist a number of SDP using protocol that doesn't use 
> a list of RTP payload type numbers in this field. Some contains only 
> "*" such as MSRP or FLUTE, others contain text strings. An example is 
> the UDPTL transport for T.38.
>
Agreed. Again, I'll go back to the requirements where we don't have 
media format negotiation in scope in the core (nor combinations of media 
format and transport protocol) - these are left for an extension currently.

-- Flemming