Hi, I am using MediaProxy to help get over some one way audio issues, however it appears to be causing more problems than it is fixing.
When I make a call between two registered phones there is no audio at all, but when I call a gateway audio passes correctly. Looking at the logs it indicates that it has RTP & RTCP for one phone but only RTP for the other: ------------------------------------------------------------------------------------------------------------------------------------------------------------- *media-relay[11366]: debug: Received new SDP offer media-relay[11366]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50060 media-relay[11366]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50061 media-relay[11366]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50062 media-relay[11366]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50063 media-relay[11366]: debug: Added new stream: (audio) 192.168.2.200:5638(RTP: Unknown, RTCP: Unknown) <-> <SERVER IP ADDRESS>:50060 <-> <SERVER IP ADDRESS>:50062 <-> Unknown (RTP: Unknown, RTCP: Unknown) media-relay[11366]: debug: created new session NWZmMmMwMzAxNDM5YjdiYTAwMDYxYTViNTllMTczMWI.: **10002*[email protected]*<10002*[email protected]> * (b62884c7) --> **10001*[email protected]* <10001*[email protected]> *media-relay[11366]: debug: Got traffic information for stream: (audio) 192.168.2.200:5638 (RTP: Unknown, RTCP: Unknown) <-> <SERVER IP ADDRESS>:50060 <-> <SERVER IP ADDRESS>:50062 <-> Unknown (RTP: <Clients Router IP>:57096, RTCP: Unknown) media-dispatcher[11369]: debug: Issuing "update" command to relay at <SERVER IP ADDRESS> media-relay[11366]: debug: updating existing session NWZmMmMwMzAxNDM5YjdiYTAwMDYxYTViNTllMTczMWI.: **10002*[email protected]*<10002*[email protected]> * (b62884c7) --> **10001*[email protected]* <10001*[email protected]> *media-relay[11366]: debug: Received updated SDP answer media-relay[11366]: debug: Got initial answer from callee for stream: (audio) 192.168.2.200:5638 (RTP: Unknown, RTCP: Unknown) <-> <SERVER IP ADDRESS>:50060 <-> <SERVER IP ADDRESS>:50062 <-> 192.168.2.10:40022 (RTP: <Clients Router IP>:57096, RTCP: Unknown) media-relay[11366]: debug: Got traffic information for stream: (audio) 192.168.2.200:5638 (RTP: Unknown, RTCP: <Clients Router IP>:55671) <-> <SERVER IP ADDRESS>:50060 <-> <SERVER IP ADDRESS>:50062 <-> 192.168.2.10:40022 (RTP: <Clients Router IP>:57096, RTCP: Unknown) media-relay[11366]: debug: Got traffic information for stream: (audio) 192.168.2.200:5638 (RTP: <Clients Router IP>:55670, RTCP: <Clients Router IP>:55671) <-> <SERVER IP ADDRESS>:50060 <-> <SERVER IP ADDRESS>:50062 <-> 192.168.2.10:40022 (RTP: <Clients Router IP>:57096, RTCP: Unknown) media-dispatcher[11369]: debug: Issuing "remove" command to relay at <SERVER IP ADDRESS> media-relay[11366]: debug: removing session NWZmMmMwMzAxNDM5YjdiYTAwMDYxYTViNTllMTczMWI.: **10002*[email protected]*<10002*[email protected]> * (b62884c7) --> **10001*[email protected]* <10001*[email protected]> *media-relay[11366]: (Port 50060 Closed) media-relay[11366]: (Port 50061 Closed) media-relay[11366]: (Port 50062 Closed) media-relay[11366]: (Port 50063 Closed) media-dispatcher[11369]: debug: Got statistics: {'from_tag': 'b62884c7', 'dialog_id': '841:447573368', 'start_time': 1256818436.3299999, 'timed_out': False, 'call_id': 'NWZmMmMwMzAxNDM5YjdiYTAwMDYxYTViNTllMTczMWI.', 'to_tag': '7t0mkzlie0', 'streams': [{'status': 'closed', 'caller_codec': 'G711u', 'post_dial_delay': 1.252835989, 'callee_codec': '1016', 'start_time': 0, 'caller_bytes': 82000, 'callee_bytes': 83600, 'caller_packets': 410, 'end_time': 8, 'callee_remote': '<Clients Router IP>:57096', 'caller_remote': '<Clients Router IP>:55670', 'media_type': 'audio', 'callee_local': '<SERVER IP ADDRESS>:50062', 'timeout_wait': 0, 'caller_local': '<SERVER IP ADDRESS>:50060', 'callee_packets': 418}], 'duration': 8, 'to_uri': **'10001*[email protected]'*<'10001*[email protected]'> *, 'from_uri': **'10002*[email protected]'* <'10002*[email protected]'>*, 'callee_ua': 'snom370/7.3.26', 'caller_ua': 'X-Lite Beta release 4.0 Beta 2 stamp 55091'}* ------------------------------------------------------------------------------------------------------------------------------------------------------------- I am using the following OpenSIP's config: # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; # !! Nathelper # Special handling for NATed clients; first, NAT test is # executed: it looks for via!=received and RFC1918 addresses # in Contact (may fail if line-folding is used); also, # the received test should, if completed, should check all # vias for rpesence of received if (nat_uac_test("31")) { # Allow RR-ed requests, as these may indicate that # a NAT-enabled proxy takes care of it; unless it is # a REGISTER xlog("Behind a NAT\n"); if (is_method("REGISTER")) { fix_nated_register(); } fix_nated_contact(); force_rport(); # Add rport parameter to topmost Via #setbflag(6); # Mark as NATed }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!is_method("REGISTER")) record_route(); if(is_method("INVITE")) { fix_nated_sdp("1"); create_dialog(); fix_nated_sdp("8"); engage_media_proxy(); } # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); exit; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); exit; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (is_method("REGISTER")) { # Uncomment this if you want to use digest authentication #if (!www_authorize("siphub.org", "subscriber")) { # www_challenge("siphub.org", "0"); # return; #}; save("location"); exit; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # Local Device Not Found Send To Gateway rewritehostport("<gateway>:5065"); } }; append_hf("P-hint: usrloc applied\r\n"); route(1); } route[1] { # !! Nathelper # if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" && !search("^Route:")) # { # sl_send_reply("479", "We don't forward to private IP addresses"); # exit; # }; # NAT processing of replies; apply to all transactions (for example, # re-INVITEs from public to private UA are hard to identify as # NATed at the moment of request processing); look at replies t_on_reply("1"); # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; } # !! Nathelper onreply_route[1] { if (nat_uac_test("31")) { # Allow RR-ed requests, as these may indicate that # a NAT-enabled proxy takes care of it; unless it is # a REGISTER xlog("Reply Behind a NAT"); fix_nated_contact(); force_rport(); # Add rport parameter to topmost Via #setbflag(6); # Mark as NATed }; }
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
