Re: [OpenSIPS-Users] RtpRroxy sturtup (init.d) script for redhat

2009-04-07 Thread Romanov Vladimir
Hi!
Could you please add command line option to change syslog FACILITY? Now I 
simply modify this in source and recompile.

-
Vladimir Romanov
Scartel Star Lab
CTO
+7 (960) 239-0853


-Original Message-
From: Maxim Sobolev [mailto:sobo...@sippysoft.com] 
Sent: Tuesday, April 07, 2009 5:39 AM
To: Bogdan-Andrei Iancu
Cc: Romanov Vladimir; Users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] RtpRroxy sturtup (init.d) script for redhat

Bogdan-Andrei Iancu wrote:
> Hi Vladimir,
> 
> really nice, indeed - I did this manually all the time :)
> 
> Maybe Maxim can integrate this directly in the RTPproxy project

Yes, I will do it.

In fact we plan moving towards multi-threading design in the next 
release, which should make utilizing multi-core chips much easier.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft

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


Re: [OpenSIPS-Users] opensips won't start

2009-04-07 Thread Luntras Loredana
Lots of thanks Bogdan. 

I changed the port to 8000 and now it works.

Regard,
Loredana

-Original Message-
From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro] 
Sent: Monday, April 06, 2009 5:04 PM
To: Luntras Loredana; users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] opensips won't start

Hi Loredana,

yes, it seams that the 8080 port (used by the internal XMLRPC server)  
is already used :
  Failed to bind listening socket to port number 8080

try changing the XMLRPC port via the "port" modparam:
 
http://www.opensips.org/html/docs/modules/devel/mi_xmlrpc.html#id227137

Regards,
Bogdan

Luntras Loredana wrote:
> Thanks a lot Bogdan,
>
> Indeed I have a level 7 debug set. I'm sending you all the logs in the
> file attached (I'm not sending to all the list because it is too
long.)
> and also a 3 level debug version.
>
> I have not seen it, but there seems to be a problem with the 8080 port
> (I let the default port for OpenXcap).
>
> Regards,
>
> Loredana
>
> -Original Message-
> From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro] 
> Sent: Friday, April 03, 2009 4:58 PM
> To: Luntras Loredana
> Cc: users@lists.opensips.org
> Subject: Re: [OpenSIPS-Users] opensips won't start
>
> Hi Loredana,
>
> before "vanishing" in the first place, what are the last logs from 
> opensips? I guess you have a debug level higher than 5 set (I see some

> debug level messages).
>
> Regards,
> Bogdan
>
> Luntras Loredana wrote:
>   
>> Unfortunatelly, I'm back. I still have problems. Now my server starts
>> but it stops after some minutes (I can't find any message error with
>> syslog and there are no files in corefiles). If I want to restart it,
>> 
> or
>   
>> to start once it is stopped, I have this: 
>> Apr  2 16:22:45 luntrasl /sbin/opensips[13503]:
>> DBG:core:shm_mem_destroy:  
>> Apr  2 16:22:45 luntrasl /sbin/opensips[13503]:
>> DBG:core:shm_mem_destroy: destroying the shared memory lock 
>> Apr  2 16:22:45 luntrasl /sbin/opensips[13503]: DBG:core:handle_sigs:
>> terminating due to SIGCHLD
>>
>> Thanks a lot for your help.
>>
>> Regards,
>>
>> Loredana
>>
>> -Original Message-
>> From: Bogdan-Andrei Iancu [mailto:bog...@voice-system.ro] 
>> Sent: Thursday, April 02, 2009 11:56 AM
>> To: Luntras Loredana
>> Cc: users@lists.opensips.org
>> Subject: Re: [OpenSIPS-Users] opensips won't start
>>
>> Hi Loredana,
>>
>> I will report this to the module maintainer as, even if there is a 
>> configuration issue, the proxy must not crash, but report an error at

>> startup.
>>
>> Thanks and regards,
>> Bogdan
>>
>> Luntras Loredana wrote:
>>   
>> 
>>> It's solved.
>>>
>>> The initial problem was due to some dependencies which were not 
>>> correct. After that I had another problem: the version of the was 
>>> rls_presentity was 0 not 1 as expected. I've changed the version to
1
>>>   
>
>   
>>> and it works.
>>>
>>> Regards,
>>>
>>> Loredana
>>>
>>>
>>> 
>>>   
>

>   
>>   
>> 
>>> *From:* users-boun...@lists.opensips.org 
>>> [mailto:users-boun...@lists.opensips.org] *On Behalf Of *Luntras
>>> 
>>>   
>> Loredana
>>   
>> 
>>> *Sent:* Wednesday, April 01, 2009 6:05 PM
>>> *To:* users@lists.opensips.org
>>> *Subject:* [OpenSIPS-Users] opensips won't start
>>>
>>> Hello, everybody.
>>>
>>> I'have installes OpenSips 1.5 and OpenXCAP. Since I've changed the 
>>> config file (as suggested by openXcap) my OpenSips won't start. I
>>>   
> must
>   
>>> 
>>>   
>>   
>> 
>>> have errors in the config files or in the modules. The message I
have
>>>   
>
>   
>>> when I try to start it is:
>>>
>>> lored...@luntrasl:/opt/opensips-1.5.0-tls$ sudo /etc/init.d/opensips
>>> 
>>>   
>> start
>>   
>> 
>>> [sudo] password for loredana:
>>>
>>> Starting : opensipsStarting /sbin/opensips...
>>>
>>> Listening on
>>>
>>> udp: 141.11.146.144 [141.11.146.144]:5066
>>>
>>> Aliases:
>>>
>>> udp: luntrasl.rennes.eu.thmulti.com:5066
>>>
>>> .
>>>
>>> lored...@luntrasl:/opt/opensips-1.5.0-tls$ sudo /etc/init.d/opensips

>>> status
>>>
>>> Status of : opensips is not running but /var/run/opensips.pid
exists.
>>>
>>> The error that I have in the syslog is
>>>
>>> Apr 1 17:34:25 luntrasl kernel: [30143.981048] opensips[20690]: 
>>> segfault at 18 ip b7a4825c sp bfcb6d80 error 4 in
>>> 
>>>   
>> pua.so[b7a45000+18000]
>>   
>> 
>>> Apr 1 17:39:01 luntrasl /USR/SBIN/CRON[20713]: (root) CMD ( [ -x 
>>> /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find 
>>> /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 |

>>> xargs -n 200 -r -0 rm)
>>>
>>> The backtrace of the core file is here:
>>>
>>> Program terminated with signal 11, Segmentation fault.
>>>
>>> [New process 20690]
>>>
>>> #0 0xb7a4825c in contains_pua_event (name=0xbfcb6dd0) at
>>> 
>>>   
>> event_list.c:109
>>   
>> 
>>> 109 event= pua_evlist->next;
>>>
>>> (gdb) bt
>

[OpenSIPS-Users] Opensips 1.5.0 Issue with LCR next_contacts

2009-04-07 Thread Amit Sharma
Hi,
  I was planning to upgrade to version 1.5.0 from our current version
1.2.2 which is quite old. We are currently using lcr module
functionality to fork to contacts based on q-values

  However, it seems that opensips keeps trying the same contact in
case only a single contact is registered. I guess one of the reasons
is that next_contacts is returning a positive value in case
contact_avp doesn't exist even when called from failure route. The
changes to unify the ruri and branch handling seem to have changed
this behavior. Is this a intentional change in behavior of
next_contacts?

  Are there any additional changes required (apart from defining the
avp's)  to opensips.cfg to use the above functionality in 1.5



Thanks,
Amit

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


Re: [OpenSIPS-Users] Opensips_getting_crashed_with_XCAP

2009-04-07 Thread Anca Vamanu
Hi Jaya,

Since you sent two mails with the same body I should have probably 
replied to both... Please don't do this from now one. One e-mail is 
enough, you should not send one each day if you don't get a reply ( 
especially if it is weekend).
Here I paste the answer to the other e-mail:

/Thanks for this report.
I have fixed the problem there. Please update and test again.

/
You should update from svn the xcap_client module.

regards,
Anca

JayaPrakash wrote:
> To be frank, I don't know what is QM_DBG_MALLOC.
> Will you please make it clear, what is it and how to compile with it?
>
> Thanks
> JayaPrakash
>
>
> On Mon, Apr 6, 2009 at 11:05 PM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Buy were you compiling with QM_DBG_MALLOC ?
>
> Regards,
> Bogdan
>
> JayaPrakash wrote:
>
> Hi Bogdan,
> I guess I did not get phrase like "freeing already freed pointer".
> If I get such phrase, I am sure, I will post it to you.
>
> Thanks
> JayaPrakash
>
>
> On Mon, Apr 6, 2009 at 10:17 PM, Bogdan-Andrei Iancu
> mailto:bog...@voice-system.ro>
>  >> wrote:
>
>Hi JayaPrakash,
>
>have you compiled the memory debug support (I see you use
> the QM
>mem manager)? If so, do you get in your  logs something like:
>"freeing already freed pointer" before the abort?  If so,
> please
>post the entire message.
>
>Regards,
>Bogdan
>
>
>JayaPrakash wrote:
>
>Hi All,
>
>Opensips 1.5 is installed in Debian 5.
>OpenXCAP 1.0.7, Soap-Simple-Proxy and Opensips-mi-proxy are
>installed and functioning properly.
>(OpenXCAP is tested by running ./test.py, It is working
> fine.)
>presence, presence_xml,
>presence_mwi,pua,pua_mi,presence_xcapdiff,rls and
> xcap_client
>are loaded in this order.
>When OpenSIPs is started, it is getting crashed. I am using
>xlite client.
>Below I am printing backtrace.
>  
>  
> **
>(gdb) bt
>#0  0xb7f81424 in __kernel_vsyscall ()
>#1  0xb7e25640 in raise () from /lib/i686/cmov/libc.so.6
>#2  0xb7e27018 in abort () from /lib/i686/cmov/libc.so.6
>#3  0x080d7478 in qm_free (qm=0x818c4e0, p=0x0,
>file=0xb77f365f "xcap_functions.c", func=0xb77f39bf
>"get_xcap_path", line=458) at mem/q_malloc.c:444
>#4  0xb77f1db7 in get_xcap_path (req=
> {xcap_root = 0xaf706308 "192.168.1.130", port = 9222,
>doc_sel = {auid = {s = 0xb79792b5 "pres-rules", len = 10},
>doc_type = 2, type = 1, xid = {s = 0x81e8484
>"sip:h...@192.168.1.130
> 
>  >
> 
> >>", len = 22}, filename =
>
>{s = 0xb79792af "index", len = 5}}, node_sel = 0x0, etag =
>0x0, match_type = 0}) at xcap_functions.c:458
>
>#5  0xb77f29f2 in xcapGetNewDoc (req=
> {xcap_root = 0xaf706308 "192.168.1.130", port = 9222,
>doc_sel = {auid = {s = 0xb79792b5 "pres-rules", len = 10},
>doc_type = 2, type = 1, xid = {s = 0x81e8484
>"sip:h...@192.168.1.130
> 
>  >
> 
> >>", len = 22}, filename =
>
>{s = 0xb79792af "index", len = 5}}, node_sel = 0x0, etag =
>0x0, match_type = 0}, user={s = 0x81e78c4
> "h...@192.168.1.130 
>>
> 
>
> >>", len = 4}, domain={s = 0x81e78c9
>"192.168.1.130", len = 13},
>
>   xcap_doc=0xbfd9bef8) at xcap_functions.c:318
>#6  0xb79754d8 in http_get_rules_doc (user={s = 0x81e78c4
>"h...@192.168.1.130 

Re: [OpenSIPS-Users] Problem with double field P-Asserted-Identity

2009-04-07 Thread mmarzuola

Hi BogdanI tried to follow your directions, but the problem persists.This is what I did:In the route where the function do_routing is called I inserted:# Request route 'invite-to-external'route[6] {if(isflagset(20)) {xlog("L_INFO", "Call to foreign domain - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");route(2);exit;}if(!isflagset(23)) {# don't allow calls relaying from PSTN to PSTN, if not explicitely forwardedif(uri=~ "^sip:[0-9]+@") {xlog("L_INFO", "Call to PSTN\n");do_routing();xlog("L_INFO", "first attempt is $ru, attributes are $avp(s:drattrs)\n");if(!goes_to_gw()) {xlog("L_ERR", "No PSTN gateways available - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");sl_send_reply("503", "PSTN Termination Currently Unavailable");exit;}setflag(21);t_on_branch("1");t_on_failure("2");route(2);exit;}}xlog("L_INFO", "Call to unknown user - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");sl_send_reply("404", "User Not Found");exit;}In the branch_route:branch_route[1] {if(is_present_hf("P-Asserted-Identity")) {xlog("L_INFO", "Removing P-Asserted-Identity in branches\n");remove_hf("P-Asserted-Identity");}if(is_present_hf("Remote-Party-ID")) {remove_hf("Remote-Party-ID");}if(is_avp_set("$avp(s:caller_cli)/s")) {xlog("L_INFO", "Set caller CLI '$avp(s:caller_cli)' - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");append_hf("P-Asserted-Identity: <$avp(s:caller_cli)>\r\n");}route(14);}# Request route 'clir'route[14] {if(isflagset(28) && !isflagset(27)) {setflag(27);xlog("L_INFO", "Anonymize caller - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");uac_replace_from("Anonymous","sip:anonym...@anonymous.invalid");if(is_present_hf("Privacy")) {remove_hf("Privacy");}append_hf("Privacy: id\r\n");}}# Request route 'base-outbound'route[2] {xlog("L_INFO","ARRIVATO NELLA ROUTE 2\n");t_on_reply("1");if(!isflagset(21)) {t_on_failure("1");}if(is_present_hf("Proxy-Authorization")) {consume_credentials();}xlog("L_INFO", "Request leaving server, D-URI='$du' - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");if(!t_relay()) {sl_reply_error();}exit;}In the failure_route;# Failure route 'pstn-failover'failure_route[2] {xlog("L_INFO", "Failure route for PSTN entered - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");route(9);if(!use_next_gw()) {xlog("L_ERR", "Failed to select next PSTN gateway - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");exit;}xlog("L_INFO", "selected next gateway $ru, attributes are $avp(s:drattrs)\n");if(is_present_hf("P-Asserted-Identity")) {xlog("L_INFO", "Removing P-Asserted-Identity in failure route\n");remove_hf("P-Asserted-Identity");}if(is_present_hf("Remote-Party-ID")) {remove_hf("Remote-Party-ID");}if(is_avp_set("$avp(s:caller_cli)/s")) {xlog("L_INFO", "Set caller CLI '$avp(s:caller_cli)' - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");append_hf("P-Asserted-Identity: <$avp(s:caller_cli)>\r\n");#append_hf("Remote-Party-ID: <$avp(s:caller_cli)>;party=caller;privacy=none;screen=yes\r\n");}route(14);t_on_failure("2");route(2);}In the INVITE sent from proxy to the second gateway are still two P-Asserted Idntity fields.   Where am I wrong?Thanks in advance.Matteo Marzuola>Hi Matteo,>Whatever change you in request_route will propagate in all branches - >this is your problem - when you set the PAI for the first destination, >in request_route, the PAI will be present in all 

Re: [OpenSIPS-Users] Opensips fifo - dp_reload hangs

2009-04-07 Thread Dan-Cristian Bogos
Hi Bogdan,

I have updated to trunk and tested again. Here is what I found out:

* First "dp_reload" is successful.
* Second "dp_reload" hangs, even for empty dialplan table.

Let me know if you need any further tests.

Ta,
DanB


On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
> Hi Dan,
> 
> I found the bug and fixed it - for the moment the fix is on trunk only 
> and if you could test it before backport to 1.5, it will be great.
> 
> Thanks and regards,
> Bogdan
> 
> Dan-Cristian Bogos wrote:
> > Hi Bogdan,
> >
> > I have managed to make some more tests for the "dp_reload" issue, and came 
> > out the following:
> >
> > * The issue is not server dependent. I have installed an opensips server on 
> > a completely different machine with different architecture, and same issue 
> > came up again.
> > * The issue is not data dependent. On the test machine I have emptied 
> > completely the dialplan table and issued a dp_reload command, same thing 
> > happened, fifo was destroyed and the command hanged (tried other commands 
> > later and no response).
> > * "dp_translate" command works fine.
> >
> > Bellow you can find the debug for the "dp_reload" with empty dialplan table 
> > in the database. 
> >
> > Can u try my scenario in your labs? I am not doing anything specific, so if 
> > this is a bug, it can be common one.
> >
> > Ta,
> > DanB
> >
> > wtdev1:/etc/opensips# opensipsctl fifo dp_reload
> > Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
> > Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server:  done consume
> > Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
> > Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
> > Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully 
> > executed!
> > Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result 
> > set at 0x8174dc8
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns 
> > returned from the query
> > Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for 
> > result columns at 0x8174e60
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174e80)[0]=[dpid]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
> > type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174e88)[1]=[pr]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
> > type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174e90)[2]=[match_op]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
> > type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174e98)[3]=[match_exp]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> > result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174ea0)[4]=[match_len]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
> > type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174ea8)[5]=[subst_exp]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> > result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174eb0)[6]=[repl_exp]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> > result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> > RES_NAMES(0x8174eb8)[7]=[attrs]
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> > result type
> > Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned 
> > from the query
> > Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
> >
> >
> >
> >
> >   
> 


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


[OpenSIPS-Users] mediaproxy-2.x with floating IP

2009-04-07 Thread Uwe Kastens
Hi,

I have a setup with opensips and mediaproxy on one server and an
active/passive cluster with opensips.
- server 1 has two IPs, 1st internal 10.10.1.3, 2nd external 10.10.10.3
- server 2 has two IPs, 1st internal 10.10.1.4, 2nd external 10.10.10.4
- floating IP (driven by heartbeat-1), internal 10.10.1.5 and external
10.10.10.5

The plan is to start opensips and mediaproxy-dispatcher and
mediaproxy-relay after assigning the floating ips with by heartbeat.

After starting a call, media-relay closes the ports after 2 sec. If I
try the same with the real ip, everthing is working fine.

Anybody else using this setup?

BR

Uwe

-- 

kiste lat: 54.322684, lon: 10.13586

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


[OpenSIPS-Users] Presence-xcap_client-issue

2009-04-07 Thread JayaPrakash
Hi All,
Opensips 1.5 (Upgraded to Development Version) is installed in Debian 5.
Following modules are loaded in the order.
presence, presence_xml, presence_mwi, pua, pua_mi, rls, xcap_client, and
mi_xmlrpc.
OpenXCAP 1.0.7 is installed and configured and test suite is running
properly.
Opensips-mi-proxy and soap-simple-proxy are running.
When the Opensips client is registerd, it is throwing the following
xcap_client error.

ERROR:xcap_client:send_http_get: Error [22] while performing curl operation

Thanks
JayaPrakash


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


Re: [OpenSIPS-Users] mediaproxy-2.x with floating IP

2009-04-07 Thread Dan Pascu
On Tuesday 07 April 2009, Uwe Kastens wrote:
> Hi,
>
> I have a setup with opensips and mediaproxy on one server and an
> active/passive cluster with opensips.
> - server 1 has two IPs, 1st internal 10.10.1.3, 2nd external 10.10.10.3
> - server 2 has two IPs, 1st internal 10.10.1.4, 2nd external 10.10.10.4
> - floating IP (driven by heartbeat-1), internal 10.10.1.5 and external
> 10.10.10.5
>
> The plan is to start opensips and mediaproxy-dispatcher and
> mediaproxy-relay after assigning the floating ips with by heartbeat.

There is no reason to run mediaproxy under heartbeat control. You can 
leave both the dispatcher and relay to run all the time and use the real 
IP addresses. They will just be idle and only the pair where opensips 
runs will be used. You can even use both relays at the same time to load 
balance traffic, no matter which server is the master.

>
> After starting a call, media-relay closes the ports after 2 sec. If I
> try the same with the real ip, everthing is working fine.
>
> Anybody else using this setup?
>
> BR
>
> Uwe

-- 
Dan

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


Re: [OpenSIPS-Users] Presence-xcap_client-issue

2009-04-07 Thread Anca Vamanu
Hi Jaya,

Just as an observation: Is it compulsory for you to use xcap_client 
module and communication through HTTP requests? I suppose that you are 
aware that with OpenXCAP you can use database as communication means 
(http://opensips.org/index.php?n=Resources.PresenceServer - point 2 in 
Configuration section).

This doesn't mean that the configuration with xcap_client should not 
work. Do you see other errors before this one?


regards,
Anca

JayaPrakash wrote:
> Hi All,
> Opensips 1.5 (Upgraded to Development Version) is installed in Debian 5.
> Following modules are loaded in the order.
> presence, presence_xml, presence_mwi, pua, pua_mi, rls, xcap_client, 
> and mi_xmlrpc.
> OpenXCAP 1.0.7 is installed and configured and test suite is running 
> properly.
> Opensips-mi-proxy and soap-simple-proxy are running.
> When the Opensips client is registerd, it is throwing the following 
> xcap_client error.
>
> ERROR:xcap_client:send_http_get: Error [22] while performing curl 
> operation
>
> Thanks
> JayaPrakash


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


Re: [OpenSIPS-Users] mediaproxy-2.x with floating IP

2009-04-07 Thread Uwe Kastens
Hi Dan,
> 
> There is no reason to run mediaproxy under heartbeat control. You can 
> leave both the dispatcher and relay to run all the time and use the real 
> IP addresses. They will just be idle and only the pair where opensips 
> runs will be used. You can even use both relays at the same time to load 
> balance traffic, no matter which server is the master.
> 

Thanks for your explanation. The reason I tried to use the floating IP
was, to have only one single IP Adress.

I think I woll follow your idea.

BR

Uwe


-- 

kiste lat: 54.322684, lon: 10.13586

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


[OpenSIPS-Users] Simple DRouting Questions

2009-04-07 Thread Brett Nemeroff
All,Since migrating from 1.4 to 1.5, I'm also moving to use the highly
recommended dRouting module. I have some questions:
1. It's unclear to me if you specify a dr_gateway.id or a dr_gw_lists.id for
the dr_rules.gwlist field. It appears to be pointed to dr_gateway.id.. I'm
not sure how to make it use a list (an early post suggests a '#' before the
list number, but this doesn't appear in the docs from what I can see with my
blury eyes

2. I don't see anyway to dump the store routes from memory via fifo. Am I
missing something?

3. Is there any way to load like 4 avps at once from the attrs field?

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


Re: [OpenSIPS-Users] Problem with double field P-Asserted-Identity

2009-04-07 Thread mmarzuola

Hi Bogdan
I tried to follow your directions, but the problem persists.

This is what I did:

In the route where the function do_routing is called I inserted:


# Request route 'invite-to-external'

route[6] {
 if(isflagset(20)) {
 xlog("L_INFO", "Call to foreign domain - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
ID=$ci\n");
 route(2);
 exit;
 }
 if(!isflagset(23)) {
 # don't allow calls relaying from PSTN to PSTN, if not explicitely forwarded
 if(uri=~ "^sip:[0-9]+@") {
 xlog("L_INFO", "Call to PSTN\n");
 do_routing();
 xlog("L_INFO", "first attempt is $ru, attributes are $avp(s:drattrs)\n");
 if(!goes_to_gw()) {
 xlog("L_ERR", "No PSTN gateways available - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
ID=$ci\n");
 sl_send_reply("503", "PSTN Termination Currently Unavailable");
 exit;
 }
 setflag(21);

 t_on_branch("1");
 t_on_failure("2");
 route(2);
 exit;
 }
 }

 xlog("L_INFO", "Call to unknown user - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
ID=$ci\n");
 sl_send_reply("404", "User Not Found");
 exit;
}

In the branch_route:

branch_route[1] {
 if(is_present_hf("P-Asserted-Identity")) {
 xlog("L_INFO", "Removing P-Asserted-Identity in branches\n");
 remove_hf("P-Asserted-Identity");
 }
 if(is_present_hf("Remote-Party-ID")) {
 remove_hf("Remote-Party-ID");
 }
 if(is_avp_set("$avp(s:caller_cli)/s")) {
 xlog("L_INFO", "Set caller CLI '$avp(s:caller_cli)' - M=$rm RURI=$ru F=$fu 
T=$tu IP=$si ID=$ci\n");
 append_hf("P-Asserted-Identity: <$avp(s:caller_cli)>\r\n");
 }
 route(14);
}


# Request route 'clir'

route[14] {
 if(isflagset(28) && !isflagset(27)) {
 setflag(27);

 xlog("L_INFO", "Anonymize caller - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
ID=$ci\n");
 uac_replace_from("Anonymous","sip:anonym...@anonymous.invalid");
 if(is_present_hf("Privacy")) {
 remove_hf("Privacy");
 }
 append_hf("Privacy: id\r\n");
 }
}


# Request route 'base-outbound'

route[2] {
 xlog("L_INFO","ARRIVATO NELLA ROUTE 2\n");
 t_on_reply("1");

 if(!isflagset(21)) {
 t_on_failure("1");
 }
 if(is_present_hf("Proxy-Authorization")) {
 consume_credentials();
 }

 xlog("L_INFO", "Request leaving server, D-URI='$du' - M=$rm RURI=$ru F=$fu 
T=$tu IP=$si ID=$ci\n");

 if(!t_relay()) {
 sl_reply_error();
 }
 exit;
}

In the failure_route;


# Failure route 'pstn-failover'

failure_route[2] {
 xlog("L_INFO", "Failure route for PSTN entered - M=$rm RURI=$ru F=$fu T=$tu 
IP=$si ID=$ci\n");
 route(9);

 if(!use_next_gw()) {
 xlog("L_ERR", "Failed to select next PSTN gateway - M=$rm RURI=$ru F=$fu T=$tu 
IP=$si ID=$ci\n");
 exit;
 }
 xlog("L_INFO", "selected next gateway $ru, attributes are $avp(s:drattrs)\n");

 if(is_present_hf("P-Asserted-Identity")) {
 xlog("L_INFO", "Removing P-Asserted-Identity in failure route\n");
 remove_hf("P-Asserted-Identity");
 }
 if(is_present_hf("Remote-Party-ID")) {
 remove_hf("Remote-Party-ID");
 }
 if(is_avp_set("$avp(s:caller_cli)/s")) {
 xlog("L_INFO", "Set caller CLI '$avp(s:caller_cli)' - M=$rm RURI=$ru F=$fu 
T=$tu IP=$si ID=$ci\n");
 append_hf("P-Asserted-Identity: <$avp(s:caller_cli)>\r\n");
 #append_hf("Remote-Party-ID: 
<$avp(s:caller_cli)>;party=caller;privacy=none;screen=yes\r\n");
 }
 route(14);

 t_on_failure("2");
 route(2);
}

In the INVITE sent from proxy to the second gateway are still two P-Asserted 
Idntity fields.
Where am I wrong?

Thanks in advance.

Matteo Marzuola




>Hi Matteo,

>Whatever change you in request_route will propagate in all branches - 
>this is your problem - when you set the PAI for the first destination, 
>in request_route, the PAI will be present in all future branches.

>To avoid this situation, avoid adding "per-branch" info from 
>request_branch - do it from branch_route; branch_route and failure_route 
>allows changes per branch (and not global ones).

>Do something like:

>request_route -> do_routing + arm branch_route
>branch_route -> set PAI for the first branch
>failure_route -> set PAI for the next branch

>Regards,
>Bogdan

>Hi all. In my scenario I try to use dynamic routing and I have a problem with 
>the P-Asserted Identity field. When >the proxy tries to send the INVITE to the 
>first gateway selected from DRouting module by the function
>do_routing, there is only one PAI field, but if that gateway is down, at the 
>second attempt to next gateway, the >INVITE contains two PAI fields identicals.

>Thanks in advance.

>Matteo Marzuola




Vuoi e

Re: [OpenSIPS-Users] Opensips fifo - dp_reload hangs

2009-04-07 Thread Bogdan-Andrei Iancu
Hi Dan,

As expected, the "debug" function strikes again (some unhandled  return 
if data was null was causing a deadlock)..

Fixed, tested and backported to 1.5.

Thanks again for your help,

Regards,
Bogdan

Dan-Cristian Bogos wrote:
> Hi Bogdan,
>
> I have updated to trunk and tested again. Here is what I found out:
>
> * First "dp_reload" is successful.
> * Second "dp_reload" hangs, even for empty dialplan table.
>
> Let me know if you need any further tests.
>
> Ta,
> DanB
>
>
> On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
>   
>> Hi Dan,
>>
>> I found the bug and fixed it - for the moment the fix is on trunk only 
>> and if you could test it before backport to 1.5, it will be great.
>>
>> Thanks and regards,
>> Bogdan
>>
>> Dan-Cristian Bogos wrote:
>> 
>>> Hi Bogdan,
>>>
>>> I have managed to make some more tests for the "dp_reload" issue, and came 
>>> out the following:
>>>
>>> * The issue is not server dependent. I have installed an opensips server on 
>>> a completely different machine with different architecture, and same issue 
>>> came up again.
>>> * The issue is not data dependent. On the test machine I have emptied 
>>> completely the dialplan table and issued a dp_reload command, same thing 
>>> happened, fifo was destroyed and the command hanged (tried other commands 
>>> later and no response).
>>> * "dp_translate" command works fine.
>>>
>>> Bellow you can find the debug for the "dp_reload" with empty dialplan table 
>>> in the database. 
>>>
>>> Can u try my scenario in your labs? I am not doing anything specific, so if 
>>> this is a bug, it can be common one.
>>>
>>> Ta,
>>> DanB
>>>
>>> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server:  done consume
>>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi tree
>>> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
>>> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT successfully 
>>> executed!
>>> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for result 
>>> set at 0x8174dc8
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns 
>>> returned from the query
>>> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes for 
>>> result columns at 0x8174e60
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174e80)[0]=[dpid]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
>>> type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174e88)[1]=[pr]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
>>> type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174e90)[2]=[match_op]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
>>> type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174e98)[3]=[match_exp]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
>>> result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174ea0)[4]=[match_len]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT result 
>>> type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174ea8)[5]=[subst_exp]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
>>> result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174eb0)[6]=[repl_exp]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
>>> result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
>>> RES_NAMES(0x8174eb8)[7]=[attrs]
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
>>> result type
>>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows returned 
>>> from the query
>>> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
>>>
>>>
>>>
>>>
>>>   
>>>   
>
>
>   


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


Re: [OpenSIPS-Users] Simple DRouting Questions

2009-04-07 Thread Bogdan-Andrei Iancu
Hi Brett,

Brett Nemeroff wrote:
> All,
> Since migrating from 1.4 to 1.5, I'm also moving to use the highly 
> recommended dRouting module. I have some questions:
> 1. It's unclear to me if you specify a dr_gateway.id 
>  or a dr_gw_lists.id  for 
> the dr_rules.gwlist field. It appears to be pointed to dr_gateway.id 
> .. I'm not sure how to make it use a list (an 
> early post suggests a '#' before the list number, but this doesn't 
> appear in the docs from what I can see with my blury eyes
when defining a rule, in the dr_rules.gwlist you can specify:
(1) a list of dr_gateway.id

(2) a single dr_gw_lists.id (with #)


the options (2) was added to make provisioning easier when you have 
large number of rules with the same list of GWs..
>  
> 2. I don't see anyway to dump the store routes from memory via fifo. 
> Am I missing something?
there is none...any specific use for it? the data is loaded from DB and 
it is not changed in memory at all.
>
> 3. Is there any way to load like 4 avps at once from the attrs field?
only one per GW - if you have multiple pieces of data there, do a list 
and use transformation to split the string.


Regards,
Bogdan
>
> Thanks!
> -Brett
>
> 
>
> ___
> 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] Opensips with MediaProxy

2009-04-07 Thread Stefano Favaro




Hi,

I'm trying to use Opensips 1.5 together with mediaproxy 2.0 in the
following scenario:

Opensips + Mediarelay and dispatcher on the same machine. 
The server has 2 network interfaces: the first interface has a public
ip, the second one has a private ip.
My internal sip systems (switch, gateways, softphones etc.) connect to
the private ip.
External softphones are registered on the public ip.
Mediaproxy is binding on both ip addresses.
RTP seems to work correctly, but i have some problems with the protocol:
I've found these errors on opensips:
ERROR:core:udp_send: sendto(sock,0x81b0c30,474,0,0xbf898d78,16):
Operation not permitted(1)

After the call is connected the 200 OK message is sent continously from
the remote party and after 30 seconds the call terminates.

Do you think that this solution can be the right one or have you got
better suggestions?
Can you help me? Thanks.




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


Re: [OpenSIPS-Users] mysql problem on 1.5

2009-04-07 Thread Bogdan-Andrei Iancu
Hi Brett,

more fixes for the DB part were done today (couple of hours ago). Please 
see if those will fix your problem. If not, try to get a backtrace from 
the core files.

Thanks and regards,
Bogdan

Brett Nemeroff wrote:
> Bogdan,
> For what it's worth, I've updated to latest 1_5 tonight (about 20 
> minutes ago) and I still am having problems. Full out crashes as well.
>
> I rewrote my queries so I'd have a bunch of little (select * from acc 
> where callid=X) kinds of queries. Of course, there is a lot of DB 
> activity while this happens. Crashes start to happen within seconds of 
> the DB activity ramping up.
>
> For grins, I slowed my queries down to ensure I only did one query per 
> second (in my database, not opensips).. after about 15-20 queries 
> (different each time really) opensips would just crash.
>
> I have acc and sip_trace loaded up, sip_trace isn't active for these 
> calls. Also potentially relevant, my acc table is an InnoDB table.
>
> Now if I slowed my call volume to 1CPS and keep the queries at 1 QPS, 
> it seemed to be happier, but still crashes eventually.
>
> -Brett
>
>
>
> On Mon, Apr 6, 2009 at 11:27 AM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Hi Brett,
>
> it looks like the DB connections are dropped and reconnect is
> taking place (this are the errors about). But to find out the real
> cause, I can enable some more logs to spot the reason for
> re-connect...
>
> I will do it later as right now I'm in the middle of some DB
> debugging and I'm afraid of mixing different patches and what goes
> on SVN :)
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
> Hi All,
> So I'm doing some load testing with sipp on my opensips 1.5
> system. I just checked out (like 2 hours ago, the 1.5 branch
> from SVN).  Everything works just fine, until I run some
> rating scripts on my database (perl scripts accessing the
> mysql db directly). While my scripts are running, I see the
> UAS in sipp retransmitting the 200 OKs and the following gets
> printed to the syslog:
> http://www.pastebin.ca/1381169
>
> As soon as my perl script is done, the 200OKs stop
> retransmitting...
> My PERL script isn't doing anything terribly unusual, however,
> it is performing the queries inside of a transaction,
> including a "SELECT/DELETE * FROM acc WHERE " kind of clause.
>
> Any ideas as to what is causing this? I'm afraid I may be
> losing call records..
>
> -Brett
>
> 
> 
>
> ___
> 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.5.0 Issue with LCR next_contacts

2009-04-07 Thread Bogdan-Andrei Iancu
Hi Amit,

Amit Sharma wrote:
> Hi,
>   I was planning to upgrade to version 1.5.0 from our current version
> 1.2.2 which is quite old. We are currently using lcr module
> functionality to fork to contacts based on q-values
>   

more suitable and proofed are the core functions:
serialize_branches() + next_branches()

their were added especially to get rid of the lcr dependency in other 
modules.
>   However, it seems that opensips keeps trying the same contact in
> case only a single contact is registered. I guess one of the reasons
> is that next_contacts is returning a positive value in case
> contact_avp doesn't exist even when called from failure route. The
> changes to unify the ruri and branch handling seem to have changed
> this behavior. Is this a intentional change in behavior of
> next_contacts?
>   
I think this is the result of a bit of inconsistency in prev lcr version 
- in request_route, if no AVP was found, true was returned; in 
failure_route, in the same case, false is return.

Right now there is no difference between request or failure route (there 
is the same behaviour), but I think "false" should be returned if 
noother AVP is available
>   Are there any additional changes required (apart from defining the
> avp's)  to opensips.cfg to use the above functionality in 1.5
>   
if you use LCR only for q-based forking, batter switch to the core 
functions.

Regards,
Bogdan
>
>
> Thanks,
> Amit
>
> ___
> 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] Presence: Integrated_XCAP_Server:Status_issues

2009-04-07 Thread JayaPrakash
Hi All,
Opensips 1.5 is installed.
XCAP Server, Opensips-mi-proxy, and Soap-simple-client are running.
Presence module is loaded with Integrated XCAP Server.
Following modules are enabled in order.

presence, presence_xml, presence_mwi, pua, pua_usrloc, pua_mi,
presence_xcapdiff.

# - presence params -
modparam("presence", "db_url","mysql://opensips:opensip...@localhost
/opensips")
modparam("presence", "server_address", "sip:dev.ongobiz.com:5060")

#---xcap params
modparam("presence_xml", "db_url", "mysql://opensips:opensip...@localhost
/opensips")
modparam("presence_xml", "integrated_xcap_server", 1)

#-pua_usrloc
modparam("pua_usrloc", "default_domain", "dev.ongobiz.com")


*
X-lite is used.*
Opensips server is running. When a client add a buddy, Other side there it
is asking to allow or deny.
Even if allowed, client is not getting the status of the buddy. It is always
showing the buddy's staus as offline.
Status parameter of Watchers table is always showing value 2.
(I didn't get any error messages.)

So, Can I get the Status of Buddy in X-lite?
How to make the staus param of Watchers table to be changed to 1, when
allowed by the buddy?


Thanks
JayaPrakash


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


Re: [OpenSIPS-Users] Problem with double field P-Asserted-Identity

2009-04-07 Thread Bogdan-Andrei Iancu
Hi Matteo,

yes because arming the branch_route will be on for all branches of the 
transaction - so the branch_route() will be triggered even for the 
branch you create in the failure_route -> one PAI in failure route and 
one in branch route.

So, you can remove the PAI manipulation from the failure_route() and let 
only branch_route to do the job.

Regards,
Bogdan

mmarzu...@interfree.it wrote:
> Hi Bogdan
> I tried to follow your directions, but the problem persists.
>
> This is what I did:
>
> In the route where the function do_routing is called I inserted:
>
> 
> # Request route 'invite-to-external'
> 
> route[6] {
>  if(isflagset(20)) {
>  xlog("L_INFO", "Call to foreign domain - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
> ID=$ci\n");
>  route(2);
>  exit;
>  }
>  if(!isflagset(23)) {
>  # don't allow calls relaying from PSTN to PSTN, if not explicitely forwarded
>  if(uri=~ "^sip:[0-9]+@") {
>  xlog("L_INFO", "Call to PSTN\n");
>  do_routing();
>  xlog("L_INFO", "first attempt is $ru, attributes are $avp(s:drattrs)\n");
>  if(!goes_to_gw()) {
>  xlog("L_ERR", "No PSTN gateways available - M=$rm RURI=$ru F=$fu T=$tu 
> IP=$si ID=$ci\n");
>  sl_send_reply("503", "PSTN Termination Currently Unavailable");
>  exit;
>  }
>  setflag(21);
>
>  t_on_branch("1");
>  t_on_failure("2");
>  route(2);
>  exit;
>  }
>  }
>
>  xlog("L_INFO", "Call to unknown user - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
> ID=$ci\n");
>  sl_send_reply("404", "User Not Found");
>  exit;
> }
>
> In the branch_route:
>
> branch_route[1] {
>  if(is_present_hf("P-Asserted-Identity")) {
>  xlog("L_INFO", "Removing P-Asserted-Identity in branches\n");
>  remove_hf("P-Asserted-Identity");
>  }
>  if(is_present_hf("Remote-Party-ID")) {
>  remove_hf("Remote-Party-ID");
>  }
>  if(is_avp_set("$avp(s:caller_cli)/s")) {
>  xlog("L_INFO", "Set caller CLI '$avp(s:caller_cli)' - M=$rm RURI=$ru F=$fu 
> T=$tu IP=$si ID=$ci\n");
>  append_hf("P-Asserted-Identity: <$avp(s:caller_cli)>\r\n");
>  }
>  route(14);
> }
>
> 
> # Request route 'clir'
> 
> route[14] {
>  if(isflagset(28) && !isflagset(27)) {
>  setflag(27);
>
>  xlog("L_INFO", "Anonymize caller - M=$rm RURI=$ru F=$fu T=$tu IP=$si 
> ID=$ci\n");
>  uac_replace_from("Anonymous","sip:anonym...@anonymous.invalid");
>  if(is_present_hf("Privacy")) {
>  remove_hf("Privacy");
>  }
>  append_hf("Privacy: id\r\n");
>  }
> }
>
> 
> # Request route 'base-outbound'
> 
> route[2] {
>  xlog("L_INFO","ARRIVATO NELLA ROUTE 2\n");
>  t_on_reply("1");
>
>  if(!isflagset(21)) {
>  t_on_failure("1");
>  }
>  if(is_present_hf("Proxy-Authorization")) {
>  consume_credentials();
>  }
>
>  xlog("L_INFO", "Request leaving server, D-URI='$du' - M=$rm RURI=$ru F=$fu 
> T=$tu IP=$si ID=$ci\n");
>
>  if(!t_relay()) {
>  sl_reply_error();
>  }
>  exit;
> }
>
> In the failure_route;
>
> 
> # Failure route 'pstn-failover'
> 
> failure_route[2] {
>  xlog("L_INFO", "Failure route for PSTN entered - M=$rm RURI=$ru F=$fu T=$tu 
> IP=$si ID=$ci\n");
>  route(9);
>
>  if(!use_next_gw()) {
>  xlog("L_ERR", "Failed to select next PSTN gateway - M=$rm RURI=$ru F=$fu 
> T=$tu IP=$si ID=$ci\n");
>  exit;
>  }
>  xlog("L_INFO", "selected next gateway $ru, attributes are 
> $avp(s:drattrs)\n");
>
>  if(is_present_hf("P-Asserted-Identity")) {
>  xlog("L_INFO", "Removing P-Asserted-Identity in failure route\n");
>  remove_hf("P-Asserted-Identity");
>  }
>  if(is_present_hf("Remote-Party-ID")) {
>  remove_hf("Remote-Party-ID");
>  }
>  if(is_avp_set("$avp(s:caller_cli)/s")) {
>  xlog("L_INFO", "Set caller CLI '$avp(s:caller_cli)' - M=$rm RURI=$ru F=$fu 
> T=$tu IP=$si ID=$ci\n");
>  append_hf("P-Asserted-Identity: <$avp(s:caller_cli)>\r\n");
>  #append_hf("Remote-Party-ID: 
> <$avp(s:caller_cli)>;party=caller;privacy=none;screen=yes\r\n");
>  }
>  route(14);
>
>  t_on_failure("2");
>  route(2);
> }
>
> In the INVITE sent from proxy to the second gateway are still two P-Asserted 
> Idntity fields.
> Where am I wrong?
>
> Thanks in advance.
>
> Matteo Marzuola
>
>
>
>
>   
>> Hi Matteo,
>> 
>
>   
>> Whatever change you in request_route will propagate in all branches - 
>> this is your problem - when you set the PAI for the first destination, 
>> in request_route, the PAI will be present in all future branches.
>> 
>
>   
>> To avoid this situation, avoid adding "per-branch" info from 
>> request_branch - do it from branch_route; branch_route and failure_route 
>> allows change

Re: [OpenSIPS-Users] no audio from caller when using nathelper

2009-04-07 Thread Bogdan-Andrei Iancu
Hi Gabriel,

So you are not using rtpproxy, but rely on the fact that * is all the 
time public. In this case, audio from caller to * should work all the 
time as the destination is public (of course, if the caller does send 
RTP). For the other way around, you can be sure * sends RTP to the 
public IP of the NAT (of the client) by doing fix_nated_sdp("1") for the 
invite - this will force the COMEDIA support in *.

Anyhow, for RTP nat traversal to work, it is mandatory for the party 
behind the nat to start sending RTP (to open the NAT). If the natted 
party will send no RTP, there will be no audio at all.

Regard,
Bogdan

Gabriel Bermudez wrote:
> Hi everyone,
>
> I'm using the nathelper and dispatcher module to send calls to an 
> Asterisk server.  I'm using the Asterisk as a SIP to H.323 converter 
> because our PSTN gateway only speaks H.323
> For some reason *sometimes* the caller does not send RTP traffic to the 
> opensips (one way audio).  The caller's UA is behind a NAT, but it 
> doesn't gets detected as a nated UA, so the RTP flow is between the 
> client's public IP and the Asterisk public IP (rtpproxy is not used).  
> I'm not sure if this problems happens also with UAs that get NAT 
> detected (not seen it happen).  I used tshark to capture the invite from 
> an undetected NAT UA (changed the UA ip with *uac_public_ip* and 
> opensip's ip with *opensips_public_ip*)
>
> Session Initiation Protocol
> Request-Line: INVITE sip:0059389954...@opensips_public_ip SIP/2.0
> Method: INVITE
> [Resent Packet: False]
> Message Header
> To: 
> SIP to address: sip:0059389954...@opensips_public_ip
> Accept: 
> application/dtmf-relay,application/sdp,text/plain,message/sipfrag,application/sip
> User-Agent: YV1/1.2.0
> Via: SIP/2.0/UDP uac_public_ip:10759;rport;branch=z9hG4bK474bfa15
> Transport: UDP
> Sent-by Address: uac_public_ip
> Sent-by port: 10759
> RPort: rport
> Branch: z9hG4bK474bfa15
> From: "710406702";tag=41a8c40d
> SIP Display info: "710406702"
> SIP from address: sip:710406...@opensips_public_ip
> SIP tag: 41a8c40d
> Allow: UPDATE,INFO,PRACK,REFER,NOTIFY,INVITE,ACK,OPTIONS,BYE,CANCEL
> Allow-Events: refer
> Call-ID: 27f2a0fb-390a1f2a-5e9e57cd-1ee3a...@uac_public_ip
> Max-Forwards: 70
> Contact: 
> Contact Binding: 
> URI: 
> SIP contact address: sip:710406...@uac_public_ip:10759
> Session-Expires: 1800
> Content-Length: 313
> Content-Type: application/sdp
> Supported: timer,100rel,join,tdialog,replaces,norefersub,histinfo
> CSeq: 57741 INVITE
> Sequence Number: 57741
> Method: INVITE
> Message Body
> Session Description Protocol
> Session Description Protocol Version (v): 0
> Owner/Creator, Session Id (o): ipr1B24E8AED4 4453550 4453550 
> IN IP4 uac_public_ip
> Owner Username: ipr1B24E8AED4
> Session ID: 4453550
> Session Version: 4453550
> Owner Network Type: IN
> Owner Address Type: IP4
> Owner Address: uac_public_ip
> Session Name (s): -
> Connection Information (c): IN IP4 uac_public_ip
> Connection Network Type: IN
> Connection Address Type: IP4
> Connection Address: uac_public_ip
> Time Description, active time (t): 0 0
> Session Start Time: 0
> Session Stop Time: 0
> Media Description, name and address (m): audio 10760 RTP/AVP 
> 0 8 4 18 101
> Media Type: audio
> Media Port: 10760
> Media Proto: RTP/AVP
> Media Format: ITU-T G.711 PCMU
> Media Format: ITU-T G.711 PCMA
> Media Format: ITU-T G.723
> Media Format: ITU-T G.729
> Media Format: 101
> Media Attribute (a): rtpmap:0 PCMU/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 0
> MIME Type: PCMU
> Media Attribute (a): rtpmap:8 PCMA/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 8
> MIME Type: PCMA
> Media Attribute (a): rtpmap:4 G723/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 4
> MIME Type: G723
> Media Attribute (a): rtpmap:18 G729/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 18
> MIME Type: G729
> Media Attribute (a): rtpmap:101 telephone-event/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 101
> 

[OpenSIPS-Users] opensips 1.5 with load_balancing

2009-04-07 Thread Uwe Kastens
Hi,

I configured load_balancing following the tutorial.

The call is relayed via t_relay to the 1st pstn gw. After that I will
receive the following error: "ERROR:load_balancer:do_load_balance:
failed to create dialog" and it looks like, that I am missing some answers.

BR

uwe


-- 

kiste lat: 54.322684, lon: 10.13586

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


Re: [OpenSIPS-Users] opensips 1.5 with load_balancing

2009-04-07 Thread Bogdan-Andrei Iancu
HI Uwe,

can you post a debug=6 log of the entire call?

Thanks and regards,
Bogdan

Uwe Kastens wrote:
> Hi,
>
> I configured load_balancing following the tutorial.
>
> The call is relayed via t_relay to the 1st pstn gw. After that I will
> receive the following error: "ERROR:load_balancer:do_load_balance:
> failed to create dialog" and it looks like, that I am missing some answers.
>
> BR
>
> uwe
>
>
>   


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


[OpenSIPS-Users] dispatcher and attended transfers

2009-04-07 Thread Stanisław Pitucha
Hi,
I'm trying to find a solution for using both a dispatcher and attended
transfers reliably.
Standard problems are:
- calls from user A must go to the same pbx as all ongoing calls To and From A
- dispatcher failover must work properly if there's a record of A's
dialog with PBX-1, but PBX-1 goes down

Issues that make this scenario hard to solve are:
- afaik, there's no good way to get the destination of other dialogs,
other than a sql query
- ds_select_domain doesn't work from failure route, so selecting a
"preferred" destination as well as failover routes must be done in the
same place

I made a patch for the dispatcher module that solves that more or less
(additional avp decides host to prepend to the list), but it has it's
own issues ("preferred" host appears twice in the destinations list,
marking bad hosts is probably buggy), so I'm not really happy with
that way to solve it.

Has anyone got a working solution for this problem?

Thanks,
Stan

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


Re: [OpenSIPS-Users] dispatcher and attended transfers

2009-04-07 Thread Adrian Georgescu
You cannot do this reliable the way you propose. The only reliable way  
is to sit behind a PBX/B2BUA that your control and behaves in a  
consistent and reliable way. Otherwise you are at the mercy at the  
combinations of the SIP User Agents that are involved in the call  
transfer operation.


If you will try to fix incrementally every problem your discover in  
the SIP Proxy for call transfer you will be busy forever solving this  
because is end-point implementation dependent.


Adrian


On Apr 7, 2009, at 6:41 PM, Stanisław Pitucha wrote:


Hi,
I'm trying to find a solution for using both a dispatcher and attended
transfers reliably.



Standard problems are:
- calls from user A must go to the same pbx as all ongoing calls To  
and From A

- dispatcher failover must work properly if there's a record of A's
dialog with PBX-1, but PBX-1 goes down

Issues that make this scenario hard to solve are:
- afaik, there's no good way to get the destination of other dialogs,
other than a sql query
- ds_select_domain doesn't work from failure route, so selecting a
"preferred" destination as well as failover routes must be done in the
same place

I made a patch for the dispatcher module that solves that more or less
(additional avp decides host to prepend to the list), but it has it's
own issues ("preferred" host appears twice in the destinations list,
marking bad hosts is probably buggy), so I'm not really happy with
that way to solve it.

Has anyone got a working solution for this problem?

Thanks,
Stan

___
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] dispatcher and attended transfers

2009-04-07 Thread Stanisław Pitucha
2009/4/7 Adrian Georgescu :
> You cannot do this reliable the way you propose. The only reliable way is to
> sit behind a PBX/B2BUA that your control and behaves in a consistent and
> reliable way. Otherwise you are at the mercy at the combinations of the SIP
> User Agents that are involved in the call transfer operation.

There is only one specific scenario I want to support:
- phone has a dialog already open to a PBX
- phone sends an new call INVITE  to a PBX
- phone joins the call legs with a REFER

I think, this is the PBX/B2BUA situation you're talking about?

I'm not sure what you mean by "the combinations of the SIP User Agents
that are involved". I didn't have any problems with this setup as long
as the same phone always uses the same pbx.

> If you will try to fix incrementally every problem your discover in the SIP
> Proxy for call transfer you will be busy forever solving this because is
> end-point implementation dependent.

I'm only trying to solve failover + distribution over PBXes in the
proxy. Transfers are properly handled by N asterisk hosts.
To be specific - my network looks like this:
UAs <-> openser (with dispatcher) <-> N identical asterisk boxes
All calls go through one of the asterisk boxes.

Stan

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


Re: [OpenSIPS-Users] Opensips fifo - dp_reload hangs

2009-04-07 Thread Dan-Cristian Bogos
Hi Bogdan,

Many thanks for solving it so fast.

I can confirm that all OK now.

Cheers,
DanB

On Tue, 2009-04-07 at 17:18 +0300, Bogdan-Andrei Iancu wrote:
> Hi Dan,
> 
> As expected, the "debug" function strikes again (some unhandled  return 
> if data was null was causing a deadlock)..
> 
> Fixed, tested and backported to 1.5.
> 
> Thanks again for your help,
> 
> Regards,
> Bogdan
> 
> Dan-Cristian Bogos wrote:
> > Hi Bogdan,
> >
> > I have updated to trunk and tested again. Here is what I found out:
> >
> > * First "dp_reload" is successful.
> > * Second "dp_reload" hangs, even for empty dialplan table.
> >
> > Let me know if you need any further tests.
> >
> > Ta,
> > DanB
> >
> >
> > On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
> >   
> >> Hi Dan,
> >>
> >> I found the bug and fixed it - for the moment the fix is on trunk only 
> >> and if you could test it before backport to 1.5, it will be great.
> >>
> >> Thanks and regards,
> >> Bogdan
> >>
> >> Dan-Cristian Bogos wrote:
> >> 
> >>> Hi Bogdan,
> >>>
> >>> I have managed to make some more tests for the "dp_reload" issue, and 
> >>> came out the following:
> >>>
> >>> * The issue is not server dependent. I have installed an opensips server 
> >>> on a completely different machine with different architecture, and same 
> >>> issue came up again.
> >>> * The issue is not data dependent. On the test machine I have emptied 
> >>> completely the dialplan table and issued a dp_reload command, same thing 
> >>> happened, fifo was destroyed and the command hanged (tried other commands 
> >>> later and no response).
> >>> * "dp_translate" command works fine.
> >>>
> >>> Bellow you can find the debug for the "dp_reload" with empty dialplan 
> >>> table in the database. 
> >>>
> >>> Can u try my scenario in your labs? I am not doing anything specific, so 
> >>> if this is a bug, it can be common one.
> >>>
> >>> Ta,
> >>> DanB
> >>>
> >>> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
> >>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
> >>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server:  done consume
> >>> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi 
> >>> tree
> >>> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
> >>> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT 
> >>> successfully executed!
> >>> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for 
> >>> result set at 0x8174dc8
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns 
> >>> returned from the query
> >>> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes 
> >>> for result columns at 0x8174e60
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174e80)[0]=[dpid]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174e88)[1]=[pr]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174e90)[2]=[match_op]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174e98)[3]=[match_exp]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174ea0)[4]=[match_len]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174ea8)[5]=[subst_exp]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174eb0)[6]=[repl_exp]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> >>> RES_NAMES(0x8174eb8)[7]=[attrs]
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> >>> result type
> >>> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows 
> >>> returned from the query
> >>> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
> >>>
> >>>
> >>>
> >>>
> >>>   
> >>>   
> >
> >
> >   
> 


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


Re: [OpenSIPS-Users] Opensips fifo - dp_reload hangs

2009-04-07 Thread Bogdan-Andrei Iancu
Super :)

Thanks and regards,
Bogdan

Dan-Cristian Bogos wrote:
> Hi Bogdan,
>
> Many thanks for solving it so fast.
>
> I can confirm that all OK now.
>
> Cheers,
> DanB
>
> On Tue, 2009-04-07 at 17:18 +0300, Bogdan-Andrei Iancu wrote:
>   
>> Hi Dan,
>>
>> As expected, the "debug" function strikes again (some unhandled  return 
>> if data was null was causing a deadlock)..
>>
>> Fixed, tested and backported to 1.5.
>>
>> Thanks again for your help,
>>
>> Regards,
>> Bogdan
>>
>> Dan-Cristian Bogos wrote:
>> 
>>> Hi Bogdan,
>>>
>>> I have updated to trunk and tested again. Here is what I found out:
>>>
>>> * First "dp_reload" is successful.
>>> * Second "dp_reload" hangs, even for empty dialplan table.
>>>
>>> Let me know if you need any further tests.
>>>
>>> Ta,
>>> DanB
>>>
>>>
>>> On Mon, 2009-04-06 at 19:14 +0300, Bogdan-Andrei Iancu wrote:
>>>   
>>>   
 Hi Dan,

 I found the bug and fixed it - for the moment the fix is on trunk only 
 and if you could test it before backport to 1.5, it will be great.

 Thanks and regards,
 Bogdan

 Dan-Cristian Bogos wrote:
 
 
> Hi Bogdan,
>
> I have managed to make some more tests for the "dp_reload" issue, and 
> came out the following:
>
> * The issue is not server dependent. I have installed an opensips server 
> on a completely different machine with different architecture, and same 
> issue came up again.
> * The issue is not data dependent. On the test machine I have emptied 
> completely the dialplan table and issued a dp_reload command, same thing 
> happened, fifo was destroyed and the command hanged (tried other commands 
> later and no response).
> * "dp_translate" command works fine.
>
> Bellow you can find the debug for the "dp_reload" with empty dialplan 
> table in the database. 
>
> Can u try my scenario in your labs? I am not doing anything specific, so 
> if this is a bug, it can be common one.
>
> Ta,
> DanB
>
> wtdev1:/etc/opensips# opensipsctl fifo dp_reload
> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: entered consume
> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server:  done consume
> Apr  6 13:53:27 [8508] DBG:mi_fifo:mi_fifo_server: done parsing the mi 
> tree
> Apr  6 13:53:27 [8508] DBG:dialplan:dp_load_db: init
> Apr  6 13:53:27 [8508] DBG:core:db_do_query: SYNC-DBG - SELECT 
> successfully executed!
> Apr  6 13:53:27 [8508] DBG:core:db_new_result: allocate 28 bytes for 
> result set at 0x8174dc8
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 8 columns 
> returned from the query
> Apr  6 13:53:27 [8508] DBG:core:db_allocate_columns: allocate 128 bytes 
> for result columns at 0x8174e60
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174e80)[0]=[dpid]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174e88)[1]=[pr]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174e90)[2]=[match_op]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174e98)[3]=[match_exp]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174ea0)[4]=[match_len]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_INT 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174ea8)[5]=[subst_exp]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174eb0)[6]=[repl_exp]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: 
> RES_NAMES(0x8174eb8)[7]=[attrs]
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_get_columns: use DB_STRING 
> result type
> Apr  6 13:53:27 [8508] DBG:db_mysql:db_mysql_fetch_result: no rows 
> returned from the query
> Apr  6 13:53:27 [8508] WARNING:dialplan:dp_load_db: no data in the db
>
>
>
>
>   
>   
>   
>>>   
>>>   
>
>
>   


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


Re: [OpenSIPS-Users] opensips 1.5 with load_balancing

2009-04-07 Thread Uwe Kastens
Hi Bogdan,

Here we go.

BR

Uwe


Bogdan-Andrei Iancu schrieb:
> HI Uwe,
> 
> can you post a debug=6 log of the entire call?
> 
> Thanks and regards,
> Bogdan
> 
> Uwe Kastens wrote:
>> Hi,
>>
>> I configured load_balancing following the tutorial.
>>
>> The call is relayed via t_relay to the 1st pstn gw. After that I will
>> receive the following error: "ERROR:load_balancer:do_load_balance:
>> failed to create dialog" and it looks like, that I am missing some
>> answers.
>>
>> BR
>>
>> uwe
>>
>>
>>   
> 
> 


-- 

kiste lat: 54.322684, lon: 10.13586



lb_log.txt.gz
Description: GNU Zip compressed data
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] newbie: question on call control

2009-04-07 Thread Nhadie
Hi All,

Just installed opensips yesterday, using the default config file i was 
able to do some user to user calling, and then adding some URI  checking 
and rewritehost i was able to send calls to my gateway. now i would like 
to test the call control for prepaid, my question is simply do i need 
radius to be able to use the call control? thanks

regards,
nhadie

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


[OpenSIPS-Users] ACC Problem. to_did blown away.

