Re: [OpenSIPS-Devel] New Transformations Available
Am 18.08.2010 11:03, schrieb Vlad Paiu: The IP transformations currently return the binary format of the IPs in a string format, to keep compatibility with both IPv4 and IPv6. Makes absolutely sense :) The bitwise operators in OpenSIPS currently only work with integers. We are now expanding the bitwise operators to also work with string variables, and a fix will be committed as soon as we finish. This has been my doubt :p Bitwise operators working with string variables would be great, I'll stay tuned! Regards, Thomas -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] New Transformations Available
Hey, that's great!
Please feel free to close my corrsponding feature request #3028431 ;-)
This should finally allow to check for example whether a Contact uri
points to a specific subnet (security checks!). The following example
shall deny REGISTER requests with Contacts pointing to your own network
(e.g. 192.0.2.128/25):
if ($ct{uri.host}{ip.isip}) {
if (($ct{uri.host}{ip.pton} 255.255.255.128{ip.pton}) ==
192.0.2.128{ip.pton}) {
xlog(L_ERR, Rejecting REGISTER pointing to OURNET);
send_reply(403, Invalid Contact);
exit;
}
}
Please note that this is just a really simple example, a full check
would have to loop through ALL provided Contacts.
Vlad: I didn't test it yet, but I guess it should work that way,
shouldn't it?
Best regards,
Thomas Gelf
Am 17.08.2010 17:30, schrieb Vlad Paiu:
The ip transformations add the possibility to store a string
representation of an IP into a binary format, and the other way round.
You can also check if a string is a valid IP address, get the family of
a binary IP representation ( INET or INET6 ) and resolve a domain name
to get its corresponding string IP address.
...
For more extended examples of using the newly available transformations,
visit http://www.opensips.org/Resources/DocsCoreTran .
--
mail: tho...@gelf.net
web: http://thomas.gelf.net/
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [ opensips-Bugs-3028327 ] nat_traversal damaged between r6844 and r6972?
Hey, my blind guesses are not that bad, aren't they? :p Submitted By: Thomas Gelf (thomas_gelf) Initial Comment: ... Just a wild guess: could it have been caused by the bug fixed in r7008? Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Fixed by commit 7008 - there was a problem with parsing of the expires contact param. Richard, Bogdan: thanks a lot! I upgraded to r7012, it's looking good until now - will wait unless some test client expires regularly and let you know the result tomorrow. Regards, Thomas -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Soon you can Blink!
As I work on Linux only I asked someone to hand me over a Mac for 20 minutes, did some (really quick) tests and captures: * first of all: compliments, really well done! * also great to see G.722 support * ICE announcements look correct, unfortunately I did not have enough time to test it with another ICE-capable device / software, they are rare... * How does it figure out it's reflective candidate if I didn't configure a STUN server? * Configuring a STUN server AND enabling ICE seems to cause problems, it didn't place calls any more. I must confess that the person testing it was sitting in another room, I was an the phone with him and sniffing at proxy side. Therefore it could also be that he misstyped the STUN server domain... * SIP MESSAGE (SMS) looks good, special characters are encoded * It has problems with special characters (example: german umlaut) if configured as display name. Blink immediately says ...cannot encode charaters... in the Add New Account dialog * Did not test MSRP That's all for now, will do deeper tests as soon as it is available for Linux ;-) Cheers, Thomas Adrian Georgescu schrieb: http://wiki.icanblink.com/ Blink implements RTP audio sessions (VoIP), session based Instant Messaging (IM), file transfer and multi-party chat sessions using MSRP protocol and its relay extension, desktop sharing using VNC protocol, publication and subscription for rich presence information such as availability, moods, activities and geo-location, management for the presence rules, resource lists, RLS services documents using XCAP protocol. You can receive a notification when the software become available or participate to our early adopter program by registering on the mailing list: http://lists.ag-projects.com/mailman/listinfo/blink -- Adrian -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Soon you can Blink!
Adrian Georgescu schrieb: * How does it figure out it's reflective candidate if I didn't configure a STUN server? The stun server must be in DNS of the caller domain or you can add them manually in Account - Advanced - Nat Traversal section Ok, that explains it - STUN server has been in the DNS :) But also adding it manually to Account - Adv... AND enabling ICE somehow blocked Blink when trying to place a call, at least it didn't do anything - and it didn't send packets to my SIP proxy. At least that's what I have been told, have not been sitting in front of that MAC while we did the tests with those different settings... Still it has to work when stun does not work. Any visible reason in / var/log/system.log or Debug window ? No idea, sorry. And the MAC is no longer here :( I'll try it with more calm once I get one next time! * It has problems with special characters (example: german umlaut) if configured as display name. Blink immediately says ...cannot encode charaters... in the Add New Account dialog We will check this. Great! -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Soon you can Blink!
Adrian Georgescu wrote: If you get the latest SIP SIMPLE command line clients (they work on Debian at least) they all have the ICE feature and display the outcome of ICE negotiation when RTP stream is active. I'll give them a try, thanks a lot! Best regards, Thomas -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Soon you can Blink!
Adrian Georgescu wrote: Again all you do with Blink can you can reproduce with the command line tools from SIP SIMPLE client SDK. Any luck installing those? Running Karmic Koala on my laptop. Discovering why python-xml won't run was possible, but it sound's like this package will not have much future. Installing python-xml from Lucid repository worked, but I don't know whether it would work :p python-xml from lenny for example doesn't like python = 2.6. And so does python-sipsimple - shall I force installation, or shall I better install Lenny to a chroot dir? You can toggle Trace Notifications in sip-session or sip-audio-session too. I'll do so - as soon as it works ;-) -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Using OpenSIPS/MediaProxy infrastructure with ICE enabled - looking for feedback
Additional note: I did not yet start my tests, but I already made some captures and gave a look at the SDP body generated by those snom phones allowed to use ICE. It seems that they are still doing ICE as proposed in draft-rosenberg-sipping-ice - and not as in the RFC-to-be mmusic draft. The new OpenSIPS/Mediaproxy enhancement does not have support for this legacy ICE variant, does it? Regards, Thomas Thomas Gelf wrote: As I consider ICE one of the most exciting and underestimated features in the SIP world, I decided to dedicate ICE a whole test day within this week. I'll set up a dedicated OpenSIPS proxy, a single MediaProxy relay and make intensive tests using a few snom phones (370, 820, 870 - they all shall support ICE) behind different NAT types (symmetric and others). I'll let you know the result as soon as I have done so. In the meantime a big hug for all your effort and for your great software! Cheers, Thomas Adrian Georgescu wrote: If someone else has ICE enabled end-points, can test and provide us with feedback about the success rate of the ICE negotiation would be great to fine tune the software! -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Using OpenSIPS/MediaProxy infrastructure with ICE enabled - looking for feedback
Adrian Georgescu wrote: We support the current and latest version, the version that is going to become an RFC (is now in the RFC editor queue). Thought so. Depending on which previous version of ICE the device implement they may work or not only real testing can show. Unfortunately what they are doing looks more like the initial draft, as written by the sipping-WG: http://tools.ietf.org/html/draft-rosenberg-sipping-ice-01 There was also some post from snom on the sipping ML while alternatives and better strategies have been discussed. Then finally Rosenberg announced the new draft and explained the move: http://www.ietf.org/mail-archive/web/sipping/current/msg05449.html At this point snom probably decided to no longer go invest development time unless ICE is getting stable. And the following post (nearly two years later) let's me believe that their implementation is still the one it was at that time: http://www.ietf.org/mail-archive/web/sipping/current/msg08461.html I reported my thoughts to snom, waiting for feedback... In the meantime: thank you once again! Cheers, Thomas -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Using OpenSIPS/MediaProxy infrastructure with ICE enabled - looking for feedback
As I consider ICE one of the most exciting and underestimated features in the SIP world, I decided to dedicate ICE a whole test day within this week. I'll set up a dedicated OpenSIPS proxy, a single MediaProxy relay and make intensive tests using a few snom phones (370, 820, 870 - they all shall support ICE) behind different NAT types (symmetric and others). I'll let you know the result as soon as I have done so. In the meantime a big hug for all your effort and for your great software! Cheers, Thomas Adrian Georgescu wrote: If someone else has ICE enabled end-points, can test and provide us with feedback about the success rate of the ICE negotiation would be great to fine tune the software! -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-News] NEW additions to configuration file routes
Anca Vamanu wrote:
1. The routes can have string names also...
I wished this was true long time ago, once I was fiddling with numerical
IDs ;-) Since using M4 macros it is no longer an issue, nonetheless I
consider it a useful and comfortable addition making routing script
writer's life easier.
2. Two new types of routes were added.
Cool! I have no immediate use for them, but I'd really like to make use
of the cache module sooner or later - and cache warmup would be an
important task in that case.
3. One new type of *onreply_route* was added: *per branch on reply
route*. Sometimes it is useful to know in a reply route to which branch
it belongs to. Now this is very simple to achieve - if you call
t_on_reply(name) from a branch route then only the replies for that
branch will go through onreply_route[name].
WOW, that's what I've been waiting for! As I have been talking with
Bogdan regarding this missing and IMO really important puzzle piece
(thanks for changelog credits, btw!), I'd like to to take the occasion
to point out that another related important addition has been made:
$T_branch_idx has been corrected / improved
Let me provide a short example showing what this could be used for:
route(use_mediaproxy_for_branch) {
$var(helper) = null;
$var(helper) = br_ + $T_branch_idx + _mp;
store_dlg_value($var(helper), 1);
}
route(branch_uses_mediaproxy) {
$var(result) = null;
$var(helper) = br_ + $T_branch_idx + _mp;
fetch_dlg_value($var(helper), $var(result));
return $var(result);
}
Better-looking constructs like
$dlg(br_ + $T_branch_idx + _mp)
are not (yet?) possible, but at least as shown above it (should) work.
Why I'm doing so? This simulates per-branch-dialog-vars. You are now
able to fork an INVITE transaction to multiple endpoints with different
requirements to your routing script (e.g. whether to use mediaproxy or
not).
This solves issues with calls from UACs with public IP forked to
a) UAC on public IP, no need for Mediaproxy, packet gets relayed
b) UAC with NAT issue, [use|engage]_media_proxy, packet with modified
SDP is relayed
If a) picks up the call, SDP in it's reply will be mangled, RTP will
fail. Since per-branch reply_routes are working as expected, the above
example will help. Another option would be a combination of branch flags
(callee has nat issue) and dialog vars (caller has nat issue) - if you
don't like this $dlg-fiddling-voodoo ;-)
Just my 2 Eurocent. Thank you for this improvement!
Best regards,
Thomas Gelf
--
mail: tho...@gelf.net
web: http://thomas.gelf.net/
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] questions about inter-domain roaming
zhangchao1 wrote: Hello everybody, I have some questions about Inter-domain Roaming. ... Here is my experiment environment(the picture above):there are two Domains A and B, C1、C2 belong to Domain A, C3 to Domain B, P1 and P2 are proxy server. C1 roams in Domain B and register to P1 through P2. then C2 want to make a telephone to C1... It doesn't matter where C1 is to be found, it will always be registered to P1. P1 will be able to reach it, takes care of keepalives, NAT fixes etc. Both P1 and P2 shall obviously record_route. Doing so C2 will always be able to call C1 (using it's proxy P1). If C3 wants to call C1 (belonging to a foreign domain) it shall use P2 as outbound proxy, P2 will look up C1's domain (eventually repecting SRV records) and send the call to P1. As we learned before, P1 will be able to contact C1. There will be no SIP packets from peer to peer, if you allow that (and don't record_route) you will be lost. Best regards, Thomas Gelf -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Test results for per-branch reply routes
Hi All, I can report that it works like a charme, as it has been promised! Tried forking call to NAT and non-NAT UAC, uac_replac_both branches, short: all kind of bad stuff ;-) The only thing I discovered failing badly: uac_replace_to works if called in a branch route - however if there are multiple branches restoring To: in reply packets fails badly. Best regards, Thomas Gelf -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Contact matching decisions if NAT fails
Hi All, after a short IRC chat with Bogdan I decided to post the following to SIP-Implementors: https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-September/023591.html I'd really like to hear your opinions - IMO it would be a useful improvement for OpenSIPS, RFC-conform, not doing harm to existing installations (beneath some users being online twice immediately during upgrade I guess) - we could also add a config switch for this behaviour, but I don't think that would be necessary. Cheers, Thomas -- mail: tho...@gelf.net web: http://thomas.gelf.net/ ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] STUN module
Razvan Pistolea wrote: Added new module - STUN server(rfc 3489) implementation. Hey, that's great!! In my understandings this is not a complete implementation of RFC 5389 - but it should provide some/most of it's functionality. Is this assumption correct? As far as I understood it suffices to provide basic STUN support - and that would be all that I need ;-) There are however some remaining questions: - I'm currently using stund, clients have configured either no port (using the default 3478) or have manually set their port to 3478 - As far as I understood OpenSIPS' STUN module is not able to run on multiple ports (i.e. 5060 as of rfc5389 and 3478 as of rfc3489), however it suggests using 3479 as secondary port (and 5060 as the default one) - Therefore: to provide RFC 5389 and 3489 support without requiring customers to reconfigure their clients, I'll remain with two STUN servers, stund and OpenSIPS?! - And if so: I need to choose a port different from 3479 as secondary port for OpenSIPS, do I? Which one would you suggest? - Is there an easier solution? Is it possible to drop stund and use the OpenSIPS module on port 3478 and 5060? - Are there clients already making use of RFC 5389? Best regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] STUN module
Razvan Pistolea wrote: Thx for the enthusiasm! The plan was to wait until Monday for an announcement but what the hell. Sorry ;-) - As far as I understood OpenSIPS' STUN module is not able to run on multiple ports (i.e. 5060 as of rfc5389 and 3478 as of rfc3489), however it suggests using 3479 as secondary port (and 5060 as the default one) You can change the secondary port(3479) to any port... say (3478) and then you don't have to make any change to the clients 3478 is probable not the best choice for the secondary port, but I'll find another one :-p and it even helps the SIP server (not having to differentiate between incoming STUN/SIP messages). I'd like to add it that additional burden, that's the most exciting part of RFC 5389 - you can use STUN for keepalives. Did you already reflect whether it could make sense to let nat_traversal and stun modules somehow talk to each other (e.g. client is sending stun keepalives from socket X, therefore no SIP keepalive is required on that socket)? - Therefore: to provide RFC 5389 and 3489 support without requiring customers to reconfigure their clients, I'll remain with two STUN servers, stund and OpenSIPS?! Yes. Until i implement rfc 5389. Ok. So choosing primary port 3478 and secondary port 3479 to replace stund is probably the way to go right now. Is your stun module a full replacement for stund? Are you aware of a free software allowing to (entirely) test their behaviour? It can work on port 3478 and 5060(primary_port) but you will have (just) a STUN rfc 3478 server. Got it. Running on both of them (= multiple instances) isn't possible, is it? - Are there clients already making use of RFC 5389? I don't know. Me too :-) Anyone else? Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Limitations of dialog module
100% ACK - I'd consider making the dialog module branch-aware a really important (even if difficult) task. As more and more modules are going to rely on it, support for a such generic thing as multiple parallel branches is IMO a must. But please don't ask me how to do so ;-) As Iñaki mentioned, engage_media_proxy is such an example. And as people with multiple registrations are not seldom I need to switch my config back to manual Mediaproxy handling. Did not yet stumble over the PRACK issue as I do not (yet) tear calls down at proxy side. Right now I'm studying b2bua-docs, trying to understand how it works and what it can do ;-) Cheers, Thomas Iñaki Baz Castillo wrote: Hi, some threads ago I talked about dialog module limitations and how those limitations are inherited in modules on top of it. I will list them here again as a separate thread (as Bogdan asked). Note that most probably I'll say nothing new. - Parallel forking: dialog module just creates a dialog entry for each incoming request, even if the proxy forkes the request to varios destinations in parallel. - PRACK and CSeq: Dialog module stores the local and remote cseq for a dialog, but cseq can also change during an early dialog (PRACK and UPDATE methods). In fact, each early dialog can have a different local/remote cseq if PRACK and/or UPDATE occurs for that *early* dialog. Since dialog modules jsut creates one entry for that dialog, the value of local/remote cseq is unreliable. If this value is used to generate a local BYE it could be incorrect. Example: UAC PROXY UAS1 UAS2 - UAC sends the INVITE with CSeq 1. - PROXY does parallel forking to UAS1 and UAS2. - dialog entry has local_cseq = 1. - UAS1 replies 180. - UAS2 requires PRACK. - UAC sends in-dialog PRACK to UAS1 (CSeq = 2). - UAS2 replies 200 OK - UAC sends ACK to UAS2 (CSeq = 2). - Dialog timeout so the proxy generates a BYE to UAS2 with CSeq = local_cseq + 1 = 2. - UAS2 rejects the BYE because it has a wrong CSeq = 2 (it should be at least 3). - Call Control: For a PSTN gateway, an established or in progress call is similar (both requires similar resources in the gw). If a request is forked to 5 different SIP URI's, and all of them are sent to the same GW, the dialog module just counts 1 dialog for that gateway. - CSeq spoofing: If a top level module relies on the existance of an active dialog, it could suffer if the caller/callee does CSeq spoofing. Example: - Alice calls BOB (Alice CSeq = 1). - Alice sends a spoofed BYE wth CSeq = 1. I don't know if dialog module will automatically end or requires to receive a 200 for that BYE: a) Suppose dialog entry is terminated: - But Bob rejects the BYE (bad CSeq). - If Bob doesn't end the dialog by itself, it remains active even if dialog module terminated it. b) Suppose dialog entry is not terminated until receipt of 200 for the BYE. - Bob rejects the BYE (bad CSeq). - Perhaps Bob owuld automatically end the dialog without sending a BYE so dialog module doesn't realize of it. - Media Proxy engage_media_proxy() A method on top of dialog module. In case you want rewrite the SDP just in case the receiver is behind NAT, it's cannot be done if the request is forked and receives various responses, some from natted clientes and some from non natted clients. This is, it must be modified (or not modified) for all the branches. This wouldn't occur if the dialog module would create an entry for each *early dialog* (this is the core missing feature of all this report). Now I read about new b2bua module and wonder if the above would also occur. Regards. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [OT] Re: [NEW] Virtual DB module
Hey, that's curious: I never used MailMan, so not sure whether it is it's own fault, or a bug in whatever software is responsible to generate the web archive. My post has been truncated right before a sentence starting with the magic word From at the beginning of the line. So, at http://lists.opensips.org/pipermail/devel/2009-July/003781.html there is missing the following part: From the active one - of course this requires your databases to be somehow perfectly synchronised. I can see that this can work fine for read operations assuming that the databases are synchronized by external means and wherever you go you get the same information, but for write I do not see where the aggregation layer is to assure that the data is synchronized and consistent. That's not OpenSIPS job - it's up to who is configuring it to take care of synced DBs and such things. OpenSIPS has to drop it's queries somewhere - nothing more. And multiple configured DBs allows you to easily take down one DB server for maintainance without interrupting the service. I consider this a very worthful addition. And there is not so much trouble you can cause if OpenSIPS is either not inserting a record or writing it twice to usrloc - after some time everything will be fine again. The impact is much less than a real downtime. Just my 2 eurocent - please correct me, if I'm wrong! Best regards, Thomas Gelf No one else ever got aware of this? Sure, From is used to split mbox files - but IMO in that case the MDA should somehow escape lines starting with From in your mail body... Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Some ways to crash OpenSIPS with current SVN
Dan Pascu write: Could you, just to rule hardware issues out, run a memory test (using memtest86+)? My nightmare seems to be over! After Bogdan's changes in revision 5889 and 5893 OpenSIPS is finally rock-solid once again! At least I did not (yet) find any method to crash it again. Many thanks for his patience and for the time he dedicated to remotely debug this issues with me! Best regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5847] trunk/modules/nat_traversal/nat_traversal.c
Dan Pascu wrote: That is no wonder. 5783 contained a bug that made segfaults certain (it operated on a different variable than intended). This is why 5784 was made immediately after it. You should not use 5783 at all. The fix Bogdan made, is given by the combination of 5783+5784. What you should use is current trunk with system malloc so we can see if it fixes your problem. Alternatively you can use anything before 5783 also with the system malloc. Right now I'm pretty sure this crashes have been somehow related to the crashes mentioned in my thread Some ways to crash OpenSIPS with current SVN - so I think we can forget about this one... ...at least unless I manage it to discover something new ;-) Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Some ways to crash OpenSIPS with current SVN
Thomas Gelf wrote: My nightmare seems to be over! After Bogdan's changes in revision 5889 and 5893 OpenSIPS is finally rock-solid once again! At least I did not (yet) find any method to crash it again. Many thanks for his patience and for the time he dedicated to remotely debug this issues with me! Best regards, Thomas Gelf One additional note: the reason this happened more or less only to me lies in the fact that QoS is currently the only module using the SDP parser - and it seems that not many people have activated this module (I'm using it to remotely query more details about active calls). The other fix (5889) is for a problem recently introduced - so probably no one is using it in production yet. I'm doing some $ct-voodoo to protect myself against some possible attacks using specially crafted REGISTER requests - and got bitten by the $ct-improving patch. Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Unable to disable PKG_MALLOC
Thank you, now it compiles also without -DPKG_MALLOC. Regards, Thomas Bogdan-Andrei Iancu wrote: Hi Thomas, This should be fixed on SVN trunk... :) Regards, Bogdan Thomas Gelf wrote: Error seems to be introduced with changes in revision 5653. I had to revert changes in 5653-5655 and finally also disabled STATISTICS to be able to use system malloc. Best regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Some ways to crash OpenSIPS with current SVN
Dan Pascu wrote: Could you, just to rule hardware issues out, run a memory test (using memtest86+)? This afternoon I've been busy googling, testing, researching. I blamed Hardware, libc/glib... my current favourite is libmysqlclient. This awful piece of software is sooo ***censored***. I did the following: on the same host (there are different jail-like partitions based on linux-vserver running on it) I got aware of another piece of software, segfaulting from time to time in another vServer: a php-based cronjob. As it is easier to debug such a script combined with php5-cli we started to dig deeper and finally tracked the problem down to one specific bug in libmysqlclient: http://bugs.mysql.com/bug.php?id=42850 This bug is definitively present in Debian Lenny's mysql client library. Could this (or a similar) one be the root of all evil, causing me so many sleepless nights? I'll do some more tests... Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Some ways to crash OpenSIPS with current SVN
Bogdan-Andrei Iancu wrote: I tried revision 5854, using both pkg_malloc and system malloc (if compiled correctly, I'm not sure - see other thread). Easiest way to crash them: restart, start a new dialog, restart while calling, maybe put on hold and pick up - works most of the times. Example backtrace: Tried to reproduce the scenariobut no luck. Could explain a bit in more details ? - the restart takes place during ringing stage or after the call is answered? what is the cfg of the dialog module? Call, pick up, say something, restart... Tried once again, r5784: [New process 10528] #0 0x2b26fc198ed5 in raise () from /lib/libc.so.6 (gdb) bt full #0 0x2b26fc198ed5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x2b26fc19a3f3 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x0041f72f in sig_alarm_abort (signo=value optimized out) at main.c:422 __FUNCTION__ = sig_alarm_abort #3 signal handler called No symbol table info available. #4 0x00474b13 in fm_status (qm=0x2b2702763000) at mem/f_malloc.c:513 f = (struct fm_frag *) 0x2b2702de1f80 i = 4015888029 j = 0 h = 1535 size = 471329333004194 __FUNCTION__ = fm_status #5 0x0041f45c in cleanup (show_status=1) at main.c:363 No locals. #6 0x0041f864 in handle_sigs () at main.c:464 chld = value optimized out chld_status = value optimized out i = value optimized out do_exit = value optimized out __FUNCTION__ = handle_sigs #7 0x00422577 in main (argc=value optimized out, argv=value optimized out) at main.c:871 cfg_log_stderr = value optimized out cfg_stream = (FILE *) 0x0 c = value optimized out r = 16 tmp = 0x7fffaef76eb0 tmp_len = value optimized out port = value optimized out proto = value optimized out ret = value optimized out seed = 2550124078 rfd = value optimized out __FUNCTION__ = main OpenSIPS stopped working - but it took about one minute unless coredump happened?! Usually it is faster - but that's not something I'd like to complain about ;-) or maybe we can see some cores + logs on your system ;) Sure, whenever you have some spare time - cores are awaiting your visit! actually, all the BTs, taken out of the context (scenario, logs, etc) are not very helpful so, maybe we do some joined testing on your platform and find the problem out. I've sent you another interesting one off-list... Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Some ways to crash OpenSIPS with current SVN
Thomas Gelf wrote: I've sent you another interesting one off-list... And another one - this time I made a call, picked it up and then tried to hold/unhold/hold/unhold it very fast - crash. Sent also this one off-list... ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5847] trunk/modules/nat_traversal/nat_traversal.c
Dan Pascu wrote: I do not know about that as I've never tried opensips-1.5 or newer. ... You are the first one to report such an issue in nat_traversal. If it would be a bug in the nat_traversal code, it would become obvious on inspection (especially after a backtrace) and many more people would be affected in a systematic manner. I have it running on dozens of system without any problem... I'm running OpenSIPS dialog-stateful with restart-persistent dialogs and dialog flags/profiles etc. Could this be somehow related to my problem? Please also note: there have been very few such crashes between other MySQL-related ones, my nightmare with some Gigs of corefiles started with revision 5783 and disappeared with 5784, at the cost of loosing a functional keep_alive mechanism ;-) I'll sent you a full backtrace from revision 5780 off-list... Regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] SF.net SVN: opensips:[5847] trunk/modules/nat_traversal/nat_traversal.c
Dan Pascu wrote: I'm a bit confused. You say segfaults started with 5783, but you have a backtrace from 5780? I showed Bogdan my (few, seldom) segfaults that I noticed with 5780, and that resulted in 5783 (causing MANY more segfaults) and finally 5784 (avoiding this special segfault at the cost of making keepalives no longer working correctly). Can you confirm if using system malloc made the problem disappear? No, I can't. I'm pretty sure that with 5783 I'd immediately achieve once again such a segfault - but that's as far as I understood to be expected and not related to the earlier problem (even if segfaults are looking very similar). Yesterday I tried latest SVN with both system- and pgk_malloc. And I was able to crash both of them. But that was for other reasons (see thread Some ways to crash OpenSIPS with current SVN, NOT related to nat_helper. Now I'll better wait for a response to my thread Unable to disable PKG_MALLOC, as I don't feel quite well with an 1.4.4 patch for current trunk ;-) Yesterday I removed -DPKG_MALLOC, reverted some statistic- related changes (r5653-5655) and finally also removed -STATISTICS. That way I was able to compile it (not sure if done correct, but looked good to me). Please note once again, that I never ever wrote C code - it's just thanks to OpenSIPS that I had to dig a little bit into it and teach myself some basics. Therefore I'm mot sure whether my changes where fine ;-) As I absolutely need to keep this system up and running at least during business hours (seldom crashes and restarts by monit are something I can live with - just r5783 was a little bit too heavvy). If you have an idea how to easily reproduce such a crash that would be great - but if really related to memory corruption I doubt that this would probably be not an easy task :-/ Cheers, Thomas ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Unable to disable PKG_MALLOC
Error seems to be introduced with changes in revision 5653. I had to revert changes in 5653-5655 and finally also disabled STATISTICS to be able to use system malloc. Best regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence across reboot
Tested db_mode 1 and 2: both are running fine now. Cheers, Thomas Bogdan-Andrei Iancu schrieb: Hi Thomas, This should be solved now - check the new SVN trunk. Regards, Bogdan Thomas Gelf wrote: Doing some tests after discussion on IRC we discovered that db_mode 2 is fine, db_mode 1 doesn't work as it should... Regards, Thomas Bogdan-Andrei Iancu wrote: I just run the script and it was ok for me :D.So, let's take it step by step. 1) after stopping Opensips (before restating) , do you see the new record in the dialog table ? what is the content of the profiles column ? ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence across reboot
This has also influence on engage_media_proxy - the session is not
terminated if I restart OpenSIPS between ACK and BYE. After timeout
it says:
media-dispatcher[20881]: session with call_id some-call...@domain.tld
from relay 1.2.3.4 did timeout
media-dispatcher[20881]: error: failed to end dialog: 404 Requested
Dialog not found
Cheers,
Thomas
Thomas Gelf wrote:
Hi Bogdan,
I have to correct myself - it's true that it isn't crashing any more,
but it seems that it doesn't it's job, it doesn't store anything to
DB.
To reproduce this, please try:
if(is_method(INVITE) ! has_totag())
{
create_dialog();
set_dlg_profile(test);
}
if(loose_route() is_method(INVITE))
{
if (is_in_profile(test)) {
xlog(L_INFO, Dialog has TEST profile);
} else {
xlog(L_INFO, Dialog does NOT have TEST profile);
}
}
Place a call, restart OpenSIPS, put call on hold (or do whatever
you'd like to do to re-issue an INVITE-request - you'll see that
it's saying that the profile got lost.
Best regards,
Thomas Gelf
Bogdan-Andrei Iancu wrote:
Hi Thomas,
Thanks for the report - the fix is on SVN. Let me know if solved the
problem.
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Core
Immediately after my previous post I hung up - and OpenSIPS crashed. Syslog entries -- OpenSIPS[31293]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled/6xx transaction OpenSIPS[31277]: INFO:core:handle_sigs: child process 31293 exited by a signal 11 OpenSIPS[31277]: INFO:core:handle_sigs: core was generated OpenSIPS[31277]: INFO:core:handle_sigs: terminating due to SIGCHLD Backtrace (PID 31277) - #0 build_res_buf_from_sip_req (code=500, text=0x7d09f790, new_tag=0x2b41aebf85e0, msg=0x2b41b47751a0, returned_len=0x7d09f56c, bmark=0x7d09f550) at msg_translator.c:1633 1633msg_translator.c: No such file or directory. in msg_translator.c Backtrace (PID 31293) - #0 0x0002 in ?? () #1 0x2b41b1de080b in destroy_dlg_callbacks_list (cb=0x2b41b4776f50) at dlg_cb.c:77 #2 0x2b41b1de9b1c in destroy_dlg_table () at dlg_hash.c:154 #3 0x2b41b1dde89f in mod_destroy () at dialog.c:648 #4 0x004575c2 in destroy_modules () at sr_module.c:381 #5 0x0041f2c3 in cleanup (show_status=1) at main.c:332 #6 0x0041fc1b in handle_sigs () at main.c:527 #7 0x00422577 in main (argc=value optimized out, argv=value optimized out) at main.c:871 Any idea what happened? Best regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence across reboot
Makes sense. Never used that function, as the only difference I've seen was that (always empty?) context-line. What context information shall I find there? Cheers, Thomas Bogdan-Andrei Iancu wrote: Hi Thomas, I think this information is more appropriate for dlg_list_ctx function: http://www.opensips.org/html/docs/modules/1.5.x/dialog.html#id272786 right? Regards, Bogdan Thomas Gelf wrote: Another little issue I stumbled over: as there are three new variables available in a dialog, they should also be exported via dlg_list (MI). These are: vars, profiles and script_flags ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] Some additional information regarding reported SQL errors
Hi Bogdan, I realized that if OpenSIPS keeps running for a while, errors appear at a higher frequency. That's why after the restart with your debug-patch it took us so long to finally find an error in my log. Now once again I've had lots of them: ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_execute() failed(2): (1210) Incorrect arguments to mysql_stmt_execute ERROR:usrloc:db_update_ucontact: updating database failed ERROR:usrloc:update_ucontact: failed to update database And after a simple restart they seem to have gone away - for a while. Best regards, Thomas Gelf ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence across reboot
Additional note: I discovered that the qos-module is filling some details into context. So YES, showing dlg vars, profiles and flags in this context field absolutely makes sense to me. Right now there is no way to retrieve them, they are also not to be found in your DB (at least unless you stop OpenSIPS) - so being able to get this information through MI commands would be very helpful. Cheers, Thomas Thomas Gelf wrote: Makes sense. Never used that function, as the only difference I've seen was that (always empty?) context-line. What context information shall I find there? Bogdan-Andrei Iancu wrote: I think this information is more appropriate for dlg_list_ctx function: http://www.opensips.org/html/docs/modules/1.5.x/dialog.html#id272786 right? Thomas Gelf wrote: Another little issue I stumbled over: as there are three new variables available in a dialog, they should also be exported via dlg_list (MI). These are: vars, profiles and script_flags ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence across reboot
Thank you, Bogdan - as already reported on IRC it's not crashing any more! Cheers, Thomas Bogdan-Andrei Iancu schrieb: Hi Thomas, Thanks for the report - the fix is on SVN. Let me know if solved the problem. Regards, Bogdan ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [NEW] Dialog data persistence across reboot
That's great, thank you very much - I'll intensively test it during this weekend! Cheers, Thomas I added to the dialog module support for data persistence (dialog script flags, dialog script variables, dialog profiles) across restart. As this data is highly dynamic nature (may changes very often), it is flushed to DB only at shutdown time - so do not expect to see it in DB during runtime. This will directly affect the script functionality - you can rely on not loosing the dialog context if rebooting, and also the module using dialog module (like load-balancer which needs to keep the profiles in order to do the job). ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
