Hi Community,
Any advice on how to handle a Retry-After header locally without sleeping?
I would like to suspend the transaction, schedule an event, wake up the
transaction after the event timer triggers, and resume the transaction. I
don't believe this is possible though.
Hi List
I want to be able to parallel branch a call to multiple registered
locations / multiple different AOR. So using the registrar lookup()
function can not be used.
I loop through all required AOR with reg_fetch_contacts, those could be
registered via a proxy and therefore require to use Path:
$ulc(aor=>path) in this case, contains the path to that destination.
On all 'additional' branches added with append_branch() I can set the
path using $branch(path).
But i struggle with the main aka first branch on which I directly set:
* $ru
* $fs
* $du
From the documentation, if I would use the registrar lookup() function,
then $du would correctly be set respecting the path for all contacts on
an AOR.
But who do I build $du manually with what I find in $ulc(aor=>path) when
not using lookup()?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello community!
I would like to ask for your help in solving a case. I thank you in advance
for any collaboration.
I have the following setup:
- *Asterisk (internal)* → *Kamailio (Proxy)* → *SIP Provider (PSTN)*
Both Asterisk and Kamailio are under my responsibility.
*Problem:*
When I initiate a call from Asterisk, I use Kamailio as the *outbound proxy*.
The *INVITE* is sent to the SIP provider, and the dialogue proceeds
normally until the provider responds with a *200 OK*, indicating the call
was answered.
However, the *200 OK* received from the provider contains a modification in
the *Contact* header, introducing a new IP address into the dialogue.
Presumably, this new IP is where the subsequent *ACK* should be sent.
The issue arises when Kamailio receives this *200 OK*: it overwrites the
*Contact* field, replacing the received IP with its own LAN IP, used for
communication with Asterisk. As a result, Asterisk sends the *ACK* back to
Kamailio, which, instead of forwarding it to the new IP from the *Contact*
in the *200 OK*, sends it to the SIP provider at the same address used for
the initial *INVITE*.
Since the *ACK* does not reach the IP expected by the provider (the new IP
introduced in the *Contact*), the provider continues to send repeated *200
OK* responses, until the call is disconnected due to a timeout, as a valid
*ACK* was never received.
I looked for conceptual answers in *RFC 3261* to support my conclusions,
but I couldn’t clearly relate the information there to the behavior
observed in this scenario.
*Key Questions:*
1.
*Should Kamailio forward the ACK to the new IP provided in the Contact
header of the 200 OK?*
2.
*Is the SIP provider correct in expecting the ACK to be sent to a
different address from the original one used in the INVITE?*
3.
*How can I configure Kamailio to ensure the dialogue proceeds correctly
and the ACK is sent to the correct IP?*
Hi Community,
Is it a common experience for architects to encounter issues with
active/active registrar designs? Specifically, when clients are the UAS of
a dialog? Some user agents accept INVITEs from any source once registered
while others are not as accepting.
There are ways around this using 302 redirect, but there seem to also be
ways per RFC to signal trusted nodes to clients. RFC 3608 seems to be an
excellent way to address this issue by communicating trustworthy nodes to
the client upon registration. However, the Service-Route header seems to
give options to the client rather than communicate trust.
No where in the RFC does trust seem to be mentioned in its design, however
one could imply it should be deduced by the presence of a Service-Route
header.
Nonetheless, even if it should communicate trust, it doesn't seem to do so
in all cases so the more logical approach to active/active is signal via a
302 redirect where the registration lives, handling INVITE transactions on
the server-side instead of client-side.
I'm curious to hear if there is any advice on from the community overcoming
trust issues with user agents in an active/active registrar design.
Hello Kamailio!
I'm etting up a kamailio server where it will receive STIP TLS connections from Zoom.
kamailio is closing TLS connections with error stating "SSL routines::no shared cipher (sni: unknown)" as below
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: tls [tls_server.c:270]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7fbcd1e9dac8 ctx 0x7fbcd2229258 sn [])
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: tls [tls_domain.c:1018]: tls_server_name_cb(): SSL_get_servername returned NULL: return SSL_TLSEXT_ERR_NOACK
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: <core> [core/tcp_main.c:2845]: tcpconn_do_send(): sending...
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: <core> [core/tcp_main.c:2881]: tcpconn_do_send(): after real write: c= 0x7fbcd3cb85d0 n=7 fd=8
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) DEBUG: <core> [core/tcp_main.c:2882]: tcpconn_do_send(): buf=
Sep 18 13:28:02 dalia kamailio[18529]: [3B blob data]
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error
Sep 18 13:28:02 dalia kamailio[18529]: 9(18529) ERROR: tls [tls_util.h:49]: tls_err_ret(): TLS accept:error:0A0000C1:SSL routines::no shared cipher (sni: unknown)
did a tcpdump trace to check the ciphers Zoom are using in the TLS client hello, and there are 4 and are supported by openssl on TLSv1.2, BUT the reis no server_name extension in the client hello.
is this related to kamailio refusing the connection because there is no server_name in the client hello or something else?, if yes can it be forced to accept TLS connection without server_name specified ?
my tls.cfg file is below
[server:default]
method = TLSv1.2
verify_certificate = no
require_certificate = no
private_key = /etc/kamailio/key.pem
certificate = /etc/kamailio/certificate.pem
ca_list = /etc/ssl/certs/ca-certificates.crt
ca_path = /etc/ssl/certs
[client:default]
method = TLSv1.2+
verify_certificate = no
require_certificate = no
Hi Kamailio community.
There are a few fields in the usrloc cache I am interested in accessing at
runtime to influence routing decisions. I can use SQLops to achieve the
same functionality, however I'm interested in minimizing DB operations. I
would like to know if there is a generally accepted approach to
retrieving this information from the memory-hosted usrloc cache rather than
dipping into the database.