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!

Call routing with Avaya SBCe

Status
Not open for further replies.

dclark1111

Technical User
Nov 5, 2019
29
US
I am struggle to get this to sink into my head. Reading pages 73 on, and I cannot get it to work. Here is what I want to do. I want to take calls destined to 123-456-NNNN to one session manager (at a second site) then all other calls to another session manager.
I built the URI group choosing SIP and Dial Plan options as:
123456*@.*
Attached the url group to a routing profile as priority 1, with priority 2 to the other SM

The url group is not match when I call in. Running a trace, I see the TO: number being 123456xxxx@IP

Is it not possible to accomplish what I want to do in a routing policy?

Then, I have tried to add this into server flows as well, as there is an option for the URI group there. When I do that, it doesn't work, and 2 it seems to bring the sip link down into a far-end-busy status. I spent a fair time in server flows as this pointed me there - as I think they are doing exactly what I want to accomplish.

The part that is catching me is the received interface must match. Trying to make sense of where I would place it. I think this hits the flow from received interface is my 1st SM, and media and signal are the carrier.

Thanks for the help and read.
 
Read carefully - it looks at the FROM header, not the TO header.

So, for calls received at the SBC, Received Interface be damned, if it matches the server configuration "PSTN", it'll use that flow.
That flow has a routing profile - to your SMs.

The message must leave the SBC on outbound call processing, and that's where the URI group applies to the TO header and matching is done on the received interface and URI group

So, your server flow that would need the URI group 123456*@* would be on the server flow that has this other SM as the Server configured on it.
 
kyle555
Thanks for the reply.
When I attach a URI group to the server flow I get a failure for the ping (health check). This is why I attempted to do this with a routing profile.
Let me spend some time on trying to apply what you suggested and see if the ping still fails
Thanks again
 
I added the URI group to the server flow for the SM that should not be receiving the numbers (call this SM2). All calls flow to SM1 even the ones that don't match the URI group.


I did as you suggested in the other post. I made a URI group that matched my cell phone. I applied this to our carrier links so to speak, as I added it to the server flow that had our signal and media interface as the carriers. It appears to be matching on the From from where I placed in on the server flow. Making progress, updating this post to help a future me or someone else.

I just need to flip the logic and have it match the To:. Guessing I have this attached to the wrong server flow.
 
I have figured this thing out. To match on the TO: field -
In server flows I have the server I want to match listed first from the carrier. It has a routing policy attached to it.
In Routing policy, I choose the destination server with a URI group to match.
In the same routing policy I chose the second SM for all other calls, as the 2nd priority - URI group was *.

My URI group I picked:
SIP - Plain Dial
Then
123456XXXX@.*

Hope this helps someone in the future.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top