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

[Magnus Westerlund <[e-mail]>]

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.

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



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

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

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

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