thr3ads.net - asterisk users - [Asterisk-Users] Asterisk + BudgeTone (behind NAT) [Jan 2004]

If this information is useful, please help other people find it:
Share via:

Owen Kelso

2004-Jan-10 16:07 UTC

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

I'm using Asterisk on a open server (no firewall or NAT) and trying to
communicate with a Grandstream BudgeTone 102 SIP phone which is behind
NAT. The BudgeTone is at firmware level 1.0.4.30 and Asterisk is from CVS
about a week ago.  My problem is that I'm only getting half-duplex
communication -- I can hear voice from the Asterisk server but the server
does not understand any voice from me.  From the console "sip debug"
shows
that the SIP part is working fine and DTMF via SIP INFO works.

I've struggled with this for a few days now and can't figure out the
cause.  The only symptoms I've found are:

(1) When I make a call the console spits out the following errors several
times per minute:
WARNING[-1220854864]: File rtp.c, Line 375 (ast_rtp_read): RTP Read error:
Resource temporarily unavailable

(2) An ethereal trace reveals that incoming RTP packets have failed UDP
checksums (all packets have the same checksum of 0xb38f).  I don't see
anything else irregular, like unreachable ports.

My sip.conf contains:
[test]
type=friend
username=test
secret=12345
host=dynamic
nat=yes
qualify=1000
dtmfmode=info
disallow=all
allow=ulaw
allow=alaw
canreinvite=no

On the NAT'ed side I have the BudgetTone set up to use STUN and ports 5060
for SIP and 19000 for RTP.  The firewall that performs NAT forwards ports
5060 and 19000-19100 UDP to the phone.

An ethereal snapshot looks like:

1.1.1.1 = Asterisk server
2.2.2.2 = Public IP where the BudgeTone is
10.0.3.205 = Private IP of BudgeTone

Frame 211 (214 bytes on wire, 214 bytes captured)
Ethernet II, Src: 00:06:29:ce:5f:f2, Dst: 00:01:c7:0b:70:22
    Destination: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
    Source: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 1.1.1.1 (1.1.1.1), Dst Addr: 2.2.2.2 (2.2.2.2)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 200
    Identification: 0x0000 (0)
    Flags: 0x04
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x2538 (correct)
    Source: 1.1.1.1 (1.1.1.1)
    Destination: 2.2.2.2 (2.2.2.2)
User Datagram Protocol, Src Port: 13364 (13364), Dst Port: 19000 (19000)
    Source port: 13364 (13364)
    Destination port: 19000 (19000)
    Length: 180
    Checksum: 0xdf43 (correct)
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    .000 1000 = Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 45554
    Timestamp: 16480
    Synchronization Source identifier: 1847249288
    Payload: E4E4E5FAF9FDF0F6F5C2C5DFD0575D58...

