[OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6

Dave Singer dave.singer at wideideas.com
Tue Feb 8 21:09:22 CET 2011


So weird.
Did you specify the -f <path to custom config> on the opensips cmd line?
That is the only thing left that I can think of as the problem, it is
using a default config that is somewhere else.

try
  updatedb
  locate opensips.cfg
Most likely the default location is /usr/etc/opensips/opensips.cfg or
/etc/opensips/opensips.cfg, depending on compile time options.

Failing that I would scrub out opensips installed pieces and
recompile/reinstall with a different --prefix=

Dave

On Tue, Feb 8, 2011 at 11:51 AM, Chris Stone <axisml at gmail.com> wrote:
> Dave,
>
> On Tue, Feb 8, 2011 at 12:02 AM, Dave Singer <dave.singer at wideideas.com> wrote:
>> Don't know what tools you are familiar with so here are some
>> suggestions for what they're worth.
>
> Appreciate the input!
>
> Am familiar with all - but included output below - always happy to
> have another set of eyes on things  ;-)
>
>> what is listening on port 5060?
>>   netstat -lnp | grep 5060
>
> tcp        0      0 67.212.153.178:5060         0.0.0.0:*
>     LISTEN      25098/opensips
> tcp        0      0 127.0.0.1:5060              0.0.0.0:*
>     LISTEN      25098/opensips
> udp        0      0 67.212.153.178:5060         0.0.0.0:*
>                 25098/opensips
> udp        0      0 127.0.0.1:5060              0.0.0.0:*
>                 25098/opensips
>
> and as seen below, that's the only opensips pid on the system...
>
>> is opensips actually running? what was the command line used?
>>   ps aux --forest | grep opensips
>
> root     25098  0.0  0.0  72884   992 ?        S    11:40   0:00
> /usr/sbin/opensips
> root     25100  0.0  0.0  72884   468 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25101  0.0  0.0  72884   468 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25102  0.0  0.0  72884   468 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25103  0.0  0.0  72884   468 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25104  0.0  0.0  72884   468 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25105  0.0  0.0  72884   472 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25106  0.0  0.0  72884   472 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25107  0.0  0.0  72884   472 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25108  0.0  0.0  72884   472 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25109  0.0  0.0  72884   472 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25110  0.0  0.0  72884   592 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25111  0.0  0.0  72884   600 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25112  0.0  0.0  72884   708 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25113  0.0  0.0  72884   708 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25114  0.0  0.0  72884   708 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25115  0.0  0.0  72884   708 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25116  0.0  0.0  72884   708 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
> root     25117  0.0  0.0  72884   704 ?        S    11:40   0:00  \_
> /usr/sbin/opensips
>
>> Does sip still pass when opensips is not running?
>
> Nope - inbound calls hang and then get a fast busy. Start opensips and
> they ring through.
>
>> if mi_fifo loaded, what is the output of <opensips install
>> path>/sbin/opensipsctl fifo ps
>> does it show that it is listening on the interfaces/ports that are
>> handeling the packets you are capturing?
>
> Wasn't loaded. Added it and retested call and yes, it shows listening
> on the correct interfaces and ports - all interfaces and tcp/udp port
> 5060:
>
> Process::  ID=0 PID=25256 Type=attendant
> Process::  ID=1 PID=25257 Type=SIP receiver udp:127.0.0.1:5060
> Process::  ID=2 PID=25259 Type=SIP receiver udp:127.0.0.1:5060
> Process::  ID=3 PID=25260 Type=SIP receiver udp:127.0.0.1:5060
> Process::  ID=4 PID=25261 Type=SIP receiver udp:127.0.0.1:5060
> Process::  ID=5 PID=25262 Type=SIP receiver udp:127.0.0.1:5060
> Process::  ID=6 PID=25263 Type=SIP receiver udp:67.212.153.178:5060
> Process::  ID=7 PID=25264 Type=SIP receiver udp:67.212.153.178:5060
> Process::  ID=8 PID=25265 Type=SIP receiver udp:67.212.153.178:5060
> Process::  ID=9 PID=25266 Type=SIP receiver udp:67.212.153.178:5060
> Process::  ID=10 PID=25267 Type=SIP receiver udp:67.212.153.178:5060
> Process::  ID=11 PID=25268 Type=time_keeper
> Process::  ID=12 PID=25269 Type=timer
> Process::  ID=13 PID=25270 Type=MI FIFO
> Process::  ID=14 PID=25271 Type=TCP receiver
> Process::  ID=15 PID=25272 Type=TCP receiver
> Process::  ID=16 PID=25273 Type=TCP receiver
> Process::  ID=17 PID=25274 Type=TCP receiver
> Process::  ID=18 PID=25275 Type=TCP receiver
> Process::  ID=19 PID=25276 Type=TCP main
>
>> If something else is listening on port 5060 opensips should be failing
>> to start with the provided config.
>
> Right, not failing to start though - no port conflict....
>
>> try running single mode with the following config:
>> and run it with:
>>  /usr/sbin/opensips -f <config file path/opensips.cfg> 2>&1 | tee test.log
>> (path to opensips executable based on your mpath in the config.
>>
>> The debug went in to test.log as well as to the screen so you can look
>> in it and search for the "test    test" to see if it handled the
>> message. Or details of why it failed to start.
>
> Had to add a 'listen.....' line to the cfg file to get it to listen on
> the public IP instead of only localhost. Started up and yes, the 'test
> test' text showed up and the call exhibited the same behavior and does
> still seem to change the IP in the SIP body (reason for the SDP being
> routed via OpenSIPS??) and the Contact header too (someone else
> noticed that - don't know how significant that is....).
>
> Incoming INVITE to Opensips 1.6 server from upstream provider:
>
>    INVITE sip:17204497101 at 67.212.153.178:5060;transport=udp SIP/2.0\r\n
>    From: "STONE C AND C"
> <sip:+13038382386 at 208.94.157.10:5060>;tag=a9d5ed0-13c4-4d519b73-1fad4e58-4134318e\r\n
>    To: <sip:17204497101 at 67.212.153.178:5060>\r\n
>    Call-ID: CXC-219-728c1330-a9d5ed0-13c4-4d519b73-1fad4e58-222f4090 at 208.94.157.10\r\n
>    CSeq: 1 INVITE\r\n
>    Via: SIP/2.0/UDP
> 208.94.157.10:5060;branch=z9hG4bK-1522a-4d519b73-1fad4e58-c268daf\r\n
>    Max-Forwards: 69\r\n
>    P-Asserted-Identity: "STONE C AND C  "
> <sip:+13038382386 at cxc.dashcs.com:5060>\r\n
>    Supported: timer,100rel\r\n
>    Content-Disposition: session;handling=required\r\n
>    Contact: <sip:+13038382386 at 208.94.157.10:5060;maddr=208.94.157.10;transport=udp>\r\n
>    Session-Expires: 1800\r\n
>    Content-Type: application/sdp\r\n
>    Content-Length: 238\r\n
>    \r\n
>    v=0\r\n
>    o=Acme_UAS 0 1 IN IP4 208.94.157.10\r\n
>    s=SIP Media Capabilities\r\n
>    c=IN IP4 208.94.157.10\r\n
>    t=0 0\r\n
>    m=audio 24600 RTP/AVP 0 18 101\r\n
>    a=rtpmap:0 PCMU/8000\r\n
>    a=rtpmap:18 G729/8000\r\n
>    a=rtpmap:101 telephone-event/8000\r\n
>    a=maxptime:20\r\n
>    a=sendrecv\r\n
>
> Outgoing INVITE from Opensips 1.6 server to Asterisk server:
>
>    INVITE sip:17204497101 at 67.212.153.178:5060;transport=udp SIP/2.0\r\n
>    From: "STONE C AND C"
> <sip:+13038382386 at 208.94.157.10:5060>;tag=a9d5ed0-13c4-4d519b73-1fad4e58-4134318e\r\n
>    To: <sip:17204497101 at 67.212.153.178:5060>\r\n
>    Call-ID: CXC-219-728c1330-a9d5ed0-13c4-4d519b73-1fad4e58-222f4090 at 208.94.157.10\r\n
>    CSeq: 1 INVITE\r\n
>    Via: SIP/2.0/UDP
> 67.212.153.178:5060;branch=z9hG4bK-1522a-4d519b73-1fad4e58-c268daf\r\n
>    Via: SIP/2.0/UDP
> 208.94.157.10:5060;branch=z9hG4bK-1522a-4d519b73-1fad4e58-c268daf\r\n
>    Max-Forwards: 69\r\n
>    P-Asserted-Identity: "STONE C AND C  "
> <sip:+13038382386 at cxc.dashcs.com:5060>\r\n
>    Supported: timer,100rel\r\n
>    Content-Disposition: session;handling=required\r\n
>    Contact: <sip:+13038382386 at 67.212.153.178:5060;maddr=208.94.157.10;transport=udp>\r\n
>    Session-Expires: 1800\r\n
>    Content-Type: application/sdp\r\n
>    Content-Length: 240\r\n
>    \r\n
>    v=0\r\n
>    o=Acme_UAS 0 1 IN IP4 67.212.153.178\r\n
>    s=SIP Media Capabilities\r\n
>    c=IN IP4 67.212.153.178\r\n
>    t=0 0\r\n
>    m=audio 24600 RTP/AVP 0 18 101\r\n
>    a=rtpmap:0 PCMU/8000\r\n
>    a=rtpmap:18 G729/8000\r\n
>    a=rtpmap:101 telephone-event/8000\r\n
>    a=maxptime:20\r\n
>    a=sendrecv\r\n
>
> And, just to confirm, this was with no parameters on the opensips
> command line and with the config:
>
> #-----------------------------------------------------------------------
> debug=9          # debug level (cmd line: -dddddddddd)
> fork=yes
> log_stderror=no  # (cmd line: -E)
>
> children=10
> check_via=no      # (cmd. line: -v)
> dns=off           # (cmd. line: -r)
> rev_dns=off       # (cmd. line: -R)
> port=5060
>
> # ------------------ module loading ----------------------------------
> mpath="/usr/lib64/opensips/modules"
> #loadmodule "xlog.so" # un comment if using opensips before 1.6.4
> # ----------------- setting module-specific parameters ---------------
>
>
> route{
> #       xlog("\n\n\n        test    test \n\n\n");
>        forward("67.212.153.179");
>        exit;
> }
>
>
> Very confusing - see nothing else on the server that would be touching
> the packets - particularly while Opensips is processing them.......
>
>
> Regards,
>
> Chris
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



More information about the Users mailing list