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

Ovidiu Sas osas at voipembedded.com
Tue Feb 8 21:16:25 CET 2011


Based on your description, it seems that you are dealing with a weird
firewall/NAT that is SIP aware.
Also, I don't know if this is a typo, but you are forwarding with
opensips to 67.212.153.179 and your INVITE is actually sent to
67.212.153.178.

Try to turn off the firewall and NAT ans see it this is fixing your issue.


Regards,
Ovidiu Sas

On Tue, Feb 8, 2011 at 2:51 PM, 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