Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Inbound SIP DDI Call Flow

Status
Not open for further replies.

Devolution

Programmer
Jun 6, 2005
189
GB
Hello all,

I think I remember finding a page in the MiVB help files in the past few years that explained the forms an incoming call checks in order to get routed to an endpoint e.g. Trunk Attributes -> Inward Dialing -> Speed Call -> ARS Digits Dialled. I cannot find this and am doubting if it ever existed.

Has anyone else seen this or can anyone confirm the order in which the MiVB forms are checked for an incoming SIP DDI call? I understand the path will be slightly different depending on if DID Routing is ticked in the Trunk Attributes for the SIP peer profile.

Thanks.
 
theres lots of things that can affect incoming calls

start on sip peer - it will have a trunk service number
check trunk attributes
if it has direct inward dialling service enabled then check DID routing form
- normally it would also have absorb 0 so that all digits received from carrier are looked at in DID routing table

if it doesn't have direct dialling enabled then you would normally use absorb/insert to adjust to the number of digits you want
for example if carrier is sending 02345678xx and you want it to match extension numbers like 27xx
- you could set trunk to absorb 8 ( remove 02345678 ) and insert 27 to change it to 27xx
- or you might not want an exact match but to use speedcalls
- you could set trunk to absorb 5 ( remove 02345 ) and use a speed call 67800 to send it to 2700

there are alos Sip peer inward dialling modfication patterns that can be applied to the trunk to modify numbers based
on digit length and leading digits ( gets a bit confusing)

If I never did anything I'd never done before , I'd never do anything.....

 
If you look at the DID Service in the Help Files (under System Features) it mentions the below.

Help Files said:
Incoming DID call processing algorithm

1. Trunk service digit modification is performed, based on the incoming trunk configuration.

2. System Speed Calls lookup is conducted.

3. CRS database is searched for the modified DID number and the associated destination number.
Possible CRS query responses:
NO MATCH - no associated destination number found
EXACT MATCH - the exact one associated destination number found
CONFLICTING MULTIPLE MATCHES - more than one associated destination number found
PARTIAL MATCH - one or more matches associated with the subset of queried digit string found

4. If an exact match is found in the CRS database, the call is routed to the destination number. Otherwise, the following routing is applied:

- If the search returns conflicting multiple matches, no matches are used and the call is routed on the originally dialed digits.
- If a partial match is found, the call is routed on the originally dialed digits.
- In a rare conflict scenario where: FOPBX (Force-to-PBX) is configured as the CRS option in the Trunk Attributes form, both CRS and DID service are enabled, and the EHDU external number matches the DID number, the call will be handled by CRS and not DID Service.

There's a little more info in the help files.
 
Thank you Billz66 and Sarond for your replies. I think the help file Sarond has pasted is the one I was thinking about but combining this with Billz66 concise explanation I have a further question. When does the Calling Party Inward Dialing Modification form get looked at, before the Trunk Attributes for the SIP Peer or after? Assuming it is indeed set for a SIP peer.
 
I believe it is before.

An example in Australia.
Telstra, one of our main carriers, passes 9 digits to our SIP Peer.
e.g. 712345678
This would have to match in our DID Service (Assuming the trunk attribute is absorbing 0)

But when we dial out we use 10 digits for non local calls and mobiles.
e.g. 0712345678

We can change the "SIP Peer Profile Called Party Inward Dialing Modification" to insert a 0 when the length is 9 so that it then matches what we would expect and the DID Service would also have to be 10 digits. (Assuming the trunk attribute is absorbing 0). So 0712345678 is what we would be analysing to route the call.

SIP Peer Profile Calling Party Inward Dialing Modification is actually to do with the caller id that we see on an incoming call. Again Telstra send 9 digit caller ID and we insert a 0 to make it look correct and also allow calling it back correctly.

Hope that makes sense...
 
Thank you Sarond.

I have used all the info that we have discussed and come up with these call flows to show the steps an incoming SIP call will make, please comment to highlight if anything is incorrect and/or needs adding...

Incoming SIP DDI (Direct Inward Dialing Service disabled in Trunk Attributes)

Step 1 - Check if there are any Inward Dialing Modification values associated to SIP Peer. If Yes, go to Step 2. If No, go to Step 3
Step 2 - If a match is found in the Inward Dialing Modification form, route to that entry. If no match continue to next step.
Step 3 - Check Trunk Attributes and apply any digit modification listed there.
Step 4 - Check Speed Calls form, if match found route to destination. If no match continue to next step.
Step 5 - Check CRS database (Extns, Groups, Keys) and route to destination. If no match continue to next step.
Step 6 - Check ARS and route to destination. If no match continue to next step.
Step 7 - If no match, call fails.


Incoming SIP DDI (Direct Inward Dialing Service enabled in Trunk Attributes)
Step 1 - Check if there are any Inward Dialing Modification values associated to SIP Peer. If Yes, go to Step 2. If No, go to Step 3
Step 2 - If a match is found in the Inward Dialing Modification form, route to that entry. If no match continue to next step.
Step 3 - Check Trunk Attributes and apply any digit modification listed there.
Step 4 - Check Direct Inward Dialing form and route to destination. If no match continue to next step.
Step 5 - Check Speed Calls form, if match found route to destination. If no match continue to next step.
Step 6 - Check CRS database (Extns, Groups, Keys) and route to destination. If no match continue to next step.
Step 7 - Check ARS and route to destination. If no match continue to next step.
Step 8 - If no match, call fails.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top