The salient quality of a reinvite is that has_totag() == true; it is
handled in the loose_route() section of your config. You want to do the
SDP manipulation in the part below that, where initial INVITEs are handled.
On 12/9/20 2:47 AM, David Cunningham wrote:
Hi Daniel,
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?
Thanks very much for your help!
On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla <[email protected]
<mailto:[email protected]>> wrote:
Hello,
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.
Cheers,
Daniel
On 08.12.20 05: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
[email protected] <mailto:[email protected]>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla --www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda>
--www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding:https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
--
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
[email protected]
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
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
