24 Aug
2006
24 Aug
'06
4:12 a.m.
I'm testing my rtpproxy config with a linksys phone and a grandstream phone,
either not NAT'ed, or behind a cisco (full cone), or behind a Netgear (symmetric).
Things generally work, but I have a problem with the grandstream
behind the symmetric nat.
This is the register:
U NAT-IP:3284 -> PROXY-IP:5060
REGISTER sip:sip.example.com SIP/2.0
Via: SIP/2.0/UDP NAT-IP:3280;branch=z9hG4bK0103d0ff79cc9c02
From: "Grandstream"
<sip:frick@sip.example.com;user=phone>;tag=743335557afcade4
To: <sip:frick@sip.example.com;user=phone>
Contact: <sip:frick@NAT-IP:3280;user=phone>
Authorization: Digest username="frick", realm="sip.example.com",
algorithm=MD5, uri="sip:sip.example.com", nonce="foo",
response="bar"
Call-ID: 11f6defb0857db17(a)192.168.0.100
CSeq: 116 REGISTER
Expires: 60
User-Agent: Grandstream BT100 1.0.6.7
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Length: 0
This is the resulting contact:
...Record(0x2864b680)..
domain: 'location'
aor : 'frick(a)sip.example.com'
~~~Contact(0x2864d4e0)~~~
domain : 'location'
aor : 'frick(a)sip.example.com'
Contact : 'sip:frick@NAT-IP:3280;user=phone'
Expires : 34
q :
Call-ID : '11f6defb0857db17(a)192.168.0.100'
CSeq : 119
User-Agent: 'Grandstream BT100 1.0.6.7'
received : 'sip:NAT-IP:3284'
Path : ''
State : CS_SYNC
Flags : 1
Sock : PROXY-IP:5060 (0x8122f50)
Methods : 5695
next : 0x0
prev : 0x0
~~~/Contact~~~~
.../Record..
Now, what I don't understand is the two ports used above: 3280 and
3284. It looks like the phone thinks it is being natted to port 3280,
but it's really getting port 3284
When I make a call I get
U NAT-IP:3284 -> PROXY-IP:5060
INVITE sip:16509415674@sip.example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP NAT-IP:3280;branch=z9hG4bK4a4c039fbcb5bef8
From: "Grandstream"
<sip:frick@sip.example.com;user=phone>;tag=2dc2fc3c94e93951
To: <sip:16509415674@sip.example.com;user=phone>
Contact: <sip:frick@NAT-IP:3280;user=phone>
Supported: replaces
Call-ID: 1f04f9c6ec474f70(a)192.168.0.100
CSeq: 26381 INVITE
User-Agent: Grandstream BT100 1.0.6.7
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Type: application/sdp
Content-Length: 419
v=0
o=frick 8000 8002 IN IP4 NAT-IP
s=SIP Call
c=IN IP4 NAT-IP
t=0 0
m=audio 3295 RTP/AVP 0 8 4 18 2 15 97 9 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:15 G728/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/16000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
and my side sends back the Proxy Authentication Required, but it sends
it to port 3280. Now, is that based on the Via: header or the Contact:
header, or (unlikely) the stored contact info from the REGISTER?
The phone acts like it never got it (and I'm guessing it didn't) and
sends the INVITE again without any auth data.
The thing that bugs me is that this is an outbound call, from the
phone out through the NAT box, I figured that would be doable.
The Linksys942 works, so I'm hoping this is a Grandstream bug,
or something I can fix in my openser config.
Thanks,
-mark
24 Aug
24 Aug
12:21 p.m.
That's typical for grandstream. If a phone is behind sym NAT it should
not use public IP:port in the message, as they are wrong. The phone
should use private IP address to allow NAT traversal in the SIP proxy.
If you do NAT traversal for all clients, than it should not matter. But
if you do it only for NATed clients (using the nat detection tests),
then you might not detect that the grandstream requires NAT traversal.
regards
klaus
Mark Kent wrote:
I'm testing my rtpproxy config with a linksys
phone and a grandstream phone,
either not NAT'ed, or behind a cisco (full cone), or behind a Netgear (symmetric).
Things generally work, but I have a problem with the grandstream
behind the symmetric nat.
This is the register:
U NAT-IP:3284 -> PROXY-IP:5060
REGISTER sip:sip.example.com SIP/2.0
Via: SIP/2.0/UDP NAT-IP:3280;branch=z9hG4bK0103d0ff79cc9c02
From: "Grandstream"
<sip:frick@sip.example.com;user=phone>;tag=743335557afcade4
To: <sip:frick@sip.example.com;user=phone>
Contact: <sip:frick@NAT-IP:3280;user=phone>
Authorization: Digest username="frick", realm="sip.example.com",
algorithm=MD5, uri="sip:sip.example.com", nonce="foo",
response="bar"
Call-ID: 11f6defb0857db17(a)192.168.0.100
CSeq: 116 REGISTER
Expires: 60
User-Agent: Grandstream BT100 1.0.6.7
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Length: 0
This is the resulting contact:
...Record(0x2864b680)..
domain: 'location'
aor : 'frick(a)sip.example.com'
~~~Contact(0x2864d4e0)~~~
domain : 'location'
aor : 'frick(a)sip.example.com'
Contact : 'sip:frick@NAT-IP:3280;user=phone'
Expires : 34
q :
Call-ID : '11f6defb0857db17(a)192.168.0.100'
CSeq : 119
User-Agent: 'Grandstream BT100 1.0.6.7'
received : 'sip:NAT-IP:3284'
Path : ''
State : CS_SYNC
Flags : 1
Sock : PROXY-IP:5060 (0x8122f50)
Methods : 5695
next : 0x0
prev : 0x0
~~~/Contact~~~~
.../Record..
Now, what I don't understand is the two ports used above: 3280 and
3284. It looks like the phone thinks it is being natted to port 3280,
but it's really getting port 3284
When I make a call I get
U NAT-IP:3284 -> PROXY-IP:5060
INVITE sip:16509415674@sip.example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP NAT-IP:3280;branch=z9hG4bK4a4c039fbcb5bef8
From: "Grandstream"
<sip:frick@sip.example.com;user=phone>;tag=2dc2fc3c94e93951
To: <sip:16509415674@sip.example.com;user=phone>
Contact: <sip:frick@NAT-IP:3280;user=phone>
Supported: replaces
Call-ID: 1f04f9c6ec474f70(a)192.168.0.100
CSeq: 26381 INVITE
User-Agent: Grandstream BT100 1.0.6.7
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Type: application/sdp
Content-Length: 419
v=0
o=frick 8000 8002 IN IP4 NAT-IP
s=SIP Call
c=IN IP4 NAT-IP
t=0 0
m=audio 3295 RTP/AVP 0 8 4 18 2 15 97 9 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:15 G728/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/16000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
and my side sends back the Proxy Authentication Required, but it sends
it to port 3280. Now, is that based on the Via: header or the Contact:
header, or (unlikely) the stored contact info from the REGISTER?
The phone acts like it never got it (and I'm guessing it didn't) and
sends the INVITE again without any auth data.
The thing that bugs me is that this is an outbound call, from the
phone out through the NAT box, I figured that would be doable.
The Linksys942 works, so I'm hoping this is a Grandstream bug,
or something I can fix in my openser config.
Thanks,
-mark
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
7:21 p.m.
Klaus Darilion typed:
> If a phone is behind sym NAT it should not use
public IP:port in
> the message, as they are wrong. The phone should use private IP
> address to allow NAT traversal in the SIP proxy.
So, I take that to mean I should turn off NAT support (i.e., STUN) in
the Grandstream.
What's the general feeling about coding in openser.cfg to pick up the
various kinds of phones (I see an example looks for "Cisco ATA") and do
something different for each. I don't want to do it... this is more
of a "Best Common Practices" question.
> If you do NAT traversal for all clients, than it
should not matter.
I do...
Bogdan-Andrei Iancu wrote:
> you might consider using force_rport() function to
overcome the port
> problem - openser will use the received port instead of the one
> advertised in Via.
I use that, I'm using the template from the nathelper-rtpproxy config
that I emailed about a few days ago. I do it before t_relay(), I do it
in the REGISTER before the challenge, ... ooops, turns out I don't
do it before the challenge for INVITE. I'll give that a shot.
> include in your nat_uac_test() the flag 16 . see:
I'm not doing any testing, I'm forcing NAT behavior for all right now.
So... is there a problem with that? That is, is there a problem with
using all the NAT support features in nathelper, other than the tests,
even if the EndPoint is not NATed?
Thanks,
-mark
12:50 p.m.
Hi Mark,
you might consider using force_rport() function to overcome the port
problem - openser will use the received port instead of the one
advertised in Via.
also, if you have a script with nat traversal support, you should
include in your nat_uac_test() the flag 16 . see:
http://openser.org/docs/modules/1.1.x/nathelper.html#AEN369
regards,
bogdan
Mark Kent wrote:
I'm testing my rtpproxy config with a linksys phone
and a grandstream phone,
either not NAT'ed, or behind a cisco (full cone), or behind a Netgear (symmetric).
Things generally work, but I have a problem with the grandstream
behind the symmetric nat.
This is the register:
U NAT-IP:3284 -> PROXY-IP:5060
REGISTER sip:sip.example.com SIP/2.0
Via: SIP/2.0/UDP NAT-IP:3280;branch=z9hG4bK0103d0ff79cc9c02
From: "Grandstream"
<sip:frick@sip.example.com;user=phone>;tag=743335557afcade4
To: <sip:frick@sip.example.com;user=phone>
Contact: <sip:frick@NAT-IP:3280;user=phone>
Authorization: Digest username="frick", realm="sip.example.com",
algorithm=MD5, uri="sip:sip.example.com", nonce="foo",
response="bar"
Call-ID: 11f6defb0857db17(a)192.168.0.100
CSeq: 116 REGISTER
Expires: 60
User-Agent: Grandstream BT100 1.0.6.7
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Length: 0
This is the resulting contact:
...Record(0x2864b680)..
domain: 'location'
aor : 'frick(a)sip.example.com'
~~~Contact(0x2864d4e0)~~~
domain : 'location'
aor : 'frick(a)sip.example.com'
Contact : 'sip:frick@NAT-IP:3280;user=phone'
Expires : 34
q :
Call-ID : '11f6defb0857db17(a)192.168.0.100'
CSeq : 119
User-Agent: 'Grandstream BT100 1.0.6.7'
received : 'sip:NAT-IP:3284'
Path : ''
State : CS_SYNC
Flags : 1
Sock : PROXY-IP:5060 (0x8122f50)
Methods : 5695
next : 0x0
prev : 0x0
~~~/Contact~~~~
.../Record..
Now, what I don't understand is the two ports used above: 3280 and
3284. It looks like the phone thinks it is being natted to port 3280,
but it's really getting port 3284
When I make a call I get
U NAT-IP:3284 -> PROXY-IP:5060
INVITE sip:16509415674@sip.example.com;user=phone SIP/2.0
Via: SIP/2.0/UDP NAT-IP:3280;branch=z9hG4bK4a4c039fbcb5bef8
From: "Grandstream"
<sip:frick@sip.example.com;user=phone>;tag=2dc2fc3c94e93951
To: <sip:16509415674@sip.example.com;user=phone>
Contact: <sip:frick@NAT-IP:3280;user=phone>
Supported: replaces
Call-ID: 1f04f9c6ec474f70(a)192.168.0.100
CSeq: 26381 INVITE
User-Agent: Grandstream BT100 1.0.6.7
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Type: application/sdp
Content-Length: 419
v=0
o=frick 8000 8002 IN IP4 NAT-IP
s=SIP Call
c=IN IP4 NAT-IP
t=0 0
m=audio 3295 RTP/AVP 0 8 4 18 2 15 97 9 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:15 G728/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:9 G722/16000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
and my side sends back the Proxy Authentication Required, but it sends
it to port 3280. Now, is that based on the Via: header or the Contact:
header, or (unlikely) the stored contact info from the REGISTER?
The phone acts like it never got it (and I'm guessing it didn't) and
sends the INVITE again without any auth data.
The thing that bugs me is that this is an outbound call, from the
phone out through the NAT box, I figured that would be doable.
The Linksys942 works, so I'm hoping this is a Grandstream bug,
or something I can fix in my openser config.
Thanks,
-mark
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6671
days inactive
6671
days old
3 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Klaus Darilion -
Mark Kent