Outbound call uses the wrong SIP trunk

[SteveITS]

Debian
18.0.1880 Standard (new install from ISO, originally as 18RC2)
Hosted in KVM
Testing from web client
Trunk provider GreenLink (set as a generic trunk; but we have multiple installs using them)

This new client has two locations. My original plan was to use an E911 rule and send a different caller ID that way. GreenLink says their policy is to have a separate trunk for each location so I set that up, with its own E911 outbound rule. So there are now two trunks, named Office and E911. Each trunk has its own login/password. For ease of testing I also set up an outbound rule for calls from my test ext 000 to go out the second trunk. Both trunks are registered.

sip.aa.greenlinknetworks.net is an SRV record that (_sip._udp.sip.aa.greenlinknetworks.net) refers to aa01.greenlinknetworks.net and aa02.greenlinknetworks.net. aa01.greenlinknetworks.net is preferred so that's the established connection.

If both the Office and E911 trunks are set to use sip.aa.greenlinknetworks.net, with different credentials, and I make a call from 000, the Activity log (Medium) shows the call matching the outbound rule, and using the E911 trunk. However GreenLink says the call connects through their system using the Office trunk, and thus the call has the wrong caller ID at the remote end.

If I set the E911 trunk to use aa01.greenlinknetworks.net, same thing...the outbound call connects to them using the (incorrect) Office trunk.

If I set the E911 trunk to use aa02.greenlinknetworks.net, the log shows the same thing but it connects to them using the (correct) E911 trunk. I can change the E911 trunk between aa01 and aa02 and reproduce the problem at will.

Note that I can also reproduce this by setting both trunks to aa02.greenlinknetworks.net. It only "works correctly" if they are different.

I am rather confused about this. Could it be that 3CX is seeing an already open connection to the IP of aa01.greenlinknetworks.net and using that, even though it should be using the second trunk (connecting to the same IP)?

For the time being we can set the E911 trunk to use aa02, which seems like it will work until the primary trunk fails over someday, in which case one of them will have the wrong caller ID.

TL,DR: does 3CX differentiate between two SIP trunks with active connections to the same SIP server?

 

[leejor]

You can confirm in the 3CX Activity Log which rule 3CX is using. Keep in mind that outbound rules are matched from the top down, with the first match being used. Could it be, that the order of your rules, needs "adjusting"?

 

[NickD_3CX]

Could it be that 3CX is seeing an already open connection to the IP of aa01.greenlinknetworks.net and using that, even though it should be using the second trunk (connecting to the same IP)?

Hi!

I'd first check what leejor suggested.
However to answer your question, with this provider there is no concept of "connection" because from what I can see, their SRVs only have UDP:


To have "connections", it would have to be over TCP, which is not the case.

You can easily check though with a quick Packet Capture from the 3CX Management Console:

1. De-register your 2 SIP Trunks (I usually just slightly alterate the registrar to something invalid)
2. Open a new tab and log into the Management Console again and start the packet capture
3. From the first browser tab, re-register your SIP Trunks.
4. Wait 5-10 seconds stop the capture and open it in Wireshark
5. Look for REGISTER messages using filter: sip.CSeq.method==REGISTER
6. You should see 2, and each one have a different "Call-ID" value. This is the main way how UDP SIP Dialogs are differentiated.

 

[SteveITS]

You can confirm in the 3CX Activity Log which rule 3CX is using

Right, I noted it was using the correct trunk per the activity log. That's why we're all confused, since they say it's not, as it's going through their system.

Nick, I'll try the registration/capture, but will need to wait until end of day.

 

[NickD_3CX]

Right, I noted it was using the correct trunk per the activity log. That's why we're all confused, since they say it's not, as it's going through their system.

Nick, I'll try the registration/capture, but will need to wait until end of day.

One more thing I just thought of is how they determine which of the 2 Trunks to assign a call to that they receive from the PBX.
It may be worth asking them if they are doing this based on the Caller ID you are presenting outbound.

To elaborate a bit. 3CX is sending the call out from the correct trunk as you confirmed, but on their side, they just see an INVITE arriving from an IP address, from which they have 2 valid Registrations (assuming both work correctly), both from the same port.

How do they know how to allocate the call? It is possible that you may have to play with the custom parameters to maybe include the username/Auth ID in some field, or maybe the main trunk number, so something for them to be able to make this distinctions.

OK, you've been around the forums enough so I didn't lead with this, but alternatively you could use a support provider with which you usually don't have such issues.

 

[SteveITS]

"Registration" was probably a better word to use than "connection" in my OP.

Capture shows unique Call-ID fields for each trunk's REGISTER, and for a call shows the right caller ID on From and Remote-Party-ID. I've bounced it back to them. I suspect you're right that they're seeing the call from the IP: port, but then they shouldn't insist on a separate trunk for this, since as we know 3CX has the outbound E911 rules.

Not that I like beating my head against walls (unsupported trunks), but I try to use these as good learning opportunities, to understand the guts of various systems involved. Documentation has all the expected answers. Forums have all the unexpected issues. Thanks for the help.