Thanks Alex!
On Thu, 10 Dec 2020 at 14:09, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
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 <abalashov(a)evaristesys.com
<mailto:abalashov@evaristesys.com>> 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
<miconda(a)gmail.com
<mailto:miconda@gmail.com>
<mailto: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/>
<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(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
<mailto: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
<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
sr-users(a)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>
--
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
sr-users(a)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>
--
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users