cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1305
Views
1
Helpful
21
Replies

Can't get URI dial peers to work correctly

Youreateapot418
Level 1
Level 1

Are there any good tutorials on how to match to "user" when matching dial peers to URI's?

I can get my dial peers on a Cisco CUBE to work correctly when numeric only (E164). But, when I replace with URI matching, it messes everything up. 

Anything I fine is related to host, FQDN etc... but not user. 

Any help appreciated.

edit: config below 

dial peer issue.jpg

1 Accepted Solution

Accepted Solutions

Have a look at this document. In Depth Explanation of Cisco IOS and IOS-XE Call Routing - Cisco It should help to understand how this operate in IOS.



Response Signature


View solution in original post

21 Replies 21

This video provides the configuration of incoming dial-peer matched by URI. Additionally, you can find the priority of match used by dial-peers.
This video provides the steps to configure dial-peer groups on a Cisco Unified Border Element platform. Tags: cube,dial,peer,group

Hopefully this explains it a bit better.

E164 dial peers result in correct behaviour. All Media and control work between 10.10.10.2 <-> 10.10.10.1 and 192.168.1.70 <-> 192.168.1.40.

But, when using the User-ID dial peer matching. I get signalling 10.10.10.2 <-> 10.10.10.1 and 192.168.1.70 <-> 192.168.1.40. But, RTP is in the following manner 10.10.10.2 <-> 192.168.1.70 and 192.168.1.70 <-> 192.168.1.40

 dial peer issue.jpg

Have you checked once, if you are matching the correct inbound dial-peer? Looks to me, that you are matching your "outbound" dial-peer in the incoming direction.

And personally, I basically wouldn't match the inbound dial-peer based on something in the FROM field.
I would match on the IP of CUBE's interface, e.g.:
voice class uri 100 sip
 host ipv4:10.10.10.1
!
dial-peer voice 100 voip
 incoming uri via 100

But why do you want to match based on the user-id in the first place?
And are you sure, that you are receiving the FROM header with "sip:LEFT@<IP>" and not with the number?

Have you checked a SIP trace?

I tell you what is probably happening (without seeing any trace logs):
Your "inbound" dial-peer is trying to match on the user-part "left" in the from field.
But the CUBE is receiving a number in the user-part.
Because you are dialing "right@..." the "outbound" dial-peer is matched in incoming direction and then in outbound direction --> Using both the interface vlan 100 as the media and control interface.

Your posts sounds like:
Let's to do some changes. Oh shit, it's not working anymore.
Ok, just open a question in the forum and don't look at any logs first.

Thank you for the demeaning ending to your post. 

It's actually 2 separate labs....

1st lab, as mentioned works fine

Left is setup as 1111, Right as 2222... then the dialpeers  are using the E164 matches

2nd lab 

Left is setup as "left", Right as "right"... then the dialpeers are changed to use the URI User-id matches.

So, your assumption is incorrect.

Why am I doing this? Because I noticed there was no solid examples anywhere online (that I have found) of how user-id should be matched in dial peers and I wanted to get it working (I know,f*** me for trying to learn). 

I've been sitting on this problem for 2 weeks now, so it wasn't as simple of "oh no it doesn't work, better just put it online"... it was in fact the opposite, I prefer not coming here, because someone trying to learn usually gets sarcastic demeaning responses from people like yourself. 

You haven't even answered the question, you just told me how you would do it, then attempted to belittle my approach. 

So do you know how to match indbound and outbound dial peers to user-id or not?

Maybe you don't get what I was trying to say: If you don't post any call logs, everything discussed here is just guessing and assuming.
So if you want help, you have to provide more info.

Only you know, that you are doing this just in your lab for learning. So my question why you wanna do it this way and not the other way is still valid, since I assumed, you have a problem with the production environment and I give ideas to do it differently.

If you don't wanna past call logs, then it's fine. But don't expect any help then.

Thank you for confirming that you do not know how to match inbound and outbound dial peers to user-id.

I've never used it before, but I've used URI matching a lot.

But again:
Maybe your config is incorrect or the calling / called patterns is not what you are expecting and therefore the dial-peer matching is not working.
But as you don't provide further information and just wanna debate about "if's" and "when's" and not about hard facts (like debugs), I can tell you, you won't get any answers by anyone here.

You cannot even confirm, if you are matching the correct dial-peer in inbound direction or that the calling number (FROM header) really is, what you are expecting. So every further discussion is unnecessary.

Instead of wasting your time and also my time discussing with me, if I have done it before or not, you could have used the time to make one single test-call with a SIP / dial-peer matching debug enabled.

You want the receive help (not me or any other person, trying to help here), so you have to deliver the requested information. Helpers are only able help based on the info you provide.
If you don't provide the requested info, it's fine, but then you won't get anymore help.

Thank you again for confirming that you do not know how to match inbound and outbound dial peers to user-id and trying to demean. 

 

Thank you for confirming, that you are not interested in a real technical discussion and that you are just interested in wasting someone else's time.

You're saying that, when you confirmed you have never done what I'm asking to do. You're wasting your own time.

But maybe I'm interested in learning new things too and finding a solution for you, but also maybe for me for a future installation? Have you ever thought about that?

But you're not interested. Your first instance was assume a load of incorrect assumptions, to project that I was wrong and you were right, and you then proceeded to tell me a completely different way to do it, and not answer the actual query. 

You just want to show you're right and I'm wrong, which this continuous back and forth is further proof of. 

You are the epitome of what's wrong with these forums. 

You don't get it, right?
"Your first instance was assume a load of incorrect assumptions..." --> I HAD to assume all this, because you didn't provide any further information. Just some pieces of config (which is static per-se).

"..., to project that I was wrong and you were right, ..." --> I just provided my thought about your problem, based on my experience working with CUBE and not based on your non-information (see first sentence).

And again, further discussing instead of just doing something.
Seems that a sales job fits you better. Talking suits you better, than doing technical things.

I do get it, you said you haven't done what I'm trying to do, so you can't help, so thank you.