Re: [OpenSIPS-Users] Dialplan module and matching numbers

[SamyGo]

Hey,

I think using this would help

if( $tU =~ "1234567890")
{
   $avp(gid) = 1;
}else if( $tU =~ " 9876543210  "){
$avp(gid) = 2;
}
if (!load_balance("$avp(gid)","transc;pstn")) {
 sl_send_reply("500","Service full");
 exit;
}

engage load-balancerto
use $avp(gid) where group_id=1/2 contains pool of servers serving your
required destination number!

I hope this helped.


BR,
Sammy.


On Thu, Apr 5, 2012 at 12:02 AM, Ali Pey  wrote:

> Hello,
>
> I need to match some destination numbers to specific servers. For instance
> if the call is to 1234567890 go to server 1 and if it is to 9876543210 go
> to server 2, etc.
>
> The purpose is to look up some numbers or patterns and then route to
> specific servers and use the load balancer module for any other numbers.
>
> Can I use the dial plan module to lookup the destinations?
>
> I don't understand the dpid. Do I need a dpid for each number? Can all my
> rows have the same dpid?
> How can I do one look up to see if the dialed number is in the dialplan
> table? It can be hundreds of numbers.
>
> Regards,
> Ali
>
>
> ___
> 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] ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/

[Rudy]

Flavio,

 If I am not mistaken, this may have been fixed after the release of
1.7.2, make sure you are building from SVN
https://opensips.svn.sourceforge.net/svnroot/opensips/branches/1.7  to
ensure you got the fix(es) .

Regards,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )



On Wed, Apr 4, 2012 at 7:44 PM, Flavio Goncalves
 wrote:
> Hi Rudy,
>
> Thanks for your reply, I'm using 1.7.2, The validate_dialog was commented, I
> will enable it later and check the results.
>
> Best Regards,
>
> Flavio E. Goncalves
>
>
>
>
> On Wed, Apr 4, 2012 at 8:25 PM, Rudy  wrote:
>>
>> Hey Flavio!
>>
>>  Hope all is well in Brazil. Is this the latest 1.8.x branch? Also,
>> are you using validate_dialog() and fix_route_dialog()  in your loose
>> route ? I remember something similar with CANCELs of early dialogs
>> happening to us. The issue I am mentioning was patched sometime ago...
>>
>> Regards,
>> --Rudy
>> Dynamic Packet
>> Toll-Free: 888.929.VOIP ( 8647 )
>>
>>
>>
>> On Wed, Apr 4, 2012 at 6:27 PM, Flavio Goncalves 
>> wrote:
>> >
>> > Hi,
>> >
>> > I'm receiving some push_reply errors. I've checked the logs and traces
>> > and I
>> > can't spot the problem. Any help would be welcome, below the debug of
>> > the
>> > exact moment of the error. .
>> >
>> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_check:
>> > start=0x
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:parse_headers:
>> > flags=20
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str
>> > 20 :
>> > 0
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str
>> > 20 :
>> > 0
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
>> > DBG:tm:t_should_relay_response:
>> > T_code=180, new_code=487
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_pick_branch: picked
>> > branch 1, code 487 (prio=0)
>> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:core:parse_headers:
>> > flags=22
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:is_3263_failure:
>> > dns-failover test: branch=1, last_recv=487, flags=2
>> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: hash
>> > 11246 label 479886256 branch 1
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_check_status:
>> > checked
>> > status is <487>
>> > Apr  4 18:43:32 sip last message repeated 2 times
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:relay_reply: branch=1,
>> > save=0, relay=1
>> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching:
>> > REF_UNSAFE:[0x7ffa2d3e1108] after is 2
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:run_trans_callbacks:
>> > trans=0x7ffa2d3e1108, callback type 8, id 0 entered
>> >
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
>> > ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/
>> >
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
>> > DBG:dialog:push_reply_in_dialog:
>> > 0x7ffa2cf8c708 totag in rpl is <> (0)
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
>> > DBG:dialog:push_reply_in_dialog:
>> > new branch with tag <>
>> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching:
>> > reply
>> > matched (T=0x7ffa2d3e1108)!
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:init_leg_info:
>> > route_set , contact , cseq 1 and bind_addr udp:200.201.194.226:5060
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:dlg_add_leg_info:
>> > set
>> > leg 2 for 0x7ffa2cf8c708: tag=<> rcseq=<1>
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
>> > DBG:core:build_res_buf_from_sip_res:  old size: 664, new size: 600
>> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
>> > DBG:core:build_res_buf_from_sip_res: copied size: orig:87, new: 23,
>> > rest:
>> > 577 msg= SIP/2.0 487 Cancelled^M Via: SIP/2.0/UDP
>> >
>> > 187.85.30.195;rport=5060;received=187.85.30.195;branch=z9hG4bKac1009787257^M
>> > Record-Route:
>> > ^M
>> > From: ;tag=1c1009364722^M To:
>> > ^M Call-ID:
>> > 10093260002622012195216@187.85.30.195^M CSeq: 1 INVITE^M Allow:
>> > INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER,PRACK,INFO,NOTIFY,REFER^M
>> > Cisco-Guid:
>> > 63185-1380843536-2264320347-2980804337^M Contact:
>> > ^M User-Agent: TELES.iGATE
>> > 39019358305613
>> > 14.6b 940^M Content-Length: 0^M ^M
>> >
>> > Flavio E. Goncalves
>> >
>> > ___
>> > 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
>
>
>
> ___
> 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] ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/

[Flavio Goncalves]

Hi Rudy,

Thanks for your reply, I'm using 1.7.2, The validate_dialog was commented,
I will enable it later and check the results.

Best Regards,

Flavio E. Goncalves




On Wed, Apr 4, 2012 at 8:25 PM, Rudy  wrote:

> Hey Flavio!
>
>  Hope all is well in Brazil. Is this the latest 1.8.x branch? Also,
> are you using validate_dialog() and fix_route_dialog()  in your loose
> route ? I remember something similar with CANCELs of early dialogs
> happening to us. The issue I am mentioning was patched sometime ago...
>
> Regards,
> --Rudy
> Dynamic Packet
> Toll-Free: 888.929.VOIP ( 8647 )
>
>
>
> On Wed, Apr 4, 2012 at 6:27 PM, Flavio Goncalves 
> wrote:
> >
> > Hi,
> >
> > I'm receiving some push_reply errors. I've checked the logs and traces
> and I
> > can't spot the problem. Any help would be welcome, below the debug of the
> > exact moment of the error. .
> >
> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_check:
> > start=0x
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:parse_headers:
> flags=20
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str
> 20 :
> > 0
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str
> 20 :
> > 0
> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
> DBG:tm:t_should_relay_response:
> > T_code=180, new_code=487
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_pick_branch: picked
> > branch 1, code 487 (prio=0)
> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:core:parse_headers:
> flags=22
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:is_3263_failure:
> > dns-failover test: branch=1, last_recv=487, flags=2
> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: hash
> > 11246 label 479886256 branch 1
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_check_status: checked
> > status is <487>
> > Apr  4 18:43:32 sip last message repeated 2 times
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:relay_reply: branch=1,
> > save=0, relay=1
> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching:
> > REF_UNSAFE:[0x7ffa2d3e1108] after is 2
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:run_trans_callbacks:
> > trans=0x7ffa2d3e1108, callback type 8, id 0 entered
> >
> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
> > ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/
> >
> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
> DBG:dialog:push_reply_in_dialog:
> > 0x7ffa2cf8c708 totag in rpl is <> (0)
> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
> DBG:dialog:push_reply_in_dialog:
> > new branch with tag <>
> > Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: reply
> > matched (T=0x7ffa2d3e1108)!
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:init_leg_info:
> > route_set , contact , cseq 1 and bind_addr udp:200.201.194.226:5060
> > Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:dlg_add_leg_info:
> set
> > leg 2 for 0x7ffa2cf8c708: tag=<> rcseq=<1>
> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
> > DBG:core:build_res_buf_from_sip_res:  old size: 664, new size: 600
> > Apr  4 18:43:32 sip /sbin/opensips[13239]:
> > DBG:core:build_res_buf_from_sip_res: copied size: orig:87, new: 23, rest:
> > 577 msg= SIP/2.0 487 Cancelled^M Via: SIP/2.0/UDP
> >
> 187.85.30.195;rport=5060;received=187.85.30.195;branch=z9hG4bKac1009787257^M
> > Record-Route:
> ^M
> > From: ;tag=1c1009364722^M To:
> > ^M Call-ID:
> > 10093260002622012195216@187.85.30.195^M CSeq: 1 INVITE^M Allow:
> > INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER,PRACK,INFO,NOTIFY,REFER^M
> Cisco-Guid:
> > 63185-1380843536-2264320347-2980804337^M Contact:
> > ^M User-Agent: TELES.iGATE
> 39019358305613
> > 14.6b 940^M Content-Length: 0^M ^M
> >
> > Flavio E. Goncalves
> >
> > ___
> > 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/

[Rudy]

Hey Flavio!

 Hope all is well in Brazil. Is this the latest 1.8.x branch? Also,
are you using validate_dialog() and fix_route_dialog()  in your loose
route ? I remember something similar with CANCELs of early dialogs
happening to us. The issue I am mentioning was patched sometime ago...

Regards,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )



