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
Hello,
with the perspective that Python2 is going to be removed from the major
Linux distributes starting with the beginning of next year, the work to
upgrade kamcli to run with Python3 has been started.
>From now on, master branch of kamcli is expected to work only with Python3:
* https://github.com/kamailio/kamcli
There is still work to be done to upgrade all the code, but any use of
it should be done with Python3 and eventual issues to be filed on bug
tracker. Of course, pull requests are welcome as always!
Who wants to use the version for Python2 has to use the code from git
branch v1.2-python2. That branch is probably not going to receive any
new feature, it will be kept for use with older systems (as well as a
running option during the upgrade period to Python3).
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda