[SR-Users] Re: Setting $du to websocket-secure
Hi Daniel, Henning
I tested the commit 60165196ad3144597c24eb9f7bb7fb0cd56f8c25 (which is
the one after your fix
https://github.com/kamailio/kamailio/commit/aa794581ecf105b5313d2f5b8bcfe516ab337936).
Although this gets my particular test INVITE working over TLS, it's
not ideal because it can allow a WSS INVITE to be relayed over TCP and
also allow a WS INVITE to be relayed over TLS (I'm not a C coder, but
that's what I suspected when I read the commit, so I tested it). It
seems as if the alias part ~5 or ~6 (for WS or WSS) is not fully
respected.
It's this scenario (the security problem of a TLS message being sent
in the clear) for which PR 3810 (which Henning mentioned earlier) was
made. That was important because an SBC might make multiple TCP/TLS
connections on behalf of sub-customers and then a conflict can arise
if/when a port get reused/shared.
However, now I see these points.
- This change affects only websocket, so doesn't completely undo the
good of that PR.
- A full/complete fix, I expect, might be much more complicated,
because it would involve changing how $du works internally and involve
nathelper as well as core.
- Perhaps I'll deprecate the non-TLS websocket listener in my proxy
server and then this won't matter any more. I expect that this will
result in everything (Via transport parameter, Record-Route port, etc)
working perfectly.
Thanks for your quick fix on this. I think it's going to unblock a
kamailio upgrade for me.
James
On Thu, 5 Sept 2024 at 08:59, James Browne wrote:
>
> Thanks, Henning.
> Yes it looks like the same issue.
> I see that Daniel pushed a commit an hour ago for this, so I'm going
> to test it right now if I can and see what I can find.
>
> James
>
> On Thu, 5 Sept 2024 at 06:19, Henning Westerholt wrote:
> >
> > Hello James,
> >
> > Thanks for sending the logs. I just briefly looked to the log files, at
> > least the port 443 "wrong" scenario looks similar from the error message to
> > the issue described here from somebody else:
> > https://github.com/kamailio/kamailio/issues/3969
> >
> > Cheers,
> >
> > Henning
> >
> > > -Original Message-
> > > From: James Browne via sr-users
> > > Sent: Mittwoch, 4. September 2024 12:23
> > > To: mico...@gmail.com
> > > Cc: Kamailio (SER) - Users Mailing List ;
> > > James
> > > Browne
> > > Subject: [SR-Users] Re: Setting $du to websocket-secure
> > >
> > > Thanks, Daniel
> > > Here are attached the logs with timestamps. I made two tests, involving
> > > INVITEs that differed only in the Call-ID and CSeq.
> > > In each case, the logs include the time of the websocket connection being
> > > made. There was no other traffic on the server during the test.
> > >
> > > ###
> > > INVITE
> > > sip:moon@bobbywomack.invalid;alias=11.15.32.1~3~6;transport=ws
> > > SIP/2.0
> > > Via: SIP/2.0/UDP 192.168.25.4:5060;rport;branch=z9hG4bK-d8754z-
> > > cc2c63344f5218d
> > > Route:
> > > Route:
> > > From: ;tag=1a56f142c2ed4d2f
> > > To:
> > > ###
> > >
> > > In log "port-80.txt", there was a websocket connection open to non-TLS
> > > port
> > > 80, and the INVITE was relayed over it.
> > > In log "port-443.txt", there was a websocket connection open to TLS port
> > > 443,
> > > and the INVITE wasn't relayed.
> > >
> > > The kamailio.cfg was effectively this.
> > > #
> > > tcp_connection_match=1
> > > request_route {
> > > route(INITIAL_INVITE_OUTGOING);
> > > }
> > > route[INITIAL_INVITE_OUTGOING] {
> > > loose_route_preloaded();
> > > handle_ruri_alias();
> > > xlog("L_NOTICE", "[$ci] P1052 About to relay WS call to $dd:$dp from
> > > $fs
> > > ($$du is $du)\n");
> > > if (!t_relay_to("0x02")) {
> > > xlog("L_WARN", "[$ci] P1052 Failed relaying WS call to
> > > $dd:$dp\n");
> > > t_reply("503", "Relaying over WS to next hop failed");
> > > }
> > > exit;
> > > }
> > > #
> > >
> > > James
> > >
> > > On Tue, 3 Sept 2024 at 15:53, Daniel-Constantin Mierla
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > can you run with debug=3 in kamailio.cfg
[SR-Users] Re: Setting $du to websocket-secure
Thanks, Henning.
Yes it looks like the same issue.
I see that Daniel pushed a commit an hour ago for this, so I'm going
to test it right now if I can and see what I can find.
James
On Thu, 5 Sept 2024 at 06:19, Henning Westerholt wrote:
>
> Hello James,
>
> Thanks for sending the logs. I just briefly looked to the log files, at least
> the port 443 "wrong" scenario looks similar from the error message to the
> issue described here from somebody else:
> https://github.com/kamailio/kamailio/issues/3969
>
> Cheers,
>
> Henning
>
> > -Original Message-
> > From: James Browne via sr-users
> > Sent: Mittwoch, 4. September 2024 12:23
> > To: mico...@gmail.com
> > Cc: Kamailio (SER) - Users Mailing List ; James
> > Browne
> > Subject: [SR-Users] Re: Setting $du to websocket-secure
> >
> > Thanks, Daniel
> > Here are attached the logs with timestamps. I made two tests, involving
> > INVITEs that differed only in the Call-ID and CSeq.
> > In each case, the logs include the time of the websocket connection being
> > made. There was no other traffic on the server during the test.
> >
> > ###
> > INVITE
> > sip:moon@bobbywomack.invalid;alias=11.15.32.1~3~6;transport=ws
> > SIP/2.0
> > Via: SIP/2.0/UDP 192.168.25.4:5060;rport;branch=z9hG4bK-d8754z-
> > cc2c63344f5218d
> > Route:
> > Route:
> > From: ;tag=1a56f142c2ed4d2f
> > To:
> > ###
> >
> > In log "port-80.txt", there was a websocket connection open to non-TLS port
> > 80, and the INVITE was relayed over it.
> > In log "port-443.txt", there was a websocket connection open to TLS port
> > 443,
> > and the INVITE wasn't relayed.
> >
> > The kamailio.cfg was effectively this.
> > #
> > tcp_connection_match=1
> > request_route {
> > route(INITIAL_INVITE_OUTGOING);
> > }
> > route[INITIAL_INVITE_OUTGOING] {
> > loose_route_preloaded();
> > handle_ruri_alias();
> > xlog("L_NOTICE", "[$ci] P1052 About to relay WS call to $dd:$dp from $fs
> > ($$du is $du)\n");
> > if (!t_relay_to("0x02")) {
> > xlog("L_WARN", "[$ci] P1052 Failed relaying WS call to $dd:$dp\n");
> > t_reply("503", "Relaying over WS to next hop failed");
> > }
> > exit;
> > }
> > #
> >
> > James
> >
> > On Tue, 3 Sept 2024 at 15:53, Daniel-Constantin Mierla
> > wrote:
> > >
> > > Hello,
> > >
> > > can you run with debug=3 in kamailio.cfg and attach all the debug
> > > messages printed by Kamailio in such case? It will help to figure out
> > > where it fails first to find properly the connection.
> > >
> > > Cheers,
> > > Daniel
> > >
> > > On 03.09.24 15:24, James Browne wrote:
> > > > Thanks for your continued answers, Daniel.
> > > >
> > > > I have an edge proxy in front of the registrar. The edge proxy calls
> > > > add_contact_alias() whenever a REGISTER is received over websocket
> > > > (before relaying the REGISTER to the registrar).
> > > >
> > > > 2) Today I tested swapping the order of the loose_route() and
> > > > handle_ruri_alias() functions, but the result was the same. Always
> > > > if the RURI (after handle_ruri_alias() is called) has transport=ws
> > > > in it, then kamailio won't deliver it over a TLS websocket
> > > > connection (when tcp_connection_match is set).
> > > >
> > > > 1) So how can I set the $du to specify what websocket-over-tls
> > > > (rather than websocket-over-tcp-without tls) should be used? The
> > > > handle_ruri_alias() function does not achieve this when I test it.
> > > > Remember that "transport=ws" is used for both WS and WSS.
> > > >
> > > > James
> > > >
> > > > On Mon, 2 Sept 2024 at 16:00, Daniel-Constantin Mierla
> > > > wrote:
> > > >> Hello,
> > > >>
> > > >> I didn't have the time to go in details over this discussion, but
> > > >> if I got it right quickly, then:
> > > >>
> > > >> 1) you can set $du to any SIP URI, where the transport parameter
> > > >> can be whatever you want
> > > >>
> > > >> 2) handle_ruri_
[SR-Users] Re: Setting $du to websocket-secure
Thanks for your continued answers, Daniel. I have an edge proxy in front of the registrar. The edge proxy calls add_contact_alias() whenever a REGISTER is received over websocket (before relaying the REGISTER to the registrar). 2) Today I tested swapping the order of the loose_route() and handle_ruri_alias() functions, but the result was the same. Always if the RURI (after handle_ruri_alias() is called) has transport=ws in it, then kamailio won't deliver it over a TLS websocket connection (when tcp_connection_match is set). 1) So how can I set the $du to specify what websocket-over-tls (rather than websocket-over-tcp-without tls) should be used? The handle_ruri_alias() function does not achieve this when I test it. Remember that "transport=ws" is used for both WS and WSS. James On Mon, 2 Sept 2024 at 16:00, Daniel-Constantin Mierla wrote: > > Hello, > > I didn't have the time to go in details over this discussion, but if I > got it right quickly, then: > > 1) you can set $du to any SIP URI, where the transport parameter can be > whatever you want > > 2) handle_ruri_alias() should be done after and loose-route processing. > The Route headers are about intermediary hops, not the end points, and > therefore they have to be consumed first. The ruri-alias should be about > endpoint, so handling it has to be done by the last SIP proxy before the > endpoint, where there is no other intermediary SIP hop (proxy). > > Cheers, > Daniel > > On 02.09.24 16:50, James Browne via sr-users wrote: > > Thanks, Daniel > > The problem is specifically about sending traffic to websocket clients > > that have already established connections to my kamailio proxy. > > > > Thanks, Henning > > You're right. That PR caused this problem, but it didn't really > > _create_ a bug but highlighted one that was already there. > > Before that PR, kamailio would relay traffic destined for a websocket > > client via a WSS connection, but it was working only due to two bugs > > that would cancel each other out. As far as I can tell, this is how it > > worked. > > - Kamailio would see the transport=ws and decide it would relay the > > message over a TCP Websocket connection to the customer's TCP port. > > - Kamailio would see a TLS connection open using that customer-side > > TCP port and relay what it was treating as a non-TLS message through a > > TLS connection. > > Of course, after that PR fixed the second bug, the first came to light. > > > > Anyway, is there a way to set the $du to a TLS-websocket URI? If not, > > then this looks like a bug to me and I think I should log a bug > > report. I've tested this thoroughly already and have a good feel for > > it. > > > > (Full disclosure: I was involved with that PR 3810 that Henning mentioned.) > > > > James > > > > On Fri, 30 Aug 2024 at 09:08, Henning Westerholt wrote: > >> Hello James, > >> > >> It sounds a bit like a similar issue that was fixed some time ago for > >> overlapping TCP and TLS sockets: > >> https://github.com/kamailio/kamailio/pull/3810 > >> > >> Cheers, > >> > >> Henning > >> > >> -- > >> Henning Westerholt - https://skalatan.de/blog/ > >> Kamailio services - https://gilawa.com > >> > >>> -Original Message- > >>> From: James Browne via sr-users > >>> Sent: Donnerstag, 29. August 2024 13:35 > >>> To: Kamailio (SER) - Users Mailing List > >>> Cc: James Browne > >>> Subject: [SR-Users] Setting $du to websocket-secure > >>> > >>> How can I set the destination URI for an INVITE to be a websocket-secure > >>> destination? Is it possible? > >>> > >>> Summary > >>> I've a proxy with tcp_connection_match=1, but websocket URIs always have > >>> transport=ws (never transport=wss) in them, so relaying a call to a WSS > >>> connection always fails. > >>> I tested running kamailio 6.0.0-dev2 compiled from a commit made this > >>> week. > >>> This proxy server uses nathelper rather than outbound module. > >>> > >>> Detail > >>> We know that "transport=ws" is used for both WS and WSS. I've a proxy > >>> server that receives an INVITE for a WSS destination, and this proxy > >>> supports > >>> both WS and WSS. > >>> This proxy server must have core parameter tcp_connection_match=1 set, and > >>> this leads the t_relay() to fail. > >>> When an INVITE comes, th
[SR-Users] Re: Setting $du to websocket-secure
Thanks, Daniel The problem is specifically about sending traffic to websocket clients that have already established connections to my kamailio proxy. Thanks, Henning You're right. That PR caused this problem, but it didn't really _create_ a bug but highlighted one that was already there. Before that PR, kamailio would relay traffic destined for a websocket client via a WSS connection, but it was working only due to two bugs that would cancel each other out. As far as I can tell, this is how it worked. - Kamailio would see the transport=ws and decide it would relay the message over a TCP Websocket connection to the customer's TCP port. - Kamailio would see a TLS connection open using that customer-side TCP port and relay what it was treating as a non-TLS message through a TLS connection. Of course, after that PR fixed the second bug, the first came to light. Anyway, is there a way to set the $du to a TLS-websocket URI? If not, then this looks like a bug to me and I think I should log a bug report. I've tested this thoroughly already and have a good feel for it. (Full disclosure: I was involved with that PR 3810 that Henning mentioned.) James On Fri, 30 Aug 2024 at 09:08, Henning Westerholt wrote: > > Hello James, > > It sounds a bit like a similar issue that was fixed some time ago for > overlapping TCP and TLS sockets: > https://github.com/kamailio/kamailio/pull/3810 > > Cheers, > > Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ > Kamailio services - https://gilawa.com > > > -Original Message- > > From: James Browne via sr-users > > Sent: Donnerstag, 29. August 2024 13:35 > > To: Kamailio (SER) - Users Mailing List > > Cc: James Browne > > Subject: [SR-Users] Setting $du to websocket-secure > > > > How can I set the destination URI for an INVITE to be a websocket-secure > > destination? Is it possible? > > > > Summary > > I've a proxy with tcp_connection_match=1, but websocket URIs always have > > transport=ws (never transport=wss) in them, so relaying a call to a WSS > > connection always fails. > > I tested running kamailio 6.0.0-dev2 compiled from a commit made this week. > > This proxy server uses nathelper rather than outbound module. > > > > Detail > > We know that "transport=ws" is used for both WS and WSS. I've a proxy > > server that receives an INVITE for a WSS destination, and this proxy > > supports > > both WS and WSS. > > This proxy server must have core parameter tcp_connection_match=1 set, and > > this leads the t_relay() to fail. > > When an INVITE comes, these are the steps. > > - The URI is something like > > sip:user@anonymous.invalid;alias=198.51.100.10~52833~6;transport=ws. > > - First handle_ruri_alias() removes the alias (which has ~6 in it, for > > wss) and sets the $du to something like > > sip:198.51.100.10:52833;transport=ws. > > - Then loose_route_preloaded() processes the Route header fields and forces > > the outbound socket to the TLS websocket one. > > - Then t_relay() fails to relay the INVITE and responds with 477 or 500. > > > > If, however, there's a non-TLS websocket connection open to the proxy, the > > INVITE would be erroneously relayed over that (using the wrong kamailio-side > > TCP port). > > I can go deeper with testing if required. I wonder whether this is a bug. > > > > James > > __ > > Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe > > send an email to sr-users-le...@lists.kamailio.org > > Important: keep the mailing list in the recipients, do not reply only to the > > sender! > > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Setting $du to websocket-secure
How can I set the destination URI for an INVITE to be a websocket-secure destination? Is it possible? Summary I've a proxy with tcp_connection_match=1, but websocket URIs always have transport=ws (never transport=wss) in them, so relaying a call to a WSS connection always fails. I tested running kamailio 6.0.0-dev2 compiled from a commit made this week. This proxy server uses nathelper rather than outbound module. Detail We know that "transport=ws" is used for both WS and WSS. I've a proxy server that receives an INVITE for a WSS destination, and this proxy supports both WS and WSS. This proxy server must have core parameter tcp_connection_match=1 set, and this leads the t_relay() to fail. When an INVITE comes, these are the steps. - The URI is something like sip:user@anonymous.invalid;alias=198.51.100.10~52833~6;transport=ws. - First handle_ruri_alias() removes the alias (which has ~6 in it, for wss) and sets the $du to something like sip:198.51.100.10:52833;transport=ws. - Then loose_route_preloaded() processes the Route header fields and forces the outbound socket to the TLS websocket one. - Then t_relay() fails to relay the INVITE and responds with 477 or 500. If, however, there's a non-TLS websocket connection open to the proxy, the INVITE would be erroneously relayed over that (using the wrong kamailio-side TCP port). I can go deeper with testing if required. I wonder whether this is a bug. James __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] TLS requests get relayed over unencrypted TCP
Hi all
I've set up a kamailio server on a public IP address to serve public clients.
- The clients REGISTER over a mix of TCP and TLS, so kamailio has
listeners on the same IP address: port 5060 for UDP/TCP and port 5061
for TLS.
- Some clients REGISTER from the same public IP address, behind the same NAT.
- Sometimes, the client-side NAT can use the same client-side IP
address and port for two concurrent connections - one TCP and one TLS
- which is normal because the server-side port is different (they're
different 5-tuples).
- Now when a request comes to kamailio, to be routed to a client, the
the t_relay_to_tls() function sometimes can relay the request over a
TCP connection instead of a TLS connection.
I've enabled tcp_connection_match=1. This is helpful, but it doesn't
completely resolve the problem. It helps when both connections (TCP
and TLS) are open, because the TLS connection will always be used for
TLS requests. However, when there's no TLS connection open, kamailio
will erroneously use the TCP connection.
Note that this setup depends on TCP/TLS connections being made from
the client to the server, not the other way around.
I've made a cut-down version of this setup to demonstrate the problem.
- Client: 11.15.32.1
- Server: 11.15.32.11
- version: kamailio 5.9.0-dev0 (x86_64/linux)
#
#!KAMAILIO
enable_tls=yes
listen=tls:11.15.32.11:5061
listen=tcp:11.15.32.11:5060
listen=udp:11.15.32.11:5060
loadmodule "tm"
loadmodule "tls"
loadmodule "pv"
loadmodule "rr"
fork=yes
log_facility=LOG_LOCAL0
log_stderror=no
children=2
debug=3
tcp_connection_match=1
modparam("tls", "low_mem_threshold1", -1)
modparam("tls", "low_mem_threshold2", -1)
modparam("tls", "certificate", "/usr/local/etc/kamailio/certs/chain")
modparam("tls", "private_key", "/usr/local/etc/kamailio/certs/key")
request_route {
loose_route();
$fs="tls:11.15.32.11:5061";
t_relay_to_tls();
}
#
This is a BYE message to be sent from internally in the network.
###
BYE sip:user3@11.15.32.1:3;transport=tls SIP/2.0
Via: SIP/2.0/UDP 0.0.0.0:1;rport;branch=z9hG4bK-d8754z-cc2c63344f5218d3-1
Route:
Route:
f: ;tag=ZUrDU2m4Z9Zam
t: ;tag=gK0ea97395
i:sdfg8we790t874ujk
CSeq: 102 BYE
Content-Length: 0
###
When I send that to kamailio over UDP, kamailio relays it over a TCP
connection, as seen with socat here (socat runs on the machine with
address 11.15.32.1).
###
$ socat - TCP:11.15.32.11:5060,bind=:3
BYE sip:user3@11.15.32.1:3;transport=tls SIP/2.0
Via: SIP/2.0/TLS
11.15.32.11:5061;branch=z9hG4bKd2bf.137932ff9a937cde941fd1790db040c9.0
Via: SIP/2.0/UDP
0.0.0.0:1;received=11.15.32.11;rport=1;branch=z9hG4bK-d8754z-cc2c63344f5218d3-1
f: ;tag=ZUrDU2m4Z9Zam
t: ;tag=gK0ea97395
i:sdfg8we790t874ujk
CSeq: 102 BYE
Content-Length: 0
###
Note that
- the RURI has transport=tls in it,
- kamailio is forcing the TLS socket,
- kamailio is using the t_relay_to_tls function,
- the Route header field tells that TLS should be used, and
- the Via header field shows that kamailio tried to send this over TLS, but
- the BYE was sent over unencrypted TCP.
If I use this socat command instead, then I can receive the BYE,
showing that kamailio is able to use TLS if there's a connection
available.
- socat - OPENSSL:11.15.32.11:5061,bind=:3,verify=no
I can't find any setting to control this, so it looks to me like a
kamailio bug. At that, I see this as a security flaw, because the SIP
traffic should always be encrypted but now is leaked.
Can anyone help?
James
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: append_hf not working
One pitfall would be to think that this function would add this header
field to any reply that kamailio would send. This append_hf() function
should add a header field to a SIP request that it *relays*, but would
not add it to a response that kamailio *generates* (for that, you
would use the append_to_reply() function).
James
On Mon, 11 Mar 2024 at 11:26, Alex Balashov via sr-users
wrote:
>
> Indeed, it has become a bit of a cliché that msg_apply_changes() should be
> called after append_hf(), uac_replace_from(), etc.
>
> This should be dispelled. In the vast majority of use-cases, it is not only
> unnecessary, but highly undesirable.
>
> -- Alex
>
> > On 11 Mar 2024, at 06:45, Henning Westerholt via sr-users
> > wrote:
> >
> > Hello,
> > the usage of msg_apply_changes is not necessary (not even recommended) for
> > append_hf (and other functions) to work. The OP was talking about a packet
> > capture, so I assume that he got the capture after the proxy send out the
> > message.
> > Cheers,
> > Henning
> > -- Henning Westerholt – https://skalatan.de/blog/
> > Kamailio services – https://gilawa.com
> > From: Unai Rodriguez via sr-users
> > Sent: Montag, 11. März 2024 09:33
> > To: Calvin E. via sr-users ; Kamailio (SER) -
> > Users Mailing List
> > Cc: Unai Rodriguez
> > Subject: [SR-Users] Re: append_hf not working
> > Using
> > https://kamailio.org/docs/modules/stable/modules/textopsx.html#textopsx.f.msg_apply_changes
> > might be relevant in your case...
> > With best wishes, Unai Rodriguez
> > On 11 Mar 2024 at 09:22 +0100, Benoit Panizzon via sr-users
> > , wrote:
> >
> > Hi Calvin
> >
> >
> > I'm trying to add something simple like the following:
> >
> > append_hf("X-testheader: True\r\n", "From");
> >
> > However, I don't see my X-testheader in a packet capture. Are there
> > any common pitfalls that would prevent append_hf from working as
> > expected?
> >
> > Weird, I use this a lot and it always works. But I never attempted to
> > specify the header after which it should be appended. Does it work if
> > you don't specifiy "From"?
> >
> > Mit freundlichen Grüssen
> >
> > -Benoît Panizzon-
> > --
> > 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
> > __
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
> > Edit mailing list options or unsubscribe:
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
> > Edit mailing list options or unsubscribe:
>
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: print_dset(): no r-uri or branches
I encountered this very problem yesterday. My code was similar to this
old code quoted a few years ago.
https://lists.kamailio.org/pipermail/sr-users/2017-November/099523.html
append_to_reply("Contact: sip:fred at 10.11.12.13\r\n");
sl_send_reply("302","moved");
exit;
The SIP worked fine, but the same error appeared every time the
SIP-302 response was sent.
To resolve the problem, I changed the code to this.
append_branch("sip:b...@example.com");
send_reply("302", "moved");
Now the SIP response works as before, kamailio adds the Contact to the
response (so I don't need append_to_reply()), and there's no warning.
James
On Thu, 7 Dec 2023 at 14:34, Saul Ibarra via sr-users
wrote:
>
> Hi!
>
> Have you changed the $rU & $ru?
>
> On Wed, Dec 6, 2023 at 10:15 AM Ali Taher via sr-users
> wrote:
>>
>> Hello all,
>>
>>
>>
>> I’m using Kamailio as SIP redirect where I’m appending the contact header
>> then send reply back using sl_send_reply("300","Multiple Choices").
>>
>>
>>
>> But I’m getting “print_dset(): no r-uri or branches” as warning in the log
>> and no packet is sent back from Kamailio to the original sender.
>>
>>
>>
>> I’m using same Kamailio configuration in another setup and it’s working
>> correctly without facing this error.
>>
>>
>>
>> I’m not able to detect the issue. Can you please assist?
>>
>>
>>
>> Regards,
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the
>> sender!
>> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: print_dset(): no r-uri or branches
It's hard to know, without some code or a packet capture.
If you can supply those, then I'll look at this for you.
James
On Wed, 6 Dec 2023 at 12:57, Ali Taher via sr-users
wrote:
>
> Hello all,
>
>
>
> I’m using Kamailio as SIP redirect where I’m appending the contact header
> then send reply back using sl_send_reply("300","Multiple Choices").
>
>
>
> But I’m getting “print_dset(): no r-uri or branches” as warning in the log
> and no packet is sent back from Kamailio to the original sender.
>
>
>
> I’m using same Kamailio configuration in another setup and it’s working
> correctly without facing this error.
>
>
>
> I’m not able to detect the issue. Can you please assist?
>
>
>
> Regards,
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: 5.6.4 debian htable dbmode=1 not writing at shutdown
I had a similar problem today. I know I'm replying months later. My problem was that I had an incorrect structure in the database. Neither the database (postgres) nor kamailo complained about the error. I upgraded from 5.6.1 to 5.7.2 and then the errors were obvious from kamailio. I changed the structure of the database (I had key_value as INTEGER instead of VARCHAR, etc) and then it worked perfectly. It would have been easy for me to blame kamailio, but it wasn't a kamailio bug. Maybe instead I might have changed the debugging level to find the cause; I skipped that because I had planned to upgrade kamailio to 5.7.2 anyway. James On Tue, 1 Aug 2023 at 07:27, Володимир Іванець wrote: > > Hello! > > Kamailio 5.6 is not saving data to the DB on shutdown on CentOS 7 for me too. > > вт, 1 серп. 2023 р., 09:47 користувач пише: >> >> Can someone confirm this? >> >> Or even better: is there a solution? >> __ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the >> sender! >> Edit mailing list options or unsubscribe: > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: SIP Proxy : BYE next hop
The loose_route() function changes the next-hop address and "absorbs"
the appropriate Route header field(s), but it doesn't route the SIP
request.
Your block of code is missing the t_relay() function call. I don't see
anything wrong with the BYE, so adding that line of code - I hope -
should work for you.
James
On Thu, 2 Nov 2023 at 14:12, Ali Taher wrote:
>
> Hi Yuriy,
>
>
>
> Thanks, I used what you suggested below, and still getting 1 as result for
> loose_route(), but BYE message is not routed anywhere.
>
>
>
> Regards,
>
>
>
> From: Yuriy G
> Sent: Thursday, November 2, 2023 3:05 PM
> To: Kamailio (SER) - Users Mailing List
> Cc: James Browne ; Ali Taher
> Subject: Re: [SR-Users] Re: SIP Proxy : BYE next hop
>
>
>
> loose_route returns result in the $rc variable
> Return code should be handed like this:
>
> https://www.kamailio.org/wikidocs/cookbooks/5.6.x/pseudovariables/#rc-returned-code
>
>
>
> чт, 2 нояб. 2023 г. в 13:27, Ali Taher via sr-users
> :
>
> Hi James,
>
> Here are my listen directives:
> listen=udp:192.168.1.2:5060
> listen=tcp: 192.168.1.2:5060
>
> knowing that:
> Kamailio IP: 192.168.1.2
> SBC IP: 192.168.1.1
> Caller IP: 192.168.1.5
>
> -Original Message-
> From: Ali Taher via sr-users
> Sent: Thursday, November 2, 2023 1:42 PM
> To: James Browne ; Kamailio (SER) - Users Mailing List
>
> Cc: Ali Taher
> Subject: [SR-Users] Re: SIP Proxy : BYE next hop
>
> Hi James,
>
> Yes I'm using loose_route() and it's returning 1, but BYE message is not
> routed anywhere.
>
> Frame 6213: 673 bytes on wire (5384 bits), 673 bytes captured (5384 bits)
> Ethernet II, Src: Cisco_f8:19:ff (00:22:bd:f8:19:ff), Dst: VMware_bf:27:0b
> (00:50:56:bf:27:0b) Internet Protocol Version 4, Src: 192.168.1.5, Dst:
> 192.168.1.2 User Datagram Protocol, Src Port: 16368, Dst Port: 5060 Session
> Initiation Protocol (BYE)
> Request-Line: BYE sip:192.168.1.1:5060;transport=udp SIP/2.0
> Message Header
> Via: SIP/2.0/UDP
> 192.168.1.5:16368;branch=z9hG4bK-d87543-c147891e677a1f19-1--d87543-;rport
> Max-Forwards: 70
> Route:
> Route:
> Contact:
> To: "121";tag=gtyrzghr-CC-1047-OFC-39
> From: "69079514";tag=7d4a7c3c
> Call-ID: 085d9048b81abc1eNDUwODVhMjI2NDk5NDM3YmZiZWZiYzI0YWZkOTU1Njc.
> [Generated Call-ID:
> 085d9048b81abc1eNDUwODVhMjI2NDk5NDM3YmZiZWZiYzI0YWZkOTU1Njc.]
> CSeq: 2 BYE
> User-Agent: eyeBeam release 1003s stamp 31159
> Reason: SIP;description="User Hung Up"
> Content-Length: 0
>
> Here is routing block related to BYE:
> if (is_method("BYE")) {
> xlog("L_INFO","INSIDE BYE");
> $var(loose) = loose_route();
> xlog("L_INFO","LOOSE : $var(loose)");
> }
>
>
> Regards,
>
> -Original Message-
> From: James Browne
> Sent: Thursday, November 2, 2023 12:31 PM
> To: Kamailio (SER) - Users Mailing List
> Cc: Ali Taher
> Subject: Re: [SR-Users] SIP Proxy : BYE next hop
>
> Hello
> Did you call the loose_route() function for the BYE? It should just work;
> that's one of the basics of how kamailio works, so I'll be very surprised if
> there's somehow a bug in kamailio.
> If that does not work, perhaps send a list of the listen directives in the
> kamailio.cfg, along with the headers of the two SIP BYE messages (incoming
> and outgoing) and I'll see what I can figure out for you.
>
> James
>
> On Thu, 2 Nov 2023 at 09:35, Ali Taher via sr-users
> wrote:
> >
> > Hello all,
> >
> >
> >
> > I’m using Kamailio as SIP proxy between session manager and SBC.
> >
> > I came across an issue in BYE request where the SBC sent in the header
> > list of Routes where first route is Kamailio IP, and the second is SM
> > IP, in addition to other routes (last route is the caller party)
> >
> > What Kamailio did is to route the BYE to the address set in the
> > Request-URI, which is the caller party.
> >
> > What should be done instead is that Kamailio should remove the Route header
> > including its own IP, and route the BYE to the next hop which is in this
> > case the SM IP.
> >
> >
> >
> > How to accomplish that?
> >
> >
> >
> > Following is the Route header in the BYE request coming from SBC:
> >
> > [truncated]Route:
> > , > port=udp;lr;av-asset-uid=xx>, > p;ibmsid=local._x_x;lr;ibmdrr>,sips:127.0.
> > 0
[SR-Users] Re: SIP Proxy : BYE next hop
Hello Did you call the loose_route() function for the BYE? It should just work; that's one of the basics of how kamailio works, so I'll be very surprised if there's somehow a bug in kamailio. If that does not work, perhaps send a list of the listen directives in the kamailio.cfg, along with the headers of the two SIP BYE messages (incoming and outgoing) and I'll see what I can figure out for you. James On Thu, 2 Nov 2023 at 09:35, Ali Taher via sr-users wrote: > > Hello all, > > > > I’m using Kamailio as SIP proxy between session manager and SBC. > > I came across an issue in BYE request where the SBC sent in the header list > of Routes where first route is Kamailio IP, and the second is SM IP, in > addition to other routes (last route is the caller party) > > What Kamailio did is to route the BYE to the address set in the Request-URI, > which is the caller party. > > What should be done instead is that Kamailio should remove the Route header > including its own IP, and route the BYE to the next hop which is in this case > the SM IP. > > > > How to accomplish that? > > > > Following is the Route header in the BYE request coming from SBC: > > [truncated]Route: > ,,,sips:127.0.0.2:15061;ibmsid=local.xx_xx_;lr;ibmdrr, > sip:SM1@SM_IP;transport=tls;lr;av-asset-uid=xx, > sip:CALLER_PARTY_IP:5061;transport=tls;lr > > > > Regards, > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Inquiry Regarding Kamailio Behavior and Drop Requests
I don't think it's possible. It's definitely not _always_ possible.
For example, if a non-SIP message arrives to kamailio, then the
request_route is never going to run, because the core will drop the
message first.
If I was to troubleshoot this further, then I'd get logs with
(millisecond) timestamps, take pcap traces at the same time, and then
later see what matches. That's how I'll know which SIP messages (or IP
packets) are getting dropped (to make the core:drop_requests
statistic). I don't know how else to do it, but I expect that this
should certainly work.
James
On Thu, 26 Oct 2023 at 15:01, satyaprakash ch
wrote:
>
> Thanks for the reply,
>
> I didn't find any suspicious logs in kamailio apart from the log which i
> shared with you in chain mail.
> Within a Pcap trace, we typically process INVITE, 300 Multiple Choice
> responses, and ACK messages pertaining to a specific server
>
> Note: For these drop requests, How do we acknowledge in kamailio?
> -- Is it possible to manage these drop requests in the Kamailio
> configuration file without actually dropping the request?
>
> Let me know if you need more information.
>
> On Thu, Oct 26, 2023 at 8:18 PM James Browne wrote:
>>
>> That looks to me that an ACK was received at kamailio for a response
>> that it generated (not relayed) to the UAC. It's normal for the SL
>> module to absorb such an ACK. It's not an error condition.
>> Your original message was about "core:drop_requests", so I doubt that
>> it's related.
>> My same advice applies: take traces and logs, and correlate them.
>>
>> > Also I have another query, For these drop requests, How do we acknowledge
>> > in kamailio?
>> What do you mean, exactly?
>>
>> James
>>
>> On Thu, 26 Oct 2023 at 13:11, satyaprakash ch
>> wrote:
>> >
>> > Hi,
>> >
>> > Thanks for the reply,
>> >
>> > When I was testing, I found the below log.
>> >
>> > Log DEBUG: sl [sl_funcs.c:462]: sl_filter_ACK(): SL local ACK
>> > found -> dropping it!
>> >
>> > On Wed, Oct 25, 2023 at 12:44 PM Henning Westerholt
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> the sanity module can be used for request and reply checks, as e.g.
>> >> visible in the default configuration.
>> >> It might be a bit too short documented in the module readme.
>> >>
>> >> Cheers,
>> >>
>> >> Henning Westerholt
>> >>
>> >> --
>> >> Henning Westerholt - https://skalatan.de/blog/
>> >> Kamailio services - https://gilawa.com
>> >>
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: James Browne via sr-users
>> >> > Sent: Dienstag, 24. Oktober 2023 17:55
>> >> > To: Kamailio (SER) - Users Mailing List
>> >> > Cc: satyaprakash ch ; James Browne
>> >> >
>> >> > Subject: [SR-Users] Re: Inquiry Regarding Kamailio Behavior and Drop
>> >> > Requests
>> >> >
>> >> > I expect that it's not related, because the documentation is clear that
>> >> > the
>> >> > function relates to requests, not responses.
>> >> >
>> >> > https://kamailio.org/docs/modules/5.5.x/modules/sanity.html#sanity.f.sanit
>> >> > y_check
>> >> > - 4.1. sanity_check([msg_checks [, uri_checks]])
>> >> > - This function makes a row of sanity checks over the given SIP
>> >> > request...
>> >> >
>> >> > It seems simple: check the logs from the xlog command and see what you
>> >> > find.
>> >> > If it's not clear enough, add the Call-ID to the log message, and then
>> >> > also
>> >> > capture (tshark/tcpdump) traffic for subsequent analysis.
>> >> >
>> >> > James
>> >> >
>> >> > On Mon, 16 Oct 2023 at 16:52, satyaprakash ch via sr-users > >> > us...@lists.kamailio.org> wrote:
>> >> > >
>> >> > > Hi,
>> >> > >
>> >> > > We possess a code within Kamailio, which specifically handles
>> >> > > malformed SIP
>> >> > responses. Below is the code snippet:
>> >> > >
>> >> > > reply_route
>> >> > > Copy code
>> >> > > if(!sanity_check("17604
[SR-Users] Re: Inquiry Regarding Kamailio Behavior and Drop Requests
That looks to me that an ACK was received at kamailio for a response
that it generated (not relayed) to the UAC. It's normal for the SL
module to absorb such an ACK. It's not an error condition.
Your original message was about "core:drop_requests", so I doubt that
it's related.
My same advice applies: take traces and logs, and correlate them.
> Also I have another query, For these drop requests, How do we acknowledge in
> kamailio?
What do you mean, exactly?
James
On Thu, 26 Oct 2023 at 13:11, satyaprakash ch
wrote:
>
> Hi,
>
> Thanks for the reply,
>
> When I was testing, I found the below log.
>
> Log DEBUG: sl [sl_funcs.c:462]: sl_filter_ACK(): SL local ACK found
> -> dropping it!
>
> On Wed, Oct 25, 2023 at 12:44 PM Henning Westerholt wrote:
>>
>> Hello,
>>
>> the sanity module can be used for request and reply checks, as e.g. visible
>> in the default configuration.
>> It might be a bit too short documented in the module readme.
>>
>> Cheers,
>>
>> Henning Westerholt
>>
>> --
>> Henning Westerholt - https://skalatan.de/blog/
>> Kamailio services - https://gilawa.com
>>
>>
>>
>> > -Original Message-
>> > From: James Browne via sr-users
>> > Sent: Dienstag, 24. Oktober 2023 17:55
>> > To: Kamailio (SER) - Users Mailing List
>> > Cc: satyaprakash ch ; James Browne
>> >
>> > Subject: [SR-Users] Re: Inquiry Regarding Kamailio Behavior and Drop
>> > Requests
>> >
>> > I expect that it's not related, because the documentation is clear that the
>> > function relates to requests, not responses.
>> >
>> > https://kamailio.org/docs/modules/5.5.x/modules/sanity.html#sanity.f.sanit
>> > y_check
>> > - 4.1. sanity_check([msg_checks [, uri_checks]])
>> > - This function makes a row of sanity checks over the given SIP request...
>> >
>> > It seems simple: check the logs from the xlog command and see what you
>> > find.
>> > If it's not clear enough, add the Call-ID to the log message, and then also
>> > capture (tshark/tcpdump) traffic for subsequent analysis.
>> >
>> > James
>> >
>> > On Mon, 16 Oct 2023 at 16:52, satyaprakash ch via sr-users > > us...@lists.kamailio.org> wrote:
>> > >
>> > > Hi,
>> > >
>> > > We possess a code within Kamailio, which specifically handles malformed
>> > > SIP
>> > responses. Below is the code snippet:
>> > >
>> > > reply_route
>> > > Copy code
>> > > if(!sanity_check("17604", "6")) {
>> > > xlog("Malformed SIP response from $si:$sp\n"); drop;
>> > >
>> > > Additionally, we have Kamailio drop request statistics as follows:
>> > >
>> > > Command: kamctl stats | grep core:drop_requests Output of the command:
>> > > core:drop_requests = 5
>> > >
>> > > My queries are:
>> > >
>> > > 1. Is the aforementioned "reply_route" related to the drop requests we
>> > > are
>> > experiencing?
>> > > 2. If it is not related, what could be the cause of the drop requests?
>> > > __
>> > > Kamailio - Users Mailing List - Non Commercial Discussions To
>> > > unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> > > Important: keep the mailing list in the recipients, do not reply only to
>> > > the
>> > sender!
>> > > Edit mailing list options or unsubscribe:
>> > __
>> > Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
>> > send an email to sr-users-le...@lists.kamailio.org
>> > Important: keep the mailing list in the recipients, do not reply only to
>> > the
>> > sender!
>> > Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: Inquiry Regarding Kamailio Behavior and Drop Requests
I expect that it's not related, because the documentation is clear
that the function relates to requests, not responses.
https://kamailio.org/docs/modules/5.5.x/modules/sanity.html#sanity.f.sanity_check
- 4.1. sanity_check([msg_checks [, uri_checks]])
- This function makes a row of sanity checks over the given SIP request...
It seems simple: check the logs from the xlog command and see what you
find. If it's not clear enough, add the Call-ID to the log message,
and then also capture (tshark/tcpdump) traffic for subsequent
analysis.
James
On Mon, 16 Oct 2023 at 16:52, satyaprakash ch via sr-users
wrote:
>
> Hi,
>
> We possess a code within Kamailio, which specifically handles malformed SIP
> responses. Below is the code snippet:
>
> reply_route
> Copy code
> if(!sanity_check("17604", "6")) {
> xlog("Malformed SIP response from $si:$sp\n");
> drop;
>
> Additionally, we have Kamailio drop request statistics as follows:
>
> Command: kamctl stats | grep core:drop_requests
> Output of the command: core:drop_requests = 5
>
> My queries are:
>
> 1. Is the aforementioned "reply_route" related to the drop requests we are
> experiencing?
> 2. If it is not related, what could be the cause of the drop requests?
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: How to filter out xhttp request in event_route[siptrace:msg]
I used to have this problem, but I don't have it right now. I've never
fixed the problem, but I'm on 5.6.1 now and it doesn't happen.
What version have you got?
James
On Mon, 23 Oct 2023 at 07:26, Benoit Panizzon via sr-users
wrote:
>
> Hi Karsten
>
> > how are you measure the traffic you don't want to your Homer? Print stuff
> > in that Kamailio event route or something else?
>
> Basically, I want to mirror sip messages to homer, only sip messages
> relevant to calls, not anything else which might be processed by
> kamailio.
>
> modules.inc:loadmodule "siptrace.so"
> modules.inc:modparam("siptrace", "trace_flag", 22);
> modules.inc:modparam("siptrace", "trace_on", 1)
> modules.inc:modparam("siptrace", "trace_mode", 1)
> modules.inc:modparam("siptrace", "hep_mode_on", 1)
> modules.inc:modparam("siptrace", "hep_version", 3)
> modules.inc:modparam("siptrace", "hep_capture_id", HEP_CAP_AGENT)
> modules.inc:modparam("siptrace", "duplicate_uri", HOMERSIPURI)
>
> I also use the xhttp interface for jsonrpc and a custom API.
>
> For this I have kamailio also listen to TCP port 8080 to have those API
> xhttp requests clearly separated from call traffic.
>
> But, as I understand, xhttp requests are initially handled as if they
> were sip requests and get processed request_route{}
>
> So my request route starts with:
>
> request_route {
>
> # Handle DMQ requests
> route(DMQ_CAPTURE);
>
> # Make sure we operate on the correct port (not on the xhttp one)
> if ($Rp != 5060 && $Rp != 5061) {
> xlog("L_ERROR", "REQUEST_ROUTE $rm to wrong port $Rp\n");
> exit;
> }
>
> so all SIP method requests to port 8080 are being dropped.
>
> I process xhttp traffic with the appropriate event route and of course
> reject http requests to sip ports with the appropriate http error
> message.
>
> event_route[xhttp:request] {
> if ($avp(debug) > 0) {
> xlog("L_INFO", "$cfg(route): XHTTP Request to URI: $hu Port: $Rp
> BODY: $rb\n");
> }
> if ($Rp != 8080) {
> # We got a HTTP Request on a sip port. Reject!
> xhttp_reply("418", "I'm a teapot", "text/html", "I'm not
> a Web-Server!");
> exit;
> }
> if ($hu =~ "^/RPC") {
> ### KAMAILIO JSONRCP pass-through
> jsonrpc_dispatch();
> } else if ($hu =~ "^/API") {
> ### IMPROWARE API
>
> [...]
>
> What I observe is the siptrace module being triggered right at the
> start of request_route. This makes sense, I want to mirror every sip
> message.
>
> But his also causes mirroring of the xhttp requests and replies to port
> 8080.
>
> Is there a way to prevent this?
>
> siptrace has an event route capable of filtering, as I understand it is
> only possible to filter on the SIP request method, not anything else:
>
> event_route[siptrace:msg] {
> if(is_method("KDMQ")) {
> drop();
> }
> }
>
> Do I miss something? How can I prevent/filter xhttp requests to be
> mirrored by the siptrace module?
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-
> --
> I m p r o W a r e A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel +41 61 826 93 00
> CH-4133 PrattelnFax +41 61 826 93 01
> Schweiz Web http://www.imp.ch
> __
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: 回复: 回复: Re: kamailio Behind nat. How Record-Route should be added ？
Hi
You also uploaded a pcap trace, using this link (which you sent directly to
me).
- https://1drv.ms/u/s!AkdU9Y6p5WVyjnrodIHt6EgS-h3U
I read it and it's clear what's going wrong.
This is your desired flow.
192.168.0.11 ---> 192.168.0.2 ---> 122.97.130.198
192.168.0.11 <--- 36.140.122.12 <--- 122.97.130.198
In this, your INVITE goes to the public IP address (122.97.130.198) like
this.
INVITE sip:+8618626439917@122.97.130.198:15060;user=phone SIP/2.0
Record-Route:
Via: SIP/2.0/UDP 36.140.122.12:7080
;branch=z9hG4bKe61a.5fe9d645ef1bbe470ca6d57fa20375bf.0
Via: SIP/2.0/UDP 192.168.0.11:45642
;received=192.168.0.11;branch=z9hG4bK98457cb5b0e44505;rport=45642
The 200-OK goes to the UAC (192.168.0.11) like this.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 36.140.122.12:7080
;rport=7080;branch=z9hG4bKe61a.5fe9d645ef1bbe470ca6d57fa20375bf.0
Via: SIP/2.0/UDP 192.168.0.11:45642
;received=192.168.0.11;branch=z9hG4bK98457cb5b0e44505;rport=45642
Record-Route:
Record-Route:
Record-Route:
The problem is, as you know, that the ACK from the UAC is routed to the
public IP address 36.140.122.12, whereas you want it to be sent to the
private IP address.
For this, double record-routing is required, as suggested earlier in this
thread.
My best guess is that your proxy has one IP address. A problem is that we
now know that you have your listen directive set to listen on the private
interface, but always advertise the public IP address, but this is not what
you want. You want to advertise one address in one direction and another in
the other direction. You want two Record-Route header fields when relaying
the initial INVITE.
I see two possible solutions (but there may be others).
- Get your proxy server to listen on two addresses, and force the socket
when relaying messages. This can be cumbersome and tricky.
- Try using the record_route_preset() function from the rr module. This can
be used to write the two Record-Route header fields exactly as you want (in
the correct order, of course).
I recommend the second option, because it would be simpler for me to
implement. I don't know how to do it in KEMI, though.
https://kamailio.org/docs/modules/5.7.x/modules/rr.html#rr.f.record_route_preset
James
On Mon, 9 Oct 2023 at 07:12, 城门 虾米 via sr-users
wrote:
> listen=udp:0.0.0.0:7080 advertise 36.140.122.12:7080
> --
> *发件人:* Nick F
> *发送时间:* 2023年10月9日 6:36
> *收件人:* 城门 虾米
> *抄送:* Kamailio (SER) - Users Mailing List
> *主题:* Re: [SR-Users] 回复: Re: kamailio Behind nat. How Record-Route should
> be added ？
>
> Hello,
>
> Could you please share part of "listen=" in your config. Do you have two
> separate interfaces for each IP?
>
> пн, 9 окт. 2023 г. в 06:00, 城门 虾米 via sr-users <
> sr-users@lists.kamailio.org>:
>
>
>
>
>
> UA(192.168.0.11) received 183, find Record-Route(36.140.122.12)
> then send ACK to 36.140.122.12(Kamialio public ip) not
> 192.168.0.2(kamailio internal ip), so Kamailio can't receive ACK.
>
> this is my config，192.168.0.11 -> Kamailio -> Other SBC(public ip)
> function ksr_request_route()
> if KSR.is_INVITE() then
> KSR.rr.record_route();
> KSR.nathelper.fix_nated_contact()
> end
> end
>
> This question has been bothering me for a long time, help me
> --
> *发件人:* James Browne
> *发送时间:* 2023年10月2日 12:03
> *收件人:* Kamailio (SER) - Users Mailing List
> *抄送:* code...@msn.com
> *主题:* Re: [SR-Users] Re: kamailio Behind nat. How Record-Route should be
> added ？
>
> If you upload a packet capture, I'll look at it and try to tell you
> what's going wrong.
> This is certainly something that can work, and I always find that
> making a diagnosis with a packet capture is the root to the solution.
> It's going to be difficult for anyone to help resolve your problem
> without a code example, a trace, or a detailed description of the
> problem. If you start with a packet capture, then I'll try to help
> you. If you give me a sample of code, too, then it'll be easier for
> me.
>
> James
>
> On Thu, 28 Sept 2023 at 10:56, codenot--- via sr-users
> wrote:
> >
> > i tried. but it does't work.
> > modparam("rr", "enable_double_rr", 1)
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> > Edit mailing list options or unsubscribe:
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-u
[SR-Users] Re: kamailio Behind nat. How Record-Route should be added ？
If you upload a packet capture, I'll look at it and try to tell you
what's going wrong.
This is certainly something that can work, and I always find that
making a diagnosis with a packet capture is the root to the solution.
It's going to be difficult for anyone to help resolve your problem
without a code example, a trace, or a detailed description of the
problem. If you start with a packet capture, then I'll try to help
you. If you give me a sample of code, too, then it'll be easier for
me.
James
On Thu, 28 Sept 2023 at 10:56, codenot--- via sr-users
wrote:
>
> i tried. but it does't work.
> modparam("rr", "enable_double_rr", 1)
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: TM max_inv_lifetime being reset by downstream responses
No reason. It was just that I changed only the max_inv_lifetime for
testing (and included all settings for completeness).
James
On Mon, 25 Sept 2023 at 15:30, Fred Posner wrote:
>
> Any reason your fr_inv_timer is both so high and more than the max timer?
>
>
> Regards,
>
> Fred Posner
>
>
>
> > On Sep 25, 2023, at 11:03 AM, James Browne via sr-users
> > wrote:
> >
> > Hi all
> > I see this old thread from 2015.
> > -
> > https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/thread/RR4WCFIP6KQQOFW42GYMDUME75IPLZEF/
> >
> > It's about max_inv_lifetime not working properly.
> > I have this problem today: SIP-180 responses from downstream
> > apparently reset max_inv_lifetime, and the transaction can live for
> > hours (apparently indefinitely) even though max_inv_lifetime is set to
> > just over a minute.
> > By spacing the SIP-180 responses (from downstream) slightly longer
> > apart than than max_inv_lifetime in kamailio, I don't get the problem,
> > so it looks to me that this is TM not matching what's in the
> > documentation (which mentions that this should be a hard limit).
> >
> > With this configuration, SIP-180 responses every minute result in the
> > transaction never ending (until the client CANCELs the call).
> > - kamailio.cfg:modparam("tm", "fr_timer", 3000)
> > - kamailio.cfg:modparam("tm", "fr_inv_timer", 30)
> > - kamailio.cfg:modparam("tm", "max_inv_lifetime", 65000)
> > - kamailio.cfg:modparam("tm", "noisy_ctimer", 1)
> >
> > That other thread ends with Daniel mentioning that he'd have to look
> > at the code, but nothing further.
> >
> > Running "git log --grep max_inv_lifetime" shows me that the last/only
> > update that wasn't just documentation was in 2007.
> > Has anyone got an ideas?
> >
> > James
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
> > Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] TM max_inv_lifetime being reset by downstream responses
Hi all
I see this old thread from 2015.
-
https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/thread/RR4WCFIP6KQQOFW42GYMDUME75IPLZEF/
It's about max_inv_lifetime not working properly.
I have this problem today: SIP-180 responses from downstream
apparently reset max_inv_lifetime, and the transaction can live for
hours (apparently indefinitely) even though max_inv_lifetime is set to
just over a minute.
By spacing the SIP-180 responses (from downstream) slightly longer
apart than than max_inv_lifetime in kamailio, I don't get the problem,
so it looks to me that this is TM not matching what's in the
documentation (which mentions that this should be a hard limit).
With this configuration, SIP-180 responses every minute result in the
transaction never ending (until the client CANCELs the call).
- kamailio.cfg:modparam("tm", "fr_timer", 3000)
- kamailio.cfg:modparam("tm", "fr_inv_timer", 30)
- kamailio.cfg:modparam("tm", "max_inv_lifetime", 65000)
- kamailio.cfg:modparam("tm", "noisy_ctimer", 1)
That other thread ends with Daniel mentioning that he'd have to look
at the code, but nothing further.
Running "git log --grep max_inv_lifetime" shows me that the last/only
update that wasn't just documentation was in 2007.
Has anyone got an ideas?
James
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: uac_replace() and uac_restore debug help
1. Make sure that the RR module adds that ftag parameter, so that it knows when the to and from are swapped. 2. I don't know. I've not tried it, but it seems to me to be a bit mask. James On Fri, Jun 23, 2023, 16:41 Duarte Rocha wrote: > Hello, > > I'm currently experiencing some odd behaviours when using these functions > and I need some help debugging to find the root of the issue. > > I receive a call from a client and do some changes to the To and From > header using auto mode with password. Encrypted info goes on the > Record-Route header parameters (vsf\vst) normally. > > 1 - On subsequent requests sent by the originating client, domains on To > and From header are different from the ones sent in the first INVITE. In > this scenario, somehow the automatic modifying has errors on the end > result. Can the different domains affect the end result of the automatic > modifying or only the vsf\vst parameters and password are needed to the > auto replace\restore? > > 2 - How can I decrypt the info on vsf and vst parameters in order to > verify the info sent and the encryption? > > Cheers, > > Duarte Rocha > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: where add contact header to ack for fail messages
I made simple tests and it seems that this is a kamailio-TM-internal message being sent, not being processed by the cfg file. If this is simple enough and deterministic, you may consider using the corex module to edit the message as it's being sent "on the wire". I can't think of any other solution. https://kamailio.org/docs/modules/5.6.x/modules/corex.html#corex.evr.network_msg You may be able to write some code that manipulates the message to manually add the Contact header. Maybe even the append_hf function may work here, but it seems unlikely. James On Mon, 8 May 2023 at 12:28, mohsen khashei wrote: > > thanks for the reply I tried it and it didn't work. also I tried onsend_route > with no luck. > > On Sun, May 7, 2023 at 7:00 PM Yuriy G wrote: >> >> Try here >> https://www.kamailio.org/docs/modules/5.6.x/modules/tm.html#tm.e.local-request >> >> However I would doubt first do I do something right by adding contact to ACK >> message wichbasicaly confirmation of the final transaction and contact here >> is meaningless. >> >> On Sun, 7 May 2023, 16:48 mohsen khashei, wrote: >>> >>> Hi I want to know where kamailio sends ack messages to faiurel messages >>> (status >=400) so that I I add Contact header to the ack. >>> I tried WITHINDLG with no luck. >>> thanks >>> __ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply only to >>> the sender! >>> Edit mailing list options or unsubscribe: >> >> __ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the >> sender! >> Edit mailing list options or unsubscribe: > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio - asterisk - ACK
Thanks for the feedback.
It's tricky, alright, making all of these things work together.
Asterisk should not be re-writing the RR header fields, alright. At
least you found a solution. I can't think of anything better than
that, if it works for you.
James
On Wed, 3 May 2023 at 17:07, Dr. Barabás Péter
wrote:
>
> Hi James,
>
>
>
> thanks for the reply. Yes, record_route() is used in INVITE request.
>
> Meanwhile I found the cause I think here:
>
> https://community.asterisk.org/t/asterisk-rewrites-record-route-header-with-incorrect-tcp-port/91202
>
>
>
> So the Record-Route header contains kamailio’s IP and listening TLS port 443
> until asterisk. When asterisk sends back 200/OK, it rewrites the port and
> client wants to send ACK to this port which is not a listening port of
> kamailio.
>
> My quick (but don’t know if proper) solution is that in reply route of INVITE
> I check that If replay comes from asterisk, I add the following:
>
>
>
> if (route(FROMASTERISK)) {
>
> remove_hf("Record-Route");
>
> append_hf("Record-Route: sips:KAMAILIO_IP:443;transport=TLS\r\n");
>
> }
>
>
>
> Now the ACK can go back to kamailio which forward it to asterisk.
>
> There was another problem with ACK when it contains private IP, the
> fix_nated_contact() in on_reply route solved this.
>
>
>
> Peter
>
>
>
>
>
> From: James Browne
> Date: Wednesday, 2023. May 3. 17:17
> To: Kamailio (SER) - Users Mailing List
> Subject: [SR-Users] Re: Kamailio - asterisk - ACK
>
> If the 200-OK to client A also contains Record-Route header fields,
> then the routing of the ACK from client A should be done using that
> route, not using the internal IP address of asterisk.
> Are you using record_route() function from the rr module?
>
> James
>
> On Wed, 26 Apr 2023 at 09:20, Péter Dr. Barabás
> wrote:
> >
> > Hi all,
> >
> >
> >
> > we are developing a softphone mobile application which registers to
> > asterisk through kamailio. Kamailo proxies the request to asterisk and
> > replies from asterisk to the clients.
> >
> > Registration works fine with asterisk authentication. The problem appears
> > in the following flow:
> >
> > Mobile client A calls client B.
> > Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with
> > credentials.
> > Asterisk sends invite to client B towards kamailio.
> > Kamailio forwards INVITE if client is registered or sends a push
> > notification to client B. When client B registers, kamailio continue the
> > suspended transaction and forwards INVITE.
> > Client B gets INVITE, sends a SIP OK.
> > Asterisk gets SIP OK through kamailio and sends an ACK to client B, which
> > is OK.
> > Asterisk sends the SIP OK to client A through kamailio.
> > Kamailio forwards SIP OK to client A but the contact address contains the
> > asterisk IP instead kamailio.
> > Clilent A try to send ACK but it does not arrive to asterisk, and the call
> > will be hungup after 30 secs.
> >
> >
> >
> > So the question is what is missing, what is the correct solution? I try to
> > use the provided configuration given in following link:
> >
> > https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
> >
> >
> >
> > The difference is that kamailio has no access to asterisk database.
> >
> >
> >
> > Thanks for your help.
> >
> >
> >
> > With kind regards,
> >
> > Peter
> >
> >
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
> > Edit mailing list options or unsubscribe:
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio - asterisk - ACK
If the 200-OK to client A also contains Record-Route header fields, then the routing of the ACK from client A should be done using that route, not using the internal IP address of asterisk. Are you using record_route() function from the rr module? James On Wed, 26 Apr 2023 at 09:20, Péter Dr. Barabás wrote: > > Hi all, > > > > we are developing a softphone mobile application which registers to asterisk > through kamailio. Kamailo proxies the request to asterisk and replies from > asterisk to the clients. > > Registration works fine with asterisk authentication. The problem appears in > the following flow: > > Mobile client A calls client B. > Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with > credentials. > Asterisk sends invite to client B towards kamailio. > Kamailio forwards INVITE if client is registered or sends a push notification > to client B. When client B registers, kamailio continue the suspended > transaction and forwards INVITE. > Client B gets INVITE, sends a SIP OK. > Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is > OK. > Asterisk sends the SIP OK to client A through kamailio. > Kamailio forwards SIP OK to client A but the contact address contains the > asterisk IP instead kamailio. > Clilent A try to send ACK but it does not arrive to asterisk, and the call > will be hungup after 30 secs. > > > > So the question is what is missing, what is the correct solution? I try to > use the provided configuration given in following link: > > https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb > > > > The difference is that kamailio has no access to asterisk database. > > > > Thanks for your help. > > > > With kind regards, > > Peter > > > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Location / Registrar, TCP: Use existing TCP connection
It should automatically re-use an existing TCP connection. Can you give an example? What I usually see is that the CPE has REGISTERed over TCP from an ephemeral TCP port, has given a Contact with a public port (5060, usually), and that the INVITE has a RURI with (implicit or explicit) port 5060 in it, which means that kamailio must attempt a new connection (because it doesn't have an existing TCP connection to the customer-side port 5060). Is this what's happening for you? Perhaps you can look at the nathelper module for use of the add_contact_alias() function. Even if this is not related to REGISTER requests, it still might work for you. James On Mon, 6 Mar 2023 at 09:55, Benoit Panizzon wrote: > > Hi List > > CPE behind Firewall, registering to Kamailio via TCP (or TLS). > > When a call is sent to the CPE, kamailio attemts to open a new TCP > connection and is blocked by Firewall. > > Is there an option to tell kamailio to use the existing registered TCP > connection? > > Mit freundlichen Grüssen > > -Benoît Panizzon- > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Call drops after 1 minute
Hi Christian I read your trace. There's no ACK after the SIP-200 response. It's cumbersome to read the trace because the client and server are at the same IP address, but I did it anyway. There's no ACK after the SIP-200 response, so it looks like the client (213.52.37.107) either doesn't sent it, or sends it directly to the server (213.52.37.107, the same IP address) without properly using the RR header field in the SIP-200 response. If you can set up a similar test and have a different host set up for the client and server (instead of 213.52.37.107 for both), and if you then trace the traffic again at all hosts, then you may find the rogue ACK request or be able to prove that the client never sent it (which might prove a broken client). When you use the client and server at the same IP address, it's not always straightforward to trace any traffic that might go directly from client to server, because it won't leave any network interface. Also I find strange that your call ends after "about a minute or so". I expect that they should end after about 31.5 seconds. It's almost certainly a SIP problem, and not any RTP/rtpproxy problem, so I recommend that you focus on the SIP. (I wrote this message before noticing that the thread is two weeks old.) James On Wed, 7 Dec 2022 at 08:41, Henning Westerholt wrote: > > Hello, > > > > it looks that the 200 OK is not properly transmitted, as they seem to be > retransmits. > > Maybe you should read a bit about SIP if you have not done it yet. It will > help you debugging this problem (and probably others in the future). 😉 > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > From: Christian B Wiik > Sent: Wednesday, December 7, 2022 9:13 AM > To: Henning Westerholt > Cc: Kamailio (SER) - Users Mailing List > Subject: Re: [SR-Users] Call drops after 1 minute > > > > Link to entire trace: > > > > https://docs.google.com/document/d/1yWFJ_Cv13p5cYk-d8m5HMBSeLalkutV0cKZHjHf1QHk/edit?usp=sharing > > > > -- > > Regards > > Christian > > > > > > ons. 7. des. 2022 kl. 08:57 skrev Henning Westerholt : > > Hi Christian, > > > > this ACK is the reply to the 407 and not the relevant one for the dialog. > > > > Please have a look to the full SIP dialog. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > From: Christian B Wiik > Sent: Wednesday, December 7, 2022 8:14 AM > To: Henning Westerholt > Cc: Kamailio (SER) - Users Mailing List > Subject: Re: [SR-Users] Call drops after 1 minute > > > > Thanks Henning. > > > > These are the first 3 packets filtering on my user. I see the ACK but I'm not > able to spot the error. > > > > U 213.52.37.107:50336 -> 10.1.2.10:5060 #1 > INVITE sip:k...@sip2.itf-as.com SIP/2.0..Via: SIP/2.0/UDP > 213.52.37.107:35270;rport;branch=z9hG4bKPj398365dc9 > 706413f868bdd222cadbed8..Max-Forwards: 70..From: > ;tag=4183d760c26e4531a7a39f45d1 > 4fb4c6..To: ..Contact: > ..Call-ID: b3dd380f0c1d4e > 0ebdd7fc223710d938..CSeq: 23860 INVITE..Route: > ..Allow: PRACK, INVITE, ACK, BYE, CAN > CEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS..Supported: > replaces, 100rel, timer, norefersu > b..Session-Expires: 1800..Min-SE: 90..User-Agent: > MicroSIP/3.21.3..Content-Type: application/sdp..Content-Le > ngth: 345v=0..o=- 3879388988 3879388988 IN IP4 > 213.52.37.107..s=pjmedia..b=AS:84..t=0 0..a=X-nat:0..m= > audio 35276 RTP/AVP 8 0 101..c=IN IP4 > 213.52.37.107..b=TIAS:64000..a=rtcp:35277 IN IP4 213.52.37.107..a=send > recv..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 > telephone-event/8000..a=fmtp:101 0-16..a=ssrc > :1053777612 cname:28d400de4b7d5918.. > # > U 10.1.2.10:5060 -> 213.52.37.107:50336 #2 > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > 213.52.37.107:35270;rport=50336;branch=z9hG4bKPj > 398365dc9706413f868bdd222cadbed8;received=213.52.37.107..From: > ;tag=4183d760c26e > 4531a7a39f45d14fb4c6..To: > ;tag=9dd61ff61e802d8e2bef5f14621ef3c2.f003010a..Call-ID: > b3dd380f0c1d4e0ebdd7fc223710d938..CSeq: 23860 INVITE..Proxy-Authenticate: > Digest realm="sip2.itf-as.com", no > nce="Y5A72WOQOq3afsXxs6AD2ihlmLAlgNOe"..Server: kamailio (5.6.2 > (x86_64/linux))..Content-Length: 0 > # > U 213.52.37.107:50336 -> 10.1.2.10:5060 #3 > ACK sip:k...@sip2.itf-as.com SIP/2.0..Via: SIP/2.0/UDP > 213.52.37.107:35270;rport;branch=z9hG4bKPj398365dc9706 > 413f868bdd222cadbed8..Max-Forwards: 70..From: > ;tag=4183d760c26e4531a7a39f45d14fb > 4c6..To: > ;tag=9dd61ff61e802d8e2bef5f14621ef3c2.f003010a..Call-ID: > b3dd380f0c1d4e0eb > dd7fc223710d938..CSeq: 23860 ACK..Route: > ..Content-Length: 0 > > > > -- > > Regards > > Christian > > > > > > ons. 7. des. 2022 kl. 07:51 skrev Henning Westerholt : > > Hello, > > > > as you’ve guessed, this can be a common problem related to the routing of
Re: [SR-Users] SIP routing per MSISDN
Anthony My understanding of hashing is that it provides pseudo-random load-balancing. It's also possibly to do random load-balancing (using rand()), but the benefit of using a hash is that the same input (RURI user, Call-ID, From URI, etc) has predictable and repeatable results. This, I imagine, would be useful in a non-transaction-stateful setup, so that re-transmissions would necessarily be routed to the same gateway to which the first request was routed. Suppose you have two RURI users - Alice and Bob - and you have two destinations. Suppose that md5 hashing is used (I don't know what's actually used in kamailio, though). Then the hash of "Alice" is an even number and the hash of "Bob" is an odd number. Suppose that the algorithm for hashing is a simple modulo-two arithmetic (because there are two destinations in the set). Then always calls to Alice will use one destination and always calls to Bob will use the other. This can be useful in some setups. I suppose that if you want to route based on another parameter of the RURI, then you might want multiple destination sets, and then you might set up your own algorithm for choosing the destination set and gateway for each request. Does this make sense? James On Mon, 24 Oct 2022 at 15:23, Anthony Blandin wrote: > > Hello, > > > > I need to route SIP INVITE towards a specific node based on the MSISDN of the > Request URI. > > I saw that the dispatcher module should be able to make this with the > function ds_select_dst and the algorithm “hash over request-URI user” but I > don’t understand how the routing is done if we can’t associate the > request-URI user with the destination address in the dispatcher DB. > > Maybe my understanding of this module is wrong. Could you help me to achieve > this? > > Thanks > > > > Anthony > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Parallel forking call drop scenario
The scenario, as I see it, is that - the call is parallel-forked from kamailio to B1 and B2 - B1 answers the call and this works fine - Kamailio sends a CANCEL to B2, but this CANCEL gets lost - B2 answers the call - B2 sends a BYE and kills the call The user A should be responsible for handling this situation (it should BYE the call to B2 when it gets the 200-OK). Miconda answered this a few years ago here. https://github.com/kamailio/kamailio/issues/570 James On Wed, 30 Mar 2022 at 05:36, Koray Vatansever wrote: > > Hi, > > I would appreciate if anyone has any suggestions regarding the following? > > > On Thu, Mar 24, 2022 at 3:38 PM Koray Vatansever > wrote: >> >> Hi everyone, >> >> I'm facing the following situation. >> >> Clients are connected over TLS. Therefore there is no retransmission in >> Kamailio. >> >> How can I prevent this call drop? >> >> >> >> +---+ +---+ +-+ >> +-+ >> | A | | Kamailio | | B1 | >> | B2 | >> +---+ +---+ +-+ >> +-+ >> | | | >> | >> | INVITE | | >> | >> |>| | >> | >> | | ---\ | >> | >> | |-| Parallel forking | | >> | >> | | |--| | >> | >> | | | >> | >> | | INVITE| >> | >> | |-->| >> | >> | | | >> | >> | | INVITE| >> | >> | >> |--->| >> | | | >> | >> | | 180 Ringing | >> | >> | |<--| >> | >> | | | >> | >> | | | >> 180 Ringing | >> | >> |<---| >> | | | >> \ | >> | | |-| User >> answers the call | | >> | | | >> |---| | >> | | | >> | >> | |200 OK | >> | >> | |<--| >> | >> | | | >> | >> | 200 OK | | >> | >> |<| | >> | >> | | | >> | >> | ACK | | >> | >> |>| | >> | >> | | | >> | >> | | ACK | >> | >> | |-->| >> | >> | --\ | | >> | >> |-| Session established with B1 | | | >> | >> | |-| | | >> | >> | | | >> | \ >
Re: [SR-Users] properly removing First Via header received
I don't know about the lump, but maybe try remove_hf_value instead.
This should also work if/when multiple Via values are comma-separated
in a single header field.
https://www.kamailio.org/docs/modules/devel/modules/textopsx.html#textopsx.f.remove_hf_value
James
On Wed, 16 Mar 2022 at 08:19, Patrick Karton wrote:
>
> i want to remove the First Via Header received from uac to kamailio.
>
> so in my script i use remove_hf("Via") but in the relayed request i see that
> ";received=x.x.x.x;rport=" is left without any header before it.
>
> i think internally kamailio adds a lump before i call the remove_hf function.
>
> how to do it properly ?
>
> Thanks
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Diversion Header & Header management - $hdrc
What you're looking for is to manage the header field _values_ (as
you mention), not the header _fields_.
Maybe try the "@hf_value" Select from the textopsx module.
https://www.kamailio.org/docs/modules/5.5.x/modules/textopsx.html#textopsx.sel.hf_value
You might try code something like this pseudocode.
while ( ! @hf_value.diversion[$var(i)] == "" ) { ...
James
On Mon, 7 Mar 2022 at 23:42, Brandon Armstead wrote:
>
> Thanks for your time in advance!
>
> When dealing with multiple headers in different formats, i.e.
>
> Diversion: ,
>
> $hdrc(Diversion) returns 1 header instead of 2. Is this expected behavior?
> What is the best way to manage all scenarios of possible multiple header
> values? It seems currently there is no easy way to iterate over ALL
> diversion headers, including scenarios like the following below:
>
> Diversion:
>
> or
>
> Diversion: ,
>
> or
>
> Diversion:
> Diversion: ,
>
> etc.
>
> - Brandon
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] get kamailio sip processes id
Maybe you can try the `kamcmd ps` command. Something like this may work for you.
top -c -p $(kamcmd ps | grep receiver | awk '{ print $1 }' | xargs | tr ' ' ,)
James
On Tue, 8 Feb 2022 at 11:26, Patrick Karton wrote:
>
> hello,
> as we are all aware kamailio create a lot of processes for many tasks.
>
> im using kamailio in kubernetes and i would like to monitor only sip
> processes with top command.
>
> i only need a way to get only kamailio sip processes id (udp receiver that
> handle sip request) .
>
> but i dont knwo how to get it.
>
> top -c -p id1,id2,id3,id4
>
>
> Thanks
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Homer7 and Kamailio 5.3
I've encountered a very similar problem in the past.The siptrace module
uses UDP and does not expect a response, so it can be confusing that
kamailio's behavior changes depending on whether the homer server is online.
The problem I've seen in the past is that when kamailio and a statsd server
are in the same IP subnet, and the statds server goes offline, an ARP
request is made whenever traffic is to be sent, and this ARP request is
blocking until it times out (a few seconds). It blocks all workers because
they all want to send a UDP packet and all have to wait.
If this is what's going on, then moving the siptrace server to a different
subnet should resolve the problem.
James
On Wed, 2 Feb 2022 at 21:43, Angelo Sipper wrote:
> Hi,
>
> I have the exact same configuration with two workers and same syntax.
> It works fine until I shut down homer. After that Kamailio stop precessing
> any traffic and all clients try to register as they are disconnected.
>
> Kind Regards,
> Angelo
>
> On Wed, Feb 2, 2022, 8:45 PM Karsten Horsmann wrote:
>
>> Hi,
>>
>> try to define an extra sendsocket.
>>
>> And add an listen directive for that sendsocket. Sorry for the formating
>> wrote this on my smartphone.
>>
>> Works for me with an similar setup and 5.3
>>
>> # capture node or webhomer target
>> #!ifdef WITH_HOMER
>> #!substdef "!MY_HOMER_CAPTURE!sip:MY_HOMER_IP_ADDR:MY_HOMER_PORT!g"
>> #!substdef "!MY_LOCAL_SENDSOCK!sip:MY_PRV_IP:MY_LOCAL_SEND_PORT!g"
>> #!substdef "!MY_LOCAL_SENDLISTEN!udp:MY_PRV_IP:MY_LOCAL_SEND_PORT!g"
>> #!endif
>>
>>
>> #!ifdef WITH_HOMER
>> #Siptrace
>> modparam("siptrace", "force_send_sock", "MY_LOCAL_SENDSOCK")
>> # local interface from where to send the duplicated traffic
>> modparam("siptrace", "duplicate_uri", "MY_HOMER_CAPTURE")
>> modparam("siptrace", "hep_mode_on", 1) # enable/disable Homer encapsulate
>> mode
>> modparam("siptrace", "hep_version", 3) # HEPv3 the timestamp and capture
>> agent ID will be included in the HEP header
>> modparam("siptrace", "hep_capture_id", MY_HOMER_CAPTURE_ID) # capture
>> agent id Limitation: 32-bit for HEPv3.
>> modparam("siptrace", "trace_to_database", 0) # trace to database
>> modparam("siptrace", "trace_on", 1) # enable/disable trace
>> modparam("siptrace", "trace_mode", 1) # default 0, if 1 then you dont
>> need call siptrace flag or sip_trace()
>> #!endif
>>
>> # sendsocket for homer
>> #!ifdef WITH_HOMER
>> socket_workers=2
>> listen=MY_LOCAL_SENDLISTEN
>> #!endif
>>
>> Henning Westerholt schrieb am Mi., 2. Feb. 2022, 18:44:
>>
>>> Hello,
>>>
>>>
>>>
>>> any feedback regarding my previous question about log files, errors?
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Henning
>>>
>>>
>>>
>>> --
>>>
>>> Henning Westerholt – https://skalatan.de/blog/
>>>
>>> Kamailio services – https://gilawa.com
>>>
>>>
>>>
>>> *From:* sr-users *On Behalf Of *Angelo
>>> Sipper
>>> *Sent:* Wednesday, February 2, 2022 5:45 PM
>>> *To:* Kamailio (SER) - Users Mailing List
>>> *Subject:* Re: [SR-Users] Homer7 and Kamailio 5.3
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> Memory on the system is 8GB and on Kamailio we have SHM 4096 and PKG 32.
>>> Each of these VM handles only a few hundred of concurrent calls and each VM
>>> has a few hundred of TLS user registrations.
>>>
>>> Kamailio uses IP to send the traffic to Homer and not domain name.
>>>
>>>
>>>
>>> Any ideas how to solve this issue?
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Angelo
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Feb 1, 2022, 8:43 PM Nick F wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> Do use domain name as destination for homer?
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Jan 31, 2022, 23:12 Henning Westerholt wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> Interesting observation. Do you see anything related to this error
>>> period in the log files? Maybe out of memory errors etc..?
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Henning
>>>
>>>
>>>
>>> --
>>>
>>> Henning Westerholt – https://skalatan.de/blog/
>>>
>>> Kamailio services – https://gilawa.com
>>>
>>>
>>>
>>> *From:* sr-users *On Behalf Of *Angelo
>>> Sipper
>>> *Sent:* Monday, January 31, 2022 12:32 PM
>>> *To:* Kamailio (SER) - Users Mailing List
>>> *Subject:* Re: [SR-Users] Homer7 and Kamailio 5.3
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> Any ideas on this topic?
>>>
>>> Anyone with same behavior?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Angelo
>>>
>>>
>>>
>>> On Thu, Jan 27, 2022, 9:18 PM Angelo Sipper wrote:
>>>
>>> Hi to all,
>>>
>>>
>>>
>>> We have a Kamailio 5.3 that sends all traffic to a homer7 using siptrace
>>> module with parameters force_send_sock and hep_mode_on,1 and hep_version,3
>>> and trace_mode,1. Everything works fine getting all traffic to Homer7 but,
>>> in case Homer7 is not reachable, Kamailio then no longer accepts traffic or
>>> registrations and it is like it crashes. When we revive Homer7 and is it
>>> again reachable accepting traffic, Kamailio then works again fine without
>>> any restart or actions.
>>>
>>> Any ideas why this may be happening? Is there anything
Re: [SR-Users] TOPOS replication with KDMQ
Thanks, Daniel That explains it perfectly. I was thinking that this would be a huge undertaking to implement it in DMQ, anyway, and now I know that this would be the wrong way to approach it. As it happens, TOPOH (with no storage needed) was unsuitable due to a UA requirement to avoid using routesets. Thanks, Henning That makes sense, but that's probably beyond my skill level for now. I was hoping to find out either that it's never been done or that someone would just hand me the solution, so I'm satisfied with the answers. Thanks for the quick responses, James On Fri, 4 Dec 2020 at 07:57, Daniel-Constantin Mierla wrote: > > Hello, > > topos was designed with a backend, being it db/sql-like using the db > connectors (e.g., mysql, postgres, ...) or with topos_redis, tailored > for it to use a redis (or variants) backend. > > From this perspective, there is nothing at this moment that dmq could > replicate. It would require to make first an in-memory storage, then > look at adding dmq layer. > > However, the idea of using from beginning a backend like redis, mysql, > ... was to leverage the replication mechanism offered by the backend. > > Unlike topoh, note that persistence is needed for topos, otherwise > traffic for active dialogs cannot be routed anymore. > > Cheers, > Daniel > > On 03.12.20 20:59, Henning Westerholt wrote: > > Hi James, > > > > I am not aware of a public DMQ extension or module for topos. You coult > > create an enhancement request for this on our tracker for this. If you want > > to start to work on this by yourself, sending an e-mail to sr-dev list > > would be also good to discuss the implementation approach. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt - https://skalatan.de/blog/ > > Kamailio services - https://gilawa.com > > > > -Original Message- > > From: sr-users On Behalf Of James > > Browne > > Sent: Thursday, December 3, 2020 3:07 PM > > To: sr-users@lists.kamailio.org > > Subject: [SR-Users] TOPOS replication with KDMQ > > > > Has anyone ever implemented DMQ replication of TOPOS data between kamailio > > servers? > > > > I'm trying to find the easiest (to maintain) way to implement this > > replication, possibly without using an external database. > > > > James > > > > ___ > > Kamailio (SER) - Users Mailing List > > sr-users@lists.kamailio.org > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > ___ > > Kamailio (SER) - Users Mailing List > > sr-users@lists.kamailio.org > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Funding: https://www.paypal.me/dcmierla > > > ___ > Kamailio (SER) - Users Mailing List > sr-users@lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] TOPOS replication with KDMQ
Has anyone ever implemented DMQ replication of TOPOS data between kamailio servers? I'm trying to find the easiest (to maintain) way to implement this replication, possibly without using an external database. James ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
