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

[Mihai Marin]

Hello Sirs, Sir Richard,
Thank you for your detailed explication.
I'm still thinking on that but I would say to act as the caller and keep
caller decision. If caller makes an offer with rtcp-mux , include separate
ICE candidates for RTCP for media proxy too and forward as it is to alice.
If callee accept it (or not) you will receive the OK with alice sdp, modify
it (depending on her choices) and forward to bob. In this way, we cover all
the cases. Eventually we can add another parameter to always ignore
rtcp-mux offers.

What are the disadvantages on doing that? Is there any possibility that
some SIP clients not to respond properly to an SDP with rtcp-mux and that's
why you are removing it - or for '+' case where delay will be added?

Thank you for sharing it with me and again, sorry if
I misunderstood something.

Have a nice weekend.

Best regards,
Mihai M



On Thu, Feb 20, 2014 at 2:44 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> 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
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140222/6185afe0/attachment.html>