Re: [SR-Users] [sr-dev] VERY IMPORTANT: deciding when to remove the MI code
On donderdag 1 december 2016 15:17:18 CET Daniel-Constantin Mierla wrote: > RPC is the alternative, a more standardized > concept, with better structured format. Before removing MI and letting everyone move to RPC, it might be wise to go over all RPC interfaces and fix them to be neat , sane and somewhat consistent. For example, there are still interfaces coding arrays as hashes with multiple identically named fields (htable.dump is one i recently ran into) . There is no language and/or JSON/XML library i know of that can properly handle those (most of them will just end up with the last entry). -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route[uac:reply] question
On maandag 19 september 2016 13:34:07 CEST Julia Boudniatsky wrote: > I send INVITE via uac_send_req() and receive "183" and "200"responses. > Only "200" appears in the log of event_route[uac:reply]. > > Is event_route[uac:reply] executed only for final responses? You should be able to set an onreply route in the tm:local-request event_route to catch replies. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Checking if a reply is part of a forked transaction
On woensdag 24 augustus 2016 20:03:57 CEST Phil Lavin wrote: > We're already doing some logic before forking and we considered tracking > call IDs in a hash table... but your idea sounds interesting (better). I > wonder if we can add a parameter to one of the headers in the request. Will > explore this tomorrow. No need to add to headers, just set a transaction flag before forking. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Running both 4.3 and 4.4 with the same database with permission module
On donderdag 18 augustus 2016 12:29:25 CEST Daniel Tryba wrote: > I want to upgrade my cluster from 4.3 to 4.4, beginning with the spare > for live testing. But since there is a change to the trusted table > (which we don't use, only address) this isn't possible without some > tricks. There is no override for skipping the version check on any > permissions table. The changes are backwards compatible with the old version. You can just use another "version" table on the new instance. http://sip-router.org/wiki/cookbooks/core-cookbook/devel#version_table Seems docs haven't made it to kamailio.org. > I need to share the subscriber/location/address/usr_preferences and > db_aliases tables between the 4.3 and 4.4 machines. The only thing I can > think of is: > -patch the permissions module to accept the old version of trusted > -create a 4.4 database and use federated tables to access the 4.3 data > > Not hard to implement any of these 2, but some other modules have the > option to skip these checks, eg: > http://www.kamailio.org/docs/modules/4.4.x/modules/auth_db.html#auth_db.p.ve > rsion_table IMHO that option needs to be removed. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [kamailio 5.0] upgrade VS rollback/backward compatibility
On dinsdag 12 april 2016 11:42:53 CEST Alex Lutay wrote: > The point here that Kamailio checks DB table_version and doesn't start > if the version mismatch found. As long as table versions are backwards compatible, just use a separate "version" table for each Kamailio version you deploy. Set the table version to the one expected by the corresponding kamailio version. -- Alex Hermann Speakup BV ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Removing parameters from user part of URI
On Monday 15 June 2015, Alex Balashov wrote:
On 06/15/2015 04:20 AM, Alex Hermann wrote:
$(rU{select,0,;}) will always select the username with all parameters
stripped.
Will it? What if the parameters precede the username, i.e.
sip:param1=hyz;param2;abc;user@host
I have never heard about that. It is valid syntax according to the ABNF. But
the URI ABNF does not specify user-parameters, the whole part between sip: and
@ is the 'user' part.
If you want to define that ; in the 'user' part defines parameters, IMHO the
only sensible thing to do is put them at the end. Otherwise, what would be the
meaning? How would you know what part is a username? What makes 'user' a
username and not 'param2' or 'abc', or even 'param1=hyz'?
--
Alex.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Removing parameters from user part of URI
On Friday 12 June 2015, Alex Balashov wrote:
Sure, but that presumes that I know the position of the parameter and the
number of parameters.
Why would you need to know that?
I'm looking for a generic approach to lob off all parameters.
$(rU{select,0,;}) will always select the username with all parameters
stripped.
--
Greetings,
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] next via branch value
On Thursday 28 May 2015, Juha Heinanen wrote: The question has been, what value could I assign to extra_id_pv to uniquely identify the branch. Since $T_branch_idx exists, perhaps a good choice could be $sel(via[1].branch) + $T_branch_idx. That would work. Just remember to store the value you use somewhere (RR-param or $sht) to be able to tear down the session when a BYE comes in. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Header Concatenation - is this a Bad Idea?
On Monday 20 April 2015, Nathan Angelacos wrote: So the next thing is to use RFC 3261 7.3 and 25.1 to concatenate the multiple Record-Routes into one longer line (same for Via, Contact, etc.): Doesn't look like there's any kamailio function in textops/x that makes this kind of thing easy; Why would you want to use textops? $(hdr(Record-Route[*])) seems to do the trick. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dialog module shared memory
On Friday 16 January 2015, Charles Chance wrote: Alex's work is still in a personal branch since he ran out of time to finish, IIRC. I have plans to look at it over the next week or so, unless Alex has other ideas. Perhaps he can comment? I couldn't get the dialog+dmq+tm combination in a stable state, it kept crashing on me. Accounting for packet loss and out-of-order events required changes to the dialog module which might have caused the issues. Because i ran out of time i had to abandon that route and went for a quick mod_perl script to send events to an external counter process. I still think the concept is ok and i probably need to take another stab at it, but i have no estimate yet of when that might happen. If anyone wants to pick up, please do. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Redirect Server Including Path/Recieved Information
On Monday 12 January 2015, Daniel-Constantin Mierla wrote: On 09/01/15 15:41, Ben Langfeld wrote: For the ease of future reference, it would appear that post was http://sr-dev.sip-router.narkive.com/bfyDpQ36/git-alexh-master-core-modu les-tm-modules-sl-make-adding-path-and-flags-to-redirected-contacts#post4 Was this merged or discarded? Trying to look at the commit with the hash id from the archive doesn't work. I kept them local due to the perceived lack of interest. Most of the individual patches are still in the sr-dev archive somewhere. They won't apply cleanly to 4.x. If there is interest now, i'll port and commit them when my setup eventually migrates to 4.x. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Unexpected evaluation to false on a phonenumber in $avp
On Monday 05 January 2015 16:19:51 Daniel Tryba wrote:
I'm using an avp to make a redirect decision. Normally this avp contains
Dutch
telephone numbers (+31[0-9]{7,10}). With a simple:
if($avp(dst_redirectnumber))
{
if statements only handle boolean conditions. An avp value does not result
in a boolean, but a string or integer. You should compare the avp to a
specific string or integer value (or $null), or use pv_isset().
(This is since the migration from kamailio 1.5 to sip-router).
--
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to check if reply is retransmission?
On Thursday 13 November 2014, Juha Heinanen wrote: Alex Hermann writes: is there a means to check if reply to t_relay()ed request is retransmission? there is t_is_retr_async_reply(), but that does not apply to regular transactions. I don't think there is a built-in for that. I ended up storing the Via branch parameter of the reply in a htable. how do you access branch value of the first via? do you use transformations since looks like there is no pv for that? I use a select: $sel(via[0].branch) -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to check if reply is retransmission?
On Thursday 13 November 2014, Juha Heinanen wrote: there is new piece of information in your reply though. based on the example on select wiki page, i was going to use index 1: based on your answer, looks like there is a mistake in the example. Probably not, i edited the parameter from 1 to 0 for this example, because from my memory, i needed the 2nd via in my code. Probably my memory had failed. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to check if reply is retransmission?
On Thursday 13 November 2014, Juha Heinanen wrote: i tried to drop 200 ok in default onreply_route if it is retransmission. it didn't work out, however, since looks like branch flags (that i need to make dropping decision) are not available in default reply route. is this intentional? You can try calling t_check_trans() beforehand. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to check if reply is retransmission?
On Thursday 13 November 2014, Juha Heinanen wrote: I read about INVITE server transactions in rfc3261 and looks like the transaction can stay in Completed state (i.e, absorbing 200 OKs) at least 32 seconds. It means that the via branch hash table must in a busy proxy be quite large. I don't think it adds much overhead. Another possibility is to keep state in the transaction, via a flag or avp. I also use $T_reply_last (tmx module) to check if the current response has a different (or same) code as the last response. Maybe you can use that? Since the same info must be available somewhere in the depths of tm module, would it be better if someone with tm knowledge would write a function to access it? I don't think tm recognises a retransmitted reply. It remembers the last reply and it does notice that a reply has already been sent (locally or forwarded). -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] how to check if reply is retransmission?
On Wednesday 05 November 2014 14:35:45 Juha Heinanen wrote: is there a means to check if reply to t_relay()ed request is retransmission? there is t_is_retr_async_reply(), but that does not apply to regular transactions. I don't think there is a built-in for that. I ended up storing the Via branch parameter of the reply in a htable. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy extra_id_pv
On Friday 26 September 2014 16:44:44 Marino Mileti wrote: Hi guys, I've seen that setting the parameter extra_id_pv, every branch should be hae different callid.. How can i set this parameter? I've tried with : modparam(rtpproxy, extra_id_pv, $avp(extra_id)) but in the INVITE message the callid is still the same for all branches. Any suggest? Did you assign a value to $avp(extra) in the script, before calling any of the rtpproxy functions? Did you use the 'b' parameter in the call to rtpproxy_*() functions? -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles
On Friday 22 August 2014, Charles Chance wrote: On 22 August 2014 16:46, Alex Hermann a...@speakup.nl wrote: Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in. Can you expand a little on the state dmq was in? I was hoping to use it as-is, but i encountered issues which had to be resolved before i could even use the module: - As soon as i enabled the dmq module, i experienced segfaults. - It had bad interaction with the maxfwd module - Status updates between hosts were largely ignored. - The configured server_address wasn't used to send messages. It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review. Looking forward to seeing it - may save me the time :) I pushed my WIP to the branch alexh/dialog-sync-wip which also contains dialog and dmq fixes and cleanups. It's WIP, so it might still change. This branch is only compile-tested so far, because i normally develop against 3.2. I just cherry-picked most of my patches to master. Known issues: - Sync get off under load, cause unknown yet, but probably because of out- of-order sync messages. Still on the TODO list: - Delete 'disabled' dmq hosts - Cope better with out-of-order sync messages - Sync initial state - Clean shutdown of DMQ, free all memory - More efficient protocol instead of JSON. Probably just write raw data in the packet, so the receiving side can just use a pointer into the buf instead of having to copy everything. -- Alex -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles
On Monday 25 August 2014, Daniel-Constantin Mierla wrote: Are these patches on top of latest version of dialog module (the ones with unique id per profile)? They're against a1b6093aaee, which includes some commits mentioning a unique id for profiles. I don't know if they interfere during runtime, because i only compile-tested it before pushing. -- Alex. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] rfc: distributing dialog profiles
On Friday 22 August 2014 16:52:59 Daniel-Constantin Mierla wrote: The next step is to build the notification system between kamailio instances. There are couple of options, as well as questions, that I want to discuss before going to implement the mechanism. There are two major aspects to care of: A) Distribution, I thought of two options for it: 1) using dmq module to publish the operations done with local profiles (add/remove) -- this seems to be the natural choice right now, Charles Chance is also willing to put effort in this direction This will be coded inside the module, so config won't be affected much (eventually some extra parameters of dialog flags). Last week, i just built profile synchronisation in the dialog module, based on dmq. It took quite a bit of debugging time because of the state dmq was in. It still has some rough edges, but i'll try to push a branch (shortly after) this weekend for review. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] function to reset all flags or bflags?
On Monday 14 July 2014, Juha Heinanen wrote: there is a function to reset a flag or bflag, but i haven't found one that would reset all flags or bflags. is there a way to do it? if not, is it ok to add such function? $mf is an R/W variable, you could assign 0 to it. Maybe $bf is R/W also, but it isn't documented as such. -- Alex ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] uri parameter value case sensitiveness
On Friday 16 May 2014 20:15:11 Daniel-Constantin Mierla wrote: Thanks for this information, clear with comparison. However, more specific to what I am looking for: If I add in INVITE: Record-Route: sip:1.2.3.4;abc=XYZ Is allowed to the other party to set next header in BYE? Route: sip:1.2.3.4;abc=xyz RFC 3261 says the Record-Route must be _copied_ into the response and the route set must be _set_ to the Record-route value. Nowhere it says a UA is to parse or manipulate the uri's beforehand. So, IMHO, an element inserting a Record-Route header must receive the corresponding Route header in the exact same way it was sent. 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. ... The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. 12.1.2 UAC Behavior The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. 12.2.1.1 Generating the Request If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] OT: Excessive or fatal bounces for yahoo, hotmail, ...
On Tuesday 29 April 2014, Daniel-Constantin Mierla wrote: 1) upgrade mailman to 2.1.16 which has an option to replace From header with the address of the mailing list. Please don't. Mailing list mangling the reply-to header are already worse enough, mangling the From makes it unbearable. 2) ask those people with yahoo/hotmail/... to use different email provider Combined, yahoo+hotmail account for a bit more than 200 addresses on sr-users. But with about 8 posts in the last 4 years, half of them spam. What people here prefer? Any other solution? Just automatically remove addresses that bounce a few times, it is commonly done on many mailinglists. Recipients are themselves reponsible for a properly operating mailserver. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] event_route[tm:branch-failure] question
On Monday 14 April 2014, Daniel-Constantin Mierla wrote: Incoming request is stored in transaction with all the changes done in request_route until the transaction is created. A matter of what was the r-uri at the moment of creating transaction, you will retrieve it in the tm specific routing blocks when such route block handles the incoming request (what is stored in t-uas). Isn't the stored state (from t_newtran()) updated on t_relay()? Iirc, at least some fields seem to have the values from t_relay() time, not t_newtran(); -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] sql_xquery() and xavp checks
On Saturday 05 April 2014 17:32:18 Alex Balashov wrote: When using sql_xquery() like this: sql_xquery(ca, SELECT * FROM gateways, gateways); ... what's a good way to check if any rows were returned? Since one does not have a $dbr(gateways=rows) value in this scenario, what should one do? All sqlops query functions have (undocumented) return values: -1: error in parameters or query execution 1: query successful, at least one row in resultset (for SELECTs) 2: query successful, no rows returned It might be useful to extend $sqlrows() to return the number of rows in the resultset. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Registrar, usrloc and duplicate keys
Hello, I'm upgrading a 1.5 install to 4.0 and encounter a problem with registrations from a phone. The phone lost power and after rebooting it starts a new registration while the old registration hasn't expired yet. The phone uses the same aor and contact but a different call-id (and cseq) which all seems ok and used to work with 1.5.x. Problem 1) When receiving this new registration, kamailio is trying to update the old registration even though the new registration doesn't match the old one. The database responds with 0 rows updated because the call-id is different. Problem 2) To try to circumvent problem 1, i have usrloc configured to try an insert instead when the update fails. That insert fails because kamailio is trying to insert with the same ruid as the old registration. Combining those, the real problem seems to be that kamailio is assigning the same ruid to both registrations. How could that be prevented? The config parameters are set so that it matches my old 1.5 config as much as possible. No need for outbound, gruu, etc. (Phone does send an +sip.instance, which happens to be identical in both registrations. I have gruu_enabled set to 0, so i would expect kamailio to ignore it as it did in 1.5. The outbound module is not loaded). modparam(registrar, min_expires, 60) modparam(registrar, default_expires, 1800) modparam(registrar, default_q, 0) modparam(registrar, path_mode, 0) modparam(registrar, use_path, 1) modparam(registrar, path_use_received, 1) modparam(registrar, gruu_enabled, 0) modparam(usrloc, db_mode, 2) modparam(usrloc, timer_interval, 20) #modparam(usrloc, db_obs_ruid, 0) # param does not really exist modparam(usrloc, db_check_update, 1) modparam(usrloc, timer_procs, 2) modparam(usrloc, hash_size, 14) modparam(usrloc, matching_mode, 0) -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Registrar, usrloc and duplicate keys
On Tuesday 16 July 2013 15:14:19 Daniel-Constantin Mierla wrote: to fix such cases, we added the option to use ruid for updates to database: http://kamailio.org/docs/modules/stable/modules/usrloc.html#usrloc.p.db_obs_ruid Something seems a bit wonky here. As you could see in my config fragment, i commented this parameter because it doesn't seem to exist. This parameter exists in documentation, but not in code: 0(14392) ERROR: core [modparam.c:152]: set_mod_param_regex: parameter db_obs_ruid of type 2 not found in module usrloc This is on 4.0. I grepped through the repository, in the 4.0 branch the documentation exists, but not the code. In master neither exists. btw, the documentation conflicts with itself. The parameter is specified as a string value, but the explanation and example have integer values (there are more of these type of errors on the same page). $ git show-ref origin/4.0 f8826df994a6baac9cfee219abafa3e1b82ee4f8 refs/remotes/origin/4.0 $ grep -rn db_obs_ruid * ChangeLog:768:- new parameter db_obs_ruid - if set to 1, db update/delete operations modules/usrloc/doc/usrloc_admin.xml:847:section id=usrloc.p.db_obs_ruid modules/usrloc/doc/usrloc_admin.xml:848: titlevarnamedb_obs_ruid/varname (string)/title modules/usrloc/doc/usrloc_admin.xml:860:titleSet varnamedb_obs_ruid/varname parameter/title modules/usrloc/doc/usrloc_admin.xml:863:modparam(usrloc, db_obs_ruid, 1) modules/usrloc/README:70: 3.32. db_obs_ruid (string) modules/usrloc/README:151: 1.32. Set db_obs_ruid parameter modules/usrloc/README:199:3.32. db_obs_ruid (string) modules/usrloc/README:312: 3.32. db_obs_ruid (string) modules/usrloc/README:734:3.32. db_obs_ruid (string) modules/usrloc/README:742: Example 1.32. Set db_obs_ruid parameter modules/usrloc/README:744:modparam(usrloc, db_obs_ruid, 1) On 7/16/13 2:47 PM, Alex Hermann wrote: #modparam(usrloc, db_obs_ruid, 0) # param does not really exist -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] question about rtpproxy r flag
On Friday 12 July 2013 06:59:38 Juha Heinanen wrote: rtpproxy_offer and answer functions have r flag described as follows: r - flags that IP address in SDP should be trusted. Without this flag, rtpproxy ignores address in the SDP and uses source address of the SIP message as media address which is passed to the RTP proxy. how does rtpproxy use this ip address? It directly starts forwarding packets to it. If you don't use this flag, rtpproxsy will wait until it has received poackets from both parties in the call. if sip message comes from behind nat, ip address in sdp is local address, not the address where rtp packets come from. and if this request has passed another (e.g. outbound) proxy before hitting the current one, also source address of sip message is not the address where rtp packets come from. either address thus seems to be useless for rtpproxy. You can make the addres more usefull by rewriting the address with fix_natted_sdp() on the first proxy the UAC reaches (load-balancer). If you don't have that possibility, maybe you can call fix_natted_sdp() on the proxy itself and call msg_apply_changes() before invoking the rtpproxy. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Sending CANCEL
On Thursday 04 July 2013 09:30:21 Grant Bagdasarian wrote: Which module can I use to have Kamailio generate a CANCEL request when it receives a certain reply code? I want to cancel a dialog when Kamailio receives a 181 Call Forwarded. Kamailio 1.5x. had this possibility. unfortunately, it got lost in the merger with SER's tm module. A resurrection of this function would be very welcome. http://www.kamailio.org/docs/modules/1.5.x/tm.html#id2492468 -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Sending CANCEL
On Thursday 04 July 2013 09:55:12 Daniel-Constantin Mierla wrote: On 7/4/13 9:52 AM, Alex Hermann wrote: On Thursday 04 July 2013 09:30:21 Grant Bagdasarian wrote: Which module can I use to have Kamailio generate a CANCEL request when it receives a certain reply code? I want to cancel a dialog when Kamailio receives a 181 Call Forwarded. Kamailio 1.5x. had this possibility. unfortunately, it got lost in the merger with SER's tm module. A resurrection of this function would be very welcome. http://www.kamailio.org/docs/modules/1.5.x/tm.html#id2492468 It was not lost: http://www.kamailio.org/docs/modules/4.0.x/modules/tmx.html#idp2473632 I forgot about tmx, luckily the function is still available. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] i386 vs. amd64
On Friday 10 May 2013, Daniel-Constantin Mierla wrote: On 64bit, a memory pointer is 8 bytes instead of 4 as on 32bit. The same applies to 'long' type which has the same size of the pointer on each architecture. From here you get more memory usage on 64bit, because many internal structures hold pointers or long values. Kamailio would probably benefit from using the X32 ABI. By their own definition: 32 ABI is designed for environments where the current ia32 ABI is sufficient. It can be viewed as ia32 with register extended to 64-bit plus 8 more registers as well as IP relative address. Everything else is still 32-bit. Unfortunately it's not (yet) an offically supported arch/port on Debian. https://sites.google.com/site/x32abi/ http://wiki.debian.org/X32Port Alex. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [PATCH] Memory corruption using s.substr transformation
On Tuesday 30 April 2013, Martin Mikkelsen wrote: This smells memory corruption. When run under valgrind, valgrind generates this error when that code is run: ==1206== Source and destination overlap in strncpy(0x55e3b2a, 0x55e3b2b, 10) ==1206==at 0x4C25ACF: strncpy (mc_replace_strmem.c:339) strncpy() must be replaced with memmove() when src and dst (may) overlap. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rfc: accounting records time details
On Monday 29 April 2013 11:05:36 Daniel-Constantin Mierla wrote: Here are some suggestions presented so far. 1) store seconds.miliseconds as double - there is a patch (which Please do not use floating point respresentations for values that will be used in accounting. Floating point is imprecise. As the time related columns will most probably be used for billing, the values should be exact. In SQL this means using the DECIMAL or NUMERIC column type. 2) store seconds and microseconds as two separate values. Should be no issues with existing modules. Even more accuracy than above, no issues with other modules, but will require to use two columns (thus four values to compute the duration) Difficult to use in calculations. Any other suggestions? 3) Use native mili/microseconds support for DATETIME or TIMESTAMP in the database. At least MariaBD and PostgreSQL support this. 4) Store mili/microseconds since epoch in a BIGINT column. Say, there will be a new parameter timestamp_mode for acc module: - bit one set - store seconds timestamp as for now (default) - bit two set - store seconds and microseconds in separate integer columns - bit three set - store seconds.miliseconds as double value in one column - bit three set - store seconds.miliseconds as DECIMAL value in one column - bit four set - add mili/microseconds to DATETIME (only valid when bit 1 is set too) - bit five set - store mili/microseconds since epoch as BIGINT value in one column Alternatively, 2 settings can be used, one for storage format and one to choose the precision/resolution. This provides the most flexibility for the user. timestamp_format: datetime (TIMESTAMP or DATETIME) epoch ((BIG)INT or DECIMAL, depending on resolution) split_epoch (2x INT) timestamp_resolution: seconds, miliseconds, microseconds Default would be the current situation: datetime + seconds -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns queries on ipv6 addresses
On Thursday 25 October 2012, Juha Heinanen wrote: an ipv6 address can thus never be a valid domain name. an ipv4 address, on the other hand, is syntactically valid domain name and perhaps someone has populated their local name server with such names. But the application (kamailio) should not attempt a DNS lookup if the hostname is an IP(v4/v6) address, from RFC1123, section 2.1: Whenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal (#.#.#.#) form. The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System. . . . However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic. It would be nice if Kamailio refuses to lookup both IPv4 and IPv6 addresses independent of the address family of listening sockets (see my emails about dispatcher and IPv6, where DNS lookups on IPv6 addressed are only skipped if Kamailio is listening on an IPv6 address). -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] dns queries on ipv6 addresses
On Thursday 25 October 2012, Daniel-Constantin Mierla wrote: On 10/25/12 4:33 PM, Alex Hermann wrote: On Thursday 25 October 2012, Juha Heinanen wrote: an ipv6 address can thus never be a valid domain name. an ipv4 address, on the other hand, is syntactically valid domain name and perhaps someone has populated their local name server with such names. But the application (kamailio) should not attempt a DNS lookup if the hostname is an IP(v4/v6) address, from RFC1123, section 2.1: It does not if it is ipv4 and the target would be an A record, as well as when it is ipv6 and the target would be an record. The thing here relates to disabling ipv6, resulting in only possible target A record, for which ipv6 does not match an ipv4 format, resulting in using the ipv6 for querying an A record. So some extra validation has to be added when one address family is disabled by config, but such addresses can actually occur. Perhaps what Juha suggested with detecting an invalid hostname is the best, avoiding querying for broken dns tokens. Agreed, but simply detecting ip addresses may also be sufficient. Maybe do str2ip _and_ str2ip6 always, independent of the listening sockets. Even if the proxy doesn't use ipv6, doing an A lookup on a literal IPv6 or IPv6 refrence should be avoided. (Currently str2ip6 is skipped if the proxy doesn't listen on an IPv6 address) -- Met vriendelijke groet, Alex Hermann SpeakUp BV T: 088-SPEAKUP (088-7732587) F: 088-7732588 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IPv6 addresses in dispatcher on IPv4 only proxy
On Monday 15 October 2012, Daniel-Constantin Mierla wrote: On 10/11/12 2:11 PM, Alex Hermann wrote: On Thursday 11 October 2012, Daniel-Constantin Mierla wrote: DEBUG: core [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: core [resolve.c:727]: get_record: lookup([IPv6 Address], 1) failed DEBUG: core [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6 Address], 1, 60, 1) DEBUG: core [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: core [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called looking at the code it seems to be ending in doing an A lookup instead of Why would it even query for ? The entry is an IP(v6) address, no lookup should be done at all. -- Met vriendelijke groet, Alex Hermann SpeakUp BV T: 088-SPEAKUP (088-7732587) F: 088-7732588 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IPv6 addresses in dispatcher on IPv4 only proxy
On Monday 15 October 2012, Daniel-Constantin Mierla wrote:
On 10/11/12 2:11 PM, Alex Hermann wrote:
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote:
DEBUG: core [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1),
h=707 DEBUG: core [resolve.c:727]: get_record: lookup([IPv6 Address],
1) failed DEBUG: core [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6
Address], 1, 60, 1)
DEBUG: core [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30)
1 (flags=1) at 707
ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address]
WARNING: core [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called
looking at the code it seems to be ending in doing an A lookup instead
of , a matter of dns_flags value that should be enabled for IPv6 if
you set dns_try_ipv6 global parameter. I couldn't spot where this would
be disabled if no IPv6 listen socket is provided.
in main.c:
if (default_core_cfg.dns_try_ipv6 !(socket_types SOCKET_T_IPV6)){
/* if we are not listening on any ipv6 address = no point
* to try to resovle ipv6 addresses */
default_core_cfg.dns_try_ipv6=0;
}
If you try the trick of adding one udp worker to listen on ::1, like:
socket_workers=1
listen=[::1]
Does it work?
Yes, that works, but I'd like to prevent the process from listening on IPv6 at
all.
I think i'll go with the database view solution or patch dispatcher locally to
skip IPv6 records.
Thanks,
--
Met vriendelijke groet,
Alex Hermann
SpeakUp BV
T: 088-SPEAKUP (088-7732587)
F: 088-7732588
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IPv6 addresses in dispatcher on IPv4 only proxy
On Thursday 11 October 2012, Alex Hermann wrote:
I am using the dispatcher module with a database table shared among
multiple proxies. Some proxies do both IPv4 and IPv6, others only do IPv4.
The problem is when i use an IPv6 address in the dispatcher table. Then
the IPv4-only proxies fail to load the table.
For reference, this little patch solved my issue. Probably not suitable
for inclusion without a config option.
diff --git a/modules_k/dispatcher/dispatch.c b/modules_k/dispatcher/dispatch.c
index 50df1fc..e0dadda 100644
--- a/modules_k/dispatcher/dispatch.c
+++ b/modules_k/dispatcher/dispatch.c
@@ -259,7 +259,14 @@ int add_dest2list(int id, str uri, int flags, int
priority, str *attrs,
LM_ERR(bad uri [%.*s]\n, uri.len, uri.s);
goto err;
}
-
+
+ /* skip IPv6 references if IPv6 lookups are disabled */
+ if (default_core_cfg.dns_try_ipv6 == 0
+ puri.host.s[0] == '[' puri.host.s[puri.host.len-1] == ']') {
+ LM_DBG(skipping IPv6 record %.*s\n, puri.host.len,
puri.host.s);
+ return 0;
+ }
+
/* get dest set */
sp = ds_lists[list_idx];
while(sp)
--
Greetings,
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] IPv6 addresses in dispatcher on IPv4 only proxy
Hello, I am using the dispatcher module with a database table shared among multiple proxies. Some proxies do both IPv4 and IPv6, others only do IPv4. The problem is when i use an IPv6 address in the dispatcher table. Then the IPv4-only proxies fail to load the table. ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 address] WARNING: core [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called ERROR: dispatcher [dispatcher.c:321]: could not initiate a connect to the database ERROR: core [sr_module.c:889]: init_mod(): Error while initializing module dispatcher (/usr/lib/kamailio/modules_k/dispatcher.so) Is there any setting i can use on the IPv4-only proxies to make it skip the IPv6 records? (apart from listening on an IPv6 address) -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IPv6 addresses in dispatcher on IPv4 only proxy
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote: is USE_IPV6 compile flag still on? Yes, the exact same verion is used on the IPv4 and IPv6 proxy processes. They're even on the same host. Do you get any other error/debug message before that can give an hint why is failing? Unfortunately not. On 10/11/12 10:53 AM, Alex Hermann wrote: Is there any setting i can use on the IPv4-only proxies to make it skip the IPv6 records? (apart from listening on an IPv6 address) don't they have access to a dns server that could I'm not sure i understand this sentence. A DNS trace show this remarkable lookup: - DNS Standard query A [IPv6 address] - DNS Standard query response, No such name It seems kamailio isn't recognizing the IPv6 address and tries an A lookup on the address including the square braces. It does this independent from the presence of a listen= statement on an IPv6 address, but the code fails if kamailio isn't listening on an IPv6 address... -- Met vriendelijke groet, Alex Hermann SpeakUp BV T: 088-SPEAKUP (088-7732587) F: 088-7732588 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] IPv6 addresses in dispatcher on IPv4 only proxy
On Thursday 11 October 2012, Daniel-Constantin Mierla wrote: On 10/11/12 12:00 PM, Alex Hermann wrote: On Thursday 11 October 2012, Daniel-Constantin Mierla wrote: Do you get any other error/debug message before that can give an hint why is failing? Unfortunately not. Not even debug messages that could lead to failure point if running with debug=3? Sorry, forgot about debug logs. Here they are: DEBUG: core [dns_cache.c:567]: dns_hash_find([IPv6 Address](30), 1), h=707 DEBUG: core [resolve.c:727]: get_record: lookup([IPv6 Address], 1) failed DEBUG: core [dns_cache.c:895]: dns_cache_mk_bad_entry([IPv6 Address], 1, 60, 1) DEBUG: core [dns_cache.c:828]: dns_cache_add: adding [IPv6 Address](30) 1 (flags=1) at 707 ERROR: dispatcher [dispatch.c:325]: could not resolve [IPv6 Address] WARNING: core [mem/f_malloc.c:474]: WARNING:fm_free: free(0) called Is dns_try_ipv6 parameter set to yes in configuration file? I tried with and without it, same result. Anyhow, the dns resolve is done for doing keepalives, if it is an ipv4 only, you will get some errors at runtime because there is no socket for ipv6. Perhaps the fix would require some coding in dispatcher module. An alternative is to use database views to make available only the groups you want in this ipv4 instance. I'll see what i can do about it. Thanks -- Met vriendelijke groet, Alex Hermann SpeakUp BV T: 088-SPEAKUP (088-7732587) F: 088-7732588 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Wrong onreply_route is called after serial forking
Hello, i noticed thet in serial forking, replies to earlier branches arriving after sending out a new branch use the onreply_route of the later branch instead of the onreply_route set before sending the earlier branch How to reproduce: 1) set onreply_route to A 2) relay 1st branch 3) 1st branch times out, internal 408 is created 4) tm send CANCEL to 1st branch 5) in failure route, onreply_route is set to B 6) relay 2nd branch 7) 1st branch responds with 487, and goes into reply_route B instead of A I think each branch should take the reply_route which was set before it got relayed and not pick up later changes meant for other branches. How would i fix this? -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Wrong onreply_route is called after serial forking
On Thursday 11 October 2012, Juha Heinanen wrote: Alex Hermann writes: 1) set onreply_route to A 2) relay 1st branch 3) 1st branch times out, internal 408 is created 4) tm send CANCEL to 1st branch 5) in failure route, onreply_route is set to B 6) relay 2nd branch 7) 1st branch responds with 487, and goes into reply_route B instead of A I think each branch should take the reply_route which was set before it got relayed and not pick up later changes meant for other branches. if first branch already timed out, shouldn't reply in step(7) go to garbage pin instead? No, let me explain it a bit more. At step 2a) a provisional response is received. The proxy is configured with a maximum ringtime (fr_inv_timeout). If that expires, an internal 408 is generated and failure_route is entered (which will launch branch 2. At (almost) the same time the proxy sends a CANCEL to abort branch 1. The uas at the receiving end of branch 1 will however still respond to the INVITE (as it should), hence the 487 from step 7. I need to do specific processing when branch 1 receives a reply, and do that in onreply_route A. Unfortunately, the reply never reaches that code. (In reality, branch 1 is not just 1 branch, but consists of multiple parallel branches, all receiving a reply on the cancelled INVITE. Most of them arrive before the 2nd branch is relayed, those are handled correctly by onreply_route A, but replies that come in later are incorrectly handled by onreply_route B) -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Wrong onreply_route is called after serial forking
On Thursday 11 October 2012, Carlos Ruiz Díaz wrote: I can confirm this behavior. I had a similar scenario when 2 or more branches were setup. First branch timed out, while second branch was being processed a reply from first branch arrived and handled improperly by a routing logic which was configured for the second branch. I isolated each response from the different branches by parsing the branch ID that Kamailio adds to the via header after processing the request. Through this mean, I managed to handle correctly each reply from different branches no matter when the response was received. I thougth of something similar. Using a common onreply_route and $T_branch_idx (but watch out for the bug i reported in another email) or setting branch flags depending on the needed handling. But this kind of defeats the purpose of having the possibility to set different onreply_routes (and makes for very messy onreply_routes). -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Catch error status rewrite by UAS in on_reply
Hello all, i sometimes get a very late reply from a broken client which triggers the following error 9because the call was already continued in another branch): ERROR: tm [t_reply.c:1193]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 200 Not a problem perse, but i would like to catch this error in the script's on_reply route because I need to prevent some actions on the reply if it will not be forwarded to the UAC. Is there a way to do this? -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Failed shared memory allocation even though there's enough free memory
Hello, i'm seeing a lot of failed memory allocations for shared memory after the shared memory has been fully used once (see shmem:max_used_size below). Used_size keeps increasing fast on a heavy loaded server, until it reaches the total_size. From that moment memory allocations start failing and eventually used_size starts dropping. After while, even when there's a lot of free memory, new allocations keep failing. ERROR:tm:build_uac_req: no more share memory (19852) ERROR:tm:t_uac: failed to build message ERROR:presence:send_notify_request: in function tmb.t_request_within ERROR:presence:notify: sending Notify not successful ERROR:presence:publ_notify: Could not send notify for dialog When i request the shmem statistics at such time, there's lots of free memory: shmem:total_size = 268435456 shmem:used_size = 3749696 shmem:real_used_size = 4822288 shmem:max_used_size = 268048584 shmem:free_size = 263613168 shmem:fragments = 62156 This is on 1.5.x, any suggestion on why it keeps failing and how to prevent this error? -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] 503 on DB Error
On Monday 12 December 2011, Daniel-Constantin Mierla wrote: On 12/10/11 11:36 AM, Olle E. Johansson wrote: I have been thinking about this as well. We could implement a db_ping function so we could test in the routing script before calling functions that use the DB. It's harder with stuff that happens in the background, like ACC and SIPTRACE. I don't know what happens with them if the database fails. one option would be to set a config env variable, like db_error, which is set by the db modules on error. Then can be checked in the config and act accordingly. This will require touching the db modules. Alternative is to propagate some return codes up to config file, but this will require changes in all modules interacting with database, including the db modules. How about calling an error_route block when a DB error occurs. Maybe with the proper return stack setup so the admin is able to return to the statement following the failed db query if he doesn't want to end the processing with some failure reply. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] db_mysql Commands out of sync; you can't run this command now
On Monday 29 August 2011, MÉSZÁROS Mihály wrote: Your patch didn't work for me. The kamailio didn't start if i use if ( _rank != PROC_MAIN) So i commented out, both if statement, and now out of sync problem disappeared That should do the trick, but it might be possible to create a zombie connection this way. I don't know how the initialization of modules works exactly, so I can't really help you with this. BUT I am experiencing that in usrloc module, still more then one worker process share the same sql connection: That is weird. AFAIK, connections can't be shared between processes, there seems to be no locking/semaphores/whatever to protect against simultaneous access. Maybe you got lucky in your tests and just didn't have enough traffic to hit the simultaneous access problem (yet). I'm out of ideas here, sorry. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] db_mysql Commands out of sync; you can't run this command now
On Monday 29 August 2011, MÉSZÁROS Mihály wrote:
I am experiencing that in usrloc module, still more then one worker
process share the same sql connection:
I'm sorry, the first patch was totally bogus. Due to the forking of the
childs, they have the same memory layout and a very high chance of allocating
the same address (in their own address space) for the connection struct.
Attached patch should give a thread_id truly unique per connection. If you're
able to find multiple processes using the same thread_id, you've found the
cause.
--
Greetings,
Alex Hermann
diff --git a/modules/db_mysql/km_dbase.c b/modules/db_mysql/km_dbase.c
index d85fe5f..0be7136 100644
--- a/modules/db_mysql/km_dbase.c
+++ b/modules/db_mysql/km_dbase.c
@@ -78,6 +78,13 @@ static int db_mysql_submit_query(const db1_con_t* _h, const str* _s)
return -1;
}
+ if (_h-table _h-table-s)
+ LM_INFO( submit_query: con: %ld table: %.*s query: %.*s\n,
+mysql_thread_id(CON_CONNECTION(_h)), _h-table-len, _h-table-s, _s-len, _s-s);
+ else
+ LM_INFO( submit_query: con: %ld query: %.*s\n,
+mysql_thread_id(CON_CONNECTION(_h)), _s-len, _s-s);
+
if (my_ping_interval) {
t = time(0);
if ((t - CON_TIMESTAMP(_h)) my_ping_interval) {
@@ -163,6 +170,12 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r)
return -1;
}
+ if (_h-table _h-table-s)
+ LM_INFO(store_result: con: %ld table: %.*s\n,
+mysql_thread_id(CON_CONNECTION(_h)), _h-table-len, _h-table-s);
+ else
+ LM_INFO(store_result: con: %ld\n, mysql_thread_id(CON_CONNECTION(_h)));
+
*_r = db_new_result();
if (*_r == 0) {
LM_ERR(no memory left\n);
diff --git a/modules/db_mysql/km_my_con.c b/modules/db_mysql/km_my_con.c
index ce20be2..26a4613 100644
--- a/modules/db_mysql/km_my_con.c
+++ b/modules/db_mysql/km_my_con.c
@@ -119,6 +119,7 @@ struct my_con* db_mysql_new_connection(const struct db_id* id)
ptr-con-reconnect = 0;
LM_DBG(connection type is %s\n, mysql_get_host_info(ptr-con));
+ LM_DBG(connection thread_id is %ld\n, mysql_thread_id(ptr-con));
LM_DBG(protocol version is %d\n, mysql_get_proto_info(ptr-con));
LM_DBG(server version is %s\n, mysql_get_server_info(ptr-con));
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] db_mysql Commands out of sync; you can't run this command now
On Saturday 27 August 2011, MÉSZÁROS Mihály wrote:
I am using the git version of kamailio, and i am experiencing problem
This message is repeated in log with all kind of mysql query
(insert/delete/select)
http://dev.mysql.com/doc/refman/5.0/en/commands-out-of-sync.html
Can you try to reproduce with attached patch and mail the line with the
mysql error as well as the last couple of loglines with submit_query and
store_result having the same con: as the failing query.
You can anonymize the queries as long as it is still deducable which module
submitted the query.
Also send list of modules using the database please.
Only one assumption:
Could it related to this change:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=
dfc2834223b7c6b2e799da5a0876b8096cfdae5e
That one can be safely reverted if you don't use the PV $sqlrows. But please
do above test without reverting this.
--
Alex Hermann
diff --git a/modules/db_mysql/km_dbase.c b/modules/db_mysql/km_dbase.c
index d85fe5f..c192a0e 100644
--- a/modules/db_mysql/km_dbase.c
+++ b/modules/db_mysql/km_dbase.c
@@ -78,6 +78,13 @@ static int db_mysql_submit_query(const db1_con_t* _h, const str* _s)
return -1;
}
+ if (_h-table _h-table-s)
+ LM_INFO( submit_query: con: %p table: %.*s query: %.*s\n,
+_h, _h-table-len, _h-table-s, _s-len, _s-s);
+ else
+ LM_INFO( submit_query: con: %p query: %.*s\n,
+_h, _s-len, _s-s);
+
if (my_ping_interval) {
t = time(0);
if ((t - CON_TIMESTAMP(_h)) my_ping_interval) {
@@ -163,6 +170,12 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r)
return -1;
}
+ if (_h-table _h-table-s)
+ LM_INFO(store_result: con: %p table: %.*s\n,
+_h, _h-table-len, _h-table-s);
+ else
+ LM_INFO(store_result: con: %p\n, _h);
+
*_r = db_new_result();
if (*_r == 0) {
LM_ERR(no memory left\n);
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] db_mysql Commands out of sync; you can't run this command now
On Sunday 28 August 2011, MÉSZÁROS Mihály wrote:
I attached the log file.
If you need detailed log/higher log level, then please let me know.
usrloc seems to be using the same connection from multiple processes:
pid: 18389 and 18391, connection: 0xb7387d5c
Aug 28 12:40:10 hal /usr/sbin/kamailio[18389]: INFO: db_mysql [km_dbase.c:83]:
submit_query: con: 0xb7387d5c table: location query: select
contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified
from location where username='mutf-hd' order by q
Aug 28 12:40:10 hal /usr/sbin/kamailio[18391]: INFO: db_mysql [km_dbase.c:83]:
submit_query: con: 0xb7387d5c table: location query: select
contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified
from location where username='ppke-vjk' order by q
Aug 28 12:40:10 hal /usr/sbin/kamailio[18389]: INFO: db_mysql [km_dbase.c:177]:
store_result: con: 0xb7387d5c table: location
Aug 28 12:40:10 hal /usr/sbin/kamailio[18389]: INFO: db_mysql [km_dbase.c:83]:
submit_query: con: 0xb7387d5c table: location query: update location set
expires='2011-08-28 12:45:10',q=-1.00
,cseq=2,flags=0,cflags=0,user_agent='Polycom HDX 8000 HD (Release -
3.0.2.1-17007)',received=NULL,path=NULL,socket='tcp:195.111.192.7:5060',methods=24575,last_modified='2011-08-28
12:40:10' where
username='mutf-hd' AND contact='sip:mutf-hd@193.225.216.28:5060;transport=tcp'
AND callid='3533311123-1752'
Aug 28 12:40:10 hal /usr/sbin/kamailio[18391]: INFO: db_mysql [km_dbase.c:177]:
store_result: con: 0xb7387d5c table: location
Aug 28 12:40:10 hal /usr/sbin/kamailio[18391]: INFO: db_mysql [km_dbase.c:83]:
submit_query: con: 0xb7387d5c table: location query: insert into location
Aug 28 12:40:10 hal /usr/sbin/kamailio[18389]: INFO: db_mysql [km_dbase.c:83]:
submit_query: con: 0xb7387d5c table: location query: select
contact,expires,q,callid,cseq,flags,cflags,user_agent,received,path,socket,methods,last_modified
from location where username='de-tek-hpc' order by q
Aug 28 12:40:10 hal /usr/sbin/kamailio[18389]: ERROR: db_mysql
[km_dbase.c:131]: driver error on query: Commands out of sync; you can't run
this command now
It probably needs a fix like below because mod_init has also created a db
connection which is inherited by at least one child and ul_dbh is not 0
anymore.
That process needs to be excluded from opening a database connection, all
other childs need to open their own DB connection. I just don't know what
rank mod_init is run as and thus don't know which process to exclude. Maybe
some other dev can jump in.
diff --git a/modules_k/usrloc/ul_mod.c b/modules_k/usrloc/ul_mod.c
index b3a9499..ca50b01 100644
--- a/modules_k/usrloc/ul_mod.c
+++ b/modules_k/usrloc/ul_mod.c
@@ -378,7 +378,7 @@ static int child_init(int _rank)
break;
}
- if (!ul_dbh)
+ if (rank != PROC_MAIN)
ul_dbh = ul_dbf.init(db_url); /* Get a new database connection
*/
if (!ul_dbh) {
LM_ERR(child(%d): failed to connect to database\n, _rank);
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [sr-dev] [regression] Message flags set in branch_route not saved into transaction
On Thursday 25 August 2011, Daniel-Constantin Mierla wrote: Hello, On 8/22/11 6:35 PM, Alex Hermann wrote: On Monday 22 August 2011 16:43:43 Alex Hermann wrote: On Monday 22 August 2011, Alex Hermann wrote: It seems kamailio 3 does not save message flags set in branch route into the transaction. In reply_route and failure_route the flag set in branch_route is unset. In 1.4 this used to work. I would like to get that behaviour back, is this possible? This patch seems to restore old functionality. Would this be ok to commit? Nevermind, i just found t_flush_flags(), which does exactly what i need. was the auto-update of the flags in 1.x? That would have made t_flush_flags() redundant, or maybe the auto-update was in branch route and t_flush_flags() purpose was for failure_route. I want to be sure we don't omit things from 1.x -- t_flush_flags() was also forgotten, added later after a report from Juha. In 1.4, message flags were updated in the transaction unconditionally after branch_route had run. The patch i provided is an exact copy of the relevant code from 1.4 and provides backward compatibility. Adding t_flush_flags() to the end of branch_route in the script accomplishes the same functionality, but requires a script update by the user. IIRC, flags were also copied to the transaction from failure_route in 1.4. Haven't tested though. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Float Comparison
On Thursday 25 August 2011, Daniel-Constantin Mierla wrote:
On 8/25/11 12:54 PM, Alex Hermann wrote:
If you just use fixed-point for fractional values, you can remove the dot
and convert to int.
$(var(float){s.replace,.}{s.int})
By fixed point do you mean when the fractional part has fixed length?
Yes.
There was a typo above, syntax should be:
$(var(float){s.replace,.,}{s.int})
--
Greetings,
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Float Comparison
On Thursday 25 August 2011, Daniel-Constantin Mierla wrote:
$(var(float){s.replace,.,}{s.int})
OK. I am not familiar with the deep details of database value types - to
expect that it is a way that I can get always the trailing 0's for such
value? For example, if I want a db column type with 5 decimals in the
fractional part, for real value 1.5 I will get 1.5
If the column is a NUMBER(n,prec)/DECIMAL(n,prec) type, at least mysql returns
it with full precision. In Kamailio they're converted to string, after which
the above transformation works.
Maybe even direct string comparison can be used on two fixed point values (as
string) with equal precision.
--
Greetings,
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] uac_req: pseudovariables, avps
On Tuesday 23 August 2011, Jon Bonilla wrote: Hi all I'm trying to generate a request using uac_req in a failure route when the call has been canceled. (Kamailio 3.1.3) Here's the code: $uac_req(hdrs) = X-PUSH-Type: mytype\r\nX-PUSH-CLI: $avp(s:first_caller_cli)\r\nX-PUSH-DST: $rU\r\n; Strings aren't evaluated for PV's. Use pv_printf or concatenate the different components with '+'. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] WARNING: timer: add_timeout: 0 expire timer added
Hello, I get this warning message when a request is relayed over tcp: WARNING: core [timer_funcs.h:119]: WARNING: timer: add_timeout: 0 expire timer added The warning is displayed after send_route() has run. (relevant) settings: modparam(tm, fr_timer, 500) modparam(tm, fr_inv_timer, 8) modparam(tm, wt_timer, 2) Every other timer related setting is at its default. Just before t_relay() is called, fr timer is set with: t_set_fr($avp(ringtime) * 1000); where $avp(ringtime) = 80. An identical setup with udp does not show the warning. Where does this warning come from and how do i suppress it? -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] WARNING: timer: add_timeout: 0 expire timer added
On Tuesday 23 August 2011 14:57:51 Juha Heinanen wrote: Alex Hermann writes: I get this warning message when a request is relayed over tcp: WARNING: core [timer_funcs.h:119]: WARNING: timer: add_timeout: 0 expire timer added which version of sr is that? have you tried with latest master version? It is the latest master version, Kamailio flavour. Btw, I have not seen this on a 3.0.1, SR flavour installation (simpler config). If the cause is not obvious to anyone, i'll try to reproduce with a trivial script. The issue is showing itself in a huge config with many, possibly interfering, modules loaded. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] WARNING: timer: add_timeout: 0 expire timer added
On Tuesday 23 August 2011 15:29:27 Juha Heinanen wrote: andrei fixed this warning a couple of days ago and it disappeared from my setups. if you have build your sip router from today's master version and still get the warning, then looks like there is another incarnation of the bug still to be fixed. Indeed, I missed that commit in the stream of commits and was still on an ancient version of saterday evening... Current master is ok. Thanks, -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] [regression] Message flags set in branch_route not saved into transaction
Hello,
It seems kamailio 3 does not save message flags set in branch route into the
transaction. In reply_route and failure_route the flag set in branch_route is
unset. In 1.4 this used to work. I would like to get that behaviour back, is
this possible?
Testscenario:
route {
setflag(0);
t_on_branch(1);
t_on_reply(1);
t_on_failure(1);
xlog(L_NOTICE, [$rm] Request before relay: $mF);
t_relay();
}
branch_route[1] {
xlog(L_NOTICE, [$rm] Branch begin: $mF);
setflag(8);
xlog(L_NOTICE, [$rm] Branch end: $mF);
}
onreply_route[1] {
xlog(L_NOTICE, [$rm] Reply ($rs) begin: $mF);
setflag(4);
xlog(L_NOTICE, [$rm] Reply end: $mF);
}
failure_route[1] {
xlog(L_NOTICE, [$rm] Failure ($T_reply_code): $mF);
}
Log output on 3.x:
[INVITE] Request begin:
[INVITE] Request before relay: 0001
[INVITE] Branch begin: 0001
[INVITE] Branch end: 0101
[INVITE] Reply (100) begin: 0001
[INVITE] Reply end: 0011
[INVITE] Failure (408): 0011
Log output on 1.4:
[INVITE] Request begin:
[INVITE] Request before relay: 0001
[INVITE] Branch begin: 0001
[INVITE] Branch end: 0101
[INVITE] Reply (100) begin: 0101
[INVITE] Reply end: 0111
[INVITE] Failure (408) begin: 0111
--
Greetings,
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [regression] Message flags set in branch_route not saved into transaction
On Monday 22 August 2011, Alex Hermann wrote:
It seems kamailio 3 does not save message flags set in branch route into
the transaction. In reply_route and failure_route the flag set in
branch_route is unset. In 1.4 this used to work. I would like to get that
behaviour back, is this possible?
This patch seems to restore old functionality. Would this be ok to commit?
diff --git a/modules/tm/t_fwd.c b/modules/tm/t_fwd.c
index 30558ab..756e4b4 100644
--- a/modules/tm/t_fwd.c
+++ b/modules/tm/t_fwd.c
@@ -1510,6 +1510,8 @@ int t_forward_nonack( struct cell *t, struct sip_msg*
p_msg ,
clear_branches();
setbflagsval(0, backup_bflags);
+ /* update flags, if changed in branch route */
+ t-uas.request-flags = p_msg-flags;
/* don't forget to clear all branches processed so far */
Testscenario:
route {
setflag(0);
t_on_branch(1);
t_on_reply(1);
t_on_failure(1);
xlog(L_NOTICE, [$rm] Request before relay: $mF);
t_relay();
}
branch_route[1] {
xlog(L_NOTICE, [$rm] Branch begin: $mF);
setflag(8);
xlog(L_NOTICE, [$rm] Branch end: $mF);
}
onreply_route[1] {
xlog(L_NOTICE, [$rm] Reply ($rs) begin: $mF);
setflag(4);
xlog(L_NOTICE, [$rm] Reply end: $mF);
}
failure_route[1] {
xlog(L_NOTICE, [$rm] Failure ($T_reply_code): $mF);
}
Log output on 3.x:
[INVITE] Request begin:
[INVITE] Request before relay: 0001
[INVITE] Branch begin: 0001
[INVITE] Branch end: 0101
[INVITE] Reply (100) begin: 0001
[INVITE] Reply end: 0011
[INVITE] Failure (408): 0011
Log output on 1.4:
[INVITE] Request begin:
[INVITE] Request before relay: 0001
[INVITE] Branch begin: 0001
[INVITE] Branch end: 0101
[INVITE] Reply (100) begin: 0101
[INVITE] Reply end: 0111
[INVITE] Failure (408) begin: 0111
--
Greetings,
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] time for acc records
On Wednesday 10 August 2011 14:21:10 Daniel-Constantin Mierla wrote: - a new column to store the seconds.milliseconds as double Please don't use double, use a fixed point format. Double's are for scientific use, this is accounting so exact numbers are required. In MySQL, one could use the DECIMAL type. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] time for acc records
On Thursday 11 August 2011, Henning Westerholt wrote: On Thursday 11 August 2011, Alex Hermann wrote: On Wednesday 10 August 2011 14:21:10 Daniel-Constantin Mierla wrote: - a new column to store the seconds.milliseconds as double Please don't use double, use a fixed point format. Double's are for scientific use, this is accounting so exact numbers are required. In MySQL, one could use the DECIMAL type. there is currently no write functionality in the DB API and also scheme generation XSL to support the DECIMAL type. IMHO support should be added then. Floating point (on digitial equipment) is not suitable nor acceptable (it might even be illegal in some jurisdictions) for accounting. I really wonder why DOUBLE support is(/would be) present in a SIP proxy. If double is not correct for you, what about just storing the milliseconds as INT value e.g. 12,3s = 123 in the DB? Why try to invent a workaround? Fixed point number types are part of SQL92: NUMERIC(precision, scale). BTW, only db_mysql and db_unixodbc currently support DECIMAL value for read, db_mysql evaluates it to DB1_STRING, db_unixodbc to DB1_INT. I know. You committed the fix for MySQL yourself after my bugreport, see commit b74e6f6. Internal representation as string is ok as long as calculations are not necessary. Alternatively a scaled integer could be used internally. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Modifying $rU after lookup()
On Tuesday 09 August 2011, Iñaki Baz Castillo wrote: The behaviour is unexpected. Imagine you do lookup (which fetchs 2 contacts) and after that, still in route block, do setflag(1). Such flag is set in branch_route for both generated branches. Why setting the $rU in same circumstances should behave different? Flags are related to the whole transaction, so being able to see them on all branches is expected. Use branch_flags if you want to set them per branch. $rU is related to the 'main' branch in request_route. There is no way to set the request uri for all branches in a transaction. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] $du gets set automatically before branch_route
On Thursday 04 August 2011, Daniel-Constantin Mierla wrote: I committed a patch to master branch in order to skip setting the dst_uri to next hop address for branch route, link to commit: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=fb4ecbf 986f4af366e5be9cbad26ceba924c77fd It would be great if you can give it a try and let me know if all is ok. Then it will be safe to backport to 3.1. I tested an empty $du and a filled in $du and both arrive as expected in branch_route. I did not test any further. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] $du gets set automatically before branch_route
Hello, while trying to upgrade from 1.5 to 3.1 i noticed that between t_relay() and branch_route, $du gets automatically set to $ru if it has not been set before. This is a change from 1.5 i could not find documentation for, so it might have been unintened. Can someone enlighten me on the purpose of this change and if there is a way to determine if $du is (was) unset other than comparing $ru to $du, wich seems a bit inefficient? Is it even guaranteed that $du gets set to $ru in every possible scenario? -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] $du gets set automatically before branch_route
On Monday 01 August 2011 17:58:17 Alex Balashov wrote:
On 08/01/2011 11:57 AM, Alex Hermann wrote:
Is it even guaranteed that $du gets set to $ru in every possible
scenario?
No, it is set only in a few cases.
Good way to check:
if(!defined $du)
That does not work:
The following script fragment:
request_route:
xlog(Relay: $ru via $du);
if (defined $du) {
xlog(Relay: $$du is defined);
}
branch_route:
xlog(Branch: $ru via $du);
if (defined $du) {
xlog(Branch: $$du is defined);
}
Produces the following log fragment:
Relay: sip:user@domain:;transport=udp via null
Branch: sip:user@domain:;transport=udp via
sip:user@domain:;transport=udp
Branch: $du is defined
Let me rephrase the question as it may have been a bit unclear: How can i
determine within branch_route if the current branch had $du set?
--
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] select count(*) with avp_db_query always returns null
On Wednesday 29 June 2011, Andrade Ricardo (CI/AFU1) wrote: Perhaps this fits better into a bug report, but I'd like to know if somebody out there experienced a similar issue. I am executing a select count query using the avp_db_query function, but it is not storing the results in any avp. Other queries are working fine. I use db_mysql connected with a mysql 5.1 server. I have tested this with kamailio-3.1.0 and kamailio-3.1.3, both didn't work. In an old box (version 1.3.x), the same query was returning the correct value. --- Here is the case which is not working: Code: avp_delete($avp(s:count)); $var(ret) = avp_db_query(SELECT count(*) FROM subscriber where username='foo', $avp(s:count)); xlog(L_INFO, var(ret)=$var(ret) avp(s:count)=$avp(s:count)); Output: INFO: script: var(ret)=1 avp(s:count)=null (notice the return code 1, which means that the query was successfull and there should be some output value stored in the avp, but it is null) The return type of the COUNT() function is a BIGINT, which is ignored in kamailio. The attached patch converts the lower 32 bits of the result to an int usable by kamailio. I'll push this eventually. -- Greetings, Alex Hermann commit 700102448a65b2fca95f763025503c910b2065bd Author: Alex Hermann a...@speakup.nl Date: Mon Jul 4 17:33:50 2011 +0200 modules/avpops: avp_db_query: treat BIGINT result as INT, disregarding the most significant 32 bits. diff --git a/modules/avpops/avpops_db.c b/modules/avpops/avpops_db.c index b5caabe..f8a18fc 100644 --- a/modules/avpops/avpops_db.c +++ b/modules/avpops/avpops_db.c @@ -395,6 +395,10 @@ int db_query_avp(struct sip_msg *msg, char *query, pvname_list_t* dest) avp_val.n = (int)RES_ROWS(db_res)[i].values[j].val.int_val; break; +case DB1_BIGINT: + avp_val.n + = (int)RES_ROWS(db_res)[i].values[j].val.ll_val; +break; case DB1_DATETIME: avp_val.n = (int)RES_ROWS(db_res)[i].values[j].val.time_val; ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_relay_to(0x02) alternative with kamailio 3.1
On Thursday 16 June 2011 01:48:45 Herve Couplet wrote: I had a setup with an old version where I used the function t_relay_to(0x02). Following the 3.1 documentation, flag : * 0x02* - do not generate reply on internal error (NOTE: has no effect anymore) I used that function as a workaround with a pbx that stop to register when it receive an error response like 478 Unresolvable destination or 408 request timeout. I did upgrade to 3.1 to have dns srv caching. Do you know how this would be possible with kamailio 3.1. If i read the docs correctly, in 3.1 t_relay() never sends an automatic reply, so you can just omit the flags. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Wednesday 15 June 2011, Iñaki Baz Castillo wrote: 2011/6/9 Iñaki Baz Castillo i...@aliax.net: 2011/6/9 Alex Hermann a...@speakup.nl: 2) About your quoted text, indeed RFC 2915 says that. But that just means that, an application (in this case a SIP client) must take *first* the valid NAPTR record with better order (lowest value). But RFC 2915 is just about NAPTR, it can not mandate that applications or protocols cannot try other NAPTR records as failover mechanism. Any SIP client or proxy implementing NAPTR records does failover to the next NAPTR record in case the first one failed (at least those I've tested). It seems that sip-router behaves exactly as you describe. This it, it performs the NAPTR resolution, chooses the record with best 'order' (for the supported transports) and just uses it (it would do SRV failover and so, but would never try other NAPTR records with less 'order'). However I've seen other SIP stacks also performing failover by taking next NAPTR records. But indeed, RFC 2915 does not mandate it, instead it says MUST NOT. So you are right. I forgot about a discussion i had about this issue a few years ago with a customer and just remembered the outcome now. (Optional) failover can be provided by different 'Preference' field within the same 'Order'. From rfc 2915/3403 section 2: The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint. Unfortunately this wasn't possible with Kamailio =1.5. Have you tried 3.x with equal 'Order' but different 'Preference' or just with different 'Order'? -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Thursday 09 June 2011 12:44:11 Iñaki Baz Castillo wrote: According to NAPTR: ~$ host -t naptr oversip.net oversip.net has NAPTR record 5 50 S SIPS+D2T _sips._tcp.oversip.net. oversip.net has NAPTR record 10 50 S SIP+D2T _sip._tcp.oversip.net. oversip.net has NAPTR record 20 50 S SIP+D2U _sip._udp.oversip.net. oversip.net has NAPTR record 40 50 S SIP+D2S _sip._sctp.oversip.net. oversip.net has NAPTR record 50 50 S SIPS+D2S _sips._sctp.oversip.net. So it should try TLS over TCP first, if it fails try TCP and if it fails try UDP. However it just uses UDP, why?? Even if I set a minor value to dns_tls_preference (so higher priority I expect) it still uses UDP. The way I read rfc2915, there is no failover mechanism. The application pick the first target that it supports and uses that. There is no mention of trying other records afterwards. Matching/finding NAPTR records stops once the first match is completed. All other records are discarded. From section 2: Order A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule matches the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field). Note the last sentence. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio debian package bug report : 3.1.3+lenny2
On Friday 27 May 2011 15:40:21 Henning Westerholt wrote: On Wednesday 25 May 2011, Philippe HENSEL wrote: Hi developpers and packagers, The file /usr/lib64/kamailio/libsrdb2.so.1.0 seems to be included in both kamailio_3.1.3+lenny2_amd64.deb and kamailio-mysql-modules_3.1.3 +lenny2_amd64.deb. So it is not possible to install kamailio-mysql-modules. According to the tracker this should be fixed, have you tried a new version of the packages, e.g. 3.1.3 or (since yesterday available) 3.1.4? I still had the issue that the install process was installing the libs to /usr/lib64 instead of /usr/lib. The rules file was only removing dups from /usr/lib. The fix for me was to export the LIBDIR variable in the rules file to have the libs installed in the correct directory: /usr/lib. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio debian package bug report : 3.1.3+lenny2
On Tuesday 31 May 2011, Daniel-Constantin Mierla wrote: On 5/31/11 9:55 AM, Alex Hermann wrote: I still had the issue that the install process was installing the libs to /usr/lib64 instead of /usr/lib. The rules file was only removing dups from /usr/lib. The fix for me was to export the LIBDIR variable in the rules file to have the libs installed in the correct directory: /usr/lib. that was solved some time ago. Do you still get the issue with 3.1.4? I checked kamailio mysql deb packages and they don't have anymore the libs. The build server uses several chroot environments, so the host system architecture is in some cases different that target architecture, so for a while, even the 'make deb' was fixed in git repository, some of packages were still broke since the build server uses completely different building script. That was fixed also and all packages should be in good shape. Well, I just downloaded a 3.1.4 amd64 .deb from deb.kamailio.org and that still has the libraries in the wrong location: /usr/lib64 instead of /usr/lib. I can't reproduce creating the same packages. If i build them with the rules file from the git repo, libs go to /usr/lib64, but dups aren't cleared (because LIBDIR=/usr/lib in the rules file and LIBDIR=/usr/lib64 in the Makefile). If I use the patch below, LIBDIR is the same (and correct) in both the rules file and the Makefile. The Makefile does not automatically inherit variables set in the rules file. They need to be explicitly exported as in the patch below or be added to the make command line: $(MAKE) LIBDIR=$(LIBDIR) -- Greetings, Alex Hermann commit f5adae2236c2c4bf037bf55bcd11100b83622c34 Author: Alex Hermann a...@speakup.nl Date: Mon May 23 16:55:47 2011 +0200 pkg: Export the LIBDIR variable from the rules file, so libraries are installed to the correct directory. diff --git a/pkg/kamailio/deb/debian/rules b/pkg/kamailio/deb/debian/rules index 30feea7..1c7423f 100755 --- a/pkg/kamailio/deb/debian/rules +++ b/pkg/kamailio/deb/debian/rules @@ -44,8 +44,8 @@ PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ ldap xml perl utils purple memcached tls \ snmpstats carrierroute xmpp cpl lua python geoip -# name of libdir in the path for libraries (e.g., lib for 32b, lib64 for 64b) -LIBDIR ?= lib +# name of libdir in the path for libraries +export LIBDIR ?= lib # directories with possible duplicate libraries (that should be deleted # from current module* packages) diff --git a/pkg/kamailio/deb/lenny/rules b/pkg/kamailio/deb/lenny/rules index 38066c0..730d3c9 100755 --- a/pkg/kamailio/deb/lenny/rules +++ b/pkg/kamailio/deb/lenny/rules @@ -44,8 +44,8 @@ PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ ldap xml perl utils purple memcached tls \ snmpstats carrierroute xmpp cpl lua python -# name of libdir in the path for libraries (e.g., lib for 32b, lib64 for 64b) -LIBDIR ?= lib +# name of libdir in the path for libraries +export LIBDIR ?= lib # directories with possible duplicate libraries (that should be deleted # from current module* packages) diff --git a/pkg/kamailio/deb/lucid/rules b/pkg/kamailio/deb/lucid/rules index 30feea7..1c7423f 100755 --- a/pkg/kamailio/deb/lucid/rules +++ b/pkg/kamailio/deb/lucid/rules @@ -44,8 +44,8 @@ PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ ldap xml perl utils purple memcached tls \ snmpstats carrierroute xmpp cpl lua python geoip -# name of libdir in the path for libraries (e.g., lib for 32b, lib64 for 64b) -LIBDIR ?= lib +# name of libdir in the path for libraries +export LIBDIR ?= lib # directories with possible duplicate libraries (that should be deleted # from current module* packages) diff --git a/pkg/kamailio/deb/squeeze/rules b/pkg/kamailio/deb/squeeze/rules index 0f2e2a5..d80b129 100755 --- a/pkg/kamailio/deb/squeeze/rules +++ b/pkg/kamailio/deb/squeeze/rules @@ -44,8 +44,8 @@ PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ ldap xml perl utils geoip memcached tls \ snmpstats carrierroute xmpp cpl lua python -# name of libdir in the path for libraries (e.g., lib for 32b, lib64 for 64b) -LIBDIR ?= lib +# name of libdir in the path for libraries +export LIBDIR ?= lib # directories with possible duplicate libraries (that should be deleted # from current module* packages) ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio debian package bug report : 3.1.3+lenny2
On Tuesday 31 May 2011 17:36:57 Daniel-Constantin Mierla wrote: The libdir for 64b systems (amd64) is lib64, as it was discussed on the mailing list. That is the general case, not using pakcges, as FHS seem to be written that way. Here we're talking about Debian packages and on debian native libs go to /usr/lib. http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1 But this is not causing the problems i have with building the packages! I downloaded the amd64 deb and the content is below, is it something wrong there? It is only /usr/lib64 as it was expected to be... On the other hand, you patch should be fine as well. But I just want to see where is something broken in provided debs at this time. The provided debs do work ok. The problem is with the provided pkg/debian/kamailio/*/rules files. The rules file does not export the LIBDIR variable to the Makefile resulting in different values within the rules file and within the Makefile breaking the dups deletion. The rules file sets LIBDIR to /usr/lib while the Makefile has installed the libs to /usr/lib64. So, the main issue is that LIBDIR needs to be exported from the rules file to the Makefile to guarantee both the rules file and the Makefile have the same notion of where the libs are going. At least in my build environment, the Makefile puts the libs in /usr/lib64 while the dups deletion works on /usr/lib resulting in packages with overlapping files. Additionally, IMHO, for Debian, LIBDIR=/usr/lib should be exported so the packages have the modules in /usr/lib as does the rest of Debian. -- Alex Hermann SpeakUp BV t: 088-7732587 f: 088-7732588 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] [PATCH] modules_k/db_sqlite: new sql backend
On Monday 04 April 2011, Timo Teräs wrote:
Implements the kamailio database API for SQLite.
+static str* str_dup(const char *_s)
+{
+ str *s;
+ int len = strlen(_s);
+
+ s = (str*) pkg_malloc(sizeof(str)+len+1);
+ s-len = len;
+ s-s = ((char*)s) + sizeof(str);
+ memcpy(s-s, _s, len);
+ s-s[len] = '\0';
+
+ return s;
+}
+
+static void str_assign(str* s, const char *_s, int len)
+{
+ s-s = (char *) pkg_malloc(len + 1);
+ s-len = len;
+ memcpy(s-s, _s, len);
+ s-s[len] = 0;
+}
You should really check the return value of all pkg_*alloc() function calls.
--
Alex Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to access additional xavp's
On Sunday 06 March 2011, Daniel-Constantin Mierla wrote: it took me quite a while due to traveling, but now the issue should be fixed on git. Indeed there was an issue with the indexes when accessing the xavp as PV. Thanks for the fix, they work fine now. -- Met vriendelijke groet, Alex Hermann SpeakUp BV T: 088-SPEAKUP (088-7732587) F: 088-7732588 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Redundancy between 2 Kamailio servers
On Wednesday 02 February 2011, you wrote: Am 27.01.2011 13:05, schrieb Alex Hermann: On Thursday 27 January 2011, Klaus Darilion wrote: Am 27.01.2011 11:21, schrieb Danny Dias: I've read some difficulty in the synchronisation of registrations because Kamailio works best when it stores registrations in memory and registrations are constantly changing - they expire and are renewed, as well as new ones joining and old ones leaving. To make the failover solution function seamlessly, it is necessary to synchronise the in-memory registrations between the primary and the backup server . This can be done by forking a copy of the registration request to the backup server, but there are some practical problems in doing this, has anyone do something with this? What problems are you referring to? I use this for some years now without any problems. Alex, what happens if one server is down. There will be lots of replication transactions which will timeout. Can this cause any problems if there are too many open transactions (retransmissions ...)? I just forward() them. btw: I just found in tm readme: * t_replicate should be done more cleanly--Vias, Routes, etc. should be removed from a message prior to replicating it (well, does not matter any longer so much as there is a new replication module). Is there really a dedicated replication module somewhere? Never seen one. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Redundancy between 2 Kamailio servers
On Wednesday 02 February 2011, Klaus Darilion wrote: Am 02.02.2011 15:24, schrieb Alex Hermann: On Wednesday 02 February 2011, you wrote: Alex, what happens if one server is down. There will be lots of replication transactions which will timeout. Can this cause any problems if there are too many open transactions (retransmissions ...)? I just forward() them. Interesting. So, do you have some logic to drop the response from the backup registrar? Or will the client receive 2 responses? Or will the backup server not response at all? I guess the last option would be the simplest one... The backup server does not respond at all. The first does all the authentication and verification, the backup just stores it in usrloc. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] kamailio and sip-router at FOSDEM 2011 - social event
On Wednesday 19 January 2011, Henning Westerholt wrote: in about two and a half week the annual open source developer conference FOSDEM (http://fosdem.org/2011/) takes place in Brussels. As in the last two years we would like to meet here for a social event, probably a dinner on Saturday evening, 6th February. According to my calendar, saturday is the 5th of February. I'm going to assume you meant saturday the 5th and not sunday the 6th. Please correct me if i'm wrong. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Redundancy between 2 Kamailio servers
On Thursday 27 January 2011, Klaus Darilion wrote: Alex, do you also do NAT keep-alive from the proxies? If yes, are you sending them from both servers at the same time? No, we require clients to sent nat-keepalives. It is much more efficient. In addition, the registrars are not directly accessible by clients, they go via load-balancers. Clients keep the NAT binding with the balancer, not the registrar. -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to access additional xavp's
On Friday 24 December 2010, Daniel-Constantin Mierla wrote: On 12/21/10 2:44 PM, Alex Hermann wrote: I'm currently toying with xavp's and have some trouble accessing the values. I want to have access to the xavp that isn't the last added one. From the wiki page on http://sip-router.org/wiki/devel/xavp I got the impression that indices are supported, but that doesn't seem to work. In the following fragment i want access to the values 1A 1B, how to do that? $xavp(test=a) = 1A; $xavp(test[0]=b) = 1B; $xavp(test=a) = 2A; $xavp(test[0]=b) = 2B; Yes, indexes are supported, functionality should be: when you do not use an index, then you just stack a new value. When you use indexes, you overwrite. In this case you have to use indexes after a and be, like $xavp(test=a[0]) a.s.o. This also doesn't work, see below and the wiki page says the index should be on the avpname... Can you explain what the index on the avpname does and what the index on the subfield does, because i thought i understood, but it doesn't seem to work. What i want to accomplish is to set an xavp (test) multiple times with multiple subfields (a b) so that when i do an pv_unset($xavp(test)) i get the next set of subfields (to be used for a serial forking scenario later on). This already works. Now i want to have random access to the xavp, using an index to get to the right set of subfields. ie if i query $xavp(test[0]=a) i get 2A, $xavp(test[1]=b) should give 1B. If i get this working i'll post an interesting patch to sqlops soon :) I did some more testing and think there is a off-by-one bug somewhere: $xavp(test=a) = 1A; $xavp(test[0]=b) = 1B; $xavp(test=a) = 2A; $xavp(test[0]=b) = 2B; $xavp(test[1]=a) = 3A; $xavp(test[1]=b) = 3B; xlog(Index on subavp); xlog(0: $xavp(test)); xlog(0a: $xavp(test=a[0])); xlog(0b: $xavp(test=b[0])); xlog(1: $xavp(test)); xlog(1a: $xavp(test=a[1])); xlog(1b: $xavp(test=b[1])); xlog(2: $xavp(test)); xlog(2a: $xavp(test=a[2])); xlog(2b: $xavp(test=b[2])); xlog(Index on avpname); xlog(0: $xavp(test[0])); xlog(0a: $xavp(test[0]=a)); xlog(0b: $xavp(test[0]=b)); xlog(1: $xavp(test[1])); xlog(1a: $xavp(test[1]=a)); xlog(1b: $xavp(test[1]=b)); xlog(2: $xavp(test[2])); xlog(2a: $xavp(test[2]=a)); xlog(2b: $xavp(test[2]=b)); Results in: Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: Index on subavp Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 0: xavp:0xb3a627c4 Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 0a: 2A Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 0b: 2B Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 1: xavp:0xb3a627c4 Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 1a: null Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 1b: null Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 2: xavp:0xb3a627c4 Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 2a: null Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 2b: null Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: Index on avpname Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 0: xavp:0xb3a627c4 Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 0a: 2A Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 0b: 2B Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 1: xavp:0xb3a6286c Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 1a: 1A Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 1b: 1B Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 2: null Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 2a: null Dec 24 12:07:40 veyron wsproxy1[13032]: ERROR: script: 2b: null Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:470]: + XAVP list: 0xb3a62770 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:473]: *** XAVP name: test Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:474]: XAVP id: 2063405720 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:475]: XAVP value type: 6 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:496]: XAVP value: xavp:0xb3a627c4 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:470]: + XAVP list: 0xb3a627c4 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:473]: *** XAVP name: b Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:474]: XAVP id: 110 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:475]: XAVP value type: 2 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:484]: XAVP value: 2B Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:473]: *** XAVP name: a Dec 24 12:07:40 veyron wsproxy1[13032]: INFO: core [xavp.c:474]: XAVP id: 109 Dec 24 12:07:40 veyron wsproxy1[13032]: INFO
[SR-Users] How to access additional xavp's
Hello, I'm currently toying with xavp's and have some trouble accessing the values. I want to have access to the xavp that isn't the last added one. From the wiki page on http://sip-router.org/wiki/devel/xavp I got the impression that indices are supported, but that doesn't seem to work. In the following fragment i want access to the values 1A 1B, how to do that? $xavp(test=a) = 1A; $xavp(test[0]=b) = 1B; $xavp(test=a) = 2A; $xavp(test[0]=b) = 2B; xlog($xavp(test[0]=a)); xlog($xavp(test[0]=b)); xlog($xavp(test[1]=a)); xlog($xavp(test[1]=b)); pv_xavp_print(); Which gives the following result: Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: script: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: script: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: script: null Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: script: null Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:470]: + XAVP list: 0xb3a38770 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:496]: XAVP value: xavp:0xb3a387c4 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:470]: + XAVP list: 0xb3a387c4 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:484]: XAVP value: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:484]: XAVP value: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:505]: - XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:496]: XAVP value: xavp:0xb3a386c8 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:470]: + XAVP list: 0xb3a386c8 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:484]: XAVP value: 1B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:484]: XAVP value: 1A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:505]: - XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: core [xavp.c:505]: - XAVP list -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Wrong handling CANCEL message
On Friday 30 April 2010 13:25:13 Iñaki Baz Castillo wrote: Yes, I agree. In fact draft invfix solves it by adding a new state Accepted so when a 200 is sent the server transaction remains in memory for a while (to absorbe INVITE retransmissions). But anyway the transaction is in Accepted state, and not in Proceeding, so a CANCEL should have no effect and the proxy shouldn't reply 200 for the CANCEL as the proxy has canceled *nothing*. The response to the CANCEL doesn't indicate if anything has been canceled (just that the CANCEL is well received), the response to the INVITE does. Answering 200 OK to the CANCEL is the least interuptive response as it won't trigger an error in the UAC. A 481 might trigger that the call is aborted as the UAC might think the dialog is invalid. If the 200 OK is received by the UAC, it should handle it just like the well known INVITE + 200 OK / CANCEL race for which it should send a BYE if the dialog is to be ended. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
