Hi,
I am using *Kamailio 4.4* as the proxy with my *Asteri**sk *server. I am
trying to develop a scenario where an extension gets registered on asterisk
via *Kamailio *when it receives a push notification. This push notification
is sent to the sip extension when a call towards this extension reaches to
the *Kamailio*.
For example, suppose there is two SIP extension(* extension 1 and extension
2*) registered on *Asterisk *via Kamailio. When a call from *extension 1*
reaches the asterisk, it forwards the *INVITE *request towards *extension 2*
via Kamailio.Kamailio will try to forward it to extension 2. suppose
the *extension
2* is not able to receive the *INVITE *request from *Kamailio*. When
extension two receive a push notification, it will register on asterisk.
So I need to get the call on *extension 2 *through the new registration.
We are trying to simulate registration of extension to the asterisk when
receiving the push notification.
First, we registered *extension 2 *and disconnected the network. Then we
tried to register the same extension when a call from *extension 1 *reaches
to Kamailio. This is a simulation of push-based registration since an
extension that receives the push will attempt to register when an incoming
call is received.
When asterisk sends *INVITE *request to Kamailio, it immediately responded
with *100 trying* provisional response. This *100* response by Kamailio
towards asterisk prevents asterisk from re-transmitting the INVITE.
Then Kamailio tried to send and retransmit the packet to *extension 2*,
which does not have network access. This* extension 2 *was on port number
*24071*. Even after successful registration(in port *59995*) of the *extension
2*, Kamailio continued to transmit the packets to the old port.
After that, we have configured Kamailio in a way that it won't send an
immeadeate provisional reply(*100 trying* ) for *INVITE *request.
Here Kamailio is not immediately sending *100 trying* message to *Asterisk*.
This forces Asterisk to re-transmit. Asterisk was found to retransmit the
same packets. However, even after the successful registration of* extension
2*, asterisk continued to send the old invite to Kamailio not the new one
to the latest port.
This is the problem for me since push relies on the *INVITE *reaching the
phone at the correct port number.
So, is there other good approaches to solve this issue?
One thing I would like to try is modifying the pending *INVITE *request
towards old registered port with the new port details when new registration
reaches to Kamailio. Can I get the ongoing requests from Kamailio?
Please suggest a viable solution.
Thank you,
Arunbalan
Hi. i would like to ask if someone has found any bash script that could
install all at once for Kamailio and Siremis in ubuntu/debian or even in
centos.
Hello again,
I am not a SIP expert, and I’m new to Kamailio, really enjoying learning it, but I’ve hit a blocker and I’m pretty sure I’ve missed something really simple.
I’m looking to implement the Redirect Server from here: https://tools.ietf.org/html/rfc3665#section-3.6 <https://tools.ietf.org/html/rfc3665#section-3.6> (the Avaya Session Manager being Alice), Kamailio as the Redirect Server. My configuration is working fine, and I can see the 302 going back (to Avaya SM), I then get the ACK I’m expecting.
The incoming SIP request contains a number of fields, including a Contact header, which I’m told SM needs on the return. But the send_reply() or sl_send_reply() doesn’t return the Contact header, and I am unable to manually set it, or any other header, using any of the append_hf(), append_to_reply() etc. mechanisms. I’m executing a msg_apply_changes() which succeeds, but no Contact header is returned.
I’ve tried an sl_send_reply(“100”, “Trying”) before any other processing, and Wireshark confirms that the SIP response is basically identical to the 302 response sent after processing… The goal is to run this stateless, I’m assuming this is possible - it certainly feels like it should be.
I’ve re-read the intros & tutorials, and other reading material such as this http://kamailio.org/docs/ser-getting-started/SER-GettingStarted.pdf <http://kamailio.org/docs/ser-getting-started/SER-GettingStarted.pdf> but, this, even my best Google-fu has left me utterly stumped…
The sl_send_reply documentation https://kamailio.org/docs/modules/5.2.x/modules/sl.html#sl_send_reply <https://kamailio.org/docs/modules/5.2.x/modules/sl.html#sl_send_reply> states “If the code is in the range 300-399 (redirect reply), the current destination set is appended to the reply as Contact headers” but the Contact header is definitely not being set when I use this.
Apologies in advance if eyes are rolling and this is really obvious, or (and?) that my lack of SIP knowledge is shining through - any tips or guidance would be appreciated. I certainly feel overwhelmed by the number of modules and the interplay between them.
If the answers to this, and other things along these lines are contained in the admin book, that’s fab, I’ve just filled the form out :)
Cheers - Robert...
Hello,
I’m working for a UK high street bank and our Kamailio implementation has been challenged because we’ve got database passwords held in clear in the configuration file.
I am unable to find any examples of where this has been worked around, there doesn’t seem to be any module or configuration means of supplying a variable in the modparam() entry that is expanded a startup. The security tutorials only seem to relate to the SIP level of security, not Kamailio as a platform.
My requirement is simple, I need to be able to supply a password via means such as loading a variable from a run-once script at start up, or a module. The ideal would be to be able to read in a Docker secret :)
I am by no means a Kamailio expert, so apologies in advance if this is a mindblowingly basic thing to achieve, but I do feel I’ve exhausted the Kamailio documentation, wiki etc. and all the goodness Google usually has to offer and drawn a blank.
Sincere thanks in advance for any assistance.
Cheers - Robert...
FOSDEM is one of the world's premier meetings of free software developers,
with over five thousand people attending each year. FOSDEM 2018
takes place 3-4 February 2018 in Brussels, Belgium. https://fosdem.org
This email contains information about:
- Real-Time Communications dev-room and lounge,
- speaking opportunities,
- volunteering in the dev-room and lounge,
- related events around FOSDEM, including the XMPP summit,
- social events (the legendary FOSDEM Beer Night and Saturday night dinners
provide endless networking opportunities),
- the Planet aggregation sites for RTC blogs
Call for participation - Real Time Communications (RTC)
=======================================================
The Real-Time dev-room and Real-Time lounge is about all things involving
real-time communication, including: XMPP, SIP, WebRTC, telephony,
mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room
is a successor to the previous XMPP and telephony dev-rooms.
We are looking for speakers for the dev-room and volunteers and
participants for the tables in the Real-Time lounge.
The dev-room is only on Sunday, 4th of February 2018. The lounge will
be present for both days.
To discuss the dev-room and lounge, please join the FSFE-sponsored
Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc
To be kept aware of major developments in Free RTC, without being on the
discussion list, please join the Free-RTC Announce list:
http://lists.freertc.org/mailman/listinfo/announce
Speaking opportunities
----------------------
Note: if you used FOSDEM Pentabarf before, please use the same account/username
Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November.
Please use the Pentabarf system to submit a talk proposal for the
dev-room. On the "General" tab, please look for the "Track" option and
choose "Real Time Communications devroom".
https://penta.fosdem.org/submission/FOSDEM18/
Other dev-rooms and lightning talks: some speakers may find their topic is
in the scope of more than one dev-room. It is encouraged to apply to more
than one dev-room and also consider proposing a lightning talk, but please
be kind enough to tell us if you do this by filling out the notes in the form.
You can find the full list of dev-rooms at
https://www.fosdem.org/2018/schedule/tracks/
and apply for a lightning talk at https://fosdem.org/submit
Main track: the deadline for main track presentations is 23:59 UTC
3rd of November. Leading developers in the Real-Time Communications
field are encouraged to consider submitting a presentation to
the main track at https://fosdem.org/submit
First-time speaking?
--------------------
FOSDEM dev-rooms are a welcoming environment for people who have never
given a talk before. Please feel free to contact the dev-room administrators
personally if you would like to ask any questions about it.
Submission guidelines
---------------------
The Pentabarf system will ask for many of the essential details. Please
remember to re-use your account from previous years if you have one.
In the "Submission notes", please tell us about:
- the purpose of your talk
- any other talk applications (dev-rooms, lightning talks, main track)
- availability constraints and special needs
You can use HTML and links in your bio, abstract and description.
If you maintain a blog, please consider providing us with the
URL of a feed with posts tagged for your RTC-related work.
We will be looking for relevance to the conference and dev-room themes,
presentations aimed at developers of free and open source software about
RTC-related topics.
Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
dev-room administrators based on the number of received proposals.
As the two previous dev-rooms have been combined into one, we may decide to
give shorter slots than in previous years so that more speakers can
participate.
Please note FOSDEM aims to record and live-stream all talks.
The CC-BY license is used.
Volunteers needed
=================
To make the dev-room and lounge run successfully, we are looking for
volunteers:
- FOSDEM provides video recording equipment and live streaming,
volunteers are needed to assist in this
- organizing one or more restaurant bookings (dependending upon number of
participants) for the evening of Saturday, 3rd of February
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists
Related events - XMPP and RTC summits
=====================================
The XMPP Standards Foundation (XSF) has traditionally held a summit
in the days before FOSDEM. There is discussion about a similar
summit taking place on the 2nd of February 2018
http://wiki.xmpp.org/web/Summit_22 - please join the mailing
list for details: http://mail.jabber.org/mailman/listinfo/summit
Social events and dinners
=========================
The traditional FOSDEM beer night occurs on Friday, 2nd of February.
On Saturday night, there are usually dinners associated with
each of the dev-rooms. Most restaurants in Brussels are not so
large so these dinners have space constraints and reservations are
essential. Please subscribe to the Free-RTC mailing list for
further details about the Saturday night dinner options and how
you can register for a seat: https://lists.fsfe.org/mailman/listinfo/free-rtc
Spread the word and discuss
===========================
If you know of any mailing lists where this CfP would be relevant, please
forward this email. If this dev-room excites you, please blog or microblog
about it, especially if you are submitting a talk.
If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:
All projects http://planet.freertc.org planet(a)freertc.org
XMPP http://planet.jabber.org ralphm(a)ik.nu
SIP http://planet.sip5060.net planet(a)sip5060.net
(Español) http://planet.sip5060.net/es/ planet(a)sip5060.net
Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.
Contact
=======
For any private queries, contact us directly using the address
fosdem-rtc-admin(a)freertc.org and for any other queries please ask on
the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc
The dev-room administration team:
Saúl Ibarra Corretgé <saghul(a)gmail.com>
Iain R. Learmonth <irl(a)debian.org>
Ralph Meijer <ralphm(a)ik.nu>
Daniel-Constantin Mierla <miconda(a)gmail.com>
Daniel Pocock <daniel(a)pocock.pro>
Hello,
I have two(or more) kamailio servers with dmq module and dmq_usrloc -
sip1.example.com and sip2.example.com
publish and subcribe replication works too.
BLF works fine if clients connected to the same kamailio server, because in
active_watchers table stored with same domain sip1.example.com
But what to do when call going from one server to second? Is there any
configuration to ignore domain in pusblish, subscribe, notify, etc?
--
Aydar A. Kamalov
Hi,
I just installed the head version from git.
version: opensips 2.4.0-dev (x86_64/linux)
flags: STATS: On, SHM_EXTRA_STATS, EXTRA_DEBUG, DISABLE_NAGLE, USE_MCAST,
SHM_MMAP, PKG_MALLOC, QM_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
git revision: d1a4419
main.c compiled on 19:53:20 Nov 28 2017 with gcc 4.8
It was compiled with EXTRA_DEBUG and DBG_TCPCON flags;
While starting opensips with the residential vanilla script it gives
following error:
Nov 28 20:05:52 [30899] ERROR:core:tcp_init: oom con hist
Nov 28 20:05:52 [30899] CRITICAL:core:main: could not initialize tcp
Nov 28 20:05:52 [30899] INFO:core:cleanup: cleanup
Nov 28 20:05:52 [30899] DBG:core:shm_mem_destroy: destroying the shared
memory lock
Nov 28 20:05:52 [30899] NOTICE:core:main: Exiting....
already running
Even if I remove the proto_tcp, and tcp related things this still gives
error and doesn't start.
Kindly help.
Regards,
Sammy
Hi community.
We experience the problem with malformed messages.
First of all, I want to say, that most of time kamailio works well and
nothing happens that can drop sessions.
But from time-to-time something changes (may be in the network) and
kamailio receives requests with malformed headers (To or From hfs).
The schema:
uplinks -> kamailio <-> routing server (asterisk)
Malformed messages were received only from asterisk server.
Sip debug on asterisk showed that messages were transmitted correctly and
headers were nice.
But kamailio obtains changed (broken) packets or perhaps can't read them
properly.
How does it look like:
Nov 10 12:37:06 kamailio-name kamailio[965]: INFO: <script>: Going to
NATMANAGE for BYE from sip:useragent7122@kamailio_address:5068
(IP=wss:client_address:62881) - R=sip:dialed_did_service@asterisk_address:50600
ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600
Nov 10 12:37:06 kamailio-name kamailio[965]: NOTICE: <script>: Relaying
request to <null> - R=sip:dialed_did_service@asterisk_address:50600
ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600
Nov 10 12:37:06 kamailio-name kamailio[965]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[965]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[965]: ERROR: dialog [dlg_cseq.c:89]:
dlg_cseq_prepare_msg(): cannot parse FROM header
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: dialog [dlg_cseq.c:89]:
dlg_cseq_prepare_msg(): cannot parse FROM header
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: uac [replace.c:783]:
restore_uris_reply(): failed to find/parse FROM hdr
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]:
pv_get_from_attr(): cannot parse From header
Nov 10 12:37:06 kamailio-name kamailio[937]: INFO: <script>: Skip manage
DEVICE_STATE for BYE from <null> (IP=udp:asterisk_address:50600) with (200
- OK) - R=<null> ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600
Nov 10 12:37:06 kamailio-name kamailio[937]: INFO: <script>:
------------------------------------MANAGE BYE by DEVICE_STATE_BYE_MANAGE
route - 200 - OK M=BYE IP=udp:asterisk_address:50600
ID=1b0044070de406153bf0e4b84d6bb793@asterisk_address:50600
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]:
pv_get_from_attr(): cannot parse From header
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: rtpengine
[rtpengine_funcs.c:331]: get_from_tag(): failed to parse From header
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: rtpengine
[rtpengine.c:2252]: rtpp_function_call(): can't get From tag
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]:
pv_get_from_attr(): cannot parse From header
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_addr_spec.c:719]: parse_addr_spec(): unexpected char [<] in
status 6: [<sip:useragent6] .
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: <core>
[parser/parse_from.c:75]: parse_from_header(): bad From header
[<sip:useragent6<+.w>;tag=jja7l45gd1]
Nov 10 12:37:06 kamailio-name kamailio[937]: ERROR: pv [pv_core.c:465]:
pv_get_from_attr(): cannot parse From header
How the packet looks like:
ACK sip:tt7etmau@bb0pd5t63b26.invalid;alias=client_address~57573~6;transport=ws
SIP/2.0
Via: SIP/2.0/UDP asterisk_address:50600;branch=z9hG4bK117106ca;rport
Route: <sip:kam2.domain.com:5068
;nat=yes;transport=udp;r2=on;ftag=as06869a5d;lr=on;vsf=AAAAAEZZSVVDVV1VRBlUUkUpFQxdVUZYXiRCHU1RQl1HRVNaXhhAQ3RuLnR3aWxpby5jb20-;vst=AAAAAAAAAAAAAAAAAAAAAAAfBwQRQE8NBR9BChIFAwddCgADFEVDQlYudHdpbGlvLmNvbQ--;did=b0c.7331>,<sip:kam2.callision.com:5068
;nat=yes;transport=ws;r2=on;ftag=as06869a5d;lr=on;vsf=AAAAAEZZSVVDVV1VRBlUUkUpFQxdVUZYXiRCHU1RQl1HRVNaXhhAQ3RuLnR3aWxpby5jb20-;vst=AAAAAAAAAAAAAAAAAAAAAAAfBwQRQE8NBR9BChIFAwddCgADFEVDQlYudHdpbGlvLmNvbQ--;did=b0c.7331>
Max-Forwards: 70
From: "19172423539" <sip:19172423539@asterisk_address:50600>;tag=as06869a5d
To: <sip:useragent7122@10.0.1.18:5068>;tag=nmv7kmpau3
Contact: <sip:19172423539@asterisk_address:50600>
Call-ID: 629d5a132c194c536b5f5c1a2a3c6e32@asterisk_address:50600
CSeq: 102 ACK
User-Agent: asterisk PBX
Content-Length: 0
The transport is used to send messages between asterisk and kamailio is TCP.
TCP configurations:
tcp_connection_lifetime=3604
tcp_accept_no_cl=yes
tcp_connect_timeout=5
tcp_send_timeout=5
tcp_rd_buf_size=16384
tcp_keepalive=yes
tcp_crlf_ping=yes
tcp_keepcnt=3
tcp_keepidle=30
tcp_keepintvl=15
tcp_max_connections=4096
I found the idea, that we need to change following parameters:
modparam("uac","restore_mode","auto")
modparam("uac","restore_dlg",1)
to:
modparam("uac","restore_mode","none")
modparam("uac","restore_dlg",0)
I did that, now it looks like all is fine, but I think it can get back.
Thanks in advance.
--
--
BR, Donat Zenichev
Wnet VoIP team
Tel Ukraine: +380(44) 5-900-800
Tel USA: +164(67) 8-174-17
https://w-net.us/ <http://wnet.ua>
Hi community.
My apologies for so frequent appealing to you.
I'm trying to solve problem with ending of sessions.
The problem consists of no 200 OK coming from uplink on our BYE requests.
Topology.
First leg:
Webrtc client <-wss-> kamailio <-sip tcp-> asterisk routing server
Second leg:
Uplink <-sip tcp-> kamailio <-sip tcp-> asterisk routing server
The problem appears only in case when dialog was ended by webrtc client.
The first leg (dialog) of the call ends nice, without any hints on problem.
But the second leg (with uplink) has problem with no 200 OK (coming from
uplink) on BYE request coming from asterisk.
Handshake between asterisk server and uplink establishes properly.
It looks like:
uplink.domain.com:5060 -> INVITE tcp -> our.kamailio.server:5060 -> INVITE
tcp -> our.asterisk.server:5060
.
uplink.domain.com:5060 <- 100 trying tcp <- our.kamailio.server:5060
.
uplink.domain.com:5060 <- 180 ringing tcp <- our.kamailio.server:5060 <-
180 ringing tcp <- our.asterisk.server:5060
.
uplink.domain.com:5060 <- 200 OK tcp <- our.kamailio.server:5060 <- 200
OK tcp <- our.asterisk.server:5060
.
uplink.domain.com:5060 -> ACK tcp -> our.kamailio.server:5060 -> ACK tcp ->
our.asterisk.server:5060
.
uplink.domain.com <-media stream-> rtpengine <-media stream->
our.asterisk.server
.
Here kamailio starts to use random source port for relaying in-dialog BYE
uplink.domain.com:5060 <- BYE tcp <- our.kamailio.server:45355 <- BYE tcp
<- our.asterisk.server:5060
.
And here the leg with uplink is expected to end with 200 OK (coming from
uplink proxy).
But uplink doesn't answer at all.
We requested a tcpdump from uplink to see how packets are forwared from
their side. And I saw that that 200 OK tries to be sent within first tcp
session - to 5060 port of kamailio server.
But sngrep on our side shows nothing, nothing appears in kamailio log, so
200 OK can't reach the 5060 socket because of some transport problem I
think.
Top via hf of our BYE request, contains kamailio record =
uplink.domain.com:5060
My main thought on this count is to suppress using of random source ports
for in-dialog requests, this behaviour looks irrelevant.
We have turned on mhomed parameter (mhomed=1). And cookbook says:
"Set the server to try to locate outbound interface on multihomed host.
This parameter affects the selection of the outgoing socket for forwarding
requests."
But, there is a big but - we can not turn of this parameter for this
moment, because routing script made with using of this one.
Kamilio works on AWS EC2 platform. It has following IP address schema:
private address atouched to container -> public address assinged to this
private address (so this is standard ip address schema for AWS containers).
For this example private address will be: 10.0.0.1
and public address will be: 100.0.0.1
Configuration - main parameters (all values are changed for an example):
advertised_address=our.kamailio.server
advertised_port=5060
alias=our.kamailio.server
alias=our.kamailio.server:5060
alias=100.0.0.1
alias=100.0.0.1:5060
alias=10.0.0.1
alias=10.0.0.1:5060
auto_aliases=no
port=5060
listen=100.0.0.1
listen=10.0.0.1
listen=tcp:100.0.0.1:5060
listen=tcp:10.0.0.1:5060
mhomed=1
fork=yes
fork_delay=5000
children=6
tcp_connection_lifetime=3604
tcp_accept_no_cl=yes
tcp_connect_timeout=5
tcp_send_timeout=5
tcp_rd_buf_size=16384
tcp_keepalive=yes
tcp_crlf_ping=yes
tcp_keepcnt=3
tcp_keepidle=30
tcp_keepintvl=15
tcp_max_connections=4096
One of the solutions to this problem was to add following inside the
relaying route block:
$fs = "tcp:" + "10.0.0.1" + ":5060";
if (!t_relay()) {
sl_reply_error();
}
But it seems to me it's not a smart solution.
--
--
BR, Donat Zenichev
Wnet VoIP team
Tel Ukraine: +380(44) 5-900-800
Tel USA: +164(67) 8-174-17
https://w-net.us/ <http://wnet.ua>
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>