Inbound Calls fail with 3 x Sip trunks registered


#1

Hi All

( ip address and phone numbers are examples not live details)
I have a UCM 6302 local ip of 192.168.0.63:5060 behind a nat router with a staic facing public ip 88.88.88.88

I have 3 sip trunks which are all registered
contact header = phonenumber@publicfacingIP:port5060

ProviderA (open sips) contact header = 1111111111@88.88.88.88:5060 ( Inbound route _1111111111 exact match)
ProviderB (Porta1) contact header = 2222222222@88.88.88.88:5060 (Inbound route _2222222222 exact match)
ProviderC (porta1) COntact header = 3333333333@88.88.88.88:5060 (Inbound route _333333333 exact match)

Outbound call works with all 3 sip tunks
Inbound calls ( invite from provider to PABX)

providerA(opensips) => incoming call 1111111111@88.88.88.88:5060 => invite to UCM6302 192.168.0.63:5060 => invite to extenison 1004@192.168.0.104 phone rings Inbound call succeeds

providerB(porta1) => incoming call 2222222222@88.88.88.88:506 => Invite to UCM6302 192.168.0.63:5060 ( provider confirms INVITE is reaching UCM 6302) multiple invites form provider
UCM cannot see the DID ( Request LINE) and the inbound call fails

ProviderC(porta1) => Incoimng calls same result has above explantion.

The fact that all trunks are registered with the same Ip and port should not be an issue the DID is mapped to the trunk and the UCM should see this DID in the request line and fwd Invite to the corresponding trunk but this is not happening. I tested this on a UCM 6510 (1.0.20.38) and it works with 2 trunks registered at once with no issue.
but on UCM 6302 (1.0.7.12) this fails

I have a ticket opened but any input will be appreciated can’t ever remember having this issue with multiple trunks before.


#2

If you have three different providers, there is really no issue as the outbound is going to three different locations. However, all inbound is coming from three as well, but to only one IP and port. This is normal and not an issue as the IP seen is what makes it different.

IT sounds like to me that the DID is possibly not formatted correctly in the inbound route.

The DID can be in the URI or the TO header and may not be the same. You need to do a capture of an inbound call using one of the problematic numbers and see how the number is formatted and in which field you want to use, which is then set in the trunk DID mode settings.


#3

Thank you for the response I will mark it as a solved solution as it is good information and can help others. Our issue was the networking admin did not whitelist the providers ip on the correct VLAN and once I could not get a trace on the inbound calls captured we realized its a networking issue, not a UCM issue