SIP Normalization for ITSP Internetworking Using Cisco Unified Border Element (CUBE)
At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE and the CUCMs on Dial-Peer’s 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T’s side that they have given us to peer with. We see this here:
! ip domain retry 0 ip domain timeout 2 ip domain name ine.com ip name-server 177.1.100.110 ! voice service voip address-hiding allow-connections sip to sip redirect ip2ip sip bind control source-interface Loopback0 bind media source-interface Loopback0 header-passing error-passthru midcall-signaling passthru g729 annexb-all ! voice class codec 1 codec preference 1 g711ulaw codec preference 2 g729r8 ! ! dial-peer voice 101 voip description ** TO/FROM CUCM SUBSCRIBER 1 ** destination-pattern 2065011...$ voice-class codec 1 session protocol sipv2 session target ipv4:177.1.10.20 incoming called-number . dtmf-relay sip-kpml rtp-nte ! dial-peer voice 102 voip description ** TO/FROM CUCM SUBSCRIBER 2 ** destination-pattern 2065011...$ voice-class codec 1 session protocol sipv2 session target ipv4:177.1.10.25 dtmf-relay sip-kpml rtp-nte ! dial-peer voice 1001 voip description ** TO/FROM SIP ITSP - AT&T SBC 1 ** destination-pattern +T voice-class sip localhost dns:corphqr1.ine.com session protocol sipv2 session target dns:sip1.att.com incoming called-number 2065011...$ dtmf-relay rtp-nte codec g729br8 ! dial-peer voice 1002 voip description ** TO/FROM SIP ITSP - AT&T SBC 2 ** destination-pattern +T voice-class sip localhost dns:corphqr1.ine.com session protocol sipv2 session target dns:sip2.att.com incoming called-number 2065011...$ dtmf-relay rtp-nte codec g729br8 ! dial-peer hunt 1 !
Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com vs. 2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let’s look at what the SIP INVITE might look like prior to any modification to the above configuration:
Sent: INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0 Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7 To: <sip:+12065015111@sip2.att.com> Date: Fri, 20 Aug 2010 02:34:27 GMT Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com Supported: 100rel,timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 2682052728-2819953119-2264595576-2861407723 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1281926067 Contact: <sip:2065011001@177.1.254.1:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 69 Session-Expires: 1800 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 292 v=0 o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1 s=SIP Call c=IN IP4 177.1.254.1 t=0 0 m=audio 16532 RTP/AVP 18 100 19 c=IN IP4 177.1.254.1 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 a=rtpmap:19 CN/8000 a=ptime:20
! voice class sip-profiles 1 request INVITE sip-header Contact modify "<sip:(.*)@(.*):5060>" "<sip:\1@ine.com:5060>" ! dial-peer voice 1001 voip voice-class sip profiles 1 ! dial-peer voice 1002 voip voice-class sip profiles 1 !
Now let’s take a look at what that did to the contents of our Contact header in a new call, and thus a new SIP INVITE message that we send out to AT&T:
Sent: INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0 Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7 To: <sip:+12065015111@sip2.att.com> Date: Fri, 20 Aug 2010 02:34:27 GMT Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com Supported: 100rel,timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 2682052728-2819953119-2264595576-2861407723 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1281926067 Contact: <sip:2065011001@ine.com:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 69 Session-Expires: 1800 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 292 v=0 o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1 s=SIP Call c=IN IP4 177.1.254.1 t=0 0 m=audio 16532 RTP/AVP 18 100 19 c=IN IP4 177.1.254.1 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 a=rtpmap:19 CN/8000 a=ptime:20
Excellent! It did exactly what we asked it to!