CUBE and CME on the same router: How to set source-interface per dial-peer?

[port.islander]

I thought I could use CUBE and CME on the same router, but I am struggling to get it to work.

Both work on their own:
a) I configure the sip trunk to the provider using sip-ua. I can register successfully and see inbound PSTN calls coming in. 

or I don't above and 

b) I configure voice register global / mode cme and voice service voip / sip / registrar server and my phone will register with CME.

I am suspecting the problem to be here:

In case of a), I configure a bind all source-interface to the provider facing Dialer 1. SIP-Trunk works, phones don't.
In case of b), I configure a bind all source-interface to the Voice VLAN SVI. Phones register, SIP-Trunk does not.

I read that I can also set this configuration per dial-peer, but I did not understand what the DPs would look like if CUBE and CME are on the same device. I tried to configure a dial-peer for my phone, destination-pattern 1111 and then set voice-class sip bind media source-interface Vlan777, but it did not seem to make any difference. I probably fail to understand what to match the dial-peers on and how many of them I would require at a minimum..

I would greatly appreciate if someone could put me in the right direction.

Config for a)

voice service voip
  ip address trusted list
    ipv4 1.1.1.1
  mode border-element
  allow-connections sip to sip  

  address-hiding
  sip
    bind all source-interface Dialer1

sip-ua
  credentials username 111111 password 7 111111111111111 realm provider.com
  authentication username 111111 password 7 111111111111111
  registrar ipv4:1.1.1.1 expires 120
  sip-server ipv4:1.1.1.1

Config for b)

voice service voip

  sip

    registrar server

    bind all source-interface Vlan777

voice register global
  mode cme

  source-address 10.70.0.254 port 5060

  max-dn 20
  max-pool 20
  load 9971 sip9971.9-4-2SR4-1  
  authenticate register
  create profile sync 005503224322506A  

!
voice register dn 1
  number 1111
!
voice register pool 1
  id mac aaaa.bbbb.cccc
  session-transport tcp
  type 9971
  number 1 dn 1
  dtmf-relay rtp-nte
  username 1111 password 1111
  codec g711ulaw
!

[Spooster IT Services · Accepted solution]

Hello @port.islander 

Upgrade the device to the Cisco latest suggested version 15.7(3)M7, remove the global "sip-ua" config, and set up a tenant for the provider. Here is the sample config:

voice class tenant 100
credentials username 111111 password 7 111111111111111 realm provider.com
authentication username 111111 password 7 111111111111111
registrar ipv4:1.1.1.1 expires 120
sip-server ipv4:1.1.1.1

bind all source-interface Dialer1

Then under the Dial-peer bind, the tenant like the following:

dial-peer voice 100 voip
description "Outbound Dial-peer to SIP Provider"
voice-class sip tenant 100
!
dial-peer voice 101 voip
description "Inbound Dial-peer to SIP Provider"
voice-class sip tenant 100

For CME, keep the global settings you mentioned above as they are like:

voice service voip
sip
registrar server
bind all source-interface Vlan777

To verify the SIP trunk status, use the "show sip-ua register status tenant 100" command

***Please mark all helpful responses***

[port.islander]

Wow, amazing... The tenant configuration allowed me to solve the problem with the binding conflict and now it works.

I can receive and place calls to the PSTN via the SIP trunk from the phone which is registered with CME. Perfect. Thank you so much!

I have one follow-up question. In the debugs, I still see registration attempts from the phone (extension) to the provider every few minutes. Is that the CUBE doing a registration on behalf of the phone? It's not needed for calls to work and gets rejected by the provider anyway. Is there any way to stop this?

Logs are below:

1.1.1.1 = SIP trunk provider server
2.2.2.2 = My public IP

1111 = The phone's internal extension

Mar 13 11:56:09.531: //10/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK92036
From: <sip:1111@1.1.1.1>;tag=CF0CC-215F
To: <sip:1111@1.1.1.1>
Date: Sat, 13 Mar 2021 02:56:09 GMT
Call-ID: 13E1CF84-82DE11EB-8007FC88-720D3EF6
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M5
Max-Forwards: 70
Timestamp: 1615604169
CSeq: 4 REGISTER
Contact: <sip:1111@2.2.2.2:5060>
Expires: 3600
Supported: path
Content-Length: 0

