Yep
version_table
Set the name of the table holding the table version. Useful if the
proxy is sharing a database within a project and during upgrades.
Default value is “version”.
Example of usage:
version_table="version44"
That's what I was looking for, perfect!
Yes, I added accountcode and notes to my table for internal use, was
just making notes on columns I need on the new version upgrade.
Thanks.
JR
On Tue, Jun 18, 2019 at 2:17 PM Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
>
> Hello,
>
> like Alex said, you can have two version tables, one for each versions
> of kamailio you play with and use in config the core parameter to set
> the name of that table.
>
> I am actually writing to say that address table never had accountcode
> and notes columns. Likely they were added in your deployment for other
> purposes or either the default column names were changed. The default
> column names are listed at:
>
> -
> https://kamailio.org/docs/db-tables/kamailio-db-5.2.x.html#gen-db-address
>
> These were the same for rather long time, iirc the recent version number
> changed mainly due to with modifications done to the size, not due to
> new columns.
>
> Cheers,
> Daniel
>
> On 18.06.19 20:50, JR Richardson wrote:
> > Hey All,
> >
> > I'm doing some upgrades and noticed database table version numbers
> > have increased.
> >
> > database table adjustments:
> > | address | production ver 3 | upgrade 5.2 ver 6 | need to add
> > accountcode and notes column
> > | dispatcher | production ver 3 | upgrade 5.2 ver 4 | need to add attr column
> > | trusted | production ver 5 | upgrade 5.2 ver 6 | need to add
> > ruri_pattern and priority column
> >
> > I run mysql master/slave so I'm concerned about the master database
> > not having the correct version numbers or can I just update the
> > version number in the table when I do the upgrade of the kamailio
> > versions?
> >
> > Thanks.
> >
> > JR
I need to send re-invite after pacemaker fails over on new rtpengine
server. Because new rtpengine dont participate in DTLS handshake and i hear
nothing, but silence. I think, may me its would be work. Do you have any
idea on this issue?
new to the area and trying to setup Kamailio with Asterisk in a single
machine. All users will register to Kamailio's port and in case of need for
media, it will be forwarded to Asterisk, that is my intention. All of my
work is based on the following link
https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb.
Here is what i have done:
- Debian 8, 64 bit machine with mysql and odbc
-
*root@kamast: ~ $ lsb_release -a No LSB modules are available. Distributor
ID: Debian Description: Debian GNU/Linux 8.11 (jessie) Release:
8.11 Codename: jessie root@kamast: ~ $ uname -a Linux kamast
3.16.0-10-amd64 #1 SMP Debian 3.16.72-1 (2019-08-13) x86_64 GNU/Linux
root@kamast: ~ $ *
- Kamailio 5.2 installed from Kamailio's deb repository
- Asterisk 13LTS installed from source
- Used the same passwords such as kamailiorw and asterisk_password,
since this is a test system, for proof of concept.
I did import to the mysql>asterisk database 3 users 2200, 2201 and 2202.
Then created in sip.conf the same 3 users with the same credentials. Then
on 3 PCs i used softphones (Jitsi, Zoiper) and registered each account to a
softphone. Problems:
- Cannot see the users in the Asterisk's cli, sip show peers
- I can see users only in Kamailio with kamctl ul show
- A call between the extensions goes to voicemail. It never reaches the
other destination eg 2200 calls 2201 and in Asterisk's console i am getting
a message that 2201 is absent and it goes to voicemail. The same with any
other extension.
Attached you can find:
1. Kamailio.cfg
2. Asterisk's sip.conf
3. Asterisk's extension.conf
4. The import that i have done to mysql for the user creation.
I would appreciate if someone could point me to the error and help me fix
it please?
Hi,
Testing on latest master deb nightly build from last night I've noticed
that when $au is not available, $Au is being set to $fu (uri) instead of
$fU (username).
Docs: https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables
...
$Au - Acc username: username for accounting purposes. It's a selective
pseudo variable (inherited from acc module). It returns auth username ($au)
if exists or From username ($fU) otherwise.
...
I have the following log in several places in a test box:
xlog("L_NOTICE", "[DEBUG] Au=$Au au=$au aU=$aU fU=$fU fu=$fu - \n");
And when I run through them (on both request and reply routes) I get the
following:
Aug 8 14:37:43 csbc01 csbc[9478]: NOTICE: {1 21564 REGISTER
d8df9be1-1702e20b(a)A.B.C.D} <script>: [DEBUG] Au=1002366(a)some.domain
au=<null> aU=<null> fU=1002366 fu=sip:1002366@some.domain -
Aug 8 14:37:43 csbc01 csbc[9479]: NOTICE: {1 21565 REGISTER
d8df9be1-1702e20b(a)A.B.C.D} <script>: [DEBUG] Au=1002366(a)some.domain
au=1002366 aU=1002366 fU=1002366 fu=sip:1002366@some.domain -
Aug 8 14:37:43 csbc01 csbc[9484]: NOTICE: {2 21565 REGISTER
d8df9be1-1702e20b(a)A.B.C.D} <script>: [DEBUG] Au=1002366(a)some.domain au=<null>
aU=<null> fU=1002366 fu=sip:1002366@some.domain -
Those 3 logs belong to the same flow from different places in the config
script.
I would expect $Au to never have a "@some.domain" in it, so I assume in
some place the replacement is not being done with $fU but with $fu.
@Devs: I'm happy to create a GH issue for tracking etc if required, please
let me know!
Cheers,
Joel.
Hello,
it's about the time to set the milestones to the next major release -
v5.3.0. There are 6 new modules and many other enhancements to existing
components in git master branch, also during the last irc devel meeting
it was proposed to freeze after summer holidays.
At this moment I would propose Wednesday, September 4, 2019 to freeze
the development. Then the release should be about one month later, after
testing interval.
In case there are people willing a bit more time for development, we can
freeze one week later, September 11, or another date -- your
suggestions here.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
I'm returning to an old issue, where Kamailio stops processing incoming
requests.
Now it turned out that only requests over UDP are not processed.
Requests over TCP work fine. Debug log doesn't show anything about the
requests over UDP, but wireshark sees them coming. core.ps shows that
main process - attendant and all udp receiver processes are alive.
Any ideas what could cause Kamailio (5.2 version) to stop processing
requests over UDP? What additional info should I try to get?
-- Juha
Hi,
I am running 4.3.5:1b0c0a, which I am aware is an EOL'd release train,
and have a problem with the dialog module I am baffled by.
On many calls - I can't find any correlation to particular kinds of
endpoints - I see spoofed BYEs come out of Kamailio after a minute and a
half, as if the call had hit a dialog timeout or the dialog module's
dead peer detection (OPTIONS pinging) kicked it out.
The thing is, neither of those explanations seem to be borne out by the
parameters of the calls under investigation. The dialog timeout on these
calls is set to 7200, and the dialog keepalives aren't enabled in either
direction. If they were, it'd be logged.
Calls that are terminated in this manner also see the following log
message:
WARNING: dialog [dlg_req_within.c:214]: bye_reply_cb(): inconsitent
dlg timer data on dlg 0x7f9997317e48 [3390:9644] with clid
'1996679936_133218050(a)x.x.x.x' and tags '2bb17663-co4006-INS001' 'as7925780d'
But I don't think this is unusual for a dialog-spoofed BYE; presumably
this is due to a 200 OK for the BYE from both ends.
So anyway, I am trying to track down anything else that could
inadvertently cause dialog to hang up calls relatively quickly in that
release, or inadvertently set the dialog timeout parameter to something
lower than is apparent from the logging and the config.
If anyone has any pointers, that would not go unappreciated!
Many thanks,
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Greetings,
I have a Kamailio proxy with uac_replace for To and From Headers. So far
everything has worked correctly.
However, I now have a client who encodes my Calling Number too and I'm
getting some issues in the restore mechanics. I have the restore setup as
"auto" and it's info is stored in "vsf" and "vst" parameters of
Record-Route.
On replies sent by my client I have the following Record-Route and From
Header (Note : My Kamailio has two IPs which makes it insert two RR headers
):
Record-Route:
<sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_
o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH
DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>
Record-Route:
<sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_
o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH
DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>
From: "+351411110097"
<sip:I2116446I_500@xxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4
In this case the restore is done correctly
When the client sends me a BYE request I have the following Route Header and
To Header
Route :
<sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_
o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH
DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>,<sip:xxx.xxx.xxx.
xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_o=128_11_Y;vsf=AA
AAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcH
wIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>
To : "+351411110097"
<sip:I2116446I_500@xxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4
In this scenario, the To after restore is : To :"+351411110097"
<sip:Q4525417L_<>Gxxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4, which
throws an internal error on Kamailio about bad URI and also makes our
MediaGateway reply with a "Bad Request".
Can this error be caused by the restore of the uac_replace mechanics? Both
Record Route URIs are on different headers while the both Route URIs are on
the same Route header. Can this be the reason?
If you need more information please let me know.
Best Regards
David Costa
Hello Bill,
(please keep the list in CC)
yes, this seems to be the case. Just looked briefly to the code, it does
an assignment in some cases. E.g. if no Presentity* data is given it
will just use the From* information. And then it should later output an
error from pua_json_update_presentity(..) if there is not the necessary
data. Do you see any error message like this?
Another idea - does it works if you add more "missing" data in the curl
requests?
Cheers,
Henning
Am 28.08.19 um 21:16 schrieb bill(a)novatrope.us:
> Henning: Good point.
>
> I do see a number of errors in the log. It looks like the json routine
> is looking for data that is not in the http query as specified by the
> author.
>
>
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Event-Name: [update]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Event-Package: [dialog]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [Presentity]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Presentity: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [Presentity-User]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Presentity-User: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [Presentity-Realm]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Presentity-Realm: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): From:
> [sip:1020101@<IP of phone>]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> From-User: [1020101]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> From-Realm: [<IP of phone>]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [From-URI]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> From-URI: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): To:
> [sip:1020108@<IP of server>:50060]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> To-User: [1020108]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [To-URI]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): To-URI: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Call-ID: [1020101@<IP of phone>]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [From-Tag]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> From-Tag: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [To-Tag]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): To-Tag: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c
> error - failed to extract field [Direction]
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field():
> Direction: []
> 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): State:
> [Confirmed]
> 17(125579) DEBUG: presence [event_list.c:348]: search_event(): start
> event= [dialog/5]
>
> On 8/28/19 12:00 PM, Henning Westerholt wrote:
>> Hello Bill,
>>
>> just giving some generic debug pointers here:
>>
>> - do you see any errors in the kamailio log file?
>>
>> - do you see any SIP traffic (e.g. by observing with ngrep, wireshark
>> etc..) to the phone after your curl command?
>>
>> Cheers,
>>
>> Henning
>>
>> Am 28.08.19 um 19:04 schrieb bill(a)novatrope.us:
>>> Hi all:
>>>
>>> I am trying to use the procedure for setting BLF lights described in
>>> https://blog.voipxswitch.com/2018/02/22/kamailio-controlling-presence-with-…
>>>
>>>
>>> WIthout success.
>>>
>>> My configuration is 1 Grandstream GXP2130 phone behind a NAT on a
>>> public IP. (IPP in example below)
>>>
>>> Kamailio is running on public IP (IPK in example) listening on port
>>> 50060
>>>
>>> The command I am sending:
>>>
>>> curl -d
>>> '{"Call-ID":"1020101@<IPP>","Event-Category":"presence","Event-Name":"update","Event-Package":"dialog","Expires":"3600","To":"sip:1020108@<IPK>:50060","To-User":"1020108","To-Realm":"<IPK>:50060","From":"sip:1020101@<IPP>","From-User":"1020101","From-Realm":"<IPP>","State":"Confirmed"}'
>>>
>>> http://localhost:8080/presence/
>>> {"Call-ID":"1020101@<IPP>","Event-Category":"presence","Event-Name":"update","Event-Package":"dialog","Expires":"3600","To":"sip:1020108@<IPK>:50060","To-User":"1020108","To-Realm":"<IPK>:50060","From":"sip:1020101@<IPP>","From-User":"1020101","From-Realm":"<IPP>","State":"Confirmed"}
>>>
>>>
>>>
>>>
>>> Kamailio appears to be processing the command OK, so I think I am just
>>> not setting it up properly>
>>>
>>> Anybody having any luck with this procedure, let me know how you are
>>> getting it to work.
>>>
>>>
>>> Bill
>>>
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users(a)lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services