2009-04-07 Thread Brett Nemeroff
Hey All,I'm sure I'm doing someting stupid here.. In general, I set all the
acc_db flags at the top of my script so everything gets logs. I'm getting
486 Busy from the far end and nice, pretty to_did from the original RURI is
being blown away with 'sip:mod_sofia'

Question is.. what do I need to do to get the 486 logged, but to have the
right did in the record.. right now I use $oU. Maybe a revert_uri? (am I
making that up?)


Here's the 486 from my upstream:


U 5.6.239.142:5060 -> 1.2.204.8:5060

SIP/2.0 486 Busy Here.

Via: SIP/2.0/UDP 1.2.204.8;branch=z9hG4bK5a3.473e0af1.0.

Via: SIP/2.0/UDP 2.3.72.138:5060
;received=2.3.72.138;branch=z9hG4bK0bf20a91;rport=5060.

From: "custdomain.com" ;tag=as0e9ef59a.

To: 
>;tag=BeZcHaUmX1D8Q.

Call-ID: 29728c50765bdc3275a6bd375a650...@2.3.72.138.

CSeq: 103 INVITE.

User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-12911.

Accept: application/sdp.

Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY,
REFER, UPDATE, REGISTER, INFO, PUBLISH.

Supported: timer, precondition, path, replaces.

Content-Length: 0.

.



U 2.3.72.138:5060 -> 1.2.204.8:5060

ACK sip:mod_so...@63.211.239.143:5060;transport=udp SIP/2.0.

Via: SIP/2.0/UDP 2.3.72.138:5060;branch=z9hG4bK0bf20a91;rport.

Route:
,.

Max-Forwards: 70.

From: "custdomain.com" ;tag=as0e9ef59a.

To: 
>;tag=BeZcHaUmX1D8Q.

Contact: .

Call-ID: 29728c50765bdc3275a6bd375a650...@2.3.72.138.

CSeq: 103 ACK.

User-Agent: SS.

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


Re: [OpenSIPS-Users] no audio from caller when using nathelper

2009-04-07 Thread Gabriel Bermudez
Thanks for your answer Bogdan

Bogdan-Andrei Iancu escribió:
> Hi Gabriel,
>
> So you are not using rtpproxy, but rely on the fact that * is all the 
> time public. In this case, audio from caller to * should work all the 
> time as the destination is public (of course, if the caller does send 
> RTP). For the other way around, you can be sure * sends RTP to the 
> public IP of the NAT (of the client) by doing fix_nated_sdp("1") for 
> the invite - this will force the COMEDIA support in *.
Yes, some phones set their contact header with the correct public IP 
address, that's when rptproxy is not used.  In this case they use * 
directly (but using opensips as a proxy).  I do use fix_nated_sdp("1"), 
but only when the nat_uac_test("3") gets passed.

