Inbound calls

[cchaulvet]

Hello,

 

After the Dial plan and the Trunk configuration, I can make external call (I can call phone from my pbx account).

But if someone want to call me on my account ? How can I do it ?

 

Thanks,

Chris

[Vodia PBX]

After the Dial plan and the Trunk configuration, I can make external call (I can call phone from my pbx account).

But if someone want to call me on my account ? How can I do it ?

 

There used to be a description on the old Wiki http://kiwi.pbxnsip.com/index.php/Inbound_Calls_on_Trunk, seems like the new Wiki is not there on this topic yet.

[UKenGB]

There used to be a description on the old Wiki http://kiwi.pbxnsip.com/index.php/Inbound_Calls_on_Trunk, seems like the new Wiki is not there on this topic yet.

This explanation linked to is seriously lacking in clarity and doesn't help much with understanding how a Trunk is 'assigned' to a call.

 

I have a Linksys SPA3102 as the PSTN Gateway and although it apparently works, in fact some calls get assigned to the wrong Trunk and not the actual PSTN Gateway Trunk. This is of course a real problem since it means calls get misrouted. So I need to be able to specify ABSOLUTELY that calls incoming from the Linksys (i.e. from the PSTN) DO get assigned to the PSTN Gateway Trunk.

 

When trying to find the correct Trunk, the PBX apparently looks for:-

 

- The incoming call matches the IP address of the outbound proxy of that trunk etc...

 

but how is a telephone call matched to an IP address? Sorry if that's a bit silly, but what part of the call is being matched? The Request URI, the address of the packet, the From Header, the To Header, all of the above...?

 

The wording of the explanation is somewhat obscure. When the expression "Domain Name" is used, does that mean the Domain part of a FQDN or the Domain field in the Trunk config page?

 

When the call is correctly identified, the log shows:-

 

- "Identify trunk (domain name match) 1"

 

What does that mean - EXACTLY. What is really being matched to what?

 

Without a true understanding of what snomONE is doing with this 'matching' it is impossible to ensure such matching will be correct EVERY time and it MUST be correct or as I said, calls get routed incorrectly with potentially disastrous consequences.

 

So could we have some additional explanation here please?

[Vodia PBX]

Okay, it works like this:

 

The PBX looks at all trunks with the following algorithm:

 

1. If the trunk is disabled or only outbound, this trunk is not considered.

 

2. Then it sets the following flags:

 

- "Matches IP": If the trunk has associated address this is set to true when the source IP address of the SIP INVITE matched one of the addresses in the associated addresses. If there are no associated addresses set, then it will use the outbound proxy addresses instead. Those addresses are all possible destinations that occur when resolving the outbound proxy address, especially including the DNS SRV candidates.

 

- "Matches Adr": Same like "matches IP", but the comparison includes the port number as well.

 

- "Matches the Domain" if the domain of the trunk matches the host name of the Request-URI or the domain name is "localhost".

 

- "Matches the User": If the trunk account name is set and matches the Request-URI user part and the host of the Request-URI is not a DNS name (IP Address).

 

- "Matches the From": If the trunk account and registrar are both set and match the From-header.

 

- "Matches a DID": If the user name of the Request-URI matches a DID in the domain of the trunk (comparision made based on the globalized number in + format according to the country code of the trunk domain).

 

3. Then it classified the quality of the match:

 

If it matches the IP and matches the From then the PBX will remember this candidate for "IP address and from match".

 

If it matches the IP and matches the User then the PBX will remember this candidate for "IP address and user match".

 

If it matches the IP and matches the DID then the PBX will remember this candidate for "IP address and DID match".

 

If it matches the Address and matches the Domain then the PBX will remember this candidate for "IP address/port and domain match".

 

If it matches the IP and matches the Domain then the PBX will remember this candidate for "IP address and domain match".

 

If it matches the Address then the PBX will remember this candidate for "IP address/port match".

 

If it matches the IP then the PBX will remember this candidate for "IP address match".

 

If it matches the Domain then the PBX will remember this candidate for "domain name match".

 

