Re: [OpenSIPS-Users] Opensips cannot start with entries in b2b_entities

2013-11-18 Thread Jeff Pyle
Bogdan,

Well, not much.  Here is everything from where it starts to read the
b2b_entities table (called "b2b_entities3" here) through to the end.

Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: request for table
[b2b_entities3]
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: db is
[/etc/opensips/dbtext]
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: loading file
[/etc/opensips/dbtext/b2b_entities3]
Nov 18 22:36:03 [27724] DBG:db_text:dbt_table_new: mtime is 1384832141
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[0] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[1] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[2] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[3] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[3] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[4] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[4] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[5] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[5] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[6] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[6] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[7] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[7] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[8] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[8] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[9] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[9] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[10] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[10] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[11] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[12] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[13] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[13] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[14] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[14] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[15] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[15] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[16] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[16] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[17] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[17] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[18] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[18] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[19] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[20] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[21] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[22] is INT!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[23] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[23] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[24] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[24] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[25] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[25] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[26] is STR!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_load_file: column[26] is actually
STRING!
Nov 18 22:36:03 [27724] DBG:db_text:dbt_query: new res with 25 cols
Nov 18 22:36:03 [27724] DBG:db_text:dbt_result_new: new res with 25 cols
Nov 18 22:36:03 [27724] DBG:core:db_new_result: allocate 48 bytes for
result set at 0x7f2b7e70e068
Nov 18 22:36:03 [27724] DBG:core:db_allocate_columns: allocate 700 bytes
for result columns at 0x7f2b7e7102d8
Nov 18 22:36:03 [27724] DBG:core:db_allocate_rows: allocate 1632 bytes for
result rows and values at 0x7f2b7e7105f8
Nov 18 22:36:03 [27724] DBG:b2b_entities:b2b_entities_restore: loading
information from database 2 records
Nov 18 22:36:03 [27724] DBG:b2b_entities:b2b_parse_key: hash_index = [155]
 - local_index= [494]
Nov 18 22:36:03 [27722] DBG:core:wait_status_code: read code 0 ? rc = 0,
errno=Success
Nov 18 22:36:03 [27722] INFO:core:daemonize: pre-daemon process exiting
with -1

The 2 records in this case were from one call with b2b topology hiding.


- Jeff


On Thu, Nov 14, 2013 at 5:27 AM, Bogdan-Andrei Iancu wrote:

>  Hi Jeff,
>
> So no errors, no nothing in the logs, but simply failing to start ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.

Re: [OpenSIPS-Users] Dialplan dp_translate error

2013-11-18 Thread Alexander Mustafin
Thanks, Liviu!

My bad - the rule is wrong. And in the debug I’ve seen error:

Nov 19 03:20:02 ops /usr/sbin/opensips[31841]: DBG:dialplan:build_rule: 
Compiling ^\d{3,6}\%23\d*$ expression with flag: 0
Nov 19 03:20:02 ops /usr/sbin/opensips[31841]: DBG:dialplan:build_rule: 
building subst rule
Nov 19 03:20:02 ops /usr/sbin/opensips[31841]: DBG:dialplan:build_rule: 
references:0 , max:2
Nov 19 03:20:02 ops /usr/sbin/opensips[31841]: ERROR:dialplan:build_rule: 
repl_exp uses a non existing subexpression
Nov 19 03:20:02 ops /usr/sbin/opensips[31841]: WARNING:dialplan:dp_load_db:  
failed to build rule -> skipping
Nov 19 03:20:02 ops /usr/sbin/opensips[31841]: DBG:core:db_free_rows: freeing 3 
rows

Previously, dp_reload don’t put anything in debug. And I don’t check log. :))

Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.com




18 нояб. 2013 г., в 20:47, Liviu Chircu  написал(а):

