Audio: Asterisk-NAT-Internet-NAT-Asterisk

Asterisk Asterisk SIP
1

Hi,

Scenario:
Servers:
PBX-A ↔ NAT ↔ Internet ↔ NAT ↔ PBX-B

Client:
client ext. 1010 (192.168.1.5) ↔ PBX-A
client ext. 1015 (192.168.1.32) ↔ PBX-A

If PBX-A ext. 1010 dials an extension on PBX-B and then is transferred to PBX-A ext. 1015 will audio work, correctly? Or is there a problem related to the double (or triple) NAT?

If this scenario should work, I’ll post a detailed capture. I’m getting:
ast_play_and_record: No audio available on PJSIP/PBX-B-00000002??

2

Should work as long as both Asterisks have correct settings for public media addresses and local networks, and direct media is set to no or no-nat.

3

Here is the full capture of the fail (verbos=5, logger=on). I do have the public IP addresses set correctly and direct_media=no

File attached–too big for here.
Asterisk-log-1010-1015-noAudio-redacted.txt (45.9 KB)

4

I can’t see anything at the A end that would compromise the audio, although I’d note;

  • the B end is using an obsolete, and therefore unsupported, version of Asterisk;
  • the Publish has multiple, duplicate, Route headers;
  • this appears to be a screen scrape, not a log, as many time stamps are missing;
  • there isn’t enough verbosity to see what the dialplan is doing;
  • the subject doesn’t make it clear that the call crosses the internet twice;
  • the call from B to A is being answered before a chargeable call would need to be started.

Your probably need to add RTP debugging, as well as showing the picture at the other end.

5

Here are actual log files.
core set verbose 5
core set debug 5
rtp set debug on
pjsip set logger on
I tried to trim as much as possible. In the past I may have trimmed too much so I tried to err on the side of leaving extra.

Just FYI, this is the only problem reported. Everything else seems to be working (knock on wood).

PBXlogs.zip (70.1 KB)

6

B is sending the wrong public address; it is sending A’s.

[Jun  5 13:27:00] VERBOSE[267864] res_pjsip_logger.c: <--- Received SIP request (915 bytes) from UDP:PBX-B-pubIPaddr:5865 --->
INVITE sip:PBX-A-pvtIPaddr:5060 SIP/2.0
Via: SIP/2.0/UDP PBX-B-pubIPaddr:5865;branch=z9hG4bK0cf67466
Max-Forwards: 70
From: <sip:DID-in-PBX-A@PBX-B-pubIPaddr:5865>;tag=as6503ce4c
To: <sip:pbx-A-ext1010@PBX-A-pvtIPaddr:5060>;tag=7eea2bbf-816b-445a-a877-ceb5e7a577b4
Contact: <sip:DID-in-PBX-A@PBX-B-pubIPaddr:5865>
Call-ID: 6c203b9859699fd07adb679f04b17b54@PBX-B-pubIPaddr:5865
CSeq: 104 INVITE
User-Agent: Asterisk PBX 13.1.0~dfsg-1.1ubuntu4.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Type: application/sdp
Content-Length: 261

v=0
o=root 2086628017 2086628019 IN IP4 PBX-A-pubIPaddr
s=Asterisk PBX 13.1.0~dfsg-1.1ubuntu4.1
c=IN IP4 PBX-A-pubIPaddr
t=0 0
m=audio 21538 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
7

Scenario:
Servers:
PBX-A ↔ NAT ↔ Internet ↔ NAT ↔ PBX-B

Client:
client ext. 1010 (192.168.1.5) ↔ PBX-A
client ext. 1015 (192.168.1.32) ↔ PBX-A

o=root 2086628017 2086628019 IN IP4 PBX-A-pubIPaddr
s=Asterisk PBX 13.1.0~dfsg-1.1ubuntu4.1
c=IN IP4 PBX-A-pubIPaddr

Is this what I should be seeing?
o=root 2086628017 2086628019 IN IP4 PBX-A-pubIPaddr
s=Asterisk PBX 13.1.0~dfsg-1.1ubuntu4.1
c=IN IP4 PBX-B-pubIPaddr

I arranged setup of an ext on PBX-B that simply dials 1015 on PBX-A for testing such that:
On PBX-A I dial ext@PBX-B and PBX-B immediately dials 1015@PBX-A.

This means cliant-1 (ext. 1010) on PBX-A should connect to client-2 (ext. 1015) on PBX-A. This was the reason for my earlier question regarding double-NAT. And, doesnt this mean PBX-B should be sending something like:

o=root 2086628017 2086628019 IN IP4 192.168.1.32
s=Asterisk PBX 13.1.0~dfsg-1.1ubuntu4.1
c=IN IP4 192.168.1.5

Am I correct in guessing the two clients have to be connected via their private IP addresses? Or is this occurring at a “higher” level and somewhere underneath the IP addresses of the private-net clients are provided?

8

That’s what you should have.

Client B doesn’t know enough about your network topology to know that any 192.168 address will work, and, in any case, will have received no information concerning that address.