sr-users July 2010

sr-users@lists.kamailio.org

64 participants
87 discussions

[Kamailio-Users] kamailio and PRACK
by BERGANZ François 10 Aug '10

10 Aug '10

Hello, Does kamailio support PRACK method ? If yes, how? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

5 4

PDT ran out of pkg memory using pdt_list
by JR Richardson 10 Aug '10

10 Aug '10

Hi All, I loaded up the PDT database with about 35K records and when I issue the commad "kamctl fifo pdt_list" I get: 3(3018) ERROR: <core> [tree.c:139]: no more pkg mem 3(3018) ERROR: mi_fifo [fifo_fnc.c:509]: command (pdt_list) processing failed Searching around I found the http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory which suggest I adjust the pkg mem size in config.h. In config.h, I found: /*used only if PKG_MALLOC is defined*/ #define PKG_MEM_POOL_SIZE 4*1024*1024 So is this what I am supposed to adjust? Maybe try: #define PKG_MEM_POOL_SIZE 4*2048*2048 or #define PKG_MEM_POOL_SIZE 8*1024*1024 Which one would be a logical adjustment? Also, is there a correlation between pkg mem and database record size as related to pdt_list? The idea is to have a few 100K records loaded in kamailio and be able to perform "kamctl fifo pdt_list | grep 512345" to show this prefix route. But without enough memory, doesn't work. Thanks. JR -- JR Richardson Engineering for the Masses

8 29

Help needed for OpenSer with Radius
by Pratik Shrestha 06 Aug '10

06 Aug '10

Dear All, I am very new to OpenSer. I want to use latest version of OpenSer with Radius. I need the documentation/tutorial on how to do this. Googling, Ionly found for the old version. Please help me. Regards, Pratik

3 8

Kamailio doesn't start
by Ernest Mavrel 06 Aug '10

06 Aug '10

Hi I have problems with starting of kamailio. When is rule in table dialplan, kamailio doesn't start. Dialplan table: id dpid pr match_op match_exp match_len subst_exp repl_exp attrs 1 1 0 1 ^0[1-9] 0 ^(0)([1-9])(.+) 386\2 Cut_0_Add_386 Log: 0(11570) DEBUG: dialplan [dp_db.c:200]: init 0(11570) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result set at 0x95ff60 0(11570) DEBUG: db_mysql [km_res.c:68]: 8 columns returned from the query 0(11570) DEBUG: <core> [db_res.c:155]: allocate 64 bytes for result names at 0x960028 0(11570) DEBUG: <core> [db_res.c:165]: allocate 32 bytes for result types at 0x960118 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[0] at 0x95fe18 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x95fe18)[0]=[dpid] 0(11570) DEBUG: db_mysql [km_res.c:100]: use DB1_INT result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[1] at 0x960310 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x960310)[1]=[pr] 0(11570) DEBUG: db_mysql [km_res.c:100]: use DB1_INT result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[2] at 0x960350 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x960350)[2]=[match_op] 0(11570) DEBUG: db_mysql [km_res.c:100]: use DB1_INT result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[3] at 0x960330 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x960330)[3]=[match_exp] 0(11570) DEBUG: db_mysql [km_res.c:136]: use DB1_STRING result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[4] at 0x9602f0 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x9602f0)[4]=[match_len] 0(11570) DEBUG: db_mysql [km_res.c:100]: use DB1_INT result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[5] at 0x9602d0 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x9602d0)[5]=[subst_exp] 0(11570) DEBUG: db_mysql [km_res.c:136]: use DB1_STRING result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[6] at 0x9602b0 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x9602b0)[6]=[repl_exp] 0(11570) DEBUG: db_mysql [km_res.c:136]: use DB1_STRING result type 0(11570) DEBUG: db_mysql [km_res.c:85]: allocate 16 bytes for RES_NAMES[7] at 0x960290 0(11570) DEBUG: db_mysql [km_res.c:92]: RES_NAMES(0x960290)[7]=[attrs] 0(11570) DEBUG: db_mysql [km_res.c:136]: use DB1_STRING result type 0(11570) DEBUG: db_mysql [km_dbase.c:342]: converting row 0 of 1 count 1 0(11570) DEBUG: <core> [db_row.c:119]: allocate 256 bytes for row values at 0x960370 0(11570) DEBUG: <core> [db_val.c:73]: converting INT [1] 0(11570) DEBUG: <core> [db_val.c:73]: converting INT [0] 0(11570) DEBUG: <core> [db_val.c:73]: converting INT [1] 0(11570) DEBUG: <core> [db_val.c:117]: converting STRING [^0[1-9]] 0(11570) DEBUG: <core> [db_val.c:73]: converting INT [0] 0(11570) DEBUG: <core> [db_val.c:117]: converting STRING [^(0)([1-9])(.+)] 0(11570) DEBUG: <core> [db_val.c:117]: converting STRING [386\2] 0(11570) DEBUG: <core> [db_val.c:117]: converting STRING [Cut_0_Add_386] 0(11570) DEBUG: dialplan [dp_db.c:374]: build_rule Any help? BR Ernest

