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
Here its some trace. ANy clue how to handle this phones if they activate STUN for example
U 80.26.x.x:52768 -> 192.168.0.170:8002
INVITE sip:2@x.x.x.x:8002 SIP/2.0.
Via: SIP/2.0/UDP 80.26.x.x:52768;branch=z9hG4bK358742535;rport.
From: "Anonymous" sip:anonymous@anonymous.invalid;tag=1478444456.
To: sip:2@x.x.x.x:8002.
Call-ID: 244257786-52768-56@IA.CG.BIE.BCH.
CSeq: 550 INVITE.
Contact: "Anonymous" sip:212@80.26.x.x:52768.
X-Grandstream-PBX: true.
Max-Forwards: 70.
User-Agent: Grandstream GXP2140 1.0.4.23.
Privacy: id.
P-Preferred-Identity: sip:212@x.x.x.x:8002.
Supported: replaces, path, timer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, application/dtmf-relay.
Content-Length: 335.
.
v=0.
o=212 8000 8000 IN IP4 80.26.x.x.
s=SIP Call.
c=IN IP4 80.26.x.x.
t=0 0.
m=audio 55422 RTP/AVP 0 8 18 9 2 101.
a=sendrecv.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:9 G722/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19)) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(FLT_NATS);
}
#!endif
return;
}
On 14 Jul 2015, at 11:56, Alberto Sagredo alberto.sagredo@avanzada7.com 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 help with NAT traversal from Kamailio.
Turn off STUN to get help from Kamailio.
/O
Usual nat_uac_test with numbers 19 and 3 does not seems to detect is behind nat so NATMANAGE is not called
Here its some trace. ANy clue how to handle this phones if they activate STUN for example
U 80.26.x.x:52768 -> 192.168.0.170:8002 http://192.168.0.170:8002/ INVITE sip:2@x.x.x.x:8002 SIP/2.0.
Via: SIP/2.0/UDP 80.26.x.x:52768;branch=z9hG4bK358742535;rport.
From: "Anonymous" sip:anonymous@anonymous.invalid;tag=1478444456.
To: sip:2@x.x.x.x:8002.
Call-ID: 244257786-52768-56@IA.CG.BIE.BCH.
CSeq: 550 INVITE.
Contact: "Anonymous" sip:212@80.26.x.x:52768.
X-Grandstream-PBX: true.
Max-Forwards: 70.
User-Agent: Grandstream GXP2140 1.0.4.23.
Privacy: id.
P-Preferred-Identity: sip:212@x.x.x.x:8002.
Supported: replaces, path, timer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, application/dtmf-relay.
Content-Length: 335.
.
v=0.
o=212 8000 8000 IN IP4 80.26.x.x.
s=SIP Call.
c=IN IP4 80.26.x.x.
t=0 0.
m=audio 55422 RTP/AVP 0 8 18 9 2 101.
a=sendrecv.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:9 G722/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport(); if (nat_uac_test("19)) { if (is_method("REGISTER")) { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS);}
#!endif
return;}
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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.n...
Test with 3 is 1 + 2 and test with 19 is 1 + 2 + 16
Cheers, Daniel
On 14/07/15 11:56, 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
Here its some trace. ANy clue how to handle this phones if they activate STUN for example
U 80.26.x.x:52768 -> 192.168.0.170:8002 http://192.168.0.170:8002
INVITE sip:2@x.x.x.x:8002 SIP/2.0.
Via: SIP/2.0/UDP 80.26.x.x:52768;branch=z9hG4bK358742535;rport.
From: "Anonymous" sip:anonymous@anonymous.invalid;tag=1478444456.
To: sip:2@x.x.x.x:8002.
Call-ID: 244257786-52768-56@IA.CG.BIE.BCH.
CSeq: 550 INVITE.
Contact: "Anonymous" sip:212@80.26.x.x:52768.
X-Grandstream-PBX: true.
Max-Forwards: 70.
User-Agent: Grandstream GXP2140 1.0.4.23.
Privacy: id.
P-Preferred-Identity: sip:212@x.x.x.x:8002.
Supported: replaces, path, timer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, application/dtmf-relay.
Content-Length: 335.
.
v=0.
o=212 8000 8000 IN IP4 80.26.x.x.
s=SIP Call.
c=IN IP4 80.26.x.x.
t=0 0.
m=audio 55422 RTP/AVP 0 8 18 9 2 101.
a=sendrecv.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:9 G722/8000.
a=rtpmap:2 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport(); if (nat_uac_test("19)) { if (is_method("REGISTER")) { fix_nated_register(); } else { fix_nated_contact(); } setflag(FLT_NATS);}
#!endif
return;}
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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 like STUN?
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 customer that for error it turns ON it does not work in my case..
Any way to force RTP in that cases?
BR
2015-07-14 12:07 GMT+02:00 Daniel Tryba d.tryba@pocos.nl:
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 like STUN?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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:
route[NATMANAGE] { rtpproxy_manage("f");
if (is_request()) { ...
It a little bit extra overhead, but much less worries about what an enduser signals and its interpretation.
Thanks Daniel!
2015-07-14 13:11 GMT+02:00 Daniel Tryba d.tryba@pocos.nl:
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:
route[NATMANAGE] { rtpproxy_manage("f");
if (is_request()) {...
It a little bit extra overhead, but much less worries about what an enduser signals and its interpretation.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alberto Sagredo -
Daniel Tryba -
Daniel-Constantin Mierla -
Olle E. Johansson