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
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
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
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,
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
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
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
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
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
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
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
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
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:
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
34 matches
Mail list logo