3 20

INumWare: Inum Users Conference
by Meftah Tayeb 31 Jul '10

31 Jul '10

hello folk you're invited to join the inum ware conference this conference is for inum users that frequantly use inum (+883 country code) (http://www.inum.net) you can join it by dialing +883510001288888 from any provider that provide INum termination (see http://www.inum.net) thank you! -- Meftah Tayeb algérie télécom SPA phone: +21321761805 phone (INUM): +883510001289101 mobile : +213660347746 mobile (INUM: +883510001289110 http://www.algerietelecom.dz

1 0

Loops using uac_replace_from
by Ján ONDREJ (SAL) 30 Jul '10

30 Jul '10

Hello, after some failures with uac_auth (uac_auth can't increase CSeq number, which is required by my provider) my provider maked me an testing access without autentification, but I still can't make calls with kamailio or openser. I can make calls with opensips, but I am still not chosen, which sip software to use in future (still using openser). This is a part of my configuration: route[6] { uac_replace_from("sip:556807505@as.xxxxxx.sk"); rewritehostport("122.33.44.200"); route(5); } When trying to sniff packets and diff them, I am still getting this from my kamailio server: U kamailio_ip:5060 -> client_ip:5060 SIP/2.0 500 I'm terribly sorry, server error occurred (6/SL). From: "Ondrej Jan" <sip:xxxxxx@xxxx>;tag=59427D6F-81E63720. To: <sip:xxxxx@xxxxx;user=phone>;tag=cc70c0fe52d7af0accfb78a94d592620.f69c. CSeq: 1 INVITE. Call-ID: 37cadcfb-f93b8e1d-431cdf6@xxxxxxxxxxx. Server: kamailio (3.0.2 (i386/linux)). Content-Length: 0. Logs are below. Any idea, what happening and why a default opensips configuration works and kamailio/openser don't? SAL [root@kamailio ~]# kamailio -DddE loading modules under /usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/ Listening on udp: 123.123.242.20:5060 Aliases: udp: kamailio.xxxx.sk:5060 *: 123.123.242.20:* WARNING: no fork mode 0(2364) INFO: <core> [tcp_main.c:4150]: init_tcp: using epoll_lt as the io watch method (auto detected) 0(2364) INFO: usrloc [hslot.c:53]: locks array size 512 0(2364) INFO: <core> [udp_server.c:166]: INFO: udp_init: SO_RCVBUF is initially 112640 0(2364) INFO: <core> [udp_server.c:217]: INFO: udp_init: SO_RCVBUF is finally 262142 4(2368) INFO: ctl [io_listener.c:224]: io_listen_loop: using epoll_lt io watch method (config) 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: tm [t_fwd.c:1379]: ERROR: t_forward_nonack: no branches for forwarding 0(2364) ERROR: <core> [action.c:1269]: WARNING: too many recursive routing table lookups (101) giving up! 0(2364) ERROR: <core> [action.c:1269]: WARNING: too many recursive routing table lookups (101) giving up! 0(2364) ERROR: <core> [action.c:1269]: WARNING: too many recursive routing table lookups (101) giving up! 0(2364) BUG: tm [t_lookup.c:1556]: tm: t_unref: REQ_ERR DELAYED should have been caught much earlier for 0xb5a15490: 17 (hex 11) ^C 4(2368) INFO: <core> [main.c:788]: INFO: signal 2 received 3(2367) INFO: <core> [main.c:788]: INFO: signal 2 received 1(2365) INFO: <core> [main.c:788]: INFO: signal 2 received 2(2366) INFO: <core> [main.c:788]: INFO: signal 2 received 0(2364) ALERT: <core> [main.c:719]: child process 2365 exited normally, status=0 0(2364) ALERT: <core> [main.c:719]: child process 2366 exited normally, status=0 0(2364) ALERT: <core> [main.c:719]: child process 2367 exited normally, status=0 0(2364) ALERT: <core> [main.c:719]: child process 2368 exited normally, status=0 0(2364) INFO: <core> [main.c:734]: INFO: dont_fork turned on, living on 0(2364) NOTICE: <core> [main.c:679]: Thank you for flying kamailio

3 2

[Kamailio-users] Weight based routing
by Chandrakant Solanki 30 Jul '10

30 Jul '10

Hello, I have setup 3 SIP server. It should be Kamailio, Asterisk or Any SIP Server. I have setup 3 server say Server A, Server B and Server C and each has weight like 50, 30, 20 in percentage. And I taken 10 calls and try to forward call based on weight. Is this possible in kamailio's module.. and if yes then which module will help me? Any Idea.. -- Regards, Chandrakant Solanki

4 6

Modifying replies in failure route
by Alex Balashov 29 Jul '10

29 Jul '10

I know failure routes operate relative to the request that failed, rather than the final reply received per se. Nevertheless, is there any way provided by Kamailio/SR at this time to modify a final reply (say, append a header, or something else theoretically permissible) prior to its being passed to the originating UAC? -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

2 4

Re: [SR-Users] urgent :geographic number problem
by Alex Balashov 29 Jul '10

29 Jul '10

These (very poorly formatted!) requests and replies all relate to OPTIONS pings and have nothing to do with calls, failed or otherwise. On 07/29/2010 07:48 AM, hala alramli wrote: > some thing strang ,befor every thing work fine but now the most of the > geografic dont receive calls from outbound (landline) but recive calls > from our system it seem that it deal with it as local number just,when i > snif the backet by using ngrep it give me this: > 2010/07/29 12:58:28.111091 77.93.***.***:5060 -> 173.33.***.***:60005 > OPTIONS sip:173.33.***.***:60005 SIP/2.0..Via: SIP/2.0/UDP > 77.93.***.***:5060 ;branch=0..From: > sip:pinger@nogafone.com;tag=b4a8a831..To: sip:173.33.***.***: > :60005..Call-ID: f8d76aa2-5f768331-3b621@173.33.***.***:..CSeq > <mailto:f8d76aa2-5f768331-3b621@77.93.249.153..CSeq>: 1 > OPTIONS..Content-Length: 0.... > U 2010/07/29 12:58:28.111114 77.93.***.***:5060 -> 173.33.***.***::60004 > OPTIONS sip:173.33.***.***::60004 SIP/2.0..Via: SIP/2.0/UDP > 77.93.249.153:5060;branch=0..From: > sip:pinger@nogafone.com;tag=c4a8a831..To: sip:173.33.***.***: > :60004..Call-ID: f8d76aa2-6f768331-3b621@77.93.***.***:..CSeq > <mailto:f8d76aa2-6f768331-3b621@77.93.249.153..CSeq>: 1 > OPTIONS..Content-Length: 0.... > U 2010/07/29 12:58:28.247854 173.33.***.***:60004 -> 77.93.249.153:5060 > SIP/2.0 404 Not Found..To: > sip:173.33.***.***:60004;tag=c8b17aeb9f7688a1i0..From: > sip:pinger@nogafone.com;tag=c4a8a831..Call-ID: f8d76aa2-6f768331-3b621@ > 77.93.***.***:..CSeq: 1 OPTIONS..Via: SIP/2.0/UDP > 77.93.***.***::5060;branch=0..Server: > Linksys/PAP2T-3.1.15(LS)..Content-Length: 0.... > U 2010/07/29 12:58:28.255958 173.33.***.***:60005 -> 77.93.249.153:5060 > SIP/2.0 404 Not Found..To: > sip:173.33.***.***:60005;tag=c8b17aeb9f7688a1i0..From: > sip:pinger@nogafone.com;tag=b4a8a831..Call-ID: f8d76aa2-5f768331-3b621@ > 77.93.***.***:..CSeq: 1 OPTIONS..Via: SIP/2.0/UDP > 77.93.***.***:5060;branch=0..Server: > Linksys/PAP2T-3.1.15(LS)..Content-Length: 0.... > what is strang is that the replay is 404 not found while > 173.33.***.***:60005 is an IP address for an online adapter i will be > thankfull for any hint > regards > hala > > --- On *Wed, 7/28/10, Alex Balashov /<abalashov(a)evaristesys.com>/* wrote: > > > From: Alex Balashov <abalashov(a)evaristesys.com> > Subject: Re: [SR-Users] urgent :geographic number problem > To: "hala alramli" <doreme202002(a)yahoo.com> > Cc: "SR-Users" <sr-users(a)lists.sip-router.org> > Date: Wednesday, July 28, 2010, 5:52 PM > > On 07/28/2010 10:48 AM, hala alramli wrote: > > > our geographic number cant receive calls from outbound (from normal > > landlines number) but it receive from our system numbers just > ?where is > > the problem,is it from our server or from the company that provide us > > with this geographic number? > > It is impossible to know the answer to this question without digging > deeper into the underlying cause of the superficial effect you are > describing. The best way is to take a packet capture and see if the > requests from the provider are actually arriving; then you will know > at least whether they are reaching the server, and from there can > see why they may not be getting handled properly at the application > level. > > If the number worked before, and spontaneously stopped working, and > you did not change any configuration, it is most likely the provider. > > -- Alex Balashov - Principal > Evariste Systems LLC > 1170 Peachtree Street > 12th Floor, Suite 1200 > Atlanta, GA 30309 > Tel: +1-678-954-0670 > Fax: +1-404-961-1892 > Web: http://www.evaristesys.com/ > > -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

1 0

Fw: Re: urgent :geographic number problem
by hala alramli 29 Jul '10

29 Jul '10

--- On Thu, 7/29/10, hala alramli <doreme202002(a)yahoo.com> wrote: From: hala alramli <doreme202002(a)yahoo.com> Subject: Re: [SR-Users] urgent :geographic number problem To: "Alex Balashov" <abalashov(a)evaristesys.com> Date: Thursday, July 29, 2010, 2:48 PM some thing strang ,befor every thing work fine but now the most of the geografic dont receive calls from outbound (landline) but recive calls from our system it seem that it deal with it as local number just,when i snif the backet by using ngrep it give me this: 2010/07/29 12:58:28.111091 77.93.***.***:5060 -> 173.33.***.***:60005 OPTIONS sip:173.33.***.***:60005 SIP/2.0..Via: SIP/2.0/UDP 77.93.***.***:5060 ;branch=0..From: sip:pinger@nogafone.com;tag=b4a8a831..To: sip:173.33.***.***: :60005..Call-ID: f8d76aa2-5f768331-3b621@173.33.***.***:..CSeq: 1 OPTIONS..Content-Length: 0.... U 2010/07/29 12:58:28.111114 77.93.***.***:5060 -> 173.33.***.***::60004 OPTIONS sip:173.33.***.***::60004 SIP/2.0..Via: SIP/2.0/UDP 77.93.249.153:5060;branch=0..From: sip:pinger@nogafone.com;tag=c4a8a831..To: sip:173.33.***.***: :60004..Call-ID: f8d76aa2-6f768331-3b621@77.93.***.***:..CSeq: 1 OPTIONS..Content-Length: 0.... U 2010/07/29 12:58:28.247854 173.33.***.***:60004 -> 77.93.249.153:5060 SIP/2.0 404 Not Found..To: sip:173.33.***.***:60004;tag=c8b17aeb9f7688a1i0..From: sip:pinger@nogafone.com;tag=c4a8a831..Call-ID: f8d76aa2-6f768331-3b621@ 77.93.***.***:..CSeq: 1 OPTIONS..Via: SIP/2.0/UDP 77.93.***.***::5060;branch=0..Server: Linksys/PAP2T-3.1.15(LS)..Content-Length: 0.... U 2010/07/29 12:58:28.255958 173.33.***.***:60005 -> 77.93.249.153:5060 SIP/2.0 404 Not Found..To: sip:173.33.***.***:60005;tag=c8b17aeb9f7688a1i0..From: sip:pinger@nogafone.com;tag=b4a8a831..Call-ID: f8d76aa2-5f768331-3b621@ 77.93.***.***:..CSeq: 1 OPTIONS..Via: SIP/2.0/UDP 77.93.***.***:5060;branch=0..Server: Linksys/PAP2T-3.1.15(LS)..Content-Length: 0.... what is strang is that the replay is 404 not found while 173.33.***.***:60005 is an IP address for an online adapter i will be thankfull for any hint regards hala --- On Wed, 7/28/10, Alex Balashov <abalashov(a)evaristesys.com> wrote: From: Alex Balashov <abalashov(a)evaristesys.com> Subject: Re: [SR-Users] urgent :geographic number problem To: "hala alramli" <doreme202002(a)yahoo.com> Cc: "SR-Users" <sr-users(a)lists.sip-router.org> Date: Wednesday, July 28, 2010, 5:52 PM On 07/28/2010 10:48 AM, hala alramli wrote: > our geographic number cant receive calls from outbound (from normal > landlines number) but it receive from our system numbers just ?where is > the problem,is it from our server or from the company that provide us > with this geographic number? It is impossible to know the answer to this question without digging deeper into the underlying cause of the superficial effect you are describing. The best way is to take a packet capture and see if the requests from the provider are actually arriving; then you will know at least whether they are reaching the server, and from there can see why they may not be getting handled properly at the application level. If the number worked before, and spontaneously stopped working, and you did not change any configuration, it is most likely the provider. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users July 2010