On Wed, Apr 4, 2012 at 6:27 PM, Flavio Goncalves  wrote:
>
> Hi,
>
> I'm receiving some push_reply errors. I've checked the logs and traces and I
> can't spot the problem. Any help would be welcome, below the debug of the
> exact moment of the error. .
>
> Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_check:
> start=0x
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:parse_headers: flags=20
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str 20 :
> 0
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str 20 :
> 0
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_should_relay_response:
> T_code=180, new_code=487
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_pick_branch: picked
> branch 1, code 487 (prio=0)
> Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:core:parse_headers: flags=22
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:is_3263_failure:
> dns-failover test: branch=1, last_recv=487, flags=2
> Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: hash
> 11246 label 479886256 branch 1
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_check_status: checked
> status is <487>
> Apr  4 18:43:32 sip last message repeated 2 times
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:relay_reply: branch=1,
> save=0, relay=1
> Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching:
> REF_UNSAFE:[0x7ffa2d3e1108] after is 2
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:run_trans_callbacks:
> trans=0x7ffa2d3e1108, callback type 8, id 0 entered
>
> Apr  4 18:43:32 sip /sbin/opensips[13239]:
> ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/
>
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:push_reply_in_dialog:
> 0x7ffa2cf8c708 totag in rpl is <> (0)
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:push_reply_in_dialog:
> new branch with tag <>
> Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: reply
> matched (T=0x7ffa2d3e1108)!
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:init_leg_info:
> route_set , contact , cseq 1 and bind_addr udp:200.201.194.226:5060
> Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:dlg_add_leg_info: set
> leg 2 for 0x7ffa2cf8c708: tag=<> rcseq=<1>
> Apr  4 18:43:32 sip /sbin/opensips[13239]:
> DBG:core:build_res_buf_from_sip_res:  old size: 664, new size: 600
> Apr  4 18:43:32 sip /sbin/opensips[13239]:
> DBG:core:build_res_buf_from_sip_res: copied size: orig:87, new: 23, rest:
> 577 msg= SIP/2.0 487 Cancelled^M Via: SIP/2.0/UDP
> 187.85.30.195;rport=5060;received=187.85.30.195;branch=z9hG4bKac1009787257^M
> Record-Route: ^M
> From: ;tag=1c1009364722^M To:
> ^M Call-ID:
> 10093260002622012195216@187.85.30.195^M CSeq: 1 INVITE^M Allow:
> INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER,PRACK,INFO,NOTIFY,REFER^M Cisco-Guid:
> 63185-1380843536-2264320347-2980804337^M Contact:
> ^M User-Agent: TELES.iGATE 39019358305613
> 14.6b 940^M Content-Length: 0^M ^M
>
> Flavio E. Goncalves
>
> ___
> 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] ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/

[Flavio Goncalves]

Hi,

I'm receiving some push_reply errors. I've checked the logs and traces and
I can't spot the problem. Any help would be welcome, below the debug of the
exact moment of the error. .

Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_check:
start=0x
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:parse_headers: flags=20
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str 20
: 0
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:core:comp_scriptvar: str 20
: 0
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_should_relay_response:
T_code=180, new_code=487
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_pick_branch: picked
branch 1, code 487 (prio=0)
Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:core:parse_headers: flags=22
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:is_3263_failure:
dns-failover test: branch=1, last_recv=487, flags=2
Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: hash
11246 label 479886256 branch 1
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:t_check_status: checked
status is <487>
Apr  4 18:43:32 sip last message repeated 2 times
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:relay_reply: branch=1,
save=0, relay=1
Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching:
REF_UNSAFE:[0x7ffa2d3e1108] after is 2
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:tm:run_trans_callbacks:
trans=0x7ffa2d3e1108, callback type 8, id 0 entered

Apr  4 18:43:32 sip /sbin/opensips[13239]:
ERROR:dialog:push_reply_in_dialog: missing TAG param in TO hdr :-/

Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:push_reply_in_dialog:
0x7ffa2cf8c708 totag in rpl is <> (0)
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:push_reply_in_dialog:
new branch with tag <>
Apr  4 18:43:32 sip /sbin/opensips[13240]: DBG:tm:t_reply_matching: reply
matched (T=0x7ffa2d3e1108)!
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:init_leg_info:
route_set , contact , cseq 1 and bind_addr udp:200.201.194.226:5060
Apr  4 18:43:32 sip /sbin/opensips[13239]: DBG:dialog:dlg_add_leg_info: set
leg 2 for 0x7ffa2cf8c708: tag=<> rcseq=<1>
Apr  4 18:43:32 sip /sbin/opensips[13239]:
DBG:core:build_res_buf_from_sip_res:  old size: 664, new size: 600
Apr  4 18:43:32 sip /sbin/opensips[13239]:
DBG:core:build_res_buf_from_sip_res: copied size: orig:87, new: 23, rest:
577 msg= SIP/2.0 487 Cancelled^M Via: SIP/2.0/UDP
187.85.30.195;rport=5060;received=187.85.30.195;branch=z9hG4bKac1009787257^M
Record-Route: ^M
From: ;tag=1c1009364722^M To: <
sip:0153188831...@otimatelecom.com.br;user=phone>^M Call-ID:
10093260002622012195216@187.85.30.195^M CSeq: 1 INVITE^M Allow:
INVITE,ACK,CANCEL,BYE,UPDATE,REGISTER,PRACK,INFO,NOTIFY,REFER^M Cisco-Guid:
63185-1380843536-2264320347-2980804337^M Contact: <
sip:553188831616@187.50.189.54>^M User-Agent: TELES.iGATE 39019358305613
14.6b 940^M Content-Length: 0^M ^M

Flavio E. Goncalves
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] OpenSIPS running out of memory after a few hours

[Jock McKechnie]

In addition to my MediaProxy loading learnings I'm also discovering
that there appears to be some fiddling to get OpenSIPS to handle this
kind of loading as well. I have a fairly simple configuration which
engages media proxy and forwards packets onto a single destination
proxy (who then sends the calls onto the carrier).

When I load up OpenSIPs with around 1400 inuse_transactions it'll
click along for an hour or two and then it'll bomb out with:
WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation
ERROR:core:do_action: memory allocation failure

ERROR:nat_traversal:save_keepalive_state: failed to open keepalive
state file for writing: Permission denied
CRITICAL:core:sig_alarm_abort: BUG - shutdown timeout triggered, dying...

I'm using the Debianised 1.6.4-notls under a VM with 512MB of RAM. I
have OpenSIPs set to allow 128MB in /etc/default/opensips. We have
almost two hundred OpenSIPS proxies all running on 64M and I've
_never_ managed to make one croak, but I imagine this one is much more
heavily loaded due to the volume of calls along with the use of the
dialog module for mediaproxy.

>From when the proxy is first fired up, it's handling a fairly
consistent 1000-1400 transactions, but it takes at least an hour for
it to go over, which suggests to me that memory isn't being released
properly. I'd be happy to throw more memory at the issue... but if
it's not releasing then I'm left to wonder if there's a flaw that is
always going to cause this problem.

Am I barking up the wrong tree here, or is this known and there's a
reasonable solution, or?

My config, for reference, is here: http://pastebin.com/ZiWbK3GJ

As always, thank you very much;

 - Jock

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Dialog and avp_timeout

[Marcello Lupo]

Hi,
I'm using opensips 1.6.4 with dialog support.
I use dialog default timeout to close automatically calls after 3 hours and it 
works great.
Sometimes happen that some dialog remain in state 3 (200 OK received but ACK 
not received) till the default_timeout is reached.
I was trying to set default_timeout to 120 seconds and change the avp_timeout 
on the ACK to a greater value so the calls in state 3 will be automatically 
closed form the system after 120 sec.
I read around the docs that the timeout can be changed everywhere in the script 
after the dialog has been created but it is not working for me.

Every time the system give me:

DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout

and never update the timeout_avp.

I have in the config:

modparam("dialog", "default_timeout", 120)
modparam("dialog", "timeout_avp", "$avp(i:104)")
modparam("dialog", "bye_on_timeout_flag", 21)

In routing block when dialog start:

create_dialog();
setflag(21);


In routing block to check ACK:

if(method=="ACK" && $DLG_status!=NULL) {
$avp(i:104)="10800";
   # $avp(i:104)=10800;
setflag(21);
}

I tried to put the avp_timeout value as INT or as STRING but no difference. 
Looking in the source code seems that default_timeout is INT but timeout_avp 
expect string value.

Someone can help?
Thank you
Bye
Marcello


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Dialplan module and matching numbers

[Ali Pey]

Hello,

I need to match some destination numbers to specific servers. For instance
if the call is to 1234567890 go to server 1 and if it is to 9876543210 go
to server 2, etc.

The purpose is to look up some numbers or patterns and then route to
specific servers and use the load balancer module for any other numbers.

Can I use the dial plan module to lookup the destinations?

I don't understand the dpid. Do I need a dpid for each number? Can all my
rows have the same dpid?
How can I do one look up to see if the dialed number is in the dialplan
table? It can be hundreds of numbers.

Regards,
Ali
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MediaProxy loading issues - I think I need some tuning here

[Jock McKechnie]

