Re: [SR-Users] DRouting, routeid is not triggered
Hi Daniel, It works... thanks alot for your help. Mac. 2014-04-25 0:48 GMT+02:00 Maciej Bylica mb...@gazeta.pl: Hi Daniel, I am about to do this on Fri and will give you feedback soon. Thanks Mac. Can you try the patch from commit: - http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c3386295d7607a58d37a65b6822bf5f98b3fefa0 If you are using git, do a git pull, then you can pick the commit in your branch (if you are not on master): git cherry-pick -x c3386295d7607a58d37a65b6822bf5f98b3fefa0 Cheers, Daniel On 24/04/14 17:16, Daniel-Constantin Mierla wrote: Hello, busy with the release I didn't have time to troubleshoot more yet. Cheers, Daniel On 24/04/14 17:10, Maciej Bylica wrote: Hello Do you need any other data to verify? Thanks. 2014-04-23 12:11 GMT+02:00 Maciej Bylica mb...@gazeta.pl: Hi Daniel, Here is debug you requested. DEBUG: core [parser/msg_parser.c:623]: parse_msg(): SIP Request: DEBUG: core [parser/msg_parser.c:625]: parse_msg(): ámethod: áINVITE DEBUG: core [parser/msg_parser.c:627]: parse_msg(): áuri: á á sip:43111223344@10.10.10.5 DEBUG: core [parser/msg_parser.c:629]: parse_msg(): áversion: SIP/2.0 DEBUG: core [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, rport = n/a; state=6 DEBUG: core [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, branch = z9hG4bKZZDHrKg1B4Q1c; state=16 DEBUG: core [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 DEBUG: core [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 DEBUG: core [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via DEBUG: core [receive.c:152]: receive_msg(): After parse_msg... DEBUG: core [receive.c:193]: receive_msg(): preparing to run routing scripts... DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 69 DEBUG: maxfwd [maxfwd.c:161]: process_maxfwd_header(): value 69 decreased to 16 DEBUG: core [parser/parse_addr_spec.c:893]: parse_addr_spec(): end of header reached, state=10 DEBUG: core [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: To [32]; uri=[sip:43111223344@10.10.10.5] DEBUG: core [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [sip:43111223344@10.10.10.5#015#012] DEBUG: core [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq CSeq: 58787375 INVITE DEBUG: core [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=203 DEBUG: core [parser/msg_parser.c:106]: get_hdr_field(): found end of header DEBUG: core [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=1eQFK719e4cyS DEBUG: core [parser/parse_addr_spec.c:893]: parse_addr_spec(): end of header reached, state=29 DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 DEBUG: siputils [checks.c:103]: has_totag(): no ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] DRouting, routeid is not triggered
Hello Do you need any other data to verify? Thanks. 2014-04-23 12:11 GMT+02:00 Maciej Bylica mb...@gazeta.pl: Hi Daniel, Here is debug you requested. DEBUG: core [parser/msg_parser.c:623]: parse_msg(): SIP Request: DEBUG: core [parser/msg_parser.c:625]: parse_msg(): method: INVITE DEBUG: core [parser/msg_parser.c:627]: parse_msg(): uri: sip:43111223344@10.10.10.5 DEBUG: core [parser/msg_parser.c:629]: parse_msg(): version: SIP/2.0 DEBUG: core [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, rport = n/a; state=6 DEBUG: core [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, branch = z9hG4bKZZDHrKg1B4Q1c; state=16 DEBUG: core [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 DEBUG: core [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 DEBUG: core [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via DEBUG: core [receive.c:152]: receive_msg(): After parse_msg... DEBUG: core [receive.c:193]: receive_msg(): preparing to run routing scripts... DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 69 DEBUG: maxfwd [maxfwd.c:161]: process_maxfwd_header(): value 69 decreased to 16 DEBUG: core [parser/parse_addr_spec.c:893]: parse_addr_spec(): end of header reached, state=10 DEBUG: core [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: To [32]; uri=[sip:43111223344@10.10.10.5] DEBUG: core [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [ sip:43111223344@10.10.10.5#015#012] DEBUG: core [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq CSeq: 58787375 INVITE DEBUG: core [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=203 DEBUG: core [parser/msg_parser.c:106]: get_hdr_field(): found end of header DEBUG: core [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=1eQFK719e4cyS DEBUG: core [parser/parse_addr_spec.c:893]: parse_addr_spec(): end of header reached, state=29 DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 DEBUG: siputils [checks.c:103]: has_totag(): no totag DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=0 T start=0x DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=49678, isACK=0 DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=1 global id=1 T end=(nil) DEBUG: core [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 12==9 [10.10.10.5] == [127.0.0.1] DEBUG: core [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 DEBUG: core [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 12==12 [10.10.10.5] == [10.10.10.5] DEBUG: core [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 DEBUG: registrar [lookup.c:158]: lookup(): '43111223344' Not found in usrloc DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , global msg id=1 , T on entrance=(nil) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=49678, isACK=0 DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found DEBUG: tm [t_hooks.c:374]: run_reqin_callbacks_internal(): DBG: trans=0x7f9ae79e2c10, callback type 1, id 0 entered DEBUG: tm [t_hooks.c:374]: run_reqin_callbacks_internal(): DBG: trans=0x7f9ae79e2c10, callback type 1, id 0 entered DEBUG: core [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: 60b78f5b572d3477887c1e8305c94b0a DEBUG: drouting [drouting.c:720]: do_routing(): using dr group 10 DEBUG: drouting [prefix_tree.c:87]: internal_check_rt(): found rgid 10 (rule list 0x7f9ae79e2a58) DEBUG: drouting [drouting.c:895]: do_routing(): setting attr [] as for ruri DEBUG: drouting [drouting.c:912]: do_routing(): setting the gw [0] as ruri sip:43111223344@10.10.10.9 DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , global msg id=1 , T on entrance=0x7f9ae79e2c10 DEBUG: tm [t_lookup.c:1378]: t_newtran(): DEBUG: t_newtran: transaction already in process 0x7f9ae79e2c10 DEBUG: tm [t_funcs.c:347]: t_relay_to(): SER: new INVITE DEBUG: core [msg_translator.c:204]: check_via_address(): check_via_address(10.10.5.5, 10.10.5.5, 0) DEBUG: core [mem/shm_mem.c:111]: _shm_resize(): WARNING:vqm_resize: resize(0) called DEBUG: tm [t_reply.c:728]: _reply_light(): DEBUG: reply sent out. buf=0x7f9afe08a608: SIP/2.0 100 trying -..., shmem=0x7f9ae79e5860: SIP/2.0 100 trying
Re: [SR-Users] DRouting, routeid is not triggered
:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: rr [loose.c:113]: find_first_route(): No Route headers found
DEBUG: core [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)
DEBUG: rr [loose.c:929]: loose_route(): There is no Route HF
DEBUG: core [receive.c:296]: receive_msg(): receive_msg: cleaning up
DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=1
global id=0 T start=0x
DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start
searching: hash=49678, isACK=1
DEBUG: tm [t_lookup.c:470]: matching_3261(): DEBUG: RFC3261 transaction
matched, tid=ZZDHrKg1B4Q1c
DEBUG: tm [t_lookup.c:726]: t_lookup_request(): DEBUG: t_lookup_request:
transaction found (T=0x7f9ae79e2c10)
DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=1
global id=1 T end=0x7f9ae79e2c10
DEBUG: tm [t_reply.c:1663]: cleanup_uac_timers(): DEBUG:
cleanup_uac_timers: RETR/FR timers reset
DEBUG: core [timer.c:595]: timer_add_safe(): timer_add called on an
active timer 0x7f9ae79e2c90 (0x7f9ae778eb18, 0x7f9ae778eb18), flags 201
DEBUG: tm [t_funcs.c:180]: put_on_wait(): tm: put_on_wait: transaction
0x7f9ae79e2c10 already on wait
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [usr_avp.c:644]: destroy_avp_list(): DEBUG:destroy_avp_list:
destroying list (nil)
DEBUG: core [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil)
DEBUG: core [receive.c:296]: receive_msg(): receive_msg: cleaning up
and call flow:
0.00 10.10.5.5 - 10.10.10.5 SIP/SDP 1100 Request: INVITE
sip:43111223344@10.10.10.5 | , with session description
0.002140 10.10.10.5 - 10.10.5.5 SIP 377 Status: 100 trying -- your call
is important to us |
0.002264 10.10.10.5 - 10.10.10.9 SIP/SDP 1250 Request: INVITE
sip:43111223344@10.10.10.9 | , with session description
0.002836 10.10.10.9 - 10.10.10.5 SIP 442 Status: 100 Trying |
0.370466 10.10.10.9 - 10.10.10.5 SIP 565 Status: 503 Service unavailable
|
0.370858 10.10.10.5 - 10.10.10.9 SIP 379 Request: ACK
sip:43111223344@10.10.10.9 |
0.370969 10.10.10.5 - 10.10.5.5 SIP 400 Status: 500 Service Unavailable
|
0.371441 10.10.5.5 - 10.10.10.5 SIP 404 Request: ACK
sip:43111223344@10.10.10.5 |
Thanks
Mac
2014-04-22 19:51 GMT+02:00 Daniel-Constantin Mierla mico...@gmail.com:
Hello,
can you set debug=3 in kamailio.cfg and then send the syslog messages for
routing a call matching the drouting rule?
Cheers,
Daniel
On 22/04/14 19:12, Maciej Bylica wrote:
Hello,
I am working on version: kamailio 4.1.2 (x86_64/linux) and heaving
troubles with drouting module.
The problem i am facing is that kamailio cannot enter routeid that is
provided inside dr_rule table.
My last try was to use standard script file with placing following data
before t_relay
if (!do_routing(10)) {
sl_send_reply(403, No route for You);
exit;
}
additionaly i have added route definition
route[1] {
xlog(L_INFO,[INFO] Default route --- fn-$fn, fu-$fu, fU-$fU,
ru-$ru, rU-$rU, sp-$sp, si-$si, tu-$tu, tU-$tU);
uac_replace_from(sip:$fU@10.10.10.5);
}
My DB contains following data:
++-++-+--+-++--+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist |
description |
++-++-+--+-++--+
| 1 | 10 | 43 | |0 | 1 | 1 | test
rule |
++-++-+--+-++--+
+--+--+---+---++---+-+
| gwid | type | address | strip | pri_prefix | attrs | description |
+--+--+---+---++---+-+
|1 | 10 | 10.10.10.9 | 0 | NULL | NULL | FirstGW|
+--+--+---+---++---+-+
The result is that script is omitting route[1] without any purpose (xlog
is not shown, $fU is not modified).
Could somebody help me to understand whats going on?
Thanks in advanced,
Mac
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman
[SR-Users] DRouting, routeid is not triggered
Hello,
I am working on version: kamailio 4.1.2 (x86_64/linux) and heaving troubles
with drouting module.
The problem i am facing is that kamailio cannot enter routeid that is
provided inside dr_rule table.
My last try was to use standard script file with placing following data
before t_relay
if (!do_routing(10)) {
sl_send_reply(403, No route for You);
exit;
}
additionaly i have added route definition
route[1] {
xlog(L_INFO,[INFO] Default route --- fn-$fn, fu-$fu, fU-$fU,
ru-$ru, rU-$rU, sp-$sp, si-$si, tu-$tu, tU-$tU);
uac_replace_from(sip:$fU@10.10.10.5);
}
My DB contains following data:
++-++-+--+-++--+
| ruleid | groupid | prefix | timerec | priority | routeid | gwlist |
description |
++-++-+--+-++--+
| 1 | 10 | 43 | |0 | 1 | 1 | test
rule |
++-++-+--+-++--+
+--+--+---+---++---+-+
| gwid | type | address | strip | pri_prefix | attrs | description |
+--+--+---+---++---+-+
|1 | 10 | 10.10.10.9 | 0 | NULL | NULL | FirstGW|
+--+--+---+---++---+-+
The result is that script is omitting route[1] without any purpose (xlog is
not shown, $fU is not modified).
Could somebody help me to understand whats going on?
Thanks in advanced,
Mac
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Several BYEs conveying Kamailio
Dear ALL, I have configured Kamailio 1.5 from svn with radius (radiusclient-ng) support for acc. All seem to work okay, except one thing. From time to time I am receiving following radius error (debug from radius server on different ip) Fri Jul 9 12:22:58 2010 : Error: rlm_sql (sql): Couldn't update SQL accounting STOP record - Column 'AcctStartTime' cannot be null Fri Jul 9 12:23:08 2010 : Error: rlm_sql (sql): Couldn't update SQL accounting STOP record - Column 'AcctStartTime' cannot be null Fri Jul 9 12:23:18 2010 : Error: rlm_sql (sql): Couldn't update SQL accounting STOP record - Column 'AcctStartTime' cannot be null A few lines from radiusclient.conf # time to wait for a reply from the RADIUS server radius_timeout 10 # resend request this many times before trying the next server radius_retries 3 After closer look at this, it turned out that there is one START request and four STOPs with the same CallID (Acct-Session-Id). START and first STOP are treated as a pair, the next ones are odd. Taking about sip i do have following scenario: MGW(1)---Kamailio(2)---SIP_Provider(SER based)(3) The call flow that generate aforemtioned errors looks like below (debug on kamailio) 1 - (2) is receiving INVITE from (3) 2 - (2) is sending Giving a Try to (3) 3 - (2) is sending INVITE to (1) 4 - (2) is receiving Trying from (1) 5 - (2) is receiving Ringing from (1) 6 - (2) is receiving OK from (1) 7 - (2) is sending OK to (3) 8 - (2) is receiving ACK from (3) 9 - (2) is sending ACK to (1) call 10 - (2) is receiving BYE from (1) (tearing down from (1) side, STOP radius request is generated) 11 - (2) is sending BYE to (3) 12 - (2) is receiving BYE from (3) (second STOP is generated, radius_retries 3, radius_timeout 10) 13 - (2) is sending BYE to (1) 14 - (2) is receiving OK from (1) 15 - (2) is sending OK to (3) 16 - (2) is receiving OK to (3) 17 - (2) is sending OK to (1) For sure there is sth wrong with SIP_Provider but how Kamilio should behave is such situation. Should second BYE (p.12) with the same callid as in p.10 be continued with p.13? Thanks in advance, Maciej. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
Hi, My script is almost done. I am wondering how weights are calculated in order to choose proper gws list. For this test I've modified gw table in following way (the same weights). LCR table points to grp_id=1. ++--+++--+--++---+---+--++--+---+ | id | gw_name | grp_id | ip_addr| hostname | port | uri_scheme | transport | strip | tag | weight | ping | flags | ++--+++--+--++---+---+--++--+---+ | 1 | GW11 | 11 | 33.44.55.66 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 2 | GW1 group 1 | 1 | 11.22.33.10 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 3 | GW5 | 2 | 22.33.44.55 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 4 | GW6 | 3 | 22.33.44.56 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 5 | GW2 group 1 | 1 | 11.22.33.11 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 6 | GW3 group 1 | 1 | 11.22.33.12 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 7 | GW4 group 1 | 1 | 11.22.33.13 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | ++--+++--+--++---+---+--++--+---+ According to syslog debugs: Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:lcr_hash_table_lookup: looking for 482221 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:lcr_hash_table_lookup: looking for 48222 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:do_load_gws: added matched_gws[0]=[2, 5, 1, 238659200] Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:do_load_gws: added matched_gws[1]=[6, 5, 1, 13052500] Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:do_load_gws: added matched_gws[2]=[5, 5, 1, 769501300] Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:do_load_gws: added matched_gws[3]=[3, 5, 1, 440887600] Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:lcr_hash_table_lookup: looking for 4822 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:lcr_hash_table_lookup: looking for 482 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:lcr_hash_table_lookup: looking for 48 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:add_gws_into_avps: added gw_uri_avp 1|0||4274347715||5060|0|0 with weight 13052500 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:add_gws_into_avps: added gw_uri_avp 1|0||3552927427||5060|0|0 with weight 238659200 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:add_gws_into_avps: added gw_uri_avp 1|0||3569704643||5060|0|0 with weight 440887600 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:add_gws_into_avps: added gw_uri_avp 1|0||4240793283||5060|0|0 with weight 769501300 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:generate_uris: r_uri sip:48221112...@11.22.33.12:5060, dst_uri Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:next_gw: added ruri_user_avp 48221112233 Jul 7 09:16:06 skype-sip01 /usr/local/sbin/kamailio[12321]: DBG:lcr:next_gw: added flags_avp 0 So it means that weights are calculated different way, not directly and only according to weight column. What is more defining wieght column does not make any sense, because data provided there produce different output. Anybody could point me in right direction. Thanks, Maciej. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
Juha, it is weight column, not priority column. weight gives a probability of the gw being chosen from among gws of the same group. What other parameters are taken into account while defining probability? Is that means, that to achieve 100% predictable routing (not to count on probability), i need to +--++--++--+ | id | prefix | from_uri | grp_id | priority | +--++--++--+ | 140 | 4822 | ^from_sip$ | 1 |1 | | 142 | 4822 | ^from_sip$ | 2 |2 | | 143 | 4822 | ^from_sip$ | 3 |3 | | 144 | 4822 | ^from_sip$ | 4 |4 | | 2 | GW1 group 1 | 1 | 11.22.33.10 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 5 | GW2 group 2 | 2 | 11.22.33.11 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 6 | GW3 group 3 | 3 | 11.22.33.12 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | | 7 | GW4 group 4 | 4 | 11.22.33.13 | NULL | 5060 | NULL | NULL | NULL | NULL |100 |0 | 0 | Thx, Maciej ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
if dp_translate matches a dialplan match_exp then corresponding attr value is assigned to attrs_pvar. you can then prefix $rU with that value and call load_gws(). Thanks Juha. I am about to implement what You've said. Maciej. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
Hi again, Last question in this topic i hope. Could I use regex in prefix column (lcr table)? I just want to have a minimum number of entries created there, and to block the rest of prefixes in this way. Thx, Maciej. 2010/6/21 Iñaki Baz Castillo i...@aliax.net: 2010/6/20 Maciej Bylica mb...@gazeta.pl: Hi Iñaki, You can inspect manually (via script) the calling number and set the from_uri pseudo variable according to it. Would it be valid? Setting 48 and 48221112233 in the lcr entries is not valid as when the CLI is 48221112233 both entries would match it (perhaps randomly or based on first entry in the table). I strongly prefer to play with cusom from_uri values manually set in the script befor invoking load_gws(pseudovariable). Sry for delay. I followed Your instructions and the effect is possitive - it works. Many thanks, Great ;) -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
This occurs because the rules with id=1 and id=3 do match the INVITE
so if the first fails (longest matching prefix) the other will be
executed. This is how LCR works.
Use load_gws() with a pseudo-variable as I recommend you in the other
mail so you won't rely on the From URI but on the call origin you have
previously analized in the script.
It works :)
In lcr:
++---+++--+
| id | prefix| from_uri | grp_id | priority |
++---+++--+
| 1 | 48| ^from_sip$ | 1 |1 |
| 2 | 48| ^from_pstn$ | 2 |1 |
++---+++--+
gw,
++--+++--+--++---+---+--++--+---+
| id | gw_name | grp_id | ip_addr| hostname | port |
uri_scheme | transport | strip | tag | weight | ping | flags |
++--+++--+--++---+---+--++--+---+
| 1 | CLI48 | 1 | 77.77.77.70 | NULL | 5060 | NULL |
NULL | NULL | NULL |150 |0 | 0 |
| 2 | CLI48backup | 1 | 77.77.77.71 | NULL | 5060 |
NULL | NULL | NULL | NULL |150 |0 | 0 |
| 3 | CLI49 | 1 | 77.77.77.75 | NULL | 5060 | NULL |
NULL | NULL | NULL | 15 |0 | 0 |
| 4 | CLI49backup | 1 | 77.77.77.76 | NULL | 5060 |
NULL | NULL | NULL | NULL | 15 |0 | 0 |
| 5 | SIPWORLD | 2 | 88.88.88.88 | NULL | 5060 |
NULL | NULL | NULL | NULL |250 |0 | 0 |
++--+++--+--++---+---+--++--+---+
if (allow_source_address(1)) {
$var(origin) = from_sip;
}
else if (allow_source_address(2)) {
$var(origin) = from_pstn;
}
else{
sl_send_reply(403, Forbidden);
exit;
where 1 and 2 are MGWs and SIPWORLD ips.
Then load_gws($var(origin)) is called.
But still one issue remains (only from SIPWORLD --- Kamailio
MGWs scenario).
As aforementioned i need to inspect calling number and choose proper
MGWs to have the call terminated.
I need to be able to identify calling numbers like 48 (only two
starting digits), 48221112233 (the whole number), and the rest.
Is there any way i can implement this functionality with lcr module?
Thx,
Maciej.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
Hi ALL,
I have a problem to configure LCR module to work properly (kamailio rel. 1.5)
The task in my case is to handle:
1) All calls coming with CLD number prefix 482223344 from my MGW
(77.77.77.77) towards kamilio and direct them to sip world
(88.88.88.88)
2) Calls with CLD starting with 48 coming from SIP world towards
kamailio and direct them to my MGWs. Additionaly i need to route it on
the basis of CLI number.
So MGWs --- Kamailio --- SIPProxies (88.88.88.88)
In db:
++---+++--+
| id | prefix| from_uri | grp_id | priority |
++---+++--+
| 1 | 48| 48 | 1 |1 |
| 2 | 48| 49 | 2 |1 |
| 3 | 482223344 | 77.77.77.77 | 3 |1 |
++---+++--+
gw,
++--+++--+--++---+---+--++--+---+
| id | gw_name | grp_id | ip_addr| hostname | port |
uri_scheme | transport | strip | tag | weight | ping | flags |
++--+++--+--++---+---+--++--+---+
| 1 | CLI48 | 1 | 77.77.77.70 | NULL | 5060 | NULL |
NULL | NULL | NULL |150 |0 | 0 |
| 2 | CLI48backup | 1 | 77.77.77.71 | NULL | 5060 |
NULL | NULL | NULL | NULL |150 |0 | 0 |
| 3 | CLI49 | 2 | 77.77.77.75 | NULL | 5060 | NULL |
NULL | NULL | NULL | 15 |0 | 0 |
| 4 | CLI49backup | 2 | 77.77.77.76 | NULL | 5060 |
NULL | NULL | NULL | NULL | 15 |0 | 0 |
| 5 | SIPWORLD | 3 | 88.88.88.88 | NULL | 5060 |
NULL | NULL | NULL | NULL |250 |0 | 0 |
++--+++--+--++---+---+--++--+---+
Unfortunately:
- call is originated on 77.77.77.77 with CLD 48222334455 number and
kamailio forward this call to grp_id=3 SIPWORLD which is okay. The
problem is that if the call fail, kamailio will try to use 77.77.77.70
and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to
provide a kind of huntstop in grp_id=3.
I've been trying with
++---+++--+
| id | prefix| from_uri | grp_id | priority |
++---+++--+
| 1 | 48| 88.88.88.88 | 1 |1 |
| 2 | 48| 88.88.88.88 | 2 |1 |
| 3 | 482223344 | 77.77.77.77 | 3 |1 |
++---+++--+
but in this case i am unable to provide kamailio with CLI number routing.
Here is a part of my config file...
if (!load_gws()) {
sl_send_reply(503, Unable to load gateways);
exit;
}
if (!next_gw()) {
sl_send_reply(503, Unable to find a
gateway);
exit;
}
route(1);
exit;
and failover for route(1)...
failure_route[11] {
# In case of failure, send it to an alternative route:
if (t_check_status(408|404|5[0-9][0-9])) {
if (!next_gw()) {
t_reply(503, Service not available, no more
gateways);
exit;
}
else{
t_on_failure(11);
t_relay();
}
exit;
}
}
Anybody could help my to get out of that?
Thx,
Maciej.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] LCR, problem with routing (prefix, from_uri, grp_id)
2010/5/12 Maciej Bylica mb...@gazeta.pl: 2010/5/12 Iñaki Baz Castillo i...@aliax.net: 2010/5/12 Maciej Bylica mb...@gazeta.pl: Hi ALL, I have a problem to configure LCR module to work properly (kamailio rel. 1.5) The task in my case is to handle: 1) All calls coming with CLD number prefix 482223344 from my MGW (77.77.77.77) towards kamilio and direct them to sip world (88.88.88.88) 2) Calls with CLD starting with 48 coming from SIP world towards kamailio and direct them to my MGWs. Additionaly i need to route it on the basis of CLI number. So MGWs --- Kamailio --- SIPProxies (88.88.88.88) In db: ++---+++--+ | id | prefix | from_uri | grp_id | priority | ++---+++--+ | 1 | 48 | 48 | 1 | 1 | | 2 | 48 | 49 | 2 | 1 | | 3 | 482223344 | 77.77.77.77 | 3 | 1 | ++---+++--+ Unfortunately: - call is originated on 77.77.77.77 with CLD 48222334455 number and kamailio forward this call to grp_id=3 SIPWORLD which is okay. The problem is that if the call fail, kamailio will try to use 77.77.77.70 and 77.77.77.71 from grp_id=1 which is wrong. I have no idea how to provide a kind of huntstop in grp_id=3. Why do you set 77.77.77.77 in the from_uri field of the third entry in 'lcr' table? It makes no sense. As you don't pass a pseudovariable to the command load_gw() then LCR tries to match the *From URI* of the INVITE with the 'from_uri' of the 'lcr' table. -- Iñaki Baz Castillo i...@aliax.net Hi, Thx for prompt answer. I was playing around with lcr table and found that i may place an IP address which is a part of sip uri there. It means that if a call is originated from 77.77.77.77 (from sip uri 482223...@77.77.77.77) then grp_id=3 should be chosen. Of course i may wipe this out but i am unsure if it help. Still the call matches id=3 and just after failure id=1. Thx, Maciej. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
