Re: [OpenSIPS-Users] Mediaproxy relay on CentOS 6 VPS

[John Quick]

Hi Muhammad,


The (edited) results for those commands you suggested running are as follows:

processor   : 0

vendor_id   : AuthenticAMD

cpu family  : 16

model   : 2

model name  : Quad-Core AMD Opteron(tm) Processor 2352

stepping: 3

cpu MHz : 1050.000

etc.

 

CentOS release 6.4 (Final)

Kernel \r on an \m

 

Linux s123456.onlinehome-server.info 2.6.32-042stab076.8 #1 SMP Tue May 14 
20:38:14 MSK 2013 x86_64 x86_64 x86_64 GNU/Linux

 

Also, just to confirm about iptables, here is the edited output from “yum info 
iptables iptables-devel”:

Installed Packages

Name: iptables

Arch: x86_64

Version : 1.4.7

Release : 9.el6

 

Name: iptables-devel

Arch: x86_64

Version : 1.4.7

Release : 9.el6

 

John

 

From: Muhammad Shahzad [mailto:shaherya...@gmail.com] 
Sent: 20 May 2013 17:49
To: John Q
Cc: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Mediaproxy relay on CentOS 6 VPS

 

Humm, strange i never had to do that. If you can check which VMS you have, may 
be i can get it tested in local data center. Following three commands may give 
you some idea,

 

cat /proc/cpuinfo

cat /etc/issue

uname -a

 

OR you can always fallback to Debian. :-)

 

Thank you.

 

 

 

On Mon, May 20, 2013 at 6:45 PM, John Quick  wrote:

Muhammed,


Thanks for responding so quickly. I already have iptables-devel package 
installed, but I used yum to install it.

I did some research the last time it happened and think it concerns Linux 
loadable modules and options that may require a re-build of the kernel.

On that occasion, I chickened out and changed to Ubuntu.

John

 

From: Muhammad Shahzad [mailto:shaherya...@gmail.com] 
Sent: 20 May 2013 17:37
To: John Q; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Mediaproxy relay on CentOS 6 VPS

 

I think you need to install iptables-devel package.

 

http://rpm.pbone.net/index.php3?stat=3 
 
&search=iptables-devel&srodzaj=3

 

Thank you.

 

 

On Mon, May 20, 2013 at 5:56 PM, John Quick  wrote:

On two different Virtual Private Servers running CentOS 6 I have hit the
same problem.
It is that when I try to start mediaproxy relay, it errors with:
FATAL: Module ip_tables not found.

Unfortunately, as it is a third party VPS, I do not know what virtualization
environment is being used.
Does anyone know how to debug this problem (before I re-image it with
Debian/Ubuntu)?

Mediaproxy version is 2.5.2 and I used my own instructions as outlined at
http://kb.smartvox.co.uk/opensips/install-mediaproxy-centos-6/
The same procedure has worked fine on many other servers running CentOS 6.

John Quick
Smartvox Limited
Web: www.smartvox.co.uk




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





 

-- 

Mit freundlichen Grüßen

Muhammad Shahzad
---
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN:   shari_78...@hotmail.com
Email:   shaherya...@googlemail.com 





 

-- 

Mit freundlichen Grüßen

Muhammad Shahzad
---
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN:   shari_78...@hotmail.com
Email:   shaherya...@googlemail.com 

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

Re: [OpenSIPS-Users] Mediaproxy relay on CentOS 6 VPS

[Saúl Ibarra Corretgé]

You are missing some iptables kernel module. Sometimes VPS providers use a 
monolithic kernel and disable things. You should be able to install a standard 
kernel from your distro's repositories.

On May 22, 2013, at 11:14 AM, John Quick wrote:

> Hi Muhammad,
> 
> The (edited) results for those commands you suggested running are as follows:
> processor   : 0
> vendor_id   : AuthenticAMD
> cpu family  : 16
> model   : 2
> model name  : Quad-Core AMD Opteron(tm) Processor 2352
> stepping: 3
> cpu MHz : 1050.000
> etc.
>  
> CentOS release 6.4 (Final)
> Kernel \r on an \m
>  
> Linux s123456.onlinehome-server.info 2.6.32-042stab076.8 #1 SMP Tue May 14 
> 20:38:14 MSK 2013 x86_64 x86_64 x86_64 GNU/Linux
>  
> Also, just to confirm about iptables, here is the edited output from “yum 
> info iptables iptables-devel”:
> Installed Packages
> Name: iptables
> Arch: x86_64
> Version : 1.4.7
> Release : 9.el6
>  
> Name: iptables-devel
> Arch: x86_64
> Version : 1.4.7
> Release : 9.el6
>  
> John
>  
> From: Muhammad Shahzad [mailto:shaherya...@gmail.com] 
> Sent: 20 May 2013 17:49
> To: John Q
> Cc: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] Mediaproxy relay on CentOS 6 VPS
>  
> Humm, strange i never had to do that. If you can check which VMS you have, 
> may be i can get it tested in local data center. Following three commands may 
> give you some idea,
>  
> cat /proc/cpuinfo
> cat /etc/issue
> uname -a
>  
> OR you can always fallback to Debian. :-)
>  
> Thank you.
>  
>  
>  
> 
> On Mon, May 20, 2013 at 6:45 PM, John Quick  wrote:
> Muhammed,
> 
> Thanks for responding so quickly. I already have iptables-devel package 
> installed, but I used yum to install it.
> I did some research the last time it happened and think it concerns Linux 
> loadable modules and options that may require a re-build of the kernel.
> On that occasion, I chickened out and changed to Ubuntu.
> 
> John
>  
> From: Muhammad Shahzad [mailto:shaherya...@gmail.com] 
> Sent: 20 May 2013 17:37
> To: John Q; OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] Mediaproxy relay on CentOS 6 VPS
>  
> I think you need to install iptables-devel package.
>  
> http://rpm.pbone.net/index.php3?stat=3&search=iptables-devel&srodzaj=3
>  
> Thank you.
>  
>  
> 
> On Mon, May 20, 2013 at 5:56 PM, John Quick  wrote:
> On two different Virtual Private Servers running CentOS 6 I have hit the
> same problem.
> It is that when I try to start mediaproxy relay, it errors with:
> FATAL: Module ip_tables not found.
> 
> Unfortunately, as it is a third party VPS, I do not know what virtualization
> environment is being used.
> Does anyone know how to debug this problem (before I re-image it with
> Debian/Ubuntu)?
> 
> Mediaproxy version is 2.5.2 and I used my own instructions as outlined at
> http://kb.smartvox.co.uk/opensips/install-mediaproxy-centos-6/
> The same procedure has worked fine on many other servers running CentOS 6.
> 
> John Quick
> Smartvox Limited
> Web: www.smartvox.co.uk
> 
> 
> 
> 
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
>  
> --
> Mit freundlichen Grüßen
> Muhammad Shahzad
> ---
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_78...@hotmail.com
> Email: shaherya...@googlemail.com
> 
> 
>  
> --
> Mit freundlichen Grüßen
> Muhammad Shahzad
> ---
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_78...@hotmail.com
> Email: shaherya...@googlemail.com
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

--
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] Registrar not saving received from Path header

[Bogdan-Andrei Iancu]

Hi Nathaniel,

Well, the logs shows that save() does not receive any flags as
params...everything indicates that you do not have the params or you are
using the wrong config file.

Regards,

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


On 05/22/2013 08:22 AM, Nathaniel L Keeling III wrote:
> Hello Bogdan,
>
> Here is the output from the opensips log. I have also attached a
> snippet from the log file.
>
> May 21 23:39:15   OpenSips[14397]: [ID 257313 local1.debug]
> DBG:registrar:save_aux: xXx - flags param is 
> May 21 23:39:15   OpenSips[14397]: [ID 154992 local1.debug]
> DBG:registrar:save_aux: xXx - flags bitmask is <0>
>
> May 21 23:39:15   OpenSips[14397]: [ID 269964 local1.debug]
> DBG:registrar:pack_ci: xXx - flags are 0
>
> Thanks
>
> Nathaniel L Keeling
>
> On 5/20/13 11:56 AM, Bogdan-Andrei Iancu wrote:
>> Hello Nathaniel,
>>
>> See the attached patch - it logs more from the part where the params
>> are handled .
>>
>> Regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 05/18/2013 09:33 AM, Nathaniel L Keeling III wrote:
>>> Hello Bogdan,
>>>
>>> Here are snippets from my script. I only have one place where I
>>> execute the save function. Just wondering, could it be truncating a
>>> byte?
>>>
>>> modparam("usrloc", "nat_bflag", 10)
>>> modparam("usrloc", "use_domain", 1)
>>> modparam("usrloc", "db_mode", 3)
>>> modparam("usrloc", "db_url",
>>> "postgres://opensips:opensip...@ama.akan.net/opensips181t")
>>> modparam("registrar", "tcp_persistent_flag", 7)
>>> modparam("registrar", "received_avp", "$avp(received_nh)")
>>>
>>>
>>> xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE
>>> ");
>>> if (!save("location","p1"))
>>> {
>>> xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to
>>> save Register's request location");
>>> sl_reply_error();
>>> }
>>>
>>> xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has
>>> successfully registered with Akan Voice");
>>> exit;
>>>
>>> Thanks
>>>
>>> Nathaniel
>>>
>>> On 5/17/13 6:07 AM, Bogdan-Andrei Iancu wrote:
 Hello Nathaniel,

 That is odd.it's like you do not set the "p1" flag 

 I tested and I with "p1" flag I get:
 May 17 14:05:03 [7944] DBG:registrar:pack_ci: xXx - flags are 10

 Are you sure your script gets to the right save() ??

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

 On 05/17/2013 09:37 AM, Nathaniel L Keeling III wrote:
> Hello Bogdan,
>
> I added the patch and here is what I found: "OpenSips[4378]: [ID
> 269964 local1.debug] DBG:registrar:pack_ci: xXx - flags are 0". I
> have also included the log file.
>
> Thanks
>
> Nathaniel Keeling
>
> On 5/16/13 3:47 AM, Bogdan-Andrei Iancu wrote:
>> Hello Nathaniel,
>>
>> Attached is an extended patch - remove the old one and apply this
>> one. Again look for any xXx logs .
>>
>> Regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 05/14/2013 02:47 PM, Nathaniel L Keeling III wrote:
>>> Hello Bogdan,
>>>
>>> here is the output from opensips's og file of the save() with
>>> the patch and the code snippet from the opensips.cfg. I did not
>>> see any ant logs with "xXx". Also,I have usrloc's db_mode set to 3.
>>>
>>> xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE
>>> ");
>>> if (!save("location","p1"))
>>> {
>>> xlog("L_ERR", "ERR:callerid:$ci|end|System error trying
>>> to save Register's request location");
>>> sl_reply_error();
>>> }
>>> xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has
>>> successfully registered with Akan Voice");
>>> exit; 
>
>
> ___
> 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] Do_Routing problem

[Bogdan-Andrei Iancu]

  
  
Kaled,
  
  You need to pay a bit of attention on what you are doing and try
  to understand things - simply throeing some lines into the script,
  without being consistent, will not make your script work and
  simply waste our time here.
  
  So, one more time:
  
  1) the drouting "modparams" I gave you were correlated with the
  AVP names in the xlogs I gave you.
  
  2) In your post, the output of the xlog line with "Destinations
  are" is missing 
  
  Regards,
  

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

On 05/21/2013 10:03 PM, M.Khaled W Chehab wrote:

  
  
  
  
  
Hi,
 
I
set in dr_rules #lebanon   as a carrier route to
terminate the  rule that match 777961 ,
Please
find below the output for your script 
 
loadmodule "drouting.so"
modparam("drouting", "db_url",
"virtual://set1") # CUSTOMIZE ME
modparam("drouting",
"use_domain", 1)
modparam("drouting", "drd_table",
"dr_gateways")
modparam("drouting", "drr_table",
"dr_rules")
modparam("drouting", "drg_table",
"dr_groups")
modparam("drouting", "drc_table",
"dr_carriers")
modparam("drouting",
"drg_user_col", "username")
modparam("drouting",
"drg_domain_col", "domain")
modparam("drouting",
"drg_grpid_col", "groupid")
modparam("drouting", "force_dns",
1)
#frequency of probing per
paramete in seconds
modparam("drouting",
"probing_interval", 120)
modparam("drouting",
"probing_method", "OPTIONS")
modparam("drouting",
"probing_from", "sip:pinger@opensips")
modparam("drouting",
"probing_reply_codes", "487")
#501, 403,404,
modparam("drouting",
"use_domain", 1)
modparam("drouting",
"gw_attrs_avp", '$avp(gw_attrs)')
modparam("drouting", "gw_id_avp",
'$avp(gw_id)')
modparam("drouting",
"rule_attrs_avp", '$avp(rule_attrs)')
 
modparam("drouting","ruri_avp",
"$avp(dr_ruri)")
modparam("drouting","rule_id_avp",
"$avp(dr_rule)")
modparam("drouting","rule_attrs_avp",
"$avp(dr_rule_attrs)")
modparam("drouting","rule_prefix_avp",
"$avp(dr_rule_prefix)")
modparam("drouting","carrier_id_avp",
"$avp(dr_cr)")
modparam("drouting","carrier_attrs_avp",
"$avp(dr_cr_attrs)")
 
 
 
GW
IDs are  :  
GW
ATTRs are    :  
CR
IDs are  : Lebanon, Lebanon, Lebanon, Lebanon,  
CR
ATTRs are    : , , , ,  
RULE:
id=104, , attrs=0, , prefix=777961,  
 
 

  
  

  
  
id
  
  
carrierid
  
  
gwlist
  
  
flags
  
  
attrs
  
  
description
  

  

  


  
  

  
  

  
  
14
  
  
Lebanon
  
  
Dahdah_JVS,Bics,IDT,Snell_93
  
  
0
  
  
 
  
  
 
  


  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  

 
And
the problem still exists, please advice
Regards
 
 

  
From: Bogdan-Andrei Iancu
[mailto:bog...@opensips.org] 
Sent: Tuesday, May 21, 2013 8:00 PM
To: OpenSIPS users mailling list
Cc: M.Khaled W Chehab
Subject: Re: [OpenSIPS-Users] Do_Routing problem
  

 
Hello,

You can check what do_routing() set (as GWs to be used)
  by adding this in your script (just after do_routing):

      

Re: [OpenSIPS-Users] VIA relay error using mhomed=1

[qasimak...@gmail.com]

I think that is retransmission of ACK packet because it didn't get its 200
ok back.

Regards,
Qasim


On Tue, May 21, 2013 at 10:08 PM, Bogdan-Andrei Iancu
wrote:

> **
> Hi Qasim,
>
> Looking at the ACK related logs, I see you get the script log
>  Sequencial 'ACK' request from caller '622190004001' for call from
> .
>
> twice - also the logs from the loose_route() function - I suspect you loop
> somehow in your script and a route is triggered twice (the route doing
> loose_route)
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 05/20/2013 02:46 PM, qasimak...@gmail.com wrote:
>
>  Hi Bodgan,
>
>  Sorry for the late reply as i was traveling this weekend. Please find
> attached call logs with debug mode 4.
>
> Regards,
> Qasim
>
>
>  On Fri, May 17, 2013 at 8:50 PM, Bogdan-Andrei Iancu  > wrote:
>
>>  Funny, as I do not see anything wrong on a first look - while running
>> in debug mode (4), please send me the logs corresponding to the ACK
>> processing.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>>   On 05/17/2013 02:34 PM, qasimak...@gmail.com wrote:
>>
>>  Hi,
>>
>>  Please find attached trace. This is server on Public IP that is why i
>> cannot send the trace on the list. I am listening to IP's as follows
>>
>> listen=udp:202.152.203.195:5060
>> listen=udp:202.152.203.195:6000
>> listen=udp:192.168.226.142:5060
>> listen=udp:192.168.226.142:6000
>>
>> disable_tcp=no
>> listen=tcp:202.152.203.195:5060
>> listen=tcp:202.152.203.195:6000
>> listen=tcp:192.168.226.142:5060
>> listen=tcp:192.168.226.142:6000
>>
>>  If you need anything else i would be happy to provide it to you.
>>
>>  Regards,
>> Qasim
>>
>>
>>
>> On Fri, May 17, 2013 at 3:50 PM, Bogdan-Andrei Iancu > > wrote:
>>
>>>  Hello Qasim,
>>>
>>> So you have multiple interfaces in OpenSIPS - are all of them the same
>>> protocol ?
>>>
>>> Please try to post a SIP capture of the full call, to see how the RR
>>> part is done.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>>   On 05/16/2013 01:07 PM, qasimak...@gmail.com wrote:
>>>
>>> On further investigation i see that i only face this issue when both
>>> caller and callee are on the same network. If both are on separate network
>>> it works fine.
>>>
>>> Regards,
>>> Qasim
>>>
>>>
>>> On Thu, May 16, 2013 at 3:05 PM, qasimak...@gmail.com <
>>> qasimak...@gmail.com> wrote:
>>>
  yes.

  Regards,
 Qasim


 On Thu, May 16, 2013 at 2:50 PM, Bogdan-Andrei Iancu <
 bog...@opensips.org> wrote:

>  And do you have UDP 202.152.203.195 port 6000 as listener defined in
> OpenSIPS ??
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
>   On 05/16/2013 12:32 PM, qasimak...@gmail.com wrote:
>
>  Hi Bodgan,
>
>  Yes i see the following route header in my packet.
>
> Route:
> 
>
>
>  And yes i am routing it through loose_route.
>
>  Regards,
> Qasim
>
>
> On Wed, May 15, 2013 at 10:40 PM, Bogdan-Andrei Iancu <
> bog...@opensips.org> wrote:
>
>>  Hello Qasim,
>>
>> The ACK should be routed via loose_route() based on the "Route"
>> headers from it. Could you check if the Route hdrs (from the ACK) are
>> correctly reflecting your opensips interfaces ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>> On 05/14/2013 07:55 AM, qasimak...@gmail.com wrote:
>>
>>   Hi,
>>
>>  I am using OpenSIPs in Public<->Private bridging mode and have
>> enabled mhomed=1. But the problem is that when we have a call in which 
>> both
>> parties are on Public interface the INVITE gets relayed properly but and
>> ACK of that invite gives the following error.
>>
>> ERROR:core:get_out_socket: no socket found
>> ERROR:core:forward_request: cannot forward to af 2, proto 1 no
>> correspondinglistening socket
>>
>>  Regards,
>> Qasim
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://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] Registrar not saving received from Path header

[Nathaniel L Keeling III]

Hello Bogdan,

I have validated the script and that i am passing a parameter. I also 
changed the debug log statement that I displayed right before the save() 
and I still get the same output. Here is the code that I use in the script:



xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE, test with 
extra debug ...");

if (!save("location", "p1"))
{
xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to save 
Register's request location");

sl_reply_error();
}

xlog("L_INFO", "INFO:callerid:$ci|end|The subscriber has 
successfully registered with Akan Voice");

exit;

Is there a better way to validate? I am not sure of what else to check.

Thanks

Nathaniel L Keeling

On 5/22/13 6:02 AM, Bogdan-Andrei Iancu wrote:

Hi Nathaniel,

Well, the logs shows that save() does not receive any flags as 
params...everything indicates that you do not have the params or you 
are using the wrong config file.


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

On 05/22/2013 08:22 AM, Nathaniel L Keeling III wrote:

Hello Bogdan,

Here is the output from the opensips log. I have also attached a 
snippet from the log file.


May 21 23:39:15   OpenSips[14397]: [ID 257313 local1.debug] 
DBG:registrar:save_aux: xXx - flags param is
May 21 23:39:15   OpenSips[14397]: [ID 154992 local1.debug] 
DBG:registrar:save_aux: xXx - flags bitmask is <0>


May 21 23:39:15   OpenSips[14397]: [ID 269964 local1.debug] 
DBG:registrar:pack_ci: xXx - flags are 0


Thanks

Nathaniel L Keeling

On 5/20/13 11:56 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

See the attached patch - it logs more from the part where the params 
are handled .


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

On 05/18/2013 09:33 AM, Nathaniel L Keeling III wrote:

Hello Bogdan,

Here are snippets from my script. I only have one place where I 
execute the save function. Just wondering, could it be truncating a 
byte?


modparam("usrloc", "nat_bflag", 10)
modparam("usrloc", "use_domain", 1)
modparam("usrloc", "db_mode", 3)
modparam("usrloc", "db_url",
"postgres://opensips:opensip...@ama.akan.net/opensips181t")
modparam("registrar", "tcp_persistent_flag", 7)
modparam("registrar", "received_avp", "$avp(received_nh)")


xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE 
");

if (!save("location","p1"))
{
xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to 
save Register's request location");

sl_reply_error();
}

xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has 
successfully registered with Akan Voice");

exit;

Thanks

Nathaniel

On 5/17/13 6:07 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

That is odd.it's like you do not set the "p1" flag 

I tested and I with "p1" flag I get:
May 17 14:05:03 [7944] DBG:registrar:pack_ci: xXx - flags are 10

Are you sure your script gets to the right save() ??

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

On 05/17/2013 09:37 AM, Nathaniel L Keeling III wrote:

Hello Bogdan,

I added the patch and here is what I found: "OpenSips[4378]: [ID 
269964 local1.debug] DBG:registrar:pack_ci: xXx - flags are 0". I 
have also included the log file.


Thanks

Nathaniel Keeling

On 5/16/13 3:47 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

Attached is an extended patch - remove the old one and apply 
this one. Again look for any xXx logs .


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

On 05/14/2013 02:47 PM, Nathaniel L Keeling III wrote:

Hello Bogdan,

here is the output from opensips's og file of the save() with 
the patch and the code snippet from the opensips.cfg. I did not 
see any ant logs with "xXx". Also,I have usrloc's db_mode set to 3.


xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE 
");

