Queue extension number overriding callers number in logs

I have an odd problem that I can’t seem to get my head around.

I have two different trunks.One is a trunk that uses IP authentication, the other one registers with the SIP provider using a username and password. We have just added the trunk that uses IP authentication as our provider has moved away from traditional copper lines.

When a call comes in on either trunk, the inbound route for them directs each of them to the same place and they work exactly the same except it’s two different numbers from two different providers.

The calls route to the phone handsets like this:

Call comes in on trunk > Goes to override condition (Force phones to ring on/off) > Goes to time conditions (Office open/closed) > Goes to Queue (300: Incoming sales calls).

Everything works fine at the phone end of things, irrespective of which trunk the call comes in on, calls come in. Caller ID is passed at all stages of the call correctly (Using PAI), the phones see the callers ID along with the CID prefixes we add. The phones work as expected.

However, in the case of the trunk that uses IP authentication (Or IP trust if thats the correct term), the call logs are being recorded very strangely.

What SHOULD happen is the call type is reflected as “In”, the source is the caller ID of the incoming caller, and the destination is either the DID of the trunk or the SIP providers internal extension.

Instead, what we are seeing is the call type is appearing as “External”, and the source of the call as being the number of the queue (300) instead of the incoming callers ID, and the destination as the agents extension number that actually handled the call. This is definitely not a desirable situation.

Additionally, it is generating call record logs and empty, 0 second call recordings to all the other agents phones in the queue that follow the same logged format. Only the agent who answered the call actually gets the call audio recorded.

Yet oddly, on calls that come in through the trunk that uses username/password registration, the calls are correctly classified as “In” on the call type, and the caller ID is passed correctly as the source and the destination is shown correctly as that sip providers trunk extension (Which is expected as they do not pass the DID but instead the trunks extension number on their system). In other words its working exactly as I expect it to.

Here is the relevant trunk sip settings for the trunk that is using IP authentication and not logging the calls correctly. For privacy reasons I have obscured identifiable details…

[OUTGOING TRUNK NAME]
SIPPROVIDER-MAINNUMBER

[OUTGOING PEER DETAILS]
type=peer
fromuser=12345678901
fromdomain=123.123.123.123
host=321.321.321.321
dtmfmode=rfc2833
canreinvite=no
insecure=invite
qualify=no
disallow=all
allow=ulaw,alaw

[INCOMING USER CONTEXT]
12345678901

[INCOMING USER DETAILS]
type=peer
fromuser=12345678901
fromdomain=123.123.123.123
host=321.321.321.321
dtmfmode=rfc2833
canreinvite=no
insecure=invite
qualify=no
disallow=all
allow=ulaw,alaw
context=from-trunk

[REGISTER STRING]
***empty***

Call recording is forced at the inbound route stage.

I am at a total loss to understand how this might be occurring if the phones are getting the correct incoming caller ID information? Any pointers would be of huge help if anyone can see where it might be going wrong.

Many thanks for your help.

This sounds like a context mismatch. I think pasting a dump of the INVITEs would help narrow it down. Or at least a short snippet from Asterisk logs in /var/log/asterisk/full or /var/log/asterisk/messages files showing the start of the calls and how they enter your dial plan.

The incoming context is normally “from-sip” (or some other “from-similar” context). If 12345678901 is one of the phone numbers in your system, the context entry could be sending the call to your system “as if” it was being initiated on your machine.

Apologies for the delay in replying.

I note the context issue. The advice from my SIP trunk provider was to set this to the line DID, however I will try that experimentally as I am sure if it is wrong it is likely causing other issues I have not noticed.

However the really weird thing is the issue resolved itself somehow.

I did not do anything, change anything, stop or restart anything. It just started working as expected and the calls suddenly started getting logged/recorded correctly with the correct details and the zero length call recordings stopped.

I am somewhat befuddled as to how but the issue appears resolved. ¯\_(ツ)_/¯

Many thanks for the suggestions and help offered.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.