16 Mar
2006
16 Mar
'06
8:28 p.m.
Hi,
Few days ago I presented UA that sends public IP in "Contact" and
"Via"
HF, when it is behind NAT. It is in private LAN but it learns its public
IP and every SIP request will contain public addresses.
It ruins NAT traversal effort, inluding nathelper + rtpproxy. I cannot
properly detect NAT-ed user neither by "Via" nor "Contact" check. As
a
result people with various modems get angry and are reporting to me all
those "I have no audio" problems. Or they cannot even register at all,
if they have partcularly stupid NAT.
What is your advice?
Vendor knows about issue but doesn't see problem.
Of course I can enable NAT traversal by "User-Agent" HF check, but 90%
of those UAs are NOT behind NAT...
--
Regards,
Arek Bekiersz
17 Mar
17 Mar
1:34 a.m.
Hi
Arek Bekiersz wrote:
Hi,
Few days ago I presented UA that sends public IP in "Contact" and
"Via"
HF, when it is behind NAT. It is in private LAN but it learns its public
IP and every SIP request will contain public addresses.
they may happen because the phone is using STUN or because of a
SIP-aware router (on NAT border)
It ruins NAT traversal effort, inluding nathelper + rtpproxy. I cannot
properly detect NAT-ed user neither by "Via" nor "Contact" check. As
a
result people with various modems get angry and are reporting to me all
those "I have no audio" problems. Or they cannot even register at all,
if they have partcularly stupid NAT.
take a look at:
http://openser.org/docs/modules/1.0.x/nathelper.html#AEN349
you have 5 tests to detect NATed clients
What is your advice?
use combined nat detection tests in order to force rtpproxy.
Vendor knows about issue but doesn't see problem.
Of course I can enable NAT traversal by "User-Agent" HF check, but 90%
of those UAs are NOT behind NAT...
regards,
bogdan
1:49 a.m.
Hello Bogdan,
Bogdan-Andrei Iancu wrote:
they may happen because the phone is using STUN or
because of a
SIP-aware router (on NAT border)
There is no STUN and the NAT is really simple one (not SIP-aware).
take a look at:
http://openser.org/docs/modules/1.0.x/nathelper.html#AEN349
you have 5 tests to detect NATed clients
None of those tests works:
1) "Contact" has public IP
2) Via contains the same address as it was received from
4) Topmost Via has public IP
8) SDP contains public IPs (UA puts them)
16) Source port is the same as in Via
This UA is a popular one. This effect is observed in firmwares that are
officially on the market for more than 3 months. I would like to force
vendor to correct this problem as soon as possible, because other of us
can experience similar problem. But first I want to be sure this is
vendor problem, not SER problem.
Here is sample debug of REGISTER sequence:
UA has IP 192.168.1.200 in private LAN behind NAT.
NAT maps UAs port 5060 in LAN to port 61003 in WAN:
192.168.1.200:5060 -> proxy_wan_ip:5060
REGISTER sip:proxy_realm SIP/2.0
Via: SIP/2.0/UDP
192.168.1.200:5060;branch=z9hG4bKD87C4E6B9057BD25A6EC854BAEB4F
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>
Call-ID: foo
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: stupid-user-agent
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
proxy_wan_ip:5060 -> 192.168.1.200:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.1.200:5060;branch=z9hG4bKD87C4E6B9057BD25A6EC854BAEB4F;rport=61003;received=nat_wan_ip
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.8ec3
Call-ID: 31888733A35E0EFE3FC22B073B50C(a)192.168.1.200
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="proxy_realm",
nonce="4405aadab124f8b271a6d6282a0fd9abc4b09b8e"
Server: Sip EXpress router
Content-Length: 0
192.168.1.200:5060 -> proxy_wan_ip:5060
REGISTER sip:proxy_realm SIP/2.0
Via: SIP/2.0/UDP
nat_wan_ip:61003;branch=z9hG4bK7BB67339C326394708852DEC41F3C
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>
Call-ID: foo
CSeq: 2 REGISTER
Authorization: Digest username="1234", realm="proxy_realm",
nonce="4405aadab124f8b271a6d6282a0fd9abc4b09b8e",
uri="sip:proxy_realm",
response="5a5c8fd5e58aa3cdcaff214c5ae4d2aa"
Max-Forwards: 70
User-Agent: stupid-user-agent
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
proxy_wan_ip:5060 -> 192.168.1.200:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP
nat_wan_ip:61003;branch=z9hG4bK7BB67339C326394708852DEC41F3C
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.1a9c
Call-ID: foo
CSeq: 2 REGISTER
Server: Sip EXpress router
Content-Length: 0
192.168.1.200:5060 -> proxy_wan_ip:5060
REGISTER sip:proxy_realm SIP/2.0
[WRONG!!] Via: SIP/2.0/udp
nat_wan_ip:61003;branch=z9hG4bK82B006EB79CB30C39996A78C9962D
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>
Call-ID: foo
CSeq: 3 REGISTER
[WRONG!!] Contact:
<sip:1234@nat_wan_ip:61003;uniq=0FC6DA2B97704905AA040333C2B03>
Authorization: Digest username="1234", realm="proxy_realm",
nonce="4405aadab124f8b271a6d6282a0fd9abc4b09b8e",
uri="sip:proxy_realm",
response="5a5c8fd5e58aa3cdcaff214c5ae4d2aa"
Expires: 1800
Max-Forwards: 70
User-Agent: stupid-user-agent
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
proxy_wan_ip:5060 -> 192.168.1.200:5060
SIP/2.0 200 OK
Via: SIP/2.0/udp
nat_wan_ip:61003;branch=z9hG4bK82B006EB79CB30C39996A78C9962D
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.3770
Call-ID: 31888733A35E0EFE3FC22B073B50C(a)192.168.1.200
CSeq: 3 REGISTER
Server: Sip EXpress router
Content-Length: 0
--
Regards,
Arek Bekiersz
2:50 a.m.
Arek Bekiersz wrote:
Hello Bogdan,
Bogdan-Andrei Iancu wrote:
as the trace shows, the phone does via SIP a kind of auto-detection of
the external IP based on received and rport via params.... can you
disable this feature?
regards,
bogdan
they may happen because the phone is using STUN
or because of a
SIP-aware router (on NAT border)
There is no STUN and the NAT is really simple one (not SIP-aware).
take a look at:
http://openser.org/docs/modules/1.0.x/nathelper.html#AEN349
you have 5 tests to detect NATed clients
None of those tests works:
1) "Contact" has public IP
2) Via contains the same address as it was received from
4) Topmost Via has public IP
8) SDP contains public IPs (UA puts them)
16) Source port is the same as in Via
This UA is a popular one. This effect is observed in firmwares that
are officially on the market for more than 3 months. I would like to
force vendor to correct this problem as soon as possible, because
other of us can experience similar problem. But first I want to be
sure this is vendor problem, not SER problem.
Here is sample debug of REGISTER sequence:
UA has IP 192.168.1.200 in private LAN behind NAT.
NAT maps UAs port 5060 in LAN to port 61003 in WAN:
192.168.1.200:5060 -> proxy_wan_ip:5060
REGISTER sip:proxy_realm SIP/2.0
Via: SIP/2.0/UDP
192.168.1.200:5060;branch=z9hG4bKD87C4E6B9057BD25A6EC854BAEB4F
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>
Call-ID: foo
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: stupid-user-agent
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
proxy_wan_ip:5060 -> 192.168.1.200:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.1.200:5060;branch=z9hG4bKD87C4E6B9057BD25A6EC854BAEB4F;rport=61003;received=nat_wan_ip
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.8ec3
Call-ID: 31888733A35E0EFE3FC22B073B50C(a)192.168.1.200
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="proxy_realm",
nonce="4405aadab124f8b271a6d6282a0fd9abc4b09b8e"
Server: Sip EXpress router
Content-Length: 0
192.168.1.200:5060 -> proxy_wan_ip:5060
REGISTER sip:proxy_realm SIP/2.0
Via: SIP/2.0/UDP
nat_wan_ip:61003;branch=z9hG4bK7BB67339C326394708852DEC41F3C
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>
Call-ID: foo
CSeq: 2 REGISTER
Authorization: Digest username="1234", realm="proxy_realm",
nonce="4405aadab124f8b271a6d6282a0fd9abc4b09b8e",
uri="sip:proxy_realm", response="5a5c8fd5e58aa3cdcaff214c5ae4d2aa"
Max-Forwards: 70
User-Agent: stupid-user-agent
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
proxy_wan_ip:5060 -> 192.168.1.200:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP
nat_wan_ip:61003;branch=z9hG4bK7BB67339C326394708852DEC41F3C
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.1a9c
Call-ID: foo
CSeq: 2 REGISTER
Server: Sip EXpress router
Content-Length: 0
192.168.1.200:5060 -> proxy_wan_ip:5060
REGISTER sip:proxy_realm SIP/2.0
[WRONG!!] Via: SIP/2.0/udp
nat_wan_ip:61003;branch=z9hG4bK82B006EB79CB30C39996A78C9962D
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>
Call-ID: foo
CSeq: 3 REGISTER
[WRONG!!] Contact:
<sip:1234@nat_wan_ip:61003;uniq=0FC6DA2B97704905AA040333C2B03>
Authorization: Digest username="1234", realm="proxy_realm",
nonce="4405aadab124f8b271a6d6282a0fd9abc4b09b8e",
uri="sip:proxy_realm", response="5a5c8fd5e58aa3cdcaff214c5ae4d2aa"
Expires: 1800
Max-Forwards: 70
User-Agent: stupid-user-agent
Supported: 100rel, replaces
Allow-Events: telephone-event, refer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INFO,
SUBSCRIBE, NOTIFY, REFER, MESSAGE
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
proxy_wan_ip:5060 -> 192.168.1.200:5060
SIP/2.0 200 OK
Via: SIP/2.0/udp
nat_wan_ip:61003;branch=z9hG4bK82B006EB79CB30C39996A78C9962D
From: <sip:1234@proxy_realm>;tag=2789838218
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.3770
Call-ID: 31888733A35E0EFE3FC22B073B50C(a)192.168.1.200
CSeq: 3 REGISTER
Server: Sip EXpress router
Content-Length: 0
3 a.m.
Hi Bogdan,
Bogdan-Andrei Iancu wrote:
as the trace shows, the phone does via SIP a kind of
auto-detection of
the external IP based on received and rport via params.... can you
disable this feature?
You are right.
No, I cannot disable it. There is no such option :-(((
I send you the trace of INVITE transaction as seen from LAN behind NAT.
It shows that also SDP is rewritten.
--
Regards,
Arek Bekiersz
---------------------------------------------------------------------------
Packet 1
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
INVITE sip:1234@proxy_realm SIP/2.0.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK483828829A0FFE1CBE2D351EC40C9.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 5 INVITE.
Contact: <sip:5678@nat_public_ip:61001;uniq=0FC6DA2B97704905AA040333C2B03>.
Max-Forwards: 70.
Expires: 120.
User-Agent: trouble-user-agent
.
Supported: 100rel, replaces.
Allow-Events: telephone-event, refer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INF
O, SUBSCRIBE, NOTIFY, REFER, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, multipart/mixed.
Accept-Encoding: identity.
Content-Length: 277.
.
v=0.
o=user 6744156 6744156 IN IP4 nat_public_ip.
s=call.
c=IN IP4 nat_public_ip.
t=1140702179 1140705779.
m=audio 7078 RTP/AVP 2 102 18 8 101.
a=sendrecv.
a=rtpmap:2 G726-32/8000.
a=rtpmap:102 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
a=rtcp:7079.
---------------------------------------------------------------------------
Packet 2
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK483828829A0FFE1CBE2D351EC40C9.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.341c.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 5 INVITE.
Proxy-Authenticate: Digest realm=".....
Server: Sip EXpress router.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 3
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
ACK sip:1234@proxy_realm SIP/2.0.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK483828829A0FFE1CBE2D351EC40C9.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.341c.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 5 ACK.
User-Agent: trouble-user-agent
.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 4
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
INVITE sip:1234@proxy_realm SIP/2.0.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
Contact: <sip:5678@nat_public_ip:61001;uniq=0FC6DA2B977049
05AA040333C2B03>.
Proxy-Authorization: Digest username="5678", realm=".....
Max-Forwards: 70.
Expires: 120.
User-Agent: trouble-user-agent
.
Supported: 100rel, replaces.
Allow-Events: telephone-event, refer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INF
O, SUBSCRIBE, NOTIFY, REFER, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, multipart/mixed.
Accept-Encoding: identity.
Content-Length: 277.
.
v=0.
o=user 6744156 6744156 IN IP4 nat_public_ip.
s=call.
c=IN IP4 nat_public_ip.
t=1140702179 1140705779.
m=audio 7078 RTP/AVP 2 102 18 8 101.
a=sendrecv.
a=rtpmap:2 G726-32/8000.
a=rtpmap:102 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
a=rtcp:7079.
---------------------------------------------------------------------------
Packet 5
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
Server: Sip EXpress router.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 6
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 180 Ringing.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=as490a0c26.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
User-Agent: good-ua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
Contact: <sip:1234@good-ua-ip>.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 8
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 200 OK.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
Record-Route: <sip:1234@proxy_public_ip;ftag=A37DA72FCC637B1D7AEB5AEAFEBC2;lr=on>.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=as490a0c26.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
User-Agent: good-ua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
Contact: <sip:1234@good-ua-ip>.
Content-Type: application/sdp.
Content-Length: 297.
.
v=0.
o=root 10049 10049 IN IP4 good-ua-ip.
s=session.
c=IN IP4 good-ua-ip.
t=0 0.
m=audio 10276 RTP/AVP 2 5 8 0 101.
a=rtpmap:2 G726-32/8000.
a=rtpmap:5 DVI4/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
---------------------------------------------------------------------------
Packet 9
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
ACK sip:1234@194.183.228.175 SIP/2.0.
Via: SIP/2.0/UDP nat_public_ip:61001;branch=z9hG4bK4E416AB44C125E935C1A974F2EA86.
Route: <sip:1234@proxy_public_ip;ftag=A37DA72FCC637B1D7AEB5AEAFEBC2;lr=on>.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=as490a0c26.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 ACK.
Contact: <sip:5678@nat_public_ip:61001;uniq=0FC6DA2B97704905AA040333C2B03>.
Max-Forwards: 70.
User-Agent: trouble-user-agent
.
Content-Length: 0.
8:09 p.m.
Hi Arek,
looking on the signalling, you cannot detect the call as nated from
proxy point of view, so there is not much you can do. It's a typically
situation where the the phones tries to perform nat traversal on its
sides but does not do a complete job, preventing also the proxy to do it :(
regards,
bogdan
Arek Bekiersz wrote:
Hi Bogdan,
Bogdan-Andrei Iancu wrote:
as the trace shows, the phone does via SIP a kind
of auto-detection
of the external IP based on received and rport via params.... can you
disable this feature?
You are right.
No, I cannot disable it. There is no such option :-(((
I send you the trace of INVITE transaction as seen from LAN behind
NAT. It shows that also SDP is rewritten.
------------------------------------------------------------------------
---------------------------------------------------------------------------
Packet 1
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
INVITE sip:1234@proxy_realm SIP/2.0.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK483828829A0FFE1CBE2D351EC40C9.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 5 INVITE.
Contact: <sip:5678@nat_public_ip:61001;uniq=0FC6DA2B97704905AA040333C2B03>.
Max-Forwards: 70.
Expires: 120.
User-Agent: trouble-user-agent
.
Supported: 100rel, replaces.
Allow-Events: telephone-event, refer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INF
O, SUBSCRIBE, NOTIFY, REFER, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, multipart/mixed.
Accept-Encoding: identity.
Content-Length: 277.
.
v=0.
o=user 6744156 6744156 IN IP4 nat_public_ip.
s=call.
c=IN IP4 nat_public_ip.
t=1140702179 1140705779.
m=audio 7078 RTP/AVP 2 102 18 8 101.
a=sendrecv.
a=rtpmap:2 G726-32/8000.
a=rtpmap:102 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
a=rtcp:7079.
---------------------------------------------------------------------------
Packet 2
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK483828829A0FFE1CBE2D351EC40C9.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.341c.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 5 INVITE.
Proxy-Authenticate: Digest realm=".....
Server: Sip EXpress router.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 3
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
ACK sip:1234@proxy_realm SIP/2.0.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK483828829A0FFE1CBE2D351EC40C9.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=935ab969d5b642f019e17a3a52b4e4b2.341c.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 5 ACK.
User-Agent: trouble-user-agent
.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 4
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
INVITE sip:1234@proxy_realm SIP/2.0.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
Contact: <sip:5678@nat_public_ip:61001;uniq=0FC6DA2B977049
05AA040333C2B03>.
Proxy-Authorization: Digest username="5678", realm=".....
Max-Forwards: 70.
Expires: 120.
User-Agent: trouble-user-agent
.
Supported: 100rel, replaces.
Allow-Events: telephone-event, refer.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, UPDATE, PRACK, INF
O, SUBSCRIBE, NOTIFY, REFER, MESSAGE.
Content-Type: application/sdp.
Accept: application/sdp, multipart/mixed.
Accept-Encoding: identity.
Content-Length: 277.
.
v=0.
o=user 6744156 6744156 IN IP4 nat_public_ip.
s=call.
c=IN IP4 nat_public_ip.
t=1140702179 1140705779.
m=audio 7078 RTP/AVP 2 102 18 8 101.
a=sendrecv.
a=rtpmap:2 G726-32/8000.
a=rtpmap:102 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.
a=rtcp:7079.
---------------------------------------------------------------------------
Packet 5
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
Server: Sip EXpress router.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 6
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 180 Ringing.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=as490a0c26.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
User-Agent: good-ua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
Contact: <sip:1234@good-ua-ip>.
Content-Length: 0.
.
---------------------------------------------------------------------------
Packet 8
Source IP Address:proxy_public_ip
Destination IP Address:192.168.1.200
SIP/2.0 200 OK.
Via: SIP/2.0/udp nat_public_ip:61001;branch=z9hG4bK0DA7F19CA20D7B6DA35154CA9467C.
Record-Route: <sip:1234@proxy_public_ip;ftag=A37DA72FCC637B1D7AEB5AEAFEBC2;lr=on>.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=as490a0c26.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 INVITE.
User-Agent: good-ua
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER.
Contact: <sip:1234@good-ua-ip>.
Content-Type: application/sdp.
Content-Length: 297.
.
v=0.
o=root 10049 10049 IN IP4 good-ua-ip.
s=session.
c=IN IP4 good-ua-ip.
t=0 0.
m=audio 10276 RTP/AVP 2 5 8 0 101.
a=rtpmap:2 G726-32/8000.
a=rtpmap:5 DVI4/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
---------------------------------------------------------------------------
Packet 9
Source IP Address:192.168.1.200
Destination IP Address:proxy_public_ip
ACK sip:1234@194.183.228.175 SIP/2.0.
Via: SIP/2.0/UDP nat_public_ip:61001;branch=z9hG4bK4E416AB44C125E935C1A974F2EA86.
Route: <sip:1234@proxy_public_ip;ftag=A37DA72FCC637B1D7AEB5AEAFEBC2;lr=on>.
From: <sip:5678@proxy_realm>;tag=A37DA72FCC637B1D7AEB5AEAFEBC2.
To: <sip:1234@proxy_realm>;tag=as490a0c26.
Call-ID: 4B7150B7D8D94964AE0470E367DE9@nat_public_ip.
CSeq: 6 ACK.
Contact: <sip:5678@nat_public_ip:61001;uniq=0FC6DA2B97704905AA040333C2B03>.
Max-Forwards: 70.
User-Agent: trouble-user-agent
.
Content-Length: 0.
18 Mar
18 Mar
1:36 a.m.
Hi Bogdan,
Thanks for all the help.
Bogdan-Andrei Iancu wrote:
Hi Arek,
looking on the signalling, you cannot detect the call as nated from
proxy point of view, so there is not much you can do. It's a typically
situation where the the phones tries to perform nat traversal on its
sides but does not do a complete job, preventing also the proxy to do it :(
So what is your final advice about how to speak with German vendor?
They are not violating RFC, but clearly, ther device will NOT work with
SER or OpenSER in NAT-traversal scenario.
They say to us everytime that they "sold approx. 2 milion of those boxes
and nobody, no ISP complained". I do not believe at all - this is DSL
router/modem, so maybe they talk about non-VoIP and VoIP boxes together.
But you will never know, this is marketing talk..
They say that "ITU-T has given them an approval. This approval described
that they are fully compatible with the RFC´s for VoIP". Well, yes, they
do not break RFC. But one flavour of this device is an ATA box, without
DSL modem. Majority of my customers will buy this ATA to use with
existing DSL router, cable modem/router or such. They WILL have
unfriendly NAT there, so what is the sense of ATA box?
--
Regards,
Arek Bekiersz
22 Mar
22 Mar
2:55 a.m.
Hi Arek,
Arek Bekiersz wrote:
Hi Bogdan,
Thanks for all the help.
Bogdan-Andrei Iancu wrote:
it's not about RFC compliance here, but about making it work, about the
logic used to detect and traverse NATS , things that are not specified
by RFC.
I guess it should be reasonable from them to accept to make this auto
NAT detection configurable in order to disable it.
alternative solutions will be (1) to consider all these UAC as nated -
by looking at UA hdr- or (2) to try to remember the NAT flag from the
non-authenticated REGISTER until the auth-ed one - the first
(challenged) register will reveal the true status of the clients (nated
or not) as it's also used by client for nat detection....but I guess it
will be quite complicated
regards,
bogdan
Hi Arek,
looking on the signalling, you cannot detect the call as nated from
proxy point of view, so there is not much you can do. It's a
typically situation where the the phones tries to perform nat
traversal on its sides but does not do a complete job, preventing
also the proxy to do it :(
So what is your final advice about how to speak with German vendor?
They are not violating RFC, but clearly, ther device will NOT work
with SER or OpenSER in NAT-traversal scenario.
They say to us everytime that they "sold approx. 2 milion of those
boxes and nobody, no ISP complained". I do not believe at all - this
is DSL router/modem, so maybe they talk about non-VoIP and VoIP boxes
together. But you will never know, this is marketing talk..
They say that "ITU-T has given them an approval. This approval
described that they are fully compatible with the RFC´s for VoIP".
Well, yes, they do not break RFC. But one flavour of this device is an
ATA box, without DSL modem. Majority of my customers will buy this ATA
to use with existing DSL router, cable modem/router or such. They WILL
have unfriendly NAT there, so what is the sense of ATA box?
6:03 a.m.
Hi Bogdan,
I think it should be possible by some flag manipulation, with some help
from registrar module. I can:
1. Set NAT-ed flag (flag 1) on first REGISTER, that comes with private
IP in Via
2. If flag (1) is set, store "temporary" registration in "location"
table, with flag (let's say flag 10)
3. challenge user
4. when second REGISTER comes (with public IP Via ,so there is no (1)
flag) check if UA is "already" in "location" table and the flag (10)
was
stored
5. If yes, set flag (1) (UA wanted to cheat us, he is NATed), answer
'200 OK' and store in "location" table, this time with flag (1)
6. Next actions will assume that user is NAT-ed, by checking (1) flag in
"location". He will also be pinged from SER. Pretty standard stuff.
However, the problem is there is no "Contact" in first REGISTER. So I
cannot store temporary entry in "location" database.. But the true
(private) IP of user is still in Via. So maybe I could append "Contact"
header field with IP value from Via. It would allow me to store this
"temporary" registration.
QUESTION: Do we have any access to Via value from ser.cfg, to append
Contact HF with Via value? And not the topmost, but the last Via, as
this will probably contain true private IP of UA?
Help!!!
I don't want to write another custom module or database for this stupid
UA. In fact last year I had to write custom module for SDP manipulation.
It was impossible to set codec preference in the SAME vendor's devices.
I had preferred system codec and I had to force it using brute force...
works until today...
--
Regards,
Arek Bekiersz
Bogdan-Andrei Iancu wrote:
it's not about RFC compliance here, but about
making it work, about the
logic used to detect and traverse NATS , things that are not specified
by RFC.
I guess it should be reasonable from them to accept to make this auto
NAT detection configurable in order to disable it.
alternative solutions will be (1) to consider all these UAC as nated -
by looking at UA hdr- or (2) to try to remember the NAT flag from the
non-authenticated REGISTER until the auth-ed one - the first
(challenged) register will reveal the true status of the clients (nated
or not) as it's also used by client for nat detection....but I guess it
will be quite complicated
7:50 a.m.
...and I answer myself.
Of course I don't need the Via value. It's not the private IP I want , but
obviously the received, public one. Come on, I was tired, sorry :-)))
For this UA I will try to solve the problem using AVP module, or I will
write some custom functions elsewhere. I just need to store real, public
(received) IP in 'location' table, together with NAT-ed flag. Could be done
either with appending Contact HF with received IP, by some clever avp
"store-retrieve" usage or otherwise.
--
Regards,
Arek Bekiersz
----- Original Message -----
From: "Arek Bekiersz" <arek(a)perceval.net>
To: "Bogdan-Andrei Iancu" <bogdan(a)voice-system.ro>
Cc: "Openser-Users" <users(a)openser.org>
Sent: Tuesday, March 21, 2006 8:03 PM
Subject: Re: [Users] UA behind NAT puts public IP in Contact, Via - help
Hi Bogdan,
I think it should be possible by some flag manipulation, with some help
from registrar module. I can:
1. Set NAT-ed flag (flag 1) on first REGISTER, that comes with private
IP in Via
2. If flag (1) is set, store "temporary" registration in "location"
table, with flag (let's say flag 10)
3. challenge user
4. when second REGISTER comes (with public IP Via ,so there is no (1)
flag) check if UA is "already" in "location" table and the flag (10)
was
stored
5. If yes, set flag (1) (UA wanted to cheat us, he is NATed), answer
'200 OK' and store in "location" table, this time with flag (1)
6. Next actions will assume that user is NAT-ed, by checking (1) flag in
"location". He will also be pinged from SER. Pretty standard stuff.
However, the problem is there is no "Contact" in first REGISTER. So I
cannot store temporary entry in "location" database.. But the true
(private) IP of user is still in Via. So maybe I could append "Contact"
header field with IP value from Via. It would allow me to store this
"temporary" registration.
QUESTION: Do we have any access to Via value from ser.cfg, to append
Contact HF with Via value? And not the topmost, but the last Via, as
this will probably contain true private IP of UA?
Help!!!
I don't want to write another custom module or database for this stupid
UA. In fact last year I had to write custom module for SDP manipulation.
It was impossible to set codec preference in the SAME vendor's devices.
I had preferred system codec and I had to force it using brute force...
works until today...
--
Regards,
Arek Bekiersz
Bogdan-Andrei Iancu wrote:
> it's not about RFC compliance here, but about making it work, about the
> logic used to detect and traverse NATS , things that are not specified
> by RFC.
> I guess it should be reasonable from them to accept to make this auto
> NAT detection configurable in order to disable it.
> alternative solutions will be (1) to consider all these UAC as nated -
> by looking at UA hdr- or (2) to try to remember the NAT flag from the
> non-authenticated REGISTER until the auth-ed one - the first
> (challenged) register will reveal the true status of the clients (nated
> or not) as it's also used by client for nat detection....but I guess it
> will be quite complicated
24 Mar
24 Mar
3:31 a.m.
Hi Arek,
my advice will be to avoid changing stuff into the proxy just to make
broken clients to work. Better try to fix the problem on its root, in
the client or simply change the client with a better one.
regards,
bogdan
Arek Bekiersz wrote:
...and I answer myself.
Of course I don't need the Via value. It's not the private IP I want , but
obviously the received, public one. Come on, I was tired, sorry :-)))
For this UA I will try to solve the problem using AVP module, or I will
write some custom functions elsewhere. I just need to store real, public
(received) IP in 'location' table, together with NAT-ed flag. Could be done
either with appending Contact HF with received IP, by some clever avp
"store-retrieve" usage or otherwise.
--
Regards,
Arek Bekiersz
----- Original Message -----
From: "Arek Bekiersz" <arek(a)perceval.net>
To: "Bogdan-Andrei Iancu" <bogdan(a)voice-system.ro>
Cc: "Openser-Users" <users(a)openser.org>
Sent: Tuesday, March 21, 2006 8:03 PM
Subject: Re: [Users] UA behind NAT puts public IP in Contact, Via - help
Hi Bogdan,
I think it should be possible by some flag manipulation, with some help
from registrar module. I can:
1. Set NAT-ed flag (flag 1) on first REGISTER, that comes with private
IP in Via
2. If flag (1) is set, store "temporary" registration in "location"
table, with flag (let's say flag 10)
3. challenge user
4. when second REGISTER comes (with public IP Via ,so there is no (1)
flag) check if UA is "already" in "location" table and the flag (10)
was
stored
5. If yes, set flag (1) (UA wanted to cheat us, he is NATed), answer
'200 OK' and store in "location" table, this time with flag (1)
6. Next actions will assume that user is NAT-ed, by checking (1) flag in
"location". He will also be pinged from SER. Pretty standard stuff.
However, the problem is there is no "Contact" in first REGISTER. So I
cannot store temporary entry in "location" database.. But the true
(private) IP of user is still in Via. So maybe I could append "Contact"
header field with IP value from Via. It would allow me to store this
"temporary" registration.
QUESTION: Do we have any access to Via value from ser.cfg, to append
Contact HF with Via value? And not the topmost, but the last Via, as
this will probably contain true private IP of UA?
Help!!!
I don't want to write another custom module or database for this stupid
UA. In fact last year I had to write custom module for SDP manipulation.
It was impossible to set codec preference in the SAME vendor's devices.
I had preferred system codec and I had to force it using brute force...
works until today...
--
Regards,
Arek Bekiersz
Bogdan-Andrei Iancu wrote:
>it's not about RFC compliance here, but about making it work, about the
>logic used to detect and traverse NATS , things that are not specified
>by RFC.
>I guess it should be reasonable from them to accept to make this auto
>NAT detection configurable in order to disable it.
>alternative solutions will be (1) to consider all these UAC as nated -
>by looking at UA hdr- or (2) to try to remember the NAT flag from the
>non-authenticated REGISTER until the auth-ed one - the first
>(challenged) register will reveal the true status of the clients (nated
>or not) as it's also used by client for nat detection....but I guess it
>will be quite complicated
>
>
25 Mar
25 Mar
7:31 a.m.
Are you using a Sipura ATA?
If so turn off NAt masquering if you are using STUN,
Regards,
-----Mensagem original-----
De: users-bounces(a)openser.org [mailto:users-bounces@openser.org] Em nome de
Arek Bekiersz
Enviada: terça-feira, 21 de Março de 2006 20:51
Para: Bogdan-Andrei Iancu
Cc: Openser-Users
Assunto: Re: [Users] UA behind NAT puts public IP in Contact, Via - help
...and I answer myself.
Of course I don't need the Via value. It's not the private IP I want , but
obviously the received, public one. Come on, I was tired, sorry :-)))
For this UA I will try to solve the problem using AVP module, or I will
write some custom functions elsewhere. I just need to store real, public
(received) IP in 'location' table, together with NAT-ed flag. Could be done
either with appending Contact HF with received IP, by some clever avp
"store-retrieve" usage or otherwise.
--
Regards,
Arek Bekiersz
----- Original Message -----
From: "Arek Bekiersz" <arek(a)perceval.net>
To: "Bogdan-Andrei Iancu" <bogdan(a)voice-system.ro>
Cc: "Openser-Users" <users(a)openser.org>
Sent: Tuesday, March 21, 2006 8:03 PM
Subject: Re: [Users] UA behind NAT puts public IP in Contact, Via - help
Hi Bogdan,
I think it should be possible by some flag manipulation, with some help
from registrar module. I can:
1. Set NAT-ed flag (flag 1) on first REGISTER, that comes with private
IP in Via
2. If flag (1) is set, store "temporary" registration in "location"
table, with flag (let's say flag 10)
3. challenge user
4. when second REGISTER comes (with public IP Via ,so there is no (1)
flag) check if UA is "already" in "location" table and the flag (10)
was
stored
5. If yes, set flag (1) (UA wanted to cheat us, he is NATed), answer
'200 OK' and store in "location" table, this time with flag (1)
6. Next actions will assume that user is NAT-ed, by checking (1) flag in
"location". He will also be pinged from SER. Pretty standard stuff.
However, the problem is there is no "Contact" in first REGISTER. So I
cannot store temporary entry in "location" database.. But the true
(private) IP of user is still in Via. So maybe I could append "Contact"
header field with IP value from Via. It would allow me to store this
"temporary" registration.
QUESTION: Do we have any access to Via value from ser.cfg, to append
Contact HF with Via value? And not the topmost, but the last Via, as
this will probably contain true private IP of UA?
Help!!!
I don't want to write another custom module or database for this stupid
UA. In fact last year I had to write custom module for SDP manipulation.
It was impossible to set codec preference in the SAME vendor's devices.
I had preferred system codec and I had to force it using brute force...
works until today...
--
Regards,
Arek Bekiersz
Bogdan-Andrei Iancu wrote:
> it's not about RFC compliance here, but about making it work, about the
> logic used to detect and traverse NATS , things that are not specified
> by RFC.
> I guess it should be reasonable from them to accept to make this auto
> NAT detection configurable in order to disable it.
> alternative solutions will be (1) to consider all these UAC as nated -
> by looking at UA hdr- or (2) to try to remember the NAT flag from the
> non-authenticated REGISTER until the auth-ed one - the first
> (challenged) register will reveal the true status of the clients (nated
> or not) as it's also used by client for nat detection....but I guess it
> will be quite complicated
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6870
days inactive
6881
days old
12 comments
4 participants
participants (4)
-
Arek Bekiersz -
Bogdan-Andrei Iancu -
Elton Machado -
Klaus Darilion