if (!save("location","p1"))
{
xlog("L_ERR", "ERR:callerid:$ci|end|System error trying 
to save Register's request location");

sl_reply_error();
}
xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber 
has successfully registered with Akan Voice");
exit; 



___
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/user

[OpenSIPS-Users] Presence BLF TLS

[Chusov Alexsandr]

Hello
I have Grandstream phone with setup BLF button.
Opensips  use for REGISTER|Presence|BLF
When set Grandstream options  to "Use Actual Ephemeral Port in Contact
with TCP/TLS" phone add to Contact header port to which it is
connected BLF work fine.
But if phone set port to standard 5060 Opensips cant send NOTIFY

Phone - > SUBSCRIBE -> Opensips
Opensips -> Ok - > Phone
Opensips -> NOTIFY -> tcp_send failed

On phone log i don't see problem. He send SUBSCRIBE received OK. About
 NOTIFY nothing.


DBG:presence:send_notify_request: built notify_body 0x10d16f0
DBG:presence:send_notify_request: headers:#012Event:
dialog#015#012Contact:
#015#012Subscription-State:
active;expires=180#015#012Content-Type:
application/dialog-info+xml#015#012
DBG:presence:build_dlg_t: CONTACT = sip:@10.222.1.253:5060;transport=tls
DBG:presence_dialoginfo:dlginfo_body_setversion: set version
DBG:presence_dialoginfo:dlginfo_body_setversion: replace version with "0"
DBG:tm:t_uac: next_hop=
DBG:core:mk_proxy: doing DNS lookup...
DBG:tm:dlg2hash: 650
DBG:tm:print_request_uri: sip:@10.222.1.253:5060;transport=tls
ERROR:tm:msg_send: tcp_send failed
ERROR:tm:t_uac: attempt to send to
'sip:@10.222.1.253:5060;transport=tls' failed
DBG:tm:set_timer: relative timeout is 5
DBG:tm:insert_timer_unsafe: [0]: 0x7f9a7d7b0fe0 (34)
INFO:presence:send_notify_request: NOTIFY sip:9...@g-voip.stb.ua via
sip:@10.222.1.253:5060;transport=tls on behalf of
sip:1...@g-voip.stb.ua for event dialog,
to_tag=6b081e8cb2be0cc593bdd08e52ae2811-c7c2, cseq=1
DBG:tm:t_unref: UNREF_UNSAFE: [0x7f9a7d7a5cc0] after is 0
DBG:core:destroy_avp_list: destroying list (nil)
DBG:core:receive_msg: cleaning up


Thanks in advance
Sorry for my English

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

Re: [OpenSIPS-Users] B2BUA Segfault

[Bogdan-Andrei Iancu]

Hello Tolga,

The crash seems to be in the memory manager, most probably because of
memory corruption. To troubleshoot such issues you need to compile-in
the memory debugger - see
http://www.opensips.org/Documentation/TroubleShooting-OutOfMem .

Using memlog=1 + memdump=10 you should get a lot of logs related to mem
ops, including a final report + abort() when the corruption is detected.

Regards,

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


On 05/22/2013 01:29 AM, Tolga Tarhan wrote:
> Hello,
>
> While using the B2BUA module in OpenSIPS 1.9.0, we've encountered a
> consistent segfault. We are using a refer scenario just like the one
> in the B2BUA sample docs, and after several REFERs for the same call
> (to different destinations), OpenSIPS crashes with a segfault. The
> core file indicates the following backtrace:
>
> #0  0x0049a334 in fm_malloc ()
> #1  0x7fdaecd96230 in shm_malloc_unsafe (type=B2B_CLIENT,
> entity_id=0x7fdaee8ec750, to_uri=0x7fff2d346360,
> from_uri=0x7fff2d346320, from_dname=0x0, ssid=,
> msg=0x0) at ../../mem/shm_mem.h:248
> #2  shm_malloc (type=B2B_CLIENT, entity_id=0x7fdaee8ec750,
> to_uri=0x7fff2d346360, from_uri=0x7fff2d346320, from_dname=0x0,
> ssid=, msg=0x0) at ../../mem/shm_mem.h:258
> #3  b2bl_create_new_entity (type=B2B_CLIENT, entity_id=0x7fdaee8ec750,
> to_uri=0x7fff2d346360, from_uri=0x7fff2d346320, from_dname=0x0,
> ssid=, msg=0x0) at logic.c:293
> #4  0x7fdaecd96882 in b2bl_new_client (to_uri= out>, from_uri=, tuple=,
> ssid=0x7fdaeb026c00, msg=) at logic.c:607
> #5  0x7fdaecda3579 in process_bridge_200OK (msg=0x7fdaee8e8b30,
> extra_headers=0x7fdaeb03d578, body=,
> tuple=0x7fdaeb01ada8, entity=) at logic.c:816
> #6  0x7fdaecda46c2 in b2b_logic_notify_reply (src= out>, msg=0x7fdaee8e8b30, key=,
> body=0x7fff2d3468b0, extra_headers=0x7fff2d3468a0,
> b2bl_key=0x7fff2d3476d0, hash_index=649, local_index=0)
> at logic.c:1133
> #7  0x7fdaecda6081 in b2b_logic_notify (src=1, msg=0x7fdaee8e8b30,
> key=0x7fdaeb03d500, type=1, param=0x7fff2d3476d0) at logic.c:2040
> #8  0x7fdaecfca7ad in b2b_tm_cback (t=0x7fdaeb054118,
> htable=0x7fdaeb014630, ps=) at dlg.c:2678
> #9  0x7fdaee291441 in run_trans_callbacks (type=256,
> trans=0x7fdaeb054118, req=, rpl= out>, code=) at t_hooks.c:212
> #10 0x7fdaee29c0e2 in local_reply (t=0x7fdaeb054118, p_msg= optimized out>, branch=, msg_status= optimized out>, cancel_bitmap=) at t_reply.c:1391
> #11 0x7fdaee29d31d in reply_received (p_msg=0x7fdaee8e8b30) at
> t_reply.c:1540
> #12 0x0042625a in forward_reply ()
> #13 0x00451c28 in receive_msg ()
> #14 0x00494e45 in udp_rcv_loop ()
> #15 0x0042d1a3 in main ()
>
> I'm not really sure how to diagnose this one. Any
> hints/fixes/suggestions would be very appreciated.
>
> Thanks,
> Tolga
>
>
> ___
> 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] memory consumed by t_relay

[Bogdan-Andrei Iancu]

Hi Chen-Che,

Looking at the stats:

at 10K:
dialog:active_dialogs = 21219
dialog:early_dialogs = 1

at 20K:
dialog:active_dialogs = 40473
dialog:early_dialogs = 1


As you can see, your active dialogs keep accumulating and consuming
memory - this is why you run out of shared mem.

Regards,

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


On 05/22/2013 09:22 AM, microx wrote:
> Hi Bogdan-Andrei,
>
> When you get the memory error, could you please do : "opensipsctl fifo 
> get_statistics all" and send me the output (off list) please? 
>
> When about 10,000 calls,  10kcalls.log
> 
>  
> .
> When about 20,000 calls,  20kcalls.log
> 
>   
>
> Also, at step 4) , by stop, you mean you shutdown OpenSIPS or you stop 
> the sipp load but OpenSIPS still runs ? 
>
> I meant that I shutdown OpenSIPS.
>
> Going back to my request on memory debugging, I was wondering why your 
> logs do no show the shm dump (but only pkg) - at step 3) do the SIGUSR 
> stuff and be sure you look for the Memory status for shm mem in your 
> logs - it must be there. 
>
> With killing one specific OpenSIPS process, I get the log as the attachment 
> https://docs.google.com/file/d/0B-NXx5YS2KQZOW11YnhNY2hGUkk/edit?usp=sharing
> (I set memdump=1, memlog=1, debug=6)
>
> If any further information is required or any provided log has something in
> lack, please feel free to let me know.
> Many thanks for your kind support.
>
> Best regards,
> Chen-Che 
>
>
>
> --
> View this message in context: 
> http://opensips-open-sip-server.1449251.n2.nabble.com/memory-consumed-by-t-relay-tp7586016p7586442.html
> Sent from the OpenSIPS - Users mailing list archive at Nabble.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] Callpickup scenario help

[Bogdan-Andrei Iancu]

Hi Miha,

So, what you need to do at OpenSIPS level is to be sure that you send
the "pick up" call to the same FS as used for the call you want to pick up.

For that I suggest to use some dialog variable (to attach some
information to the calls) in combination with get_dialog_info() function
( http://www.opensips.org/html/docs/modules/1.9.x/dialog.html#id294427
). This function allows you to (1) grep all existing calls based on a
dlg_var==some_value and (2) return another dlg_var from the found dialog
; the returned dlg_var may contain the id of the SF where the call was
sent to.

Regards,

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


On 05/22/2013 09:23 AM, Miha wrote:
> HI to all,
>
> i need a little help regarding one scenaria (What would be the best
> way to implement this).
>
> I am having opensips which is heandling registration and load
> balancing. Behind opensips I am having FS servers. What would be the
> best way to implement group call pickup. I need to know to which FS
> server send I call which will do call pickup. I must intercept only
> ringing phones. Call pickup future I have implemented on FS as would
> be also for PBX futures.
>
> 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

Re: [OpenSIPS-Users] Presence BLF TLS

[Bogdan-Andrei Iancu]

Hi Chusov,

The NOTIFY is sent back to the IP:port from the Contact in received
SUBSCRIBE. Do you have a pcap capture of the SUBSCRIBE + NOTIFY on the
opensips side ?

Regards,

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


On 05/22/2013 06:12 PM, Chusov Alexsandr wrote:
> Hello
> I have Grandstream phone with setup BLF button.
> Opensips  use for REGISTER|Presence|BLF
> When set Grandstream options  to "Use Actual Ephemeral Port in Contact
> with TCP/TLS" phone add to Contact header port to which it is
> connected BLF work fine.
> But if phone set port to standard 5060 Opensips cant send NOTIFY
>
> Phone - > SUBSCRIBE -> Opensips
> Opensips -> Ok - > Phone
> Opensips -> NOTIFY -> tcp_send failed
>
> On phone log i don't see problem. He send SUBSCRIBE received OK. About
>  NOTIFY nothing.
>
>
> DBG:presence:send_notify_request: built notify_body 0x10d16f0
> DBG:presence:send_notify_request: headers:#012Event:
> dialog#015#012Contact:
> #015#012Subscription-State:
> active;expires=180#015#012Content-Type:
> application/dialog-info+xml#015#012
> DBG:presence:build_dlg_t: CONTACT = sip:@10.222.1.253:5060;transport=tls
> DBG:presence_dialoginfo:dlginfo_body_setversion: set version
> DBG:presence_dialoginfo:dlginfo_body_setversion: replace version with "0"
> DBG:tm:t_uac: next_hop=
> DBG:core:mk_proxy: doing DNS lookup...
> DBG:tm:dlg2hash: 650
> DBG:tm:print_request_uri: sip:@10.222.1.253:5060;transport=tls
> ERROR:tm:msg_send: tcp_send failed
> ERROR:tm:t_uac: attempt to send to
> 'sip:@10.222.1.253:5060;transport=tls' failed
> DBG:tm:set_timer: relative timeout is 5
> DBG:tm:insert_timer_unsafe: [0]: 0x7f9a7d7b0fe0 (34)
> INFO:presence:send_notify_request: NOTIFY sip:9...@g-voip.stb.ua via
> sip:@10.222.1.253:5060;transport=tls on behalf of
> sip:1...@g-voip.stb.ua for event dialog,
> to_tag=6b081e8cb2be0cc593bdd08e52ae2811-c7c2, cseq=1
> DBG:tm:t_unref: UNREF_UNSAFE: [0x7f9a7d7a5cc0] after is 0
> DBG:core:destroy_avp_list: destroying list (nil)
> DBG:core:receive_msg: cleaning up
>
>
> Thanks in advance
> Sorry for my English
>
> ___
> 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] Registrar not saving received from Path header

