if(has_body("application/sdp") && search("a=sendonly")) [1]
It's what comes to mind off the top of my head, anyway.
-- Alex
[1] https://www.kamailio.org/docs/modules/stable/modules/textops.html
On 12/9/20 7:43 PM, David Cunningham wrote:
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]
<mailto:[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]>
> <mailto:[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/>
<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]>
<mailto:[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>
<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> <http://www.asipto.com <http://www.asipto.com>>
> www.twitter.com/miconda <http://www.twitter.com/miconda>
<http://www.twitter.com/miconda <http://www.twitter.com/miconda>>
--www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
<http://www.linkedin.com/in/miconda
<http://www.linkedin.com/in/miconda>>
> Funding:https://www.paypal.me/dcmierla
<https://www.paypal.me/dcmierla> <https://www.paypal.me/dcmierla
<https://www.paypal.me/dcmierla>>
>
>
>
> --
> David Cunningham, Voisonics Limited
> http://voisonics.com/ <http://voisonics.com/>
<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>
>
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>,
http://www.csrpswitch.com/ <http://www.csrpswitch.com/>
_______________________________________________
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>
--
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