>> I'm running a Deb Wheezy/Sid (unstable) release to keep up with the
>> latest dependencies for MediaProxy's build - which, I admit, I'm using
>> a build package from a few months ago.
>>
>> I've got iptables v1.4.12.2 running, with MediaProxy 2.5.1 (according
>> to the dpkg information after the debuild), so slightly behind that
>> fixed descriptor leak release.
>>
>> The loading on the box was clearly not right with whatever seems to be
>> going wrong, so my making any kind of assumptions on how well
>> MediaProxy works is unfair until I've got this sorted out.
>>
>
> The problem is indeed the file descriptor leak, which was fixed between 2.5.1 
> and 2.5.2. In case you want to verify this yourself, just use lsof on the 
> media-relay PID and start a call: 4 new descriptors will show up, but after 
> the call is ended they are not released.
>
> Please do upgrade to MediaProxy 2.5.2 and test again :-)
>
> FYI, we do have a public Debian repository with MediaProxy built for several 
> Debian and Ubuntu versions, check it out: 
> http://mediaproxy.ag-projects.com/projects/mediaproxy/wiki/InstallationGuide

Saúl,

You called it. Complete turn around in load-out - no more port
complaints and at 900 calls I'm seeing around 20% usage across four
cores. And the 'apt-get update' updates -relay for me, which I was
expecting to have to build (like I did initially), so I'm very
pleased.

When the system is humming along at 900 calls I started noticing these pop up:
warning: Aggregate speed calculation time exceeded 10ms: 10401us for
431 sessions
Googling shows that this is related to some statistics, so I've turned
it off for now to see how far I can push media-proxy.

Would you be able to recommend some other settings that I should make
to help mediaproxy-relay push as many calls as possible?

I'm very grateful for your help;

 - Jock

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] sip message enters on bucle

[Jorge Ortea]

Hi Bogdan,


Ok, now we known that is happening. But, is it logic? or is it a bug in 1.6.4.2 
version?


   Curiously this does not happen with UDP signaling.



Thanks.

Regards.

Date: Wed, 4 Apr 2012 18:19:04 +0300
From: bog...@opensips.org
To: dar...@hotmail.com
CC: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] sip message enters on bucle



  



  
  
Jorge,



the message is not looping, it is retransmitting - it is something
different. OpenSIPS tries to open a new TCP conn to the destination
(as there is no existing one), but it fails in timeout as you cannot
open a TCP conn somewhere behind a NAT.



Regards,

Bogdan



On 04/04/2012 06:06 PM, Jorge Ortea wrote:

  
  


Hi Bogdan,



Is correct, Z.Z.Z.Z:5062 is a public adress behind a NAT. I have
found that opensips haven't this tcp connection, now this
account has changed the public adress.



But the sip messages keeps in the loop. It's like if Opensips is
looking for a tcp connection that it hasn't ?¿



Thanks.

Regards.






  Date: Wed, 4 Apr 2012 17:38:31 +0300

  From: bog...@opensips.org

  To: dar...@hotmail.com

  CC: users@lists.opensips.org

  Subject: Re: [OpenSIPS-Users] sip message enters on bucle

  

  
  
  Hi Jorge,

  

  So opensips tries to send the BYE to Z.Z.Z.Z:5062 via TCP
  (guess based on Route hdrs), but nobody is listening on TCP -
  is this address pointing behind a NAT ? why is not accepting a
  new TCP connection.

  

  On the other side, what you can do is to reduce the timeout on
  TCP connection, so opensips will react sooner:

  http://www.opensips.org/Resources/DocsCoreFcn18#toc78

  

  Regards,

  Bogdan

  

  On 04/04/2012 05:16 PM, Jorge Ortea wrote:
  

 

  Hi Bogdan,

  

  Exactly, is ready, OpenSIPS try to reach to destination
  but now the account 2105 haven't the location: 
  Z.Z.Z.Z:5062

  

  In fact, when OpenSIPS try to reach to there, it write in
  log: (this account uses TLS signaling)

  

  Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
  ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from
  10 s 

  Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
  ERROR:core:tcpconn_connect: tcp_blocking_connect failed 

  Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
  ERROR:core:tcp_send: connect failed 

  Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
  ERROR:tm:msg_send: tcp_send failed 

  Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
  ERROR:tm:t_forward_nonack: sending request failed 

  

  Thus, how can i detect and avoid this ??

  

  Thanks.

  Regards.

  

  

  
Date: Wed, 4 Apr 2012 14:56:16
+0300

From: bog...@opensips.org

To: users@lists.opensips.org

CC: dar...@hotmail.com

Subject: Re: [OpenSIPS-Users] sip message enters on
bucle



Hi Jorge,



It looks like Asterisk generates the BYEs and
retransmits it because there is no reply coming back
from opensips. Normally the BYE is end 2 end replied (so
 

Re: [OpenSIPS-Users] sip message enters on bucle

[Bogdan-Andrei Iancu]

Jorge,

the message is not looping, it is retransmitting - it is something 
different. OpenSIPS tries to open a new TCP conn to the destination (as 
there is no existing one), but it fails in timeout as you cannot open a 
TCP conn somewhere behind a NAT.


Regards,
Bogdan

On 04/04/2012 06:06 PM, Jorge Ortea wrote:


Hi Bogdan,

Is correct, Z.Z.Z.Z:5062 is a public adress behind a NAT. I have found 
that opensips haven't this tcp connection, now this account has 
changed the public adress.


But the sip messages keeps in the loop. It's like if Opensips is 
looking for a tcp connection that it hasn't ?¿


Thanks.
Regards.



Date: Wed, 4 Apr 2012 17:38:31 +0300
From: bog...@opensips.org
To: dar...@hotmail.com
CC: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] sip message enters on bucle

Hi Jorge,

So opensips tries to send the BYE to Z.Z.Z.Z:5062 via TCP (guess based 
on Route hdrs), but nobody is listening on TCP - is this address 
pointing behind a NAT ? why is not accepting a new TCP connection.


On the other side, what you can do is to reduce the timeout on TCP 
connection, so opensips will react sooner:

http://www.opensips.org/Resources/DocsCoreFcn18#toc78

Regards,
Bogdan

On 04/04/2012 05:16 PM, Jorge Ortea wrote:


Hi Bogdan,

Exactly, is ready, OpenSIPS try to reach to destination but now
the account 2105 haven't the location:  Z.Z.Z.Z:5062

In fact, when OpenSIPS try to reach to there, it write in log:
(this account uses TLS signaling)


Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:core:tcpconn_connect: tcp_blocking_connect failed
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:core:tcp_send: connect failed
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:tm:msg_send: tcp_send failed
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:tm:t_forward_nonack: sending request failed

Thus, how can i detect and avoid this ??

Thanks.
Regards.



Date: Wed, 4 Apr 2012 14:56:16 +0300
From: bog...@opensips.org 
To: users@lists.opensips.org 
CC: dar...@hotmail.com 
Subject: Re: [OpenSIPS-Users] sip message enters on bucle

Hi Jorge,

It looks like Asterisk generates the BYEs and retransmits it
because there is no reply coming back from opensips. Normally the
BYE is end 2 end replied (so the other end device should generate
the reply for BYE).
But looking at the 477 reply you get from OpenSIPS, I suspect that
OpenSIPS was trying to forward the BYE request (maybe via TCP),
got blocked and failed at the end - this failure resulted in the
477 reply.

Check the opensips logs to see error when processing the BYE.

Regards,
Bogdan

On 04/04/2012 11:42 AM, Jorge Ortea wrote:

Hi,

I have the follow VoIP platform;  OpenSIPS 1.6.4.2-tls +
Mediaproxy 2.0 + a pair of Asterisks 1.4 (behind SER)

It works fine but sometimes a sip message enters on a loop.
Asterisk sends 5 sip messages at every turn


My logs in OpenSIPS:

Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]:
:: BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29

Re: [OpenSIPS-Users] MediaProxy loading issues - I think I need some tuning here

[Saúl Ibarra Corretgé]

Hi Jock,

On Apr 4, 2012, at 3:10 PM, Jock McKechnie wrote:

> Thank you, Saúl, for your swift reply.
> 
> I'm running a Deb Wheezy/Sid (unstable) release to keep up with the
> latest dependencies for MediaProxy's build - which, I admit, I'm using
> a build package from a few months ago.
> 
> I've got iptables v1.4.12.2 running, with MediaProxy 2.5.1 (according
> to the dpkg information after the debuild), so slightly behind that
> fixed descriptor leak release.
> 
> The loading on the box was clearly not right with whatever seems to be
> going wrong, so my making any kind of assumptions on how well
> MediaProxy works is unfair until I've got this sorted out.
> 

The problem is indeed the file descriptor leak, which was fixed between 2.5.1 
and 2.5.2. In case you want to verify this yourself, just use lsof on the 
media-relay PID and start a call: 4 new descriptors will show up, but after the 
call is ended they are not released.

Please do upgrade to MediaProxy 2.5.2 and test again :-)

FYI, we do have a public Debian repository with MediaProxy built for several 
Debian and Ubuntu versions, check it out: 
http://mediaproxy.ag-projects.com/projects/mediaproxy/wiki/InstallationGuide


Regards,

--
Saúl Ibarra Corretgé
AG Projects




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] sip message enters on bucle

[Jorge Ortea]

Hi Bogdan,

Is correct, Z.Z.Z.Z:5062 is a public adress behind a NAT. I have found that 
opensips haven't this tcp connection, now this account has changed the public 
adress.

But the sip messages keeps in the loop. It's like if Opensips is looking for a 
tcp connection that it hasn't ?¿