[Bogdan-Andrei Iancu]

Could you try : save("location","$((ff))") ?
Do you get any error ?

What is your opensips version ?

Regards,

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


On 05/22/2013 05:49 PM, Nathaniel L Keeling III wrote:
> Hello Bogdan,
>
> I have validated the script and that i am passing a parameter. I also
> changed the debug log statement that I displayed right before the
> save() and I still get the same output. Here is the code that I use in
> the script:
>
>
> xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE, test with
> extra debug ...");
> if (!save("location", "p1"))
> {
> xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to
> save Register's request location");
> sl_reply_error();
> }
>
> xlog("L_INFO", "INFO:callerid:$ci|end|The subscriber has
> successfully registered with Akan Voice");
> exit;
>
> Is there a better way to validate? I am not sure of what else to check.
>
> Thanks
>
> Nathaniel L Keeling
>
> On 5/22/13 6:02 AM, Bogdan-Andrei Iancu wrote:
>> Hi Nathaniel,
>>
>> Well, the logs shows that save() does not receive any flags as
>> params...everything indicates that you do not have the params or you
>> are using the wrong config file.
>>
>> Regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 05/22/2013 08:22 AM, Nathaniel L Keeling III wrote:
>>> Hello Bogdan,
>>>
>>> Here is the output from the opensips log. I have also attached a
>>> snippet from the log file.
>>>
>>> May 21 23:39:15   OpenSips[14397]: [ID 257313 local1.debug]
>>> DBG:registrar:save_aux: xXx - flags param is 
>>> May 21 23:39:15   OpenSips[14397]: [ID 154992 local1.debug]
>>> DBG:registrar:save_aux: xXx - flags bitmask is <0>
>>>
>>> May 21 23:39:15   OpenSips[14397]: [ID 269964 local1.debug]
>>> DBG:registrar:pack_ci: xXx - flags are 0
>>>
>>> Thanks
>>>
>>> Nathaniel L Keeling
>>>
>>> On 5/20/13 11:56 AM, Bogdan-Andrei Iancu wrote:
 Hello Nathaniel,

 See the attached patch - it logs more from the part where the
 params are handled .

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

 On 05/18/2013 09:33 AM, Nathaniel L Keeling III wrote:
> Hello Bogdan,
>
> Here are snippets from my script. I only have one place where I
> execute the save function. Just wondering, could it be truncating
> a byte?
>
> modparam("usrloc", "nat_bflag", 10)
> modparam("usrloc", "use_domain", 1)
> modparam("usrloc", "db_mode", 3)
> modparam("usrloc", "db_url",
> "postgres://opensips:opensip...@ama.akan.net/opensips181t")
> modparam("registrar", "tcp_persistent_flag", 7)
> modparam("registrar", "received_avp", "$avp(received_nh)")
>
>
> xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE
> ");
> if (!save("location","p1"))
> {
> xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to
> save Register's request location");
> sl_reply_error();
> }
>
> xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has
> successfully registered with Akan Voice");
> exit;
>
> Thanks
>
> Nathaniel
>
> On 5/17/13 6:07 AM, Bogdan-Andrei Iancu wrote:
>> Hello Nathaniel,
>>
>> That is odd.it's like you do not set the "p1" flag 
>>
>> I tested and I with "p1" flag I get:
>> May 17 14:05:03 [7944] DBG:registrar:pack_ci: xXx - flags are 10
>>
>> Are you sure your script gets to the right save() ??
>>
>> Regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 05/17/2013 09:37 AM, Nathaniel L Keeling III wrote:
>>> Hello Bogdan,
>>>
>>> I added the patch and here is what I found: "OpenSips[4378]: [ID
>>> 269964 local1.debug] DBG:registrar:pack_ci: xXx - flags are 0".
>>> I have also included the log file.
>>>
>>> Thanks
>>>
>>> Nathaniel Keeling
>>>
>>> On 5/16/13 3:47 AM, Bogdan-Andrei Iancu wrote:
 Hello Nathaniel,

 Attached is an extended patch - remove the old one and apply
 this one. Again look for any xXx logs .

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

 On 05/14/2013 02:47 PM, Nathaniel L Keeling III wrote:
> Hello Bogdan,
>
> here is the output from opensips's og file of the save() with
> the patch and the code snippet from the opensips.cfg. I did
> not see any ant logs with "xXx". Also,I have usrloc's db_mode
> set to 3.
>
> xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TAB

Re: [OpenSIPS-Users] Slight problem routing 100s and 183s

[Bogdan-Andrei Iancu]

Hi Nick,

I guess you simply have 2 calls in there.

The callid : 4737d441-5fb15ea7-7142c0d8@192.168.2.11   comes from
.11(phone) goes to .5(opensips)  and to .10 (asterisk) - this call is
not picked up  (there is only a trying from asterisk), so .11 fires a
CANCEL which ends the call.

I do not know what is about the replies with callid
1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060 - they seems to
belong to another call, involving a party with public IP, but I do not
see the INVITE, just some replies.

Regards,

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


On 05/21/2013 08:19 PM, Nick Khamis wrote:
> Bogdan I am so sorry!!! 192.168.2.11 is actually a UAC polycom phone.
> The only asterisk box that is being used in the scenario right now is
> 192.168.2.10, as seen in the traces. Please forgive me! :)
>
> N.
>
> On 5/21/13, Bogdan-Andrei Iancu  wrote:
>> Hello Nick,
>>
>> To be honest, I'm a bit confused - looking at the trace, I see the
>> INVITE comes from .11 (an aterisks), goes to .5 (opensipsIn) and then to
>> .10 (another asterisk)This does not match the network diagram ..
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 05/17/2013 11:30 PM, Nick Khamis wrote:
>>> Bogdan,
>>>
>>> I see how busy you are with OpenSIPS so I will make it count.
>>> Yes OpenSIP-Out is the new box that we have put in place to:
>>>
>>> Bellow is a quick network diagram. The issue we are experiencing is
>>> that the 100s, 183s and 200s
>>> that come back from the carrier do not get processed or even responded
>>> to by OpenSIPS-In.
>>> The complete sip trace for OpenSIPS-In can be found at
>>> "http://pastebin.com/iGeWsc40";.
>>> I did not include anything for "OUT" since it is performing as expected.
>>>
>>> Some things to notice are the changed CallID. This is done by asterisk
>>> (192.168.2.10):
>>>
>>> Initial: Call-ID: 4737d441-5fb15ea7-7142c0d8@192.168.2.11
>>> .
>>> Modified: Call-ID: 1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060
>>> .
>>>
>>> And the vanishing of RR: Record-Route:
>>> .
>>> This is also due to asterisk's recreation of the initial INVITE.
>>>
>>> When it comes to network appliances, this is the last piece of the pie.
>>> From now on it's mainly business logic, which should be less of a
>>> learning
>>> curve for us!!!
>>>
>>> I decided to post my problem online with example values, so it would
>>> hopefully help someone
>>> in the future.
>>>
>>> Kind Regards,
>>>
>>> Nick.
>>>
>>> network.jpg
>>> 
>>>
>>>
>>>
>>> ___
>>> 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] VIA relay error using mhomed=1

[Bogdan-Andrei Iancu]

No, it is not a retransmission as it is the same process and there is no
second set of logs for receiving a message from network:

May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]: DBG:core:parse_msg:
SIP Request:
May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]:
DBG:core:parse_msg:  method:  
May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]:
DBG:core:parse_msg:  uri:

May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]:
DBG:core:parse_msg:  version: 

May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]:
DBG:core:receive_msg: preparing to run routing scripts...
...
May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]: DBG:rr:after_loose:
Topmost route URI:
'sip:622190004...@xx.xx.xx.xx:6000;lr;ftag=2e76e266;did=c7c.34372c92' is me
...
May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]:
[udp:622190004001@39.42.183.233:7085]: Sequencial 'ACK' request from
caller '622..' for call from ...

May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]: DBG:rr:after_loose:
Topmost route URI:
'sip:622190004...@xx.xx.xx.xx:6000;lr;ftag=2e76e266;did=c7c.34372c92' is me
...
May 20 11:34:52 jkt-svr-mvapp-2 rtsip-service[1411]:
[udp:622190004001@39.42.183.233:7085]: Sequencial 'ACK' request from
caller '622.' for call from 


It is clearly a loop.

Regards,

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


On 05/22/2013 03:21 PM, qasimak...@gmail.com wrote:
> I think that is retransmission of ACK packet because it didn't get its
> 200 ok back.
>
> Regards,
> Qasim
>
>
> On Tue, May 21, 2013 at 10:08 PM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hi Qasim,
>
> Looking at the ACK related logs, I see you get the script log
>  Sequencial 'ACK' request from caller '622190004001' for call
> from .
>
> twice - also the logs from the loose_route() function - I suspect
> you loop somehow in your script and a route is triggered twice
> (the route doing loose_route)
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/20/2013 02:46 PM, qasimak...@gmail.com
>  wrote:
>> Hi Bodgan,
>>
>> Sorry for the late reply as i was traveling this weekend. Please
>> find attached call logs with debug mode 4.
>>
>> Regards,
>> Qasim
>>
>>
>> On Fri, May 17, 2013 at 8:50 PM, Bogdan-Andrei Iancu
>> mailto:bog...@opensips.org>> wrote:
>>
>> Funny, as I do not see anything wrong on a first look - while
>> running in debug mode (4), please send me the logs
>> corresponding to the ACK processing.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 05/17/2013 02:34 PM, qasimak...@gmail.com
>>  wrote:
>>> Hi,
>>>
>>> Please find attached trace. This is server on Public IP that
>>> is why i cannot send the trace on the list. I am listening
>>> to IP's as follows
>>>
>>> listen=udp:202.152.203.195:5060 
>>> listen=udp:202.152.203.195:6000 
>>> listen=udp:192.168.226.142:5060 
>>> listen=udp:192.168.226.142:6000 
>>>
>>> disable_tcp=no
>>> listen=tcp:202.152.203.195:5060 
>>> listen=tcp:202.152.203.195:6000 
>>> listen=tcp:192.168.226.142:5060 
>>> listen=tcp:192.168.226.142:6000 
>>>
>>> If you need anything else i would be happy to provide it to you.
>>>
>>> Regards,
>>> Qasim
>>>
>>>
>>>
>>> On Fri, May 17, 2013 at 3:50 PM, Bogdan-Andrei Iancu
>>> mailto:bog...@opensips.org>> wrote:
>>>
>>> Hello Qasim,
>>>
>>> So you have multiple interfaces in OpenSIPS - are all of
>>> them the same protocol ?
>>>
>>> Please try to post a SIP capture of the full call, to
>>> see how the RR part is done.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>>
>>>
>>> On 05/16/2013 01:07 PM, qasimak...@gmail.com
>>>  wrote:
 On further investigation i see that i only face this
 issue when both caller and callee are on the same
 network. If both are on separate network it works fine.

 Regards,
 Qasim


 On Thu, May 16, 2013 at 3:05 PM, qasimak...@gmail.com
  >>> 