Frame 212 (214 bytes on wire, 214 bytes captured)
Ethernet II, Src: 00:01:c7:0b:70:22, Dst: 00:06:29:ce:5f:f2
    Destination: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
    Source: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1 (1.1.1.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 200
    Identification: 0xe398 (58264)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 233
    Protocol: UDP (0x11)
    Header checksum: 0xd89e (correct)
    Source: 2.2.2.2 (2.2.2.2)
    Destination: 1.1.1.1 (1.1.1.1)
User Datagram Protocol, Src Port: 19000 (19000), Dst Port: 13364 (13364)
    Source port: 19000 (19000)
    Destination port: 13364 (13364)
    Length: 180
    Checksum: 0xb38f (incorrect, should be 0x1dc4)
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    .000 1000 = Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 53058
    Timestamp: 3449661727
    Synchronization Source identifier: 3820906983
    Payload: D4D4D5D5D555D5D555D4D5D5D5D4D4D4...

Frame 213 (214 bytes on wire, 214 bytes captured)
Ethernet II, Src: 00:06:29:ce:5f:f2, Dst: 00:01:c7:0b:70:22
    Destination: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
    Source: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 1.1.1.1 (1.1.1.1), Dst Addr: 2.2.2.2 (2.2.2.2)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 200
    Identification: 0x0000 (0)
    Flags: 0x04
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x2538 (correct)
    Source: 1.1.1.1 (1.1.1.1)
    Destination: 2.2.2.2 (2.2.2.2)
User Datagram Protocol, Src Port: 13364 (13364), Dst Port: 19000 (19000)
    Source port: 13364 (13364)
    Destination port: 19000 (19000)
    Length: 180
    Checksum: 0xa9d4 (correct)
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    .000 1000 = Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 45555
    Timestamp: 16640
    Synchronization Source identifier: 1847249288
    Payload: 76767671707071717176744A494C4158...

Frame 214 (214 bytes on wire, 214 bytes captured)
Ethernet II, Src: 00:01:c7:0b:70:22, Dst: 00:06:29:ce:5f:f2
    Destination: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
    Source: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1 (1.1.1.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 200
    Identification: 0xe399 (58265)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 233
    Protocol: UDP (0x11)
    Header checksum: 0xd89d (correct)
    Source: 2.2.2.2 (2.2.2.2)
    Destination: 1.1.1.1 (1.1.1.1)
User Datagram Protocol, Src Port: 19000 (19000), Dst Port: 13364 (13364)
    Source port: 19000 (19000)
    Destination port: 13364 (13364)
    Length: 180
    Checksum: 0xb38f (incorrect, should be 0xa92e)
Real-Time Transport Protocol
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 .... = Extension: False
    .... 0000 = Contributing source identifiers count: 0
    0... .... = Marker: False
    .000 1000 = Payload type: ITU-T G.711 PCMA (8)
    Sequence number: 53059
    Timestamp: 3449661887
    Synchronization Source identifier: 3820906983
    Payload: D5D4D7D7D4D4D4D5D5D5555555555454...

Anyone have ideas?

Thanks,
Owen

Arnd Vehling

2004-Jan-10 17:49 UTC

head link

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

Hi,

thats very probably a NAT problem. Your NAT box is probaly blocking
the incoming UDP voice stream. 

If asteriks supports a RTP Proxy you can try that.

best regards,

  Arnd

Chandra

2004-Jan-10 19:22 UTC

head link

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

i also had the same problem.... temporarily i solved my problem with both
outside NAT. u can also do it if both inside NAT. * outside NAT and
Budgetone behind NAT simply doesn't seem to work. if u ever solve this
problem please let me know too.

thanks

cm

----- Original Message -----
From: "Owen Kelso" <owen@barkie.net>
To: <asterisk-users@lists.digium.com>
Sent: Sunday, January 11, 2004 4:52 AM
Subject: [Asterisk-Users] Asterisk + BudgeTone (behind NAT)

> I'm using Asterisk on a open server (no firewall or NAT) and trying to
> communicate with a Grandstream BudgeTone 102 SIP phone which is behind
> NAT. The BudgeTone is at firmware level 1.0.4.30 and Asterisk is from CVS
> about a week ago.  My problem is that I'm only getting half-duplex
> communication -- I can hear voice from the Asterisk server but the server
> does not understand any voice from me.  From the console "sip
debug" shows
> that the SIP part is working fine and DTMF via SIP INFO works.
>
> I've struggled with this for a few days now and can't figure out
the
> cause.  The only symptoms I've found are:
>
> (1) When I make a call the console spits out the following errors several
> times per minute:
> WARNING[-1220854864]: File rtp.c, Line 375 (ast_rtp_read): RTP Read error:
> Resource temporarily unavailable
>
> (2) An ethereal trace reveals that incoming RTP packets have failed UDP
> checksums (all packets have the same checksum of 0xb38f).  I don't see
> anything else irregular, like unreachable ports.
>
> My sip.conf contains:
> [test]
> type=friend
> username=test
> secret=12345
> host=dynamic
> nat=yes
> qualify=1000
> dtmfmode=info
> disallow=all
> allow=ulaw
> allow=alaw
> canreinvite=no
>
> On the NAT'ed side I have the BudgetTone set up to use STUN and ports
5060
> for SIP and 19000 for RTP.  The firewall that performs NAT forwards ports
> 5060 and 19000-19100 UDP to the phone.
>
> An ethereal snapshot looks like:
>
> 1.1.1.1 = Asterisk server
> 2.2.2.2 = Public IP where the BudgeTone is
> 10.0.3.205 = Private IP of BudgeTone
>
> Frame 211 (214 bytes on wire, 214 bytes captured)
> Ethernet II, Src: 00:06:29:ce:5f:f2, Dst: 00:01:c7:0b:70:22
>     Destination: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
>     Source: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
>     Type: IP (0x0800)
> Internet Protocol, Src Addr: 1.1.1.1 (1.1.1.1), Dst Addr: 2.2.2.2
(2.2.2.2)>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 200
>     Identification: 0x0000 (0)
>     Flags: 0x04
>     Fragment offset: 0
>     Time to live: 64
>     Protocol: UDP (0x11)
>     Header checksum: 0x2538 (correct)
>     Source: 1.1.1.1 (1.1.1.1)
>     Destination: 2.2.2.2 (2.2.2.2)
> User Datagram Protocol, Src Port: 13364 (13364), Dst Port: 19000 (19000)
>     Source port: 13364 (13364)
>     Destination port: 19000 (19000)
>     Length: 180
>     Checksum: 0xdf43 (correct)
> Real-Time Transport Protocol
>     10.. .... = Version: RFC 1889 Version (2)
>     ..0. .... = Padding: False
>     ...0 .... = Extension: False
>     .... 0000 = Contributing source identifiers count: 0
>     0... .... = Marker: False
>     .000 1000 = Payload type: ITU-T G.711 PCMA (8)
>     Sequence number: 45554
>     Timestamp: 16480
>     Synchronization Source identifier: 1847249288
>     Payload: E4E4E5FAF9FDF0F6F5C2C5DFD0575D58...
>
> Frame 212 (214 bytes on wire, 214 bytes captured)
> Ethernet II, Src: 00:01:c7:0b:70:22, Dst: 00:06:29:ce:5f:f2
>     Destination: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
>     Source: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
>     Type: IP (0x0800)
> Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1
(1.1.1.1)>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 200
>     Identification: 0xe398 (58264)
>     Flags: 0x00
>     Fragment offset: 0
>     Time to live: 233
>     Protocol: UDP (0x11)
>     Header checksum: 0xd89e (correct)
>     Source: 2.2.2.2 (2.2.2.2)
>     Destination: 1.1.1.1 (1.1.1.1)
> User Datagram Protocol, Src Port: 19000 (19000), Dst Port: 13364 (13364)
>     Source port: 19000 (19000)
>     Destination port: 13364 (13364)
>     Length: 180
>     Checksum: 0xb38f (incorrect, should be 0x1dc4)
> Real-Time Transport Protocol
>     10.. .... = Version: RFC 1889 Version (2)
>     ..0. .... = Padding: False
>     ...0 .... = Extension: False
>     .... 0000 = Contributing source identifiers count: 0
>     0... .... = Marker: False
>     .000 1000 = Payload type: ITU-T G.711 PCMA (8)
>     Sequence number: 53058
>     Timestamp: 3449661727
>     Synchronization Source identifier: 3820906983
>     Payload: D4D4D5D5D555D5D555D4D5D5D5D4D4D4...
>
> Frame 213 (214 bytes on wire, 214 bytes captured)
> Ethernet II, Src: 00:06:29:ce:5f:f2, Dst: 00:01:c7:0b:70:22
>     Destination: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
>     Source: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
>     Type: IP (0x0800)
> Internet Protocol, Src Addr: 1.1.1.1 (1.1.1.1), Dst Addr: 2.2.2.2
(2.2.2.2)>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 200
>     Identification: 0x0000 (0)
>     Flags: 0x04
>     Fragment offset: 0
>     Time to live: 64
>     Protocol: UDP (0x11)
>     Header checksum: 0x2538 (correct)
>     Source: 1.1.1.1 (1.1.1.1)
>     Destination: 2.2.2.2 (2.2.2.2)
> User Datagram Protocol, Src Port: 13364 (13364), Dst Port: 19000 (19000)
>     Source port: 13364 (13364)
>     Destination port: 19000 (19000)
>     Length: 180
>     Checksum: 0xa9d4 (correct)
> Real-Time Transport Protocol
>     10.. .... = Version: RFC 1889 Version (2)
>     ..0. .... = Padding: False
>     ...0 .... = Extension: False
>     .... 0000 = Contributing source identifiers count: 0
>     0... .... = Marker: False
>     .000 1000 = Payload type: ITU-T G.711 PCMA (8)
>     Sequence number: 45555
>     Timestamp: 16640
>     Synchronization Source identifier: 1847249288
>     Payload: 76767671707071717176744A494C4158...
>
> Frame 214 (214 bytes on wire, 214 bytes captured)
> Ethernet II, Src: 00:01:c7:0b:70:22, Dst: 00:06:29:ce:5f:f2
>     Destination: 00:06:29:ce:5f:f2 (Ibm_ce:5f:f2)
>     Source: 00:01:c7:0b:70:22 (Cisco_0b:70:22)
>     Type: IP (0x0800)
> Internet Protocol, Src Addr: 2.2.2.2 (2.2.2.2), Dst Addr: 1.1.1.1
(1.1.1.1)>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
> Total Length: 200
>     Identification: 0xe399 (58265)
>     Flags: 0x00
>     Fragment offset: 0
>     Time to live: 233
>     Protocol: UDP (0x11)
>     Header checksum: 0xd89d (correct)
>     Source: 2.2.2.2 (2.2.2.2)
>     Destination: 1.1.1.1 (1.1.1.1)
> User Datagram Protocol, Src Port: 19000 (19000), Dst Port: 13364 (13364)
>     Source port: 19000 (19000)
>     Destination port: 13364 (13364)
>     Length: 180
>     Checksum: 0xb38f (incorrect, should be 0xa92e)
> Real-Time Transport Protocol
>     10.. .... = Version: RFC 1889 Version (2)
>     ..0. .... = Padding: False
>     ...0 .... = Extension: False
>     .... 0000 = Contributing source identifiers count: 0
>     0... .... = Marker: False
>     .000 1000 = Payload type: ITU-T G.711 PCMA (8)
>     Sequence number: 53059
>     Timestamp: 3449661887
>     Synchronization Source identifier: 3820906983
>     Payload: D5D4D7D7D4D4D4D5D5D5555555555454...
>
> Anyone have ideas?
>
> Thanks,
> Owen
>
>
>
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
>

Paul Liew

2004-Jan-10 21:40 UTC

head link

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

From: "Owen Kelso" <owen@barkie.net>
Sent: Sunday, January 11, 2004 10:07 AM
Subject: [Asterisk-Users] Asterisk + BudgeTone (behind NAT)

>
> On the NAT'ed side I have the BudgetTone set up to use STUN and ports
5060
> for SIP and 19000 for RTP.  The firewall that performs NAT forwards ports
> 5060 and 19000-19100 UDP to the phone.
Hi Owen,

Even though your GS is behind a NAT, it shouldn't be set for STUN unless
you're actually using a STUN server. I have GS installed in many locations
behind a NAT but without the STUN option set.

Paul

Steve

2004-Jan-11 17:24 UTC

head link

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

On Saturday 10 January 2004 06:07 pm, Owen Kelso wrote:> I'm using Asterisk on a open server (no firewall or NAT) and trying to
> communicate with a Grandstream BudgeTone 102 SIP phone which is behind
> NAT. The BudgeTone is at firmware level 1.0.4.30 and Asterisk is from CVS
> about a week ago.  My problem is that I'm only getting half-duplex
> communication -- I can hear voice from the Asterisk server but the server
> does not understand any voice from me.  From the console "sip
debug" shows
> that the SIP part is working fine and DTMF via SIP INFO works.

I use OpenBSD firewalls with NAT and redirect and it works just as it's 
supposed to. 

That's not even half duplex. In half duplex each side Can talk, but only one
at a time. It seems to be an error with configuring your firewall. (One 
common error is to only turn on redirect. But you also need to Allow the 
traffic to flow...

-- 
Steve

__________________________________________________
You actually need to constantly be alert 
 and willing to handle things, or life 
   will find a way to get you good!

Owen Kelso

2004-Jan-11 21:06 UTC

head link

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

Thanks for all of your responses.

I confirmed that the phone works perfectly without NAT or through a IPSec
VPN (yeah, I know, same thing).

I've concluded that the Netgear router (FVS318) performing the NAT is
corrupting the outgoing RTP packets.  Traces confirmed that the BudgeTone
is sending them out with a UDP checksum of 0 but the next hop after the
Netgear router they are set to a non-zero value (an incorrect one). 
Asterisk is never even seeing the packets because the kernel is
recognizing them as corrupt and dropping them, hence the recvfrom()
"Resource temporarily unavailable" errors in rtp.c.

I'm going to write Netgear to see what they have to say about it.  If I
make any progress I'll post to the list...thanks again, Owen

Apparently Analagous Threads

Search for more reasonably related threads

asterisk users - Jan 2004 - Asterisk + BudgeTone (behind NAT)

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

[Asterisk-Users] Asterisk + BudgeTone (behind NAT)

Apparently Analagous Threads