I have followed the instructions here, but the custom context is simply ignored it seems.
The issue I’m having is that for some reason the sip extensions are always using the one sip context regardless of the did they actually come in on.
– Executing [xxxxxx9794@from-trunk-sip-xxxxx9510:1] Set(“SIP/xxxxx9510-0000002b”, “GROUP()=OUT_13”) in new stack
– Executing [xxxxxx9794@from-trunk-sip-xxxxxx9510:2] Goto(“SIP/xxxxx9510-0000002b”, “from-trunk,xxxxx9794,1”) in new stack
– Goto (from-trunk,xxxxx9794,1)
– Executing [xxxxxx9794@from-trunk:1] Set(“SIP/xxxxxx9510-0000002b”, “__FROM_DID=xxxxxx9794”) in new stack
etc…
as you can see… the from-trunk is the correct number, but the instructions are always from the 9510 extension regardless of which DID the call actually comes from.
This wasn’t a problem in 1.5 (this is a 1.6 system) and I have tried changing the inbound context in both peer and user to be something else (just to see if it would work) but nothing changes.
Before you get too carried away here, please make sure that the call really is failing in some way. I’ve seen this happen before, where you have multiple trunks from one provider but the channel identifier will always show a DID of only one of those. The thing to remember is that this is just a temporary channel identifier and in no way affects the actual call flow, but it is confusing when you are trying to trace a call and see the “incorrect” DID in the channel identifier string. However, the ONLY purpose of that number is to keep track of the various active calls in the system, and apparently Asterisk uses a DID assigned to the provider (though not necessarily that particular call) plus a sequence number that resets to 00000000 whenever Asterisk is restarted. AFAIK the channel identifier is totally meaningless except for keeping the calls separate, so unless calls really are being mis-routed you shouldn’t worry about what appears there.
The issue isn’t that the calls are failing in this case. We have some software that needs to know what DID the call came in from to make some decisions behind the scenes so to speak.
If this isn’t possible then I think we have some issues.
1.8 still shows the same behavior. The flash panel shows the wrong trunk calling.
I have two trunks configured going to different extensions. The calls work fine, but the panel and cli show the calls all coming from the trunk with the lowest number configured.
This is a problem for our app.
Is this a bug with asterisk, freepbx?? Who should I send the bug report to?