[OpenSIPS-Users] B2BUA and SBC - Best practice
Hi all, I'm designing a new VoIP platform in which transcoding and prepaid features must be provided. One essential component of the architecture will be a b2bua, but I'm wondering about where it should be deployed. In detail, I'm thinking about a standard architecture (opensips + mediaproxy) with a b2bua (freeswitch) used for media transcoding, prepaid, topology hiding and media services. What is the best practice in this case? I could design the architecture in two ways: 1) UsersProviders/PSTN || || Opensips/Mediaproxy == B2BUA (here opensips/mediaproxy+B2BUA acts as a whole SBC) 2) UsersProviders/PSTN |||| B2BUA || Opensips/Mediaproxy (here the B2BUA should works also as SBC and could do protocol interworking (es h323) but which component should authenticate/authorize the users? I would like to handle all subscribers just in opensips) If I use a b2bua for all sessions, do I still require a media proxy for nat traversal? Thanks for your hints. Best Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Osipsconsole and XMLRPC support
Il 29/06/11 14.40, Mike Tesliuk ha scritto: you can use the perl to do this, take a look on the link below http://search.cpan.org/~rdietrich/xmlrpc-pureperl-0.03/lib/XMLRPC/PurePerl.pm http://search.cpan.org/%7Erdietrich/xmlrpc-pureperl-0.03/lib/XMLRPC/PurePerl.pm take a look on mi_xmlrpc module documentation too http://www.opensips.org/html/docs/modules/1.6.x/mi_xmlrpc.html you can read about php ripcord lib too or php-xmlrpc http://code.google.com/p/ripcord/wiki/RipcordClientManual http://phpxmlrpc.sourceforge.net/ dont forget to protect your xmlprc port on firewall Hi Mike, thanks. I know there are xmlrpc libraries that I could use. But I would like to know if there is an XMLRPC support from osipsconsole/opensipsCP, or otherwise what is the best way to remotely provision the Opensips infrastructure. I think the mi_xmlrpc module is suited just for read/reload/get_statistics actions (and not for database interaction). Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Osipsconsole and XMLRPC support
Hi All, I'm wondering if last osipconsole version has XMLRPC support. I would like to do user provisioning (add user, add aliases,...) from a different machine than Opensips and with osipsconsole I shouldn't care of database changes. If not, what could be the best option to manage Opensips database? Best regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence for routing logic
Il 17/02/11 17.57, Anca Vamanu ha scritto: XCAP server does not store the published presence state, but only a permanent state - through pidf manipulation (RFC 4827) ( not sure though what clients support this). So in fact for your design, you should maybe query the published state in presence server and also check if the user has some default state set in XCAP server. One of our development projects this year will be add an event notification interface to OpenSIPS. And presence status change events will also be included. It will be announced soon, stay tuned :) . Then it will be possible to have an external application that will be notified when a status change occurs for a user, maybe also say which was the previous status. And your external application can do anything with it - insert/delete a row usr_preferences for example. HI Anca, thank you for the explanation. I'm waiting for the event notification interface, which seems very interesting for this purpose. In the meanwhile I'll take a deeper dive into all needed presence components and actions required. Best Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence for routing logic
Il 16/02/11 18.19, Anca Vamanu ha scritto: Hi Carlo, Here are my ideas about this. One solution would be to insert into usr_preferences table a record with the URI where the call must be forwarded for the user (you can put the username in RURI) when the presence status is meeting, holiday, etc. And delete it when changes into something else. Now the question is where to do this. In the OpenSIPS script is very hard - you have to make regexps to extract the status from the Publish body, select from database the previous stored state and apply the regexp again, very inefficient. The other solutions are an external application or an opensips module. The external application could query the presentity table periodically or maybe be called by a trigger at insert ( not sure this is possible). The module can export a function to be called before handle_publish to analyze the previous and the current state. Then when handling Invites - do avp_db_load for the caller and if a record is found forward it to that URI. Hi Anca, thank you for your interesting point of view. Indeed I was thinking about the development of a new presence module (or a function) but for checking the subscriber status directly from the XCAP server. In this way in the script (INVITE) I should do xcap_check_status for the callee, do an avp_db_load and forward the caller to the URI stored in usr_preferences (linked to the presence status). This is just a proof of concept, as I need a better understanding of all opensips presence modules. Best regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence for routing logic
Il 16/02/11 18.34, Adrian Georgescu ha scritto: Hi Carlo, Such powerful feature would deserve some module of its own. Routing based on end-user provided preferences using presence is something fresh and cool nobody has tried it before. Make something that uses published presence and xcap policy in a meaningful way for the end-user! Hi Adrian, happy that you share my idea :) I think this feature will be interesting and we want to implement in the best way. An UC system with end-user provided preferences and the one-number reach (in italy we have a nomadic number - prefix 55) is really cool and flexible. As I said to Anca, an interesting way could be a function that check the presence status directly from the xcap server. Is this a feasible solution? What could be the changes needed? Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence for routing logic
Il 17/02/11 10.56, Adrian Georgescu ha scritto: Carlo, You should check the aggregated PIDF published by SIP UAs in the presence module and if none is online you should check the pidf-manipulation XCAP document that contains the same data for when clients are not online. Hi Adrian, you are talking about a new module/function that checks the PIDF information? Or the opensips presence module? Blink wil publish soon this information and you can play with it also from the client side. it is a way to request PIDF information of another user from a Blink API? Regards ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Presence for routing logic
Dear all, I'm thinking about a design of an unified communication system based on presence status. I would like to know if the presence status of a subscriber could be used to define the routing logic. An example is routing the call to voicemail when Alice's status is meeting or to a cell phone when she is on holiday. Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] CDRTool and opensips 1.6
Hello Ag-projects Team, I would like to know if the next version of CDRTool will be fully- compatible with opensips 1.6. In a test environment I have CDRTool 7.0.2 and the following error (because opensips 1.6 doesn't use anymore the trusted table): Database DB_opensips error: Table 'opensips.trusted' doesn't exist (1146) select * from trusted Do you think that this is the only problem (I can ignore it) or there are other hidden incompatibilities? Thanks and Best regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool and opensips 1.6
Il giorno 01/apr/10, alle ore 12:02, Saúl Ibarra Corretgé ha scritto: You need to create a MySQL view to 'emulate' the trusted table: [...] PS: The view was suggested by Jeff Pyle IIRC :) Ok very good! Thank you Saúl and Jeff :) Best regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Push notifications to users
Hello all! I'm thinking about a nice service in order to send a push notification to users when there is, for example, a missed call (when the device is not logged in) or a new message in the voicemail (like the iphone skype/facebook notification). Do you have any experience on this? Could you share any useful link? I would like to know what protocols, technologies should be involved in this process. Thank you. Best Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Push notifications to users
Il giorno 11/feb/10, alle ore 17:42, Bogdan-Andrei Iancu ha scritto: Hi Carlo, and this notification should be a message or a presence notification? Hi Bogdan, it could be a message (like: You have a new voicemail message), but honestly I don't know if a presence notification could have better features. Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call-control exception with custom scenario
Hi all, I'm experiencing with a Call Control exception and a custom scenario: - User 1...@domain1.sip.xxx.it calls number 00390832097193 (dbaliased to 65310...@domain2.sip.xxx.it) - 65310...@domain2.sip.xxx.it has a call redirect to 1...@domain1.sip.xxx.it - Finally 1...@domain1.sip.xxx.it calls user 1...@domain1.sip.xxx.it - The billing party is 65310...@domain2.sip.xxx.it (the problem arise either with postpaid or prepaid) My syslog shows: Call control log: Nov 6 10:15:55 sip call-control[2657]: Call id 35436eb2766e5f7f of 1...@domain1.sip.xxx.it to sip:1...@domain1.sip.xxx.it is postpaid not limited Nov 6 10:15:55 sip call-control[2657]: error: Unhandled error in Deferred: Nov 6 10:15:55 sip call-control[2657]: Traceback (most recent call last): Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/python2.5/ site-packages/twisted/internet/defer.py, line 328, in _runCallbacks Nov 6 10:15:55 sip call-control[2657]: self.result = callback(self.result, *args, **kw) Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/pymodules/ python2.5/callcontrol/sip.py, line 185, in _setup_finish_calllimit Nov 6 10:15:55 sip call-control[2657]: deferred.callback(None) Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/python2.5/ site-packages/twisted/internet/defer.py, line 243, in callback Nov 6 10:15:55 sip call-control[2657]: self._startRunCallbacks(result) Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/python2.5/ site-packages/twisted/internet/defer.py, line 312, in _startRunCallbacks Nov 6 10:15:55 sip call-control[2657]: self._runCallbacks() Nov 6 10:15:55 sip call-control[2657]: --- exception caught here --- Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/python2.5/ site-packages/twisted/internet/defer.py, line 328, in _runCallbacks Nov 6 10:15:55 sip call-control[2657]: self.result = callback(self.result, *args, **kw) Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/pymodules/ python2.5/callcontrol/controller.py, line 206, in _CC_finish_init Nov 6 10:15:55 sip call-control[2657]: self.factory.application.clean_call(req.callid) Nov 6 10:15:55 sip call-control[2657]: File /usr/lib/pymodules/ python2.5/callcontrol/controller.py, line 303, in clean_call Nov 6 10:15:55 sip call-control[2657]: except valueError: Nov 6 10:15:55 sip call-control[2657]: exceptions.NameError: global name 'valueError' is not defined Cdrtool log: Nov 6 10:15:55 mproxy1 cdrtool[10373]: DebitBalance Duration=0 CallId=35436eb2766e5f7f From=sip:1...@domain1.sip.xxx.it Gateway=10.0.6.32 To=sip:00390832097...@domain1.sip.xxx.it:5060 Nov 6 10:15:55 mproxy1 cdrtool[10373]: MaxSessionTime Duration=36000 CallId=35436eb2766e5f7f From=sip:65310...@domain2.sip.xxx.it Gateway=10.0.6.32 To=sip:1...@domain1.sip.xxx.it What can be tha cause for this exception? In other cases all the process is ok... Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Registration - strange behaviour
Hi all, I have a natted ATA that is trying to register to my opensips. The registration comes from a port different from the standard 5060. The problem is that the opensips reply to the 5060 and not to the receiving port (45900). I don't understand this behaviour U 200.200.200.200:45900 - IP_OPENSIPS:5060 REGISTER sip:sip.xxx.it SIP/2.0. Via: SIP/2.0/UDP 192.168.2.100;branch=z9hG4bK-fe05a550. From: SPAFax1004 sip:1...@sip.xxx.it;tag=b7441aad8d759152o0. To: SPAFax1004 sip:1...@sip.xxx.it. Call-ID: 300b52dc-49189...@192.168.2.100. CSeq: 3028 REGISTER. Max-Forwards: 70. Contact: SPAFax1004 sip:1...@192.168.2.100;expires=3600. User-Agent: Linksys/SPA2102-5.2.10. Content-Length: 0. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura, replaces. . # U IP_OPENSIPS:5060 - 200.200.200.200:5060- should be 45900?? SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.2.100;branch=z9hG4bK- fe05a550;received=200.200.200.200. From: SPAFax1004 sip:1...@sip.xxx.it;tag=b7441aad8d759152o0. To: SPAFax1004 sip: 1...@sip.xxx.it;tag=c97b4d1cb1f3d0da549e06a8d482ef63.29be. Call-ID: 300b52dc-49189...@192.168.2.100. CSeq: 3028 REGISTER. WWW-Authenticate: Digest realm=sip.xxx.it, nonce=4ae82d7205d60d2de8569cda129f11de143bdaf8a3b7, qop=auth. Server: VoIP SIPServer. Content-Length: 0. What could be the problem? Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Multi-domain and reinvite authentications
Il giorno 26/ott/09, alle ore 17:27, Iñaki Baz Castillo ha scritto: El Lunes, 26 de Octubre de 2009, Carlo Dimaggio escribió: Is there a better implementation? Yes, don't ask for authentication for a re-INVITE :) Hi Iñaki, Is this the right implementation or a workaround? (in Flavio Goncalves' book I see the authentication of re-invites...) There could be a security issue without this authentication? (for example a custom packet with a fake to_tag and a route header? Thanks ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Multi-domain and reinvite authentications
Il giorno 27/ott/09, alle ore 09:43, Thomas Gelf ha scritto: [...] Attacks could be a little bit easier if your UAC does not check all components for correctness. To protect your clients against such attacks, you could use the dialog module (ignoring the fact that a proxy should not do so ;-)) and it's validate_dialog() function. Thanks, I understand... Now I cannot use this function because I have a 1.5 opensips installation. When I'll migrate to 1.6, I'll use the validate_dialog() function, that is very interesting for this purpose... Best regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Multi-domain and reinvite authentications
Hi all,
I have a problem with an ITSP interconnection and my multi-domain
opensips. Here my scenario:
ITSP - my opensips (IP: 123.123.123.123) - ATA SPA2102 (u...@domaina.com
)
When I receive a call to one of my numbers (for example ), the
ITSP send me the INVITE always with the TO header 5...@123.123.123.123
(the ATA has registered with u...@domaina.com).
I have an alias_db configured from 5...@123.123.123.123 to u...@domaina.com
.
The problem arises when the ATA switch to T38 with a Reinvite (the
From header now is 5...@123.123.123.123): the opensips asks to a
proxy_authorize(,subscriber) with realm=123.123.123.123 and the
ATA reply with auth u...@123.123.123, but this user is invalid (it
should be u...@domaina.com...):
if (loose_route()) {
#Check authentication of re-invites
if(method==INVITE (!allow_trusted())) {
xlog (L_INFO, Re-Invite - M=$rm RURI=$ru F=$fu T=
$tu IP=$si ID=$ci\n);
if !(is_from_gw()) {
if (!proxy_authorize(,subscriber)) {
[...]
I would like to know what could be the right behaviour for the proxy,
I know that rewriting of the (first) TO header is not RFC-compliant...
Should I store the domain aliased (domainA.com) and use it as variable
to proxy_authorize?
Is there a better implementation?
Thanks and regards,
Carlo Dimaggio
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CallControl - CDRTool : MySQL server has gone away (2006)
Il giorno 24/lug/09, alle ore 15:02, Adrian Georgescu ha scritto: If you lower the mysql connection timeout to a a few minutes you will see in syslog that the software is able to reconnect correctly in case of 2006 or 2013. But I have seen this myself too, randomly it fails and though the error code is intercepted in mysql connection library used by cdrtool (in db_mysql.inc) sometimes it still does not work as expected and could not trace the reason how it can do this. Maybe you can inspect that code add some debugging statements to it and find the culprit. Hi Adrian, I took your mail of last july because I'm experiencing with the same problems. After the mysql timeout (8 hours), cdrtool doesn't reconnect to mysql: Database error for query 'select * from prepaid where account = '1...@sip.xxx.it '': MySQL server has gone away (2006), link_id =Resource id #53, query_id = I think is useful to tell you that I hadn't these problems with an ubuntu 8.04 installation (now I have a lenny 64bit)... There could be something in this last installation (like some parameters in mysql config?) Do you have hints for this? Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rpid_avp and NULL values
Il giorno 22/lug/09, alle ore 11:09, Bogdan-Andrei Iancu ha scritto: Hi Carlo, you must set the line : modparam(auth_db, load_credentials, $avp(s:rpid)=rpid) This line instructs opensips to load at db auth time tht rpid field into the $avp(s:rpid) variable. Hi Bogdan, Last july I have modified the opensips.cfg adding modparam(auth_db, load_credentials, $avp(s:rpid)=rpid) and all worked. Now I have executed some test after upgrading to 1.5.3 and I'm experiencing with the same problem (if rpid field of user A is NULL, after some calls user A takes the rpid of another user B (that is not null)) In addition, user A has a different domain of user B. What do you think about this behaviour? Thanks and Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] New MediaProxy release 2.3.7
Il giorno 04/set/09, alle ore 13:34, Adrian Georgescu ha scritto: Hello, There is a new release of MediaProxy available, it contains several bug fixes. Hi Adrian, Can you provide amd64 updated packages in the ag-projects repository? (I need mediaproxy-common_2.3.7_amd64.deb) Thanks and Regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] CDRTool 6.9.1 prepaid error and info
Hi all, I have some problems in configuring CDRTool 6.9.1 (prepaid). When I try to insert a new prepaid account from the web interface I have: Database error for query insert into prepaid ( reseller_id,account,balance,session_counter,domain) values ( '0','1...@sip.example.com ','10','0',SUBSTRING_INDEX(account, '@',-1)) : Unknown column 'domain' in 'field list' (1054) Where are the fields last_call_price, destination of table prepaid? And where can I find the updated version of Rating.Txt? (I would like to have information about the meaning of new functions, prepaid_history, prepaid_cards,...) Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool 6.9.1 prepaid error and info
Il giorno 04/set/09, alle ore 18:24, Adrian Georgescu ha scritto: You probably did not read the changelog carefully and did not apply the changes from setup/mysql/alter_tables.mysql Hi Adrian, I have installed cdrtool 6.9.1 in a new system without upgrading from an old version, so I think there is no need to apply alter_tables.mysql... In the create_table.mysql of 6.9.1 I see: -- -- Table structure for table `prepaid` -- DROP TABLE IF EXISTS `prepaid`; CREATE TABLE `prepaid` ( `id` int(10) unsigned NOT NULL auto_increment, `reseller_id` int(10) unsigned not NULL, `account` varchar(255) NOT NULL default '', `balance` decimal(10,4) NOT NULL default '0.', `change_date` datetime NOT NULL default '-00-00 00:00:00', `active_sessions` text NOT NULL, `session_counter` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `reseller_idx` (`reseller_id`), UNIQUE KEY `acc_id` (`account`) ) DEFAULT CHARSET=latin1; Is there an error in this script (no column domain)? What about last_call_price, destination field? Thank you Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool 6.9.1 prepaid error and info
Il giorno 04/set/09, alle ore 18:24, Adrian Georgescu ha scritto: You probably did not read the changelog carefully and did not apply the changes from setup/mysql/alter_tables.mysql Hi Adrian, I have installed cdrtool 6.9.1 in a new system without upgrading from an old version, so I think there is no need to apply alter_tables.mysql... In the create_table.mysql of 6.9.1 I see: -- -- Table structure for table `prepaid` -- DROP TABLE IF EXISTS `prepaid`; CREATE TABLE `prepaid` ( `id` int(10) unsigned NOT NULL auto_increment, `reseller_id` int(10) unsigned not NULL, `account` varchar(255) NOT NULL default '', `balance` decimal(10,4) NOT NULL default '0.', `change_date` datetime NOT NULL default '-00-00 00:00:00', `active_sessions` text NOT NULL, `session_counter` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `reseller_idx` (`reseller_id`), UNIQUE KEY `acc_id` (`account`) ) DEFAULT CHARSET=latin1; Is there an error in this script (no column domain)? What about last_call_price, destination field? Thank you Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Upgrade version problems in a production system (mediaproxy)
Il giorno 24/lug/09, alle ore 18:13, Raúl Alexis Betancor Santana ha scritto: That's too wilde Adrian !!! ... and abosolut wrong, I don't agree at all. All the systems I run/install run Debian stable, and if I need some blending edge soft I backport it to stable. Backporting mediaproxy it's a very simple task, as it's a very simple dependency software. Hi Raúl, Can you share this task? How do you satisfy the dependencies? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Upgrade version problems in a production system (mediaproxy)
Hi all, I'm wondering about the right distribution and version for a production environment: i ask you this because of some problems in upgrading my systems. I'm using two Ubuntu 8.04 Server LTS with opensips 1.5.2, callcontrol 2.0.4, mediaproxy 2.3.4, cdrtool 6.8.1. I didn't have any error in upgrading opensips and the other softwares until now, but today I have tried to upgrade mediaproxy to 2.3.5 and I'm experienced with the old version of different packages (python-application, python-support, python-gnutls, libgnutls,...) and I am unable to install this new versions (for dependencies). My question is: how can mantain an updated production server? I have seen that an updated python-application is always needed for new versions of mediaproxy... How do you handle this process (without using an unstable/testing distribution)? Thank you and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rpid_avp and NULL values
Il giorno 20/lug/09, alle ore 19:13, Bogdan-Andrei Iancu ha scritto: Hi Carlo, yes there were some fixes in the 1.5.1 that are now available in 1.5.2. But it is rather strange what you describehow does the load_credentials param look like for you? Hi Bogdan, I have the default value for load_credentials (no param for auth_db) and modparam(auth, rpid_avp, $avp(s:rpid)). Is there any error with this config? Should I need modparam(auth_db, load_credentials, $avp(s:rpid)=rpid) instead of rpid_avp? Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rpid_avp and NULL values
Il giorno 17/lug/09, alle ore 14:46, Bogdan-Andrei Iancu ha scritto: Hi Carlo, what DB backend are you using? mysql ? Regards, Bogdan Hi Bogdan, yes Mysql. Are there some improvements in 1.5.2? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] rpid_avp and NULL values
Il giorno 10/lug/09, alle ore 12:51, Carlo Dimaggio ha scritto: Hi all, I'm using rpid column in subscriber table in order to set the display- name of the p-asserted header, but I have some problems with NULL values. In detail, I use modparam(auth, rpid_avp, $avp(s:rpid)) to load the rpid. When rpid value is NULL, the $avp(s:rpid) sometimes contains values of other subscribers (that are not NULL)... It's a strange behaviour... What can be the problem (is it possible that rpid_avp takes the rpid of another subscriber)? Hi, Nobody has the same problem? I've seen that if the rpid is not null, rpid_avp contains always the right value... Thanks ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] rpid_avp and NULL values
Hi all, I'm using rpid column in subscriber table in order to set the display- name of the p-asserted header, but I have some problems with NULL values. In detail, I use modparam(auth, rpid_avp, $avp(s:rpid)) to load the rpid. When rpid value is NULL, the $avp(s:rpid) sometimes contains values of other subscribers (that are not NULL)... It's a strange behaviour... What can be the problem (is it possible that rpid_avp takes the rpid of another subscriber)? Thanks, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] CDRTool and diverted calls
Hi all, I would like to know if CDRTool ver. 6.x supports the rating of diverted calls (I'm trying to find another way to bill a unconditional call forwarding...). In the web interface I don't find any reference to diverted calls... From an old changelog I see: 1.6 New major rating features added: - Implemented rating of diverted calls --- Can you help me understand how to configure the rating engine? Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool and diverted calls
Il giorno 24/giu/09, alle ore 11:50, Iñaki Baz Castillo ha scritto: This means that when the called replies a 302, OpenSIPS should do recursion on it, extract the Contact of the 302 and generate a new branch for it. Also it should set the AVP which will be mapped to Radius UserName field to the AoR replying the 302. Hi Iñaki, My aim is a little bit different because I want to handle a simple cfu directly from opensips (without a 302 from client). I don't understand very well how CDRTool bill the call diversion in this case (maybe is not possible?) In the opensips.cfg now I have: modparam(acc, radius_extra, User-Name=$Au; Calling-Station-Id= $from; Called-Station-Id=$to; Sip-Translated-Request-URI=$ruri; [...] Canonical-URI=$avp(s:can_uri); Billing-Party=$avp(s:billing_party) # Simple test for unconditional call forward $avp(s:callfwd)=sip:00390212...@sip.clio.it; avp_pushto($ru, $avp(s:callfwd)); $avp(s:divert_reason)=cfu; $avp(s:billing_party)=$tu; xlog (L_INFO, TEST Forward - M=$rm RURI=$ru F=$fu T=$tu IP= $si ID=$ci\n); The result is that radius request is (for 1000 to 1001 diverted to 00390212345): Wed Jun 24 11:59:29 2009 Acct-Status-Type = Start Service-Type = Sip-Session Sip-Response-Code = 200 Sip-Method = Invite [...] User-Name = 1...@sip.clio.it Calling-Station-Id = sip:1...@sip.clio.it:5060 Called-Station-Id = sip:1...@sip.clio.it:5060 Sip-Translated-Request-URI = sip:00390212...@10.0.1.44 [...] Canonical-URI = sip:00390212...@sip.clio.it Billing-Party = sip:1...@sip.clio.it:5060 Divert-Reason = cfu [...] Where I'm wrong? Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool and diverted calls
Il giorno 24/giu/09, alle ore 12:37, Iñaki Baz Castillo ha scritto: As Adrian already suggested: by setting an appropiate value for an AVP which will be mapped to Radius UserName field (billing username). Or well, if you set Billing-Party it has preference. ok, I will use $avp(s:billing_party)... This is NOT secure at all, please NEVER rely on the To header as the caller could generate an spoofed INVITE with To different than the RURI. Instead, store the original RURI in some AVP and use it to set $avp(s:billing_party). it's true! thanks. As you see, Billing-Party = sip:1001 Isn't it what you desire? Yes, but in this way I bill only the second call (from 1001 to 0039021...). Instead, I want to bill two calls: 1) from 1000 to 1001 and 2) from 1001 to 0039021 With these information, the caller (1000) will not pay for his call, isn't it true? Thanks ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool and diverted calls
Il giorno 24/giu/09, alle ore 13:12, Adrian Georgescu ha scritto: Carlo, What you try to do is not entirely logical (except of course for earning more money from the same call), from the signaling and media perspective is a single call, not two. Is a way to abuse the calling party that will pay for calls it did not initiate. Hi Adrian, I have thought about your words, I don't want more money from the same call, My question was for special contracts that need billing also for internal opensips calls. For example: 1000 pay X for call 1001(all account are internal) 1001 pay Y for call 00390212345 (0039083212345 is external pstn number) When 1001 perform an unconditional forwarding, I should bill X (1000- 1001) + Y (1001-00390212345), as expected from 1000 and 1001. Otherwise the client 1000 could ask me why the call hasn't billed... At the end, I think that the only way is to create an additional script to CDRTool for handle this situation (look inside the radacct). Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRTool and diverted calls
Il giorno 24/giu/09, alle ore 16:17, Carlo Dimaggio ha scritto: Hi Adrian, I have thought about your words, I don't want more money from the same Sorry Adrian, another (little question). CDRTool checks in radacct the username (the billing-party), but as I can see the prepaid engine uses the from field (in this manner the diversion doesn't work because the prepaid bill the calling-party...). It's an expected behaviour or I should change something in my opensips config for using the billing-party (without change the from because I must preserve the real calling-party)? cdrtool syslog: - MaxSessionTime From=sip:1...@sip.xxx.it Lock=1 [...] ^ should be 1001 Thanks and regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call-forward and multi-leg accounting
Hi all, I'm trying to implement a call-forward-unconditional with radius multi- leg accounting. The multileg acc parameter is: modparam(acc, multi_leg_info, Calling-Station-Id=$avp(s:cwd_src);Called-Station-Id= $avp(s:cwd_dst)), while in the request route I have this test block: $avp(s:cfu)=sip:1...@sip.xxx.it; avp_pushto($ruri, $avp(s:cfu)); append_branch(); $avp(s:cwd_src)=sip:1...@sip.xxx.it; $avp(s:cwd_dst)=sip:1...@sip.xxx.it; The test call is: 1000 - 1002 - redirected to 1001 My aim is to have two radius accounting messages but I have only one accouting message with the multi_leg_info attached. Indeed I have seen in the documentation that this should be the normal behaviour when radius is used. Is there any way to achive my aim (two invite, one from 1000 to 1002 and one from 1002 to 1001)? Thank you, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Prefix format in routing script
HI all, I would change my opensips.cfg from lcr to dynamic routing in order to use the routing features (time/priority) of the drouting module. However I have some problems with the routing prefix. In the DB I usually use the prefix +39NUM but as I can see, drouting cannot permit non-numbers. So I am a little bit confused because I have different situations (with several changes for ruri in opensips.cfg) 1) dbaliases (for DID match) with prefix +39 2) external routing (drouting) with prefix 0039 3) ENUM query with prefix +39 3) CDRTool numbers for billing with prefix 0039 My question is: how could be the right format to store these information? +39NUM or 0039NUM? How can I uniform the routing procedure? I hope you can help me ;-) Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Prefix format in routing script
Hi all, I would change my opensips.cfg from lcr to dynamic routing in order to use the routing features (time/priority) of the drouting module. However I have some problems with the routing prefix. In the DB I usually use the prefix +39NUM but as I can see, drouting cannot permit non-numbers. So I am a little bit confused because I have different situations (with several changes for ruri in opensips.cfg) 1) dbaliases (for DID match) with prefix +39 2) external routing (drouting) with prefix 0039 3) ENUM query with prefix +39 3) CDRTool numbers for billing with prefix 0039 My question is: how could be the right format to store these information? +39NUM or 0039NUM? How can I uniform the routing procedure? I hope you can help me :) Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Mediaproxy relay exception for video call
Hi all, I have an exception in media-relay when I try to perform a video call (h.263/264 or 261). A voice call works fine. The two endpoints are Ekiga 3.0 and Xmeeting 0.3.4a (or Xlite 3) while the other versions are: opensips 1.5.1, media dispatcher and relay 2.3.4. Is this problem related to mediaproxy 2.3.4? Thanks and regards, Carlo Dimaggio --- Log Media-dispatcher May 5 10:38:07 sip media-dispatcher[4623]: debug: Issuing update command to relay at IP_MEDIA May 5 10:38:07 sip media-dispatcher[4623]: warning: Relay at IP_MEDIA returned error: Received error from relay at IP_MEDIA in response to update command May 5 10:38:07 sip media-dispatcher[4623]: error: Error processing request: No suitable relay found --- Log Media-relay May 5 10:38:07 media media-relay[14342]: Traceback (most recent call last): May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/twisted/internet/epollreactor.py, line 197, in _doReadOrWrite May 5 10:38:07 media media-relay[14342]: why = selectable.doRead() May 5 10:38:07 media media-relay[14342]: File /var/lib/python- support/python2.5/gnutls/interfaces/twisted/__init__.py, line 82, in doRead May 5 10:38:07 media media-relay[14342]: return tcp.Connection.doRead(self) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/twisted/internet/tcp.py, line 362, in doRead May 5 10:38:07 media media-relay[14342]: return self.protocol.dataReceived(data) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/twisted/protocols/basic.py, line 149, in dataReceived May 5 10:38:07 media media-relay[14342]: self.lineReceived(line) May 5 10:38:07 media media-relay[14342]: --- exception caught here --- May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/relay.py, line 180, in lineReceived May 5 10:38:07 media media-relay[14342]: response = self.factory.parent.got_command(self.factory.host, self.command, self.headers) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/relay.py, line 391, in got_command May 5 10:38:07 media media-relay[14342]: local_media = self.session_manager.update_session(dispatcher, **headers) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/mediacontrol.py, line 673, in update_session May 5 10:38:07 media media-relay[14342]: session = Session(self, dispatcher, call_id, from_tag, from_uri, to_tag, to_uri, cseq, user_agent, media, is_downstream, is_caller_cseq) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/mediacontrol.py, line 422, in __init__ May 5 10:38:07 media media-relay[14342]: self.update_media(cseq, to_tag, user_agent, media_list, is_downstream, is_caller_cseq) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/mediacontrol.py, line 463, in update_media May 5 10:38:07 media media-relay[14342]: stream = MediaStream(self, media_type, media_ip, media_port, party, media_direction) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/mediacontrol.py, line 317, in __init__ May 5 10:38:07 media media-relay[14342]: self.caller = MediaParty(self) May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/mediacontrol.py, line 285, in __init__ May 5 10:38:07 media media-relay[14342]: self.ports = port_rtp, port_rtcp = self.manager.get_ports() May 5 10:38:07 media media-relay[14342]: File /usr/lib/python2.5/ site-packages/mediaproxy/mediacontrol.py, line 640, in get_ports May 5 10:38:07 media media-relay[14342]: return self.ports.popleft() May 5 10:38:07 media media-relay[14342]: exceptions.IndexError: pop from an empty deque ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy relay exception for video call
Il giorno 05/mag/09, alle ore 12:28, Ruud Klaver ha scritto: Hi Carlo, This seems to be exactly the same exception you posted before. It means no relaying UDP ports are available at the relay. Could you check your configuration for the amount of ports you allocated? Hi Ruud, I'm sorry!!! I have forgot that I've changed the config.ini in media relay... :-( There was no problem in voice call because the stream used only 4 ports... Many, many thanks ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Osipsconsole and store_plaintext_pw variable
Hello, I have set the variable STORE_PLAINTEXT_PW=0 in osipsconsolerc but if I exec the commands add or passwd, the password of the account in db is not encrypted. Is there something I should change? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips crashed - problem with MD5?
Il giorno 15/apr/09, alle ore 13:36, Bogdan-Andrei Iancu ha scritto: Hi Carlo, The backtrace looks really broken.it might be a core overwrite. What revision on 1.5.0 are you using (do opensips -V) ? there are several mysql related bugs fixed since the 1.5.0 release. If you have a SVN copy, do a SVN update to get the latest fixes. Otherwise I recomand upgrading to 1.5.1 (see the download section on the web site). Ok Bogdan, I have upgraded to 1.5.1. One question: why I see version 1.4.3 from opensips -V and 1.5.1 from osipsconsole (monitor)? Thanks and Regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call-control exception
Il giorno 04/apr/09, alle ore 17:09, Adrian Georgescu ha scritto: Hello Carlo, I made a fix, please upgrade to version 6.7.6 and check if this happens again. Hi Adrian, I have upgraded to 6.7.6. Now I don't see any differences between prices. Thank you!! Best regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call-control exception
Il giorno 04/apr/09, alle ore 10:58, Adrian Georgescu ha scritto: Try same command first with MaxSessionTime to simulate the start of the session Ok. The results are: - 1) Duration=15 MaxSessionTime Duration=15 CallId=test_call_adrian From=sip:1...@sip.xxx.it Gateway=79.1.2.3 To=sip:0039347123...@sip.xxx.it:5060;user=phone 15 DebitBalance Duration=15 CallId=test_call_adrian From=sip:1...@sip.xxx.it Gateway=79.1.2.3 To=sip:0039347123...@sip.xxx.it:5060;user=phone Ok MaxSessionTime=0 0.0413 Duration: 15 s App: audio Destination: 3934 Customer: domain=sip.xxx.it Connect: 0. StartTime: 2009-04-04 13:30:32 -- Span: 1 Duration: 15 s ProfileId: 331002 / weekend RateId: 3310021 / 0-24h Rate: 0.1650 / 60 s Price: 0.0413 2) Duration=16 MaxSessionTime Duration=16 CallId=test_call_adrian From=sip:1...@sip.xxx.it Gateway=79.1.2.3 To=sip:0039347123...@sip.xxx.it:5060;user=phone 16 DebitBalance Duration=16 CallId=test_call_adrian From=sip:1...@sip.xxx.it Gateway=79.1.2.3 To=sip:0039347123...@sip.xxx.it:5060;user=phone Ok MaxSessionTime=0 0.0440 Duration: 16 s App: audio Destination: 3934 Customer: domain=sip.xxx.it Connect: 0. StartTime: 2009-04-04 13:31:15 -- Span: 1 Duration: 16 s ProfileId: 331002 / weekend RateId: 3310021 / 0-24h Rate: 0.1650 / 60 s Price: 0.0440 -- Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call-control exception
Il giorno 03/apr/09, alle ore 12:45, Luci Stanescu ha scritto: Hi Carlo, Hi Luci, Does this exception happen with prepaid calls or non-prepaid calls? only with prepaid calls Do you allow simultaneous prepaid calls on your platform? Until now, I have tried only one call for customer... Can you please also paste the logs from CDRTool which correspond to the calls for which this exception is raised? Sure: -- Apr 3 15:23:50 proxy cdrtool[32597]: MaxSessionTime From=sip:1...@sip.xxx.it Lock=1 To=sip:0039345123...@sip.xxx.it:5060 CallId=f86a8a1d21a02f93 Duration=36000 Gateway=10.0.8.183 Apr 3 15:23:50 proxy cdrtool[32597]: MaxSessionTime=339 Type=prepaid CallId=f86a8a1d21a02f93 billingparty=1...@sip.xxx.it DestId=3934 Balance=0.9317 Spans=1 Apr 3 15:23:58 proxy cdrtool[32597]: MaxSessionTime From=sip:1...@sip.xxx.it Lock=1 To=sip:0039345123...@sip.xxx.it:5060 State=Connected CallId=f86a8a1d21a02f93 Duration=36000 Gateway=10.0.8.183 Apr 3 15:23:58 proxy cdrtool[32597]: Account locked by another call Apr 3 15:24:03 proxy cdrtool[32597]: DebitBalance Duration=4.75118803978 CallId=f86a8a1d21a02f93 From=sip: 1...@sip.xxx.it Gateway=10.0.8.183 To=sip:0039345123...@sip.xxx.it:5060 Apr 3 15:24:03 proxy cdrtool[32597]: ConnectFee=0. CallId=f86a8a1d21a02f93 Span=1 Duration=4.75118803978 DestId=3934 domain=sip.xxx.it Profile=331002 Period=weekday Rate=3310021 Interval=0-24 Cost=0.1650/60 Price=0.0131 Price in=0. Apr 3 15:24:03 proxy cdrtool[32597]: Price=0.0131 Duration=4.75118803978 CallId=f86a8a1d21a02f93 billingparty=1...@sip.xxx.it DestId=3934 MaxSessionTime=0 -- Why I have the message Account locked by another call if this is the first call for that customer? Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call-control exception
Il giorno 03/apr/09, alle ore 20:20, Luci Stanescu ha scritto: Hi Carlo, There is a bug in CDRTool when using prepaid_lock = 1 Until it's fixed, you can set the option to 0. This will allow simultaneous prepaid calls and the bug will no longer manifest. Call-control did not take the possibility of this in consideration and this is why it gives the weird error. I will modify it to give a more clear message, but you should set the prepaid_lock option to 0. Ok Luci, thank you for the info. I'll wait for the fix... Another question: in my tests I see that the price shown in prepaid accounts (and in logs) is a little bit different from cdrs list of cdrtool. For example preaid accounts shows last price = 0.0433 while cdrs shows price = 0.0413. It is a bug? Many thanks, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call-control exception
Il giorno 03/apr/09, alle ore 20:20, Luci Stanescu ha scritto: Hi Carlo, There is a bug in CDRTool when using prepaid_lock = 1 Until it's fixed, you can set the option to 0. This will allow simultaneous prepaid calls and the bug will no longer manifest. Call-control did not take the possibility of this in consideration and this is why it gives the weird error. I will modify it to give a more clear message, but you should set the prepaid_lock option to 0. Ok Luci, thank you for the info. I'll wait for the fix... Another question: in my tests I see that the price shown in prepaid accounts (and in logs) is a little bit different from cdrs list of cdrtool. For example preaid accounts shows last price = 0.0433 while cdrs shows price = 0.0413. It is a bug? Many thanks, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call-control exception
Il giorno 03/apr/09, alle ore 22:53, Adrian Georgescu ha scritto: Carlo, Can you paste all the cdrtool syslog lines related to the call in question? Hi Adrian. Here the syslog. I see that the Duration calculated with cron is different from that calculated when the prepaid call is closed (15 (int?) instead of 15.7315969467): Thanks, Carlo Apr 3 22:24:07 proxy cdrtool[13214]: MaxSessionTime From=sip:1...@sip.xxx.it Lock=1 To=sip:0039347123...@sip.xxx.it:5060;user=phone State=Connected callid=31cfbec-c0a80101-...@192.168.1.100 Duration=36000 Gateway=79.1.2.3 Apr 3 22:24:07 proxy cdrtool[13214]: Maximum duration for session 31cfbec-c0a80101-...@192.168.1.100 of 1...@sip.xxx.it to destination 3934 having balance=1. is 364 Apr 3 22:24:07 proxy cdrtool[13214]: MaxSessionTime=364 Type=prepaid callid=31cfbec-c0a80101-...@192.168.1.100 billingparty=1...@sip.xxx.it DestId=3934 Balance=1. Spans=1 Apr 3 22:24:23 proxy cdrtool[13214]: DebitBalance Duration=15.7315969467 callid=31cfbec-c0a80101-...@192.168.1.100 From=sip:1...@sip.xxx.it Gateway=79.37.254.50 To=sip:0039347123...@sip.xxx.it:5060;user=phone Apr 3 22:24:23 proxy cdrtool[13214]: ConnectFee=0. callid=31cfbec-c0a80101-...@192.168.1.100 Span=1 Duration=15.7315969467 DestId=3934 domain=sip.xxx.it Profile=331002 Period=weekday Rate=3310021 Interval=0-24 Cost=0.1650/60 Price=0.0433 Price in=0. Apr 3 22:24:23 proxy cdrtool[13214]: Price=0.0433 Duration=15.7315969467 callid=31cfbec-c0a80101-...@192.168.1.100 billingparty=1...@sip.xxx.it DestId=3934 MaxSessionTime=0 Apr 3 22:25:01 proxy /USR/SBIN/CRON[13258]: [...] Apr 3 22:25:01 proxy cdrtool[13268]: ConnectFee=0. callid=31cfbec-c0a80101-...@192.168.1.100 Span=1 Duration=15 DestId=3934 domain=sip.xxx.it Profile=331002 Period=weekday Rate=3310021 Interval=0-24 Cost=0.1650/60 Price=0.0413 Price in=0. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ERROR:core:pv_parse_spec: bad parameters after upgrading to 1.5
Il giorno 31/mar/09, alle ore 16:23, Bogdan-Andrei Iancu ha scritto: Please apply this patch, recompile the module and let me know if the problem was solved. Hi Bogdan, I have applied this patch and now all works fine!!! I have tested it with different calls and I haven't seen any errors. Many thanks for your quick patch! Best regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call-control exception
Hi, I'm experiencing with an exception in call-control 2.0.3. I have seen that there are no explicit problems on prepaid system (the calls are handled in the right way): Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] Unhandled error in Deferred: Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] Traceback (most recent call last): Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] File /usr/lib/python2.5/site- packages/callcontrol/rating.py, line 131, in lineReceived Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] self._respond(getattr(self, '_PE_ %s' % self.__request.command.lower())(line)) Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] File /usr/lib/python2.5/site- packages/callcontrol/rating.py, line 193, in _respond Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] req.deferred.callback(result) Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] File /usr/lib/python2.5/site- packages/twisted/internet/defer.py, line 239, in callback Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] self._startRunCallbacks(result) Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] File /usr/lib/python2.5/site- packages/twisted/internet/defer.py, line 304, in _startRunCallbacks Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] self._runCallbacks() Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] --- exception caught here --- Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] File /usr/lib/python2.5/site- packages/twisted/internet/defer.py, line 317, in _runCallbacks Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] self.result = callback(self.result, *args, **kw) Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] File /usr/lib/python2.5/site- packages/callcontrol/sip.py, line 239, in _start_finish_calllimit Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] delay = limit - self.timelimit Apr 1 17:28:17 sip call-control[9224]: [RatingEngineProtocol,client] exceptions.TypeError: unsupported operand type(s) for -: 'str' and 'int' Where is the problem? Thanks and regards, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ERROR:core:pv_parse_spec: bad parameters after upgrading to 1.5
Il giorno 26/mar/09, alle ore 17:13, Bogdan-Andrei Iancu ha scritto:
Hi Carlo,
I just checked with 1.5 the
if (is_user_in(Credentials,ITALY_MOBILE)) {
and it is ok. no error.
Are you sure this is the line that generates the error? I suspect
you might have a typo in one of the is_user_in() functions, for
the first param. Because if this value is not recognized as a
default one (see
http://www.opensips.org/html/docs/modules/devel/group.html#id228395)
, it is assumed to be a pseudo-variable. And the error you get is
about an invalid PV
So,please check your script.
Hi Bogdan,
I have 5 blocks in which I use the function is_user_in():
if (is_user_in(Credentials, quota)) {
if (!is_user_in(Credentials, ITALY_NATIONAL)) {
if (is_user_in(Credentials, ITALY_NATIONAL)) {
if (is_user_in(Credentials, ITALY_MOBILE)) {
if (is_user_in(Credentials, INTERNATIONAL)) {
In all functions I use Credentials as first parameter. Do you see
something wrong?
If I comment these lines I don't have errors...
Thanks and regards,
Carlo
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] ERROR:core:pv_parse_spec: bad parameters after upgrading to 1.5
Hi all, After the upgrading to 1.5 I see these errors in my log: Mar 25 10:25:48 sip /sbin/opensips[7908]: ERROR:core:pv_parse_spec: bad parameters Mar 25 10:25:48 sip /sbin/opensips[7908]: ERROR:group:get_hf: unsupported User Field identifier Mar 25 10:25:48 sip /sbin/opensips[7908]: ERROR:group:is_user_in: unable to get user/dom source These errors appear after few calls (for example I have no errors for the first 2-3 calls), but I'm able to make calls. I don't know what can be the reason because in 1.4.3 there was no problem. The only thing I have added to configuration is create_dialog() before using set_dlg_profile(). Can you help me understanding these errors? Thank you, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] ERROR:core:pv_parse_spec: bad parameters after upgrading to 1.5
Il giorno 25/mar/09, alle ore 18:35, Sergio Gutierrez ha scritto: Hi Carlo. Just for testing, could you try this: ... $avp(s:group)=ITALY_MOBILE; if(is_user_in(credentials, $avp(s:group))) ... Hi Sergio, I've tried but nothing... same problem (and same errors) Regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DB version error in upgrading to 1.5
Il giorno 24/mar/09, alle ore 15:22, Bogdan-Andrei Iancu ha scritto: Hi Carlo, to update your database to 1.5 (from 1.4 version) you need to do opensipdbctl migrate - this should solve your problem. Regards, Bogdan Hi Bogdan, I've used the command 'opensipsdbctl migrate' but I have the same problem (the version of trusted table is 4 instead of 5). Do I change manually the number to 5 as Mauro suggested? Thanks, Carlo The output of opensipsdbctl migrate is: # opensipsdbctl migrate opensips opensips_15 MySQL password for root: INFO: Creating new Database opensips_new INFO: test server charset INFO: creating database opensips_new ... INFO: Core OpenSIPS tables succesfully created. Install presence related tables? (y/n): y INFO: creating presence tables into opensips_new ... INFO: Presence tables succesfully created. Install tables for imc cpl siptrace domainpolicy carrierroute userblacklist? (y/n): y INFO: creating extra tables into opensips_new ... INFO: Extra tables succesfully created. INFO: Migrating data from opensips to opensips_new INFO: -- Migrating opensips.acc to opensips_new.acc.OK INFO: -- Migrating opensips.missed_calls to opensips_new.missed_calls.OK INFO: -- Migrating opensips.aliases to opensips_new.aliases.OK INFO: -- Migrating opensips.dbaliases to opensips_new.dbaliases.OK INFO: -- Migrating opensips.grp to opensips_new.grp.OK INFO: -- Migrating opensips.re_grp to opensips_new.re_grp.OK INFO: -- Migrating opensips.silo to opensips_new.silo.OK INFO: -- Migrating opensips.domain to opensips_new.domain.OK INFO: -- Migrating opensips.uri to opensips_new.uri.OK INFO: -- Migrating opensips.usr_preferences to opensips_new.usr_preferences.OK INFO: -- Migrating opensips.trusted to opensips_new.trusted.OK INFO: -- Migrating opensips.address to opensips_new.address.OK INFO: -- Migrating opensips.speed_dial to opensips_new.speed_dial.OK ERROR: failed to migrate opensips.gw to opensips_new.gw!!! Skip it and continue (y/n)? y -- Migrating opensips.gw_grp to opensips_new.gw_grp.SKIPPED (no source) INFO: -- Migrating opensips.lcr to opensips_new.lcr.OK INFO: -- Migrating opensips.pdt to opensips_new.pdt.OK INFO: -- Migrating opensips.subscriber to opensips_new.subscriber.OK INFO: -- Migrating opensips.cpl to opensips_new.cpl.OK -- Migrating opensips.siptrace to opensips_new.siptrace.SKIPPED (no source) INFO: -- Migrating opensips.imc_rooms to opensips_new.imc_rooms.OK -- Migrating opensips.im_members to opensips_new.imc_members.SKIPPED (no source) INFO: Migration successfully completed. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DB version error in upgrading to 1.5
Il giorno 24/mar/09, alle ore 16:15, Bogdan-Andrei Iancu ha scritto: I just checked and creating a new DB will set a 5 version for the trusted table. Are you sure you are not mixing somehow the old and new DB ? I don't think, but I'll investigate better... For now, I have set manually the version table. Thank you, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DB version error in upgrading to 1.5
Il giorno 24/mar/09, alle ore 17:05, Bogdan-Andrei Iancu ha scritto: And only the trusted table was affected ? the rest of the tables are ok? Hi Bogdan, At the end, I have modified trusted, gw, address, lcr, subscriber, dialog, grp, location, userblacklist tables. It seems a little bit strange, but for now all is fine. Best regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Problem with t_check_trans()
Hi all,
I have a problem with the following configuration and the
t_check_trans() function:
userA - Asterisk - Opensips - userB
In detail, if userA calls userB and then userA sends CANCEL,
t_check_trans doesn't recognize the transaction.
I would like to know how t_check_trans matches the transaction (which
headers?).
With another client (instead of Asterisk) all works fine.
Thank you,
Carlo Dimaggio
1) In my opensips.cfg I have:
# CANCEL processing
if (is_method(CANCEL)) {
if (t_check_trans()) {
xlog (L_INFO, Cancel Session - M=$rm RURI=$ru F=$fu T=
$tu IP=$si ID=$ci\n);
route(1);
};
exit;
}
route[1] {
#
# --- FORWARD REQUEST TO TARGET
#
# Forward statefully
xlog (L_INFO, Forward request to target - M=$rm RURI=$ru F=$fu
T=$tu IP=$si ID=$ci\n);
t_on_reply(1);
t_on_failure(1);
if (!t_relay()) {
sl_reply_error();
};
exit;
}
2) The ngrep is:
U 10.0.6.101:5060 - 10.0.6.1:5060
INVITE sip:1...@opensips SIP/2.0.
Via: SIP/2.0/UDP 10.0.6.101:5060;branch=z9hG4bK765f9c34;rport.
From: 1005 sip:1...@opensips;tag=as44c8623d.
To: sip:1...@opensips.
Contact: sip:1...@10.0.6.101.
Call-ID: 59f29a0e0b415eb8208902334bcfe...@opensips.
CSeq: 103 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Proxy-Authorization: Digest username=1005, realm=opensips,
algorithm=MD5, uri=sip:1...@opensips,
nonce=49bfb4ee0064a87d5b8f0656c0b2ac4ff80e64bebff0,
response=137b777f01625c5e28f50f9972d2c23c, qop=auth,
cnonce=6d2606c0, nc=0001.
Date: Tue, 17 Mar 2009 14:33:57 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 258.
.
v=0.
o=root 4614 4615 IN IP4 10.0.6.101.
s=session.
c=IN IP4 10.0.6.101.
t=0 0.
m=audio 15694 RTP/AVP 0 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
U 10.0.6.101:5060 - 10.0.6.1:5060
CANCEL sip:1...@opensips SIP/2.0.
Via: SIP/2.0/UDP 10.0.6.101:5060;branch=z9hG4bK63d5b445;rport.
From: 1005 sip:1...@opensips;tag=as44c8623d.
To: sip:1...@opensips.
Call-ID: 59f29a0e0b415eb8208902334bcfe...@opensips.
CSeq: 103 CANCEL.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Content-Length: 0.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] NOTIFY nat_keepalive - Bad Event
Hi all,
I'm using nat_traversal and the nat_keepalive function. For phones-
compatibility I have to use the NOTIFY method but all my registered
phones reply to opensips with Bad Request / Bad Event (with OPTIONS
method some phones reply with 200 OK). What I am wrong?
Can you help me?
Thanks,
Carlo Dimaggio
Opensips.cfg
modparam(nat_traversal, keepalive_interval, 90)
modparam(nat_traversal, keepalive_method, NOTIFY)
modparam(nat_traversal, keepalive_state_file, /var/run/opensips/
keepalive_state)
[...]
if ((method==REGISTER || (method==INVITE !has_totag()))
client_nat_test(3))
{
nat_keepalive();
}
Trace with NOTIFY
#
U IP_OPENSIPS:5060 - 10.0.8.183:5060
NOTIFY sip:10.0.8.183:5060 SIP/2.0.
Via: SIP/2.0/UDP IP_OPENSIPS:5060;branch=0.
From: sip:keepalive@IP_OPENSIPS;tag=4c2a2dbf.
To: sip:10.0.8.183:5060.
Call-ID: 2fe80f67-6c647fe7-27@IP_OPENSIPS.
CSeq: 1 NOTIFY.
Event: keep-alive.
Content-Length: 0.
.
#
U 10.0.8.183:5060 - IP_OPENSIPS:5060
SIP/2.0 489 Bad Event.
Via: SIP/2.0/UDP IP_OPENSIPS:5060;branch=0.
From: sip:keepalive@IP_OPENSIPS;tag=4c2a2dbf.
To: sip:10.0.8.183:5060;tag=224300607.
Call-ID: 2fe80f67-6c647fe7-27@IP_OPENSIPS.
CSeq: 1 NOTIFY.
Contact: sip:10.0.8.183:5060.
Server: Aastra 55i/2.3.1.26.
Content-Length: 0.
.
-
Trace with OPTIONS
#
U IP_OPENSIPS:5060 - 10.0.8.183:5060
OPTIONS sip:10.0.8.183:5060 SIP/2.0.
Via: SIP/2.0/UDP IP_OPENSIPS:5060;branch=0.
From: sip:keepalive@IP_OPENSIPS;tag=6386f398.
To: sip:10.0.8.183:5060.
Call-ID: 406b0979-64c6436a-27@IP_OPENSIPS.
CSeq: 1 OPTIONS.
Content-Length: 0.
.
#
U 10.0.8.183:5060 - IP_OPENSIPS:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP IP_OPENSIPS:5060;branch=0.
From: sip:keepalive@IP_OPENSIPS;tag=6386f398.
To: sip:10.0.8.183:5060;tag=85691902.
Call-ID: 406b0979-64c6436a-27@IP_OPENSIPS.
CSeq: 1 OPTIONS.
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE,
PRACK, SUBSCRIBE, INFO.
Server: Aastra 55i/2.3.1.26.
Content-Length: 0.
.
-
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy 2.3: reinvites' SDP not modified
Il giorno 13/feb/09, alle ore 13:56, Dan Pascu ha scritto: The Patton device seems to be faulty. In its answer it strips all params from the Record-Route header except from lr=on. Similarly it strips all params from the Record-Route headers except lr=on when converting the Record-Route headers to Route headers on subsequent re-INVITEs. Among these params is the did (dialog-id) which is used to identify the dialog the message belongs to. My guess is that those re-INVITEs are not matched against their dialogs anymore so no mediaproxy callbacks are called for them to modify their SDP. You can try to use use_media_proxy() and end_media_session() instead of engage_media_proxy() to manually call on mediaproxy to handle the SDP for every INVITE/reply during the dialog. The dialog based method of using engage_media_proxy can only work if the devices work properly and do not prevent the dialog module from recognizing an in-dialog message because its identification elements were altered. Thank you Dan/Adrian/Ruud for your quick and expert answers :-) I understand. Do you think I can write to tech support of Patton and explain the problem? It is a bug in their firmware or a particular behaviour? I would like to continue using engage_media_proxy... Many thanks, Carlo Dimaggio ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy 2.3: reinvites' SDP not modified
Il giorno 11/feb/09, alle ore 12:00, Ruud Klaver ha scritto:
Hi Carlo,
The problem definitely lies with OpenSIPS in your first example, the
one that didn't work, since the media-dispatcher does not receive
anything from the mediaproxy module in OpenSIPs when the re-INVITE
is received. Could you please provide the relevant parts of your
OpenSIPS config and its logging for both of these cases?
From the logs I gave you I cannot tell that much, except that in the
first case your proxy seems to anonymize the SIP URI of the caller,
but this shouldn't matter.
The mediaproxy module should just look for the m=image line, which
is the same in both traces. Other than that it does no processing of
the T38 stuff, it should be agnostic to it.
Hi Ruud,
Sure. I attach the relevant parts of my configuration and the log for
both of these cases.
I don't understand why there is this behaviour with two devices
(grandstream and patton) and the same opensips.cfg... In both of these
cases, the re-invite is performed (as you can see from the ngrep log)
but when I use the patton, it seems that mediaproxy doesn't recognise
the t38 session and doesn't proxy the call.
I use engage_media_proxy() in my script that should automatically call
use_media_proxy() on every request and reply that belongs to the
dialog...
What kind of errors could be in my configuration?
Thank you,
Carlo Dimaggio
opensips.cfg
Description: Binary data
{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf430
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww25060\viewh13020\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural
\f0\fs24 \cf0 Feb 11 12:53:58 sip /sbin/opensips[4644]: New request - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4644]: NAT Peer - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4644]: Determine request target - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4644]: Non-Register request handler - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4644]: Account INVITE or Missed call\
Feb 11 12:53:58 sip /sbin/opensips[4644]: Internal Domain - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: New request - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: NAT Peer - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Determine request target - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Non-Register request handler - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Account INVITE or Missed call\
Feb 11 12:53:58 sip /sbin/opensips[4642]: Internal Domain - M=INVITE RURI=sip:08321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Normalize URI - add +39 for internal reasons - M=INVITE RURI=sip:+3908321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Callee is not local - M=INVITE RURI=sip:+3908321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Privacy mode or RPID not defined... - M=INVITE RURI=sip:+3908321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Caller anonymized... - M=INVITE RURI=sip:+3908321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Engage MediaProxy - M=INVITE RURI=sip:+3908321...@opensips F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:58 sip /sbin/opensips[4642]: Try gateway - M=INVITE RURI=sip:0832@IP_T38MODEM:6060;transport=udp F=sip:1...@opensips T=sip:08321...@opensips IP=10.0.6.52 id=zlr05-ia1...@opensips \
Feb 11 12:53:59 sip /sbin/opensips[4642]: New
Re: [OpenSIPS-Users] mediaproxy 2.3: reinvites' SDP not modified
Il giorno 06/gen/09, alle ore 20:10, Ruud Klaver ha scritto: Maybe you can still find it somewhere in your syslog? Grep for image, which is the media type used by T.38 IIRC. The point is that we tried to implement this well, but it was very difficult actually obtaining test devices to see if it worked in a real life testbed. Hi Ruud, I'm working now on t.38 fax with opensips 1.4.3 + mediaproxy 2.3.1 and I have the same problem as Jeff. Here's my scenario. I have a fax connected to a patton (sip number 1004) with a private ip (192.168.1.253) and a hylafax/t38modem (sip number 0832) with a public ip (IP_T38MODEM). Calls are established at g711, proxied with engage_media_proxy() (all is ok as i can see, the c=line has the media-relay ip), but when there is a re-invite for t38 the media is not proxied and the packets have c=line with original ip (private and public) (In this way t38modem sends packets to the private ip...). There's no image media type in syslog. The problem is in both ways (patton to t38modem and t38modem to patton). If the patton has the public ip all works fine. I have some logs. I hope these information can be useful for you (sorry for the length :-)): Thanks and Regards, Carlo Dimaggio --- 1) Syslog media-dispatcher Feb 7 21:02:49 sip media-dispatcher[4614]: [OpenSIPSControlProtocol, 7,] Issuing update command to relay at IP_MEDIA_RELAY Feb 7 21:02:49 sip media-dispatcher[4614]: [OpenSIPSControlProtocol, 6,] Issuing update command to relay at IP_MEDIA_RELAY 2) Syslog media-relay Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Received new SDP offer Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 5 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50001 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50002 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50003 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Added new stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - Unknown (RTP: Unknown, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] created new session ambvr0-hpa1y...@opensips: 1...@opensips (4g5g2-7QUQV0) -- 08321...@opensips Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] updating existing session ambvr0-hpa1y...@opensips: 1...@opensips (4g5g2-7QUQV0) -- 08321...@opensips Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Received updated SDP answer Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Got initial answer from callee for stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: Unknown, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: IP_T38MODEM:10024, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: IP_PUBLIC_PATTON:10002, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: IP_T38MODEM: 10024, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: IP_PUBLIC_PATTON:10002, RTCP: IP_PUBLIC_PATTON:10003) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM: 10024 (RTP: IP_T38MODEM:10024, RTCP: Unknown) 3) Sip Trace (opensips/media-dispatcher) U IP_PUBLIC_PATTON:5061 - IP_OPENSIPS:5060 INVITE sip:08321...@opensips SIP/2.0. From: PattonFAXsip:1...@opensips;tag=4g5g2-7QUQV0. To: sip:08321...@opensips. Call-ID: ambvr0-hpa1y...@opensips. CSeq: 112 INVITE. Via: SIP/2.0/UDP 192.168.1.253:5061;branch=z9hG4bK1M0f2-NN50iMEOI0. Contact: PattonFAXsip:1...@192.168.1.253:5061. Max-Forwards: 70. Route: sip:IP_OPENSIPS:5060. User-Agent: 20n/021106. Allow: INVITE,BYE,CANCEL,OPTIONS,PRACK,NOTIFY,UPDATE,REFER. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 233. . v=0. o=1004 192916 1 IN IP4 192.168.1.253. s=-. c=IN IP4 192.168.1.253. t=0 0. m=audio 10002 RTP/AVP 8 0 96. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:96 telephone-event/8000. a=ptime:30. a=rtpmap:96 telephone-event/8000
Re: [OpenSIPS-Users] mediaproxy 2.3: reinvites' SDP not modified
Il giorno 06/gen/09, alle ore 20:10, Ruud Klaver ha scritto: Maybe you can still find it somewhere in your syslog? Grep for image, which is the media type used by T.38 IIRC. The point is that we tried to implement this well, but it was very difficult actually obtaining test devices to see if it worked in a real life testbed. Hi Ruud, I'm working now on t.38 fax with opensips 1.4.3 + mediaproxy 2.3.1 and I have the same problem as Jeff. Here's my scenario. I have a fax connected to a patton (sip number 1004) with a private ip (192.168.1.253) and a hylafax/t38modem (sip number 0832) with a public ip (IP_T38MODEM). Calls are established at g711, proxied with engage_media_proxy() (all is ok as i can see, the c=line has the media-relay ip), but when there is a re-invite for t38 the media is not proxied and the packets have c=line with original ip (private and public) (In this way t38modem sends packets to the private ip...). There's no image media type in syslog. The problem is in both ways (patton to t38modem and t38modem to patton). If the patton has the public ip all works fine. I have some logs. I hope these information can be useful for you (sorry for the length :-)): Thanks and Regards, Carlo Dimaggio --- 1) Syslog media-dispatcher Feb 7 21:02:49 sip media-dispatcher[4614]: [OpenSIPSControlProtocol, 7,] Issuing update command to relay at IP_MEDIA_RELAY Feb 7 21:02:49 sip media-dispatcher[4614]: [OpenSIPSControlProtocol, 6,] Issuing update command to relay at IP_MEDIA_RELAY 2) Syslog media-relay Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Received new SDP offer Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 5 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50001 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50002 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50003 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Added new stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - Unknown (RTP: Unknown, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] created new session ambvr0-hpa1y...@opensips: 1...@opensips (4g5g2-7QUQV0) -- 08321...@opensips Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] updating existing session ambvr0-hpa1y...@opensips: 1...@opensips (4g5g2-7QUQV0) -- 08321...@opensips Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Received updated SDP answer Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Got initial answer from callee for stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: Unknown, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: IP_T38MODEM:10024, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: IP_PUBLIC_PATTON:10002, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: IP_T38MODEM: 10024, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: IP_PUBLIC_PATTON:10002, RTCP: IP_PUBLIC_PATTON:10003) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM: 10024 (RTP: IP_T38MODEM:10024, RTCP: Unknown) 3) Sip Trace (opensips/media-dispatcher) U IP_PUBLIC_PATTON:5061 - IP_OPENSIPS:5060 INVITE sip:08321...@opensips SIP/2.0. From: PattonFAXsip:1...@opensips;tag=4g5g2-7QUQV0. To: sip:08321...@opensips. Call-ID: ambvr0-hpa1y...@opensips. CSeq: 112 INVITE. Via: SIP/2.0/UDP 192.168.1.253:5061;branch=z9hG4bK1M0f2-NN50iMEOI0. Contact: PattonFAXsip:1...@192.168.1.253:5061. Max-Forwards: 70. Route: sip:IP_OPENSIPS:5060. User-Agent: 20n/021106. Allow: INVITE,BYE,CANCEL,OPTIONS,PRACK,NOTIFY,UPDATE,REFER. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 233. . v=0. o=1004 192916 1 IN IP4 192.168.1.253. s=-. c=IN IP4 192.168.1.253. t=0 0. m=audio 10002 RTP/AVP 8 0 96. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:96 telephone-event/8000. a=ptime:30. a=rtpmap:96 telephone-event/8000
Re: [OpenSIPS-Users] mediaproxy 2.3: reinvites' SDP not modified
Il giorno 06/gen/09, alle ore 20:10, Ruud Klaver ha scritto: Maybe you can still find it somewhere in your syslog? Grep for image, which is the media type used by T.38 IIRC. The point is that we tried to implement this well, but it was very difficult actually obtaining test devices to see if it worked in a real life testbed. Hi Ruud, I'm working now on t.38 fax with opensips 1.4.3 + mediaproxy 2.3.1 and I have the same problem as Jeff. Here's my scenario. I have a fax connected to a patton (sip number 1004) with a private ip (192.168.1.253) and a hylafax/t38modem (sip number 0832) with a public ip (IP_T38MODEM). Calls are established at g711, proxied with engage_media_proxy() (all is ok as i can see, the c=line has the media-relay ip), but when there is a re-invite for t38 the media is not proxied and the packets have c=line with original ip (private and public) (In this way t38modem sends packets to the private ip...). There's no image media type in syslog. The problem is in both ways (patton to t38modem and t38modem to patton). If the patton has the public ip all works fine. I have some logs. I hope these information can be useful for you (sorry for the length :-)): Thanks and Regards, Carlo Dimaggio --- 1) Syslog media-dispatcher Feb 7 21:02:49 sip media-dispatcher[4614]: [OpenSIPSControlProtocol, 7,] Issuing update command to relay at IP_MEDIA_RELAY Feb 7 21:02:49 sip media-dispatcher[4614]: [OpenSIPSControlProtocol, 6,] Issuing update command to relay at IP_MEDIA_RELAY 2) Syslog media-relay Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Received new SDP offer Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 5 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50001 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50002 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50003 Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Added new stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - Unknown (RTP: Unknown, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] created new session ambvr0-hpa1y...@opensips: 1...@opensips (4g5g2-7QUQV0) -- 08321...@opensips Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] updating existing session ambvr0-hpa1y...@opensips: 1...@opensips (4g5g2-7QUQV0) -- 08321...@opensips Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Received updated SDP answer Feb 7 21:01:21 media media-relay[3339]: [RelayClientProtocol,client] Got initial answer from callee for stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: Unknown, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: Unknown, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: IP_T38MODEM:10024, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: IP_PUBLIC_PATTON:10002, RTCP: Unknown) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM:10024 (RTP: IP_T38MODEM: 10024, RTCP: Unknown) Feb 7 21:01:21 media media-relay[3339]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) 192.168.1.253:10002 (RTP: IP_PUBLIC_PATTON:10002, RTCP: IP_PUBLIC_PATTON:10003) - IP_MEDIA_RELAY:5 - IP_MEDIA_RELAY:50002 - IP_T38MODEM: 10024 (RTP: IP_T38MODEM:10024, RTCP: Unknown) 3) Sip Trace (opensips/media-dispatcher) U IP_PUBLIC_PATTON:5061 - IP_OPENSIPS:5060 INVITE sip:08321...@opensips SIP/2.0. From: PattonFAXsip:1...@opensips;tag=4g5g2-7QUQV0. To: sip:08321...@opensips. Call-ID: ambvr0-hpa1y...@opensips. CSeq: 112 INVITE. Via: SIP/2.0/UDP 192.168.1.253:5061;branch=z9hG4bK1M0f2-NN50iMEOI0. Contact: PattonFAXsip:1...@192.168.1.253:5061. Max-Forwards: 70. Route: sip:IP_OPENSIPS:5060. User-Agent: 20n/021106. Allow: INVITE,BYE,CANCEL,OPTIONS,PRACK,NOTIFY,UPDATE,REFER. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 233. . v=0. o=1004 192916 1 IN IP4 192.168.1.253. s=-. c=IN IP4 192.168.1.253. t=0 0. m=audio 10002 RTP/AVP 8 0 96. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:96 telephone-event/8000. a=ptime:30. a=rtpmap:96 telephone-event/8000
[OpenSIPS-Users] Behaviour of enum_pv_query
Hi all, In my config I'm using enum_pv_query(pvar) instead of enum_query() because all my R-URI are like 00390 and not +390, so I create a pvar without the 00 and with '+'. I always receive ERROR:enum:enum_pv_query_3: R-URI user is not an E164 number: in fact, my R-URI is not an E164 number... But I don't know why there is such control for R-URI in enum_pv_query_3, I use this function to bypass checking of R-URI! Perhaps there is a requirement in E164 RFC? I would like to understead this behaviour... Thank you! Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Upgrade CDRTool to 6.7.1 - problems
Il giorno 29/dic/08, alle ore 15:51, Adrian Georgescu ha scritto: Carlo, From your description it looks like an incorrect configuration in global.inc. If I were you I would start with a fresh global.inc.simple.sample and port the settings from the old version. Adrian Hi Adrian, Thank you for your reply. I created another global.inc starting from global.inc.simple.sample but the problem still remained. After that, I have dropped the cdrtool db and created another through the new script setup_mysql.sh. (ver. 6.7.1) Now the problem is solved and I can connect to the web interface. So I think that there was some differences between the database schemas... Regards, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Upgrade CDRTool to 6.7.1 - problems
Anybody can help me? Where I can find more informations about this datasource ERROR? Thank you! Il giorno 23/dic/08, alle ore 22:23, Carlo Dimaggio ha scritto: Hi all, I have some problems with the upgrade of CDRTool from 6.6.10 to 6.7.1. I have downloaded the debian package (my machine is an ubuntu server) and followed the instruction included in http://download.ag-projects.com/CDRTool/doc/Upgrade.txt . Now I can start (and reload) successfully cdrtool but if I connect to the web interface this error is shown: Error initializing CDRTool datasource sip_trace Before the upgrade all was fine (mysql user/pass, permissions, configurations,...). There are no errors in syslog. How can I debug the problem? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Upgrade CDRTool to 6.7.1 - problems
Anybody can help me? Where I can find more informations about this datasource ERROR? Thank you! Il giorno 23/dic/08, alle ore 17:15, Carlo Dimaggio ha scritto: Hi all, I have some problems with the upgrade of CDRTool from 6.6.10 to 6.7.1. I have downloaded the debian package (my machine is an ubuntu server) and followed the instruction included in http://download.ag-projects.com/CDRTool/doc/Upgrade.txt . Now I can start (and reload) successfully cdrtool but if I connect to the web interface this error is shown: Error initializing CDRTool datasource sip_trace Before the upgrade all was fine (mysql user/pass, permissions, configurations,...). There are no errors in syslog. How can I debug the problem? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Upgrade CDRTool to 6.7.1 - problems
Hi all, I have some problems with the upgrade of CDRTool from 6.6.10 to 6.7.1. I have downloaded the debian package (my machine is an ubuntu server) and followed the instruction included in http://download.ag-projects.com/CDRTool/doc/Upgrade.txt . Now I can start (and reload) successfully cdrtool but if I connect to the web interface this error is shown: Error initializing CDRTool datasource sip_trace Before the upgrade all was fine (mysql user/pass, permissions, configurations,...). There are no errors in syslog. How can I debug the problem? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Upgrade CDRTool to 6.7.1 - problems
Hi all, I have some problems with the upgrade of CDRTool from 6.6.10 to 6.7.1. I have downloaded the debian package (my machine is an ubuntu server) and followed the instruction included in http://download.ag-projects.com/CDRTool/doc/Upgrade.txt . Now I can start (and reload) successfully cdrtool but if I connect to the web interface this error is shown: Error initializing CDRTool datasource sip_trace Before the upgrade all was fine (mysql user/pass, permissions, configurations,...). There are no errors in syslog. How can I debug the problem? Thanks, Carlo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
