Two extensions on the same LAN but no audio

Asterisk Asterisk SIP
1

My asterisk is on a remote site behind an NAT router.

I have two extensions 3001 (192.168.7.32) and 3008 (192.168.7.93) on the same LAN in a separate site with external IP 176.156.223.236. These two extensions are registered to the asterisk.

My network works pretty well. These two extensions can call in and out, including via a SPA 3000 to the POTS world.

However, I now find that extensions 3001 and 3008 cannot hear one another. It’s odd because the log says “media will flow directly between them” and both end points are the local LAN IP addresses as shown below:

  == Using SIP RTP CoS mark 5
       > 0x16b8118 -- Strict RTP learning after remote address set to: 192.168.7.32:51376
    -- Executing [3008@from-internal:1] Answer("SIP/3001-000000ab", "") in new stack
       > 0x16b8118 -- Strict RTP qualifying stream type: audio
       > 0x16b8118 -- Strict RTP switching source address to 176.156.223.236:51376
    -- Executing [3008@from-internal:2] Dial("SIP/3001-000000ab", "SIP/3008,300") in new stack
  == Using SIP RTP CoS mark 5
    -- Called SIP/3008
    -- SIP/3008-000000ac is ringing
       > 0x1bfdab0 -- Strict RTP learning after remote address set to: 192.168.7.93:43554
    -- SIP/3008-000000ac answered SIP/3001-000000ab
    -- Channel SIP/3008-000000ac joined 'simple_bridge' basic-bridge <faa8a1ff-d74d-4b31-8f32-6123b148675b>
    -- Channel SIP/3001-000000ab joined 'simple_bridge' basic-bridge <faa8a1ff-d74d-4b31-8f32-6123b148675b>
       > Bridge faa8a1ff-d74d-4b31-8f32-6123b148675b: switching from simple_bridge technology to native_rtp
       > Remotely bridged 'SIP/3001-000000ab' and 'SIP/3008-000000ac' - media will flow directly between them
       > 0x1bfdab0 -- Strict RTP qualifying stream type: audio
       > 0x1bfdab0 -- Strict RTP learning after remote address set to: 192.168.7.93:43554
       > 0x16b8118 -- Strict RTP learning after remote address set to: 192.168.7.32:51376

What could be the cause of the problem? Is the problem local to something in the 192.168.7.x LAN or could it be due to configuration in sip.conf?

2

You mean devices, not extensions.

We’d need to see the SDP exchange to be sure, but your logging says that the two devices have been told to talk to each other directly. If they have accepted those requests, the problem lies outside Asterisk.

I would note, though, that the devices don’t seem to be NAT aware, so if audio worked before the remote bridge, it is because you were using one of the workaround options for dealing with non-NAT aware devices (nar=comedia). This shouldn’t affect it after the remote bridge. A NAT aware device would have provided the public address for media.

3

Thanks.

I am using nat=comedia and it works for the other more “complicated” scenarios:

  • from local device to a remote device
  • from a remote device to a local SPA 3000
  • (incoming call on FXO port of ) local SPA 3000 to a remote device

where local means on the same LAN as the asterisk, and remote means in a different site passing through two NAT routers and is registered to the same asterisk.

3001 and 3008 are configured using this template:

[template-1](!)
dtmfmode=rfc2833
context=from-internal
type=friend
callcounter=yes

3001 is an X-Lite softphone on my PC, and 3008 is Zopier app on my Android phone. What do you mean by not NAT-aware?

How do I see the SDP exchange?

4

A NAT aware phone knows it is behind NAT and knows, or knows how to find its public address. Your phones are giving out a private address, even though they are talking to Asterisk which is outside the NAT boundary. In that context, a NAT aware phone would have send its public address.

To see the SDP exchange, given that you are using chan_sip, use the CLI command “sip set debug on”, and make sure you have a log file enabled for VERBOSE logging. Additional information is provided in the DEBUG log channel.

Please don’t include irrelevant transactions like REGISTER and OPTIONS, as it takes time to plough through them, and many people end up only providing those,not the INVITE/200 OK pairs, which contain the useful information.