Thanks.
Regards.


Date: Wed, 4 Apr 2012 17:38:31 +0300
From: bog...@opensips.org
To: dar...@hotmail.com
CC: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] sip message enters on bucle



  



  
  
Hi Jorge,



So opensips tries to send the BYE to Z.Z.Z.Z:5062 via TCP (guess
based on Route hdrs), but nobody is listening on TCP - is this
address pointing behind a NAT ? why is not accepting a new TCP
connection.



On the other side, what you can do is to reduce the timeout on TCP
connection, so opensips will react sooner:

http://www.opensips.org/Resources/DocsCoreFcn18#toc78



Regards,

Bogdan



On 04/04/2012 05:16 PM, Jorge Ortea wrote:

  
  


Hi Bogdan,



Exactly, is ready, OpenSIPS try to reach to destination but now
the account 2105 haven't the location:  Z.Z.Z.Z:5062



In fact, when OpenSIPS try to reach to there, it write in
log: (this account uses TLS signaling)



Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: ::
BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
- Source: X.X.X.152

Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: ::
BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
- Source: X.X.X.152

Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: ::
BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
- Source: X.X.X.152

Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: ::
BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
- Source: X.X.X.152

Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: ::
BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
- Source: X.X.X.152

Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s


Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:core:tcpconn_connect: tcp_blocking_connect failed 

Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:core:tcp_send: connect failed 

Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:tm:msg_send: tcp_send failed 

Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]:
ERROR:tm:t_forward_nonack: sending request failed 



Thus, how can i detect and avoid this ??



Thanks.

Regards.






  Date: Wed, 4 Apr 2012 14:56:16 +0300

  From: bog...@opensips.org

  To: users@lists.opensips.org

  CC: dar...@hotmail.com

  Subject: Re: [OpenSIPS-Users] sip message enters on bucle

  

  
  
  Hi Jorge,

  

  It looks like Asterisk generates the BYEs and retransmits it
  because there is no reply coming back from opensips. Normally
  the BYE is end 2 end replied (so the other end device should
  generate the reply for BYE).

  But looking at the 477 reply you get from OpenSIPS, I suspect
  that OpenSIPS was trying to forward the BYE request (maybe via
  TCP), got blocked and failed at the end - this failure
  resulted in the 477 reply.

  

  Check the opensips logs to see error when processing the BYE.

  

  Regards,

  Bogdan

  

  On 04/04/2012 11:42 AM, Jorge Ortea wrote:
  

 Hi,

  

  I have the follow VoIP platform;  OpenSIPS 1.6.4.2-tls +
  Mediaproxy 2.0 + a pair of Asterisks 1.4 (behind SER)

  

  It works fine but sometimes a sip message enters on a
  loop. Asterisk sends 5 sip
  messages at every turn

  

  

  My logs in OpenSIPS:

  

  Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]:
  :: BYE - from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
  - Source: X.X.X.152

  Apr  4 10:14:19 alpha02 /usr/local/sbin/o

Re: [OpenSIPS-Users] sip message enters on bucle

[Bogdan-Andrei Iancu]

Hi Jorge,

So opensips tries to send the BYE to Z.Z.Z.Z:5062 via TCP (guess based 
on Route hdrs), but nobody is listening on TCP - is this address 
pointing behind a NAT ? why is not accepting a new TCP connection.


On the other side, what you can do is to reduce the timeout on TCP 
connection, so opensips will react sooner:

http://www.opensips.org/Resources/DocsCoreFcn18#toc78

Regards,
Bogdan

On 04/04/2012 05:16 PM, Jorge Ortea wrote:


Hi Bogdan,

Exactly, is ready, OpenSIPS try to reach to destination but now the 
account 2105 haven't the location:  Z.Z.Z.Z:5062


In fact, when OpenSIPS try to reach to there, it write in log: 
(this account uses TLS signaling)


Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 
 - Source: X.X.X.152
Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 
 - Source: X.X.X.152
Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 
 - Source: X.X.X.152
Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 
 - Source: X.X.X.152
Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 
 - Source: X.X.X.152
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:core:tcpconn_connect: tcp_blocking_connect failed
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:core:tcp_send: connect failed
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:tm:msg_send: tcp_send failed
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:tm:t_forward_nonack: sending request failed


Thus, how can i detect and avoid this ??

Thanks.
Regards.



Date: Wed, 4 Apr 2012 14:56:16 +0300
From: bog...@opensips.org
To: users@lists.opensips.org
CC: dar...@hotmail.com
Subject: Re: [OpenSIPS-Users] sip message enters on bucle

Hi Jorge,

It looks like Asterisk generates the BYEs and retransmits it because 
there is no reply coming back from opensips. Normally the BYE is end 2 
end replied (so the other end device should generate the reply for BYE).
But looking at the 477 reply you get from OpenSIPS, I suspect that 
OpenSIPS was trying to forward the BYE request (maybe via TCP), got 
blocked and failed at the end - this failure resulted in the 477 reply.


Check the opensips logs to see error when processing the BYE.

Regards,
Bogdan

On 04/04/2012 11:42 AM, Jorge Ortea wrote:

Hi,

I have the follow VoIP platform;  OpenSIPS 1.6.4.2-tls +
Mediaproxy 2.0 + a pair of Asterisks 1.4 (behind SER)

It works fine but sometimes a sip message enters on a loop.
Asterisk sends 5 sip messages at every turn


My logs in OpenSIPS:

Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152
Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
 - Source:
X.X.X.152



Sip messages in Asterisk *CLI> 'sip debug':

set_destination: Parsing
 for address/port to
send to
set_destination: set destination to X.X.X.150, port 5060
Reliably Transmitting (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK

Re: [OpenSIPS-Users] sip message enters on bucle

[Jorge Ortea]

Hi Bogdan,

Exactly, is ready, OpenSIPS try to reach to destination but now the account 
2105 haven't the location:  Z.Z.Z.Z:5062

In fact, when OpenSIPS try to reach to there, it write in log: (this 
account uses TLS signaling)

Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s 
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:core:tcpconn_connect: tcp_blocking_connect failed 
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: ERROR:core:tcp_send: 
connect failed 
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: ERROR:tm:msg_send: 
tcp_send failed 
Apr  4 10:14:27 alpha02 /usr/local/sbin/opensips[29503]: 
ERROR:tm:t_forward_nonack: sending request failed 

Thus, how can i detect and avoid this ??

Thanks.
Regards.


Date: Wed, 4 Apr 2012 14:56:16 +0300
From: bog...@opensips.org
To: users@lists.opensips.org
CC: dar...@hotmail.com
Subject: Re: [OpenSIPS-Users] sip message enters on bucle



  



  
  
Hi Jorge,



It looks like Asterisk generates the BYEs and retransmits it because
there is no reply coming back from opensips. Normally the BYE is end
2 end replied (so the other end device should generate the reply for
BYE).

But looking at the 477 reply you get from OpenSIPS, I suspect that
OpenSIPS was trying to forward the BYE request (maybe via TCP), got
blocked and failed at the end - this failure resulted in the 477
reply.



Check the opensips logs to see error when processing the BYE.



Regards,

Bogdan



On 04/04/2012 11:42 AM, Jorge Ortea wrote:

  
  
Hi,



I have the follow VoIP platform;  OpenSIPS 1.6.4.2-tls +
Mediaproxy 2.0 + a pair of Asterisks 1.4 (behind SER)



It works fine but sometimes a sip message enters on a loop. Asterisk
  sends 5 sip messages at
every turn





My logs in OpenSIPS:



Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: ::
BYE - from 9 to O2105 - Callid:
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152

  





Sip messages in Asterisk *CLI> 'sip debug':



set_destination: Parsing
 for
address/port to send to

set_destination: set destination to X.X.X.150, port 5060

Reliably Transmitting (no NAT) to X.X.X.150:5060:

BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0

Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport

Route:
,

From: "9" ;tag=as167eb28e

To: ;tag=bcd482cd12b8a21i0

Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152

CSeq: 2874 BYE

User-Agent: Asterisk PBX

Max-Forwards: 70

X-Asterisk-HangupCause: Normal Clearing

X-Asterisk-HangupCauseCode: 16

Content-Length: 0





---

Scheduling destruction of SIP dialog
'5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152' in 32000 ms
(Method: REFER)

Retransmitting #1 (no NAT) to X.X.X.150:5060:

BYE sip:2105@Z.Z.Z.Z:5062;transport=tls

Re: [OpenSIPS-Users] MediaProxy loading issues - I think I need some tuning here

[Jock McKechnie]

Thank you, Saúl, for your swift reply.

I'm running a Deb Wheezy/Sid (unstable) release to keep up with the
latest dependencies for MediaProxy's build - which, I admit, I'm using
a build package from a few months ago.

I've got iptables v1.4.12.2 running, with MediaProxy 2.5.1 (according
to the dpkg information after the debuild), so slightly behind that
fixed descriptor leak release.

The loading on the box was clearly not right with whatever seems to be
going wrong, so my making any kind of assumptions on how well
MediaProxy works is unfair until I've got this sorted out.

Thank you, again.

 - JP


On Wed, Apr 4, 2012 at 1:46 AM, Saúl Ibarra Corretgé
 wrote:
> Hi Jock,
>
> What MediaProxy version are you running?
>
> On Apr 3, 2012, at 10:50 PM, Jock McKechnie wrote:
>
>> Greetings all;
>>
>> We have several mediaproxy systems running in small scale production
>> (~50-100 calls concurrently) and have been very pleased with the
>> results. We find that we have to restart the relay/dispatcher machines
>> daily to keep them ticking over (they tend to get lost on their own
>> after a few days runtime), but this is a minor inconvenience.
>>
>
> What do you mean by "get lost on their own"?
>
>> Until today. Today I tried moving one of our small carrier circuits
>> over to it and gee whiz did all sorts of exciting things happen. I
>> have our systems set up with an initial OpenSIPS/media-dispatcher
>> running on a VM (public IP). This dispatcher speaks to a blade server
>> which is running a single media-relay instance.
>>
>> Under light load all is well. When the load starts ramping up (800+
>> calls) thing start going a bit pear-shaped, however. I end up with
>> massive numbers of entries like this in the syslog of the relay:
>> Cannot use port pair 53378/53379
>> Which appears to bog the whole relay down to the point where it's
>> using 100% of the core. Even after turning the calls back off, the
>> -relay remains at 100% and continues to dump more 'Cannot use port
>> pair' notices into rsyslog and is impossible to stop normally due to
>> it being so tied up. rsyslog was not loaded out in the 'top', so
>> although it was clearly being hammered by -relay, I don't think
>> rsyslog was the bottleneck here.
>>
>
> There was a very nasty bug after an API change in iptables which caused 
> socket descriptors to be leaked, which led to this situation. What version of 
> iptables are you using? (iptables -V).
>
>> I guess my first question is, what am I doing wrong here to cause it
>> to be pushing literally tens of thousands of these errors?
>>
>> And then, next, how do I best tune mediaproxy to handle larger loads?
>> I was thinking I could run several -relays on a single blade as they
>> appear to be single-threaded and, therefore, multiple forks will load
>> across the machine properly... but I'm not even sure if -relay can use
>> a different conf file to the default.
>>
>
> Yes, MediaProxy is single threaded, but the actual relaying of packets happen 
> in *kernel space*, not in that single thread. Thus, you shouldn't run more 
> than one relay in a single box, and that's why it's not even supported. If 
> one box it's not enough, just add another one with another instance of 
> MediaProxy relay :-)
>
>> The dispatcher, which as I said lives on the OpenSIPS vm, looks like this:
>> [Dispatcher]
>> socket_path=/tmp/dispatcher.sock
>> listen=dispatcher.public.ip.address
>> management_use_tls=no
>> log_level=WARNING
>>
>> The relay, on a Dell M610 blade, looks like:
>> [Relay]
>> dispatchers=dispatcher.public.ip.address
>> relay_ip=relay.public.ip.address
>> port_range=5:6
>> log_level=WARNING
>>
>> Any suggestions would be gratefully received;
>>
>
>
> Regards,
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>
> ___
> 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] Opensips 1.6.2-notls - Died

[Wesley Volcov]

Dear Bogdan,

Ok, thank you!

I'm going to upgrade my opensips version.

Regards,

On 4 April 2012 08:49, Bogdan-Andrei Iancu  wrote:

> **
> Hi Wesley,
>
> It seems to be a bug in opensips in nathelper module (the module that
> drives the RTPProxy).
>
> Regards,
> Bogdan
>
>
> On 04/04/2012 02:19 PM, Wesley Volcov wrote:
>
> Hello Bogdan,
>
> Thank you for replying me!
>
> So, I forgot to mention that I use the rtpproxy 1.2.1 version too. And,
> when I disable the rtpproxy, I don't have this problem, my openips just
> work very fine, without die.
>
> When the problem occurs, the rtpproxy process appers OK, runing fine, just
> the opensips gone away.
>
> If it's a realy openips bug,  I think there is no problem to upgrade this
> to the last one version (1.8 I guess).
>
> Do think it's a openips bug or a rtpproxy bug ?
>
> Regards
>
>
> On 4 April 2012 05:03, Bogdan-Andrei Iancu  wrote:
>
>>  Hello Wesley,
>>
>> 1.6.2 is really old - like 4 major releases ago and 1.6 is not even
>> maintained anymore. Are there any chances to upgrade to a newer version ? A
>> lot of bugs were fixed in the mean while. If the upgrade is not an option,
>> I will try to help you in debugging the problem.
>>
>> Regards,
>> Bogdan
>>
>>
>> On 04/03/2012 03:20 PM, Wesley Volcov wrote:
>>
>>  Dear list,
>>
>> In the last days, I'm having problems with my opensips server. It just
>> died!
>>
>> In the log files I see:
>>
>> /usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: child process 9365
>> exited by a signal 11
>> /usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: core was generated
>> /usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: terminating due to
>> SIGCHLD
>> /usr/local/sbin/opensips[9364]: INFO:core:sig_usr: signal 15 received
>> /usr/local/sbin/opensips[9368]: INFO:core:sig_usr: signal 15 received
>> /usr/local/sbin/opensips[9369]: INFO:core:sig_usr: signal 15 received
>> /usr/local/sbin/opensips[9366]: INFO:core:sig_usr: signal 15 received
>> /usr/local/sbin/opensips[9367]: INFO:core:sig_usr: signal 15 received
>> /usr/local/sbin/opensips[9363]: INFO:core:sig_usr: signal 15 received
>> /usr/local/sbin/opensips[9361]: INFO:db_mysql:get_new_stmt_ctx: disconect
>> event for 0x81d13d0
>> /usr/local/sbin/opensips[9361]: INFO:db_mysql:reset_all_statements:
>> reseting all statements on connection: (0x81d1ac4) 0x81d13d0
>> /usr/local/sbin/opensips[9361]: INFO:db_mysql:get_new_stmt_ctx:
>> re-connected successful for 0x81d13d0
>>
>> I see 2 core files each one with different information. I have opened it
>> with gdb program and did a bt full command to see the full information.
>>
>> Could someone help me?
>>
>> Follow the core files information:
>>
>>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>


-- 
Wesley Volcov
Email: wesleyvol...@gmail.com
Messenger: vol...@live.com
Mobile: +55 11 7999-7444
Website: http://volcov.blogspot.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] load_balancer

[Miha]

Hi @SamyGo and Bodan,

thank you very much for all your help:)

I think I need a bit more reading about opensips configuration. So I 
will first read few things and that ask questions, I think this would be 
better:)


Thank you very much for all your help!

Reagrds,
Miha

On 4/4/2012 1:59 PM, Bogdan-Andrei Iancu wrote:
Currently there is no such function in LB (not even in trunk) - I 
added a "feature request" on tracker, so we will add it in the next 
versions.


Regards,
Bogdan

On 04/04/2012 12:08 PM, SamyGo wrote:


that would be great, in fact I am currently installing latest 1.8 
version and I guess I saw these functions appearing somewhere !! - 
that would really make life easier :)

Thanks Sir. :)

On Wed, Apr 4, 2012 at 1:17 PM, Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


Hi Sammy,

I was thinking to simplify a bit this and to add to LB module a
function like lb_is_from_peer() , to test if an IP + port matches
on of the peers defined in LB...

Regards,
Bogdan


On 04/04/2012 10:23 AM, SamyGo wrote:

Hi Miha,

I do exactly what Bogdan said, but using DB connecitons. IF its
an Initial INVITE connect to DB and query table load_balancer
and see if the source ip of INVITE matches any of the
load_balanaced FS servers then I know that its from
inside-media-serves to outside.

The next thing is identifying what original destination your FS
was trying to send the calls to i.e carrier-ip / uri !

So in your FS dialplan add a sip header where you store the real
destination of the SBC/trunk and once you are in the IF
condition where you detect your internal FS servers, strip off
that header  change the $ru and t-relay the call !!

phone(dial 007@FS )<===> FS (P-Real-DST: CAR.RIE.R.IP & dial
007@OpenSIPS )<>OpenSIPS(0...@car.rie.r.ip
)<===> ITSP(0...@car.rie.r.ip
 )

I hope this is what you wanted.

Regards,
Sammy

On Wed, Apr 4, 2012 at 11:49 AM, Miha mailto:m...@softnet.si>> wrote:

Hi Bogan,

that is a bit tricky as phones are registering on Opensips
server. If I make this that the phones will not register as
FSs servers are on different ips than SBC.

What would you sugget?

Regards,
Miha


On 4/2/2012 6:30 PM, Bogdan-Andrei Iancu wrote:

Hi Miha,

Well, in your script, when dealing with the initial
requests, just look at the source IP of the INVITEs - if
from SBC, do the lb stuff, otherwise route it back to SBC.
   if (src_ip==11.22.33.44) {
   # do LB
   } else {
# send to SBC
   }

Regards,
Bogdan

On 04/02/2012 09:30 AM, Miha wrote:

Hi,

as I am dealing with opensips for the first time I
would ask you for a little help.
I have installed and configured opensips that works
like load_balancer

(http://wiki.freeswitch.org/wiki/Enterprise_deployment_OpenSIPS).

I tested it and works. Than I have created siptrunk
and point it to Opensips. Opensips was balacing the
calls to one of the FSs, that I have set in opensips
configuration.

How can I now configure opensips, if the call is
made from FS, that opensips will send it to SBC
(from where sip trunk is made), so that the calls
will be working in both direction?


Thanks!

Miha

___
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





-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
http://www.opensips-solutions.com





--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


___
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] load_balancer