4. After processing all trunks, it will return the result in the following precedence:

 

- IP address and DID match

- IP address and from match

- IP address and user match

- IP address/port and domain match

- IP address and domain match

- IP address/port match

- IP address match

- domain name match

 

I know this description needs to be "digested", but that's the way it works folks. The bottom line is to find the "best match" (kind of least energy if you want) which is stated in 4.

[UKenGB]

Excellent, thanks. At last some very useful real information.

 

However, I do have a problem that is almost made more confusing with the above. My PSTN Gateway Trunk uses the same FQDN (of the Linksys itself) in the Domain and Proxy fields, the latter including the port. The account and password is also the same as set up in the Linksys (although it doesn't look like any auth is requested). IOW, I would think the match should be good. But I found that incoming PSTN calls would be consistently assigned to different Trunks which ALL register to the VOIP provider so no domain names or IP addresses would match at all. I then discovered that if I entered the Linksys' FQDN in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config (empty for ALL other Trunks) it all seemed to then work with calls being correctly assigned to the PSTN Gateway.

 

But I have now noticed some calls that are NOT being correctly matched e.g.

 

010/12/19 19:36 077xxxxxxxx 01932xxxxxx(44) Ken.work

 

The above is a (test) call from my mobile to the PSTN number, but it is being incorrectly assigned to the Ken.work Trunk - a test Trunk that is registered to the VOIP Provider. Later :-

 

2010/12/20 16:18 077xxxxxxxx 01932xxxxxx PSTN Gateway

 

Another test call from my mobile to the same PSTN number, but in this case it is correctly assigned to the PSTN Gateway Trunk.

 

Neither of the above are isolated incidents, but something that puzzles me is the extension number (44) that appears in the first line. I'm not sure why that is there and what does it mean. Is it significant to this problem?

 

In fact I've just realised that the (44) means the extension to which calls assigned to the Ken.work Trunk were being directed, so it appears by virtue of the Trunk that has been assigned and therefore has no relevance to which Trunk is assigned. At least, it shouldn't have. However, the PSTN Gateway Trunk directs calls to a Hunt Group, so why is that not specified in the Call log in the same way?

 

Bearing in mind that the Linksys' FQDN is in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config for BOTH the above calls, I fail to see how it can possibly match this call to a Trunk that has no relationship to the incoming call data, but that seems to be exactly what it has done for that first call.

 

Sorry, I seem to have Hijacked this thread, although the subject mater is relevant. Should we move this to a new thread?

[pbx support]

Excellent, thanks. At last some very useful real information.

 

However, I do have a problem that is almost made more confusing with the above. My PSTN Gateway Trunk uses the same FQDN (of the Linksys itself) in the Domain and Proxy fields, the latter including the port. The account and password is also the same as set up in the Linksys (although it doesn't look like any auth is requested). IOW, I would think the match should be good. But I found that incoming PSTN calls would be consistently assigned to different Trunks which ALL register to the VOIP provider so no domain names or IP addresses would match at all. I then discovered that if I entered the Linksys' FQDN in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config (empty for ALL other Trunks) it all seemed to then work with calls being correctly assigned to the PSTN Gateway.

 

But I have now noticed some calls that are NOT being correctly matched e.g.

 

010/12/19 19:36 077xxxxxxxx 01932xxxxxx(44) Ken.work

 

The above is a (test) call from my mobile to the PSTN number, but it is being incorrectly assigned to the Ken.work Trunk - a test Trunk that is registered to the VOIP Provider. Later :-

 

2010/12/20 16:18 077xxxxxxxx 01932xxxxxx PSTN Gateway

 

Another test call from my mobile to the same PSTN number, but in this case it is correctly assigned to the PSTN Gateway Trunk.

 

Neither of the above are isolated incidents, but something that puzzles me is the extension number (44) that appears in the first line. I'm not sure why that is there and what does it mean. Is it significant to this problem?

 

In fact I've just realised that the (44) means the extension to which calls assigned to the Ken.work Trunk were being directed, so it appears by virtue of the Trunk that has been assigned and therefore has no relevance to which Trunk is assigned. At least, it shouldn't have. However, the PSTN Gateway Trunk directs calls to a Hunt Group, so why is that not specified in the Call log in the same way?

 

Bearing in mind that the Linksys' FQDN is in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config for BOTH the above calls, I fail to see how it can possibly match this call to a Trunk that has no relationship to the incoming call data, but that seems to be exactly what it has done for that first call.

 

Sorry, I seem to have Hijacked this thread, although the subject mater is relevant. Should we move this to a new thread?

 

Does your example refer to the inbound calls or outbound calls. The explanation that 'pbxnsip' provided applies only to the incoming calls to the PBX (FYI).

[UKenGB]

Does your example refer to the inbound calls or outbound calls. The explanation that 'pbxnsip' provided applies only to the incoming calls to the PBX (FYI).

Outbound is controlled by the Dial Plan so no problem.

 

Inbound is the problem and only for calls from the Linksys SPA3102. Calls from the VOIP provider seem to always be assigned the correct Trunk, no doubt due to the use of the 'Line' parameter when registering.

[Vodia PBX]

Bearing in mind that the Linksys' FQDN is in 'Explicitly list addresses for inbound traffic:' in the PSTN Gateway Trunk config for BOTH the above calls, I fail to see how it can possibly match this call to a Trunk that has no relationship to the incoming call data, but that seems to be exactly what it has done for that first call.

 

Well, which other trunk does the PBX match? Check the above rules, why this trunk would get a higher precedence in the trunk matching than the Linksys trunk. Maybe the other trunk has no outbound proxy specified. And of course make sure that you have no unneccessary trunks and make sure that you dont use IP addresses to identify extensions (in the registration setting for the extension).

[UKenGB]

Well, which other trunk does the PBX match? Check the above rules, why this trunk would get a higher precedence in the trunk matching than the Linksys trunk.

That's my point, I cannot see how it could possibly match. Account, Domain, Username, Password, Proxy match NOTHING in the incoming call data. Whereas in the PSTN Gateway Trunk I have explicitly set the address from which to accept calls which according to your rules above would produce the highest ranking match. So why send it to a Trunk that apparently doesn't match.

 

Well, which other trunk does the PBX match? Check the above rules, why this trunk would get a higher precedence in the trunk matching than the Linksys trunk. Maybe the other trunk has no outbound proxy specified.

Ah. It is possible the test trunk did not have a Proxy set at the time it was assigned those calls instead of the PSTN Gateway. I recently corrected this in one Trunk and it could have been that one. It would also explain why current test calls seem to be handled correctly.

 

However, what you're saying is that an empty Proxy setting will match anything, with a higher ranking than any of the rules you state above, even higher than a Trunk with a matching proxy and an explicitly stated address?

[Vodia PBX]

However, what you're saying is that an empty Proxy setting will match anything, with a higher ranking than any of the rules you state above, even higher than a Trunk with a matching proxy and an explicitly stated address?

 

The idea of the rules is that the trunk with empty proxy should have a low precedence. This is essentialy for ENUM calls where you cannot say where the call will come from. But because SIP routing is so complicated, the complex rule construct above can have surprising side effects.

 

Also, the PBX must make a decision if the call comes from an extension. Keep that in mind. If the From-header matches a username on the system, it wll think that the call does not come from a trunk, but from an extension.

[UKenGB]

Also, the PBX must make a decision if the call comes from an extension. Keep that in mind. If the From-header matches a username on the system, it wll think that the call does not come from a trunk, but from an extension.

Do you mean matches just Username, or would it match an Account name? Or any other field/parameter?

[Vodia PBX]

Do you mean matches just Username, or would it match an Account name? Or any other field/parameter?

 

It will match the username and the domain. However, if you use the "localhost" domain, it will match only the username. If the call comes from a trunk with the outbound or explicit inbound set, then the trunk will have higher precedence than the extension. But anyway, another item to check.