Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Good to hear that! Cheers, Henk On 11-02-11 02:15, Chris Stone wrote: Well, looks like it WAS the ip_nat_sip and related kernel modules, but not just on the Opensips server, also on the Asterisk server. I unloaded all of the modules on the backend Asterisk server too and tried a test call again and this time it worked just fine. Appreciate all the help with this Henk and Ovidiu! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu,
On Wed, Feb 9, 2011 at 3:02 PM, Ovidiu Sas o...@voipembedded.com wrote:
It may be that something on the way out that is changing the message.
I've seen some routers messing with the INVITE that is sent out.
I want to see the message as it is when it leaves opensips and before
being sent out into the network.
Well, using this in the script:
loadmodule tm.so
route{
xlog(L_INFO, SIP message in route():\n);
xlog(L_INFO, $mb\n);
forward(67.212.153.179);
exit;
}
local_route {
xlog(L_INFO, SIP message in local_route():\n);
xlog(L_INFO, $mb\n);
}
The first message is logged, but nothing for the one in local_route().
Sorry, don't mean to be stupid - guess I must be missing something
yet.
Anyway, here's what was logged:
Feb 10 17:58:28 mars /usr/sbin/opensips[19343]: SIP message in route():
Feb 10 17:58:28 mars /usr/sbin/opensips[19343]: INVITE
sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0^M From:
STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d5489b4-2b1f9707-34d78458^M
To: sip:17204497101@67.212.153.178:5060^M Call-ID:
CXC-195-5df63d90-a9d5ed0-13c4-4d5489b4-2b1f9707-3c07ffca@208.94.157.10^M
CSeq: 1 INVITE^M Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-fa3a0-4d5489b4-2b1f9707-5e2659b1^M
Max-Forwards: 69^M P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060^M Supported: timer,100rel^M
Content-Disposition: session;handling=required^M Contact:
sip:+13038382386@208.94.157.10:5060;maddr=208.94.157.10;transport=udp^M
Session-Expires: 1800^M Content-Type: application/sdp^M
Content-Length: 238^M ^M v=0^M o=Acme_UAS 0 1 IN IP4 208.94.157.10^M
s=SIP Media Capabilities^M c=IN IP4 208.94.157.10^M t=0 0^M m=audio
22478 RTP/AVP 0 18 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:18
G729/8000^M a=rtpmap:101 telephone-event/8000^M a=maxptime:20^M
a=sendrecv^M
Feb 10 17:58:31 mars /usr/sbin/opensips[19345]: INFO:core:buf_init:
initializing...
Feb 10 17:58:31 mars /usr/sbin/opensips[19345]: SIP message in route():
Feb 10 17:58:31 mars /usr/sbin/opensips[19345]: ACK
sip:17204497101@67.212.153.179:5060 SIP/2.0^M From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d5489b4-2b1f9707-34d78458
^M To: sip:17204497101@67.212.153.178:5060;tag=as6c8f0e36^M Call-ID:
CXC-195-5df63d90-a9d5ed0-13c4-4d5489b4-2b1f9707-3c07ffca@208.94.157.10^M
CSeq: 1 ACK^M Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-fa3ba-4d5489b7-2b1fa2e2-68bee566^M
Max-Forwards: 69^M Contact:
sip:+13038382386@208.94.157.10:5060;maddr=208.94.157.10;transport=udp^M
Content-Length: 0^M ^M
Feb 10 17:58:39 mars /usr/sbin/opensips[19347]: INFO:core:buf_init:
initializing...
Feb 10 17:58:39 mars /usr/sbin/opensips[19347]: SIP message in route():
Feb 10 17:58:39 mars /usr/sbin/opensips[19347]: BYE
sip:17204497101@67.212.153.179:5060 SIP/2.0^M From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d5489b4-2b1f9707-34d78458
^M To: sip:17204497101@67.212.153.178:5060;tag=as6c8f0e36^M Call-ID:
CXC-195-5df63d90-a9d5ed0-13c4-4d5489b4-2b1f9707-3c07ffca@208.94.157.10^M
CSeq: 2 BYE^M Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-fa417-4d5489bf-2b1fc19c-3af7df9c^M
Max-Forwards: 69^M Content-Length: 0^M ^M
Thanks
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6 - SOLVED
Well, looks like it WAS the ip_nat_sip and related kernel modules, but not just on the Opensips server, also on the Asterisk server. I unloaded all of the modules on the backend Asterisk server too and tried a test call again and this time it worked just fine. Appreciate all the help with this Henk and Ovidiu! Thanks Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Well, looks like it WAS the ip_nat_sip and related kernel modules, but not just on the Opensips server, also on the Asterisk server. I unloaded all of the modules on the backend Asterisk server too and tried a test call again and this time it worked just fine. Appreciate all the help with this Henk and Ovidiu! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Henk, On Tue, Feb 8, 2011 at 6:23 PM, Henk Hesselink opensips-us...@voipro.nl wrote: What does an ngrep trace on the interface (interfaces?) of the machine show? Are the packets changed when they leave the machine? In that case it must be happening on that machine, i.e. no external firewall It shows that the packets are changed on the machine - no external firewall involvement: [root@mars ~]# ngrep -pt -d eth0 port 5060 and not host 38.116.136.247 interface: eth0 (67.212.153.176/255.255.255.240) filter: (ip) and ( port 5060 and not host 38.116.136.247 ) # U 2011/02/09 12:57:47.457399 208.94.157.10:5060 - 67.212.153.178:5060 INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0..From: STONE C AND C sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d52f1ba-24e62632-44ba7768..To: sip:17204497101@67.21 2.153.178:5060..Call-ID: cxc-173-6b187330-a9d5ed0-13c4-4d52f1ba-24e62632-15a05...@208.94.157.10..cseq: 1 INVITE..Via: SIP/2.0/UDP 208.94.157.10:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b781 ..Max-Forwards: 69..P-Asserted-Identity: STONE C AND C sip:+13038382...@cxc.dashcs.com:5060..Supported: timer,100rel..Content-Disposition: session;handling=required..Contact: sip:+1303838238 6@208.94.157.10:5060;maddr=208.94.157.10;transport=udp..Session-Expires: 1800..Content-Type: application/sdp..Content-Length: 238v=0..o=Acme_UAS 0 1 IN IP4 208.94.157.10..s=SIP Media Capabilit ies..c=IN IP4 208.94.157.10..t=0 0..m=audio 21428 RTP/AVP 0 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=maxptime:20..a=sendrecv.. # U 2011/02/09 12:57:47.459479 67.212.153.178:5060 - 67.212.153.179:5060 INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0..From: STONE C AND C sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d52f1ba-24e62632-44ba7768..To: sip:17204497101@67.21 2.153.178:5060..Call-ID: cxc-173-6b187330-a9d5ed0-13c4-4d52f1ba-24e62632-15a05...@208.94.157.10..cseq: 1 INVITE..Via: SIP/2.0/UDP 67.212.153.178:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b78 1..Via: SIP/2.0/UDP 208.94.157.10:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b781..Max-Forwards: 69..P-Asserted-Identity: STONE C AND C sip:+13038382...@cxc.dashcs.com:5060..Supported: t imer,100rel..Content-Disposition: session;handling=required..Contact: sip:+13038382386@67.212.153.178:5060;maddr=208.94.157.10;transport=udp..Session-Expires: 1800..Content-Type: application/sdp. .Content-Length: 240v=0..o=Acme_UAS 0 1 IN IP4 67.212.153.178..s=SIP Media Capabilities..c=IN IP4 67.212.153.178..t=0 0..m=audio 21428 RTP/AVP 0 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8 000..a=rtpmap:101 telephone-event/8000..a=maxptime:20..a=sendrecv.. munging. If that is the case then run OpenSIPS with debug level 9 or so, save the output and then grep on the 2 different IP adresses that are in the incoming/outgoing contact header to see why that header is being changed. That might give a clue as to the SDP routing. I can see that the addresses are being changed for what's send v.s. what's received from the upstream. Can't say that I can tell the why of it though. Here's the output of the call test. Do you maybe see why Opensips is making such a change and hence, causing the SDP to be routed back to it? Feb 9 13:27:28 [12757] DBG:core:socket2str: udp:67.212.153.178:5060 Feb 9 13:27:28 [12757] WARNING:core:main: no fork mode Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: F_OPTIMIZE=16384, /ROUNDTO=2048 Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: F_HASH_SIZE=2099, fm_block size=33632 Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: params (0x2b1aeab1d000, 33554432), start=0x2b1aeab1d000 Feb 9 13:27:28 [12757] DBG:core:shm_mem_init_mallocs: success Feb 9 13:27:28 [12757] INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Feb 9 13:27:28 [12757] DBG:core:set_core_dump: core dump limits set to 18446744073709551615 Feb 9 13:27:28 [12757] NOTICE:core:main: version: opensips 1.4.0-notls (x86_64/linux) Feb 9 13:27:28 [12757] INFO:core:main: using 32 Mb shared memory Feb 9 13:27:28 [12757] INFO:core:main: using 1 Mb private memory per process Feb 9 13:27:28 [12757] DBG:core:add_avp_galias: registering serial_branch for avp id 16725044 Feb 9 13:27:28 [12757] DBG:core:init_stats_collector: statistics manager successfully initialized Feb 9 13:27:28 [12757] DBG:core:count_module_procs: modules require 0 extra processes Feb 9 13:27:28 [12757] DBG:core:mk_proxy: doing DNS lookup... Feb 9 13:27:28 [12757] DBG:core:probe_max_receive_buffer: getsockopt SO_RCVBUF is initially 129024 Feb 9 13:27:28 [12757] DBG:core:probe_max_receive_buffer: trying SO_RCVBUF: 258048 Feb 9 13:27:28 [12757] DBG:core:probe_max_receive_buffer: setting SO_RCVBUF; set=258048,verify=262142 Feb 9 13:27:28 [12757] DBG:core:probe_max_receive_buffer: trying SO_RCVBUF: 260096 Feb 9 13:27:28 [12757]
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Add the following xlog at the beginning of the script:
xlog(L_INFO, $mb\n);
Then and add a local_route:
local_route {
xlog(L_INFO, $mb\n);
}
Then check the logs. There you should have the received and sent message.
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 4:02 PM, Chris Stone axi...@gmail.com wrote:
Henk,
On Tue, Feb 8, 2011 at 6:23 PM, Henk Hesselink opensips-us...@voipro.nl
wrote:
What does an ngrep trace on the interface (interfaces?) of the machine
show? Are the packets changed when they leave the machine? In that
case it must be happening on that machine, i.e. no external firewall
It shows that the packets are changed on the machine - no external
firewall involvement:
[root@mars ~]# ngrep -pt -d eth0 port 5060 and not host 38.116.136.247
interface: eth0 (67.212.153.176/255.255.255.240)
filter: (ip) and ( port 5060 and not host 38.116.136.247 )
#
U 2011/02/09 12:57:47.457399 208.94.157.10:5060 - 67.212.153.178:5060
INVITE sip:17204497101@67.212.153.178:5060;transport=udp
SIP/2.0..From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d52f1ba-24e62632-44ba7768..To:
sip:17204497101@67.21
2.153.178:5060..Call-ID:
cxc-173-6b187330-a9d5ed0-13c4-4d52f1ba-24e62632-15a05...@208.94.157.10..cseq:
1 INVITE..Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b781
..Max-Forwards: 69..P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060..Supported:
timer,100rel..Content-Disposition: session;handling=required..Contact:
sip:+1303838238
6@208.94.157.10:5060;maddr=208.94.157.10;transport=udp..Session-Expires:
1800..Content-Type: application/sdp..Content-Length:
238v=0..o=Acme_UAS 0 1 IN IP4 208.94.157.10..s=SIP Media Capabilit
ies..c=IN IP4 208.94.157.10..t=0 0..m=audio 21428 RTP/AVP 0 18
101..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a=rtpmap:101
telephone-event/8000..a=maxptime:20..a=sendrecv..
#
U 2011/02/09 12:57:47.459479 67.212.153.178:5060 - 67.212.153.179:5060
INVITE sip:17204497101@67.212.153.178:5060;transport=udp
SIP/2.0..From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d52f1ba-24e62632-44ba7768..To:
sip:17204497101@67.21
2.153.178:5060..Call-ID:
cxc-173-6b187330-a9d5ed0-13c4-4d52f1ba-24e62632-15a05...@208.94.157.10..cseq:
1 INVITE..Via: SIP/2.0/UDP
67.212.153.178:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b78
1..Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b781..Max-Forwards:
69..P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060..Supported: t
imer,100rel..Content-Disposition:
session;handling=required..Contact:
sip:+13038382386@67.212.153.178:5060;maddr=208.94.157.10;transport=udp..Session-Expires:
1800..Content-Type: application/sdp.
.Content-Length: 240v=0..o=Acme_UAS 0 1 IN IP4
67.212.153.178..s=SIP Media Capabilities..c=IN IP4 67.212.153.178..t=0
0..m=audio 21428 RTP/AVP 0 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:18
G729/8
000..a=rtpmap:101 telephone-event/8000..a=maxptime:20..a=sendrecv..
munging. If that is the case then run OpenSIPS with debug level 9 or
so, save the output and then grep on the 2 different IP adresses that
are in the incoming/outgoing contact header to see why that header is
being changed. That might give a clue as to the SDP routing.
I can see that the addresses are being changed for what's send v.s.
what's received from the upstream. Can't say that I can tell the why
of it though. Here's the output of the call test. Do you maybe see why
Opensips is making such a change and hence, causing the SDP to be
routed back to it?
Feb 9 13:27:28 [12757] DBG:core:socket2str: udp:67.212.153.178:5060
Feb 9 13:27:28 [12757] WARNING:core:main: no fork mode
Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: F_OPTIMIZE=16384,
/ROUNDTO=2048
Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: F_HASH_SIZE=2099,
fm_block size=33632
Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: params
(0x2b1aeab1d000, 33554432), start=0x2b1aeab1d000
Feb 9 13:27:28 [12757] DBG:core:shm_mem_init_mallocs: success
Feb 9 13:27:28 [12757] INFO:core:init_tcp: using epoll_lt as the TCP
io watch method (auto detected)
Feb 9 13:27:28 [12757] DBG:core:set_core_dump: core dump limits set
to 18446744073709551615
Feb 9 13:27:28 [12757] NOTICE:core:main: version: opensips
1.4.0-notls (x86_64/linux)
Feb 9 13:27:28 [12757] INFO:core:main: using 32 Mb shared memory
Feb 9 13:27:28 [12757] INFO:core:main: using 1 Mb private memory per process
Feb 9 13:27:28 [12757] DBG:core:add_avp_galias: registering
serial_branch for avp id 16725044
Feb 9 13:27:28 [12757] DBG:core:init_stats_collector: statistics
manager successfully initialized
Feb 9 13:27:28 [12757] DBG:core:count_module_procs: modules require 0
extra processes
Feb 9 13:27:28 [12757] DBG:core:mk_proxy: doing DNS lookup...
Feb 9
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu,
On Wed, Feb 9, 2011 at 2:12 PM, Ovidiu Sas o...@voipembedded.com wrote:
Add the following xlog at the beginning of the script:
xlog(L_INFO, $mb\n);
Cool - forgot about the $mb to log the packet. Thanks - can be handy.
In the route() function, the packet was dumped to the log. Looked the
same, as expected.
Then and add a local_route:
local_route {
xlog(L_INFO, $mb\n);
}
Added, but did not get hit since I'm not using the tm module and from
what I read, this is only used when using the tm module.
Then check the logs. There you should have the received and sent message.
No sent message seen, just the initial invite as received
Thanks
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
well ... switch to tm and try again.
On Wed, Feb 9, 2011 at 4:28 PM, Chris Stone axi...@gmail.com wrote:
Ovidiu,
On Wed, Feb 9, 2011 at 2:12 PM, Ovidiu Sas o...@voipembedded.com wrote:
Add the following xlog at the beginning of the script:
xlog(L_INFO, $mb\n);
Cool - forgot about the $mb to log the packet. Thanks - can be handy.
In the route() function, the packet was dumped to the log. Looked the
same, as expected.
Then and add a local_route:
local_route {
xlog(L_INFO, $mb\n);
}
Added, but did not get hit since I'm not using the tm module and from
what I read, this is only used when using the tm module.
Then check the logs. There you should have the received and sent message.
No sent message seen, just the initial invite as received
Thanks
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu, On Wed, Feb 9, 2011 at 2:30 PM, Ovidiu Sas o...@voipembedded.com wrote: well ... switch to tm and try again. Did and no luck - still not firing local_route(). Changed my forward() to t_relay(), thinking that might be it, and got a *ton* of error messages about memory for xlog needing increased from 4096. Did that a few numbers up to 65535 and still got a bunch of memory allocation errors logged. But, what would this tell us though that'd be different than the output from the ngrep traces, packet captures, debug output etc, that I've posted? Thanks Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
It may be that something on the way out that is changing the message. I've seen some routers messing with the INVITE that is sent out. I want to see the message as it is when it leaves opensips and before being sent out into the network. On Wed, Feb 9, 2011 at 4:56 PM, Chris Stone axi...@gmail.com wrote: Ovidiu, On Wed, Feb 9, 2011 at 2:30 PM, Ovidiu Sas o...@voipembedded.com wrote: well ... switch to tm and try again. Did and no luck - still not firing local_route(). Changed my forward() to t_relay(), thinking that might be it, and got a *ton* of error messages about memory for xlog needing increased from 4096. Did that a few numbers up to 65535 and still got a bunch of memory allocation errors logged. But, what would this tell us though that'd be different than the output from the ngrep traces, packet captures, debug output etc, that I've posted? Thanks Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Chris, First off, the ngrep trace doesn't seem to match the debug log, f.i. the From: tag is different. You might also want to check out -Wbyline for ngrep, makes reading the output a lot easier. But ignoring the tags, the debug log shows DBG:core:forward_request: sending: and then the exact original message (with an extra Via: of course). So it seems to me OpenSIPS is sending out what you'd expect. So I believe the munging is happening after the packet leaves OpenSIPS and before it is sent out on the wire. Run lsmod | grep nat and see if you have nf_nat_sip (I'm assuming it's a Linux box), or maybe some other module that might be doing this. Cheers, Henk On 09-02-11 22:02, Chris Stone wrote: Henk, On Tue, Feb 8, 2011 at 6:23 PM, Henk Hesselinkopensips-us...@voipro.nl wrote: What does an ngrep trace on the interface (interfaces?) of the machine show? Are the packets changed when they leave the machine? In that case it must be happening on that machine, i.e. no external firewall It shows that the packets are changed on the machine - no external firewall involvement: [root@mars ~]# ngrep -pt -d eth0 port 5060 and not host 38.116.136.247 interface: eth0 (67.212.153.176/255.255.255.240) filter: (ip) and ( port 5060 and not host 38.116.136.247 ) # U 2011/02/09 12:57:47.457399 208.94.157.10:5060 - 67.212.153.178:5060 INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0..From: STONE C AND C sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d52f1ba-24e62632-44ba7768..To: sip:17204497101@67.21 2.153.178:5060..Call-ID: cxc-173-6b187330-a9d5ed0-13c4-4d52f1ba-24e62632-15a05...@208.94.157.10..cseq: 1 INVITE..Via: SIP/2.0/UDP 208.94.157.10:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b781 ..Max-Forwards: 69..P-Asserted-Identity: STONE C AND C sip:+13038382...@cxc.dashcs.com:5060..Supported: timer,100rel..Content-Disposition: session;handling=required..Contact: sip:+1303838238 6@208.94.157.10:5060;maddr=208.94.157.10;transport=udp..Session-Expires: 1800..Content-Type: application/sdp..Content-Length: 238v=0..o=Acme_UAS 0 1 IN IP4 208.94.157.10..s=SIP Media Capabilit ies..c=IN IP4 208.94.157.10..t=0 0..m=audio 21428 RTP/AVP 0 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8000..a=rtpmap:101 telephone-event/8000..a=maxptime:20..a=sendrecv.. # U 2011/02/09 12:57:47.459479 67.212.153.178:5060 - 67.212.153.179:5060 INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0..From: STONE C AND C sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d52f1ba-24e62632-44ba7768..To: sip:17204497101@67.21 2.153.178:5060..Call-ID: cxc-173-6b187330-a9d5ed0-13c4-4d52f1ba-24e62632-15a05...@208.94.157.10..cseq: 1 INVITE..Via: SIP/2.0/UDP 67.212.153.178:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b78 1..Via: SIP/2.0/UDP 208.94.157.10:5060;branch=z9hG4bK-9be4f-4d52f1ba-24e62632-5636b781..Max-Forwards: 69..P-Asserted-Identity: STONE C AND C sip:+13038382...@cxc.dashcs.com:5060..Supported: t imer,100rel..Content-Disposition: session;handling=required..Contact: sip:+13038382386@67.212.153.178:5060;maddr=208.94.157.10;transport=udp..Session-Expires: 1800..Content-Type: application/sdp. .Content-Length: 240v=0..o=Acme_UAS 0 1 IN IP4 67.212.153.178..s=SIP Media Capabilities..c=IN IP4 67.212.153.178..t=0 0..m=audio 21428 RTP/AVP 0 18 101..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G729/8 000..a=rtpmap:101 telephone-event/8000..a=maxptime:20..a=sendrecv.. munging. If that is the case then run OpenSIPS with debug level 9 or so, save the output and then grep on the 2 different IP adresses that are in the incoming/outgoing contact header to see why that header is being changed. That might give a clue as to the SDP routing. I can see that the addresses are being changed for what's send v.s. what's received from the upstream. Can't say that I can tell the why of it though. Here's the output of the call test. Do you maybe see why Opensips is making such a change and hence, causing the SDP to be routed back to it? Feb 9 13:27:28 [12757] DBG:core:socket2str:udp:67.212.153.178:5060 Feb 9 13:27:28 [12757] WARNING:core:main: no fork mode Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: F_OPTIMIZE=16384, /ROUNDTO=2048 Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: F_HASH_SIZE=2099, fm_block size=33632 Feb 9 13:27:28 [12757] DBG:core:fm_malloc_init: params (0x2b1aeab1d000, 33554432), start=0x2b1aeab1d000 Feb 9 13:27:28 [12757] DBG:core:shm_mem_init_mallocs: success Feb 9 13:27:28 [12757] INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Feb 9 13:27:28 [12757] DBG:core:set_core_dump: core dump limits set to 18446744073709551615 Feb 9 13:27:28 [12757] NOTICE:core:main: version: opensips 1.4.0-notls (x86_64/linux) Feb 9 13:27:28 [12757] INFO:core:main: using 32 Mb shared memory Feb 9 13:27:28 [12757] INFO:core:main: using 1 Mb private memory per process Feb 9 13:27:28
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Henk, On Wed, Feb 9, 2011 at 3:48 PM, Henk Hesselink opensips-us...@voipro.nl wrote: First off, the ngrep trace doesn't seem to match the debug log, f.i. the From: tag is different. You might also want to check out -Wbyline for ngrep, makes reading the output a lot easier. They were different calls - same source and destination DIDs, but 2 different calls But ignoring the tags, the debug log shows DBG:core:forward_request: sending: and then the exact original message (with an extra Via: of course). So it seems to me OpenSIPS is sending out what you'd expect. So I believe the munging is happening after the packet leaves OpenSIPS and before it is sent out on the wire. Run lsmod | grep nat and see if you have nf_nat_sip (I'm assuming it's a Linux box), or maybe some other module that might be doing this. Well, checked that and found a bunch of stuff: [root@mars ~]# lsmod | grep nat ip_nat_tftp34881 0 ip_nat_snmp_basic 43461 0 ip_nat_sip 37313 0 ip_nat_pptp39237 0 ip_nat_irc 35777 0 ip_nat_h32340769 0 ip_nat_ftp 36545 0 ip_nat_amanda 35393 0 ip_conntrack_tftp 37913 1 ip_nat_tftp ip_conntrack_sip 41745 1 ip_nat_sip ip_conntrack_pptp 45665 1 ip_nat_pptp ip_conntrack_irc 40465 1 ip_nat_irc ip_conntrack_h323 88193 1 ip_nat_h323 ip_conntrack_ftp 41361 1 ip_nat_ftp ip_conntrack_amanda38345 1 ip_nat_amanda iptable_nat40773 0 and Googling on that, found a bunch of hits that talked about ip_nat_sip and nf_nat_sip causing exactly the problem I am seeing. Exciting! So, removed those modules (rmmod), disabled them in shorewall, made sure that /etc/modprobe.conf would not reload them, restarted opensips and did a test call. Same problem. Checked the modules and found the sip ones not loaded: [root@mars ~]# lsmod | grep nat ip_nat_tftp34881 0 ip_nat_snmp_basic 43461 0 ip_nat_pptp39237 0 ip_nat_irc 35777 0 ip_nat_h32340769 0 ip_nat_ftp 36545 0 ip_nat_amanda 35393 0 ip_conntrack_tftp 37913 1 ip_nat_tftp ip_conntrack_pptp 45665 1 ip_nat_pptp ip_conntrack_irc 40465 1 ip_nat_irc ip_conntrack_h323 88193 1 ip_nat_h323 ip_conntrack_ftp 41361 1 ip_nat_ftp ip_conntrack_amanda38345 1 ip_nat_amanda iptable_nat40773 0 . So, made sure shorewall was disabled and rebooted the box. Now, none of these modules are active: [root@mars ~]# lsmod | grep nat [root@mars ~]# Test call still fails though in the same way. DARN! Thought you had hit on it! But, SDP is still being routed incorrectly: [root@mars ~]# tethereal -i eth0 -f 'udp' Running as user root and group root. This could be dangerous. Capturing on eth0 0.00 208.94.157.10 - 67.212.153.178 SIP/SDP Request: INVITE sip:17204497101@67.212.153.178:5060;transport=udp, with session description 0.000709 67.212.153.178 - 67.212.153.179 SIP/SDP Request: INVITE sip:17204497101@67.212.153.178:5060;transport=udp, with session description 0.002113 67.212.153.179 - 67.212.153.178 SIP Status: 100 Trying 0.010449 67.212.153.178 - 208.94.157.10 SIP Status: 100 Trying 1.005118 67.212.153.179 - 67.212.153.178 SIP Status: 180 Ringing 1.005920 67.212.153.178 - 208.94.157.10 SIP Status: 180 Ringing 3.006377 67.212.153.179 - 67.212.153.178 SIP/SDP Status: 200 OK, with session description 3.007123 67.212.153.178 - 208.94.157.10 SIP/SDP Status: 200 OK, with session description 3.031546 208.94.157.10 - 67.212.153.178 SIP Request: ACK sip:17204497101@67.212.153.179:5060 3.032332 67.212.153.178 - 67.212.153.179 SIP Request: ACK sip:17204497101@67.212.153.179:5060 3.046018 67.212.153.179 - 67.212.153.178 RTP PT=ITU-T G.711 PCMU, SSRC=0x621B0940, Seq=3994, Time=160, Mark 3.063905 67.212.153.179 - 67.212.153.178 RTP PT=ITU-T G.711 PCMU, SSRC=0x621B0940, Seq=3995, Time=320 3.083848 67.212.153.179 - 67.212.153.178 RTP PT=ITU-T G.711 PCMU, SSRC=0x621B0940, Seq=3996, Time=480 3.103845 67.212.153.179 - 67.212.153.178 RTP PT=ITU-T G.711 PCMU, SSRC=0x621B0940, Seq=3997, Time=640 3.123839 67.212.153.179 - 67.212.153.178 RTP PT=ITU-T G.711 PCMU, SSRC=0x621B0940, Seq=3998, Time=800 . Still digging and looking for the answer Thanks Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Chris, Weird indeed. Dave Singers suggestions are excellent, maybe also check that there are no old OpenSIPS processes hanging around (with ps axu). I occasionally see a process that won't die and then the restart will fail. Cheers, Henk Hesselink On 08-02-11 03:14, Chris Stone wrote: Sorry all for the last message - too quick on the Send button. On Mon, Feb 7, 2011 at 6:48 PM, Henk Hesselinkopensips-us...@voipro.nl wrote: Hi Chris, That config should't touch the Contact header, and yet that's also been modified: In: Contact:sip:+13038382386@208.94.157.10 ... Out: Contact:sip:+13038382386@67.212.153.178 ... Are you sure nothing else is touching the message? Yes, absolutely. The packets were captured on the Opensips server - in from upstream provider and then the next packet relaying the invite to backend Asterisk server. The upstream provider is, of course, on a remote network. The Asterisk server is on the same LAN - only a switch separating the 2 servers. The only application on the server that touched the packets would be Opensips. So I'm not nuts - something very weird is going on here eh? Regards, Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Dave, On Tue, Feb 8, 2011 at 12:02 AM, Dave Singer dave.sin...@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 tcp0 0 67.212.153.178:5060 0.0.0.0:* LISTEN 25098/opensips tcp0 0 127.0.0.1:5060 0.0.0.0:* LISTEN 25098/opensips udp0 0 67.212.153.178:5060 0.0.0.0:* 25098/opensips udp0 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 ?S11:40 0:00 /usr/sbin/opensips root 25100 0.0 0.0 72884 468 ?S11:40 0:00 \_ /usr/sbin/opensips root 25101 0.0 0.0 72884 468 ?S11:40 0:00 \_ /usr/sbin/opensips root 25102 0.0 0.0 72884 468 ?S11:40 0:00 \_ /usr/sbin/opensips root 25103 0.0 0.0 72884 468 ?S11:40 0:00 \_ /usr/sbin/opensips root 25104 0.0 0.0 72884 468 ?S11:40 0:00 \_ /usr/sbin/opensips root 25105 0.0 0.0 72884 472 ?S11:40 0:00 \_ /usr/sbin/opensips root 25106 0.0 0.0 72884 472 ?S11:40 0:00 \_ /usr/sbin/opensips root 25107 0.0 0.0 72884 472 ?S11:40 0:00 \_ /usr/sbin/opensips root 25108 0.0 0.0 72884 472 ?S11:40 0:00 \_ /usr/sbin/opensips root 25109 0.0 0.0 72884 472 ?S11:40 0:00 \_ /usr/sbin/opensips root 25110 0.0 0.0 72884 592 ?S11:40 0:00 \_ /usr/sbin/opensips root 25111 0.0 0.0 72884 600 ?S11:40 0:00 \_ /usr/sbin/opensips root 25112 0.0 0.0 72884 708 ?S11:40 0:00 \_ /usr/sbin/opensips root 25113 0.0 0.0 72884 708 ?S11:40 0:00 \_ /usr/sbin/opensips root 25114 0.0 0.0 72884 708 ?S11:40 0:00 \_ /usr/sbin/opensips root 25115 0.0 0.0 72884 708 ?S11:40 0:00 \_ /usr/sbin/opensips root 25116 0.0 0.0 72884 708 ?S11:40 0:00 \_ /usr/sbin/opensips root 25117 0.0 0.0 72884 704 ?S11: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 21 | 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
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
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 axi...@gmail.com wrote: Dave, On Tue, Feb 8, 2011 at 12:02 AM, Dave Singer dave.sin...@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
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
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 axi...@gmail.com wrote: Dave, On Tue, Feb 8, 2011 at 12:02 AM, Dave Singer dave.sin...@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 21 | tee test.log (path to opensips executable based on your
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Dave, On Tue, Feb 8, 2011 at 1:09 PM, Dave Singer dave.sin...@wideideas.com wrote: 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. Yes - used: opensips -f /etc/opensips/opensips.cfg 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. The only one is /etc/opensips/opensips.cfg Failing that I would scrub out opensips installed pieces and recompile/reinstall with a different --prefix= That's about where I am at.This particular installation is not from source, but rather the RPMs from the EPEL repo - installed: [root@mars opensips]# rpm -qa | grep opensips opensips-mysql-1.6.3-2.el5 opensips-regex-1.6.3-2.el5 opensips-db_berkeley-1.6.3-2.el5 opensips-snmpstats-1.6.3-2.el5 opensips-tlsops-1.6.3-2.el5 opensips-perlvdb-1.6.3-2.el5 opensips-1.6.3-2.el5 opensips-perl-1.6.3-2.el5 opensips-acc-1.6.3-2.el5 So, guess I'll uninstall these RPMs and try again from source and see how that goes... Thanks! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu, On Tue, Feb 8, 2011 at 1:16 PM, Ovidiu Sas o...@voipembedded.com wrote: 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. No firewall - though of that too at first. There is a PIX between the net and the servers, but not between the Opensips server and the Asterisk server. The packet capture showing the modifications to the INVITES was from the Opensips server - in-n-out. No firewall involved at that point. The Opensips server is 67.212.153.178 and it's forwarding to the Asterisk server which is at 67.212.153.179. Due to previous issues with the sip fixup in PIX firewalls, that it disabled in the PIX we're using. But again, this modification is being done after the PIX hands it off to the Opensips server Thanks! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
You din't posted a proper SIP capture (no UDP src/dst IP for your packets), but it seems that you are having a firewall issue. Just add an xlog into your opensips server and see that you will have no entries in syslog. The INVITE that is sent out is having the same Max-Forwards counter and you have a second Via with exactly the same branch parameter. Regards, Ovidiu Sas On Tue, Feb 8, 2011 at 3:58 PM, Chris Stone axi...@gmail.com wrote: Ovidiu, On Tue, Feb 8, 2011 at 1:16 PM, Ovidiu Sas o...@voipembedded.com wrote: 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. No firewall - though of that too at first. There is a PIX between the net and the servers, but not between the Opensips server and the Asterisk server. The packet capture showing the modifications to the INVITES was from the Opensips server - in-n-out. No firewall involved at that point. The Opensips server is 67.212.153.178 and it's forwarding to the Asterisk server which is at 67.212.153.179. Due to previous issues with the sip fixup in PIX firewalls, that it disabled in the PIX we're using. But again, this modification is being done after the PIX hands it off to the Opensips server Thanks! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu,
On Tue, Feb 8, 2011 at 2:31 PM, Ovidiu Sas o...@voipembedded.com wrote:
You din't posted a proper SIP capture (no UDP src/dst IP for your
packets), but it seems that you are having a firewall issue. Just add
I agree that it almost sounds like a firewall issue butI
completely disabled iptables on the server and tested again - issue
persists...
So the only other firewall is the PIX - external to this server. All
of the protocol fixup in it for SIP is disabled. Not sure how the PIX
can play in here when:
UPSTREAM PROVIDER
|
|
PIX Firewall
|
|
Cisco 12 port Switch
| |
| |
OpenSIPS Asterisk
Once the INVITE comes in, it would not see the PIX again - goes to
Opensips and then Asterisk.
an xlog into your opensips server and see that you will have no
entries in syslog.
Added: xlog(L_ERR, [method=$rm, from=$fu, to=$ru, src_ip=$si]\n);
tested another call and the log entries do so up:
Feb 8 17:22:53 mars /usr/sbin/opensips[7046]:
INFO:core:probe_max_receive_buffer: using a UDP receive buffer of 255
kb
Feb 8 17:23:04 mars /usr/sbin/opensips[7058]: INFO:core:buf_init:
initializing...
Feb 8 17:23:04 mars /usr/sbin/opensips[7058]: [method=INVITE,
from=sip:+13038382386@208.94.157.10:5060,
to=sip:17204497101@67.212.153.178:5060;transport=udp,
src_ip=208.94.157.10]
Feb 8 17:23:07 mars /usr/sbin/opensips[7066]: INFO:core:buf_init:
initializing...
Feb 8 17:23:07 mars /usr/sbin/opensips[7066]: [method=ACK,
from=sip:+13038382386@208.94.157.10:5060,
to=sip:17204497101@67.212.153.179:5060, src_ip=208.94.157.10]
Feb 8 17:23:18 mars /usr/sbin/opensips[7058]: [method=BYE,
from=sip:+13038382386@208.94.157.10:5060,
to=sip:17204497101@67.212.153.179:5060, src_ip=208.94.157.10]
The INVITE that is sent out is having the same Max-Forwards counter
and you have a second Via with exactly the same branch parameter.
Would that not be then the result some 'default' within Opensips since
it's occurring with such a basic simple config? The config just calls
forward() essentially. No modules are loaded or initialized and the
route() block looks simply like:
route{
xlog(L_ERR, [method=$rm, from=$fu, to=$ru, src_ip=$si]\n);
forward(67.212.153.179);
exit;
}
Thanks!
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Chris,
What does an ngrep trace on the interface (interfaces?) of the machine
show? Are the packets changed when they leave the machine? In that
case it must be happening on that machine, i.e. no external firewall
munging. If that is the case then run OpenSIPS with debug level 9 or
so, save the output and then grep on the 2 different IP adresses that
are in the incoming/outgoing contact header to see why that header is
being changed. That might give a clue as to the SDP routing.
Cheers,
Henk Hesselink
On 09-02-11 01:28, Chris Stone wrote:
Ovidiu,
On Tue, Feb 8, 2011 at 2:31 PM, Ovidiu Saso...@voipembedded.com wrote:
You din't posted a proper SIP capture (no UDP src/dst IP for your
packets), but it seems that you are having a firewall issue. Just add
I agree that it almost sounds like a firewall issue butI
completely disabled iptables on the server and tested again - issue
persists...
So the only other firewall is the PIX - external to this server. All
of the protocol fixup in it for SIP is disabled. Not sure how the PIX
can play in here when:
UPSTREAM PROVIDER
|
|
PIX Firewall
|
|
Cisco 12 port Switch
| |
| |
OpenSIPS Asterisk
Once the INVITE comes in, it would not see the PIX again - goes to
Opensips and then Asterisk.
an xlog into your opensips server and see that you will have no
entries in syslog.
Added: xlog(L_ERR, [method=$rm, from=$fu, to=$ru, src_ip=$si]\n);
tested another call and the log entries do so up:
Feb 8 17:22:53 mars /usr/sbin/opensips[7046]:
INFO:core:probe_max_receive_buffer: using a UDP receive buffer of 255
kb
Feb 8 17:23:04 mars /usr/sbin/opensips[7058]: INFO:core:buf_init:
initializing...
Feb 8 17:23:04 mars /usr/sbin/opensips[7058]: [method=INVITE,
from=sip:+13038382386@208.94.157.10:5060,
to=sip:17204497101@67.212.153.178:5060;transport=udp,
src_ip=208.94.157.10]
Feb 8 17:23:07 mars /usr/sbin/opensips[7066]: INFO:core:buf_init:
initializing...
Feb 8 17:23:07 mars /usr/sbin/opensips[7066]: [method=ACK,
from=sip:+13038382386@208.94.157.10:5060,
to=sip:17204497101@67.212.153.179:5060, src_ip=208.94.157.10]
Feb 8 17:23:18 mars /usr/sbin/opensips[7058]: [method=BYE,
from=sip:+13038382386@208.94.157.10:5060,
to=sip:17204497101@67.212.153.179:5060, src_ip=208.94.157.10]
The INVITE that is sent out is having the same Max-Forwards counter
and you have a second Via with exactly the same branch parameter.
Would that not be then the result some 'default' within Opensips since
it's occurring with such a basic simple config? The config just calls
forward() essentially. No modules are loaded or initialized and the
route() block looks simply like:
route{
xlog(L_ERR, [method=$rm, from=$fu, to=$ru, src_ip=$si]\n);
forward(67.212.153.179);
exit;
}
Thanks!
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
You are re-posting the same question again without providing any additional info: http://lists.opensips.org/pipermail/users/2011-February/016626.html Regards, Ovidiu Sas On Mon, Feb 7, 2011 at 12:20 PM, Chris Stone axi...@gmail.com wrote: We have an Opensips 1.4 installation that routes calls to multiple Asterisk servers. We have a perl module that Opensips runs that does an SQL query to find the Asterisk server that the call should be sent to. All works great and Opensips handles only the SIP traffic - all the SDP/RTP traffic is between the UAs and the Asterisk servers. Getting a new Opensips server ready to go online. Using the same config (with minor changes such as the addition of loading signal.so, removing xlog.so, etc) and Opensips 1.6.3. In testing, I was finding there was no audio (either direction) for calls. Did a packet capture on the Asterisk server and Opensips server and found that the outgoing SDP/RTP packets were also being routed by Asterisk back to the Opensips server and the incoming packets were also going to Opensips. This is not what I want - would like the same behavior as we have with 1.4 where only the SIP traffic goes through the Opensips server. Have done a good amount of research to resolve this and I am not finding anything helpful. Can anyone tell me why I am seeing this change in 1.6 v.s. 1.4 and how I can get 1.6 to behave the same as with 1.4 with regards to the audio traffic? Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
On Mon, Feb 7, 2011 at 10:35 AM, Ovidiu Sas o...@voipembedded.com wrote:
You are re-posting the same question again without providing any
additional info:
http://lists.opensips.org/pipermail/users/2011-February/016626.html
Sorry, did not see my original message in my Gmail sent messages, or a
reply - so, figured it did not get sent and resent.
Have you checked if the your config is altering the SDP?
Check the SDP for the same message before coming to your opensips
server and after leaving the opensips server.
If the SDP is altered and the IP in SDP is pointing to your opensips
server, then there is your problem.
The config does nothing with the SDP. The config is nearly identical
(is identical functionality wise) to what we're running with Opensips
1.4. Was there some 'default' behavior change between 1.4 and 1.6 that
might be the cause?
For reference, here's our config for the 1.6 installation:
### Global Parameters #
#debug=3
debug=9
log_stderror=no
#log_facility=LOG_LOCAL0
fork=yes
children=25
/* uncomment the following lines to enable TLS support (default off) */
#disable_tls = no
#listen = tls:your_IP:5061
#tls_verify_server = 1
#tls_verify_client = 1
#tls_require_client_certificate = 0
#tls_method = TLSv1
#tls_certificate = /etc/opensips/tls/user/user-cert.pem
#tls_private_key = /etc/opensips/tls/user/user-privkey.pem
#tls_ca_list = /etc/opensips/tls/user/user-calist.pem
port=5060
sip_warning=1
tos=IPTOS_LOWDELAY
### Modules Section
#set module path
mpath=/usr/lib64/opensips/modules
/* uncomment next line for MySQL DB support */
loadmodule signaling.so
loadmodule sl.so
loadmodule tm.so
loadmodule rr.so
loadmodule maxfwd.so
loadmodule textops.so
loadmodule mi_fifo.so
loadmodule uri.so
loadmodule acc.so
loadmodule avpops.so
loadmodule perl.so
# originate/terminate permissions
loadmodule permissions.so
# dispatcher
loadmodule dispatcher.so
# - setting module-specific parameters ---
# - mi_fifo params -
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
# - rr params -
# add value to ;lr param to cope with most of the UAs
modparam(rr, enable_full_lr, 1)
# do not append from tag to the RR (no need for this script)
modparam(rr, append_fromtag, 0)
# - uri params -
modparam(uri, use_uri_table, 0)
# - acc params -
/* what sepcial events should be accounted ? */
modparam(acc, early_media, 1)
modparam(acc, report_ack, 1)
modparam(acc, report_cancels, 1)
/* by default ww do not adjust the direct of the sequential requests.
if you enable this parameter, be sure the enable append_fromtag
in rr module */
modparam(acc, detect_direction, 0)
/* account triggers (flags) */
modparam(acc, failed_transaction_flag, 3)
modparam(acc, log_flag, 1)
modparam(acc, log_missed_flag, 2)
/* uncomment the following lines to enable DB accounting also */
modparam(acc, db_flag, 1)
modparam(acc, db_missed_flag, 2)
# - perl params -
modparam(perl, modpath, /usr/lib64/opensips/modules/)
modparam(perl, filename, /usr/local/sbin/perl_sql_routing.pl)
# - permissions params -
modparam(permissions, default_deny_file, /etc/opensips/permissions.deny)
modparam(permissions, default_allow_file, /etc/opensips/permissions.allow)
# - dispatcher params
modparam(dispatcher,list_file,/etc/opensips/dispatcher.list)
modparam(dispatcher,force_dst,1)
modparam(dispatcher,flags,3)
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, grp_avp, $avp(i:272))
modparam(dispatcher, cnt_avp, $avp(i:273))
### Routing Logic
# main request routing logic
route{
if (!mf_process_maxfwd_header(32)) {
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [483 - Too Many Hops]\n);
sl_send_reply(483,Too Many Hops);
exit;
}
if (msg:len 16384 ) {
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [413 - Message is too big - greater than 16384
bytes]\n);
sl_send_reply(413, Message is too big - greater
than 16384 bytes]);
exit;
};
if (is_method(REGISTER)) {
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [503 - Registration Unavailable]\n);
sl_send_reply(503, Registration Unavailable via
this proxy - contact supp...@axint.net for assistance);
exit;
}
if (is_method(PUBLISH))
{
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [503 - Publish Service Unavailable]\n);
sl_send_reply(503, Service Unavailable);
exit;
}
if (has_totag()) {
#xlog(L_ERR, Request has_totag(). Request: $rm
from $fu to $tu r-uri $ru src_ip $si\n);
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Just capture a call that is going through your SIP proxy and check the
SDP in the received and sent INVITE and the SDP in the received and
sent 200ok. The connection IP and port for each SDP should be the
same (untouched).
If it's untouched, then your opensips config is working as expected
and your RTP problem is somewhere else.
Regards,
Ovidiu Sas
On Mon, Feb 7, 2011 at 1:10 PM, Chris Stone axi...@gmail.com wrote:
On Mon, Feb 7, 2011 at 10:35 AM, Ovidiu Sas o...@voipembedded.com wrote:
You are re-posting the same question again without providing any
additional info:
http://lists.opensips.org/pipermail/users/2011-February/016626.html
Sorry, did not see my original message in my Gmail sent messages, or a
reply - so, figured it did not get sent and resent.
Have you checked if the your config is altering the SDP?
Check the SDP for the same message before coming to your opensips
server and after leaving the opensips server.
If the SDP is altered and the IP in SDP is pointing to your opensips
server, then there is your problem.
The config does nothing with the SDP. The config is nearly identical
(is identical functionality wise) to what we're running with Opensips
1.4. Was there some 'default' behavior change between 1.4 and 1.6 that
might be the cause?
For reference, here's our config for the 1.6 installation:
### Global Parameters #
#debug=3
debug=9
log_stderror=no
#log_facility=LOG_LOCAL0
fork=yes
children=25
/* uncomment the following lines to enable TLS support (default off) */
#disable_tls = no
#listen = tls:your_IP:5061
#tls_verify_server = 1
#tls_verify_client = 1
#tls_require_client_certificate = 0
#tls_method = TLSv1
#tls_certificate = /etc/opensips/tls/user/user-cert.pem
#tls_private_key = /etc/opensips/tls/user/user-privkey.pem
#tls_ca_list = /etc/opensips/tls/user/user-calist.pem
port=5060
sip_warning=1
tos=IPTOS_LOWDELAY
### Modules Section
#set module path
mpath=/usr/lib64/opensips/modules
/* uncomment next line for MySQL DB support */
loadmodule signaling.so
loadmodule sl.so
loadmodule tm.so
loadmodule rr.so
loadmodule maxfwd.so
loadmodule textops.so
loadmodule mi_fifo.so
loadmodule uri.so
loadmodule acc.so
loadmodule avpops.so
loadmodule perl.so
# originate/terminate permissions
loadmodule permissions.so
# dispatcher
loadmodule dispatcher.so
# - setting module-specific parameters ---
# - mi_fifo params -
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
# - rr params -
# add value to ;lr param to cope with most of the UAs
modparam(rr, enable_full_lr, 1)
# do not append from tag to the RR (no need for this script)
modparam(rr, append_fromtag, 0)
# - uri params -
modparam(uri, use_uri_table, 0)
# - acc params -
/* what sepcial events should be accounted ? */
modparam(acc, early_media, 1)
modparam(acc, report_ack, 1)
modparam(acc, report_cancels, 1)
/* by default ww do not adjust the direct of the sequential requests.
if you enable this parameter, be sure the enable append_fromtag
in rr module */
modparam(acc, detect_direction, 0)
/* account triggers (flags) */
modparam(acc, failed_transaction_flag, 3)
modparam(acc, log_flag, 1)
modparam(acc, log_missed_flag, 2)
/* uncomment the following lines to enable DB accounting also */
modparam(acc, db_flag, 1)
modparam(acc, db_missed_flag, 2)
# - perl params -
modparam(perl, modpath, /usr/lib64/opensips/modules/)
modparam(perl, filename, /usr/local/sbin/perl_sql_routing.pl)
# - permissions params -
modparam(permissions, default_deny_file, /etc/opensips/permissions.deny)
modparam(permissions, default_allow_file,
/etc/opensips/permissions.allow)
# - dispatcher params
modparam(dispatcher,list_file,/etc/opensips/dispatcher.list)
modparam(dispatcher,force_dst,1)
modparam(dispatcher,flags,3)
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, grp_avp, $avp(i:272))
modparam(dispatcher, cnt_avp, $avp(i:273))
### Routing Logic
# main request routing logic
route{
if (!mf_process_maxfwd_header(32)) {
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [483 - Too Many Hops]\n);
sl_send_reply(483,Too Many Hops);
exit;
}
if (msg:len 16384 ) {
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [413 - Message is too big - greater than 16384
bytes]\n);
sl_send_reply(413, Message is too big - greater
than 16384 bytes]);
exit;
};
if (is_method(REGISTER)) {
xlog(L_ERR, $rm from $fu to $tu r-uri $ru
src_ip $si [503 - Registration Unavailable]\n);
sl_send_reply(503, Registration Unavailable via
this proxy - contact supp...@axint.net for assistance);
exit;
}
if (is_method(PUBLISH))
{
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu, On Mon, Feb 7, 2011 at 11:22 AM, Ovidiu Sas o...@voipembedded.com wrote: Just capture a call that is going through your SIP proxy and check the SDP in the received and sent INVITE and the SDP in the received and sent 200ok. The connection IP and port for each SDP should be the same (untouched). If it's untouched, then your opensips config is working as expected and your RTP problem is somewhere else. As I was seeing traffic wise, OpenSIPS is modifying the INVITE and putting it's own IP where my 1.4 installation is putting my upstream provider's IP. Both of these are the SIP body text showing what I am referring to. Both are inbound calls. First, to our OpenSIPS 1.4 installation from upstream and from that installation to our Asterisk box (this is working as we want): v=0\r\n o=PVG 1297116052450 1297116052450 IN IP4 199.173.80.118\r\n s=-\r\n p=+1 613555\r\n c=IN IP4 199.173.80.118\r\n t=0 0\r\n m=audio 52056 RTP/AVP 18 0 8 101\r\n a=rtpmap:101 telephone-event/8000\r\n a=fmtp:101 0-15\r\n a=ptime:20\r\n a=fmtp:18 annexb=no\r\n v=0\r\n o=PVG 1297116052450 1297116052450 IN IP4 199.173.80.118\r\n s=-\r\n p=+1 613555\r\n c=IN IP4 199.173.80.118\r\n t=0 0\r\n m=audio 52056 RTP/AVP 18 0 8 101\r\n a=rtpmap:101 telephone-event/8000\r\n a=fmtp:101 0-15\r\n a=ptime:20\r\n a=fmtp:18 annexb=no\r\n Note that 199.173.80.118 is my upstream provider. And then from upstream to our OpenSIPS 1.6 installation and from that installation to our Asterisk box (not working right - SDP is being relayed via OpenSIPS): 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 25682 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 v=0\r\n o=Acme_UAS 0 1 IN IP4 67.112.153.182\r\n s=SIP Media Capabilities\r\n c=IN IP4 67.112.153.182\r\n t=0 0\r\n m=audio 25682 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 Note that 208.94.157.1 is my upstream provider and 67.112.153.182 is the OpenSIPS 1.6 server. So, yes, looks like the issue is in Opensips. As I noted though, we're using the same config with 1.6 (posted in previous message) as we have running on 1.4. So not sure why now OpenSIPS is modifying and putting itself in the relay path for SDP when we only want that for SIP as with 1.4. Thanks and any ideas? Is there some default for this that may have changed from 1.4 to 1.6 that I missed in the upgrade docs? Best Regards, Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
By default, opensips does not modify the SDP. Double check your config. If you don't need to touch SDP, make sure that you are not loading nathelper or mediaproxy. Those are the two modules that are changing SDP. Regards, Ovidiu Sas On Mon, Feb 7, 2011 at 5:39 PM, Chris Stone axi...@gmail.com wrote: Ovidiu, On Mon, Feb 7, 2011 at 11:22 AM, Ovidiu Sas o...@voipembedded.com wrote: Just capture a call that is going through your SIP proxy and check the SDP in the received and sent INVITE and the SDP in the received and sent 200ok. The connection IP and port for each SDP should be the same (untouched). If it's untouched, then your opensips config is working as expected and your RTP problem is somewhere else. As I was seeing traffic wise, OpenSIPS is modifying the INVITE and putting it's own IP where my 1.4 installation is putting my upstream provider's IP. Both of these are the SIP body text showing what I am referring to. Both are inbound calls. First, to our OpenSIPS 1.4 installation from upstream and from that installation to our Asterisk box (this is working as we want): v=0\r\n o=PVG 1297116052450 1297116052450 IN IP4 199.173.80.118\r\n s=-\r\n p=+1 613555\r\n c=IN IP4 199.173.80.118\r\n t=0 0\r\n m=audio 52056 RTP/AVP 18 0 8 101\r\n a=rtpmap:101 telephone-event/8000\r\n a=fmtp:101 0-15\r\n a=ptime:20\r\n a=fmtp:18 annexb=no\r\n v=0\r\n o=PVG 1297116052450 1297116052450 IN IP4 199.173.80.118\r\n s=-\r\n p=+1 613555\r\n c=IN IP4 199.173.80.118\r\n t=0 0\r\n m=audio 52056 RTP/AVP 18 0 8 101\r\n a=rtpmap:101 telephone-event/8000\r\n a=fmtp:101 0-15\r\n a=ptime:20\r\n a=fmtp:18 annexb=no\r\n Note that 199.173.80.118 is my upstream provider. And then from upstream to our OpenSIPS 1.6 installation and from that installation to our Asterisk box (not working right - SDP is being relayed via OpenSIPS): 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 25682 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 v=0\r\n o=Acme_UAS 0 1 IN IP4 67.112.153.182\r\n s=SIP Media Capabilities\r\n c=IN IP4 67.112.153.182\r\n t=0 0\r\n m=audio 25682 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 Note that 208.94.157.1 is my upstream provider and 67.112.153.182 is the OpenSIPS 1.6 server. So, yes, looks like the issue is in Opensips. As I noted though, we're using the same config with 1.6 (posted in previous message) as we have running on 1.4. So not sure why now OpenSIPS is modifying and putting itself in the relay path for SDP when we only want that for SIP as with 1.4. Thanks and any ideas? Is there some default for this that may have changed from 1.4 to 1.6 that I missed in the upgrade docs? Best Regards, Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Ovidiu,
On Mon, Feb 7, 2011 at 4:19 PM, Ovidiu Sas o...@voipembedded.com wrote:
By default, opensips does not modify the SDP.
Double check your config. If you don't need to touch SDP, make sure
that you are not loading nathelper or mediaproxy. Those are the two
modules that are changing SDP.
Made sure neither of these were being loaded and used - mediaproxy
was, but nathelper was not. I need neither, so removed, restarted
opensips, tested a call. No change - problem persisted. So, dropped
down to a bare config:
#---
debug=9 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
children=25
check_via=no # (cmd. line: -v)
dns=off # (cmd. line: -r)
rev_dns=off # (cmd. line: -R)
port=5060
# for more info: sip_router -h
# -- module loading --
mpath=/usr/lib64/opensips/modules
# - setting module-specific parameters ---
route{
forward(67.212.153.179);
exit;
}
#---
Restarted OpenSIPS with the above, and problem persists - SDP routing
modified (apparently) and Opensips proxies the audio.
Incoming from upstream:
INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0\r\n
From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
To: sip:17204497101@67.212.153.178:5060\r\n
Call-ID:
CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a@208.94.157.10\r\n
CSeq: 1 INVITE\r\n
Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Max-Forwards: 69\r\n
P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060\r\n
Supported: timer,100rel\r\n
Content-Disposition: session;handling=required\r\n
Contact:
sip:+13038382386@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 22684 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 to Asterisk:
INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0\r\n
From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
To: sip:17204497101@67.212.153.178:5060\r\n
Call-ID:
CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a@208.94.157.10\r\n
CSeq: 1 INVITE\r\n
Via: SIP/2.0/UDP
67.212.153.178:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Max-Forwards: 69\r\n
P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060\r\n
Supported: timer,100rel\r\n
Content-Disposition: session;handling=required\r\n
Contact:
sip:+13038382386@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 22684 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
I've got to be missing something stupid - the setup works great under
1.4 - would expect as well or better under 1.6 - but appears that
there's some config option or default that I'm missing
But, with such a basic config as above, not sure what it would
be.Would sure seem that, by some default, OpenSIPS proxies the
audio, no?
Thanks!
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Hi Chris,
That config should't touch the Contact header, and yet that's also been
modified:
In: Contact:sip:+13038382386@208.94.157.10 ...
Out: Contact:sip:+13038382386@67.212.153.178 ...
Are you sure nothing else is touching the message?
Regards,
Henk Hesselink
On 08-02-11 02:33, Chris Stone wrote:
Ovidiu,
On Mon, Feb 7, 2011 at 4:19 PM, Ovidiu Saso...@voipembedded.com wrote:
By default, opensips does not modify the SDP.
Double check your config. If you don't need to touch SDP, make sure
that you are not loading nathelper or mediaproxy. Those are the two
modules that are changing SDP.
Made sure neither of these were being loaded and used - mediaproxy
was, but nathelper was not. I need neither, so removed, restarted
opensips, tested a call. No change - problem persisted. So, dropped
down to a bare config:
#---
debug=9 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
children=25
check_via=no # (cmd. line: -v)
dns=off # (cmd. line: -r)
rev_dns=off # (cmd. line: -R)
port=5060
# for more info: sip_router -h
# -- module loading --
mpath=/usr/lib64/opensips/modules
# - setting module-specific parameters ---
route{
forward(67.212.153.179);
exit;
}
#---
Restarted OpenSIPS with the above, and problem persists - SDP routing
modified (apparently) and Opensips proxies the audio.
Incoming from upstream:
INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0\r\n
From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
To:sip:17204497101@67.212.153.178:5060\r\n
Call-ID:
CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a@208.94.157.10\r\n
CSeq: 1 INVITE\r\n
Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Max-Forwards: 69\r\n
P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060\r\n
Supported: timer,100rel\r\n
Content-Disposition: session;handling=required\r\n
Contact:sip:+13038382386@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 22684 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 to Asterisk:
INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0\r\n
From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
To:sip:17204497101@67.212.153.178:5060\r\n
Call-ID:
CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a@208.94.157.10\r\n
CSeq: 1 INVITE\r\n
Via: SIP/2.0/UDP
67.212.153.178:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Max-Forwards: 69\r\n
P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060\r\n
Supported: timer,100rel\r\n
Content-Disposition: session;handling=required\r\n
Contact:sip:+13038382386@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 22684 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
I've got to be missing something stupid - the setup works great under
1.4 - would expect as well or better under 1.6 - but appears that
there's some config option or default that I'm missing
But, with such a basic config as above, not sure what it would
be.Would sure seem that, by some default, OpenSIPS proxies the
audio, no?
Thanks!
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
On Mon, Feb 7, 2011 at 6:48 PM, Henk Hesselink opensips-us...@voipro.nl wrote:
Hi Chris,
That config should't touch the Contact header, and yet that's also been
modified:
In: Contact:sip:+13038382386@208.94.157.10 ...
Out: Contact:sip:+13038382386@67.212.153.178 ...
Are you sure nothing else is touching the message?
Regards,
Henk Hesselink
On 08-02-11 02:33, Chris Stone wrote:
Ovidiu,
On Mon, Feb 7, 2011 at 4:19 PM, Ovidiu Saso...@voipembedded.com wrote:
By default, opensips does not modify the SDP.
Double check your config. If you don't need to touch SDP, make sure
that you are not loading nathelper or mediaproxy. Those are the two
modules that are changing SDP.
Made sure neither of these were being loaded and used - mediaproxy
was, but nathelper was not. I need neither, so removed, restarted
opensips, tested a call. No change - problem persisted. So, dropped
down to a bare config:
#---
debug=9 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
children=25
check_via=no # (cmd. line: -v)
dns=off # (cmd. line: -r)
rev_dns=off # (cmd. line: -R)
port=5060
# for more info: sip_router -h
# -- module loading --
mpath=/usr/lib64/opensips/modules
# - setting module-specific parameters ---
route{
forward(67.212.153.179);
exit;
}
#---
Restarted OpenSIPS with the above, and problem persists - SDP routing
modified (apparently) and Opensips proxies the audio.
Incoming from upstream:
INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0\r\n
From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
To:sip:17204497101@67.212.153.178:5060\r\n
Call-ID:
CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a@208.94.157.10\r\n
CSeq: 1 INVITE\r\n
Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Max-Forwards: 69\r\n
P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060\r\n
Supported: timer,100rel\r\n
Content-Disposition: session;handling=required\r\n
Contact:sip:+13038382386@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 22684 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 to Asterisk:
INVITE sip:17204497101@67.212.153.178:5060;transport=udp SIP/2.0\r\n
From: STONE C AND C
sip:+13038382386@208.94.157.10:5060;tag=a9d5ed0-13c4-4d509b92-1bc5e644-648c7598\r\n
To:sip:17204497101@67.212.153.178:5060\r\n
Call-ID:
CXC-260-758763d0-a9d5ed0-13c4-4d509b92-1bc5e643-43d2bf0a@208.94.157.10\r\n
CSeq: 1 INVITE\r\n
Via: SIP/2.0/UDP
67.212.153.178:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Via: SIP/2.0/UDP
208.94.157.10:5060;branch=z9hG4bK-11150e-4d509b92-1bc5e644-273291f1\r\n
Max-Forwards: 69\r\n
P-Asserted-Identity: STONE C AND C
sip:+13038382...@cxc.dashcs.com:5060\r\n
Supported: timer,100rel\r\n
Content-Disposition: session;handling=required\r\n
Contact:sip:+13038382386@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 22684 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
I've got to be missing something stupid - the setup works great under
1.4 - would expect as well or better under 1.6 - but appears that
there's some config option or default that I'm missing
But, with such a basic config as above, not sure what it would
be.Would sure seem that, by some default, OpenSIPS proxies the
audio, no?
Thanks!
Chris
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Sorry all for the last message - too quick on the Send button. On Mon, Feb 7, 2011 at 6:48 PM, Henk Hesselink opensips-us...@voipro.nl wrote: Hi Chris, That config should't touch the Contact header, and yet that's also been modified: In: Contact:sip:+13038382386@208.94.157.10 ... Out: Contact:sip:+13038382386@67.212.153.178 ... Are you sure nothing else is touching the message? Yes, absolutely. The packets were captured on the Opensips server - in from upstream provider and then the next packet relaying the invite to backend Asterisk server. The upstream provider is, of course, on a remote network. The Asterisk server is on the same LAN - only a switch separating the 2 servers. The only application on the server that touched the packets would be Opensips. So I'm not nuts - something very weird is going on here eh? Regards, Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
On Mon, Feb 7, 2011 at 9:14 PM, Chris Stone axi...@gmail.com wrote: Sorry all for the last message - too quick on the Send button. On Mon, Feb 7, 2011 at 6:48 PM, Henk Hesselink opensips-us...@voipro.nl wrote: Hi Chris, That config should't touch the Contact header, and yet that's also been modified: In: Contact:sip:+13038382386@208.94.157.10 ... Out: Contact:sip:+13038382386@67.212.153.178 ... Are you sure nothing else is touching the message? Yes, absolutely. The packets were captured on the Opensips server - in from upstream provider and then the next packet relaying the invite to backend Asterisk server. The upstream provider is, of course, on a remote network. The Asterisk server is on the same LAN - only a switch separating the 2 servers. The only application on the server that touched the packets would be Opensips. So I'm not nuts - something very weird is going on here eh? Yes. For sure you are using a different config. Are you running multiple servers on that box? Or are you having some virtual machines there? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
On Mon, Feb 7, 2011 at 7:05 PM, Ovidiu Sas o...@voipembedded.com wrote:
On Mon, Feb 7, 2011 at 9:14 PM, Chris Stone axi...@gmail.com wrote:
Sorry all for the last message - too quick on the Send button.
On Mon, Feb 7, 2011 at 6:48 PM, Henk Hesselink opensips-us...@voipro.nl
wrote:
Hi Chris,
That config should't touch the Contact header, and yet that's also been
modified:
In: Contact:sip:+13038382386@208.94.157.10 ...
Out: Contact:sip:+13038382386@67.212.153.178 ...
Are you sure nothing else is touching the message?
Yes, absolutely. The packets were captured on the Opensips server - in
from upstream provider and then the next packet relaying the invite to
backend Asterisk server. The upstream provider is, of course, on a
remote network. The Asterisk server is on the same LAN - only a switch
separating the 2 servers. The only application on the server that
touched the packets would be Opensips.
So I'm not nuts - something very weird is going on here eh?
Yes. For sure you are using a different config.
Are you running multiple servers on that box?
Or are you having some virtual machines there?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Don't know what tools you are familiar with so here are some
suggestions for what they're worth.
what is listening on port 5060?
netstat -lnp | grep 5060
is opensips actually running? what was the command line used?
ps aux --forest | grep opensips
Does sip still pass when opensips is not running?
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?
If something else is listening on port 5060 opensips should be failing
to start with the provided config.
try running single mode with the following config:
#---
debug=9 # debug level (cmd line: -dd)
fork=no
log_stderror=yes # (cmd line: -E)
children=1
check_via=no # (cmd. line: -v)
dns=off # (cmd. line: -r)
rev_dns=off # (cmd. line: -R)
port=5060
# for more info: opensips -h
# -- 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\ntesttest \n\n\n);
forward(67.212.153.179);
exit;
}
and run it with:
/usr/sbin/opensips -f config file path/opensips.cfg 21 | tee test.log
(path to opensips executable based on your mpath in the config.
you should get a boat load of debug go past your screen when it starts
and for any message that goes through opensips.
To stop it just do CTRL+C
The debug went in to test.log as well as to the screen so you can look
in it and search for the testtest to see if it handled the
message. Or details of why it failed to start.
Happy hunting.
Dave
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Have you checked if the your config is altering the SDP? Check the SDP for the same message before coming to your opensips server and after leaving the opensips server. If the SDP is altered and the IP in SDP is pointing to your opensips server, then there is your problem. Regards, Ovidiu Sas On Fri, Feb 4, 2011 at 7:53 PM, Chris Stone axi...@gmail.com wrote: Hello - We have an Opensips 1.4 server that routes incoming calls to a couple of different Asterisk servers and to upstream providers. All working great and with the current config, the Opensips server only handles the SIP traffic - all of the audio is between the UAs and Asterisk servers. Am building another Opensips server and decided to do it with the 1.6.3 release. With virtually the same config (really only had to change a couple of things at the top like loading signal.so, dropping the loading of xlog.so, etc), now Opensips is in the picture for all of the audio as well as SIP traffic. Was troubleshooting an issue with no audio in either direction when calling in - so was capturing traffic on the Opensips server, saw the SIP traffic, call relayed correctly to the Asterisk server where and IVR was played and all the audio was going back to the Opensips server. Did the same test on the Opensips 1.4 server and no audio packets - which is what I want. Done a days searching and am not finding the fix. Someone know what changed and how I can get the same behavior I have with 1.4 with the 1.6 release? Thanks! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Change in SDP/RTP routing with Opensips 1.4 and 1.6
Hello - We have an Opensips 1.4 server that routes incoming calls to a couple of different Asterisk servers and to upstream providers. All working great and with the current config, the Opensips server only handles the SIP traffic - all of the audio is between the UAs and Asterisk servers. Am building another Opensips server and decided to do it with the 1.6.3 release. With virtually the same config (really only had to change a couple of things at the top like loading signal.so, dropping the loading of xlog.so, etc), now Opensips is in the picture for all of the audio as well as SIP traffic. Was troubleshooting an issue with no audio in either direction when calling in - so was capturing traffic on the Opensips server, saw the SIP traffic, call relayed correctly to the Asterisk server where and IVR was played and all the audio was going back to the Opensips server. Did the same test on the Opensips 1.4 server and no audio packets - which is what I want. Done a days searching and am not finding the fix. Someone know what changed and how I can get the same behavior I have with 1.4 with the 1.6 release? Thanks! Chris ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
