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

[Flemming Andreasen <[e-mail]>]

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

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


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

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