Hello,
another edition of FOSDEM is approaching, about 2 weeks left:
- https://fosdem.org/2017/
Couple of devs and many Kamailio friends will be around.
Like past year, there is a Realtime Communications devroom, this edition
on Sunday. Very interesting presentation for our ecosystem: Olle giving
a presentation about IPv4/IPv6, Inaki introducing its SFU media server
project, Jose talking about JsSIP, Daniel debating about fundraising
FreeRTC, Lorenzo with Janus SIP-WebRTC gateway, the other Lorenzo with
Homer Sipcature, Saul with Jitsi, Dan with cgrates, Matt with Asterisk,
Giovanni with FreeSwitch... Schedule at:
- https://fosdem.org/2017/schedule/track/real_time_communications/
On Sunday morning, part of Lua devroom, I will present about using Lua
for building RTC services with Kamailio:
- https://fosdem.org/2017/schedule/track/lua/
- https://fosdem.org/2017/schedule/event/luartcserviceskamailio/
During the past editions we organized a dinner on Saturday evening.
Shall we attempt to do it again in advance this year? Or should we do it
on spot based on the weather and mood at the end of Saturday?
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
Hello,
we have the following Configuration for our kamailio installation (we are
using TLS and not udp)
(1) F5 Firewall (configured as message fowarding), opening a TLS server on
the outside
(2) SIP proxy, with a TLS server accessed by the F5 . The SIP proxy doesnt
see the F5 TLS server
(3) SIP registrar
REGISTER works find
We have the following issue on INVITE:
A sends an INVITE to B.
The Registrar patches the R-URI with the content of location, which contains
the publi ip of the Device (because the device used stun)
we force the routing from registrar to proxy by using t_relay (SIP_PROXY_IP)
/The proxy tries to route to this R-URI, which is not visible/
I am not sure how to fix that:
Record Route is for a true sip proxy, but the Firewall does not have an
server facing the SIP proxy: the sip proxy needs to find the proper client
socket opened at register to route the INVITE
We have arranged for the Firewall to add its own Via, but if i understand
correctly, this is used for replies, and here we are dealing with a request
forwarding, and t_relay uses the r-ruri to route requests. IT might be why
REGISTER works correctly (ie the 200 OK is routed correctly from proxy to
firewall)
I could arrange for the location table to contain the private ip and port of
the firewall connection (through the use of the received/rport info inserted
in the Via by the proxy )
That would mean, however that the contact of the user will contain the
private interface of the F5 which i found weird.
How do you think i should proceed ? any advices are welcome
Thank you
--
View this message in context: http://sip-router.1086192.n5.nabble.com/kamailio-proxy-behind-firewall-tp15…
Sent from the Users mailing list archive at Nabble.com.
Hi All.
I ave just try to temporary disable 1 of 2 RTPEngines.
It was disabled successfully all media dialogs was finished.
But when I have try to enable it I have kamailio crashed with error:
CRITICAL: <core> [pass_fd.c:277]: receive_fd(): EOF on 121
Does anyone have such issue?
kamailio 4.4.5 on RHEL 7.2 x86_64
rtpengine 4.4.0 on RHEL 7.2 x86_64
# kamctl fifo nh_show_rtpp all
which: no gdb in
(/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/)
udp:10.1.23.24:2223:: set=0
index:: 0
disabled:: 0
weight:: 1
recheck_ticks:: 0
udp:10.1.23.25:2223:: set=0
index:: 1
disabled:: 0
weight:: 1
recheck_ticks:: 0
after
# kamctl fifo nh_enable_rtpp udp:10.1.23.25:2223 0
it was successfully disabled with media going on
after
# kamctl fifo nh_enable_rtpp udp:10.1.23.25:2223 1
I got kamailio crash with error
CRITICAL: <core> [pass_fd.c:277]: receive_fd(): EOF on 121
sorry I does not have coredump, it is production system.
my config regarding rtpengine:
modparam("rtpengine", "rtpengine_allow_op", 1)
modparam("rtpengine", "rtpengine_sock", "udp:10.1.23.24:2223
udp:10.1.23.25:2223")
Thank you.
--
Best regards,
Sergey Basov e-mail: sergey.v.basov(a)gmail.com
Hello sr-users,
First of all, I'm new to this forum so any help would be greatly
appreciated as my Kamailio knowledge is somewhat limited. Thanks for your
patience.
So to the question at hand. If the originator of the SIP method sends SIP
messages out of order, does the Kamailio put them back in order before
relaying it to the destination device? I'm seeing where the 200 OK was
sent first before the SIP UPDATE within the same CSeq number.
The reason I'm asking is because I'm seeing this behavior now with UDP
transport protocol and I'm trying to justify why we don't need to switch to
TCP to fix this issue.
Thanks.
--Andy
Our Kamailio 4.2.3 recently began seg-faulting in production. I ran a bt
full, but without the debuginfo I presume it isn't much use. We cannot
locate the original RPMs for this version to be able to obtain the
debuginfo RPM. We are running the kamailio-4.2.3-3.1.x86_64 RPM for
CentOS6. Anybody have it or can help us find the debug, or offer other
advice?
Hi,
I've fixed a loose_route problem with a broken gateway.
Essentially gateway sends ACKs and BYEs with an unroutable contact
header (i.e. it sticks the address of the proxy into the header,
rather than the destination UA address).
This is all on the same network, so there is not NAT.
So by caching the contact URI to for replies back to the gateway, I
can populate $ru to forward the ACK or BYE back to the correct UA.
However, what I've noticed is that for BYEs, I also need to set the
$du variable in addition to $ru. But this is required for ACKs.
This is not a problem per se, but I'm interesting to know why - could
anybody explain?
Cheers,
Ben
Hi guys,
We are using vmware to run kamailio. The thing is that they give us support
only if we install Red Hat.
Did you test kamailio on RH? Any issues or things to have in mind?
What linux dist do you recommend?
Thanks!
Diego.
Hello,
the dinner at Fosdem 2017 is planned to start at 20:00, on Saturday, Feb
4, 2017. The address is:
Le Pickwick
Avenue Adolphe Buyl 79
1050 Ixelles, Belgium
* https://en.yelp.be/biz/le-pickwick-ixelles
The place is nearby Fosdem location.
If you announced the intention to participate at the dinner before Feb
1, 2017, your seat is reserved. If you did it afterwards, please contact
me during RTC Devroom to confirm the availability of the seats.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
