Hi All,
I am trying to replay a request to the destination via Kamailio, and I am using t_relay_to_tcp for that , but in that case Kamailio is adding its own address as the top VIA header. Is there a way I can instruct Kamailio not to add local via header ?
Hello all, context first, we have an REST API that performs queries to
external devices in the network (diameter to DRA's, REST to different
servers) and based on n conditions returns the content for a Contact header
to be used in a SIP 302.
Now we're consuming this API with http_client (synchronously) and as
there's no way to speed up the API (pipeline executions, delays on external
api's etc etc) we're hitting a limit where all children become busy waiting
for the API to answer.
So i decided to move to http_async_client and started working on it on the
lab with this first and base concept to test.
request_route {
#for testing purposes only
if(is_method("ACK")){
exit;
}
$http_req(all) = $null;
$http_req(suspend) = 1;
$http_req(timeout) = 500;
$http_req(method) = "POST";
$http_req(hdr) = "Content-Type: application/json";
jansson_set("string", "event", "sip-routing", "$var(cre_query)");
xlog("L_INFO","API ASYNC ROUTING REQUEST: $var(cre_query)\n");
$http_req(body) = $var(cre_query);
t_newtran();
http_async_query("http://192.168.86.128:8000/", "CRE_RESPONSE");
}
http://192.168.86.128:8000/ receives the POST, randomly creates a delay
between 0.5 and 1 second and responds (simulating the real api with an
excess delay to probe the concept)
Then
route[CRE_RESPONSE] {
if ($http_ok && $http_rs == 200) {
xlog("L_INFO","CRE RESPONSE: $http_rb\n");
# for testing purpose, Contact content will be replaced from the received
api response
append_to_reply("Contact: <sip:1234@google.com>\r\n");
send_reply(302,"Moved Temporarily");
exit;
}
send_reply(500, "Internal error");
exit;
}
INVITE is received and processed, API is called, after API response, 302 is
replied and then an ACK (ignored by now).
Situation is that the 302 retransmitted
37 1519.846253067 192.168.86.34 → 192.168.86.128 SIP/SDP 585 Request:
INVITE sip:service@192.168.86.128:5060 |
38 1519.848100380 192.168.86.128 → 192.168.86.34 SIP 318 Status: 100
Trying |
39 1520.094997642 192.168.86.128 → 192.168.86.34 SIP 407 Status: 302
Moved Temporarily |
40 1520.102323728 192.168.86.34 → 192.168.86.128 SIP 453 Request: ACK
sip:service@192.168.86.128:5060 |
41 1520.591300933 192.168.86.128 → 192.168.86.34 SIP 407 Status: 302
Moved Temporarily |
42 1521.591061065 192.168.86.128 → 192.168.86.34 SIP 407 Status: 302
Moved Temporarily |
43 1523.591227956 192.168.86.128 → 192.168.86.34 SIP 407 Status: 302
Moved Temporarily |
18(24) DEBUG: tm [t_reply.c:1703]: t_retransmit_reply(): reply
retransmitted. buf=0x7f6d79745dc0: SIP/2.0 3..., shmem=0x7f6d75187fd8:
SIP/2.0 3
18(24) DEBUG: tm [t_reply.c:1703]: t_retransmit_reply(): reply
retransmitted. buf=0x7f6d79745dc0: SIP/2.0 3..., shmem=0x7f6d75187fd8:
SIP/2.0 3
18(24) DEBUG: tm [t_reply.c:1703]: t_retransmit_reply(): reply
retransmitted. buf=0x7f6d79745dc0: SIP/2.0 3..., shmem=0x7f6d75187fd8:
SIP/2.0 3
18(24) DEBUG: tm [timer.c:634]: wait_handler(): finished transaction:
0x7f6d75184cc8 (p:0x7f6d74f600c8/n:0x7f6d74f600c8)
18(24) DEBUG: tm [h_table.c:132]: free_cell_helper(): freeing transaction
0x7f6d75184cc8 from timer.c:643
Any help to avoid the retransmission and make the transaction just finish
right after the 302 will be appreciated.
regards
Hello,
I wanted to know if this can be accomplished, or if I'm doing something wrong.
What I'm hoping to accomplish is to have kamailio periodically send OPTIONS packets to endpoints that are connected over UDP only.
As of right now, I currently have the following configured under usrloc:
modparam("usrloc", "timer_interval", 5)
modparam("usrloc", "timer_procs", 2)
modparam("usrloc", "use_domain", MULTIDOMAIN)
modparam("usrloc", "db_url", DBURL)
modparam("usrloc", "db_mode", 0)
modparam("usrloc", "ka_mode", 1)
modparam("usrloc", "ka_method", "OPTIONS")
modparam("usrloc", "ka_from", "sip:ping@sip-domain.com")
modparam("usrloc", "ka_domain", "sip-domain.com")
modparam("usrloc", "ka_timeout", 125)
modparam("usrloc", "ka_interval", 60)
With these parameters, all endpoints will be sent OPTIONS packets periodically as expected. When setting "ka_mode" to "4", as expected, endpoints registered with UDP only receive OPTIONS packets; which is what I wanted.
The issue that I'm having with these parameters is that endpoints registered with anything other that UDP are triggering a contact-expired event after a little over 2 minutes. I have the registrar set to 3600 as an expiry; I'm assuming the contact is expiring due to the "ka_timeout" value.
--------------------------
Is there a way to only have keep-alive packets/ and timeouts apply to endpoints registered on UDP?
Thank you.
Hi all!
I need to integrate a REST Service with Kamailio. Integration is easy, not
a problem, but my concern is that the REST Services has a JWT token
authentication required for each request, common to many (it not all) REST
Services.
So, it is required to POST for authentication (username and password) and
once I get authentication done, and receive a JWT token, I will need to use
this token in all other requests to the REST Service. The token is valid
for 24h.
My question is:
- how to save the token for use during 24h, on all calls/sessions, without
the need to authenticate on every call?
- how to detect the token has expired and re-authenticate?
I looked for some modules, but could not find any that suited me.
I am thinking of executing a Python script for this, but concerned about
latency and PDD....
Any thoughts? Any suggestions? Any known best-practice?
Atenciosamente / Kind Regards / Cordialement / Un saludo,
*Sérgio Charrua*
Hello All,
I am trying to limiting the number of video calls (converting Volte to
Vilte). To reduce traffic on the enodeb.
Its like if there are 10 volte calls going on then I should be able to
limit the number calls that can be converted to Vilte.
I tried to write a route in kamailio_pcscf.cfg using module ims_dialog. But
it doesnt work and get some errors while doing a modparam.
Tried another method of counting eRAB at eNB (ENBUEID and ERABID pair with
qci-2). This worked, but after sometime the extra call got established.
Looks like traffic is going through qci 9 bearer.
Is there any method where we can achieve this.
Thanks in Advance.
Regards,
Dushyanth
Hi Batanai,
After disabling #!define WITH_NAT in Kamailio, calls from the Asterisk
endpoint to Microsoft Teams are functioning correctly. Both inbound and
outbound calls exhibit proper two-way audio and no disconnection issues but
there is no Bye when hangup from ms teams.
However, I am encountering a problem with outbound calls originating from
Microsoft Teams. When a call is placed from MS Teams, the recipient's phone
rings as expected. Once the call is answered, Microsoft Teams disconnects
the call immediately. The root of the issue seems to be that the ACK
message is not being sent or received properly. As a result, Microsoft
Teams does not receive the ACK, leading to an immediate call termination.
Additionally, Asterisk does not receive a BYE message from Kamailio.
*Summary of the Issue:*
- *Inbound Calls*: From Asterisk to MS Teams work fine, with full audio
and no disconnections but no BYE from ms teams.
- *Outbound Calls*: From MS Teams to Asterisk result in the call being
disconnected immediately after being answered due to a missing ACK, and
Asterisk does not receive a BYE message.
Thanks,
On Tue, Aug 27, 2024 at 5:45 PM Batanai Musiiwa <batanai.musiiwa(a)etel.co.zw>
wrote:
> Hi @
> Muhammad. May you advise if the calls are disconnecting in either
> direction?
>
> ;
>
> On Tue, Aug 27, 2024 at 11:05 AM Muhammad Sohaib via sr-users <
> sr-users(a)lists.kamailio.org> wrote:
>
>> Hi everyone,
>>
>> Thank you all for your kind help with the TLS configuration. Palany's
>> suggestion worked flawlessly, and now both inbound and outbound calls are
>> functioning.
>>
>> However, I'm facing a one-way audio issue, and calls are disconnected
>> after 30 seconds. I suspect this might be related to NAT. Here’s the
>> current setup:
>>
>> *Asterisk <===> Kamailio (as SBC) <=====> MS Teams*
>>
>> Could this be related to my NAT configuration, or is there something else
>> I should investigate? Any guidance would be greatly appreciated.
>>
>> Thanks again for your support!
>>
>> On Thu, Aug 15, 2024 at 11:02 PM palany <palany(a)advancedzim.com> wrote:
>>
>>>
>>>
>>> Hi Muhammad
>>>
>>>
>>>
>>> Can you try your tls cfg as below and make sure your certificates have
>>> the right permissions.
>>>
>>>
>>>
>>> [server:default]
>>>
>>> method = TLSv1.2+
>>>
>>> verify_certificate = no
>>>
>>> require_certificate = no
>>>
>>> private_key = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
>>>
>>> certificate = /etc/letsencypt/live/MYDOMAIN/fullchain.pem
>>>
>>>
>>>
>>> [client:default]
>>>
>>> method = TLSv1.2+
>>>
>>> verify_certificate = no
>>>
>>> require_certificate = no
>>>
>>> private_key = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
>>>
>>> certificate = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
>>>
>>> *From:* Muhammad Sohaib via sr-users [mailto:sr-users@lists.kamailio.org]
>>>
>>> *Sent:* Thursday, 15 August 2024 3:46 PM
>>> *To:* Kamailio (SER) - Users Mailing List
>>> *Cc:* Muhammad Sohaib
>>> *Subject:* [SR-Users] certificate verify failed (sni: unknown)
>>> integration with ms teams
>>>
>>>
>>>
>>> Dear all,
>>>
>>>
>>>
>>> Trying to integrate Kamailio with MS Teams by following
>>> https://skalatan.de/en/blog/kamailio-sbc-teams
>>>
>>>
>>>
>>> kamcmd dispatcher.list | egrep "URI|FLAGS"
>>>
>>>
>>> URI: sip:
>>> sip.pstnhub.microsoft.com;transport=tls
>>> FLAGS: IP
>>> URI: sip:
>>> sip2.pstnhub.microsoft.com;transport=tls
>>> FLAGS: IP
>>> URI: sip:
>>> sip3.pstnhub.microsoft.com;transport=tls
>>> FLAGS: IP
>>>
>>>
>>>
>>> Kamailio Logs:
>>>
>>> /usr/local/sbin/kamailio[412158]: INFO: <script>: Sent out tm request:
>>> OPTIONS sip:sip.pstnhub.microsoft.com;transport=tls SIP/2.0#015#012
>>> Via: SIP/2.0/TLS
>>> x.x.x.x:5061;branch=z9hG4bK5dad.92de50b2000000000000000000000000.0#015#012
>>> To: <sip:sip.pstnhub.microsoft.com;transport=tls>#015#012
>>> From: <sip:test.mytest.com
>>> >;tag=5d0939b82abe9b1bbf185d963b6e6c88-edeb3c71#015#012
>>> CSeq: 10 OPTIONS#015#012
>>> Call-ID: 2db6bede5631d9b6-412158(a)88.99.244.106#015#012
>>> <http://2db6bede5631d9b6-412158@88.99.244.106#015%23012>
>>> Max-Forwards: 70#015#012Content-Length: 0#015#012
>>> User-Agent: kamailio (5.8.2 (x86_64/linux))
>>>
>>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1312]:
>>> tls_h_read_f(): protocol level error
>>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_util.h:49]:
>>> tls_err_ret(): TLS write:error:0A000086:SSL routines::certificate verify
>>> failed (sni: unknown)
>>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1316]:
>>> tls_h_read_f(): src addr: 52.114.75.24:5061
>>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1319]:
>>> tls_h_read_f(): dst addr: x.x.x.x:0
>>> /usr/local/sbin/kamailio[412165]: ERROR: <core> [core/tcp_read.c:1524]:
>>> tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fa74d265d40 r:
>>> 0x7fa74d265e68 (-1)
>>>
>>>
>>> tls.cfg:
>>>
>>> [server:default]
>>> method = TLSv1.2+
>>> verify_certificate = yes
>>> require_certificate = yes
>>> private_key = /etc/letsencrypt/live/test.mytest.com/privkey.pem
>>> certificate = /etc/letsencrypt/live/test.mytest.com/fullchain.pem
>>> ca_list = /etc/letsencrypt/live/test.mytest.com/fullchain.pem
>>> server_name = test.mytest.com
>>>
>>> [client:default]
>>> method = TLSv1.2+
>>> verify_certificate = yes
>>> require_certificate = yes
>>> private_key = /etc/letsencrypt/live/test.mytest.com/privkey.pem
>>> certificate = /etc/letsencrypt/live/test.mytest.com/fullchain.pem
>>> ca_list = /etc/letsencrypt/live/test.mytest.com/fullchain.pem
>>>
>>> Please suggest what I am missing.
>>>
>>> ---
>>>
>>> Thanks,
>>>
>>
>>
>> --
>> Thanks,
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
>
--
Thanks,
Hello list!
Please help me understand if putting my b2bua in sensory deprivation is
actually the best approach to punish it for sole reason of its existence.
The background of this horror story is pretty cliche, call center needs a
way to infinitely expand, so I'm building a scaling telephony core.
Our main protagonist is an innocent b2bua with a very grounded backstory:
step 0: receive external instruction to start a call
step 1: originate
step 2: park
step 3: play moh until:
- - a) told to pass it to other component
- - b) told to hang up
- - c) hang up on local timeout
A simplified diagram of the call flow looks something like this (repeating
names are same components):
### Signaling ###
Remote Destination
^
Kamailio-external
^
Freeswitch-originator
V
Freeswitch- queue
V
Kamailio-local
V
Agent
### end of signaling ###
### Media ###
Remote Destination
^
Rtpengine-external
^
Freeswitch-originator
V
Freeswitch-queue
V
Rtpengine- local
V
Agent
### end of media ###
Due to specifics of the setting, re-negotiating the media and any
non-essential signaling with remote destination is a very much last resort.
And, as you can imagine, after step3a (pass it to other component), the
character development of Freeswitch-originator service stops completely.
Well, at least it is doing an honest job by playing the music on hold,
which a little bit justifies its presence on the media path. But not for
long.
In the world of near future, pull request number 3956 is merged with the
master branch, exposing the rtpengine API and leaving me no reason not to
move MoH to a kernel media player. At this moment I feel a wild urge to get
rid of Freeswitch-originator at all, but then I read the sources for mohq
and dialog to remind myself that Kamailio is a proxy and proxies can't do
this... So I fill b2bua's dialplan with 387.44 million lines of hateful
comments and remind it to rcvonly every time it tries to warn the others
about the grim fate.
When the queue designates an agent to his call, theoretically I don't even
need the second freswitch as well - if agen't media session has been
established (sometimes ICE take tooo long) with Rtpengine- local, I can
bridge their media sessions using publish and subscribe.
I'd like to ask your opinion, list: do you see any plotholes potential
issues with such deisgn?
I'd honestly like to set Freeswitch to bypass-media, so it wont' waste
ports and cpu for nothing at all.
Are there any issues if I add body for the iniitial invite in the
request_route as if it was received in there?
Maybe there's a better way, overall?
Any critique is welcome!
Thank you
--
AC
Hello Experts,
I need your advice on the following issue if you can kindly help.
I am working on a hold call flow:
UA - > Kamailio (RTP Engine) - > FS
initial call establishes fine, RTP engine is invoked and SDP media IP is modified correctly. Then
1.
I am receiving a hold re-invite with a send-only
2.
I see Kamailio is changing the media IP in the SDP (with my RTP engine IP) when it sends the Invite to my core FS server.
3.
FS sends 200 OK with a=recvonly
4.
Kamailio relays the message as it is to the other leg.
can someone advise me, on how can I invoke rtpengine at step 4, so the SDP is sent with my media server IP in the 200 OK?
--- 200 OK from FS ----
SIP/2.0 200 OK
Via: SIP/2.0/UDP 13.54.01.02:5060;branch=z9hG4bKd2e8.8a573af8d927f67c1db4550676f8be88.0;i=1
Via: SIP/2.0/TCP 192.168.10.117:51280;received=218.33.01.02;rport=51280;branch=z9hG4bKPj7d1d8968830d4ed3922eec7da7cdc17c;alias
Record-Route: <sip:13.54.01.02:5060;r2=on;lr=on>
Record-Route: <sip:13.54.01.02;transport=tcp;r2=on;lr=on>
From: <sip:0403225908@trunk.xyz.corp>;tag=6a180ffa7f824972a2c59ba47f293acb
To: <sip:+61285038000@trunk.xyz.corp>;tag=DZrpcpgS1BDKF
Call-ID: 4154062196634c34a2dbcb6b612bf44c
CSeq: 12263 INVITE
Contact: <sip:+61285038000@54.88.54.88:5060;transport=udp>
User-Agent: UserAgentX/v1.0
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Require: timer
Supported: timer, path, replaces
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 266
v=0
o=FreeSWITCH 1724635755 1724635757 IN IP4 54.88.54.88
s=FreeSWITCH
c=IN IP4 54.88.54.88
t=0 0
m=audio 21202 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=recvonly
a=ptime:20
a=rtcp:21203 IN IP4 54.88.54.88
--- 200 OK relayed towards the UA ----
2024/08/26 17:22:39.923639 172.16.8.126:5060 -> 218.33.78.33:51280
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.10.117:51280;received=218.33.01.02;rport=51280;branch=z9hG4bKPj7d1d8968830d4ed3922eec7da7cdc17c;alias
Record-Route: <sip:13.54.01.02:5060;r2=on;lr=on>
Record-Route: <sip:13.54.01.02;transport=tcp;r2=on;lr=on>
From: <sip:0403225908@trunk.xyz.corp>;tag=6a180ffa7f824972a2c59ba47f293acb
To: <sip:+61285038000@trunk.xyz.corp>;tag=DZrpcpgS1BDKF
Call-ID: 4154062196634c34a2dbcb6b612bf44c
CSeq: 12263 INVITE
Contact: <sip:+61285038000@54.88.54.88:5060;transport=udp>
User-Agent: UserAgentX/v1.0
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Require: timer
Supported: timer, path, replaces
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 266
v=0
o=FreeSWITCH 1724635755 1724635757 IN IP4 54.88.54.88
s=FreeSWITCH
c=IN IP4 54.88.54.88
t=0 0
m=audio 21202 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=recvonly
a=ptime:20
a=rtcp:21203 IN IP4 54.88.54.88
my configs for within dialog route:
#####
route[WITHINDLG] {
append_hf("X-Test-Header: route_WITHINDLG\r\n");
if (has_totag()) {
if (loose_route()) {
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
if (is_method("ACK")) {
xlog("L_INFO", "Relaying ACK\n");
}
if (is_method("INVITE|UPDATE")) {
if (has_body("application/sdp") && search_body("m=image") && search_body("T38")) {
xlog("L_INFO", "T.38 re-INVITE detected, skipping rtpengine invocation\n");
} else {
xlog("L_INFO", "Non-T.38 INVITE detected, invoking rtpengine\n");
rtpengine_manage("replace-origin replace-session-connection");
}
}
route(RELAY);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
route(PRESENCE);
exit;
}
if (is_method("ACK")) {
if (t_check_trans()) {
t_relay();
exit;
} else {
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
}
#####
looking forward to your usual guidance.
Thank you!
Regards,
Shah