Trying to configure my AT&T ipFlex sip. They state the only thing needed in the PEER information is:
host=xxx.xxx.xxx.xxx
type=peer
With that configured, I can make call and receive calls … UNLESS the person I am calling also is using the ipFlex product. Then, on those calls (outbound from my system), there is a second INVITE that happens that makes my freepbx send a 481 BYE and ends that call in the AT&T system. I have added “canreinvite=no” (and “directmedia=no”, but that has made not change. It only seems to happen on outbound calls, if the person at that destination calls us back, it works fine.
Why are you using chan_sip? Switching to pjsip might avoid the issue, though if the AT&T side is statically configured, they will have to send calls to a different port (FreePBX defaults are pjsip on 5060 and chan_sip on 5160).
If you want to troubleshoot the chan_sip case, at the Asterisk command prompt type
sip set debug on
make a failing test call, paste the Asterisk log at pastebin.freepbx.org and post the link here.
As I understand it, the Re-INVITE is inbound. That is completely outside the control of Asterisk. 481 means that Asterisk didn’t recognize the call to which the Re-INVITE applied: e.g. a mismatch of Call-ID, from-tag or to-tag. That wouldn’t affect the call in Asterisk, because no call was recognized… I assume it is the peer that shut the call down because the Re-INVITE was rejected.
Although your case isn’t an outbound Re-INVITE, one of the main reasons why canreinvite was renamed was that it only applied to the use of Re-INVITE for direct media. Asterisk will also actively Re-INVITE for connected line presentation updates, and for session timer refreshes, so you also have to, for chan_sip, make sendrpid=no, and set session timers to refuse, to stop all outbound Re-INVITEs.
You are going to have fix inbound Re-INVITEs from the AT&T side, either by disabling the feature that is using them, or by getting it to send the right values in the Re-INVITE.
481 BYE is confusing, as chan_sip wouldn’t send that, it would send something like 481 Call/Transaction Does Not Exist. It cannot be sending a BYE after the 481 as that can only be sent for ones that do exist.
I just noticed on another thread you are running FreePBX 2.11. Is this the same system? If so, you not only don’t have pjsip available, but are likely running an old Asterisk with bugs associated with re-invite.
How does the IP Flex trunk come to you? Via a router port on a private network or via a ‘handoff’ ?
This is the SIP that at&t gave me. I have debug on now, but not when they sent this capture.
https://pastebin.freepbx.org/view/bc88378a
I have done another test call on my side and will post in the next message.
No. I have upgraded after that. FreePBX 15.0.17.34
Ip Flex is over fiber and the SIP channel is dedicated port on the AT&T router.
Without your original INVITE, it is impossible to say why the transaction wasn’t found. However, there is nothing you can do to stop the 481, if they send a Re-INVITE that doesn’t match the call.
Here is a more recent with SIP debug turned on (my side only / no att debug log)
https://pastebin.freepbx.org/view/ca0e5669
Line 8:
Call-ID: [email protected]:5160
So, it appears that you have chan_sip Bind Port 5160 (the default) but AT&T sent the re-invite to port 5060 where you presumably have pjsip listening, and pjsip rejected the re-invite because it’s a chan_sip call!
Either their system is just “assuming” that the SIP port is always 5060, or there is something subtle wrong with your config. A SIP trace including the original INVITE from you to them would show which side is wrong.
Would changing the truck to PJSIP solve the problem? How does one do a sip trace? Wireshark?
sip set debug on
or
pjsip set debug on
The main output is logged in the VERBOSE category.
You might need to specifically route 10.0.0.0/8 traffic (which is technically ‘non-routeable’ but the ip space of the IP Flex backbone) back through you 172. interface.
For now, leave your incoming alone and set up a trivial outbound-only pjsip trunk for testing.
Registration None
Authentication None
SIP Server 172.16.41.100
Change the Outbound Route to use this trunk and test.
1 Like
Although I agree that confusing the channel drivers is an issue here (although something else has to be wrong for it to break, and we need to see the Contact header in your output INVITE to know where that lies), as background information, it looks like the the AT&T is doing a session timer update.
Note I also agree that completely removing chan_sip from the picture is probably the best approach.
Most likely yes. Just change your trunk to chan_pjsip.
If the pjsip trunk still causes trouble, enable a SIP trace with
pjsip set logger on
and paste the log of a failing call. Please leave the ‘Delete After’ option at Keep Forever, so future readers of the thread can follow along.
Problem corrected when changing to pjsip trunk instead of sip.
2 Likes
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.