Re: [OpenSIPS-Users] Presence BLF TLS

[Chusov Alexsandr]

I do not have  pcap because use TLS. But I can tomorrow create pcap TCP.
Two phone one enable "Use Actual Ephemeral Port in Contact with TCP/TLS" (
2...@g-voip.stb.ua )

AOR:: 9...@g-voip.stb.ua
Contact:: sip:@10.222.1.253:5060;transport=tls Q=
Expires:: 247
Callid:: 311684349-506...@ba.ccc.b.cfd
Cseq:: 2053
User-agent:: Grandstream GXP2120 1.0.5.24
State:: CS_SYNC
Flags:: 0
Cflag:: 0
Socket:: tls:10.222.0.17:5061
Methods:: 6015
AOR:: 2...@g-voip.stb.ua
Contact:: sip:2083@10.222.1.221:45266;transport=tls Q=
Expires:: 88
Callid:: 991321032-506...@ba.ccc.b.ccb
Cseq:: 2047
User-agent:: Grandstream GXP1405 1.0.5.15
State:: CS_SYNC
Flags:: 0
Cflag:: 0
Socket:: tls:10.222.0.17:5061
Methods:: 6015

I also asked a friend to test the asterisk. He send NOTIFY to port is
connected to not Contact.



2013/5/22 Bogdan-Andrei Iancu 

> Hi Chusov,
>
> The NOTIFY is sent back to the IP:port from the Contact in received
> SUBSCRIBE. Do you have a pcap capture of the SUBSCRIBE + NOTIFY on the
> opensips side ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/22/2013 06:12 PM, Chusov Alexsandr wrote:
> > Hello
> > I have Grandstream phone with setup BLF button.
> > Opensips  use for REGISTER|Presence|BLF
> > When set Grandstream options  to "Use Actual Ephemeral Port in Contact
> > with TCP/TLS" phone add to Contact header port to which it is
> > connected BLF work fine.
> > But if phone set port to standard 5060 Opensips cant send NOTIFY
> >
> > Phone - > SUBSCRIBE -> Opensips
> > Opensips -> Ok - > Phone
> > Opensips -> NOTIFY -> tcp_send failed
> >
> > On phone log i don't see problem. He send SUBSCRIBE received OK. About
> >  NOTIFY nothing.
> >
> >
> > DBG:presence:send_notify_request: built notify_body 0x10d16f0
> > DBG:presence:send_notify_request: headers:#012Event:
> > dialog#015#012Contact:
> > #015#012Subscription-State:
> > active;expires=180#015#012Content-Type:
> > application/dialog-info+xml#015#012
> > DBG:presence:build_dlg_t: CONTACT = sip:@10.222.1.253:5060
> ;transport=tls
> > DBG:presence_dialoginfo:dlginfo_body_setversion: set version
> > DBG:presence_dialoginfo:dlginfo_body_setversion: replace version with "0"
> > DBG:tm:t_uac: next_hop=
> > DBG:core:mk_proxy: doing DNS lookup...
> > DBG:tm:dlg2hash: 650
> > DBG:tm:print_request_uri: sip:@10.222.1.253:5060;transport=tls
> > ERROR:tm:msg_send: tcp_send failed
> > ERROR:tm:t_uac: attempt to send to
> > 'sip:@10.222.1.253:5060;transport=tls' failed
> > DBG:tm:set_timer: relative timeout is 5
> > DBG:tm:insert_timer_unsafe: [0]: 0x7f9a7d7b0fe0 (34)
> > INFO:presence:send_notify_request: NOTIFY sip:9...@g-voip.stb.ua via
> > sip:@10.222.1.253:5060;transport=tls on behalf of
> > sip:1...@g-voip.stb.ua for event dialog,
> > to_tag=6b081e8cb2be0cc593bdd08e52ae2811-c7c2, cseq=1
> > DBG:tm:t_unref: UNREF_UNSAFE: [0x7f9a7d7a5cc0] after is 0
> > DBG:core:destroy_avp_list: destroying list (nil)
> > DBG:core:receive_msg: cleaning up
> >
> >
> > Thanks in advance
> > Sorry for my English
> >
> > ___
> > 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] Presence BLF TLS

[Bogdan-Andrei Iancu]

The registration info is used only for routing the SUBSCRIBE (which is
ok). For the NOTIFY routing, the info from SUBSCRIBE + its 200 OK is
used - this is why I need the pcap.

Regards,

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


On 05/22/2013 08:24 PM, Chusov Alexsandr wrote:
> I do not have  pcap because use TLS. But I can tomorrow create pcap TCP.
> Two phone one enable "Use Actual Ephemeral Port in Contact with
> TCP/TLS" ( 2...@g-voip.stb.ua  )
>
> AOR:: 9...@g-voip.stb.ua 
> Contact:: sip:@10.222.1.253:5060;transport=tls Q=
> Expires:: 247
> Callid:: 311684349-506...@ba.ccc.b.cfd
> Cseq:: 2053
> User-agent:: Grandstream GXP2120 1.0.5.24
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: tls:10.222.0.17:5061
> 
> Methods:: 6015
> AOR:: 2...@g-voip.stb.ua 
> Contact:: sip:2083@10.222.1.221:45266;transport=tls Q=
> Expires:: 88
> Callid:: 991321032-506...@ba.ccc.b.ccb
> Cseq:: 2047
> User-agent:: Grandstream GXP1405 1.0.5.15
> State:: CS_SYNC
> Flags:: 0
> Cflag:: 0
> Socket:: tls:10.222.0.17:5061
> 
> Methods:: 6015
>
> I also asked a friend to test the asterisk. He send NOTIFY to port is
> connected to not Contact.
>
>
>
> 2013/5/22 Bogdan-Andrei Iancu  >
>
> Hi Chusov,
>
> The NOTIFY is sent back to the IP:port from the Contact in received
> SUBSCRIBE. Do you have a pcap capture of the SUBSCRIBE + NOTIFY on the
> opensips side ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/22/2013 06:12 PM, Chusov Alexsandr wrote:
> > Hello
> > I have Grandstream phone with setup BLF button.
> > Opensips  use for REGISTER|Presence|BLF
> > When set Grandstream options  to "Use Actual Ephemeral Port in
> Contact
> > with TCP/TLS" phone add to Contact header port to which it is
> > connected BLF work fine.
> > But if phone set port to standard 5060 Opensips cant send NOTIFY
> >
> > Phone - > SUBSCRIBE -> Opensips
> > Opensips -> Ok - > Phone
> > Opensips -> NOTIFY -> tcp_send failed
> >
> > On phone log i don't see problem. He send SUBSCRIBE received OK.
> About
> >  NOTIFY nothing.
> >
> >
> > DBG:presence:send_notify_request: built notify_body 0x10d16f0
> > DBG:presence:send_notify_request: headers:#012Event:
> > dialog#015#012Contact:
> > #015#012Subscription-State:
> > active;expires=180#015#012Content-Type:
> > application/dialog-info+xml#015#012
> > DBG:presence:build_dlg_t: CONTACT =
> sip:@10.222.1.253:5060;transport=tls
> > DBG:presence_dialoginfo:dlginfo_body_setversion: set version
> > DBG:presence_dialoginfo:dlginfo_body_setversion: replace version
> with "0"
> > DBG:tm:t_uac: next_hop=
> > DBG:core:mk_proxy: doing DNS lookup...
> > DBG:tm:dlg2hash: 650
> > DBG:tm:print_request_uri: sip:@10.222.1.253:5060;transport=tls
> > ERROR:tm:msg_send: tcp_send failed
> > ERROR:tm:t_uac: attempt to send to
> > 'sip:@10.222.1.253:5060;transport=tls' failed
> > DBG:tm:set_timer: relative timeout is 5
> > DBG:tm:insert_timer_unsafe: [0]: 0x7f9a7d7b0fe0 (34)
> > INFO:presence:send_notify_request: NOTIFY sip:9...@g-voip.stb.ua
>  via
> > sip:@10.222.1.253:5060;transport=tls on behalf of
> > sip:1...@g-voip.stb.ua  for
> event dialog,
> > to_tag=6b081e8cb2be0cc593bdd08e52ae2811-c7c2, cseq=1
> > DBG:tm:t_unref: UNREF_UNSAFE: [0x7f9a7d7a5cc0] after is 0
> > DBG:core:destroy_avp_list: destroying list (nil)
> > DBG:core:receive_msg: cleaning up
> >
> >
> > Thanks in advance
> > Sorry for my English
> >
> > ___
> > 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] Slight problem routing 100s and 183s

[Nick Khamis]

Hello Bogdan,

Thank you so much for your response, and your time! The log is for the same
call, only, the callid is getting changed by asterisk. What is happening is:

192.168.2.11 (UAC) -> 192.168.2.5 (OpenSIPSIn) INVITE
Call-ID: 4737d441-5fb15ea7-7142c0d8@192.168.2.11.

192.168.2.5 (OpenSIPSIn) -> 192.168.2.10 (Asterisk) INVITE
Call-ID: 4737d441-5fb15ea7-7142c0d8@192.168.2.11.

192.168.2.10 (Asterisk) -> 192.168.2.20 (OpenSIPSOut) INVITE
Call-ID: 1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060.

192.168.2.20 (OpenSIPSOut) -> 94.101.2.122 (Service Provider) INVITE
Call-ID: 1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060.

94.101.2.122:5060 (ServicProvider) -> 192.168.2.5:5060 (OpenSIPSIn) Giving
a Try
Call-ID: 1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060.

I am assuming because the callid coming into OpenSIPSIn from the service
provider has been changed by asterisk, and OpensipsIn is not aware traffic
with that callid, the 183 and 200s are being ignored?

I experienced something similar with BYEs and 404, due to changed callid
where Vlad solved the problem by explicitly forcing dialog matching
using match_dialog.
I am not sure if that is possible here too?

http://lists.opensips.org/pipermail/users/2013-April/025322.html

I also thought about trying to relay the 183 and 200s coming in from the
service provider to asterisk. The reason for this is because asterisk has
the two callid mapped, and can relay the traffic with the "original" callid
back to the proxy.

However, to limit the traffic going back and forth, if I can use the
"match_dialog" approach again it would be perfect!!

