Part-5 Troubleshooting Inbound SIP Trunk Calls on CUBE and CUCM

so today we are gonna do a quick troubleshooting of an incoming PSTN call so call that is received by a cube will be sent to the Cisco Unified Communications Manager and then will be answered on the Cisco jabber hey guys welcome to my channel my name is Amit Singh and I thank you for visiting my channel and watching my videos I hope you guys are liking this if you haven't yet subscribed to my channel please do so and share this information with a lot of people that you think would need help so let's get quickly started okay so let's start with the testing so the first call that we would test now is an incoming call all right fellas I think you guys are now a little bit more informed about the cube call configurations and everything so let's get the ball rolling okay so let's also enable few debugs so I will say debug CC sip messages so this would allow you to see the sip in whites and if there are any problems and all these informations and I would also say debug by CC API in out this would help you to see if there are any codec mismatches and what are the incoming and outgoing dull peers that have been matched okay so let's make some calls so I'm making my first call so the real D ID number that I should dial is you know nine one nine four seven two and then I think it's four four zero two and the expected result should be that you know the call reaches this jabber user that ends with double 7 double 0 let's see what happens when I make the call if we have the right translations in place and what happens next so I've placed a call now and let's see if there is a call I'm just waiting oh that's good you hear of us busy all right so let's stop this and let's see what's going on with this call why is this incoming call so I dialed this number from a PSTN mobile you know and I tried to reach this number nine one nine four seven two four four or two this is the PSTN number and this is the number that should be translated to seven 700 at the end so it should be like plus 1 408 triple five seven seven zero zero you know and then it should work I mean we have we have checked the translation rule was in place right the last time so what happens why is this number not matching all right so let's to show logging and let's see some information what was it why is it not working so you see that you received an invite for the number nine one nine four seven two four four Oh - this is the received in white you know that means this is an incoming call and this is received on the external interface of this router and who has sent this in white so as we know this is the IP address of the provider so we have received the invite really from the providers IP address okay and then this is the PSTN number that was dialing this call you know and it was sent for this number that means it should match the extension seven seven zero zero at the end all right so what happens next after the invite that's an incoming in white so if you see here there is an SDP information that means the provider is sending an early offer for an incoming call with all the information where should the calls media be connected to that's the IP address and then what is the codec that it supports g.711 new law and then the telephony event 101 right the next that you see is the cube sends 100 trying and where does it send it sends back to the provider on 10.1 got 40 dot 11 okay and then you see again that the cube forwards this in white back or not back but the forwards it's in white to the sea you see em and then if you see here the number is translated the number is translated to +1 408 triple 5 4 4 over 2 that means that's the wrong translation right it should be translated to +1 4 oh a triple five double 7 double zero because we want to call a user with the number double 7 double zero and not double four double double 4 zero 2 and this is why if you see back that the see you see M will be sending back so first this UCM sends 100 trying you know it's received from the cesium and then you will see that received 404 not found that means this number was not available to the Cisco Unified Communications Manager database and this is why we heard a fast busy alright and then if you see that the AK is sent back to this you see M by the cube and then the cube will send 404 not found to the provider at the same time okay and then you will see that the provider has received send and AK as well so this is the received AK from the provider alright so now let's just check what's wrong with our translation so show run pipe section translation voice translation right enroll I think okay good we saw we said that any number that comes in with this with the last four digits anything please translate it to plus one for Oh a triple fie and the last four digits keep it as it is that's why we said one one means keep the matching as it is or the rest as it is okay so that's why this translation rule was matched but the number was incorrect okay so let's create another rule to translate the number correctly so we will say voice translation - rule 1000 let's just create a static rule rule - I will just copy this rule here and we'll just make a couple of changes and here I will statically say match double seven double zero alright or the other way is I will say four four zero - you know if this is the case then triple five keep this piece right so it will now translate let's now just do a test so we will do test voice translation - rule 1000 and then the number is nine one nine four seven two four four zero - there's a number that is being sent by the provider to the cube - call seven seven zero zero oh it still matches nine one nine four seven two four four zero two and then it matches the rule one and it doesn't match the rule - alright so voice translation - rule one thousand and I will say no rule - and I will say let's just create a static rule and I will say rule and I will just copy this again let's make it this time static so I will say double seven double zero that's the number that I'm trying to match and then if there is anything that matches nine one nine four seven two four 402 just translate that number to this thing plus one 408 triple five double seven zero all right let's stress now test voice translation rule one thousand nine point nine four seven two four four zero two and you see it still matches rule one because of the longest match criteria because both are one and the same so let's go ahead and just interchange those rules so let's say voice translation - Roli 1000 and then I will say for the rule 1 I will say seven seven zero zero and then here I will say here four four zero two so that's my rule number one okay so let's just remove roll - and then roll one again and then we will create a rule - so we are just interchanging we are making rule one as rule two and rule two as run rule 1 okay let's test again what happens nine one nine four seven two four four zero two and now you see that the priority is not given to rule one because these two rules have the same same match same match and that's why it was always giving the priority to rule one you know so now after I just interchanged the rule priority you see that let me show you the rules again show run pipe section voice translation - rule 1000 you see here I just change the priority of the rules I didn't change anything else you know and that's how it matches now rule one instead of rule - and now the call should be rightly translated - seven seven zero zero and then it should be reached to the Cisco jabber phone okay so I'm gonna make the call again let's see what happens this time all right and then we still hear a fast busy now what's the problem let's check now let's go ahead and see again the logs so I will show logging I just go at the end of this message because there are a lot of logs all right and then here you see that we still receive a 404 not found from the Cisco Unified Communications Manager so basically I will show you also the invites you know so this is the received invite from the provider on this number and then to the cube and then there was an incoming dial PR match and then the outgoing dial pier match and then cube send a 100 trying back to the provider and then we sent an invite back or sorry I sent an invite to the Communications Manager now with the right number Wow so at least the translation rule is working now we have +1 408 ruble 5 double 7 double 0 and if we see the user it has the same number as well you know so it has the same number but still the call is not working and the C UCM is sending a 404 not found okay so let's see what is the issue if there is an issue how can we resolve it so let's go to Cisco Unified Communications Manager and then let's just see what's the problem in the Cisco Unified Communications Manager because now we know that cube is sending it correctly it's again and again coming from Cisco Unified Communications Manager so there is definitely a problem with this is co unified communications manager okay so let's just check in the cube if the cube is correct or not if the SIP trunk configuration for the cube is correct alright so what will happen here is so this is your let me open maybe we can was that's good right what will happen here is the cube will send an invite to the co CM SIP trunk you know and in the SIP trunk there should be an access provided or should be a CSS on the incoming CSS so that it could either reach the device or it could either match any translation pattern or whatever you know so it needs to have access here so what we should check really is if there is a CSS available on the SIP trunk so that it can send the call to that particular device and is it reachable okay so let's just see if we see at the incoming CSS very good we do not have any CSS being assigned and if we check the phone or the directory number route plan directory number there should be a phone number that ends with 7700 and if we have a look this is in a partition and that's why the call is failing because the SIP trunk has no access to this partition you know and this is why it was sending back a 404 not found you know because it cannot reach that partition the SIP trunk cannot reach that partition and that's why it was sending a 404 not found back to the cube and then cube was sending it back to the provider all right so let's create a CSS and we will give it as inbound cube CSS and then we will assign a base partition to this cube CSS and then we will assign this to the SIP trunk the CSS to the SIP trunk all right and then we make sure that this cube is in full service now you see that the status has changed so that means the cube reset was done so it says options being not enabled and it will take around one minute to come up ok so now we see that the cube is in full service or the SIP trunk is in full service and let's try to attempt another call and this time it should be fine I think I will at least I will do clear logging and then let's just see what happens next fingers crossed this time the call should connect and voila you see that there is a call I am able to answer it and let's just see all right so I've disconnected the call and I see that I you saw that I made this command so as to check what is the codec that is being used and you see that the codec end-to-end is used as g.711 you long alright so this is the way that you could check the codec that is being used and then who is the originating who has who is the answering party and who is the or originator and then also you could see the VoIP RTP connections so which are the IP addresses that are involved in the RTP packets you know so these are the local IP addresses and these are the remote IP addresses that were involved so it is a jabber and then the PSTN phone IP address or the service provider IP address you know so this way you could confirm that your codec is used correctly and then the RTP connections are fine and then let's just have a look at the call information so here you see that this is the received in white from the provider and it was received on this interface that's the kick 0 / 0 / 1 so when interface on the cube this was sent by the provider that you see in the via header that means the wire header has matched the correct dial peer you know so because we said match the incoming van Dyle peer on the wire header and it has matched on that you know and that's why they call has been received so it was an early offer here we will see all the informations and then this is the output of Y PCC API in out and here you should see that the incoming dial per that was masked was 2001 it was masked on a wire header and then the cube sent 100 trying back to the provider and then again there is an outgoing the LP air match so it's a outgoing dial pr1000 that has been matched you know and then once the dial Pierre was matched then the translation profile was assigned and that's how the number got translated from 9 1 whatever it was 2 plus 1 4 Oh a triple five double 7 double zero okay it was not before the matching of the dal Pierre very important the dial Pierre after matching off the dial Pierre the number was translated you know you see here the called number okay and then you will see that after the dial Pierre everything was done then the SIP in white is being sent to the Cisco Unified Communications Manager at the IP address there that we have mentioned it as a session target 198 18 130 3.3 all right I think it's a long session so I would not include the outgoing dial Pierre and this testing in this so we did a little bit of troubleshooting I think I hope you guys understood how was it done so it's really necessary to analyze the log sometimes if you have some fast busy problems and why who sent the error message back or who sent in our case now for example the Cu cm was sending the message back even though there was the problem on the cube right I mean the first problem was on the cue that the translation rule was not correct but still the caesium was sending okay 404 not found why because see you sim was receiving a wrong for wrong directory number right so it's not the problem of the see you see M actually it was the problem of the cube and then there's second problem was on actually actually on the SIP trunk because the SIP trunk didn't had the CSS so it couldn't access the directory number to which the cube was trying to reach okay so that's why the next time we assigned the CSS the call went successfully and it was able to reach correctly with the right codec information alright so in our next video we'll talk about our outgoing call and we will see and troubleshoot some interesting things and I hope you guys would like it and after this we will be discussing about you know the different ways that al pair could be configured how we could transform these four dial peers into two and then make it compact and really easy to understand so a lot of interesting stuff to come guys you know keep sharing this information let's go all out and learn something more during this time of kovat 19 and make use of this time to make ourselves better engineer all right I thank you everyone for watching my video and do not forget to watch my next video that's coming in in next week until then thank you bye bye take care

Channel: TrainCollab

Views: 5,859

Keywords: cucm, cube, collaboration, SIPTrunk, uc, troubleshooting, ITSP, SBC

Id: 40bit6cyQ_Q

Length: 26min 8sec (1568 seconds)

Published: Sat Jun 06 2020