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@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:
On 8 Dec 2020, at 18:55, Richard Fuchs <rfuchs@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:
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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto: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
-- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users