This is the last piece of the elephant!!! I hope I can put it together :)

Kind Regards,

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

[OpenSIPS-Users] DO_Routing Jump Timer

[M.Khaled W Chehab]

Hello,

 

I am using do_rouring module on opensips 1.8.3 

I have a problem such as if the trunk is unreachable it will make a lot of
delay and the user may send a cancel before it jump to next provider ,how to
avoid that and let it jump if there were  no response in 4 seconds from the
trunk

 

My TM parametes are :

loadmodule "tm.so"

modparam("tm", "fr_timer",10)

modparam("tm", "wt_timer",10)

modparam("tm", "fr_inv_timer", 60)

modparam("tm", "onreply_avp_mode", 1)

modparam("tm", "fr_timer_avp", "$avp(4)")

modparam("tm", "fr_inv_timer_avp

 

regards

 

 

 

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

Re: [OpenSIPS-Users] Do_Routing problem

[M.Khaled W Chehab]

Dear bogdan,

 

Thanks for you  ,my problem been  solved 

 

Regards

khaled

 

From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org] 
Sent: Wednesday, May 22, 2013 2:12 PM
To: M.Khaled W Chehab
Cc: 'OpenSIPS users mailling list'
Subject: Re: [OpenSIPS-Users] Do_Routing problem

 

Kaled,

You need to pay a bit of attention on what you are doing and try to
understand things - simply throeing some lines into the script, without
being consistent, will not make your script work and simply waste our time
here.

So, one more time:

1) the drouting "modparams" I gave you were correlated with the AVP names in
the xlogs I gave you.

2) In your post, the output of the xlog line with "Destinations are" is
missing 

Regards,




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


On 05/21/2013 10:03 PM, M.Khaled W Chehab wrote: 

Hi,

 

I set in dr_rules #lebanon   as a carrier route to terminate the  rule
that match 777961 ,

Please find below the output for your script 

 

loadmodule "drouting.so"

modparam("drouting", "db_url", "virtual://set1") # CUSTOMIZE ME

modparam("drouting", "use_domain", 1)

modparam("drouting", "drd_table", "dr_gateways")

modparam("drouting", "drr_table", "dr_rules")

modparam("drouting", "drg_table", "dr_groups")

modparam("drouting", "drc_table", "dr_carriers")

modparam("drouting", "drg_user_col", "username")

modparam("drouting", "drg_domain_col", "domain")

modparam("drouting", "drg_grpid_col", "groupid")

modparam("drouting", "force_dns", 1)

#frequency of probing per paramete in seconds

modparam("drouting", "probing_interval", 120)

modparam("drouting", "probing_method", "OPTIONS")

modparam("drouting", "probing_from",  
"sip:pinger@opensips")

modparam("drouting", "probing_reply_codes", "487")

#501, 403,404,

modparam("drouting", "use_domain", 1)

modparam("drouting", "gw_attrs_avp", '$avp(gw_attrs)')

modparam("drouting", "gw_id_avp", '$avp(gw_id)')

modparam("drouting", "rule_attrs_avp", '$avp(rule_attrs)')

 

modparam("drouting","ruri_avp", "$avp(dr_ruri)")

modparam("drouting","rule_id_avp", "$avp(dr_rule)")

modparam("drouting","rule_attrs_avp", "$avp(dr_rule_attrs)")

modparam("drouting","rule_prefix_avp", "$avp(dr_rule_prefix)")

modparam("drouting","carrier_id_avp", "$avp(dr_cr)")

modparam("drouting","carrier_attrs_avp", "$avp(dr_cr_attrs)")

 

 

 

GW IDs are  :  

GW ATTRs are:  

CR IDs are  : Lebanon, Lebanon, Lebanon, Lebanon,  

CR ATTRs are: , , , ,  

RULE: id=104, , attrs=0, , prefix=777961,  

 

 


 
 Description:
Full Texts

 
 id

 
 carrierid

 
 gwlist

 
 flags

 
 attrs

 
 description


 
 Description: Edit

 
 Description: Delete

14

Lebanon

Dahdah_JVS,Bics,IDT,Snell_93

0

 

 



 

And the problem still exists, please

Re: [OpenSIPS-Users] Do_Routing problem

[Nick Khamis]

Mismatched prefix between IDT BICS etc...?

N.

On 5/22/13, M.Khaled W Chehab  wrote:
> Dear bogdan,
>
>
>
> Thanks for you  ,my problem been  solved
>
>
>
> Regards
>
> khaled
>
>
>
> From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
> Sent: Wednesday, May 22, 2013 2:12 PM
> To: M.Khaled W Chehab
> Cc: 'OpenSIPS users mailling list'
> Subject: Re: [OpenSIPS-Users] Do_Routing problem
>
>
>
> Kaled,
>
> You need to pay a bit of attention on what you are doing and try to
> understand things - simply throeing some lines into the script, without
> being consistent, will not make your script work and simply waste our time
> here.
>
> So, one more time:
>
> 1) the drouting "modparams" I gave you were correlated with the AVP names
> in
> the xlogs I gave you.
>
> 2) In your post, the output of the xlog line with "Destinations are" is
> missing
>
> Regards,
>
>
>
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 05/21/2013 10:03 PM, M.Khaled W Chehab wrote:
>
> Hi,
>
>
>
> I set in dr_rules #lebanon   as a carrier route to terminate the  rule
> that match 777961 ,
>
> Please find below the output for your script
>
>
>
> loadmodule "drouting.so"
>
> modparam("drouting", "db_url", "virtual://set1") # CUSTOMIZE ME
>
> modparam("drouting", "use_domain", 1)
>
> modparam("drouting", "drd_table", "dr_gateways")
>
> modparam("drouting", "drr_table", "dr_rules")
>
> modparam("drouting", "drg_table", "dr_groups")
>
> modparam("drouting", "drc_table", "dr_carriers")
>
> modparam("drouting", "drg_user_col", "username")
>
> modparam("drouting", "drg_domain_col", "domain")
>
> modparam("drouting", "drg_grpid_col", "groupid")
>
> modparam("drouting", "force_dns", 1)
>
> #frequency of probing per paramete in seconds
>
> modparam("drouting", "probing_interval", 120)
>
> modparam("drouting", "probing_method", "OPTIONS")
>
> modparam("drouting", "probing_from",  
> "sip:pinger@opensips")
>
> modparam("drouting", "probing_reply_codes", "487")
>
> #501, 403,404,
>
> modparam("drouting", "use_domain", 1)
>
> modparam("drouting", "gw_attrs_avp", '$avp(gw_attrs)')
>
> modparam("drouting", "gw_id_avp", '$avp(gw_id)')
>
> modparam("drouting", "rule_attrs_avp", '$avp(rule_attrs)')
>
>
>
> modparam("drouting","ruri_avp", "$avp(dr_ruri)")
>
> modparam("drouting","rule_id_avp", "$avp(dr_rule)")
>
> modparam("drouting","rule_attrs_avp", "$avp(dr_rule_attrs)")
>
> modparam("drouting","rule_prefix_avp", "$avp(dr_rule_prefix)")
>
> modparam("drouting","carrier_id_avp", "$avp(dr_cr)")
>
> modparam("drouting","carrier_attrs_avp", "$avp(dr_cr_attrs)")
>
>
>
>
>
>
>
> GW IDs are  : 
>
> GW ATTRs are: 
>
> CR IDs are  : Lebanon, Lebanon, Lebanon, Lebanon,
>
> CR ATTRs are: , , , ,
>
> RULE: id=104, , attrs=0, , prefix=777961,
>
>
>
>
>
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60&goto=tbl_structure.php&display_options
> _form=1&display_text=F&token=4c290d9fc747fadbbb216f2d571c00ef> Description:
> Full Texts
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60+ORDER+BY+%60dr_carriers%60.%60id%60+AS
> C&token=4c290d9fc747fadbbb216f2d571c00ef> id
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60+ORDER+BY+%60dr_carriers%60.%60carrieri
> d%60+ASC&token=4c290d9fc747fadbbb216f2d571c00ef> carrierid
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60+ORDER+BY+%60dr_carriers%60.%60gwlist%6
> 0+ASC&token=4c290d9fc747fadbbb216f2d571c00ef> gwlist
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60+ORDER+BY+%60dr_carriers%60.%60flags%60
> +ASC&token=4c290d9fc747fadbbb216f2d571c00ef> flags
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60+ORDER+BY+%60dr_carriers%60.%60attrs%60
> +ASC&token=4c290d9fc747fadbbb216f2d571c00ef> attrs
>
>
>  ery=SELECT+%2A+FROM+%60dr_carriers%60+ORDER+BY+%60dr_carriers%60.%60descript
> ion%60+ASC&token=4c290d9fc747fadbbb216f2d571c00ef> description
>
>   
>
>  &where_clause=%60dr_carriers%60.%60id%60+%3D+14&clause_is_unique=1&sql_query
> =SELECT+%2A+FROM+%60dr_carriers%60&goto=sql.php&token=4c290d9fc747fadbbb216f
> 2d571c00ef> Description: Edit
>
>
>  ery=DELETE+FROM+%60opensips%60.%60dr_carriers%60+WHERE+%60dr_carriers%60.%60
> id%60+%3D+14&zero_rows=The+row+has+been+deleted&goto=sql.php%3Fdb%3Dopensips
> %26table%3Ddr_carriers%26sql_query%3DSELECT%2B%252A%2BFROM%2B%2560dr_carrier
> s%2560%26zero_rows%3

[OpenSIPS-Users] Use_next-$avp(gw_id) parameter

[M.Khaled W Chehab]

Dears

 

I am using opensips 1.8.3 with do_routing module 

>From documentation:

The name of the avp for storing the id of the current selected
gateway/destination - once a new destination is selected (via the
use_next_gw() function), the AVP will be updated with the ID of the new
selected gateway/destination.

 

xlog("after issue 2 gw:
$avp(gw_id) ... and attrs : $avp(rule_attrs) --");

use_next_gw();

   xlog("before issue 2 gw:
$avp(gw_id) .. and attrs : $avp(rule_attrs) --");

debug

after issue 2 gw: Snell_93 ... and attrs : 1
--

before issue 2 gw:  .. and attrs : 
--

How to force do_routing function to store the : $avp(gw_id)after
use_next_gw();

 

 

Regards

 

 

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

[OpenSIPS-Users] acc record outbound response to originator

[Dave Singer]

I'm wanting to record the response sent back to the call originator, not
just the last winning response selected by tm module. There are cases where
opensips translates like a received 503 to a 500 or like if you don't trust
the response you received from a vendor that is not using sip codes
properly.
Also want to log when I reject a call without making any outbound attempts.
Like for loop detected or some other invalid formatting. It seems it only
logs after t_relay has been used.

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

Re: [OpenSIPS-Users] B2BUA Segfault

[Tolga Tarhan]

Thank you -- I've recompiled and enabled the memory debug. I have the log
file from the whole experience available here:

http://netbrains-misc.s3.amazonaws.com/opensips/opensips.log

(note - real phone numbers and domain names in the log have been replaced
with placeholders)

The key item seems to be:

CRITICAL:core:qm_free: freeing already freed pointer, first free: logic.c:
process_bridge_200OK(740) - aborting

Although this appears to be after we've already decided we're going to
crash, as I see "INFO:core:cleanup: cleanup" and "NFO:core:handle_sigs:
child process 24788 exited by a signal 6" above this part of the log.

Also worth noting is the existance of "CRITICAL:b2b_logic:b2bl_drop_entity:
we should never end up here" throughout the log.

Also, here's the stack trace at crash time. Note that there were two core
files generated for the same crash, so this is the backtrace from each:

#0  0x003564c328a5 in raise () from /lib64/libc.so.6
#1  0x003564c34085 in abort () from /lib64/libc.so.6
#2  0x0049d370 in qm_free ()
#3  0x7ffccb253804 in process_bridge_200OK () from
/usr/lib64/opensips/modules/b2b_logic.so
#4  0x7ffccb254ba2 in b2b_logic_notify_reply () from
/usr/lib64/opensips/modules/b2b_logic.so
#5  0x7ffccb2565e1 in b2b_logic_notify () from
/usr/lib64/opensips/modules/b2b_logic.so
#6  0x7ffccb47a7a7 in b2b_tm_cback () from
/usr/lib64/opensips/modules/b2b_entities.so
#7  0x7ffccc744b71 in run_trans_callbacks () from
/usr/lib64/opensips/modules/tm.so
#8  0x7ffccc74fa12 in local_reply () from
/usr/lib64/opensips/modules/tm.so
#9  0x7ffccc750cc5 in reply_received () from
/usr/lib64/opensips/modules/tm.so
#10 0x004266da in forward_reply ()
#11 0x00452ad8 in receive_msg ()
#12 0x00496c95 in udp_rcv_loop ()
#13 0x0042d763 in main ()

#0  0x003564c328a5 in raise () from /lib64/libc.so.6
#1  0x003564c34085 in abort () from /lib64/libc.so.6
#2  0x0049d370 in qm_free ()
#3  0x7ffccb25a003 in b2bl_delete () from
/usr/lib64/opensips/modules/b2b_logic.so
#4  0x7ffccb25a3d5 in destroy_b2bl_htable () from
/usr/lib64/opensips/modules/b2b_logic.so
#5  0x0046dbf2 in destroy_modules ()
#6  0x004298a1 in cleanup ()
#7  0x0042a360 in handle_sigs ()
#8  0x0042db66 in main ()

I am unfamiliar with this codebase. Can anyone garner anything useful from
the logs?

Thanks,
Tolga



On Wed, May 22, 2013 at 9:02 AM, Bogdan-Andrei Iancu wrote:

> **
> Hello Tolga,
>
> The crash seems to be in the memory manager, most probably because of
> memory corruption. To troubleshoot such issues you need to compile-in the
> memory debugger - see
> http://www.opensips.org/Documentation/TroubleShooting-OutOfMem .
>
> Using memlog=1 + memdump=10 you should get a lot of logs related to mem
> ops, including a final report + abort() when the corruption is detected.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 05/22/2013 01:29 AM, Tolga Tarhan wrote:
>
> Hello,
>
>  While using the B2BUA module in OpenSIPS 1.9.0, we've encountered a
> consistent segfault. We are using a refer scenario just like the one in the
> B2BUA sample docs, and after several REFERs for the same call (to different
> destinations), OpenSIPS crashes with a segfault. The core file indicates
> the following backtrace:
>
>  #0  0x0049a334 in fm_malloc ()
> #1  0x7fdaecd96230 in shm_malloc_unsafe (type=B2B_CLIENT,
> entity_id=0x7fdaee8ec750, to_uri=0x7fff2d346360, from_uri=0x7fff2d346320,
> from_dname=0x0, ssid=, msg=0x0) at
> ../../mem/shm_mem.h:248
> #2  shm_malloc (type=B2B_CLIENT, entity_id=0x7fdaee8ec750,
> to_uri=0x7fff2d346360, from_uri=0x7fff2d346320, from_dname=0x0, ssid= optimized out>, msg=0x0) at ../../mem/shm_mem.h:258
> #3  b2bl_create_new_entity (type=B2B_CLIENT, entity_id=0x7fdaee8ec750,
> to_uri=0x7fff2d346360, from_uri=0x7fff2d346320, from_dname=0x0, ssid= optimized out>, msg=0x0) at logic.c:293
> #4  0x7fdaecd96882 in b2bl_new_client (to_uri=,
> from_uri=, tuple=,
> ssid=0x7fdaeb026c00, msg=) at logic.c:607
> #5  0x7fdaecda3579 in process_bridge_200OK (msg=0x7fdaee8e8b30,
> extra_headers=0x7fdaeb03d578, body=,
> tuple=0x7fdaeb01ada8, entity=) at logic.c:816
> #6  0x7fdaecda46c2 in b2b_logic_notify_reply (src= out>, msg=0x7fdaee8e8b30, key=, body=0x7fff2d3468b0,
> extra_headers=0x7fff2d3468a0, b2bl_key=0x7fff2d3476d0, hash_index=649,
> local_index=0)
> at logic.c:1133
> #7  0x7fdaecda6081 in b2b_logic_notify (src=1, msg=0x7fdaee8e8b30,
> key=0x7fdaeb03d500, type=1, param=0x7fff2d3476d0) at logic.c:2040
> #8  0x7fdaecfca7ad in b2b_tm_cback (t=0x7fdaeb054118,
> htable=0x7fdaeb014630, ps=) at dlg.c:2678
> #9  0x7fdaee291441 in run_trans_callbacks (type=256,
> trans=0x7fdaeb054118, req=, rpl=,
> code=) at t_hooks.c:212
> #10 0x7fdaee29c0e2 in local_reply (t=0x7fdaeb054118, p_msg= optimized out>, branch=, msg_status= out>, ca

Re: [OpenSIPS-Users] B2BUA Segfault

[Tolga Tarhan]

Sorry for the self-reply -- here's the (same) stacktraces with line numbers
and params:

#0  0x003564c328a5 in raise () from /lib64/libc.so.6
#1  0x003564c34085 in abort () from /lib64/libc.so.6
#2  0x0049d370 in qm_free (qm=, p=, file=0x7ffccb25df64 "logic.c", func=,
line=755) at mem/q_malloc.c:450
#3  0x7ffccb253804 in process_bridge_200OK (msg=0x7ffcccdd2600,
extra_headers=0xd5, body=, tuple=0x7ffcc9518de0,
entity=) at logic.c:755
#4  0x7ffccb254ba2 in b2b_logic_notify_reply (src=, msg=0x7ffcccdd2600, key=, body=0x7fffc2ce15d0,
extra_headers=0x7fffc2ce15c0, b2bl_key=0x7fffc2ce23f0, hash_index=649,
local_index=1)
at logic.c:1133
#5  0x7ffccb2565e1 in b2b_logic_notify (src=1, msg=0x7ffcccdd2600,
key=0x7ffcc9525e40, type=1, param=0x7fffc2ce23f0) at logic.c:2040
#6  0x7ffccb47a7a7 in b2b_tm_cback (t=0x7ffcc951c110,
htable=0x7ffcc94f38d0, ps=) at dlg.c:2678
#7  0x7ffccc744b71 in run_trans_callbacks (type=256,
trans=0x7ffcc951c110, req=, rpl=,
code=) at t_hooks.c:212
#8  0x7ffccc74fa12 in local_reply (t=0x7ffcc951c110, p_msg=, branch=, msg_status=, cancel_bitmap=) at t_reply.c:1391
#9  0x7ffccc750cc5 in reply_received (p_msg=0x7ffcccdd2600) at
t_reply.c:1540
#10 0x004266da in forward_reply (msg=0x7ffcccdd2600) at
forward.c:574
#11 0x00452ad8 in receive_msg (buf=,
len=, rcv_info=0x7fffc2ce28c0) at receive.c:207
#12 0x00496c95 in udp_rcv_loop () at udp_server.c:424
#13 0x0042d763 in main_loop (argc=,
argv=) at main.c:884
#14 main (argc=, argv=) at
main.c:1557

#0  0x003564c328a5 in raise () from /lib64/libc.so.6
#1  0x003564c34085 in abort () from /lib64/libc.so.6
#2  0x0049d370 in qm_free (qm=, p=, file=0x7ffccb262d75 "records.c", func=, line=595) at mem/q_malloc.c:450
#3  0x7ffccb25a003 in b2bl_delete (tuple=0x7ffcc9518de0,
hash_index=, not_del_b2be=1) at records.c:595
#4  0x7ffccb25a3d5 in destroy_b2bl_htable () at records.c:705
#5  0x0046dbf2 in destroy_modules () at sr_module.c:371
#6  0x004298a1 in cleanup (show_status=1) at main.c:348
#7  0x0042a360 in handle_sigs () at main.c:549
#8  0x0042db66 in main_loop (argc=,
argv=) at main.c:1024
#9  main (argc=, argv=) at
main.c:1557

Thanks,
Tolga


On Wed, May 22, 2013 at 1:00 PM, Tolga Tarhan  wrote:

> Thank you -- I've recompiled and enabled the memory debug. I have the log
> file from the whole experience available here:
>
> http://netbrains-misc.s3.amazonaws.com/opensips/opensips.log
>
> (note - real phone numbers and domain names in the log have been replaced
> with placeholders)
>
> The key item seems to be:
>
> CRITICAL:core:qm_free: freeing already freed pointer, first free: logic.c:
> process_bridge_200OK(740) - aborting
>
> Although this appears to be after we've already decided we're going to
> crash, as I see "INFO:core:cleanup: cleanup" and "NFO:core:handle_sigs:
> child process 24788 exited by a signal 6" above this part of the log.
>
> Also worth noting is the existance of
> "CRITICAL:b2b_logic:b2bl_drop_entity: we should never end up here"
> throughout the log.
>
> Also, here's the stack trace at crash time. Note that there were two core
> files generated for the same crash, so this is the backtrace from each:
>
> #0  0x003564c328a5 in raise () from /lib64/libc.so.6
> #1  0x003564c34085 in abort () from /lib64/libc.so.6
> #2  0x0049d370 in qm_free ()
> #3  0x7ffccb253804 in process_bridge_200OK () from
> /usr/lib64/opensips/modules/b2b_logic.so
> #4  0x7ffccb254ba2 in b2b_logic_notify_reply () from
> /usr/lib64/opensips/modules/b2b_logic.so
> #5  0x7ffccb2565e1 in b2b_logic_notify () from
> /usr/lib64/opensips/modules/b2b_logic.so
> #6  0x7ffccb47a7a7 in b2b_tm_cback () from
> /usr/lib64/opensips/modules/b2b_entities.so
> #7  0x7ffccc744b71 in run_trans_callbacks () from
> /usr/lib64/opensips/modules/tm.so
> #8  0x7ffccc74fa12 in local_reply () from
> /usr/lib64/opensips/modules/tm.so
> #9  0x7ffccc750cc5 in reply_received () from
> /usr/lib64/opensips/modules/tm.so
> #10 0x004266da in forward_reply ()
> #11 0x00452ad8 in receive_msg ()
> #12 0x00496c95 in udp_rcv_loop ()
> #13 0x0042d763 in main ()
>
> #0  0x003564c328a5 in raise () from /lib64/libc.so.6
> #1  0x003564c34085 in abort () from /lib64/libc.so.6
> #2  0x0049d370 in qm_free ()
> #3  0x7ffccb25a003 in b2bl_delete () from
> /usr/lib64/opensips/modules/b2b_logic.so
> #4  0x7ffccb25a3d5 in destroy_b2bl_htable () from
> /usr/lib64/opensips/modules/b2b_logic.so
> #5  0x0046dbf2 in destroy_modules ()
> #6  0x004298a1 in cleanup ()
> #7  0x0042a360 in handle_sigs ()
> #8  0x0042db66 in main ()
>
> I am unfamiliar with this codebase. Can anyone garner anything useful from
> the logs?
>
> Thanks,
> Tolga
>
>
>
> On Wed, May 22, 2013 at 9:02 AM, Bogdan-Andrei Iancu 
> wrote:
>
>> **
>> Hello Tolga,
>>
>> The crash seems to be in