Mar 13 11:56:09.663: //10/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bK92036;received=2.2.2.2;rport=63333
From: <sip:1111@1.1.1.1>;tag=CF0CC-215F
To: <sip:1111@1.1.1.1>;tag=as4481e0c0
Call-ID: 13E1CF84-82DE11EB-8007FC88-720D3EF6
CSeq: 4 REGISTER
Server: provider.com
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="realm.provider.com", nonce="2d7f288e"
Content-Length: 0

Mar 13 11:56:09.667: //10/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:1.1.1.1:5060 SIP/2.0
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKA1650
From: <sip:1111@1.1.1.1>;tag=CF0CC-215F
To: <sip:1111@1.1.1.1>
Date: Sat, 13 Mar 2021 02:56:09 GMT
Call-ID: 13E1CF84-82DE11EB-8007FC88-720D3EF6
User-Agent: Cisco-SIPGateway/IOS-15.7.3.M5
Max-Forwards: 70
Timestamp: 1615604169
CSeq: 5 REGISTER
Contact: <sip:1111@2.2.2.2:5060>
Expires: 3600
Supported: path
Authorization: Digest username="279440",realm="realm.provider.com",uri="sip:1.1.1.1:5060",response="e212608f941904857407b9749de7a722",nonce="2d7f288e",algorithm=MD5
Content-Length: 0

Mar 13 11:56:09.799: //10/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 2.2.2.2:5060;branch=z9hG4bKA1650;received=2.2.2.2;rport=63333
From: <sip:1111@1.1.1.1>;tag=CF0CC-215F
To: <sip:1111@1.1.1.1>;tag=as4481e0c0
Call-ID: 13E1CF84-82DE11EB-8007FC88-720D3EF6
CSeq: 5 REGISTER
Server: provider.com
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Mar 13 11:56:09.799: //10/000000000000/SIP/Error/ccsip_api_register_result_ind:
Message Code Class 4xx Method Code 100 received for REGISTER
R1(config-class)#
Mar 13 11:56:09.799: //10/000000000000/SIP/Error/sipSPIFlushDeferredQueue:
Invalid deferredQueue

[Roger Kallberg]

Try with the solution in this post, it looks to be a perfect match. https://community.cisco.com/t5/ip-telephony-and-phones/phone-is-trying-to-register-with-itsp-as-against-cme/td-p/3865275

[port.islander]

Very good. Had to adapt the solution from Skinny to SIP phones and it would not stop without a reload of the router, but it works now. Thanks a lot!

[dimigav1977]

This situation is about ISP ?

[Scott Leport]

Hi there,

A copy of the config would help for sure, but essentially you could try something like this (edit to suit your deployment):

dial-peer voice 10 voip

 description ***To ITSP***

 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0

Remove the global bind from your SIP configuration, e.g.

voice-service-voip

 sip

  no bind all source-interface Vlan777

This would bind all signaling and media to this dial-peer when calls match this dial-peer, so outgoing calls essentially. I don't think you would need to bind any other interfaces unless you were making on-net calls to other phone systems from the CME.

[Roger Kallberg]

I think the global bind would be needed for the CME part. I would recommend to go the path @Spooster IT Services suggest with tenant configuration. That's in my experience the best option for registration type of connections to a SIP ITSP service.

[port.islander]

Thank you! Yes, I tried the tenant configuration and it works well. 

It's interesting that there seems to be a disagreement whether the global bind is needed for CME or not. During my testing, I could only get CME registration to work if indeed I had the global bind set to the internal-facing interface (in my case the Voice VLAN SVI).

[Roger Kallberg]

This is my understanding and experience also. Although not with CME, but with SRST. As this is basically pretty much the same component in configuration it should be the same.

[Nithin Eluvathingal]

Have a look on attached CME configuration with SIP trunk . Since ITSP need source and destination Port  5060 you will see under SIP-UA, connection reuse and port 5060.

[port.islander]

Thank you! It was helpful to see the configuration with the dial-peers. However, I could not get CME configuration to work without the global binding and tenant configuration as suggested by @Spooster IT Services . It's interesting that in your example you could manage without it.

[dimigav1977]

Dear Nithin,

I used a GPON FTTH connection which provide me DATA, VOICE and IPTV.

This connection works with VLAN for each service. DATA provided with public IP and the other two (VOICE and IPTV) with DHCP from provider.

I use two analog phones on FXS module and two Cisco 8961 IP Phones. I have troubles to make the VOICE service in use.

The config provided by you can be useful for me?

[Roger Kallberg]

@dimigav1977 It is much better if you create your own post with your question instead of piggy back on another post. Especially as your question is off topic to the OP.

[dimigav1977]

Thanks