Like with most new technologies, beginnings can be painful. With ITSP trunks,it is no different. The lack of specific rules and instructions can lead to a daunting experience when trying to deal with CUBE Registration with ITSP. We have all been there, the rough first implementation of CUBE and the bliss of overcoming the obstacles, just to find out that the next CUBE implementation will lead us through a whole new path in an uncharted territory. And it is not our fault either! We read, we researched, we took examples and yet, the the hurdles are just getting more complicated. The problem is, there are too many possible scenarios. Some of the main reasons for the massive variations are: ITSPs has to support a wide range vendors, thus, interpretations of IETF. Different ITSPs use different vendors softswitches and architectures. Our own designs, products and versions vary from customer to customer. Hence, variations in deployments are unavoidable. Fortunately, these problems are solvable, as long as we understand some basic concepts. In this post I'll cover the CUBE Registration and CUBE Authentication concepts as they are the core of our communication with the ITSP. Get ready The hard truth is, more often than not, the customer mails us this poor scanned fax that he received from the ITSP, which usually includes three lines: username, password and IP address. Well yippiee ki-yay!! Didn't I just win the lottery!! At times, it felt like it would be easier to extract information from a spy.. So, if we don't want to spend the night chasing ghosts, we have to ask the right questions! The bare minimum that we have to discover is the ITSP's approach to registration and it's approach to authentication. Mentally note that these are two different concepts with different roles. Let's see what they are all about. CUBE Registration Ever wondered what registration to ITSP is really for? Well, I did, and to be honest, too late for my own good. Simply put, registration is there for the ITSP to know that you are alive and kicking and more importantly, where to send your incoming calls. It's just like registering your name with your home address so that your bills will come to the right place. In most cases, ITSP does not statically configure your CUBE's IP Address in their systems to send you the SIP traffic. That's what registration is for, to dynamically manage the location of each customer's DID. This is obviously a great advantage for the ITSP, but we can find it handy as well, as you'll notice in the troubleshooting section. Enough said, let's get to work. Parameters required: Username Password Registrar server IP/FQDN Realm (domain) Do note that these are the parameters required for registration alone. For a successful cut-off, more information is needed. You can find the full list here. Command syntax: sip-ua registrar [dns:/ipv4:/ipv6:] registrar-server-address credentials username username password [0/7] password realm realm For example: Username: ucpros Password: 123456 Registrar server IP/FQDN: SIP.ucpros.net Realm: ucpros.net sip-ua   credentials username ucpros password 0 123456 realm ucpros.net   registrar dns:SIP.ucpros.net Verify and troubleshoot The first step would be making sure we are not shooting blanks! Easiest method to verify that we are indeed registered to our ITSP is running: CUBE#show sip-ua register status Line                             peer       expires(sec) reg survival P-Associ-URI ================================ ========== ============ === ======== ============ ucpros                           -1         56           yes normal CUBE# If our first attempt was unlucky we would need to understand why. Run both of the command below to see CUBE registration attempts: Debug ccsip messages Debug ccsip non-call Watch the response code from ITSP to understand the reason for the failure. It should put you back on the right track. Remember me mentioning in the beginning that dynamic registration to ITSP can help us with our troubleshooting? We'll, I wasn't lying! Dynamic Registration means that you can actually register to your ITSP from every device who has the right credentials. Although not the most uplifting thought security wise, it means that if everything you try fails, try and register a softphone with the ITSP using the same credentials. The advantage of it is, that usually these softphones only require the most basic info like username, password and domain. The softphone will then automatically apply this info into the SIP messages. Personally I use MicroSIP but there are many other options. If you manage to register with your softphone, it means that the ITSP is at least doing something right, so open your Wireshark and compare the SIP messages from CUBE registration attempts with the ones generated by your softphone. Watch the differences in the SIP headers to understand what went wrong. Using a simple softphone is also great for troubleshooting a lot of other CUBE problems. Whenever you reach a dead end, use it to compare CUBEs behavior with another device. CUBE Authentication As opposed to registration, authentication is actually a method that ITSP uses to verify your identity. Essentially, it uses authentication to decide whether we are allowed to make this call. The role of authentication, from ITSP's point of view, is to allow you to make outgoing calls. Without it, every call attempt would be accepted and that's, well.. unacceptable! In most cases, authentication should be pretty straight forward, if you pay attention to details that is (clue: skip to the troubleshooting section if you can't bear the suspense) Parameters required: Username Password Realm (domain) Command syntax: sip-ua authentication username username password [0/7] password realm realm For example: Username: ucpros Password: 123456 Realm: ucpros.net sip-ua   authentication username ucpros password 0 123456 realm ucpros.net Verify and troubleshoot Configuring authentication seems simple enough, but whenever it poses an issue or outgoing calls are failing, open your eyes for the following common pitfalls. Now, let's get to business and turn the debug ccsip messages on! This is what you would usually see: (showing only communication between CUBE and ITSP to simplify the output) Following is an Invite message sent from CUBE to ITSP. Watch the from field. The syntax should contain either your username or a number out of your allocated DID range! Anything other than that and your call won't go through. Do pay attention to the number of digits as different ITSPs might have different requirements for the calling number. What some of us are missing, is that the from field is actually one of the authentication parameters. Oct 23 12:15:13.648: //44/570577000000/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:403454@iptel.org:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK3AD75 Remote-Party-ID: "ucpros" <sip:100@192.168.1.20>;party=calling;screen=yes;privacy=off From: "ucpros" <sip:ucpros@ucpros.net>;tag=345CA8-1182 To: <sip:403454@iptel.org> Date: Sun, 23 Oct 2016 12:15:13 GMT Call-ID: 2F3B7D9F-985111E6-8008865A-F6ED7E07@192.168.1.20 Supported: timer,resource-priority,replaces,sdp-anat Min-SE:  1800 Cisco-Guid: 1459975936-0000065536-0000000001-0167880896 User-Agent: Cisco-SIPGateway/IOS-15.5.3.S2 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1477224913 Contact: <sip:100@192.168.1.20:5060> Call-Info: <sip:192.168.1.20:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" Expires: 180 Allow-Events: telephone-event Max-Forwards: 68 Session-Expires:  1800 Content-Length: 0 Oct 23 12:15:13.759: //44/570577000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK3AD75;received=87.71.31.219 From: "ucpros" <sip:ucpros@ucpros.net>;tag=345CA8-1182 To: <sip:403454@iptel.org> Call-ID: 2F3B7D9F-985111E6-8008865A-F6ED7E07@192.168.1.20 CSeq: 101 INVITE Content-Length: 0 Next, we can see a challenged response from ITSP Pay attention to the Digest Realm field. That is the realm you should configure in your Authentication command under sip-ua Oct 23 12:15:13.766: //44/570577000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK3AD75;received=87.71.31.219 From: "ucpros" <sip:ucpros@ucpros.net>;tag=345CA8-1182 To: <sip:403454@iptel.org>;tag=78A48057-580CA9D1000A93BC-CAD9A700 Call-ID: 2F3B7D9F-985111E6-8008865A-F6ED7E07@192.168.1.20 CSeq: 101 INVITE Proxy-Authenticate: Digest realm="ucpros.net", nonce="WAysJlgMqc7UL30vd9AwPJsK+KVESIx/" Server: ser (3.3.0-pre1 (i386/linux)) Warning: 392 192.168.0.85:5060 "Noisy feedback tells: pid=1812 req_src_ip=192.168.0.155 req_src_port=5060 in_uri=sip:403454@iptel.org:5060 out_uri=sip:403454@iptel.org:5060 via_cnt==1" Content-Length: 0 Oct 23 12:15:13.767: //44/570577000000/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:403454@iptel.org:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK3AD75 From: "ucpros" <sip:100@ucpros.net>;tag=345CA8-1182 To: <sip:403454@iptel.org>;tag=78A48057-580CA9D1000A93BC-CAD9A700 Date: Sun, 23 Oct 2016 12:15:13 GMT Call-ID: 2F3B7D9F-985111E6-8008865A-F6ED7E07@192.168.1.20 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Content-Length: 0 Here CUBE sends another invite, this time with the Authentication details: Oct 23 12:15:13.767: //44/570577000000/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:403454@iptel.org:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK3B6A8 Remote-Party-ID: "ucpros" <sip:100@192.168.1.20>;party=calling;screen=yes;privacy=off From: "ucpros" <sip:ucpros@ucpros.net>;tag=345CA8-1182 To: <sip:403454@iptel.org> Date: Sun, 23 Oct 2016 12:15:13 GMT Call-ID: 2F3B7D9F-985111E6-8008865A-F6ED7E07@192.168.1.20 Supported: timer,resource-priority,replaces,sdp-anat Min-SE: 1800 Cisco-Guid: 1459975936-0000065536-0000000001-0167880896 User-Agent: Cisco-SIPGateway/IOS-15.5.3.S2 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 102 INVITE Timestamp: 1477224913 Contact: <sip:100@192.168.1.20:5060> Call-Info: <sip:192.168.1.20:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" Expires: 180 Allow-Events: telephone-event Proxy-Authorization: Digest username="ucpros",realm="ucpros.net",uri="sip:403454@iptel.org:5060",response="sad234324fsd234sadAWD12315",nonce="WAysJlgMqc7UL30vd9AwPJsK+KVESIx/",algorithm=md5 Max-Forwards: 68 Session-Expires: 1800 Content-Length: 0 Oct 23 12:15:13.875: //44/570577000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK3B6A8;received=87.71.31.219 From: "ucpros" <sip:ucpros@ucpros.net>;tag=345CA8-1182 To: <sip:403454@iptel.org> Call-ID: 2F3B7D9F-985111E6-8008865A-F6ED7E07@192.168.1.20 CSeq: 102 INVITE Content-Length: 0 Wrap-Up True, setting up CUBE registration and authentication with ITSP can be a frustrating task, but when you understand the concepts and the minimum required, to allow incoming and outgoing calls you are halfway there :) Our spiritual father, Alexander Graham Bell said: Before anything else, preparation is the key to success Bell is here to remind us, that in order to make it look easy, we have to do our homework and get the max info we can from ITSP before D-day. We must show up to the cut-off, as prepared as possible. If you encounter difficulties, follow the troubleshooting steps, they will point you in the right direction. Don't be afraid to use a softphone if troubleshooting hits a dead end, It's like getting a second opinion. It will also help you determine, whether the problem lies with your configuration or the ITSP's. Understand the concepts described here, and this post will be a long forgotten memory. If you need help with other aspects of CUBE, I've written two-part, step-by-step post that covers the main concepts. You can also download the CUBE Config Utility to help you create clean, professional, resource sensitive and best practice driven CUBE configuration. Best of luck! Pasha. ... View more