Tuesday, February 23, 2016

CUBE URI Dialing


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:

  1. Top Most VIA header in INVITE message
  2. Request-URI header in INVITE message
  3. TO header in INVITE message
  4. FROM header in INVITE message
  5. Called Number (incoming called-number)
  6. Calling Number (answer-address)
  7. Calling Number (destination-pattern)
  8. 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:

  1. URI of an incoming INVITE message & Carrier-ID Target
  2. Called Number & Carrier-ID Target
  3. URI of an incoming INVITE message
  4. 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" ;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" ;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To:
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: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
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" ;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: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
Max-Forwards: 70
Content-Length: 0

<----- span="">
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" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;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:
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" ;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: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
Max-Forwards: 70
Content-Length: 0

<----- span="">
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" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;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:
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" ;tag=28~8901f810-e3b7-43de-b8ef-31fe13e397a7-18206035
To:
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: ;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0114274944-0000065536-0000000026-0182856970
Session-Expires:  1800
P-Asserted-Identity: "SBUSER1-CALLER"
Remote-Party-ID: "SBUSER1-CALLER" ;party=calling;screen=yes;privacy=off
Contact:
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" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;tag=971004A4-14C8
To:
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:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Length: 0

This can be fixed by applying normalization.

  1. Copy Remote-Party-ID header from incoming INVITE message to u01 variable
  2. 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" ;party=calling;screen=yes;privacy=off
From: "SBUSER1-CALLER" ;tag=9CF9483C-13B4
To:
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:
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
at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)

DNS Performance Troubleshooting

When you are troubleshooting internet performance, there are different parts of the connection should be verified:   ·         DNS Pe...

  • PxGrid Part # 3 - Troubleshooting FMC-ISE Identity Sync
    From FMC CLI, verify ISE integration status using the command   root@vFPMC:/etc/rc.d# cat /var/sf/run/adi-health $status = {      'ADI&#...
  • SIP Call Transfer
    In SIP IOS call transfer is achieved using REFER method. Similar to H450.2, a REFER message will be sent from transferor to transferee t...
  • CUCM SIP Early Offer
    By default CUCM uses SIP Delayed Offer. In order to enable Early Offer, use one of the following methods: MTP is required ...