Re: [OpenSIPS-Users] OpenSips, Media-Dispatcher: Calls not being sent to media-relays after upgrade
Hi, On 15/4/10 4:44 AM, Mike O'Connor wrote: Hi All I downgrade back to opensips-1.6.1 and mediaproxy-2.3.10, mediaproxy started working again. I then upgraded to mediaproxy-2.4.2, mediaproxy was still being used. Upgrading to opensips-1.6.2 again and mediaproxy stopped working. So the problem must be in opensips-1.6.2, I've been compiling my own 64bit version. Mike Humm, that's quite surprising :-S There were some changes to the mediaproxy module in the last release, but I didn't face that issue myself. Can you paste the log produced by opensips when it should have called MediaProxy? Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips just stops responding
Hi Bogdan, Thanks for this info. I never thought in this direction. My local DNS server IP had indeed changed a few weeks ago and my secondary DNS server is at a different location which might be causing the delay. I had forgot to change the local DNS server address in which Opensips was running. I've now changed it yesterday and will keep monitoring this week. This was indeed very very helpful. Thanks a lot !! --- Jayesh Hi Jayesh, The trace shows your opensips is blocked in doing a DNS query. I guess you have some domain name which get a very long timeout in query - this long timeout keeps an opensips processes blocked until timeout fires or gets an answer I suggest to set up a local DNS server (as proxy) to force a very low timeout on queries (to avoid blocking all opensips processes in DNS). This majoe problem is to be fixed in new opensips 2.0 version. Regards, Bogdan Jayesh Nambiar wrote: Hi Bogdan, Tried different things on the script but still the script seems to die after some time. Some Time could be few hours or few days. I was not able to do the gdb and get the backtrace as one of my technician would always restart it to get the opensips up and working. I was finally able do the gdb and get the backtrace today. I have pasted the backtrace, Please check and give me some idea on where to check and correct for this? #0 0x003f83ac8fdf in poll () from /lib64/libc.so.6 #1 0x003f88608e00 in __libc_res_nsend () from /lib64/libresolv.so.2 #2 0x003f88607c26 in __libc_res_nquery () from /lib64/libresolv.so.2 #3 0x003f88607e96 in __libc_res_nquerydomain () from /lib64/libresolv.so.2 #4 0x003f886081c0 in __libc_res_nsearch () from /lib64/libresolv.so.2 #5 0x2b0de09ca8cf in _nss_dns_gethostbyname3_r () from /lib64/libnss_dns.so.2 #6 0x2b0de09caabe in _nss_dns_gethostbyname_r () from /lib64/libnss_dns.so.2 #7 0x003f83ae7e71 in gethostbyname_r@@GLIBC_2.2.5 () from /lib64/libc.so.6 #8 0x003f83ae77a3 in gethostbyname () from /lib64/libc.so.6 #9 0x00459a29 in sip_resolvehost (name=0x7fff0d2fda80, port=0x800b1a, proto=0x800b1c, is_sips=-1, dn=0x800b40) at resolve.h:349 #10 0x0043fe10 in mk_proxy (name=0x7fff0d2fda80, port=0, proto=0, is_sips=0) at proxy.c:252 #11 0x2b0d9de09588 in t_relay_to (p_msg=0x7f8ae0, proxy=0x0, flags=value optimized out) at ut.h:111 #12 0x2b0d9de1b706 in w_t_relay (p_msg=0x7f8ae0, proxy=0x0, flags=0x0) at tm.c:1079 #13 0x0040ea39 in do_action (a=0x790b70, msg=0x7f8ae0) at action.c:967 #14 0x0041150c in run_action_list (a=value optimized out, msg=0x7f8ae0) at action.c:139 #15 0x00466a34 in eval_expr (e=0x790c48, msg=0x7f8ae0, val=0x0) at route.c:1240 #16 0x0046654d in eval_expr (e=0x790c98, msg=0x7f8ae0, val=0x0) at route.c:1556 #17 0x004664f5 in eval_expr (e=0x790ce8, msg=0x7f8ae0, val=0x0) at route.c:1561 #18 0x0040da1d in do_action (a=0x7914d8, msg=0x7f8ae0) at action.c:689 #19 0x0041150c in run_action_list (a=value optimized out, msg=0x7f8ae0) at action.c:139 #20 0x0040f845 in do_action (a=0x78e480, msg=0x7f8ae0) at action.c:119 #21 0x0041150c in run_action_list (a=value optimized out, msg=0x7f8ae0) at action.c:139 #22 0x0040fd13 in do_action (a=0x78fb28, msg=0x7f8ae0) at action.c:706 #23 0x0041150c in run_action_list (a=value optimized out, msg=0x7f8ae0) at action.c:139 #24 0x00410814 in do_action (a=0x78fc00, msg=0x7f8ae0) at action.c:712 #25 0x0041150c in run_action_list (a=value optimized out, msg=0x7f8ae0) at action.c:139 #26 0x00410814 in do_action (a=0x78fcd8, msg=0x7f8ae0) at action.c:712 #27 0x0041150c in run_action_list (a=value optimized out, msg=0x7f8ae0) at action.c:139 #28 0x00411869 in run_top_route (a=0x7880a8, msg=0x7f8ae0) at action.c:119 #29 0x00455fa5 in receive_msg ( buf=0x754e00 ACK sip:6...@sip.novanetfone.insip%3a...@sip.novanetfone.in mailto:sip%3a...@sip.novanetfone.in sip%253a...@sip.novanetfone.in SIP/2.0\r\nRecord-Route: sip:203.XXX.53.XXX;lr=on;ftag=100ef178-1c01a8c0-13c4-50029-e41ec-12a04394-e41ec\r\nRecord-Route: sip:203.XXX.53.XXX;lr=on;ftag=100ef178-1c01a8c0-..., len=4183, rcv_info=0x7fff0d2ffac0) at receive.c:162 #30 0x0049a384 in udp_rcv_loop () at udp_server.c:492 #31 0x00429c3d in main (argc=3, argv=value optimized out) at main.c:818 Thanks for all the help, --- Jayesh Message: 2 Date: Fri, 02 Apr 2010 14:09:47 +0300 From: Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro Subject: Re: [OpenSIPS-Users] Opensips just stops responding To: OpenSIPS users mailling list users@lists.opensips.org mailto:users@lists.opensips.org Message-ID: 4bb5d07b.9060...@voice-system.ro
Re: [OpenSIPS-Users] [OpenSIPS-Devel] New features in BLF and presence
Schumann Sebastian wrote: Hi Anca Nice feature, one question: Publish. The result is that when a buddy is in a call you will see a status indicating this and in the rest of the time you will see the presence state that the buddy set in his client. Is this also done for buddies that did not publish any state before? How will this be threaded by the module? Example: I am registered (but nothing published), performing a call and hang up afterwards. I assume that it will trigger from offline to online but busy to offline again. Is the module considering this or would this require the use of pua_usrloc to have the correct behavior for clients that do not publish presence? Thanks! Sebastian Hi Sebastian, The module does consider this case. The buddy will indeed appear offline until a call is preformed, then it will apear online with status 'Calling' and then if answered 'On the phone' . After the call ends the user will appear again offline. Regards, -- Anca Vamanu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Transport follow up
Hi Daniel, Have you read RFC3263 about Locating SIP Servers (with proto selection) ? http://www.ietf.org/rfc/rfc3263.txt Regards, Bogdan Daniel Goepp wrote: I had a previous question regarding default transport, and the response I got was that the RFC says the order should be UDP, TCP then TLS. However after reading into this further (and some recent experiences with other platforms) I'm wondering if I have a new feature request for OpenSIPS. From the RFC 3263 - Section 4.1 Selecting a Transport Protocol, I read it as saying: 1. If specified in the RURI it SHOULD use this (but doesn't have to) 2. Bunch of stuff on NAPTR (which we are not doing) 3. The section related to what we are doing: -clip- If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier _sip for SIP URIs and _sips for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record. If no SRV records are found, the client SHOULD use TCP for a SIPS URI, and UDP for a SIP URI. However, another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU. -clip- The way I read this is that OpenSIPS MAY select whatever transport it likes, and if no DNS SRV is found, then it would default to using UDP first for SIP. But in our set, DNS SRV does exist, and there are both TCP and UDP records. We would like to decide the default transport order to use, starting with TLS then TCP then UDP. I think I can try to write something in the script to do this, but I'm not sure yet. I don't want to rewrite the RURI, I just want to specify the transport. It would be great if there was a global variable defined in the config that was something like transport_order=TLS,TCP,UDP Thoughts? -dg ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips Control Panel - Statistics Monitor - Statistics Charts
Hi Erick, I think I have a solution for you problem. You need to give apache/httpd write permissions on the folder ../opensips-cp/web/tools/system/smonitor/generated This is because apache is trying to create a png file in that folder. Let me know if you succeeded. Regards, Alex On 4/14/2010 22:46, Erick Chinchilla Berrocal wrote: agepng($this-img, $fileName); /var/www/opensips-cp/web/tools/system/smonitor/lib/libchart/classes/view/plot# vim Plot.php please let me know what is the procedure for fix the problem Thanks -- Alex Ionescu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] New features in BLF and presence
Iñaki Baz Castillo wrote: 2010/4/14 Anca Vamanu a...@opensips.org: Therefore, we decided to mix the dialog information with presence at the presence server. Now, the presence server is able to tell you if a buddy is in a call through presence Notifications even if his phone did not send a presence Publish with this information. The mixing in fact generates presence from dialog info when a call is in progress and mixes this with the presence information received from his phone through Publish. The result is that when a buddy is in a call you will see a status indicating this and in the rest of the time you will see the presence state that the buddy set in his client. Hi, this feature sounds really reasonable for the real world in which we live :) Could I see how such NOTIFY (mixing presence and dialog information) looks? (just an example). Thanks. Hi Inaki, The mixing is done as until now, no changes in this part. The presence info extracted from dialog is considered to have the greatest priority and is inserted the first. Here is an example: ?xml version=1.0 encoding=UTF-8? presence xmlns=urn:ietf:params:xml:ns:pidf xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid xmlns:c=urn:ietf:params:xml:ns:pidf:cipid entity=sip:a...@192.168.2.132 tuple xmlns=urn:ietf:params:xml:ns:pidf id=tuple_mixingid status basicopen/basic /status /tuple note xmlns=urn:ietf:params:xml:ns:pidfOn the phone/note dm:person xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid id=pers_mixingid rpid:activities rpid:on-the-phone/ /rpid:activities dm:noteOn the phone/dm:note /dm:person tuple id=tab31c654 status basicopen/basic /status /tuple dm:person id=p9e054e30 rpid:activities rpid:busy/ /rpid:activities dm:noteBusy/dm:note /dm:person /presence Regards, -- Anca Vamanu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] [OpenSIPS-Devel] New features in BLF and presence
2010/4/15 Anca Vamanu a...@opensips.org: Hi Inaki, The mixing is done as until now, no changes in this part. The presence info extracted from dialog is considered to have the greatest priority and is inserted the first. Here is an example: ?xml version=1.0 encoding=UTF-8? presence xmlns=urn:ietf:params:xml:ns:pidf xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid xmlns:c=urn:ietf:params:xml:ns:pidf:cipid entity=sip:a...@192.168.2.132 tuple xmlns=urn:ietf:params:xml:ns:pidf id=tuple_mixingid status basicopen/basic /status /tuple note xmlns=urn:ietf:params:xml:ns:pidfOn the phone/note dm:person xmlns:dm=urn:ietf:params:xml:ns:pidf:data-model xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid id=pers_mixingid rpid:activities rpid:on-the-phone/ /rpid:activities dm:noteOn the phone/dm:note /dm:person tuple id=tab31c654 status basicopen/basic /status /tuple dm:person id=p9e054e30 rpid:activities rpid:busy/ /rpid:activities dm:noteBusy/dm:note /dm:person /presence Really nice. Thanks. -- Iñaki Baz Castillo i...@aliax.net ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call not being routed correctly with OSP module
Hi, I'm using OpenSIPS in a test environment with an OSP server to provide authorization for calls. The setup is 2 phones and an opensips sip proxy. SIP proxy has an IP of 192.168.1.2 Testphone has an IP of 192.168.1.4 and number 1202 Testphone 2 has an IP of 192.168.1.5 and number 1203 With no accounts setup on the OSP server when I try and make a call the sip proxy returns a 503 because the device is not authorized by the OSP server. Now I have added devices to the OSP server and am trying to make a call from 1203 to 1202 I'm getting 404's. When looking at call detail records on the OSP server there are four calls there even though I only placed one. They all have sources of 192.168.1.5 and destinations of 1202 except one that has a destination of 192.168.1.4 which is the IP of the phone I want to reach. The output in the opensips logfile of the routing logic is shown below: ROUTE: Route IN - M=INVITE RURI=sip:1...@192.168.1.2 F=sip:testpho...@192.168.1.2 T=sip:1...@192.168.1.2 IP=192.168.1.5 id=001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5 ROUTE: Processing INVITE OSP authorization validation logic Without OSP token, apply different authentication strategy Go ahead, everyone is welcomed ROUTE: Authentication passed ROUTE: Use OSP to get routing OSP authorization and routing logic Requesting OSP authorization and routing INFO:osp:ospRequestRouting: request auth and routing for: service_type '0' source '[192.168.1.2]:5060' source_dev '[192.168.1.5]:5060' source_networkid '' calling 'testphone2' called '1202' preferred '' nprn '' npcic '' npdi '0' spid '' ocn '' spn '' altspn '' mcc '' mnc '' diversion_user '' diversion_host '' call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' dest_count '5' INFO:osp:ospLoadRoutes: get destination '0': valid after '2010-04-15T10:47:06Z' valid until '2010-04-15T10:57:06Z' time limit '14400' seconds call id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' calling 'testphone2' called '1202' host '[192.168.1.5]' nprn '' npcic '' npdi '0' spid '' ocn '' spn '' altspn '' mcc '' mnc '' supported '1' network id '' token size '0' INFO:osp:ospLoadRoutes: get destination '1': valid after '2010-04-15T10:47:06Z' valid until '2010-04-15T10:57:06Z' time limit '14400' seconds call id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' calling 'testphone2' called '1202' host '[192.168.1.4]' nprn '' npcic '' npdi '0' spid '' ocn '' spn '' altspn '' mcc '' mnc '' supported '1' network id '' token size '0' INFO:osp:ospRequestRouting: there are '2' OSP routes, call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' Response received Try the 1st route Prepare route specific OSP information INFO:osp:ospPrepareDestination: prepare route to URI 'sip:1...@192.168.1.5' for call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' transaction_id '5460314288097329217' ROUTE: Route OUT Try the next route Prepare route specific OSP information INFO:osp:ospPrepareDestination: prepare route to URI 'sip:1...@192.168.1.4' for call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' transaction_id '5460314288097329217' Try the next route ROUTE: All destinations attempted for call ID '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5'. Call cannot be completed. INFO:osp:ospReportOrigSetupUsage: report orig setup for call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' transaction_id '5460314288097329217' ROUTE: Route IN - M=ACK RURI=sip:1...@192.168.1.2 F=sip:testpho...@192.168.1.2 T=sip:1...@192.168.1.2 IP=192.168.1.5 id=001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5 ROUTE: Processing ACK ROUTE: Relay E2E ACK ROUTE: Route OUT I cant seem to make sense of whats going on, can anyone see what the problem is here? Thanks -- View this message in context: http://n2.nabble.com/Call-not-being-routed-correctly-with-OSP-module-tp4906928p4906928.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] B2B No TO TAG found
Hi Antonio, This is in fact a bug. I will fix it and let you know. Regards, -- Anca Vamanu www.voice-system.ro Antonio Anderson Souza wrote: Hi, I have on doubt, my scenario I have a SIP-Phone A that calls a SIP-Phone B establish the calls, after some time the SIP-Phone B send a Refer with Refer-To header pointing to a SIP-Phone C, the call scenario is working properly, except that the Invite generated by the B2B scenario to transfer the call to the SIP-Phone C is generated with the SIP-Phone B as From, so to the SIP-Phone C seams that the SIP-Phone B are calling him, but who is calling is SIP-Phone A. There are some way to change this behavior in the B2B call scenario, or Can i use the UAC module in the script to replace the From header? Regards, Antonio Anderson Souza Voice Technology http://www.antonioams.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips Control Panel - User
Hi Erick, So, I understand that you have OCP installed. On 4/15/2010 00:56, Erick Chinchilla Berrocal wrote: FYI I installed the opensips-cp Now we have the following issue Opensips Control Panel -- Module User - We can add, remove users with the control panel and with opensipsctl - We used two ip softphone X-Lite , the register is ok , make calls between the phones ( 1001 to 1002) ( 1002 a 1001) - With the commands opensipsctl ul show opensipsctl monitor the informations are ok With the control panel with the control panel, I can see the user, add o remove now we don't see the users if are online or no I think that you should be able to see the online user by checking the Online Users radio button in the Search box under the User Management tab We don't look any call in the control panel , module CDRViewer o Dialog Well, to see calls in the CDR Viewer you have to make some configs (see the INSTALL file - see the three steps there - tables, stored procedure and a script to be put in cron) To see the dialogs in Dialog module you have to load configure the module *dialog* into the OpenSIPS config. - that is why you get errors like *ERROR:mi_fifo:mi_fifo_server: command dlg_list is not available*. (I can see that you have other NOT loaded modules - like dispatcher ... ) Edit this file, but I have the same problem, according this link http://opensips-cp.sourceforge.net/ *opensips-cp/config/tools/admin/list_admins/db.inc.php* This is the log/opensips Apr 14 15:30:04 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command dlg_list is not available Apr 14 15:30:06 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command ds_list is not available Apr 14 15:30:06 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command ds_reload is not available Apr 14 15:30:16 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command sip_trace is not available Apr 14 15:30:22 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command sip_trace is not available Apr 14 15:30:23 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command sip_trace is not available Apr 14 15:30:36 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command dlg_list is not available Apr 14 15:30:38 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command ds_list is not available Apr 14 15:30:38 net /sbin/opensips[2750]: ERROR:mi_fifo:mi_fifo_server: command ds_reload is not available Apr 14 15:37:39 net /sbin/opensips[2750]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2737]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2735]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2734]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2738]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2748]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2733]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2752]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2741]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2760]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2736]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2758]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2743]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2754]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2744]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:39 net /sbin/opensips[2755]: INFO:core:sig_usr: signal 15 received Apr 14 15:37:40 net opensips: INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Apr 14 15:37:40 net /sbin/opensips[5466]: NOTICE:core:main: version: opensips 1.6.2-notls (i386/linux) Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:core:main: using 128 Mb shared memory Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:core:main: using 1 Mb private memory per process Apr 14 15:37:40 net /sbin/opensips[5466]: NOTICE:signaling:mod_init: initializing module ... Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:sl:mod_init: Initializing StateLess engine Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:tm:mod_init: TM - initializing... Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:maxfwd:mod_init: initializing... Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:usrloc:ul_init_locks: locks array size 512 Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:registrar:mod_init: initializing... Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:textops:mod_init: initializing... Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:xlog:mod_init: initializing... Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:acc:mod_init:
Re: [OpenSIPS-Users] One dispatcher mystery solved; Doesn't seem to be remembering a gateway is failed however
Jock McKechnie wrote:
On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
Hi Jock,
Jock McKechnie wrote:
On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro
mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro
wrote:
Hi Jock,
I'm wondering if the above error is some kind of AVP
storage thing I
haven't set up that is causing it not to properly mark the
gateway,
or more likely, not remember the mark. But I can't spot
anything in
the dispatcher documentation that says as such.
your guess is right - dispatcher module uses AVPs to keep
the state
(between sequential tries on the same dialog).
I guess the ds_mark_dst() fails - can you check this?
(this function
search for the dst and grp avps to identify the last tried
destination.).
Greetings Bogdan, and thanks as always;
I tried this:
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd (marking as bad)\n );
if (!ds_mark_dst(p)) {
xlog(L_NOTICE, [$Tf] Panic! Not
marked\n);
}
}
No 'Panic' in the logs.
The dst and grp AVPs are set up, as you saw on my original post,
but... that doesn't mean I'm not missing anything.
So, ds_mark does not fail .
Are you 100% sure your script does define the cnt grp dst avp
params for the dispatcher module
Unless somehow I'm doing it wrong, pretty sure:
# Set up the dispatcher
modparam(dispatcher, db_url,
mysql://openser:passw...@192.168.0.20/company
http://openser:passw...@192.168.0.20/company)
modparam(dispatcher, table_name, dispatcher)
modparam(dispatcher, flags, 2 )
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, grp_avp, $avp(i:272))
modparam(dispatcher, cnt_avp, $avp(i:273))
modparam(dispatcher, ds_ping_method, OPTIONS)
modparam(dispatcher, ds_ping_interval, 5)
modparam(dispatcher, ds_ping_from, sip:+1410...@192.168.0.2
mailto:sip%3a%2b1410...@192.168.0.2)
modparam(dispatcher, ds_probing_threshhold, 3)
As far as I can tell from the documentation and other people's
examples, this should be all that is required to make this function...
Could you check and be sure the error:
ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
comes from the ds_mark_dst() ? - put some logs before and after it. Also
eabling full debug (level 4) may also help.
Regards,
Bogdan
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Transport follow up
I did, but I don't see anything that says it would be a violation of SIP to try a number of transports in sequence, and to determine that sequence by the proxy. And I do understand that this is not a problem with OpenSIPS, just trying to find a way to accomplish something new perhaps. We are working with some other networks which use a different method of selecting transport. And we are trying to implement a similar method to select transport using OpenSIPS. Very similar to how route advancing works, but at the transport level. I am working now to do it at the scripting level, but just thought this might be something to consider actually implementing as functionality at the application level. Perhaps it is just too unique of a problem and not worth it. The problem I believe is UDP is clearly the most commonly used transport, but as devices get more capable (for example in our situation with large SDPs for video, and traversing multiple proxies adding record routes), packet sizes get larger, and TCP becomes a more reliable transport. Additionally many folks we work with would prefer that is a secure connection is available, then it should be used. So the defaults on their network proxies will attempt in the order of TLS, TCP then UDP to place a call. I will continue my work to try to get this going, but thought I would post for comments here to get thoughts on the matter, or recommendations on how this would be best implemented using OpenSIPS. Thanks. -dg On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi Daniel, Have you read RFC3263 about Locating SIP Servers (with proto selection) ? http://www.ietf.org/rfc/rfc3263.txt Regards, Bogdan Daniel Goepp wrote: I had a previous question regarding default transport, and the response I got was that the RFC says the order should be UDP, TCP then TLS. However after reading into this further (and some recent experiences with other platforms) I'm wondering if I have a new feature request for OpenSIPS. From the RFC 3263 - Section 4.1 Selecting a Transport Protocol, I read it as saying: 1. If specified in the RURI it SHOULD use this (but doesn't have to) 2. Bunch of stuff on NAPTR (which we are not doing) 3. The section related to what we are doing: -clip- If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier _sip for SIP URIs and _sips for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record. If no SRV records are found, the client SHOULD use TCP for a SIPS URI, and UDP for a SIP URI. However, another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU. -clip- The way I read this is that OpenSIPS MAY select whatever transport it likes, and if no DNS SRV is found, then it would default to using UDP first for SIP. But in our set, DNS SRV does exist, and there are both TCP and UDP records. We would like to decide the default transport order to use, starting with TLS then TCP then UDP. I think I can try to write something in the script to do this, but I'm not sure yet. I don't want to rewrite the RURI, I just want to specify the transport. It would be great if there was a global variable defined in the config that was something like transport_order=TLS,TCP,UDP Thoughts? -dg ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ 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 Control Panel - Statistics Monitor - Statistics Charts
Alex I can fix this issue Thanks for your help I made the following change according your recommendation chown www-data:www-data /var/www/opensips-cp/web/tools/system/smonitor/generated -R /var/www/opensips-cp/web/tools/system/smonitor/generated# ls -al total 32 drwxr-xr-x 2 www-data www-data 4096 2010-04-15 08:40 . drwxr-xr-x 7 root root 4096 2010-03-08 12:54 .. -rw-r--r-- 1 www-data www-data 5664 2010-04-15 08:40 core:bad_msg_hdr.png -rw-r--r-- 1 www-data www-data 5700 2010-04-15 08:40 core:bad_URIs_rcvd.png -rw-r--r-- 1 www-data www-data 5312 2010-04-15 08:40 core:drop_replies.png Thanks Erick Ch. From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu Sent: Thursday, April 15, 2010 3:01 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Opensips Control Panel - Statistics Monitor - Statistics Charts Hi Erick, I think I have a solution for you problem. You need to give apache/httpd write permissions on the folder ../opensips-cp/web/tools/system/smonitor/generated This is because apache is trying to create a png file in that folder. Let me know if you succeeded. Regards, Alex On 4/14/2010 22:46, Erick Chinchilla Berrocal wrote: agepng($this-img, $fileName); /var/www/opensips-cp/web/tools/system/smonitor/lib/libchart/classes/view/plo t# vim Plot.php please let me know what is the procedure for fix the problem Thanks -- Alex Ionescu www.voice-system.ro __ Information from ESET NOD32 Antivirus, version of virus signature database 3997 (20090409) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2B No TO TAG found
Antonio Anderson Souza wrote: Hi, I have on doubt, my scenario I have a SIP-Phone A that calls a SIP-Phone B establish the calls, after some time the SIP-Phone B send a Refer with Refer-To header pointing to a SIP-Phone C, the call scenario is working properly, except that the Invite generated by the B2B scenario to transfer the call to the SIP-Phone C is generated with the SIP-Phone B as From, so to the SIP-Phone C seams that the SIP-Phone B are calling him, but who is calling is SIP-Phone A. There are some way to change this behavior in the B2B call scenario, or Can i use the UAC module in the script to replace the From header? Regards, Antonio Anderson Souza Voice Technology http://www.antonioams.com Hi Antonio, I have just committed a fix. Can you please update and test? Regards, -- Anca Vamanu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Transport follow up
Daniel, So, the transport to be used is chosen as follows: A) if transport in URI - use it B) if no port in URI, try to use NAPTR B1) if NAPTR - use the advertised protocols as per weight and priority in NAPTR records (in the given order) B2) if no NAPTR - it is up to the proxy to choose the protocol (obeying the URI scheme, like sips). I guess you are referring to B2 case, which you can do in script, using a serial forking scenario (forcing different protos via $du ). Regards, Bogdan Daniel Goepp wrote: I did, but I don't see anything that says it would be a violation of SIP to try a number of transports in sequence, and to determine that sequence by the proxy. And I do understand that this is not a problem with OpenSIPS, just trying to find a way to accomplish something new perhaps. We are working with some other networks which use a different method of selecting transport. And we are trying to implement a similar method to select transport using OpenSIPS. Very similar to how route advancing works, but at the transport level. I am working now to do it at the scripting level, but just thought this might be something to consider actually implementing as functionality at the application level. Perhaps it is just too unique of a problem and not worth it. The problem I believe is UDP is clearly the most commonly used transport, but as devices get more capable (for example in our situation with large SDPs for video, and traversing multiple proxies adding record routes), packet sizes get larger, and TCP becomes a more reliable transport. Additionally many folks we work with would prefer that is a secure connection is available, then it should be used. So the defaults on their network proxies will attempt in the order of TLS, TCP then UDP to place a call. I will continue my work to try to get this going, but thought I would post for comments here to get thoughts on the matter, or recommendations on how this would be best implemented using OpenSIPS. Thanks. -dg On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi Daniel, Have you read RFC3263 about Locating SIP Servers (with proto selection) ? http://www.ietf.org/rfc/rfc3263.txt Regards, Bogdan Daniel Goepp wrote: I had a previous question regarding default transport, and the response I got was that the RFC says the order should be UDP, TCP then TLS. However after reading into this further (and some recent experiences with other platforms) I'm wondering if I have a new feature request for OpenSIPS. From the RFC 3263 - Section 4.1 Selecting a Transport Protocol, I read it as saying: 1. If specified in the RURI it SHOULD use this (but doesn't have to) 2. Bunch of stuff on NAPTR (which we are not doing) 3. The section related to what we are doing: -clip- If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier _sip for SIP URIs and _sips for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record. If no SRV records are found, the client SHOULD use TCP for a SIPS URI, and UDP for a SIP URI. However, another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU. -clip- The way I read this is that OpenSIPS MAY select whatever transport it likes, and if no DNS SRV is found, then it would default to using UDP first for SIP. But in our set, DNS SRV does exist, and there are both TCP and UDP records. We would like to decide the default transport order to use, starting with TLS then TCP then UDP. I think I can try to write something in the script to do this, but I'm not sure yet. I don't want to rewrite the RURI, I just want to specify the transport. It would be great if there was a global variable defined in the config that was something like transport_order=TLS,TCP,UDP Thoughts? -dg ___ Users mailing list Users@lists.opensips.org
Re: [OpenSIPS-Users] Transport follow up
If NAPTR was the method being used, but in this case is not setup. So the problem I'm trying to solve is what to do when the endpoints and the other gateways are not being explicit via either URI or DNS. The endpoint is not specifying transport in the RURI, and DNS SRV is setup and exists with entries for both TCP and UDP, but no NAPTR. In this case, it's really leaving it up to the proxy to decide what transport to prefer. -dg On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Daniel, So, the transport to be used is chosen as follows: A) if transport in URI - use it B) if no port in URI, try to use NAPTR B1) if NAPTR - use the advertised protocols as per weight and priority in NAPTR records (in the given order) B2) if no NAPTR - it is up to the proxy to choose the protocol (obeying the URI scheme, like sips). I guess you are referring to B2 case, which you can do in script, using a serial forking scenario (forcing different protos via $du ). Regards, Bogdan Daniel Goepp wrote: I did, but I don't see anything that says it would be a violation of SIP to try a number of transports in sequence, and to determine that sequence by the proxy. And I do understand that this is not a problem with OpenSIPS, just trying to find a way to accomplish something new perhaps. We are working with some other networks which use a different method of selecting transport. And we are trying to implement a similar method to select transport using OpenSIPS. Very similar to how route advancing works, but at the transport level. I am working now to do it at the scripting level, but just thought this might be something to consider actually implementing as functionality at the application level. Perhaps it is just too unique of a problem and not worth it. The problem I believe is UDP is clearly the most commonly used transport, but as devices get more capable (for example in our situation with large SDPs for video, and traversing multiple proxies adding record routes), packet sizes get larger, and TCP becomes a more reliable transport. Additionally many folks we work with would prefer that is a secure connection is available, then it should be used. So the defaults on their network proxies will attempt in the order of TLS, TCP then UDP to place a call. I will continue my work to try to get this going, but thought I would post for comments here to get thoughts on the matter, or recommendations on how this would be best implemented using OpenSIPS. Thanks. -dg On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi Daniel, Have you read RFC3263 about Locating SIP Servers (with proto selection) ? http://www.ietf.org/rfc/rfc3263.txt Regards, Bogdan Daniel Goepp wrote: I had a previous question regarding default transport, and the response I got was that the RFC says the order should be UDP, TCP then TLS. However after reading into this further (and some recent experiences with other platforms) I'm wondering if I have a new feature request for OpenSIPS. From the RFC 3263 - Section 4.1 Selecting a Transport Protocol, I read it as saying: 1. If specified in the RURI it SHOULD use this (but doesn't have to) 2. Bunch of stuff on NAPTR (which we are not doing) 3. The section related to what we are doing: -clip- If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier _sip for SIP URIs and _sips for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record. If no SRV records are found, the client SHOULD use TCP for a SIPS URI, and UDP for a SIP URI. However, another transport protocol, such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU. -clip- The way I read this is that OpenSIPS MAY select whatever transport it likes, and if no DNS SRV is found, then it would default to using UDP first for SIP. But in our set, DNS SRV does exist, and there are both TCP and UDP records. We would like to decide the default transport order to use,
Re: [OpenSIPS-Users] Transport follow up
exactly, and you can configure in opensips cfg whatever sequence of protocols to be tried (by doing serial forking). Regards, Bogdan Daniel Goepp wrote: If NAPTR was the method being used, but in this case is not setup. So the problem I'm trying to solve is what to do when the endpoints and the other gateways are not being explicit via either URI or DNS. The endpoint is not specifying transport in the RURI, and DNS SRV is setup and exists with entries for both TCP and UDP, but no NAPTR. In this case, it's really leaving it up to the proxy to decide what transport to prefer. -dg On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Daniel, So, the transport to be used is chosen as follows: A) if transport in URI - use it B) if no port in URI, try to use NAPTR B1) if NAPTR - use the advertised protocols as per weight and priority in NAPTR records (in the given order) B2) if no NAPTR - it is up to the proxy to choose the protocol (obeying the URI scheme, like sips). I guess you are referring to B2 case, which you can do in script, using a serial forking scenario (forcing different protos via $du ). Regards, Bogdan Daniel Goepp wrote: I did, but I don't see anything that says it would be a violation of SIP to try a number of transports in sequence, and to determine that sequence by the proxy. And I do understand that this is not a problem with OpenSIPS, just trying to find a way to accomplish something new perhaps. We are working with some other networks which use a different method of selecting transport. And we are trying to implement a similar method to select transport using OpenSIPS. Very similar to how route advancing works, but at the transport level. I am working now to do it at the scripting level, but just thought this might be something to consider actually implementing as functionality at the application level. Perhaps it is just too unique of a problem and not worth it. The problem I believe is UDP is clearly the most commonly used transport, but as devices get more capable (for example in our situation with large SDPs for video, and traversing multiple proxies adding record routes), packet sizes get larger, and TCP becomes a more reliable transport. Additionally many folks we work with would prefer that is a secure connection is available, then it should be used. So the defaults on their network proxies will attempt in the order of TLS, TCP then UDP to place a call. I will continue my work to try to get this going, but thought I would post for comments here to get thoughts on the matter, or recommendations on how this would be best implemented using OpenSIPS. Thanks. -dg On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro wrote: Hi Daniel, Have you read RFC3263 about Locating SIP Servers (with proto selection) ? http://www.ietf.org/rfc/rfc3263.txt Regards, Bogdan Daniel Goepp wrote: I had a previous question regarding default transport, and the response I got was that the RFC says the order should be UDP, TCP then TLS. However after reading into this further (and some recent experiences with other platforms) I'm wondering if I have a new feature request for OpenSIPS. From the RFC 3263 - Section 4.1 Selecting a Transport Protocol, I read it as saying: 1. If specified in the RURI it SHOULD use this (but doesn't have to) 2. Bunch of stuff on NAPTR (which we are not doing) 3. The section related to what we are doing: -clip- If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier _sip for SIP URIs and _sips for SIPS URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose the most preferred record. If no
Re: [OpenSIPS-Users] Transport follow up
Okay, thanks for the info, I will try serial forking. As per one of the
previous threads regarding this, one of the ways recommended to force a
transport was to tag the RURI, for example:
if($rd=proxy.othercompany.com){
$rd = proxy.othercompany.com;transport=TCP;
}
Although this does seem to force the transport, I'm having some troubles
with media getting setup when I do this. Is this the method you would
recommend, or do you have a better way to force a specific transport?
Thanks
-dg
On Thu, Apr 15, 2010 at 9:02 AM, Bogdan-Andrei Iancu bog...@voice-system.ro
wrote:
exactly, and you can configure in opensips cfg whatever sequence of
protocols to be tried (by doing serial forking).
Regards,
Bogdan
Daniel Goepp wrote:
If NAPTR was the method being used, but in this case is not setup. So
the problem I'm trying to solve is what to do when the endpoints and
the other gateways are not being explicit via either URI or DNS. The
endpoint is not specifying transport in the RURI, and DNS SRV is setup
and exists with entries for both TCP and UDP, but no NAPTR. In this
case, it's really leaving it up to the proxy to decide what transport
to prefer.
-dg
On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
Daniel,
So, the transport to be used is chosen as follows:
A) if transport in URI - use it
B) if no port in URI, try to use NAPTR
B1) if NAPTR - use the advertised protocols as per weight and
priority in NAPTR records (in the given order)
B2) if no NAPTR - it is up to the proxy to choose the protocol
(obeying the URI scheme, like sips).
I guess you are referring to B2 case, which you can do in script,
using
a serial forking scenario (forcing different protos via $du ).
Regards,
Bogdan
Daniel Goepp wrote:
I did, but I don't see anything that says it would be a violation
of
SIP to try a number of transports in sequence, and to determine
that
sequence by the proxy. And I do understand that this is not a
problem
with OpenSIPS, just trying to find a way to accomplish something
new
perhaps. We are working with some other networks which use a
different method of selecting transport. And we are trying to
implement a similar method to select transport using OpenSIPS.
Very
similar to how route advancing works, but at the transport level.
I
am working now to do it at the scripting level, but just thought
this
might be something to consider actually implementing as
functionality
at the application level. Perhaps it is just too unique of a
problem
and not worth it. The problem I believe is UDP is clearly the most
commonly used transport, but as devices get more capable (for
example
in our situation with large SDPs for video, and traversing multiple
proxies adding record routes), packet sizes get larger, and TCP
becomes a more reliable transport. Additionally many folks we work
with would prefer that is a secure connection is available, then it
should be used. So the defaults on their network proxies will
attempt
in the order of TLS, TCP then UDP to place a call.
I will continue my work to try to get this going, but thought I
would
post for comments here to get thoughts on the matter, or
recommendations on how this would be best implemented using
OpenSIPS.
Thanks.
-dg
On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro
mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro
wrote:
Hi Daniel,
Have you read RFC3263 about Locating SIP Servers (with proto
selection) ?
http://www.ietf.org/rfc/rfc3263.txt
Regards,
Bogdan
Daniel Goepp wrote:
I had a previous question regarding default transport, and
the
response I got was that the RFC says the order should be UDP,
TCP then
TLS. However after reading into this further (and some
recent
experiences with other platforms) I'm wondering if I have
a new
feature request for OpenSIPS. From the RFC 3263 -
Section 4.1
Selecting a Transport Protocol, I read it as saying:
1. If specified in the RURI it SHOULD use this (but doesn't
have to)
2. Bunch of stuff on NAPTR (which we are not doing)
3. The section related to what we are doing:
-clip-
If no NAPTR records are found, the client constructs
Re: [OpenSIPS-Users] One dispatcher mystery solved; Doesn't seem to be remembering a gateway is failed however
On Thu, Apr 15, 2010 at 8:41 AM, Bogdan-Andrei Iancu bog...@voice-system.ro
wrote:
Jock McKechnie wrote:
On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro wrote:
Hi Jock,
Jock McKechnie wrote:
On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro mailto:bog...@voice-system.ro
mailto:bog...@voice-system.ro mailto:bog...@voice-system.ro
wrote:
Hi Jock,
I'm wondering if the above error is some kind of AVP
storage thing I
haven't set up that is causing it not to properly mark the
gateway,
or more likely, not remember the mark. But I can't spot
anything in
the dispatcher documentation that says as such.
your guess is right - dispatcher module uses AVPs to keep
the state
(between sequential tries on the same dialog).
I guess the ds_mark_dst() fails - can you check this?
(this function
search for the dst and grp avps to identify the last tried
destination.).
Greetings Bogdan, and thanks as always;
I tried this:
if( t_check_status(408) ){
xlog( L_NOTICE, [$Tf] FR: $ci -- TIMEOUT for
Gateway $rd (marking as bad)\n );
if (!ds_mark_dst(p)) {
xlog(L_NOTICE, [$Tf] Panic! Not
marked\n);
}
}
No 'Panic' in the logs.
The dst and grp AVPs are set up, as you saw on my original post,
but... that doesn't mean I'm not missing anything.
So, ds_mark does not fail .
Are you 100% sure your script does define the cnt grp dst avp
params for the dispatcher module
Unless somehow I'm doing it wrong, pretty sure:
# Set up the dispatcher
modparam(dispatcher, db_url,
mysql://openser:passw...@192.168.0.20/company
http://openser:passw...@192.168.0.20/company)
modparam(dispatcher, table_name, dispatcher)
modparam(dispatcher, flags, 2 )
modparam(dispatcher, dst_avp, $avp(i:271))
modparam(dispatcher, grp_avp, $avp(i:272))
modparam(dispatcher, cnt_avp, $avp(i:273))
modparam(dispatcher, ds_ping_method, OPTIONS)
modparam(dispatcher, ds_ping_interval, 5)
modparam(dispatcher, ds_ping_from,
sip:+1410...@192.168.0.2sip%3a%2b1410...@192.168.0.2
mailto:sip%3a%2b1410...@192.168.0.2sip%253a%252b1410...@192.168.0.2
)
modparam(dispatcher, ds_probing_threshhold, 3)
As far as I can tell from the documentation and other people's
examples, this should be all that is required to make this function...
Could you check and be sure the error:
ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
comes from the ds_mark_dst() ? - put some logs before and after it. Also
eabling full debug (level 4) may also help.
My apologies, Bogdan, I should have done this better myself. I have traced
the error to the ds_next_domain():
Config section from inside failure_route[]:
xlog(L_NOTICE, [$Tf] HEREA\n);
if (ds_next_domain()) {
xlog(L_NOTICE, [$Tf] HEREB\n);
.
.
The logs contain:
[Thu Apr 15 11:23:06 2010] HEREA
ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
DBG:dispatcher:ds_next_dst: using [sip:192.168.0.20:5060]
[Thu Apr 15 11:23:06 2010] HEREB
So clearly the ds_next_domain() is producing it. However the function -is-
returning the correct next entry in the dispatcher list, which is bizarre.
I'm not sure, now, how this related to ds_select_domain() incorrectly
choosing marked entries, alas.
Cheers;
- Jock
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2B No TO TAG found
Dear Anca, I just tested it, and it's working perfectly! Thank you very much for your support, Antonio Anderson Souza Voice Technology http://www.antonioams.com On Thu, Apr 15, 2010 at 12:17 PM, Anca Vamanu a...@opensips.org wrote: Antonio Anderson Souza wrote: Hi, I have on doubt, my scenario I have a SIP-Phone A that calls a SIP-Phone B establish the calls, after some time the SIP-Phone B send a Refer with Refer-To header pointing to a SIP-Phone C, the call scenario is working properly, except that the Invite generated by the B2B scenario to transfer the call to the SIP-Phone C is generated with the SIP-Phone B as From, so to the SIP-Phone C seams that the SIP-Phone B are calling him, but who is calling is SIP-Phone A. There are some way to change this behavior in the B2B call scenario, or Can i use the UAC module in the script to replace the From header? Regards, Antonio Anderson Souza Voice Technology http://www.antonioams.com Hi Antonio, I have just committed a fix. Can you please update and test? Regards, -- Anca Vamanu www.voice-system.ro ___ 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] Permissions module database
Hi, I'd like to know if it's possible to have the allow and deny rules in a database table instead of in files, Can I use the address table to make the permissions based on the FROM and RURI rules? Best regards, Antonio Anderson Souza Voice Technology http://www.antonioams.com ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Permissions module database
You should be able to.. Check out: http://www.opensips.org/html/docs/modules/1.6.x/permissions.html#id271903 On Thu, Apr 15, 2010 at 1:41 PM, Antonio Anderson Souza anto...@voicetechnology.com.br wrote: Hi, I'd like to know if it's possible to have the allow and deny rules in a database table instead of in files, Can I use the address table to make the permissions based on the FROM and RURI rules? Best regards, Antonio Anderson Souza Voice Technology http://www.antonioams.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
