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...
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
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@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@192.168.1.200 CSeq: 3 REGISTER Server: Sip EXpress router Content-Length: 0
Arek Bekiersz wrote:
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).
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
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:
- "Contact" has public IP
- Via contains the same address as it was received from
- Topmost Via has public IP
- SDP contains public IPs (UA puts them)
- 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@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@192.168.1.200 CSeq: 3 REGISTER Server: Sip EXpress router Content-Length: 0
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.
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.
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?
Hi Arek,
Arek Bekiersz wrote:
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?
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 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...
...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@perceval.net To: "Bogdan-Andrei Iancu" bogdan@voice-system.ro Cc: "Openser-Users" users@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:
- 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
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@perceval.net To: "Bogdan-Andrei Iancu" bogdan@voice-system.ro Cc: "Openser-Users" users@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:
- 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
Are you using a Sipura ATA?
If so turn off NAt masquering if you are using STUN,
Regards,
-----Mensagem original----- De: users-bounces@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@perceval.net To: "Bogdan-Andrei Iancu" bogdan@voice-system.ro Cc: "Openser-Users" users@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:
- 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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Arek Bekiersz -
Bogdan-Andrei Iancu -
Elton Machado -
Klaus Darilion