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

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 &lt;rfuchs(a)sipwise.com&gt; wrote: