[OpenSIPS-Users] MediaProxy No Audio Problems

Ross Beer beer.ross at googlemail.com
Thu Oct 29 13:29:28 CET 2009


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*200 at mydomain.com*<10002*200 at mydomain.com>
* (b62884c7) --> **10001*200 at mydomain.com* <10001*200 at mydomain.com>
*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*200 at mydomain.com*<10002*200 at mydomain.com>
* (b62884c7) --> **10001*200 at mydomain.com* <10001*200 at mydomain.com>
*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*200 at mydomain.com*<10002*200 at mydomain.com>
* (b62884c7) --> **10001*200 at mydomain.com* <10001*200 at mydomain.com>
*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*200 at mydomain.com'*<'10001*200 at mydomain.com'>
*, 'from_uri': **'10002*200 at mydomain.com'* <'10002*200 at mydomain.com'>*,
'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

};

}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20091029/d8c2d0c0/attachment.htm 


More information about the Users mailing list