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 <miconda@gmail.com
> <mailto:miconda@gmail.com>> 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
>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> 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
> 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