Thanks Daniel!
2015-07-14 13:11 GMT+02:00 Daniel Tryba :
> >If i turn STUN off as Olle mentioned, all worked fine.. but if i have a
> >customer that for error it turns ON it does not work in my case..
>
> > Any way to force RTP in that cases?
>
> Just always start the rtpproxy, especially when
>If i turn STUN off as Olle mentioned, all worked fine.. but if i have a
>customer that for error it turns ON it does not work in my case..
> Any way to force RTP in that cases?
Just always start the rtpproxy, especially when you have a setup where some
rtp is handled with non public ips:
rout
Yes you are right , but in my scenario a couple of Asterisk behind NAT
must not route RTP directly , all must go to RTP Proxy so i have found
that case that for me its not working.
Sorry if i haven explained so much..
If i turn STUN off as Olle mentioned, all worked fine.. but if i have a
custo
Hello,
the request has public IP address in Via and Contact, matching the
source IP. If you look at the tests you do in the readme of the
nathelper module, then the request appears as not being natted, see:
-
http://kamailio.org/docs/modules/stable/modules/nathelper.html#nathelper.f.nat_uac_test
On Tuesday 14 July 2015 11:56:38 Alberto Sagredo wrote:
> I have found an issue detecting NAT of GS 1.4.23 Phones when using Stun on
> this phones
>
> Usual nat_uac_test with numbers 19 and 3 does not seems to detect is behind
> nat so NATMANAGE is not called
Isn't that the point of using things
> On 14 Jul 2015, at 11:56, Alberto Sagredo
> wrote:
>
> I have found an issue detecting NAT of GS 1.4.23 Phones when using Stun on
> this phones
If they activate STUN they signal with a public IP. If they signal with a
public IP, they tell us they
can handle NAT by themself and require no h
