<div dir="ltr"><div>Hi Daniel,</div><div><br></div><div>Removing the sendonly from the INVITE SDP sounds like the most workable solution in our case. We'd only want to do it for a new INVITE though, not a re-INVITE in a situation where a call is put on hold. Would you be able to give an example of such a configuration?</div><div><br></div><div>Thanks very much for your help!</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla <<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hello,</p>
<p>if the endpoint is not behind a port forwarding nat/firewall
(when one can instruct the rtp relay to use signaling address),
then probably you can try to remove the sendonly from the INVITE
SDP. That will enable rtp from endpoint to doorbell, which may
rise additional concerns (e.g., privacy) if its is explicitly not
wanted to happen. But as Alex said in another response, the only
way to get it work is to make the endpoint behind nat to send a
RTP packet. Usually the doorbells I encountered so far were
accepting incoming traffic as well, to discuss/interact with the
person ringing on it.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>On 08.12.20 05:01, David Cunningham
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hello,</div>
<div>
<div><br>
</div>
<div>We have a problem with a SIP doorbell device which sends
media one way only, and NAT at the receiving device.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Has anyone else encountered this, and are there any
recommended solutions?<br>
</div>
<div><br>
</div>
<div>Thank you in advance<font color="#888888">!<br>
</font></div>
</div>
<div><br>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>David Cunningham, Voisonics Limited<br>
<a href="http://voisonics.com/" target="_blank">http://voisonics.com/</a><br>
USA: +1 213 221 1092<br>
New Zealand: +64 (0)28 2558 3782</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Kamailio (SER) - Users Mailing List
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre cols="72">--
Daniel-Constantin Mierla -- <a href="http://www.asipto.com" target="_blank">www.asipto.com</a>
<a href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Funding: <a href="https://www.paypal.me/dcmierla" target="_blank">https://www.paypal.me/dcmierla</a></pre>
</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David Cunningham, Voisonics Limited<br><a href="http://voisonics.com/" target="_blank">http://voisonics.com/</a><br>USA: +1 213 221 1092<br>New Zealand: +64 (0)28 2558 3782</div></div></div></div></div></div></div></div></div></div></div>