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

Thu Feb 20 10:15:14 CET 2014

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.
The most important part (for this problem) from RFC 5761 I think is the
following
5.1.3 <http://tools.ietf.org/html/rfc5761#section-5.1.3>. Interactions with
ICE

   It is common to use the Interactive Connectivity Establishment (ICE)
   [19 <http://tools.ietf.org/html/rfc5761#ref-19>] methodology to
establish RTP sessions in the presence of Network
   Address Translation (NAT) devices or other middleboxes.  If RTP and
   RTCP are sent on separate ports, the RTP media stream comprises two
   components in ICE (one for RTP and one for RTCP), with connectivity
   checks being performed for each component.  If RTP and RTCP are to be
   multiplexed on the same port some of these connectivity checks can be
   avoided, reducing the overhead of ICE.

   If it is desired to use both ICE and multiplexed RTP and RTCP, the
   initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
   RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
   lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
   fallback port for RTCP in the case that the answerer does not support
   RTP and RTCP multiplexing.  This MUST be done for each media where
   RTP and RTCP multiplexing is desired.

   If the answerer wishes to multiplex RTP and RTCP on a single port, it
   MUST generate an answer containing an "a=rtcp-mux" attribute and a
   single "a=candidate:" line corresponding to the RTP port (i.e., there
   is no candidate for RTCP) for each media where it is desired to use

     RTP and RTCP multiplexing.  The answerer then performs connectivity

   checks for that media as if the offer had contained only a single
   candidate for RTP.  If the answerer does not want to multiplex RTP
   and RTCP on a single port, it MUST NOT include the "a=rtcp-mux"
   attribute in its answer and MUST perform connectivity checks for all
   offered candidates in the usual manner.

   On receipt of the answer, the offerer looks for the presence of the
   "a=rtcp-mux" line for each media where multiplexing was offered.  If
   this is present, then connectivity checks proceed as if only a single
   candidate (for RTP) were offered, and multiplexing is used once the
   session is established.  If the "a=rtcp-mux" line is not present, the
   session proceeds with connectivity checks using both RTP and RTCP
   candidates, eventually leading to a session being established with
   RTP and RTCP on separate ports (as signalled by the "a=rtcp:"
   attribute).

My thought is that the cause why is not working in my example is that I'm
in a LAN (no restrictive network with friendly NAT) where TURN is not
needed and I have no a=rtcp-mux but 2 ICE STUN Candidates with the same
port.

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

I hope I don't say stupid things and sorry if I do that.

Thank you.

Best regards,
Mihai M

On Tue, Feb 18, 2014 at 6:43 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 02/18/14 11:12, Mihai Marin wrote:
> > Hello Sirs,
> > Thank you, one step forward but still buggy - half buggy :)
> >
> > Now, it's working just one way. If bob calls alice, alice will receive
> > video but bob won't. If I stop mediaproxy-ng process (without any other
> > modification) and redo the call, everything is just fine.
> >
> > The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA
> > The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
> >
> > I noticed something strange in those 2 SDPs (just audio candidates,
> > video are the same):
> > 1. offer
> > 1.a. stun candidates
> > a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx
> > raddr 192.168.0.5 rport 63015 generation 0
> > a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx
> > raddr 192.168.0.5 rport 63015 generation 0
> > 1.b. turn candidates
> > a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ
> host
> > a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ
> host
> >
> > 2. answer
> > 2.a. stun candidates
> > a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx
> > raddr 192.168.0.5 rport 63028 generation 0
> > a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx
> > raddr 192.168.0.5 rport 63031 generation 0
> > 2.b. turn candidates
> > a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ
> host
> >
> > No bundle in sdp but:
> >  - offer has 1 single port for stun candidates and 2 for turn candidates
> >  - answer has 2 ports for stun candidates and 1 for turn candidates
> >
> > The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
> >
> > Do you have any idea why this behavior?
>
> Yes, this is caused by MP-NG demultiplexing RTCP. I haven't thought of
> this before, as in our case we only use MP-NG with the '+' flag, which
> would eliminate this issue.
>
> What happens is that MP-NG supports rtcp-mux in that it answers to an
> rtcp-mux offer and handles it correctly, but it never offers rtcp-mux to
> anyone, unless that endpoint is already talking rtcp-mux.
>
> So from Alice's offer, MP-NG knows that Alice supports rtcp-mux and
> gladly accepts the offer in the answer sent to Alice. In this case, the
> same port is used for RTP and RTCP, which implies that only one ICE
> candidate is given for that port (only in the answer though -- in the
> offer, two must be given as a fallback).
>
> However, MP-NG doesn't offer rtcp-mux to Bob, which means that Bob's
> answer includes separate ICE candidates for RTP and RTCP (due to
> separate ports). As those ICE candidates are left in place by MP-NG when
> translating the answer (which will include rtcp-mux), there's now a
> disagreement between the ICE candidates from Bob (two per candidate due
> to lack of rtcp-mux) and the ICE candidate inserted by MP-NG (only one
> due to rtcp-mux).
>
> There's two possible solutions without resorting to the '+' flag...
> Either make MP-NG offer rtcp-mux to Bob initially (who may or may not
> accept it -- if he doesn't, nothing is fixed), or make it reject the
> rtcp-mux offer coming from Alice (which violates the WebRTC spec).
>
> Another thing that MP-NG could do is to remove the RTCP ICE candidates
> in the answer going to Alice, hoping that Bob knows to demultiplex the
> RTCP packets coming in on the RTP port, despite rtcp-mux not having been
> negotiated.
>
> I can't say I like any of these options :)
>
> 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/20140220/26a3f6d4/attachment-0001.html>