This is a workaround that I found that is OK for my situation, but I'd generally consider it a gross hack. I found this gem in chan_sip.c:
/* Always OK if no secret */
if (ast_strlen_zero(secret) && ast_strlen_zero(md5secret))
return AUTH_SUCCESSFUL;
So, my workaround is to put:
secret=
In the config for each extension. This is OK for me because I'm not worried about someone on my network trying to register for an extension that isn't theirs. In general, however, it's totally insecure because it bypasses any further authentication (including my issue with the username mismatch).
With SIP, the signaling is done via SIP and the digitized audio is sent via a different protocol, RTP. The SIP and RTP can and often are sent to different IP addresses. Thats normally not a problem, as long as the IP addresses are all reachable..
Whats happening in your situation, is something like this:
PBX2 sends a SIP INVITE to PBX1. Included in that INVITE is information about where to send the audio. PBX2 specifies its own IP address. Since its IP address is reachable from PBX1, calls between the two work.
Now, when the callee is an outside line, PBX1 sends its own INVITE to your provider, and passes on in that INVITE the information about where to send the audio (ie, the IP address of PBX2) If both PBXs were on public IPs, this would be fine. Since they are not both reachable from the outside, you need to modify the behavior of PBX1
On PBX1, in your sip.conf file, there should be a peer configuration for PBX2. In that peer configuration, you need to add the following line:
canreinvite=no
(On more recent versions of asterisk, you would use directmedia=no instead.)
This will cause PBX1 to stay in the media path whenever it is involved with a call with PBX2. In otherwords, when you call the outside world, PBX1 will give your provider its own IP address for where to send the audio, it will then proxy that audio, and send it on to PBX2.
Hope this helps!
Best Answer
Here is what's going on. This explanation is geared toward Red Hat derived systems:
The server's startup scripts execute in a particular sequence, with some scripts depending on others completing successfully.
In the case of asterisk, it requires (or should require) that the network be up before starting. You'll see this in the init script as a line like:
where
$networkis present.The problem is that by default the network is considered "up" if IPv4 configuration completes, even if IPv6 configuration does not complete.
To change this behavior, edit
/etc/sysconfig/network-scripts/ifcfg-eth0(or your particular interface) to specify that IPv6 must also come up:Note that only NetworkManager pays attention to this setting, so if you've disabled NetworkManager and are using the old network script, it will be ignored. You can also make the equivalent setting in the NetworkManager GUI.