> Hello again,
> 
> On second thoughts, I can tell you're running a post 1.9 version of OpenSIPS. 
> Now in debug mode you should see all the rules being dumped in the logs with 
> every "reload" operation, either at startup or through MI.
> 
> Could you check if the DPID: 3 rules actually appear listed in that very 
> verbose dump?
> 
> Best regards,
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
> On 11/18/2013 01:54 PM, Alexander Mustafin wrote:
>> Hi.
>> 
>> I’m using some translation rules for various purposes.
>> I’ve got dial plan rule with dpid=3, but when I try to do dp_translate(«3»…) 
>> - I see next message in the log:
>> 
>> Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_get_ivalue: 
>> searching 4
>> Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_translate_f: 
>> dpid is 3
>> Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_get_svalue: 
>> searching 19
>> Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_translate_f: 
>> input is 1001%23777
>> Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_translate_f: 
>> no information available for dpid 3
>> 
>> Rule in database:
>> 3 3 0 1 ^\d{3,6}\%23\d*$ 0 ^\d{3,6}\%23\d*$ \2 0 
>> 
>> I was tried dp_reload and restart server - but unsuccessfully. If I use same 
>> rule with dpid=1 - all works fine ((
>> 
>> Best regards,
>> Alexander Mustafin
>> mustafin.aleksa...@gmail.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

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


Re: [OpenSIPS-Users] AVP-based uac_auth in b2bua

2013-11-18 Thread Jeff Pyle
Yes:

# - tm params -
modparam("tm", "fr_timer", 2)
modparam("tm", "fr_inv_timer", 118)
modparam("tm", "disable_6xx_block", 1)
modparam("tm", "restart_fr_on_each_reply", 0)
modparam("tm", "onreply_avp_mode", 1)


- Jeff


On Mon, Nov 18, 2013 at 7:36 PM, Ovidiu Sas  wrote:

> Did you set the onreply_avp_mode for tm:
> http://www.opensips.org/html/docs/modules/devel/tm.html#id293972
>
>
> On Monday, November 18, 2013, Jeff Pyle wrote:
>
>> It's 1.10 pulled from git a few hours ago.  Debian 7 64-bit.
>>
>> The AVPs are set prior to calling the b2b scenario:
>>
>> modparam("uac_auth","auth_realm_avp",   "$avp(auth_realm)")
>> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
>> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
>> #modparam("uac_auth","credential","UserName:AuthRealm123:SuperS33cret")
>>
>> route {
>>   ...
>> $avp(auth_user)  := "UserName";
>> $avp(auth_pass)  := "SuperS33cret";
>> $avp(auth_realm) := "AuthRealm123";
>>
>> b2b_init_request("top hiding/t105");
>> ...
>> }
>>
>>
>> debugs:
>>
>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback: Received reply
>> [407] for dialog [0x7ff941c13268], method [INVITE]
>> Nov 18 18:07:55 [26004] DBG:tm:t_unref_cell: UNREF_UNSAFE:
>> [0x7ff941c18448] after is 1
>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback:
>> dlg=[0x7ff941c13268], uac_tran=NULL
>>  Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
>> ="AuthRealm123" state=2
>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
>> ="528a9de900013e5f13fe985df4a9848356a1f937207ecfe4" state=3
>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body: ="auth"
>> state=1
>> Nov 18 18:07:55 [26004] DBG:b2b_logic:b2bl_parse_key: hash_index = [472]
>>  - local_index= [0]
>>
>>
>>
>> The following (successful) debugs occur if I uncomment the credential
>> modparam visible above:
>>
>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
>> dlg=[0x7f8a06744c30], uac_tran=NULL
>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
>> ="66.94.76.24" state=2
>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
>> ="528a9fbf00014297ef8f2335679f0310537c85fe2b007186" state=3
>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body: ="auth"
>> state=1
>> Nov 18 18:15:45 [26118] DBG:uac_auth:build_authorization_hdr: auth_hdr is
>> > nonce="528a9fbf00014297ef8f2335679f0310537c85fe2b007186",
>> uri="sip:2165551212@domain", qop=auth, nc=0001, cnonce="3105687311",
>> response="ef047011046690b6eea99c7848de499a", algorithm=MD5
>> >
>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
>> [Proxy-Authorization: Digest ...]
>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback: uri [...]
>>
>>
>>
>> I tried to follow the source to isolate the failing mechanism.  I arrived
>> at modules/uac_auth/auth.c.  In get_avp_credential() at line 199:
>>
>> avp = search_first_avp( realm_avp_type, realm_avp_name, &val, 0);
>> if ( avp==NULL || (avp->flags&AVP_VAL_STR)==0 || val.s.len<=0 )
>> return 0;
>>
>> In my case I've discovered avp==NULL so the if-statement returns 0.
>>  avp==NULL because in the search_first_avp() at line 346 of usr_avp.c:
>>
>> if (*crt_avps==0)
>> return 0;
>>
>> And it's game over.  I can't discern what causes this.  I'm already way
>> in over my pay grade.  :)
>>
>>
>> - Jeff
>>
>>
>> On Mon, Nov 18, 2013 at 6:02 PM, Ovidiu Sas wrote:
>>
>> Can you post the debug logs and let us know which version of opensips
>> are you running?
>> Also, make sure that you set the credentials in AVPs before invoking
>> the b2b call.
>>
>> Thanks,
>> Ovidiu
>>
>> On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle 
>> wrote:
>> > This functionality has become key for my configuration.  I've done some
>> > digging today.  Here's what I know.
>> >
>> > b2b_entities' auth call gets to around line 347 of usr_avp.c and fails:
>> >
>> > if (*crt_avps==0)
>> > return 0;
>> >
>> > Programming is not my strength.  Any thoughts what might cause this
>> > condition, or how it might be related b2b_entities' ability to process
>> an
>> > auth request?
>> >
>> >
>> > - Jeff
>> >
>> >
>> >
>> >
>> > On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle 
>> wrote:
>> >>
>> >> Hi Ovidiu,
>> >>
>> >> It does not.  At least not for me.  Here are some snippets of my config
>> >> file:
>> >>
>> >> modparam("uac_auth","auth_realm_avp",  "$avp(auth_realm)")
>> >> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
>> >> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
>> >>
>> >>
>> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
>> >>
>> >> route {
>> >>
>> >>   ... sanity checks, etc ...
>> >>
>> >> $avp(auth_realm) := "appropriate-realm";
>> >> $avp(auth_user)  := "valid-username";
>> >> $avp(auth_pass)  := "valid-password";
>> >>
>> >> if !(b2b_init_request

Re: [OpenSIPS-Users] AVP-based uac_auth in b2bua

2013-11-18 Thread Ovidiu Sas
Did you set the onreply_avp_mode for tm:
http://www.opensips.org/html/docs/modules/devel/tm.html#id293972


On Monday, November 18, 2013, Jeff Pyle wrote:

> It's 1.10 pulled from git a few hours ago.  Debian 7 64-bit.
>
> The AVPs are set prior to calling the b2b scenario:
>
> modparam("uac_auth","auth_realm_avp",   "$avp(auth_realm)")
> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> #modparam("uac_auth","credential","UserName:AuthRealm123:SuperS33cret")
>
> route {
>   ...
> $avp(auth_user)  := "UserName";
> $avp(auth_pass)  := "SuperS33cret";
> $avp(auth_realm) := "AuthRealm123";
>
> b2b_init_request("top hiding/t105");
> ...
> }
>
>
> debugs:
>
> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback: Received reply
> [407] for dialog [0x7ff941c13268], method [INVITE]
> Nov 18 18:07:55 [26004] DBG:tm:t_unref_cell: UNREF_UNSAFE:
> [0x7ff941c18448] after is 1
> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback:
> dlg=[0x7ff941c13268], uac_tran=NULL
> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
> ="AuthRealm123" state=2
> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
> ="528a9de900013e5f13fe985df4a9848356a1f937207ecfe4" state=3
> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body: ="auth"
> state=1
> Nov 18 18:07:55 [26004] DBG:b2b_logic:b2bl_parse_key: hash_index = [472]
>  - local_index= [0]
>
>
>
> The following (successful) debugs occur if I uncomment the credential
> modparam visible above:
>
> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
> dlg=[0x7f8a06744c30], uac_tran=NULL
> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
> ="66.94.76.24" state=2
> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
> ="528a9fbf00014297ef8f2335679f0310537c85fe2b007186" state=3
> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body: ="auth"
> state=1
> Nov 18 18:15:45 [26118] DBG:uac_auth:build_authorization_hdr: auth_hdr is
>  nonce="528a9fbf00014297ef8f2335679f0310537c85fe2b007186",
> uri="sip:2165551212@domain", qop=auth, nc=0001, cnonce="3105687311",
> response="ef047011046690b6eea99c7848de499a", algorithm=MD5
> >
> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
> [Proxy-Authorization: Digest ...]
> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback: uri [...]
>
>
>
> I tried to follow the source to isolate the failing mechanism.  I arrived
> at modules/uac_auth/auth.c.  In get_avp_credential() at line 199:
>
> avp = search_first_avp( realm_avp_type, realm_avp_name, &val, 0);
> if ( avp==NULL || (avp->flags&AVP_VAL_STR)==0 || val.s.len<=0 )
> return 0;
>
> In my case I've discovered avp==NULL so the if-statement returns 0.
>  avp==NULL because in the search_first_avp() at line 346 of usr_avp.c:
>
> if (*crt_avps==0)
> return 0;
>
> And it's game over.  I can't discern what causes this.  I'm already way in
> over my pay grade.  :)
>
>
> - Jeff
>
>
> On Mon, Nov 18, 2013 at 6:02 PM, Ovidiu Sas  wrote:
>
> Can you post the debug logs and let us know which version of opensips
> are you running?
> Also, make sure that you set the credentials in AVPs before invoking
> the b2b call.
>
> Thanks,
> Ovidiu
>
> On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle 
> wrote:
> > This functionality has become key for my configuration.  I've done some
> > digging today.  Here's what I know.
> >
> > b2b_entities' auth call gets to around line 347 of usr_avp.c and fails:
> >
> > if (*crt_avps==0)
> > return 0;
> >
> > Programming is not my strength.  Any thoughts what might cause this
> > condition, or how it might be related b2b_entities' ability to process an
> > auth request?
> >
> >
> > - Jeff
> >
> >
> >
> >
> > On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle 
> wrote:
> >>
> >> Hi Ovidiu,
> >>
> >> It does not.  At least not for me.  Here are some snippets of my config
> >> file:
> >>
> >> modparam("uac_auth","auth_realm_avp",  "$avp(auth_realm)")
> >> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> >> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> >>
> >>
> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
> >>
> >> route {
> >>
> >>   ... sanity checks, etc ...
> >>
> >> $avp(auth_realm) := "appropriate-realm";
> >> $avp(auth_user)  := "valid-username";
> >> $avp(auth_pass)  := "valid-password";
> >>
> >> if !(b2b_init_request("top hiding/t105")) {
> >> xlog("L_ERR", "** b2b_init  failed - - S=$si:$sp T=$tU
> >> F=$fU C=$ci\n");
> >> send_reply("500", "Internal Server Error");
> >> }
> >> exit;
> >> }
> >>
> >>
> >> Configured like this, the 407 gets passed back to the client.  If I
> >> uncomment the 'credential' modparam, the B2B will send an INVITE with
> the
> >> correct auth.
> >>
> >> The same ua

Re: [OpenSIPS-Users] AVP-based uac_auth in b2bua

2013-11-18 Thread Jeff Pyle
It's 1.10 pulled from git a few hours ago.  Debian 7 64-bit.

The AVPs are set prior to calling the b2b scenario:

modparam("uac_auth","auth_realm_avp",   "$avp(auth_realm)")
modparam("uac_auth","auth_username_avp","$avp(auth_user)")
modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
#modparam("uac_auth","credential","UserName:AuthRealm123:SuperS33cret")

route {
  ...
$avp(auth_user)  := "UserName";
$avp(auth_pass)  := "SuperS33cret";
$avp(auth_realm) := "AuthRealm123";

b2b_init_request("top hiding/t105");
...
}


debugs:

Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback: Received reply [407]
for dialog [0x7ff941c13268], method [INVITE]
Nov 18 18:07:55 [26004] DBG:tm:t_unref_cell: UNREF_UNSAFE: [0x7ff941c18448]
after is 1
Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback:
dlg=[0x7ff941c13268], uac_tran=NULL
Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
="AuthRealm123" state=2
Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:
="528a9de900013e5f13fe985df4a9848356a1f937207ecfe4" state=3
Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body: ="auth"
state=1
Nov 18 18:07:55 [26004] DBG:b2b_logic:b2bl_parse_key: hash_index = [472]  -
local_index= [0]



The following (successful) debugs occur if I uncomment the credential
modparam visible above:

Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
dlg=[0x7f8a06744c30], uac_tran=NULL
Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
="66.94.76.24" state=2
Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:
="528a9fbf00014297ef8f2335679f0310537c85fe2b007186" state=3
Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body: ="auth"
state=1
Nov 18 18:15:45 [26118] DBG:uac_auth:build_authorization_hdr: auth_hdr is

Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:
[Proxy-Authorization: Digest ...]
Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback: uri [...]



I tried to follow the source to isolate the failing mechanism.  I arrived
at modules/uac_auth/auth.c.  In get_avp_credential() at line 199:

avp = search_first_avp( realm_avp_type, realm_avp_name, &val, 0);
if ( avp==NULL || (avp->flags&AVP_VAL_STR)==0 || val.s.len<=0 )
return 0;

In my case I've discovered avp==NULL so the if-statement returns 0.
 avp==NULL because in the search_first_avp() at line 346 of usr_avp.c:

if (*crt_avps==0)
return 0;

And it's game over.  I can't discern what causes this.  I'm already way in
over my pay grade.  :)


- Jeff


On Mon, Nov 18, 2013 at 6:02 PM, Ovidiu Sas  wrote:

> Can you post the debug logs and let us know which version of opensips
> are you running?
> Also, make sure that you set the credentials in AVPs before invoking
> the b2b call.
>
> Thanks,
> Ovidiu
>
> On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle 
> wrote:
> > This functionality has become key for my configuration.  I've done some
> > digging today.  Here's what I know.
> >
> > b2b_entities' auth call gets to around line 347 of usr_avp.c and fails:
> >
> > if (*crt_avps==0)
> > return 0;
> >
> > Programming is not my strength.  Any thoughts what might cause this
> > condition, or how it might be related b2b_entities' ability to process an
> > auth request?
> >
> >
> > - Jeff
> >
> >
> >
> >
> > On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle 
> wrote:
> >>
> >> Hi Ovidiu,
> >>
> >> It does not.  At least not for me.  Here are some snippets of my config
> >> file:
> >>
> >> modparam("uac_auth","auth_realm_avp",  "$avp(auth_realm)")
> >> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> >> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
> >>
> >>
> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
> >>
> >> route {
> >>
> >>   ... sanity checks, etc ...
> >>
> >> $avp(auth_realm) := "appropriate-realm";
> >> $avp(auth_user)  := "valid-username";
> >> $avp(auth_pass)  := "valid-password";
> >>
> >> if !(b2b_init_request("top hiding/t105")) {
> >> xlog("L_ERR", "** b2b_init  failed - - S=$si:$sp T=$tU
> >> F=$fU C=$ci\n");
> >> send_reply("500", "Internal Server Error");
> >> }
> >> exit;
> >> }
> >>
> >>
> >> Configured like this, the 407 gets passed back to the client.  If I
> >> uncomment the 'credential' modparam, the B2B will send an INVITE with
> the
> >> correct auth.
> >>
> >> The same uac_auth config with the same AVPs work correctly if I use
> >> uac_auth() on a failure_route in a pure proxy config.  That's why I'm
> >> confused about it not working with the B2B.  I looked through the
> source and
> >> as best I can tell the same functions are called the same way for each.
> >>
> >> Ok, let me be specific on that last point.  The client to this B2B
> >> instance is another Opensips instance with proxy-only commands, most
> notably
> >> rtpproxy.  That's where I have u

Re: [OpenSIPS-Users] AVP-based uac_auth in b2bua

2013-11-18 Thread Ovidiu Sas
Can you post the debug logs and let us know which version of opensips
are you running?
Also, make sure that you set the credentials in AVPs before invoking
the b2b call.

Thanks,
Ovidiu

On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle  wrote:
> This functionality has become key for my configuration.  I've done some
> digging today.  Here's what I know.
>
> b2b_entities' auth call gets to around line 347 of usr_avp.c and fails:
>
> if (*crt_avps==0)
> return 0;
>
> Programming is not my strength.  Any thoughts what might cause this
> condition, or how it might be related b2b_entities' ability to process an
> auth request?
>
>
> - Jeff
>
>
>
>
> On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle  wrote:
>>
>> Hi Ovidiu,
>>
>> It does not.  At least not for me.  Here are some snippets of my config
>> file:
>>
>> modparam("uac_auth","auth_realm_avp",  "$avp(auth_realm)")
>> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
>> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
>>
>> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
>>
>> route {
>>
>>   ... sanity checks, etc ...
>>
>> $avp(auth_realm) := "appropriate-realm";
>> $avp(auth_user)  := "valid-username";
>> $avp(auth_pass)  := "valid-password";
>>
>> if !(b2b_init_request("top hiding/t105")) {
>> xlog("L_ERR", "** b2b_init  failed - - S=$si:$sp T=$tU
>> F=$fU C=$ci\n");
>> send_reply("500", "Internal Server Error");
>> }
>> exit;
>> }
>>
>>
>> Configured like this, the 407 gets passed back to the client.  If I
>> uncomment the 'credential' modparam, the B2B will send an INVITE with the
>> correct auth.
>>
>> The same uac_auth config with the same AVPs work correctly if I use
>> uac_auth() on a failure_route in a pure proxy config.  That's why I'm
>> confused about it not working with the B2B.  I looked through the source and
>> as best I can tell the same functions are called the same way for each.
>>
>> Ok, let me be specific on that last point.  The client to this B2B
>> instance is another Opensips instance with proxy-only commands, most notably
>> rtpproxy.  That's where I have uac_auth() working today.  With that I call
>> the scenario here as "top hiding/at105" (note the "a") to intentionally pass
>> the 407 back to the proxy config.  It works.  Ideally, I'd prefer the B2B
>> scenario here field the 407.
>>
>>
>> - Jeff
>>
>>
>> On Wed, Nov 13, 2013 at 4:34 PM, Ovidiu Sas  wrote:
>>>
>>> If you set the AVPs before creating the b2b call, it should work on 1.10.
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> On Tue, Nov 12, 2013 at 11:16 PM, Jeff Pyle 
>>> wrote:
>>> > I was about to let this one go when I found "B2B module gets visibility
>>> > to
>>> > credentials defined via AVPs" on the About Version 1.10 page.  In my
>>> > case it
>>> > works only if I define the 'credential' modparam for uac_auth.
>>> >
>>> > The AVPs do work if I use the uac_auth() function in a failure_route
>>> > instead
>>> > of the B2BUA top hiding.
>>> >
>>> > Is there a trick I'm missing?
>>> >
>>> >
>>> >
>>> > - Jeff
>>> >
>>> >
>>> > On Mon, Nov 11, 2013 at 11:09 AM, Jeff Pyle 
>>> > wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> I have uac_auth() working with AVPs in a proxy configuration on v1.10.
>>> >> This is important because I need to choose the authentication username
>>> >> and
>>> >> password based on the usr_preferences of the source IP of the call.
>>> >> Is it
>>> >> possible choose the credentials at call-time (like the AVPs allow) in
>>> >> a B2B
>>> >> top-hiding scenario?
>>> >>
>>> >> The scenario authenticates properly if I statically specify a
>>> >> "credentials" modparam for uac_auth.  It does not work, however, if I
>>> >> set
>>> >> AVPs prior to calling b2b_init_request("top hiding").  Is there
>>> >> another way
>>> >> to approach this?
>>> >>
>>> >>
>>> >> Regards,
>>> >> Jeff
>>> >>
>>> >
>>> >
>>> > ___
>>> > Users mailing list
>>> > Users@lists.opensips.org
>>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>> >
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.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
>



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

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


Re: [OpenSIPS-Users] AVP-based uac_auth in b2bua

2013-11-18 Thread Jeff Pyle
This functionality has become key for my configuration.  I've done some
digging today.  Here's what I know.

b2b_entities' auth call gets to around line 347 of usr_avp.c and fails:

if (*crt_avps==0)
return 0;

Programming is not my strength.  Any thoughts what might cause this
condition, or how it might be related b2b_entities' ability to process an
auth request?


- Jeff




On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle  wrote:

> Hi Ovidiu,
>
> It does not.  At least not for me.  Here are some snippets of my config
> file:
>
> modparam("uac_auth","auth_realm_avp",  "$avp(auth_realm)")
> modparam("uac_auth","auth_username_avp","$avp(auth_user)")
> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")
>
> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")
>
> route {
>
>   ... sanity checks, etc ...
>
> $avp(auth_realm) := "appropriate-realm";
> $avp(auth_user)  := "valid-username";
> $avp(auth_pass)  := "valid-password";
>
> if !(b2b_init_request("top hiding/t105")) {
> xlog("L_ERR", "** b2b_init  failed - - S=$si:$sp T=$tU
> F=$fU C=$ci\n");
> send_reply("500", "Internal Server Error");
> }
> exit;
> }
>
>
> Configured like this, the 407 gets passed back to the client.  If I
> uncomment the 'credential' modparam, the B2B will send an INVITE with the
> correct auth.
>
> The same uac_auth config with the same AVPs work correctly if I use
> uac_auth() on a failure_route in a pure proxy config.  That's why I'm
> confused about it not working with the B2B.  I looked through the source
> and as best I can tell the same functions are called the same way for each.
>
> Ok, let me be specific on that last point.  The client to this B2B
> instance is another Opensips instance with proxy-only commands, most
> notably rtpproxy.  That's where I have uac_auth() working today.  With that
> I call the scenario here as "top hiding/at105" (note the "a") to
> intentionally pass the 407 back to the proxy config.  It works.  Ideally,
> I'd prefer the B2B scenario here field the 407.
>
>
> - Jeff
>
>
> On Wed, Nov 13, 2013 at 4:34 PM, Ovidiu Sas  wrote:
>
>> If you set the AVPs before creating the b2b call, it should work on 1.10.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Tue, Nov 12, 2013 at 11:16 PM, Jeff Pyle 
>> wrote:
>> > I was about to let this one go when I found "B2B module gets visibility
>> to
>> > credentials defined via AVPs" on the About Version 1.10 page.  In my
>> case it
>> > works only if I define the 'credential' modparam for uac_auth.
>> >
>> > The AVPs do work if I use the uac_auth() function in a failure_route
>> instead
>> > of the B2BUA top hiding.
>> >
>> > Is there a trick I'm missing?
>> >
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Mon, Nov 11, 2013 at 11:09 AM, Jeff Pyle 
>> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I have uac_auth() working with AVPs in a proxy configuration on v1.10.
>> >> This is important because I need to choose the authentication username
>> and
>> >> password based on the usr_preferences of the source IP of the call.
>>  Is it
>> >> possible choose the credentials at call-time (like the AVPs allow) in
>> a B2B
>> >> top-hiding scenario?
>> >>
>> >> The scenario authenticates properly if I statically specify a
>> >> "credentials" modparam for uac_auth.  It does not work, however, if I
>> set
>> >> AVPs prior to calling b2b_init_request("top hiding").  Is there
>> another way
>> >> to approach this?
>> >>
>> >>
>> >> Regards,
>> >> Jeff
>> >>
>> >
>> >
>> > ___
>> > Users mailing list
>> > Users@lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.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] opensips shutdown leaves some processes

2013-11-18 Thread Jeff Pyle
Hi Bogdan,

You're right, localhost doesn't seem to have anything to do with it.  In
fact, I can't reproduce this problem anymore.  One difference is now I'm
using DBG_QM_MALLOC instead of F_MALLOC to troubleshoot the other memory
issue.

Now, instead of leaving processes running after shutdown, it crashes
outright:
  CRITICAL:core:qm_free: freeing already freed pointer, first free:
t_reply.c: free_faked_req(580) - aborting

This happens only if I use the uac_auth() function.  I ran it again to get
a memlog and it failed like this:
  CRITICAL:core:qm_free: freeing already freed pointer, first free: auth.c:
uac_auth(187) - aborting

This is probably the same problem as bug 126.  Memlog and bt available here:
  http://storageb.fidelityvoice.net/~jpyle/signal6.zip


- Jeff



On Mon, Nov 18, 2013 at 4:59 AM, Bogdan-Andrei Iancu wrote:

>  Hi Jeff,
>
> the LO interface issue is really strange - I cannot imagine a relation
> between the LO interface and the shutdown interfaceattaching with gdb
> to a running process is as simple as accessing a core file "gdb bin_file
> pid"
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 11/14/2013 04:36 PM, Jeff Pyle wrote:
>
> Hi Bogdan,
>
>  I had not, that's a new concept for me.  I'll see what I can do.
>  Changing from localhost to LAN IPs did solve the problem of processes not
> shutting down properly, however.  Just the already freed memory 
> crashremains.
>
>
>  - Jeff
>
>
>
> On Thu, Nov 14, 2013 at 5:29 AM, Bogdan-Andrei Iancu 
> wrote:
>
>>  Hi Jeff,
>>
>> Have you tried to attach with gdb to the remaining process and to get a
>> backtrace ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>> On 11/12/2013 06:03 AM, Jeff Pyle wrote:
>>
>>Hello,
>>
>>  In one particular configuration on 1.10 a standard Opensips shutdown
>> isn't ending all the processes...if calls have passed through the system.
>>  If no calls have passed, everything shuts down fine.
>>
>>  At one particular moment in time with everything running I have:
>>
>>  Process::  ID=0 PID=26283 Type=attendant
>> Process::  ID=1 PID=26284 Type=MI XMLRPC
>> Process::  ID=2 PID=26285 Type=MI FIFO
>> Process::  ID=3 PID=26286 Type=RTPP timeout receiver
>> Process::  ID=4 PID=26287 Type=SIP receiver udp:127.0.0.1:5002
>> Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
>> Process::  ID=6 PID=26289 Type=time_keeper
>> Process::  ID=7 PID=26290 Type=timer
>>
>>  But after /etc/init.d/opensips stop, it's always the attendant (26283)
>> and the second SIP receiver (26288) hanging around.  It requires a kill -9
>> to get them to go away.
>>
>>  A full debug isn't showing anything obvious:
>>
>>  Nov 11 22:51:29 [26283] DBG:core:handle_sigs: SIGTERM received, program
>> terminates
>> Nov 11 22:51:29 [26289] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26288] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26290] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26287] INFO:core:sig_usr: signal 15 received
>>  Nov 11 22:51:29 [26286] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26285] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26284] INFO:core:sig_usr: signal 15 received
>>
>>  But not everything has terminated:
>>
>>  # ps ax | grep opensips
>> 26283 ?S< 0:00 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
>> opensips -g opensips
>> 26288 ?R< 0:21 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8 -M 1 -u
>> opensips -g opensips
>>
>>  Any suggestions on where to continue investigating?
>>
>>
>>  - Jeff
>>
>>
>>
>>
>> ___
>> 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] Get IP/Port of registered user (or from Location table?)

2013-11-18 Thread bluerain
So anyhow, I probabaly better off to go with "IF" statement then "switch" in
this type of scenario,huh...



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Get-IP-Port-of-registered-user-or-from-Location-table-tp7588494p7588563.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] Get IP/Port of registered user (or from Location table?)

2013-11-18 Thread bluerain
Really?!  So the "exit" statement I put does not EXIT from the entire script? 
Then what does "exit" do?  Hey by the way, thanks again for taking the time
answering my question.

And if it go next block, the return code should been "-1" why it would
execute in code block in "-3" or "-2"?  



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Get-IP-Port-of-registered-user-or-from-Location-table-tp7588494p7588562.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] Dialplan dp_translate error

2013-11-18 Thread Liviu Chircu

Hello again,

On second thoughts, I can tell you're running a post 1.9 version of 
OpenSIPS. Now in debug mode you should see all the rules being dumped in 
the logs with every "reload" operation, either at startup or through MI.


Could you check if the DPID: 3 rules actually appear listed in that very 
verbose dump?


Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 11/18/2013 01:54 PM, Alexander Mustafin wrote:

Hi.

I'm using some translation rules for various purposes.
I've got dial plan rule with dpid=3, but when I try to do 
dp_translate(«3»...) - I see next message in the log:


Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_get_ivalue: searching 4
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_translate_f: dpid is 3
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_get_svalue: searching 19
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_translate_f: input is 1001%23777
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_translate_f: no information available for dpid 3


Rule in database:
3301^\d{3,6}\%23\d*$0^\d{3,6}\%23\d*$\20

I was tried dp_reload and restart server - but unsuccessfully. If I 
use same rule with dpid=1 - all works fine ((


Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.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] Dialplan dp_translate error

2013-11-18 Thread Liviu Chircu

Hello Alexander,

Are you using a pre or post 1.9 version of OpenSIPS?

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 11/18/2013 01:54 PM, Alexander Mustafin wrote:

Hi.

I'm using some translation rules for various purposes.
I've got dial plan rule with dpid=3, but when I try to do 
dp_translate(«3»...) - I see next message in the log:


Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_get_ivalue: searching 4
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_translate_f: dpid is 3
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_get_svalue: searching 19
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_translate_f: input is 1001%23777
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: 
DBG:dialplan:dp_translate_f: no information available for dpid 3


Rule in database:
3301^\d{3,6}\%23\d*$0^\d{3,6}\%23\d*$\20

I was tried dp_reload and restart server - but unsuccessfully. If I 
use same rule with dpid=1 - all works fine ((


Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.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


[OpenSIPS-Users] Dialplan dp_translate error

2013-11-18 Thread Alexander Mustafin
Hi.

I’m using some translation rules for various purposes.
I’ve got dial plan rule with dpid=3, but when I try to do dp_translate(«3»…) - 
I see next message in the log:

Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_get_ivalue: 
searching 4
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_translate_f: 
dpid is 3
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_get_svalue: 
searching 19
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_translate_f: 
input is 1001%23777
Nov 18 11:38:28 ops /usr/sbin/opensips[31844]: DBG:dialplan:dp_translate_f: no 
information available for dpid 3

Rule in database:
3   3   0   1   ^\d{3,6}\%23\d*$0   
^\d{3,6}\%23\d*$\2  0   

I was tried dp_reload and restart server - but unsuccessfully. If I use same 
rule with dpid=1 - all works fine ((

Best regards,
Alexander Mustafin
mustafin.aleksa...@gmail.com




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


Re: [OpenSIPS-Users] OpenSIPS not processing responses?

2013-11-18 Thread Muhammad Shahzad Shafi
 

Ah so, this makes sense. I guess you just need to adjust and fine
tune some TCP parameters, take a look at
this,

www.opensips.org/Documentation/Script-CoreParameters-1-8#toc75
[2] Important flags to optimize are,


tcp_connect_timeout
tcp_send_timeout tcp_no_new_conn_flag
tcp_keep

Also as you mentioned, the IP in error message is
different and unreachable, which leads me to question, which node is
handing NAT? i guess it would be opensips (since it seems to be edge
proxy in your setup, comparable to P-CSCF in IMS), so you need to make
sure you handle the NAT correctly on it (with NAT keepalive etc.
setup).

Thank you. 

On 2013-11-15 14:59, Gavin Murphy wrote: 

> Yes,
we are bridging between TCP and UDP. There are no custom scripts being
used, just the core OpenSIPS scripting, with OpenSIPS acting just as a
proxy. We had another event occur last evening and managed to capture
some interesting information that suggests the problem is related to
blocking tcp connections:
> 
> aaa@ip-10-72-7-129:/dir$ grep
"ERROR:core:tcp_blocking_connect: timeout 10 s elapsed from 10 s"
opensips.log | sed 's/:.. ip.*//'| uniq -c
> 2 Nov 14 06:50
> 2 Nov 14
06:53
> 2 Nov 14 06:55
> 1 Nov 14 06:56
> 2 Nov 14 06:57
> 2 Nov 14
07:00
> 
> 2 Nov 14 13:53
> 3 Nov 14 13:54
> 2 Nov 14 13:55
> 23 Nov
14 13:56
> 29 Nov 14 13:57
> 30 Nov 14 13:58
> 30 Nov 14 13:59
> 
>
While I'm not familiar with the inner workings of OpenSIPS, it seems
like there is something happening that may be causing all of the child
processes to block while trying to establish outbound TCP connections.
Unfortunately the "tcp_blocking_connect: timeout" error (and the
subsequent "tcp_blocking_connect failed" error) doesn't indicate the
address that caused the failure, and there's no way that I can see to
correlate the error back to a request being processed. But I suspect
it's a case where a client connected via TCP, registered with our
registrar (where the path to the client, including the address of the
TCP connection endpoint on OpenSIPS that has an ephemeral port, is
recorded), but when we go to send a bunch of requests to that client it
is no longer there and it causes all of the opensips child processes to
effectively block trying to establish a connection to an address it will
never be able to connect to. In the end 477 Send Failed is returned in
those cases, but I think the child trying to establish the connection is
blocked until the connect times out, and things start piling up behind
it, leading to a vicious circle.
> 
> Assuming all of the analysis is
correct, can we prevent OpenSIPS from spending time trying to establish
a connection that can never be established?
> 
> Thanks,
> 
> Gavin
> 
>
On 15/11/2013 7:00 AM, users-requ...@lists.opensips.org [1] wrote: 
>

>> Seems opensips is acting as transport bridge between udp and tcp,
so, 
>> do the SIP replies actually arrive at same interface (transport
+ ip + 
>> port) from where the request was sent, and opensips is
listening to that 
>> interface? Can you share SIP trace with us?
>> 
>>
Also, are you using any custom application, e.g. perl / lua script etc.

>> in opensips dial plan, that might be blocking the opensips thread
that 
>> is managing this transaction. As far as i remember opensips
1.8.x does 
>> not have async processing, therefore, if any script or
module command 
>> that consumes time e.g. custom sql query, external
script or shell 
>> command etc. would block opensips and any responses
received during that 
>> time are likely to be ignored.
>> 
>> Thank
you.
>> 
>> On 2013-11-14 16:05, Gavin Murphy wrote:
>> 
>>> Hi all,
>>>

>>> We're seeing a possible issue in OpenSIPS related to the timely
>>>
processing of replies. For example, OpenSIPS receives a REGISTER and
>>>
passes it on to our application server (which is the registrar). The
>>>
registrar receives it within the same second and generates the
>>>
response (a 401 initially) within 0.003 seconds. However OpenSIPS
>>>
doesn't appear to receive that message, and half a second after the
>>>
first REGISTER is sent, there is a retransmission after 0.5 second,
>>>
which is again received by our registrar and a response is generated
>>>
very quickly. But still the 401 doesn't get received and/or
processed
>>> by OpenSIPS. The retransmission happens again a few times
as per RFC
>>> 3261. Eventually, almost 30 seconds later OpenSIPS logs
that the 
>>> reply
>>> to the REGISTER has been received.
>>> 
>>>
Based on the evidence it seems that there is no problem with
OpenSIPS
>>> sending the request and it being received by our registrar.
There 
>>> also
>>> doesn't appear to be any issues with the
retransmission by OpenSIPS 
>>> at
>>> the right intervals, nor does the
registrar appear to be introducing
>>> any delays. There is not much
other traffic going on at the same 
>>> time,
>>> but there are other
REGISTERs that are getting the same result.
>>> 
>>> Here are some logs
from OpenSIPS:
>>> Initial relay to our registrar:

Re: [OpenSIPS-Users] Problem with Opensips-cp CDR And Users registration

2013-11-18 Thread Vishnu Vardhan
Hi,

Thanks for response i loaded that modules and i again i am facing same
problem.And users online status is not showing and and users are not
registering in Softphone.And i configured opensips and asterisk in the same
server.

Log message.

Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
NOTICE:core:main: version: opensips 1.8.3-notls (x86_64/linux)
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:core:main: using 32 Mb shared memory
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:core:main: using 2 Mb private memory per process
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
NOTICE:signaling:mod_init: initializing module ...
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:sl:mod_init: Initializing StateLess engine
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:tm:mod_init: TM - initializing...
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:rr:mod_init: rr - initializing
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:maxfwd:mod_init: initializing...
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:sipmsgops:mod_init: initializing...
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:usrloc:ul_init_locks: locks array size 512
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:registrar:mod_init: initializing...
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:acc:mod_init: initializing...
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12310]:
INFO:core:probe_max_sock_buff: using rcv buffer of 448 kb
Nov 18 06:06:13 developer-asterisk-vm24 opensips: INFO:core:daemonize:
pre-daemon process exiting with 0
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12317]:
INFO:core:sig_usr: signal 13 received
Nov 18 06:06:13 developer-asterisk-vm24 /usr/local/sbin/opensips[12317]:
ERROR:core:start_timer_processes: failed to send status code

Regards,
Vishnu





On Fri, Nov 15, 2013 at 6:59 PM, Vishnu Vardhan wrote:

> Hi,
>
> I installed opensips 1.8 with opensips 5.0.And i integrate with it
> asterisk 11.0.3.When i tried to register the users it is not updating
> in cdr-viewer and in softphone also users are not registering after
> registering in users pannel.Can any one help he to get out of this
> problem.And pls see the below log message of opensips which i got.
>
> Nov 15 05:00:27 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> sip_trace is not available
>
> Nov 15 05:01:03 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> dr_gw_status is not available
>
> Nov 15 05:01:30 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> dlg_list is not available
>
> Nov 15 05:09:37 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> sip_trace is not available
>
> Nov 15 05:09:58 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> dr_gw_status is not available
>
> Nov 15 05:10:02 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> dlg_list is not available
>
> Nov 15 06:08:45 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> domain_reload is not available
>
> Nov 15 06:12:23 developer-asterisk-vm24
> /usr/local/sbin/opensips[3373]: ERROR:mi_fifo:mi_fifo_server: command
> domain_reload is not available
>
> Regards,
> Vishnu
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Opensips 1.10 and embedded ARM system

2013-11-18 Thread Samuel Muller
Hello Ovidiu,

Thanks for your help.
I tried to run OpenSips without the dispatcher module, it's working
fine (I mean, no crash yet ...).
Later this week I will have more info, I've to investigate based on
your advices.

Have a nice day,

Samuel MULLER


--

Message: 3
Date: Thu, 14 Nov 2013 11:20:18 -0500
From: Ovidiu Sas 
Subject: Re: [OpenSIPS-Users] Opensips 1.10 and embedded ARM system
To: OpenSIPS users mailling list 
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

Hello Samuel,

OpenSIPS is already built for a handfull of embedded devices via the
optware feeds:
http://www.nslu2-linux.org/

If you want to take a look at the master makefile for cross compiling
opensips, you can find it here:
http://svn.nslu2-linux.org/svnroot/optware/trunk/make/opensips.mk

I ran opensips on arm without any issue, so it might be that your
build is not sane.
Generate a core file and use gdb to investigate.

Regards,
Ovidiu Sas

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


Re: [OpenSIPS-Users] opensips shutdown leaves some processes

2013-11-18 Thread Bogdan-Andrei Iancu
Hi Jeff,

the LO interface issue is really strange - I cannot imagine a relation
between the LO interface and the shutdown interfaceattaching with
gdb to a running process is as simple as accessing a core file "gdb
bin_file pid"

Regards,

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


On 11/14/2013 04:36 PM, Jeff Pyle wrote:
> Hi Bogdan,
>
> I had not, that's a new concept for me.  I'll see what I can do.
>  Changing from localhost to LAN IPs did solve the problem of processes
> not shutting down properly, however.  Just the already freed memory
> crash  remains.
>
>
> - Jeff
>
>
>
> On Thu, Nov 14, 2013 at 5:29 AM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hi Jeff,
>
> Have you tried to attach with gdb to the remaining process and to
> get a backtrace ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 11/12/2013 06:03 AM, Jeff Pyle wrote:
>> Hello,
>>
>> In one particular configuration on 1.10 a standard Opensips
>> shutdown isn't ending all the processes...if calls have passed
>> through the system.  If no calls have passed, everything shuts
>> down fine.
>>
>> At one particular moment in time with everything running I have:
>>
>> Process::  ID=0 PID=26283 Type=attendant
>> Process::  ID=1 PID=26284 Type=MI XMLRPC
>> Process::  ID=2 PID=26285 Type=MI FIFO
>> Process::  ID=3 PID=26286 Type=RTPP timeout receiver
>> Process::  ID=4 PID=26287 Type=SIP receiver udp:127.0.0.1:5002
>>  
>> Process::  ID=5 PID=26288 Type=SIP receiver udp:127.0.0.1:5002
>>  
>> Process::  ID=6 PID=26289 Type=time_keeper
>> Process::  ID=7 PID=26290 Type=timer
>>
>> But after /etc/init.d/opensips stop, it's always the attendant
>> (26283) and the second SIP receiver (26288) hanging around.  It
>> requires a kill -9 to get them to go away.
>>
>> A full debug isn't showing anything obvious:
>>
>> Nov 11 22:51:29 [26283] DBG:core:handle_sigs: SIGTERM received,
>> program terminates
>> Nov 11 22:51:29 [26289] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26288] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26290] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26287] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26286] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26285] INFO:core:sig_usr: signal 15 received
>> Nov 11 22:51:29 [26284] INFO:core:sig_usr: signal 15 received
>>
>> But not everything has terminated:
>>
>> # ps ax | grep opensips
>> 26283 ?S< 0:00 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8
>> -M 1 -u opensips -g opensips
>> 26288 ?R< 0:21 /usr/sbin/opensips -f
>> /etc/opensips/opensips.cfg -P /var/run/opensips/opensips.pid -m 8
>> -M 1 -u opensips -g opensips
>>
>> Any suggestions on where to continue investigating?
>>
>>
>> - Jeff
>>
>>
>>
>>
>> ___
>> 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.9.1 stopped writing into log

2013-11-18 Thread Bogdan-Andrei Iancu
Hello Yuri,

Perfect !

Regards,

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


On 11/14/2013 04:15 PM, Yuri Ritvin wrote:
> Thank you, Bogdan.
> You are absolutely right. OpenSIPS is OK.
> I made an "investigation" and found a culprit - an rsyslog.conf got
> corrupted from an automated action taken by Puppet ...
> I restored the rsyslog.conf from a backup and the log normal operation
> has been resumed.
>
> Thanks a lot !
> Yuri
>
>
> On Thu, Nov 14, 2013 at 5:16 AM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hello Yuri,
>
> It may be a syslog problem IMHO. What you can do is to set
> "log_stderror = yes" in your cfg - this will make opensips to
> write to console instead of syslog. If you see the logs, it means
> there is no problem with opensips, but rather with syslog.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 11/11/2013 01:37 AM, Yuri Ritvin wrote:
>> I have installed Opensips 1.9.1 which works fine, but recently it
>> stopped writing into the opensips.log file - just in the middle.
>> Enough space, memory, CPU resources. Something triggered this issue.
>> I tried to revive logging by restarting rsyslog and opensips
>> processes, but it doesn't help. Reboot didn't change this
>> phenomenon too.
>> Any ideas / hints on this subject   ?
>>
>> Thank you,
>> Yuri
>>
>>
>> ___
>> 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] Regd Load Balancer Algorithms

2013-11-18 Thread Bogdan-Andrei Iancu
Hello Santosh,

You cannot use 2 algorithms in the same time - like weight based and
round robin. You need to choose the one which better fits your needs.
Dispatcher module provides both algs (round robin in 4, all other hash
based algs are subject to weight balancing).

Regards,

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


On 11/14/2013 07:13 PM, santosh satapathy wrote:
> Thanks for input Bogdan. I would like to add weight dynamically to
> destinations based on their health (resource capability and not solely
> based on their status as Active from options probing) so that number
> of calls on each destination also is controlled on their resource
> capability and as well distributed in a round robin manner.
>
> Is there any provision to configure load balancer with both the
> options (weighted, round robin) etc. in the configuration file to
> achieve the scenario mentioned in before.
>
> Appreciate if you could assist me with any solution or similar. 
>
> Thanks
> Santosh
>
>
> On Thu, Nov 14, 2013 at 2:26 AM, Bogdan-Andrei Iancu
> mailto:bog...@opensips.org>> wrote:
>
> Hello Santosh,
>
> The Load Balancing module does routing only based on the load of
> the destination (how many calls are ongoing on each destination).
>
> You can look also at the dDispatcher module, where you have
> multiple algorithm for distributing calls. See :
>
> http://www.opensips.org/html/docs/modules/1.10.x/dispatcher.html#id294038
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
>
> On 11/12/2013 05:24 AM, santosh satapathy wrote:
>> Hi,
>>
>> I am new to this mailing list and evaluating various options for
>> a good load balancer. Can somebody help let me know if we can
>> choose two algorithms (Ex: weighted and round robin) together for
>> load balancing.
>>
>> -- 
>> Thanks
>>
>> Santosh
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org 
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> -- 
> Thanks
>
> Santosh
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Get IP/Port of registered user (or from Location table?)

2013-11-18 Thread Liviu Chircu

Hello bluerain,

Everything you said makes perfect sense and, surprisingly, it is (and 
should be) the expected behaviour, given that exact piece of code.


In a *switch *statement, the default behaviour is to go to the *next 
block* if a block does not end with the *break* keyword. It is normal 
for that script to perform exactly 4 lookups.


Your code now becomes:

"

case -1:
$var(aor)="sip:FRANK101@22.22.22.22:5062";
if(!lookup("location","","$var(aor)")) {
t_reply("404","Not Found new $rc");
exit;
}
break;

case -3:
#$var(aor)="sip:FRANK101@22.22.22.22:5062";
#if(!lookup("location","","$var(aor)")) {
t_newtran();
t_reply("404","Not Found");
exit;
#}
break;

...

"

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 11/18/2013 03:14 AM, bluerain wrote:

Hello Liviu,

thanks for your help again!  Ok, so I tried that and is weird, is kinda
working but is working weirdly.  Not sure, maybe I don't truely understand
how opensips works?  But here is my code:

if (is_method("INVITE")) {

trace_dialog();

if (!lookup("location","m")){
switch($rc)
{
case -1:

$var(aor)="sip:FRANK101@22.22.22.22:5062";

if(!lookup("location","","$var(aor)")) {
t_reply("404","Not Found new 
$rc");
exit;
}
case -3:

#$var(aor)="sip:FRANK101@22.22.22.22:5062";

#if(!lookup("location","","$var(aor)")) {
t_newtran();
t_reply("404","Not 
Found");
exit;
#}
case -2:

#$var(aor)="sip:FRANK101@22.22.22.22:5062";

#if(!lookup("location","","$var(aor)")) {
sl_send_reply("405", "Method 
Not Allowed");
exit;
#}
}
}

route(relay);
}

So if I use the code above, it would reply "404","Not Found" which means the
lookup() function returned "-3"

And then if I unquote the all the "#" in "-3" section", since that is where
the error happend, now when I sent the INVITE, it would return "405 Method
Not Allowed", which means now lookup() function returned "-2"

So lastly if I unquote the "#"in "-2", the call actually worked!  But it
seems the code must got iterated 3 times before it reach the "method not
found" section and thus finally sent the call out?

So what I mean is that if I sent an "unknown" user in the INVITE, from the
code above, it will jump to "-1" section (because it return error code -1)
and then when it execute again the lookup() in the "-1" section, it jump to
-3 and then execute lookup() again in "-3" and then finally it jump to "-2"
to execute the finally lookup.  Why?

Shouldn't it simply jump to "-1" and then do the lookup("frank101") which IS
IN THE LOCATION table and then proceed with jumping to the route(relay) and
FRANK101 phone should ring, no?

but instead it seems it looped back into the "invite" and then do the lookup
again with blah errors, until it finally reach the finally possibility of
"-2", then call works... weird, why?

Thank you!




--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Get-IP-Port-of-registered-user-or-from-Location-table-tp7588494p7588550.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