9 Dec
2020
9 Dec
'20
3:09 p.m.
The doorbell is the caller. ICE support would be required on the
callee side (between NATed callee and asterisk).
There's no need for ICE support on the doorbell/caller side.
-ovidiu
On Wed, Dec 9, 2020 at 2:42 AM Alex Balashov <abalashov(a)evaristesys.com> wrote:
ICE support just doesn't seem to me to be something a SIP doorbell would
have.
On 12/9/20 2:39 AM, Olle E. Johansson wrote:
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On 8 Dec 2020, at 18:55, Richard Fuchs
<rfuchs(a)sipwise.com
<mailto:rfuchs@sipwise.com>> wrote:
Use IPv6
While I like that proposal, assuming that IPv6 will not have a stateful
firewall is propably not a good assumption.
So I suspect that an IPv6 firewall would not let the packets in if there
is not outbound traffic first. I do like Ovidius
ICE-based solution and would like to add RTCP - if muxed it would open
the port, but the likelyhood that it’s
implemented is propably low.
IPv6 greetings!
/O :-)
Cheers
On 07/12/2020 23.01, David Cunningham wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
We have a problem with a SIP doorbell device which sends media one
way only, and NAT at the receiving device.
When the doorbell button is pressed it makes a call to a configured
destination. Since the doorbell only sends and doesn't receive it
sends the INVITE with sendonly in the SDP, and the destination then
replies with a 200 OK with recvonly in the SDP. The problem is that
the destination is behind NAT, and its reply contains a private
network IP in the SDP.
Normally Asterisk when nat=yes works around that by adjusting the
destination for RTP to be the address it actually receives audio
from, however because this device is recvonly Asterisk never receives
audio from it. This means Asterisk keeps trying to send the
doorbell's RTP to the private network IP which of course fails, and
the destination never gets the RTP from the doorbell.
We haven't found a solution in Asterisk to this, so are now looking
to Kamailio which acts as a load-balancing proxy in front of Asterisk
for one. For example, maybe we could use fix_nated_sdp, but only on
200 OK's with recvonly.
Has anyone else encountered this, and are there any recommended
solutions?
Thank you in advance!
--
David Cunningham, Voisonics Limited
http://voisonics.com/ <http://voisonics.com/>
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users