[Bogdan-Andrei Iancu]

Currently there is no such function in LB (not even in trunk) - I added 
a "feature request" on tracker, so we will add it in the next versions.


Regards,
Bogdan

On 04/04/2012 12:08 PM, SamyGo wrote:


that would be great, in fact I am currently installing latest 1.8 
version and I guess I saw these functions appearing somewhere !! - 
that would really make life easier :)

Thanks Sir. :)

On Wed, Apr 4, 2012 at 1:17 PM, Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


Hi Sammy,

I was thinking to simplify a bit this and to add to LB module a
function like lb_is_from_peer() , to test if an IP + port matches
on of the peers defined in LB...

Regards,
Bogdan


On 04/04/2012 10:23 AM, SamyGo wrote:

Hi Miha,

I do exactly what Bogdan said, but using DB connecitons. IF its
an Initial INVITE connect to DB and query table load_balancer and
see if the source ip of INVITE matches any of the load_balanaced
FS servers then I know that its from inside-media-serves to outside.

The next thing is identifying what original destination your FS
was trying to send the calls to i.e carrier-ip / uri !

So in your FS dialplan add a sip header where you store the real
destination of the SBC/trunk and once you are in the IF condition
where you detect your internal FS servers, strip off that header
 change the $ru and t-relay the call !!

phone(dial 007@FS )<===> FS (P-Real-DST: CAR.RIE.R.IP & dial
007@OpenSIPS )<>OpenSIPS(0...@car.rie.r.ip
)<===> ITSP(0...@car.rie.r.ip
 )

I hope this is what you wanted.

Regards,
Sammy

On Wed, Apr 4, 2012 at 11:49 AM, Miha mailto:m...@softnet.si>> wrote:

Hi Bogan,

that is a bit tricky as phones are registering on Opensips
server. If I make this that the phones will not register as
FSs servers are on different ips than SBC.

What would you sugget?

Regards,
Miha


On 4/2/2012 6:30 PM, Bogdan-Andrei Iancu wrote:

Hi Miha,

Well, in your script, when dealing with the initial
requests, just look at the source IP of the INVITEs - if
from SBC, do the lb stuff, otherwise route it back to SBC.
   if (src_ip==11.22.33.44) {
   # do LB
   } else {
# send to SBC
   }

Regards,
Bogdan

On 04/02/2012 09:30 AM, Miha wrote:

Hi,

as I am dealing with opensips for the first time I
would ask you for a little help.
I have installed and configured opensips that works
like load_balancer

(http://wiki.freeswitch.org/wiki/Enterprise_deployment_OpenSIPS).

I tested it and works. Than I have created siptrunk
and point it to Opensips. Opensips was balacing the
calls to one of the FSs, that I have set in opensips
configuration.

How can I now configure opensips, if the call is made
from FS, that opensips will send it to SBC (from
where sip trunk is made), so that the calls will be
working in both direction?


Thanks!

Miha

___
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





-- 
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
http://www.opensips-solutions.com





--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] sip message enters on bucle

[Bogdan-Andrei Iancu]

Hi Jorge,

It looks like Asterisk generates the BYEs and retransmits it because 
there is no reply coming back from opensips. Normally the BYE is end 2 
end replied (so the other end device should generate the reply for BYE).
But looking at the 477 reply you get from OpenSIPS, I suspect that 
OpenSIPS was trying to forward the BYE request (maybe via TCP), got 
blocked and failed at the end - this failure resulted in the 477 reply.


Check the opensips logs to see error when processing the BYE.

Regards,
Bogdan

On 04/04/2012 11:42 AM, Jorge Ortea wrote:

Hi,

I have the follow VoIP platform;  OpenSIPS 1.6.4.2-tls + Mediaproxy 
2.0 + a pair of Asterisks 1.4 (behind SER)


It works fine but sometimes a sip message enters on a loop. Asterisk 
sends 5 sip messages at every turn



My logs in OpenSIPS:

Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152
Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152
Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152
Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152
Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: :: BYE - 
from 9 to O2105 - Callid: 
5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - Source: X.X.X.152




Sip messages in Asterisk *CLI> 'sip debug':

set_destination: Parsing  
for address/port to send to

set_destination: set destination to X.X.X.150, port 5060
Reliably Transmitting (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,

From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Scheduling destruction of SIP dialog 
'5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152' in 32000 ms (Method: REFER)

Retransmitting #1 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,

From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Retransmitting #2 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,

From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Retransmitting #3 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,

From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Retransmitting #4 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,

From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---

<--- SIP read from X.X.X.150:5060 --->
SIP/2.0 477 Send failed (477/TM)
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport=5060
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
Server: OpenSIPS (1.6.4-2-tls (i386/linux))
Content-Length: 0


<->
--- (8 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived
-- Incoming call: Got SIP response 477 "Send failed (477/TM)" back 
from X.X.X.150




At the end, i have restart the asterisk to solve it. How can I avoid it ?


Thanks.
Regards.



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

___
Users 

Re: [OpenSIPS-Users] Opensips 1.6.2-notls - Died

[Bogdan-Andrei Iancu]

Hi Wesley,

It seems to be a bug in opensips in nathelper module (the module that 
drives the RTPProxy).


Regards,
Bogdan

On 04/04/2012 02:19 PM, Wesley Volcov wrote:

Hello Bogdan,

Thank you for replying me!

So, I forgot to mention that I use the rtpproxy 1.2.1 version too. 
And, when I disable the rtpproxy, I don't have this problem, my 
openips just work very fine, without die.


When the problem occurs, the rtpproxy process appers OK, runing fine, 
just the opensips gone away.


If it's a realy openips bug,  I think there is no problem to upgrade 
this to the last one version (1.8 I guess).


Do think it's a openips bug or a rtpproxy bug ?

Regards


On 4 April 2012 05:03, Bogdan-Andrei Iancu > wrote:


Hello Wesley,

1.6.2 is really old - like 4 major releases ago and 1.6 is not
even maintained anymore. Are there any chances to upgrade to a
newer version ? A lot of bugs were fixed in the mean while. If the
upgrade is not an option, I will try to help you in debugging the
problem.

Regards,
Bogdan


On 04/03/2012 03:20 PM, Wesley Volcov wrote:

Dear list,

In the last days, I'm having problems with my opensips server. It
just died!

In the log files I see:

/usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: child
process 9365 exited by a signal 11
/usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: core was
generated
/usr/local/sbin/opensips[9361]: INFO:core:handle_sigs:
terminating due to SIGCHLD
/usr/local/sbin/opensips[9364]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9368]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9369]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9366]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9367]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9363]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9361]: INFO:db_mysql:get_new_stmt_ctx:
disconect event for 0x81d13d0
/usr/local/sbin/opensips[9361]:
INFO:db_mysql:reset_all_statements: reseting all statements on
connection: (0x81d1ac4) 0x81d13d0
/usr/local/sbin/opensips[9361]: INFO:db_mysql:get_new_stmt_ctx:
re-connected successful for 0x81d13d0

I see 2 core files each one with different information. I have
opened it with gdb program and did a bt full command to see the
full information.

Could someone help me?

Follow the core files information:




--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] load_balancer

[SamyGo]

that would be great, in fact I am currently installing latest 1.8 version
and I guess I saw these functions appearing somewhere !! - that would
really make life easier :)
Thanks Sir. :)

On Wed, Apr 4, 2012 at 1:17 PM, Bogdan-Andrei Iancu wrote:

> **
> Hi Sammy,
>
> I was thinking to simplify a bit this and to add to LB module a function
> like lb_is_from_peer() , to test if an IP + port matches on of the peers
> defined in LB...
>
> Regards,
> Bogdan
>
>
> On 04/04/2012 10:23 AM, SamyGo wrote:
>
> Hi Miha,
>
>  I do exactly what Bogdan said, but using DB connecitons. IF its an
> Initial INVITE connect to DB and query table load_balancer and see if the
> source ip of INVITE matches any of the load_balanaced FS servers then I
> know that its from inside-media-serves to outside.
>
>  The next thing is identifying what original destination your FS was
> trying to send the calls to i.e carrier-ip / uri !
>
>  So in your FS dialplan add a sip header where you store the real
> destination of the SBC/trunk and once you are in the IF condition where you
> detect your internal FS servers, strip off that header  change the $ru and
> t-relay the call !!
>
>  phone(dial 007@FS )<===> FS (P-Real-DST: CAR.RIE.R.IP & dial 
> 007@OpenSIPS)<>OpenSIPS(
> 0...@car.rie.r.ip)<===> ITSP(0...@car.rie.r.ip )
>
>  I hope this is what you wanted.
>
>  Regards,
> Sammy
>
> On Wed, Apr 4, 2012 at 11:49 AM, Miha  wrote:
>
>> Hi Bogan,
>>
>> that is a bit tricky as phones are registering on Opensips server. If I
>> make this that the phones will not register as FSs servers are on different
>> ips than SBC.
>>
>> What would you sugget?
>>
>> Regards,
>> Miha
>>
>>
>> On 4/2/2012 6:30 PM, Bogdan-Andrei Iancu wrote:
>>
>>> Hi Miha,
>>>
>>> Well, in your script, when dealing with the initial requests, just look
>>> at the source IP of the INVITEs - if from SBC, do the lb stuff, otherwise
>>> route it back to SBC.
>>>if (src_ip==11.22.33.44) {
>>># do LB
>>>} else {
>>> # send to SBC
>>>}
>>>
>>> Regards,
>>> Bogdan
>>>
>>> On 04/02/2012 09:30 AM, Miha wrote:
>>>
 Hi,

 as I am dealing with opensips for the first time I would ask you for a
 little help.
 I have installed and configured opensips that works like load_balancer (
 http://wiki.freeswitch.org/wiki/Enterprise_deployment_OpenSIPS).

 I tested it and works. Than I have created siptrunk and point it to
 Opensips. Opensips was balacing the calls to one of the FSs, that I have
 set in opensips configuration.

 How can I now configure opensips, if the call is made from FS, that
 opensips will send it to SBC (from where sip trunk is made), so that the
 calls will be working in both direction?


 Thanks!

 Miha

 ___
 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
>>
>
>
>
> --
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] sip message enters on bucle

[Jorge Ortea]

Hi,

I have the follow VoIP platform;  OpenSIPS 1.6.4.2-tls + Mediaproxy 2.0 + a 
pair of Asterisks 1.4 (behind SER)

It works fine but sometimes a sip message enters on a loop. Asterisk sends 5 
sip messages at every turn


My logs in OpenSIPS:

Apr  4 10:14:17 alpha02 /usr/local/sbin/opensips[29503]: :: BYE - from 
9 to O2105 - Callid: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - 
Source: X.X.X.152
Apr  4 10:14:18 alpha02 /usr/local/sbin/opensips[29525]: :: BYE - from 
9 to O2105 - Callid: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - 
Source: X.X.X.152
Apr  4 10:14:19 alpha02 /usr/local/sbin/opensips[29497]: :: BYE - from 
9 to O2105 - Callid: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - 
Source: X.X.X.152
Apr  4 10:14:21 alpha02 /usr/local/sbin/opensips[29487]: :: BYE - from 
9 to O2105 - Callid: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - 
Source: X.X.X.152
Apr  4 10:14:25 alpha02 /usr/local/sbin/opensips[29511]: :: BYE - from 
9 to O2105 - Callid: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152 - 
Source: X.X.X.152
  


Sip messages in Asterisk *CLI> 'sip debug':

set_destination: Parsing  for 
address/port to send to
set_destination: set destination to X.X.X.150, port 5060
Reliably Transmitting (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Scheduling destruction of SIP dialog 
'5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152' in 32000 ms (Method: REFER)
Retransmitting #1 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Retransmitting #2 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Retransmitting #3 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
Retransmitting #4 (no NAT) to X.X.X.150:5060:
BYE sip:2105@Z.Z.Z.Z:5062;transport=tls SIP/2.0
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport
Route: 
,
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---

<--- SIP read from X.X.X.150:5060 --->
SIP/2.0 477 Send failed (477/TM)
Via: SIP/2.0/UDP X.X.X.152:5060;branch=z9hG4bK59044fff;rport=5060
From: "9" ;tag=as167eb28e
To: ;tag=bcd482cd12b8a21i0
Call-ID: 5b62cc795e6be4ea3fa9a26e543e3622@X.X.X.152
CSeq: 2874 BYE
Server: OpenSIPS (1.6.4-2-tls (i386/linux))
Content-Length: 0


<->
--- (8 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived
-- Incoming call: Got SIP response 477 "Send failed (477/TM)" back from 
X.X.X.150



At the end, i have restart the asterisk to solve it. How can I avoid it ?


Thanks.
Regards.


  ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] load_balancer

[Bogdan-Andrei Iancu]

Hi Sammy,

I was thinking to simplify a bit this and to add to LB module a function 
like lb_is_from_peer() , to test if an IP + port matches on of the peers 
defined in LB...


Regards,
Bogdan

On 04/04/2012 10:23 AM, SamyGo wrote:

Hi Miha,

I do exactly what Bogdan said, but using DB connecitons. IF its an 
Initial INVITE connect to DB and query table load_balancer and see if 
the source ip of INVITE matches any of the load_balanaced FS servers 
then I know that its from inside-media-serves to outside.


The next thing is identifying what original destination your FS was 
trying to send the calls to i.e carrier-ip / uri !


So in your FS dialplan add a sip header where you store the real 
destination of the SBC/trunk and once you are in the IF condition 
where you detect your internal FS servers, strip off that header 
 change the $ru and t-relay the call !!


phone(dial 007@FS )<===> FS (P-Real-DST: CAR.RIE.R.IP & dial 
007@OpenSIPS )<>OpenSIPS(0...@car.rie.r.ip)<===> 
ITSP(0...@car.rie.r.ip )


I hope this is what you wanted.

Regards,
Sammy

On Wed, Apr 4, 2012 at 11:49 AM, Miha > wrote:


Hi Bogan,

that is a bit tricky as phones are registering on Opensips server.
If I make this that the phones will not register as FSs servers
are on different ips than SBC.

What would you sugget?

Regards,
Miha


On 4/2/2012 6:30 PM, Bogdan-Andrei Iancu wrote:

Hi Miha,

Well, in your script, when dealing with the initial requests,
just look at the source IP of the INVITEs - if from SBC, do
the lb stuff, otherwise route it back to SBC.
   if (src_ip==11.22.33.44) {
   # do LB
   } else {
# send to SBC
   }

Regards,
Bogdan

On 04/02/2012 09:30 AM, Miha wrote:

Hi,

as I am dealing with opensips for the first time I would
ask you for a little help.
I have installed and configured opensips that works like
load_balancer
(http://wiki.freeswitch.org/wiki/Enterprise_deployment_OpenSIPS).

I tested it and works. Than I have created siptrunk and
point it to Opensips. Opensips was balacing the calls to
one of the FSs, that I have set in opensips configuration.

How can I now configure opensips, if the call is made from
FS, that opensips will send it to SBC (from where sip
trunk is made), so that the calls will be working in both
direction?


Thanks!

Miha

___
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





--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] load_balancer

[Bogdan-Andrei Iancu]

Hi,

Of course, use the logic I mentioned only for INVITE request, not for 
REGISTERs - you can do different routing logics depending on the method.


Regards,
Bogdan

On 04/04/2012 09:49 AM, Miha wrote:

Hi Bogan,

that is a bit tricky as phones are registering on Opensips server. If 
I make this that the phones will not register as FSs servers are on 
different ips than SBC.


What would you sugget?

Regards,
Miha

On 4/2/2012 6:30 PM, Bogdan-Andrei Iancu wrote:

Hi Miha,

Well, in your script, when dealing with the initial requests, just 
look at the source IP of the INVITEs - if from SBC, do the lb stuff, 
otherwise route it back to SBC.

if (src_ip==11.22.33.44) {
# do LB
} else {
 # send to SBC
}

Regards,
Bogdan

On 04/02/2012 09:30 AM, Miha wrote:

Hi,

as I am dealing with opensips for the first time I would ask you for 
a little help.
I have installed and configured opensips that works like 
load_balancer 
(http://wiki.freeswitch.org/wiki/Enterprise_deployment_OpenSIPS).


I tested it and works. Than I have created siptrunk and point it to 
Opensips. Opensips was balacing the calls to one of the FSs, that I 
have set in opensips configuration.


How can I now configure opensips, if the call is made from FS, that 
opensips will send it to SBC (from where sip trunk is made), so that 
the calls will be working in both direction?



Thanks!

Miha

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users









--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fix source IP in a 2-NICs router with openSIPS

[Bogdan-Andrei Iancu]

Hi Víctor,

You have to take care of 2 things:

1) signaling - for this you opensips should only do double RR to record 
the change of interface (in on priv IP and out on pub IP) - to have 
this, before pushing out the call to asterisk, do 
force_send_socket(pub_IP), so that a different interface will be 
selected as outbound.

For contact you do not have to do nothing.

2) media - insert RTPproxy which must be configured in bridging mode (to 
use 2 interfaces). And according to SIP traffic, you need to use the "e" 
or "i" flags (when invoking RTPproxy from script) in order to choose the 
proper IP for media. Like for INVITE (going from priv to pub) instruct 
RTPP to use the pub interface, for the 200 ok reply, need to use the 
priv interface.


Regards,
Bogdan

On 04/03/2012 04:31 PM, Víctor Fernández Martínez wrote:

Hi! I'm trying to set up OpenSIPS in a router with 2 NICs that performs a
dynamic NAT. It will receive requests from the UACs on eth0 (NIC behind NAT)
and should forward them through eth1 (public NIC) to an Asterisk outside of
the NAT. I'm not allowed to configure the Asterisk. I have also configured
rtpproxy and would like to use it in order to traverse the NAT. I have
openSIPS listening on both NICs, so the UACs inside of the NAT connect
directly to the socket of openSIPS in eth0.

The question is: I have tried to use fix_nated_contact() and fix_nated_sdp() but
they don't actually change the source IP, so I get no RTP traffic. Seems like
openSIPS doesn't realise there is a NAT, since it receives the requests
directly through its socket in the LAN. So when I use
rewritehostport("IP_OF_ASTERISK"), Asterisk is getting the LAN IPs instead of
the IP of eth1, which is the public IP. I'm using force_send_socket() to force
openSIPS to send the SIP messages to Asterisk through eth1. Is there some way
to fix the IPs so Asterisk gets the public IP (eth1)?

Thank you very much in advance.


Barracuda Networks AG
Vorsitzender des Aufsichtsrates/ Chairman of the supervisory board: Dean Drako
Vorstand/ Executive Board: Dr. Wieland Alge, Mag. Guenter Klausner
Sitz der Gesellschaft/ Registered office: 6020 Innsbruck, Austria
Handelsgericht Innsbruck Firmenbuch/ Registration Number: 184392s
UID-Nr/ VAT Number: ATU47509003

Diese Nachricht und allfaellige angehaengte Dokumente sind vertraulich und nur 
fuer den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Adressat 
sein, ist jede Offenlegung, Weiterleitung oder sonstige Verwendung dieser 
Information nicht gestattet. In diesem Fall bitten wir, den Absender zu 
verstaendigen und die Information zu vernichten. Fuer Uebermittlungsfehler oder 
sonstige Irrtuemer bei Uebermittlung besteht keine Haftung.

This message and any attached files are confidential and intended solely for 
the addressee(s). Any publication, transmission or other use of the information 
by a person or entity other than the intended addressee is prohibited. If you 
receive this in error please contact the sender and delete the material. The 
sender does not accept liability for any errors or omissions as a result of the 
transmission.


'Like' us on Facebook for exclusive content and other resources on all 
Barracuda Networks solutions.
Visit http://barracudanetworks.com/facebook



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips 1.6.2-notls - Died

[Bogdan-Andrei Iancu]

Hello Wesley,

1.6.2 is really old - like 4 major releases ago and 1.6 is not even 
maintained anymore. Are there any chances to upgrade to a newer version 
? A lot of bugs were fixed in the mean while. If the upgrade is not an 
option, I will try to help you in debugging the problem.


Regards,
Bogdan

On 04/03/2012 03:20 PM, Wesley Volcov wrote:

Dear list,

In the last days, I'm having problems with my opensips server. It just 
died!


In the log files I see:

/usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: child process 
9365 exited by a signal 11

/usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: core was generated
/usr/local/sbin/opensips[9361]: INFO:core:handle_sigs: terminating due 
to SIGCHLD

/usr/local/sbin/opensips[9364]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9368]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9369]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9366]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9367]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9363]: INFO:core:sig_usr: signal 15 received
/usr/local/sbin/opensips[9361]: INFO:db_mysql:get_new_stmt_ctx: 
disconect event for 0x81d13d0
/usr/local/sbin/opensips[9361]: INFO:db_mysql:reset_all_statements: 
reseting all statements on connection: (0x81d1ac4) 0x81d13d0
/usr/local/sbin/opensips[9361]: INFO:db_mysql:get_new_stmt_ctx: 
re-connected successful for 0x81d13d0


I see 2 core files each one with different information. I have opened 
it with gdb program and did a bt full command to see the full information.


Could someone help me?

Follow the core files information:

*CORE 1:*

re was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid 
-m 1024 -u root -g root'.

Program terminated with signal 11, Segmentation fault.
#0  0x002502a7 in unref_dlg (dlg=0x78136b98, cnt=1) at dlg_hash.c:587
587 d_entry = &(d_table->entries[dlg->h_entry]);

(gdb) bt full
#0  0x002502a7 in unref_dlg (dlg=0x78136b98, cnt=1) at dlg_hash.c:587
d_entry = 0x8c3abd8
__FUNCTION__ = "unref_dlg"
#1  0x00244fd4 in tmcb_unreference_dialog (t=0x7a8c1ad4, type=8192, 
param=0x1acd14) at dlg_handlers.c:518

No locals.
#2  0x001834c2 in run_trans_callbacks (type=8192, trans=0x7a8c1ad4, 
req=0x0, rpl=0x0, code=0) at t_hooks.c:208

cbp = 0x78173a8c
backup = 0x81a2504
trans_backup = 0x
__FUNCTION__ = "run_trans_callbacks"
#3  0x0016fa81 in free_cell (dead_cell=0x7a8c1ad4) at h_table.c:124
b = 
i = 
rpl = 
tt = 
foo = 
p = 
#4  0x0016fadb in free_hash_table () at h_table.c:342
p_cell = 0x267ccc
tmp_cell = 0x0
i = 1538
#5  0x0017dba4 in tm_shutdown () at t_funcs.c:99
__FUNCTION__ = "tm_shutdown"
#6  0x080be491 in destroy_modules () at sr_module.c:370
t = 0x81b8570
foo = 0x81b8554
#7  0x0806b0a0 in cleanup (show_status=1) at main.c:336
No locals.
#8  0x0806bfd4 in handle_sigs () at main.c:533
chld = 0
chld_status = 139
i = 6
do_exit = 1
__FUNCTION__ = "handle_sigs"
#9  0x08070564 in main_loop (argc=9, argv=0xbf85e4a4) at main.c:913
i = 4
pid = 
si = 0x0
startup_done = 0x0
chd_rank = 4
__FUNCTION__ = "main_loop"
#10 main (argc=9, argv=0xbf85e4a4) at main.c:1388
cfg_log_stderr = 0
cfg_stream = 0x8c26008
c = 
r = 0
---Type  to continue, or q  to quit---
tmp = 0xbf85ff64 ""
tmp_len = 
port = 12570437
proto = 
ret = 
seed = 196014188
rfd = 4
__FUNCTION__ = "main"

*CORE 2:*

Core was generated by `/usr/local/sbin/opensips -P 
/var/run/opensips.pid -m 1024 -u root -g root'.

Program terminated with signal 11, Segmentation fault.
#0  0x080faab7 in get_all_bodies (msg=0x81d419c) at 
parser/parse_multipart.c:193

193 if (msg->buf + msg->len - start < get_content_length(msg))

(gdb) bt full
#0  0x080faab7 in get_all_bodies (msg=0x81d419c) at 
parser/parse_multipart.c:193

start = 0x81926e0 ""
end = 
type = 
cur = 
temp = 
delimiter = {s = 0x0, len = 0}
__FUNCTION__ = "get_all_bodies"
#1  0x00e59f0d in force_rtp_proxy (msg=0x81926e0, str1=0x81d419c 
"\"'1", str2=0x0, offer=0) at nathelper.c:2773

m = 
p = 
body = {s = 0x0, len = 0}
skip = 
c = 
__FUNCTION__ = "force_rtp_proxy"
#2  0x00e5edae in rtpproxy_answer2_f (msg=0x81d419c, str1=0x81c8920 
"FW", str2=0x0) at nathelper.c:2742

No locals.
#3  rtpproxy_answer1_f (msg=0x81d419c, str1=0x81c8920 "FW", str2=0x0) 
at nathelper.c:2731

cp = 
newip = 
"177.107.192.207\000@\240\317\000\001\000\000\000\b\000\000\000\364_\322\000@\220\035\b8\253\303\b"

#4  0x080544fd in do_action (a=0x81c89ac, msg=0x81d419c) at action.c:967
val_s = {
   

Re: [OpenSIPS-Users] load_balancer

[SamyGo]

Hi Miha,

I do exactly what Bogdan said, but using DB connecitons. IF its an Initial
INVITE connect to DB and query table load_balancer and see if the source ip
of INVITE matches any of the load_balanaced FS servers then I know that its
from inside-media-serves to outside.

The next thing is identifying what original destination your FS was trying
to send the calls to i.e carrier-ip / uri !

So in your FS dialplan add a sip header where you store the real
destination of the SBC/trunk and once you are in the IF condition where you
detect your internal FS servers, strip off that header  change the $ru and
t-relay the call !!

phone(dial 007@FS )<===> FS (P-Real-DST: CAR.RIE.R.IP & dial
007@OpenSIPS)<>OpenSIPS(0...@car.rie.r.ip)<===>
ITSP(0...@car.rie.r.ip )

I hope this is what you wanted.

Regards,
Sammy

On Wed, Apr 4, 2012 at 11:49 AM, Miha  wrote:

> Hi Bogan,
>
> that is a bit tricky as phones are registering on Opensips server. If I
> make this that the phones will not register as FSs servers are on different
> ips than SBC.
>
> What would you sugget?
>
> Regards,
> Miha
>
>
> On 4/2/2012 6:30 PM, Bogdan-Andrei Iancu wrote:
>
>> Hi Miha,
>>
>> Well, in your script, when dealing with the initial requests, just look
>> at the source IP of the INVITEs - if from SBC, do the lb stuff, otherwise
>> route it back to SBC.
>>if (src_ip==11.22.33.44) {
>># do LB
>>} else {
>> # send to SBC
>>}
>>
>> Regards,
>> Bogdan
>>
>> On 04/02/2012 09:30 AM, Miha wrote:
>>
>>> Hi,
>>>
>>> as I am dealing with opensips for the first time I would ask you for a
>>> little help.
>>> I have installed and configured opensips that works like load_balancer (
>>> http://wiki.freeswitch.org/**wiki/Enterprise_deployment_**OpenSIPS
>>> ).
>>>
>>> I tested it and works. Than I have created siptrunk and point it to
>>> Opensips. Opensips was balacing the calls to one of the FSs, that I have
>>> set in opensips configuration.
>>>
>>> How can I now configure opensips, if the call is made from FS, that
>>> opensips will send it to SBC (from where sip trunk is made), so that the
>>> calls will be working in both direction?
>>>
>>>
>>> Thanks!
>>>
>>> Miha
>>>
>>> __**_
>>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users