Hello guys,
I have public and private IPs, and i need to force the sending socket
replying to internal out externals endpoint, so i'm using this:
function to check the destination (i tried using $sndto(ip) but it always
returns NULL):
route[CHECK_DEST_NET] {
if ( $du=~"sip:172\..*" ) {
setflag(FLAG_TO_PRIVATE);
xlog("L_ERR", "[CHECK_SOURCE] Packet going to PRIVATE -> [$du]\n" );
} else {
setflag(FLAG_TO_PUBLIC);
xlog("L_ERR", "[CHECK_SOURCE] Packet going to PUBLIC -> [$du]\n" );
}
return;
}
on my relay:
route(CHECK_DEST_NET);
if (isflagset(FLAG_TO_PRIVATE)) {
xlog("L_ERR", "[RELAY] forcing socket to PRIVATE NET\n" );
force_send_socket(LISTEN_INSIDE_IF:LISTEN_INSIDE_PORT);
} else {
xlog("L_ERR", "[RELAY] forcing socket to PUBLIC NET\n" );
force_send_socket(LISTEN_OUTSIDE_IF:LISTEN_OUTSIDE_PORT);
}
This works nicely, except for ACKs and potentially other packets sent
statelessly?
Anyone knows how to fix this?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
Hi all,
I’m still building with app_ruby and loving it - for the most part!
I’m having an issue with one of my providers responding with a 482 on auth invite. Researching, it appears that my CSeq isn’t incrementing and this is the reason for the issue.
I already have the relevant flag set in my kamailio.cfg however:
modparam("dialog", "track_cseq_updates", 1)
During my uac_auth, I’ve tried manually setting the diff, as well as running msg_iflag_reset (as suggested by Daniel - https://github.com/kamailio/kamailio/issues/1359 <https://github.com/kamailio/kamailio/issues/1359> - unfortunately the function isn’t exported in KEMI):
if KSR::UAC.uac_auth() then
KSR.info("UAC authed, relaying")
#KSR::COREX.msg_iflag_reset("UAC_AUTH")
KSR::PV.sets("$dlg_var(cseq_diff)", "1")
KSR.info("CSeq diff: #{KSR::PV.gete("$dlg_var(cseq_diff)")}")
KSR::TM.t_relay()
Unfortunately in both cases the actual CSeq doesn’t increment in the second INVITE:
INVITE 1 (unauthenticated):
> CSeq: 102 INVITE
INVITE 2 (with Authorization header):
> CSeq: 102 INVITE
I’m unsure if I’ve missed something silly around the track_cseq_updates flag, or if app_ruby somehow isn’t interacting with the dialog module when running uac_auth to trigger the increment?
Thanks!
Kind regards,
Andrew
My K host is behind a mobile WiFi hotspot and I tried to make K listen at
the IPv6 address fe80::6e29:95ff:fe7d:37e6/64 that the host has received
from the hotspot.
Using that address on listen line gives error:
Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR: <core> [core/udp_server.c:395]: udp_init(): bind(8, 0x7ff97dfb3fe4, 28) on FE80:0:0:0:6E29:95FF:FE7D:37E6: Invalid argument
Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR: <core> [core/udp_server.c:401]: udp_init(): might be caused by using a link local address, try site local or global
I can ping that address like this:
$ ping6 fe80::6e29:95ff:fe7d:37e6%wlp1s0
PING fe80::6e29:95ff:fe7d:37e6%wlp1s0(fe80::6e29:95ff:fe7d:37e6%wlp1s0) 56 data bytes
64 bytes from fe80::6e29:95ff:fe7d:37e6%wlp1s0: icmp_seq=1 ttl=64 time=0.030 ms
I then tried to add %wlp1s0 suffix to the listen address, but got error:
Apr 21 09:10:35 salmon sip-proxy[7896]: 0(7948) CRITICAL: <core> [core/cfg.y:3510]: yyerror_at(): parse error in config file /etc/sip-proxy/sip-proxy.cfg, line 408, column 34: ip address, interface name or hostname expected
Did I do something wrong? If not, why is it that K cannot listen at a
link local address? It is something that Linux networking stack does
not support?
-- Juha
Hello,
What is your recommendation on using clean_unused with db defined pipes?
>>pl_check("systemwide");
If I leave the system idle, they are eventually "cleaned" as expected. In
our use case, that means failed calls unfortunately.
I am trying to see if I can mix both db/static pipes with dynamic/run-time
pipes.
Thanks
Cindy
I am fairly sure it’s been asked a number of times, but is there a way to know the destination, and more especially the transport, of the next hop of a reply message, viewable from onreply_route?
For requests, we have $nh and many other PVs which in some way evidence where it’s going.
And yes, I’m aware that this can be previewed from the onsend_routes*, but I need to amalgamate that knowledge with some transaction-specific data.
Thanks!
—
Sent from mobile, with due apologies for brevity and errors.
Hi all,
i use kamailio 5.0.7 in production and i noticed that i cant listen the
dialogs after a few days of traffic on this server.
Then i got "kamcmd dlg.list_ctx " - "ERROR: reply too big".
So now my question - i want to debug my "sleeping dialogs" with dlg.list -
how big should it change the values of without knowing the size of the
current filled up binrpc stuff?
Or is there a better option to debug dialog-module?
modparam("ctl", "binrpc_max_body_size", ??)
modparam("ctl", "binrpc_struct_max_body_size", ?)
--
Cheers and see you in Berlin
*Karsten Horsmann*
Hi Daniel,
Thank you very much for clarifying!
Cheers,
Yufei
On 30 Apr 2019 at 08:10, <Daniel-Constantin Mierla <miconda(a)gmail.com>>
wrote:
Hello,
there is an errata for that RFC, but it refers only to the BYE, where it
adds back the transport=tcp, but the ACK R-URI should follow the same
rules, see:
* https://www.rfc-editor.org/errata/eid5294
Cheers,
Daniel
On 28.04.19 22:54, Yufei Tao wrote:
Hi,
I have a question regarding basic SIP flow for establishing a call session,
and wonder if anyone can help me clarify.
For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s
R-URI should be a copy of the Contact header of the OK message.
However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed
the parameters from the Contact header of the OK, e.g.
In OK the Contact header is:
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
<sip:bob@client.biloxi.example.com;transport=tcp>
And ACK the R-URI is:
ACK sip:bob@client.biloxi.example.com SIP/2.0
Which has got the parameter ‘transport=tcp’ removed – why is this?
In this case if the proxy connected to Bob handles ACK in the usual way as
it would for all in-dialog requests, i.e. based on routing headers only and
not extra processing, it’ll try to relay the ACK message to Bob using the
default transport UDP which is not expected and will fail.
Can anyone help explain why the parameters are removed in RFC3665 examples
please? Have I missed anything? Thank you very much!
Yufei
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Hi,
I have a question regarding basic SIP flow for establishing a call session, and wonder if anyone can help me clarify.
For normal call set up, INVITE-OK-ACK, from RFC3261, I believe the ACK’s R-URI should be a copy of the Contact header of the OK message.
However in RFC3665 sections 3.1 and 3.2 for example, the ACK’s R-URI missed the parameters from the Contact header of the OK, e.g.
In OK the Contact header is:
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
And ACK the R-URI is:
ACK sip:bob@client.biloxi.example.com SIP/2.0
Which has got the parameter ‘transport=tcp’ removed – why is this?
In this case if the proxy connected to Bob handles ACK in the usual way as it would for all in-dialog requests, i.e. based on routing headers only and not extra processing, it’ll try to relay the ACK message to Bob using the default transport UDP which is not expected and will fail.
Can anyone help explain why the parameters are removed in RFC3665 examples please? Have I missed anything? Thank you very much!
Yufei
Hi ppl,
After a branch route fails, I need to re-evaluate the next destination and
adjust RR parameters, if need be, like for example adjust the nat=yes|priv.
failure_route[MANAGE_PSTN_FAILURE] {
...
remove_record_route();
record_route();
route(NATMANAGE);
...
route(RELAY);
}
The result is that the new branch is stripped of "Record-Route:
<sip:MYIP>", but the params remained. Moreover, record_route hasn't been
re-added as instructed in the failure route.
Request headers of the initial branch that will eventually timeout and fail:
2019/04/27 18:29:18.034992 10.22.0.1:5060 -> 10.22.0.100:5060
INVITE sip:1514XXXXXXX@10.22.0.100 SIP/2.0
Record-Route: <sip:10.22.0.1;r2=on;lr=on;did=9e2.3dd2;nat=priv>
Record-Route: <sip:65.XX.XX.1;r2=on;lr=on;did=9e2.3dd2;nat=priv>
New request branch after failure:
2019/04/27 18:29:19.538292 65.XX.XXX.1:5060 -> 65.XX.XX.2:5060
INVITE sip:1514XXXXXXX@65.XX.XX.2 SIP/2.0
;lr=on;did=9e2.3dd2;nat=priv>
kamailio -v
version: kamailio 5.1.6 (x86_64/linux) 7d1964
Much obliged.
--Sergiu
