Hi,
Sorry if this question has been answered before, but I'm rather puzzled
as to the intent behind sht_lock() / sht_unlock().
Presumably, "thread"-safe / shm mutex locking is already implemented in
htable query and mutation operations, otherwise htable would be unusable in
a route script context.
So what is the purpose of this higher-level lock? Is it to create a way
to block config script execution in multiple processes as to serialise
operations? Why would one want to do this under any ordinary
circumstances? Perhaps it is a failure of my imagination...
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/
Hello,
TL;DR
How can I execute a routine in my Kamailio python module
(kamailio_python.py) on demand? For example, using kamcmd from the command
line. I know you can execute *app_python.reload *but I don't need to
reload the whole python module, and furthermore, docs for this call say
it's unstable and can even crash your kamailio instance. So my goal is to
execute one single python routine on demand.
https://www.kamailio.org/docs/modules/5.1.x/modules/app_python.html#app_pyt…
Full explanation:
I'm currently implementing OIDC token authentication for Kamailio. I have
a python routine that extracts the token from a custom SIP header, and
validates the token as per the OIDC spec (I'm using pyjwt plus other custom
checks for this). In order to do offline validation of the token, you need
the Identity Provider (IdP) Server's certificate, which I get in advance
and cache in a local file on my Kamailio server. I also have an external
python script which I can run to get the latest certificate from the IdP
server and update it locally.
The part I'm missing is how to tell Kamailio to reload the value of the
certificate from the local cache, WITHOUT stopping kamailio or interrupting
any sessions. This is needed in case the certificate is updated (e.g. due
to expiration or compromise) on the IdP server; if you don't update it so
that Kamailio can use the latest one, all token verification will fail
(tokens signed by IdP server using latest private key corresponding to
latest certificate, but Kamailio trying to validate the signature using the
public key extracted from previous certificate -- this results in a
signature error, as Kamailio needs to be using the public key corresponding
to the private one that was used to sign the token).
By being able to execute one single python routine on demand (e.g. using
kamcmd), I can tell Kamailio to reload the certificate value from the local
cache, which I just updated by running my other (external and unrelated to
Kamailio software) python script.
Hope this makes sense, and hopefully I can get some tips on how to achieve
this.
Thanks,
Martín.
Hello,
I'm using Kamailio as a proxy behind freeswitch to alter some packets (183
packets precisely).
Here is my scenario:
(---Customer---) --> ((port 5065)---Kamailio---) -->
((port5060)---Freeswitch---) --> (---Supplier---)
Here is my request route :
route{
if (is_method("INVITE")) {
xlog("L_INFO","INSIDE request route $si \n");
insert_hf("X-AUTH-IP: $si\r\n");
}
route(FWD);
}
reply_route {
#xlog("L_INFO","INSDE reply \n");
if (status == "183") {
change_reply_status(180, "Ringing");
exit;
}
}
route[FWD] {
#xlog("L_INFO","INSIDE FWD \n");
forward(X.X.X.X,5060);
}
Where X.X.X.X is the Freeswitch IP
This script is working normally as long as the customer is sending the
requests(INVITE,BYE,ACK,CANCEL..) . But when the supplier or freeswitch
initiated the request , above script causes loop where the packet is bounced
between kamailio and freeswitch.
As I know , loose_route is used to handle such requests , but I'm not sure
how to forward these packets to the customer after receiving them from
freeswitch.
I'm not sure also if what's I'm doing is statefull or stateless.
Any help is appreciated.
Thanks,
Ali Taher
Hello,
I am trying make presence module work with Kamailio. Right now I am testing
these modules: presence, presence_xml, presence_dialoginfo, pua and
pua_dialoginfo.
I had some success, the BLF is working only when the monitored extension is
calling. When the monitored extension is calling, then the BLF changes its
color (red). After end of the call the BLF changes color to green.
My problem is when a User comes on-line then it sends SUBSCRIBE with
*Event: dialog* and
don't get notified of its subscribers state and BLF is not changed.
I found similar problem in this mail list :
https://lists.kamailio.org/pipermail/sr-users/2017-March/096314.html
But is not working for me.
Second question is about BLF and offline state. I can not found
anything in RFC, there is no offline state, no way to turn off the BLF
lamp from green to OFF.
I found only this pdf from grandstream:
http://www.grandstream.com/sites/default/files/Resources/GXP21x0_Eventlist_…
mentioning offline state on page 8.
Does anyone have experience with it?
Hello,
I'm using below routing logic to change the 183 reply to 180 and send it
back to the origination.
Noting that Kamailio is listening on 5065.
route{
if (is_method("INVITE")) {
xlog("L_INFO","INSIDE request route $si \n");
insert_hf("X-AUTH-IP: $si\r\n");
}
route(FWD);
}
reply_route {
#xlog("L_INFO","INSDE reply \n");
if (status == "183") {
change_reply_status(180, "Ringing");
exit;
}
}
route[FWD] {
#xlog("L_INFO","INSIDE FWD \n");
forward(x.x.x.x,5060);
}
Below is the scenario , where the customer is sending packets to Kamailio ,
and Kamailio is forwarding them the supplier (with IP x.x.x.x) , then the
supplier reply back to kamailio and kamailio relay the reply to the
customer
----Customer---- --> ----Kamailio ---> ---Supplier---
I have a case where the supplier sends in some cases an in-dialog invite
(Re-Invite) , which is considered I think as SIP-Request and thus as per
above routing logic , kamailio is sending it back to the supplier , yet I
need to send it to the customer.
How can I solve this issue?
Thanks
Ali Taher
Hi guys,
on a test server with kamailio 4.3.7 statefull configuration with dialog
I see a lot of messages like this..
Jul 16 15:20:26 vm-nextaitz-01 /usr/sbin/kamailio[31288]: ERROR: dialog
[dlg_req_within.c:340]: send_bye(): terminating non-confirmed dialogs
not supported
Jul 16 15:20:26 vm-nextaitz-01 /usr/sbin/kamailio[31288]: ERROR: dialog
[dlg_req_within.c:340]: send_bye(): terminating non-confirmed dialogs
not supported
Jul 16 15:20:26 vm-nextaitz-01 media-dispatcher[31555]: error: failed to
end dialog: 500 Operation failed
I'm not find the issue and the way for fix..
Any idea ?
Regards
Laura
Hi. I found some additional scenario when kamailio works incorrect with ACK
Cseq after succesfull auth with uac_auth but unsuccesfull call:
1.Caller via kamailio as proxy (Cseq 1)
2.Kamailio resends call to provider with Auth method (Cseq 1)
3. Provider answers 401/407 (Cseq 1)
4. Kamailio inrases Cseq and sends invite with credentians (dialog
track_cseq_updates = 1, uac_auth()) (Cseq 2)
5. Provider says - 404. not found (Cseq 2)
6. Kamailio resends INVITE to another server (lets say VM). It contans not
tracked yet Cseq (Cseq 1)
7. VM server says 200 (Cseq 1)
8. Kamailio resends 200 to the caller (Сseq 1)
9. Caller says ACK (Cseq 1)
10. Kamailio incrases CSeq of ACK and resends t VM server (Сseq 2)
So in this case kamialio tries to track Sceq because thining that this ACK
belongs to the dialog that was made to the auth server
So as I see here is a misunderstanding on the dialog module
Any suggestions how to avoid it or exclude resent INVITE from the dialog
module tracking?
Hi,
I've got a scenario where call branch #1 goes to an in-call announcement
server; the message is played out via unidirectional early media
(183+SDP), then that branch is disposed of with a 503. A subsequent call
then goes out to the real SIP provider that will ultimately answer the
call.
There's some trouble handling this with RTPEngine:
Two subsequent calls to rtpengine_offer() in a normal request route
context will result in two SDP message lumps concatenated in the second
INVITE (to the provider).
This can be fixed by putting the rtpengine_offer() invocations into
branch routes. However, the next problem is that then the identical
offer goes to the second callee with no regard for RTPEngine's internal
state, so RTPEngine ends up transmitting from a different port to the
one that is declared in the SDP offer, requiring NAT latching from the
provider to achieve proper symmetry in the return stream.
This can be fixed with:
rtpengine_offer("replace-origin replace-session-connection ICE=remove via-branch=1 internal external");
And in the reply handling:
rtpengine_answer("replace-origin replace-session-connection ICE=remove via-branch=2");
An alternative to using via-branch[1] is to simply delete the call before initiating branch #2:
rtpengine_delete("delete-delay=0");
rtpengine_offer("replace-origin replace-session-connection ICE=remove internal external");
However, both of these lead to the problem that caller receives two
distinct SDP answers on the respective branches.
I am not sure offhand whether this is a protocol semantics violation. On
the one hand, RFC 3261 § 13.2.1 ("Creating the Initial INVITE") says:
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
So, I always understood that the first answer is the final answer,
absent a session-updating request cycle. On the other hand, RFC 3960
("Early Media and Ringing Tone Generation in the Session Initiation
Protocol (SIP)") Section 4 says:
The application server model consists of having the UAS behave as an
application server to establish early media sessions with the UAC.
The UAC indicates support for the early-session disposition type
(defined in [2]) using the early-session option tag. This way, UASs
know that they can keep offer/answer exchanges for early media
(early-session disposition type) separate from regular media (session
disposition type).
I take this, along with RFC 3959 Section 3, to imply an amendment to
3261 § 13.2.1, but I'm not sure. Regardless, I'm not convinced all UAs
will handle this situation.
So, what I would most prefer is a means of recycling the same answer
port on the "back" side of RTPEngine while pivoting it on the front
across branches/multiple offers.
Is that possible? If so, how can it be achieved?
Many thanks,
-- Alex
[1] As best as I understood how to use it; the documentation is a bit
unclear!
--
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/
Hello.
My uplink usually gives ringback as both 183 Progress with SDP and 180 Ringing also with (different) SDP. One of my clients can't handle that behavior and it just don't plays ringback at all. Is it possible to relay only last provisional response with SDP and drop anything else 183? Any ideas plz? Can't figure out even a logic itself.
Thanks.
--
sent from myMail for Android