Re: [OpenSIPS-Users] Registrar not saving received from Path header

[Nathaniel L Keeling III]

Hello Bogdan,

I am using opensips v1.8.3. I was using v1.8.2 earlier but I upgraded 
thinking it might fix my issue. When I changed the script to the 
save("location", "$((ff))") I get this config error when starting opensips:


May 22 17:39:11 [14757] ERROR:core:pv_parse_spec: pvar ""(inner_name) 
not found
May 22 17:39:11 [14757] ERROR:core:pv_parse_spec: wrong char [f/102] in 
[$((ff))] at [3 (2)]

May 22 17:39:11 [14757] ERROR:core:fixup_spve: wrong format[$((ff))]
May 22 17:39:11 [14757] ERROR:core:fix_actions: fixing failed (code=-1) 
at cfg line 767

May 22 17:39:11 [14757] CRITICAL:core:fix_expr: fix_actions error
May 22 17:39:11 [14757] ERROR:core:main: failed to fix configuration 
with err code -1


Thanks

Nathaniel L Keeling

On 5/22/13 11:46 AM, Bogdan-Andrei Iancu wrote:

Could you try : save("location","$((ff))") ?
Do you get any error ?

What is your opensips version ?

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

On 05/22/2013 05:49 PM, Nathaniel L Keeling III wrote:

Hello Bogdan,

I have validated the script and that i am passing a parameter. I also 
changed the debug log statement that I displayed right before the 
save() and I still get the same output. Here is the code that I use 
in the script:



xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE, test with 
extra debug ...");

if (!save("location", "p1"))
{
xlog("L_ERR", "ERR:callerid:$ci|end|System error trying to 
save Register's request location");

sl_reply_error();
}

xlog("L_INFO", "INFO:callerid:$ci|end|The subscriber has 
successfully registered with Akan Voice");

exit;

Is there a better way to validate? I am not sure of what else to check.

Thanks

Nathaniel L Keeling

On 5/22/13 6:02 AM, Bogdan-Andrei Iancu wrote:

Hi Nathaniel,

Well, the logs shows that save() does not receive any flags as 
params...everything indicates that you do not have the params or you 
are using the wrong config file.


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

On 05/22/2013 08:22 AM, Nathaniel L Keeling III wrote:

Hello Bogdan,

Here is the output from the opensips log. I have also attached a 
snippet from the log file.


May 21 23:39:15   OpenSips[14397]: [ID 257313 local1.debug] 
DBG:registrar:save_aux: xXx - flags param is
May 21 23:39:15   OpenSips[14397]: [ID 154992 local1.debug] 
DBG:registrar:save_aux: xXx - flags bitmask is <0>


May 21 23:39:15   OpenSips[14397]: [ID 269964 local1.debug] 
DBG:registrar:pack_ci: xXx - flags are 0


Thanks

Nathaniel L Keeling

On 5/20/13 11:56 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

See the attached patch - it logs more from the part where the 
params are handled .


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

On 05/18/2013 09:33 AM, Nathaniel L Keeling III wrote:

Hello Bogdan,

Here are snippets from my script. I only have one place where I 
execute the save function. Just wondering, could it be truncating 
a byte?


modparam("usrloc", "nat_bflag", 10)
modparam("usrloc", "use_domain", 1)
modparam("usrloc", "db_mode", 3)
modparam("usrloc", "db_url",
"postgres://opensips:opensip...@ama.akan.net/opensips181t")
modparam("registrar", "tcp_persistent_flag", 7)
modparam("registrar", "received_avp", "$avp(received_nh)")


xlog("SAVING THE SUBSCRIBER INTO THE LOCATION TABLE 
");

if (!save("location","p1"))
{
xlog("L_ERR", "ERR:callerid:$ci|end|System error trying 
to save Register's request location");

sl_reply_error();
}

xlog("L_NOTICE", "NOTICE:callerid:$ci|end|The subscriber has 
successfully registered with Akan Voice");

exit;

Thanks

Nathaniel

On 5/17/13 6:07 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

That is odd.it's like you do not set the "p1" flag 

I tested and I with "p1" flag I get:
May 17 14:05:03 [7944] DBG:registrar:pack_ci: xXx - flags are 10

Are you sure your script gets to the right save() ??

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

On 05/17/2013 09:37 AM, Nathaniel L Keeling III wrote:

Hello Bogdan,

I added the patch and here is what I found: "OpenSips[4378]: 
[ID 269964 local1.debug] DBG:registrar:pack_ci: xXx - flags are 
0". I have also included the log file.


Thanks

Nathaniel Keeling

On 5/16/13 3:47 AM, Bogdan-Andrei Iancu wrote:

Hello Nathaniel,

Attached is an extended patch - remove the old one and apply 
this one. Again look for any xXx logs .


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

On 05/14/2013 02:47 PM, Nathaniel L Keeling III wrote:

Hello Bogdan,

here is the output from opensips's og file of the save() with 
the patch and the code snippet from the opensips.cfg. I did 
not see any ant logs with "xXx". Also,

Re: [OpenSIPS-Users] memory consumed by t_relay

[microx]

Hi Bogdan-Andrei,

Thanks so much for your help. With modparam("dialog", "default_timeout", n),
the 
dialogs are removed and the memory consumption issue is resolved.

Best wishes,
Chen-Che



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/memory-consumed-by-t-relay-tp7586016p7586470.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

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

Re: [OpenSIPS-Users] Sip server dipping/advice

[Daniel Yu]

M.Khaled,

It may be easier to perform HTTP Queries to perform the LRN lookup. Have a
look at www.bulkvs.com where we offer HTTP based LRN DIPs.

Cheers -

Daniel



> -- Forwarded message --
> From: M.Khaled W Chehab 
> Date: Tue, May 14, 2013 at 6:17 AM
> Subject: [OpenSIPS-Users] Sip server dipping/advice
> To: users@lists.opensips.org, users-boun...@lists.opensips.org
>
>
> Hi,
>
> ** **
>
> ** **
>
> I am using opensips 1.8.x with do_routing module ,and trying to implement
> the US  dipping service in my script
>
> I am sending the call to the dipping sip server gateway and receive the
> 302 message containing  the LRN number  ,
>
> As as result I can have the rn number but I am sending the invite  to the
> dipping provider twice ,please can you advice how to setup it in the right
> way  
>
> if ($rU=~"^.") {
>
> route(7);
>
> route(1);
>
> exit;
>
> ** **
>
> route[1] {
>
> if (subst_uri('/(sip:.*);nat=yes/\1/')) {
>
> setbflag(6);
>
> }
>
> ** **
>
> if (isflagset(5)) {
>
>search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');*
> ***
>
> }
>
>  
>
> # for INVITEs enable some additional helper routes
>
> if (is_method("INVITE")) {
>
> ** **
>
>  
>
> t_on_branch("2");
>
> t_on_reply("2");
>
> t_on_failure("1");
>
> avp_db_query("UPDATE `opensips`.`invites` set `trunkip`
> ='$rd' where  `CALLID` = '$ci' ");
>
> ** **
>
> } else if (is_method("BYE")) {
>
> setflag(1); # do accounting ...
>
> setflag(3); #transaction falis
>
> setflag(4); #CDR Table
>
> xlog("Route 1
> Bye---");
>
>
>
> } else if (is_method("ACK")) {
>
> # call answered an ACKed, start billing here
>
> ** **
>
> } else if (is_method("CANCEL")) {
>
> # call cancelled by caller, do clean up here' ");
>
> }
>
> ** **
>
> if (!t_relay()) {
>
> xlog("L_INFO", "--Debug Customer
> ID:$avp(Cusid)/IP:$si--#11###Reply: $T_reply_code\n");
>
> ** **
>
> send_reply("500","Internal Error");
>
> };
>
> ** **
>
> exit;
>
> }
>
>  
>
> route[7]{
>
> if (!do_routing("$avp(Cusid)","FW")) {
>
> drop();
>
> exit;
>
> }
>
> }
>
> ** **
>
>  
>
> route[6] {
>
> if ( use_next_gw() ) {
>
> $var(prefix) =
> $(avp(gw_attrs){csv.value,1});
>
> $rU = $var(prefix) + $avp(dst);
>
> xlog("L_INFO", "--Debug Customer
> ID:$avp(Cusid)/IP:$si-Calling number to Next Provier $rU\n");
>
> setflag(26); #Missed calls
>
> t_on_failure("1");
>
> t_relay();
>
> exit;
>
> }
>
> }
>
> ** **
>
>  
>
> branch_route[2] {
>
> xlog("L_INFO", "--Debug Customer ID:$avp(Cusid)/IP:$si-new
> branch at $ru\n");
>
> route(7);
>
> }
>
> ** **
>
>  
>
> failure_route[1] {
>
> ** **
>
>  
>
>  if (!t_check_status("302")) {
>
> if (!next_routing()){
>
> xlog("L_INFO", "LRN - Unable to DIP");
>
> t_reply("500","Unable to DIP");
>
> exit;
>
> }
>
> xlog("L_INFO", "LRN - Unable to DIP - Trying Next");
>
> t_on_failure("1");
>
> t_relay();
>
> exit;  
>
> }
>
> ** **
>
> if (!$(ct.fields(uri){param.value,rn})){
>
>xlog("L_INFO", "LRN - No redirect
> information found");
>
> route(1);
>
>   }else if
> ($(ct.fields(uri){param.value,rn}) == $tU){
>
>   xlog("L_INFO", "LRN - Returned same number, no need to
> redirect");
>
> route(1);
>
>   }else{ 
>
> xlog("LRN-$rU---Else lRN
> $avp(lrnct)-");
>
> $rU=$avp(lrnct);   
>
> xlog("LRN-$rU---Else lRN
> $avp(lrnct)-");
>
> ** **
>
>  route(1);
>
>
>
> }
>
> 
>
>