if (nat_uac_test("3")) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER

if (method == "REGISTER" || ! search("^Record-Route:")) {
log("LOG: Someone trying to register from private 
IP, rewriting\n");

# This will work only for user agents that support 
symmetric
# communication. We tested quite many of them and 
majority is
# smart enough to be symmetric. In some phones it 
takes a configuration
# option. With Cisco 7960, it is called 
NAT_Enable=Yes, with kphone it is
# called "symmetric media" and "symmetric signalling".

fix_nated_contact(); # Rewrite contact with source 
IP of signalling
force_rport(); # Add rport parameter to topmost Via
setflag(6);# Mark as NATed
};

if (method == "INVITE") {
fix_nated_sdp("1"); # Add direction=active to SDP
};
};

>
> Anyhow, for RTP nat traversal to work, it is mandatory for the party 
> behind the nat to start sending RTP (to open the NAT). If the natted 
> party will send no RTP, there will be no audio at all.
And that's exactly what wasn't happening, *sometimes* (the sometimes was 
the one bugging me really).  It seemed not a opensips nat issue but a 
asterisk nat issue.  So I setted up asterisk's realtime with the 
following view

CREATE OR REPLACE VIEW sipfriends AS
 SELECT subscriber.username AS name, 'friend'::character varying AS 
"type", subscriber.username, subscriber."password" AS secret, 
'dynamic'::character varying AS host, 'rfc2833'::character varying AS 
dtmfmode, 'all'::character varying AS disallow, 'g729'::character 
varying AS allow, 'no'::character varying AS canreinvite, 
'yes'::character varying AS nat, 'from-ser'::character varying AS 
context, ''::character varying AS regserver, 0 AS regseconds
   FROM subscriber;

As you can see, nat=yes always.  Seems that this solved the problem, 
I'll do some more testing tomorrow ;)
Thanks for your help.

Regards,

>
> Regard,
> Bogdan
>
> Gabriel Bermudez wrote:
>> Hi everyone,
>>
>> I'm using the nathelper and dispatcher module to send calls to an 
>> Asterisk server.  I'm using the Asterisk as a SIP to H.323 converter 
>> because our PSTN gateway only speaks H.323
>> For some reason *sometimes* the caller does not send RTP traffic to 
>> the opensips (one way audio).  The caller's UA is behind a NAT, but 
>> it doesn't gets detected as a nated UA, so the RTP flow is between 
>> the client's public IP and the Asterisk public IP (rtpproxy is not 
>> used).  I'm not sure if this problems happens also with UAs that get 
>> NAT detected (not seen it happen).  I used tshark to capture the 
>> invite from an undetected NAT UA (changed the UA ip with 
>> *uac_public_ip* and opensip's ip with *opensips_public_ip*)
>>
>> Session Initiation Protocol
>> Request-Line: INVITE sip:0059389954...@opensips_public_ip SIP/2.0
>> Method: INVITE
>> [Resent Packet: False]
>> Message Header
>> To: 
>> SIP to address: sip:0059389954...@opensips_public_ip
>> Accept: 
>> application/dtmf-relay,application/sdp,text/plain,message/sipfrag,application/sip
>>  
>>
>> User-Agent: YV1/1.2.0
>> Via: SIP/2.0/UDP 
>> uac_public_ip:10759;rport;branch=z9hG4bK474bfa15
>> Transport: UDP
>> Sent-by Address: uac_public_ip
>> Sent-by port: 10759
>> RPort: rport
>> Branch: z9hG4bK474bfa15
>> From: "710406702";tag=41a8c40d
>> SIP Display info: "710406702"
>> SIP from address: sip:710406...@opensips_public_ip
>> SIP tag: 41a8c40d
>> Allow: 
>> UPDATE,INFO,PRACK,REFER,NOTIFY,INVITE,ACK,OPTIONS,BYE,CANCEL
>> Allow-Events: refer
>> Call-ID: 27f2a0fb-390a1f2a-5e9e57cd-1ee3a...@uac_public_ip
>> Max-Forwards: 70
>> Contact: 
>> Contact Binding: 
>> URI: 
>> S

Re: [OpenSIPS-Users] mysql problem on 1.5

2009-04-07 Thread Jeff Pyle
Bogdan,

For what it's worth, these changes have not affected my inability to connect
to the siptrace db more often than not.  Still the same error 2003 as
before.


- Jeff



On 4/7/09 11:35 AM, "Bogdan-Andrei Iancu"  wrote:

> Hi Brett,
> 
> more fixes for the DB part were done today (couple of hours ago). Please
> see if those will fix your problem. If not, try to get a backtrace from
> the core files.
> 
> Thanks and regards,
> Bogdan
> 
> Brett Nemeroff wrote:
>> Bogdan,
>> For what it's worth, I've updated to latest 1_5 tonight (about 20
>> minutes ago) and I still am having problems. Full out crashes as well.
>> 
>> I rewrote my queries so I'd have a bunch of little (select * from acc
>> where callid=X) kinds of queries. Of course, there is a lot of DB
>> activity while this happens. Crashes start to happen within seconds of
>> the DB activity ramping up.
>> 
>> For grins, I slowed my queries down to ensure I only did one query per
>> second (in my database, not opensips).. after about 15-20 queries
>> (different each time really) opensips would just crash.
>> 
>> I have acc and sip_trace loaded up, sip_trace isn't active for these
>> calls. Also potentially relevant, my acc table is an InnoDB table.
>> 
>> Now if I slowed my call volume to 1CPS and keep the queries at 1 QPS,
>> it seemed to be happier, but still crashes eventually.
>> 
>> -Brett
>> 
>> 
>> 
>> On Mon, Apr 6, 2009 at 11:27 AM, Bogdan-Andrei Iancu
>> mailto:bog...@voice-system.ro>> wrote:
>> 
>> Hi Brett,
>> 
>> it looks like the DB connections are dropped and reconnect is
>> taking place (this are the errors about). But to find out the real
>> cause, I can enable some more logs to spot the reason for
>> re-connect...
>> 
>> I will do it later as right now I'm in the middle of some DB
>> debugging and I'm afraid of mixing different patches and what goes
>> on SVN :)
>> 
>> Regards,
>> Bogdan
>> 
>> Brett Nemeroff wrote:
>> 
>> Hi All,
>> So I'm doing some load testing with sipp on my opensips 1.5
>> system. I just checked out (like 2 hours ago, the 1.5 branch
>> from SVN).  Everything works just fine, until I run some
>> rating scripts on my database (perl scripts accessing the
>> mysql db directly). While my scripts are running, I see the
>> UAS in sipp retransmitting the 200 OKs and the following gets
>> printed to the syslog:
>> http://www.pastebin.ca/1381169
>> 
>> As soon as my perl script is done, the 200OKs stop
>> retransmitting...
>> My PERL script isn't doing anything terribly unusual, however,
>> it is performing the queries inside of a transaction,
>> including a "SELECT/DELETE * FROM acc WHERE " kind of clause.
>> 
>> Any ideas as to what is causing this? I'm afraid I may be
>> losing call records..
>> 
>> -Brett
>> 
>> 
>> 
>> 
>> ___
>> 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


[OpenSIPS-Users] Modifying INVITE header to add phone-context

2009-04-07 Thread Julian Yap
I have a PSTN gateway which requires a Phone-Context value in the
outgoing SIP INVITE message to further apply ISDN NPI/TON details.

Here's an example of what I currently have going out to the PSTN gateway:
INVITE sip:1...@sip.server.com:5060;user=phone SIP/2.0.

This is what I require:
INVITE sip:1...@sip.server.com:5060;phone-context=sip.server.com;user=phone
SIP/2.0.

Any clues on how to add the Phone-Context value?

Thanks,
Julian

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


Re: [OpenSIPS-Users] Stop time is not Updated by the internal bye in Local_route

2009-04-07 Thread ASHWINI NAIDU
hi bogdan,

I am referring to the stop time generated by radius which is updated in
radacct. Anyways i Have resolved the issue.



On Mon, Apr 6, 2009 at 10:11 PM, Bogdan-Andrei Iancu  wrote:

> Hi Ashwini,
>
> What "stop" time are you refering to?
>
> Regards,
> Bogdan
>
> ASHWINI NAIDU wrote:
>
>> hi,
>>  When the call controller sends a dlg_end_dlg  to the 2 end-points after
>> the balance tends to nil. The internal bye is entering the local_route but
>> it is not updating the stop time.
>>
>> Below is the piece of code in local_route
>>
>> local_route {
>>
>>if ( method == "BYE") {
>>log(1,"\nInternal bye was generated\n");
>>setflag(3);
>>unforce_rtp_proxy();
>>acc_db_request("Internally generated BYE", "acc");
>>};
>> }
>>
>>
>> --
>> Thanking You,
>> Ashwini BR Naidu
>> 
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>


-- 
Thanking You,
Ashwini BR Naidu
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users