Solved: Re: Multiple Sip trunks to One Cube and CUCM for different Sip providers for Migration

umutyasar · ‎01-30-2020

Hi,

We're planning to move from one sip provider to the other.

We connect the cube to the other sip trunk and configure inbound/outbound dial peers.

The new provider gives us a new number range for testing.

I didn't configure new dial peers for the new sip trunk to cube and also didn't configure a new sip trunk to cucm.

I think it's possible to use existing sip trunk and dial peers.

For testing purposes, I choose a branch phone and assigned a new Directory number to cucm phone with the number the incoming call will have. I'm using the existing sip trunk (RG), CCS and Partition that the branch is using in production.

I configured a Translation pattern for the new number as well with the same CSS and Partition that the branch is using in production.

The problem is I can't get any dial tonne, once I dial the test number. What do you think is the reason of the problem?

Do I need to configure new sip trunk on cucm and new dial peers to cube for cucm for the new sip trunk?

Regards,

U

TONY SMITH · ‎02-19-2020

@umutyasar wrote:
Now I need to plan a migration of DIDs from existing to new ITSP. New ITSP will do the porting.
I want to plan for a single number range porting firstly (12345600-99) after that I want to go for a state by state approach, like 01..., 02..., 03... But for this, I need to influence the outgoing calls according to calling (internal) DID.
Is it possible to do that with cucm and cube?
If not do you know any other solution?

Ideally you would get the new SIP provide to honour the calling numbers for all your existing numbers, then you can switch all your outbound calls even when the incoming number ranges are not yet ported.

However if that's not possible, I think you could route outbound calls based on calling number as follows ..

Create a second CUCM facing dial peer which will match calls based on calling number, if you use "incoming calling e164-pattern-map" you'll be able to match multiple ranges and add to the list as your numbers port.

Use Class of Restriction or Dial Peer Groups for force calls matched on that dial peer to use the new SIP service

When the migration is all complete you can strip back a lot of this configuration.

Does that make sense? I'd be interested to see if others have any neater ideas.

View solution in original post

Mohammed al Baqari · ‎01-30-2020

I would definitely start by isolating production from testing to avoid
interruptions and unplanned outages. Start with that then we can
troubleshoot further.

umutyasar · ‎01-30-2020

Hi Mohammed,

Unfortunately, I don't have lab environment to test the solution.

Do you think my approach is correct from the design perspective?

Which areas can I look at for this problem?

The test phone number disappears from the mobile phone, without any dial tone like it doesn’t exist. I could not see any logs on the cube for the new phone range while running “debug ccsip messages” during test calls.

Call Flow:

Mobile Phone—PSTN—Cube--Cucm—Telephone for DID

TONY SMITH · ‎01-31-2020

I've done a few installs with more than one provider on the same CUBE. What I'd suggest is first setting up a dial peer for the new ITSP, I always use a single dial peer for both in and out. If you prefer separate, then set them both up. Ideally match inbound by SIP URI, and for outbound put a non-conflicting destination pattern so it won't interfere with anything.

At this stage if you don't see incoming INVITE when you call that number then you should raise it with the carrier. If you do see an incoming invite you can start to assess whether you'll need to adjust codecs or number formats to get it to work.

You can set a test prefix on the new outbound dial peer, for example destination pattern *98T and translation rule to remove the prefix. Then you can make test calls on a call by call basis without interfering with the live calls.

umutyasar · ‎02-02-2020

Hi Tony,

I can't see invite messages from the provider. I can see options messages and respond them with 200OK.

I created a ticket to the provider. They told me the trunk is down since there is no contact field in my 200OK responses to the options message. I did a research but couldn't find a way to add contact field to the 200OK message. Do you know how to add it?

TONY SMITH · ‎02-03-2020

Possibly it could be added with a SIP profile. This would add to all OK responses on that particular dial peer, not just those sent in response to the Options poll. I had a quick look on a couple of installs and I can't see any sending a Contact header in any OK response.

umutyasar · ‎02-03-2020

Hi Tony,

I configure a sip profile for the outbound dial-peer like below.

But it still doesn't include the below contact field in the 200OK responses to the options messages.

Why do you think it doesn't work?

voice class sip-profiles 3

response 200 sip-header Contact add "sip:x.x.x.x:5060"

TONY SMITH · ‎02-04-2020

This works for me ...

response 200 method OPTIONS sip-header Contact add "Contact: sip:xxxxxxx"

umutyasar · ‎02-04-2020

Hi Tony,

I think this is the exact command for this solution. Thanks for that.

I configured it but it didn't work for me. Maybe there is another thing preventing to add the header, but I couldn't see any config causing this problem. I ran "debug ccsip all" comamnd as well, I couldn't find a log regarding added header or anything that prevents it.

TONY SMITH · ‎02-05-2020

Have you applied the profile to the correct dial peer? I always use a single dial peer for both in and out so can't be sure, but I suspect the profile needs to be on the inbound DP for it to affect a response.

davisjaron · ‎02-03-2020

Just to confirm, have you set up your sip-ua configurations? You should have the following configurations:
(config)#sip-ua
(config)#credentials username [USERNAME] password [PASSWORD] realm [ITSP URL]
(config)#authentication username [USERNAME] password [PASSWORD] realm [ITSP URL]
(config)#registrar [NUMBER] dns:[ITSP URL]

I assume you do, but if you're saying your trunk is down, that is where I would look first.

Your CUBE to CUCM trunk can be reused, no need to make a new one there, but you definitely will need a new dial-peer to the new ITSP otherwise the CUBE will never send or receive the calls to and from the new provider. As mentioned before, you can use a single dial-peer to receive inbound as well as send outbound to the ITSP. Match with the Via headers URI (using the command "incoming uri via" to check the incoming calls invite via header)

umutyasar · ‎02-03-2020

Hi Davis,

There are an authentication and registration config for the 1st provider under sip-ua.

However, the new Provider doesn't require SIP trunk registration or Authentication. Thus I didn't configure anything under sip-ua for the second one. Instead, I configured "session target ipv4:x.x.x.x" under outbound dial-peer, pointing providers sip server ip address.

Once I receive invite messages from the provider I plan to Match with the Via headers URI in inbound dial-peer, but I couldn't get one yet.

davisjaron · ‎02-05-2020

Are you unable to test inbound calls? That is where I would start, honestly, is testing an inbound rather than outbound. Once you've received an inbound call, you can view the SIP headers and cross reference it against the information the ITSP gave you for configurations. They could have easily fat fingered an IP address or something.

I assume, since you say they don't require authentication, that this ITSP is your on-prem service provider? I wouldn't assume this would be an internet based service provider without authentication.

TONY SMITH · ‎02-05-2020

He has said, and this is unusual, that the service provider has told him they won't route incoming calls unless he fixes these OK replies. So at the moment there's nothing to see inbound except the Options polling.

umutyasar · ‎02-05-2020

Hi Guys,

I asked the SP to disable the options temporarily during testing.

I can see inbound invite messages now coming from the second sip trunk.

But I have issues with inbound and outbound test calls.

Inbound calls: I get dial tone and the test phone is ringing but no 2-way voice. I noticed Sip binding for media was not configured on inbound/outbound dial peers for WAN interface, I configured it but still same issue. It seems a media (rtp) issue, but I haven't resolved yet.

Outbound calls: Cube LAN interface (SIP trunk destination ip) returning "604 Does not exist anywhere" and " No matching outgoing dial-peer" error. I configured the outbound dial-peer for the second SP with the destination pattern and with preference 2. Do you have any idea why it can't match it?