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

[Flemming Andreasen <[e-mail]>]

Magnus Westerlund wrote:
> Hi,
>
> See comments inline.
>
> Flemming Andreasen skrev:
>>
>>
>> Magnus Westerlund wrote:
>>> 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.
>> Thanks for taking the time to read the document Magnus - responses 
>> below.
>>>
>>> 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. 
>> 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.
>
> Yes. Sorry for mixing up the language.
>
>>> 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  ?
>
> Well, you can use the payload format in AVP but then you lack the NACK 
> format to request any retransmissions with.
>
>  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.
>
> 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.
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.


>>
>> 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.
>>
>
>
> 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'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) ?

>>> 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.
>
>
>> 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.
>
> 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.
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).

>
>>>
>>> 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.
>>>
>>> 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'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.
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.

>>> 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.
>>
>
>
> Agreed, lets discuss the general issues. To me it is a choice between 
> 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

>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>

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