[SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here

[Richard Fuchs]

On 02/20/14 04:15, Mihai Marin wrote:
> Hello Sirs, Sir Richard,
> I understand the problem but I don't understand the behavior. Let me
> tell you how I understood the problem and where I misunderstand the
> behavior.
> 
> BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) -
> Kamailio - MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows
> that bob request rtcp-mux but ignore it by removing "a=rtcp-mux" line
> from SDP and add 2 ICE Candidates with different ports .
> ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC
> (alice) - Kamailio - MP-NG  - Kamailio - UAS (bob). From the offer,
> MP-NG knows that bob accept rtcp-mux, ignore it first time, but still
> accept alice's answer with rtcp-mux (accepting the RTP and RTCP
> multiplexing) - offering rtcp-mux in response (answer).
> 
> First, I don't understand why is not working :).  Offer received by
> alice does not contain rtcp-mux and has 2 ICE Candidates with different
> ports and the answer contains a=rtcp-mux and has 1 ICE Candidates for
> bundle.

Let me try to put it in a more concise way then.

Bob is calling Alice. Bob is offering to Alice, and Alice is answering
to Bob.

Bob's point of view: Bob offers rtcp-mux. He also includes ICE
candidates for RTCP as fallback, as required. Bob receives an answer
accepting rtcp-mux. Thus, Bob will talk rtcp-mux and as such, the answer
must not include separate ICE candidates for RTCP.

Alice's point of view: Alice receives offer without rtcp-mux. Since
rtcp-mux wasn't offered, it can't be negotiated nor offered nor
accepted. Alice therefore allocates a separate port for RTCP and
includes separate ICE candidates for RTCP, as required.

Mediaproxy's point of view: Bob offers rtcp-mux and mediaproxy accepts
it in its answer. Thus, Bob will talk rtcp-mux and therefore mediaproxy
won't include a separate ICE candidate for RTCP, as required.

The problem is that Alice doesn't know that Bob talks rtcp-mux, only
mediaproxy knows. Alice therefore includes separate ICE candidates for
RTCP, while mediaproxy doesn't. Bob now sees separate ICE candidates for
RTCP coming from Alice, although Bob is talking rtcp-mux and so those
shouldn't be there.

> Another question is why MP-NG does not offer rtcp-mux event is it knows
> from the original SDP that rtcp-mux is prefered, at least for the "no +"
> case? Can't we put a rule like: ok, if we want "no + case" - decision
> moved to client side - and original SDP has a=rtcp-mux we generate
> candidates according to that. Why changing client preferences when
> switching to "no + - client decision"?

The reason is that not all RTP clients support rtcp-mux and since
mediaproxy has no real benefit from muxing RTCP, the chances of
establishing media flow are higher if rtcp-mux is left out. To the
offering client, it normally makes no difference (Bob sees his rtcp-mux
offer accepted, as required by WebRTC, so all is good) and we are
conservative with what we're sending to the answering client. You never
know what a client which doesn't understand rtcp-mux will do...

If mediaproxy knew that the answering client is also WebRTC, then it
would be safe to include rtcp-mux in the offer. But, it doesn't know that.

As mentioned earlier, the fact that this causes problems when ICE
candidates are only inserted and not deleted is something that hasn't
occurred to me before (mediaproxy's design is primarily based on it
being used to unconditionally proxy the media, and not to merely serve
as a fallback). I can envision something like an "rtcp-mux pass-through"
mode, where mediaproxy's offering and answering of rtcp-mux depends on
what the other client does. This is something that still needs to be
implemented though.

I'm not sure what the default mode of operation ought to be: should the
default be to always try to demux RTCP unless specified otherwise, or
should the default be to go along with what the clients do unless demux
is specifically requested? Any opinions on this?

cheers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140220/7a4137c2/attachment-0001.pgp>