- Cisco Community
- Technology and Support
- Collaboration
- Collaboration Knowledge Base
- CUBE URI Dialing
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
02-23-2016 11:27 AM - edited 03-12-2019 10:21 AM
New features has been introduced in CUBE to support URI dialing
Enable URI Call Routing
By default CUBE will lookup the user field in the Request-URI of the INVITE message which should be made of digits. To support URI dialing, you need to enable domain-lookup call routing in the CUBE.
Domain lookup should be enabled globally or on the incoming dial-peer. Domain lookup isn't required on the outgoing dial-peer
voice service voip
sip
call-route url
or
dial-peer voice x voip
voice-class sip call-route url
Inbound Dial-Peers
Inbound dial-peers can match based on SIP URI of the incoming INVITE message. The matching order is:
- Top Most VIA header in INVITE message
- Request-URI header in INVITE message
- TO header in INVITE message
- FROM header in INVITE message
- Called Number (incoming called-number)
- Calling Number (answer-address)
- Calling Number (destination-pattern)
- Dialpeer 0
voice class uri voice-class-uri-tag sip|tel
Specify a URI field for the voice class:
host hostname-pattern
host ipv4:ipv4-address
host ipv6:ipv6-address
host dns:dns-address
pattern uri-pattern
user-id username-pattern
!
dial-peer voice tag voip
session protocol sipv2
incoming uri { from | request | to | via} voice-class-uri-tag
You need to apply the command 'session protocol sipv2' in order to configure URI matching. Without this command, URI matching commands won't be listed
In a scenario where multiple SIP hops are involved in a call, there would be multiple via headers involved, and the topmost via header of an incoming SIP invite represents the last hop that forwarded the SIP request, and the bottom-most via header would represent the originator of the SIP request. Match based on VIA header of incoming INVITE message will match the last hop that forwarded the request (neighboring SIP entity), which is the topmost via header. Other VIA headers are ignored
INVITE sip:123@1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.10.1:5093;branch=z9hG4bK-17716-1-0
Via: SIP/2.0/TCP 10.10.14.20:5093;branch=z9hG4bK-28280-1-0
Outgoing Dial Peer
Similarly, outbound dial-peers can match URIs of incoming INVITE message ordered as follow:
- URI of an incoming INVITE message & Carrier-ID Target
- Called Number & Carrier-ID Target
- URI of an incoming INVITE message
- Called Number
voice class uri 2001 sip
host ipv4:10.2.1.1
!
dial-peer voice 1 VoIP
destination uri 2001
carrier-id target orange
!
dial-peer voice 2 VoIP
destination-pattern 654321
carrier-id target orange
!
dial-peer voice 3 VoIP
destination uri 2001
!
dial-peer voice 4 voip
destination-pattern 654321
INVITE sip:654321@10.2.1.1 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:5060;x-route-tag="cid:orange@10.1.1.1";branch=z9hG4bK-23955-1-0
From: "555" <sip:555@10.1.1.1:5060>;tag=1
Configuration Example
voice class uri InboundMatch sip
pattern hquser*
!
voice class uri outgoingURI sip
host dns:hqcluster.local
!
dial-peer voice 1913 voip
session protocol sipv2
session target ipv4:10.45.230.10
incoming uri request InboundMatch
voice-class sip call-route url
!
dial-peer voice 1912 voip
session protocol sipv2
session target ipv4:10.170.10.200
destination uri outgoingURI
*********************************************************************
Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local>;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.45.230.10:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires: 1800
P-Asserted-Identity: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>;party=calling;screen=yes;privacy=off
Contact: <sip:sbuser1@10.45.230.10:5060;transport=tcp>
Max-Forwards: 70
Content-Length: 0
Request URI Pass-Through
By default CUBE will replace the host portion in Req-URI & TO headers of INVITE message with the configured session target as follow:
dial-peer voice 1913 voip
session protocol sipv2
session target ipv4:10.45.230.10
incoming uri request InboundMatch
voice-class sip call-route url
!
dial-peer voice 1912 voip
session protocol sipv2
session target ipv4:10.170.10.200
destination uri outgoingURI
----->
Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local>;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.45.230.10:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires: 1800
P-Asserted-Identity: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>;party=calling;screen=yes;privacy=off
Contact: <sip:sbuser1@10.45.230.10:5060;transport=tcp>
Max-Forwards: 70
Content-Length: 0
<-----
Sent:
INVITE sip:hquser1@10.170.10.200:5060 SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK44CE2352
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;tag=970E872C-1947
To: <sip:hquser1@10.170.10.200>
Date: Mon, 22 Feb 2016 15:18:36 GMT
Call-ID: 61038AB0-D8AE11E5-AF45D397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2310550400-0000065536-0000000046-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456154316
Contact: <sip:sbuser1@10.170.170.2:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Length: 0
In URI dialing this isn't a desirable behavior as the preference is to maintain the domain-name for the destination system to be able to perform domain-lookup. Typical example when routing calls from CUCM to Lync or vice-versa.
You can pass-through Req-URI and TO headers using the command 'voice-class sip requri-passing' which needs to be applied globally or on the outgoing dial-peer
Note: Remote-Party-ID, From and Contact headers will be modified to reflect the session target in the host portion
dial-peer voice 1913 voip
session protocol sipv2
session target ipv4:10.45.230.10
incoming uri request InboundMatch
voice-class sip call-route url
!
dial-peer voice 1912 voip
session protocol sipv2
session target ipv4:10.170.10.200
destination uri outgoingURI
voice-class sip requri-passing
The debugs will look as follow:
----->
Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local>;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.45.230.10:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires: 1800
P-Asserted-Identity: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>;party=calling;screen=yes;privacy=off
Contact: <sip:sbuser1@10.45.230.10:5060;transport=tcp>
Max-Forwards: 70
Content-Length: 0
<-----
Sent:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK44CF3C
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;tag=971004A4-14C8
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 15:20:14 GMT
Call-ID: 9B388AED-D8AE11E5-AF4BD397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3290550400-0000065536-0000000047-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456154414
Contact: <sip:sbuser1@10.170.170.2:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Length: 0
302 Contact Header Pass-Through
Similar to Req-URI, you can pass-through contact header only in outgoing 302 messages. This is important in call forward scenarios in order to maintain host portion of contact header instead of replacing it with session target
voice service voip
sip
contact-passing
or
dial-peer voice tag voip
session protocol sipv2
voice-class sip contact-passing
Remote-Party-ID Normalization
The next step is to fix the caller-ID display. Incoming INVITE in below debug contains caller ID, caller URI and caller DN which is basically blended addressing.
Received:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/TCP 10.45.230.10:5060;branch=z9hG4bK2379042ad5
From: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local>;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 10:35:46 GMT
Call-ID: 6cfb280-6ca1e482-1a-ae62d0a@10.45.230.10
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM9.1
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.45.230.10:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires: 1800
P-Asserted-Identity: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>;party=calling;screen=yes;privacy=off
Contact: <sip:sbuser1@10.45.230.10:5060;transport=tcp>
Max-Forwards: 70
Content-Length: 0
CUBE will override Remote-Party-ID header to reflect the session target in the host portion. Also, it will strip x-cisco-number as it is unsupported header. At the receiving endpoint, the caller number won't be displayed and the caller URI will be wrongly displayed.
Sent:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK44CF3C
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;tag=971004A4-14C8
To: <sip:hquser1@hqcluster.local>
Date: Mon, 22 Feb 2016 15:20:14 GMT
Call-ID: 9B388AED-D8AE11E5-AF4BD397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3290550400-0000065536-0000000047-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456154414
Contact: <sip:sbuser1@10.170.170.2:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Length: 0
This can be fixed by applying normalization.
- Copy Remote-Party-ID header from incoming INVITE message to u01 variable
- Paste Remote-Party-ID header to outgoing INVITE message from u01 variable
!!! … Define which headers are allowed to be copied from incoming SIP message
voice class sip-copylist 1
sip-header Remote-Party-ID
!!! … Create normalization rule to modify the required header. First copy the peer-header (which is incoming header) to variable then paste it as outgoing header
voice class sip-profiles 10
request INVITE peer-header sip Remote-Party-ID copy "(.*)" u01
request INVITE sip-header Remote-Party-ID modify "(.*)" "Remote-Party-ID: \u01"
!!! … Assign the copy-list to inbound dial-peer
dial-peer voice 1913 voip
session protocol sipv2
session target ipv4:10.45.230.10
incoming uri request InboundMatch
voice-class sip call-route url
voice-class sip copy-list 1
!!! … Assign the normalization rule to outgoing dial-peer
dial-peer voice 1912 voip
session protocol sipv2
session target ipv4:10.170.10.200
destination uri outgoingURI
voice-class sip profiles 10
voice-class sip requri-passing
Sent:
INVITE sip:hquser1@hqcluster.local SIP/2.0
Via: SIP/2.0/UDP 10.170.170.2:5060;branch=z9hG4bK47AF844
Remote-Party-ID: "SBUSER1-CALLER" <sip:sbuser1@sbcluster.local;x-cisco-number=3000>;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" <sip:sbuser1@10.170.170.2>;tag=9CF9483C-13B4
To: <sip:hquser1@hqcluster.local>
Date: Tue, 23 Feb 2016 18:53:06 GMT
Call-ID: 82872A36-D99511E5-BF28D397-811E4C2B@10.170.170.2
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2873105024-0000065536-0000000111-0182856970
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1456253586
Contact: <sip:sbuser1@10.170.170.2:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Length: 0
Derive Session Target from SIP-URI
CUBE can use the host portion of Req-URI header in incoming INVITE message to findout the session target. If the host portion is an IP address, CUBE will directly signal the IP. However, in URI Dialing the host portion usually is a domain-name. Hence, CUBE will resolve the domain name and signal the result IP.
dial-peer voice 1912 voip
session protocol sipv2
session target sip-uri
destination uri outgoingURI
voice-class sip profiles 10
voice-class sip requri-passing
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: