Hi Alex, Thank you for that. Do you offhand know of an easy way to test if the sendonly attribute is set? Presumably we can use sdp_remove_line_by_prefix() to remove it.,
On Wed, 9 Dec 2020 at 20:52, Alex Balashov <[email protected]> wrote: > 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 > -- David Cunningham, Voisonics Limited 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
