Re: [MMUSIC] Offer/Answer PT Questions - text proposal

[Jonathan Lennox <[e-mail]>]

> On Mar 2, 2016, at 5:24 PM, Paul Kyzivat <[e-mail]> wrote:
> 
> On 3/2/16 5:05 PM, Colin Perkins wrote:
>> 
>>> On 1 Mar 2016, at 19:32, Paul Kyzivat <[e-mail]> wrote:
>>> 
>>> *If* it is really the case that there is no relationship between O/A and the lifetime of RTP sessions, then we have some work to do to sort out what the relationship is between what is in the O/A and what is in the RTP session.
>>> 
>>> IIUC, in the case where the is no RTP session prior an offer, the O/A must at least establish some initial PT bindings for the session-to-be.
>>> 
>>> (I have a feeling that what we are discussing is quite fundamental, and I find it shocking if it hasn't been considered in the past.)
>>> 
>>> Colin - your insight would be helpful here.
>> 
>> I don’t have good insights here. I’ve long had the impression there are conflicts between the o/a rules and the RTP rules, but I’m insufficiently familiar with o/a to identify or resolve them.
> 
> And I have begun to suspect those conflicts too, but I’m insufficiently familiar with *rtp* to identify or resolve them.
> 
> I guess we need to find somebody fluent in both, or else keep talking till we understand each other. Maybe Roman fits the bill. I suspect that Jonathan Lennox does, but he seems to have been quiet recently, so I suspect he is busy.

Hi — yes, I’ve been fairly busy, but I’ll try to respond.

RTP (in its full RFC 3550 generality) and SDP Offer/Answer certainly do have conflicts.  Basically, the problem is that offer/answer assumes that each end of a negotiation specifies its own view of a session, with fairly wide latitude to specify its own preferences, whereas RTP assumes a single session view shared by all participants.

As a consequence of this, there are a number of RTP topologies that can’t be negotiated through SDP Offer/Answer, unless both sides of the negotiation know (through some out-of-band means) that that’s what they’re trying to do.

I wrote a draft back in 2012 on the topic — draft-lennox-avtcore-rtp-topo-offer-answer-00 — with the intention of indicating that RTP should relax some of its constraints for offer/answer-only use cases, but I don’t think I convinced anybody.  Nonetheless, the draft is still probably useful for pointing out some of the mismatches between the two models.

Other than the PT negotiation problem, already discussed, the other major issue is bandwidth.  Offer/Answer lets each side set its bandwidth independently, but RTP assumes a single global session bandwidth.  In particular, RTCP member timeouts are based on the RTCP bandwidth, and it’s not clear how these should be computed when session bandwidths are asymmetric.

(I don’t think this last point is a flaw in Offer/Answer — asymmetric bandwidths are a very common real-world use case which need to be supported.  Instead, I think this is something that RTP needs to figure out.  This will become even more relevant as RMCAT-type bandwidth discovery mechanisms mean that the endpoints have no a priori way of knowing even the order of magnitude of available bandwidth to expect.)