Troubleshoot Call Setup & Media Establishment

0:00Welcome to this skill, "Trommishik Qa'al setup and media establishment."

0:03So in this skill, we look at several different Qa'al flows where we are

0:06receiving different

0:07responses when we're trying to setup a Qa'al. We also have a discussion on how

0:11we can approach

0:12troubleshooting media establishment. So let's see what else you want to recover

0:16in this skill.

0:16So in our first video, we'll have a review of a normal Qa'al setup and teardown

0:22.

0:22Then finally, now we'll look at a sip Qa'al flow, we'll receive it for the

0:26found,

0:28along with a 487 request canceled. Then we have three different scenarios where

0:32either inbound or

0:33on-ball calls to the ITSP are not functioning. After that, we'll see that we

0:38can execute

0:39certain commands on a command line and then we look at some factors that may

0:43come into play

0:43when it comes to troubleshooting media establishment. Then finally, we'll look

0:48at our

0:48final scenario where we'll receive a 488 non-assetteable media. So as always, I

0:54thank you for allowing

0:54me to be part of your journey and I'll see you in this video.

0:00So in this thing, it will go over a normal cost set up and turn it up.

0:03Now you've been with me throughout this course, this is a purely review.

0:06So we have a scenario where we have an inbound call from the ITSP to Pedro.

0:11So in a normal cost set up and turn it on, we have our request here,

0:15that being the invite. Then we have a 100 shrine, 180 ring, and 200 roll cap.

0:21These are our responses. Then an ACK, which is a request, is sent indicating

0:28confirmation that it received a final response to the invite request.

0:34Then we have media that is later established and eventually someone

0:36terminates this phone call. So here's a buy request.

0:40Then later we get a 200k, which is our response to that request.

0:45So this is the foundation here of a basic slip-call flow.

0:49And this is important, especially when looking at slip-call flows, attempting

0:52to

0:52determine what the issue is. This is exactly what we see in our

0:56call flow here. So this is Q, this is CUCM, this is Pedro, and his endpoint.

1:04So here we see invite, we see 100 shrine, 180 ring in, and 200 roll cap.

1:10Then finally we see our acknowledgement, which is confirmation that we received

1:14the final response, this being the 200k, to the invite request.

1:19With this invite, we see SDP information that we now know is

1:24the indication of early offer. So the media parameters, like the codecs,

1:28that we're going to use will be negotiated in the invite,

1:32and later we get a response in a 200k.

1:36So here we also have an invite being set to Pedro's phone,

1:39which is CUCM. And we can see CUCM sends an invite here,

1:44but there's nothing within the body. So this gives us an indication that this

1:48is

1:48the late offer. So with the late offer, the media

1:52parameters, like the codec, is negotiated in the 200k,

1:57along with the acknowledgement. So that's for you would find your SDP

2:01information. But let's do a live warsar capture here.

2:07So what we do is make a phone call from Pedro's phone.

2:10So let me start the capture here, but we're going to filter only SIP messages.

2:16So we're going to go off hook, we still notified there,

2:20the VDAL, out to the HSP. We see an invite 100 try and 180 ring.

2:26Now when I enter a call, so we initially saw the invite,

2:32the 100 try and the 180 ring in. Then once we entered the phone call,

2:36we saw the 200k, which was the final response to our invite.

2:40And then we saw our acknowledgement. And there we go, we have a basic review of

2:45the

2:45normal call setup and teardown for a SIP call.

0:00So, that's the other scenario, we have an inbound call from the ITSP, and I

0:05call it

0:05"Rotted to CCM", and eventually we get this "44" not found.

0:09So, let's bring over that call flow.

0:12So, we get an invite here.

0:15The number that the ITSP is trying to dial is 1,813-555-6523.

0:18So, we get a try back from CCM, so this tells us that we can't communicate with

0:26that CCM

0:27server.

0:28And then, eventually we get a "44" not found.

0:31So, let's go over to CCM.

0:35So, there's some over the call Pedro, there was a dial 1,813-555-2401.

0:41Now, in my environment, "241" is the "stentional Pedro".

0:46So, if we go to the device and phone, go to "fine", and we go to "Pedro's Phone

0:56", we

0:56see "2401" here, and you may ask, "Well, how are we transforming a translating,

1:021,813-555-2401,

1:062,2401?"

1:08So, you can do that on the cube itself using voice translation rules.

1:17And we looked at voice translation rules during serial core, and we'll revisit

1:23them later

1:24in this course.

1:25Now, I can also do the same using CCM by using lysing translation patterns.

1:32So if we go to "Car routing", go down to "translation pattern", I'll hit "fine

1:37".

1:37We have a couple here, but if I look at this one, for example, this will

1:42translate this

1:42number, the "x" being any numbers from 0 to 9, down to the "last" for "gets".

1:49So, this is how someone can dial 1, 813-555-2401, that being Pedro.

1:57See, some received that number, and with the translation pattern, it translates

2:01that to

2:01"2401".

2:02Now, I can see you see, we go to "Car routing", and go to "Rough planning port

2:09", and I can

2:09say "show me any patterns that match 2, 401".

2:12I would find, then we see a "dural 3" number here, which belongs to Pedro.

2:18As we can see, right there.

2:22So how about this number, 1, 813-555-6523?

2:27So based on the information that we just went over, I would expect to see a

2:31directory number

2:32somewhere in my system for 6, 5, 2, 3.

2:35So going back to CCM, let's go back to "Car routing", "Rough plan report".

2:42Let's do 6, 5, 2, 3.

2:43I would find here, and we can see that I do not have that directory number

2:48configured

2:49within CCM.

2:52And now we know the reason, but we received this 404, and I found from CCM,

2:57because CCM

2:58is telling you, I do not have this number within my CCM database.

3:04So in fact, let's bring up "washer", I have my phone here.

3:09Going to dial 1, 1, 2, 3, 5.

3:12I had a call here.

3:13"Your call cannot be completed, it's dialed.

3:15Please consult your directory and call again."

3:18So notice what happens if I wait here.

3:21Let me end up all, and I'll stop that wireshark capture.

3:29So we can see here that in by the sentover to CCM, we get a 100 shrine, we get

3:35the 183

3:36session progress where you play some media about a call being invalid.

3:40But I did get this 404 now found because I waited for the announcement to

3:43finish.

3:44What's what happens if I repeat this?

3:46What do not wait for the announcement to play out?

3:49So let me go ahead and start a new capture.

3:53I'll here read that.

3:54"Your call cannot be completed, it's dialed."

3:56And this time I'll end call.

4:00So let me stop the capture there.

4:02So notice here, we get a 487 request cancel, which we'll talk about in later n

4:07ugget.

4:08We did not get a 404 now found.

4:12For the reason being, we terminate the call during the 183 session progress

4:17when a media

4:18was being played to us before the fact that we would see a 404 now found.

4:24So in this nugget we went over a scenario where we received a 404 now found.

4:28And we saw the reason that we did get the response because CCM did not have

4:32that number

4:33within it. See you in the next video.

0:00So next we'll take a look at a sip car flow that has a 47 request cancel. In

0:04this scenario,

0:05Pedro makes it a phone call and later terminates that phone call.

0:09So Pedro is attempting to make it a phone call.

0:13So the question here is the call established or not. So did the destination

0:21answer the phone call.

0:22So Pedro did establish that phone call.

0:26So the other side did enter the call. So if the answer is yes here,

0:30then at some point Pedro determined that phone call we would expect to see a

0:36bite.

0:36And that's not what we see here. So the call wasn't established.

0:40So the destination is the example still ringing. And Pedro terminates that

0:45phone call.

0:45So at this point a cancel will be sent.

0:48So it really comes down to what the call established.

0:52In both cases Pedro did to remain the phone call. But if the call was indeed

0:57established we get a bite.

0:58If it wasn't established yet at that point we get a cancel.

1:01So taking a look at that call flow we have an invite. We have one who trying.

1:07We have 180 bringing here.

1:09So you can see the support for Prag here. But eventually we get a cancel.

1:15Now this call flow is from a perspective of Q.

1:19So we don't see the messages from the phone over to CUCM.

1:23But as soon Pedro hit and call at that point a cancel was sent from the

1:29endpoint over to CUCM.

1:31That's exactly what we see here that sent over to Q.

1:34Then we get a 200 okay to that cancel. Then we get a final response to the

1:40original invite that was sent right here.

1:42And the final response is 487 request cancel.

1:47So let's go back and do a live capture once again. I will hit start here.

1:52Let's go ahead and bring up our phone. I'm going to give the ITSP a call here.

1:58Now watch what happens when I hit and call what that phone is to ring in.

2:07So here we can see that the cancel was sent from this IP phone. It has the IP

2:14address 1012 CUCM.

2:16Then we see our final response that being a 47 request cancel.

2:21Let's run that test once again. I'll start new capture.

2:25I'm going to hit redot here.

2:28But this time I'll insert,

2:30put the call mutual voice feedback. Now watch what happens when I hit and call.

2:35Then we stop the capture now.

2:38So now we see that a buy was sent from the endpoint over to CUCM.

2:44For the reason being the call was already established.

2:46So in fact we have another call flow here.

2:51So this call flow is very similar. We have an invite on the shrine when it is

2:55ringing. We have a 200k.

2:57Followed by the acknowledgement. So this tells us that the session was

3:00established.

3:01So at some point Pedro terminated the phone call and then sent a buy over to C

3:05UCM.

3:06So in this again we looked at a sit call flow that contained a 487 request

3:11cancel.

3:12And the reason for this response because one side, in this case Pedro,

3:17terminated the call before it was established.

3:19[BLANK_AUDIO]

0:00In our next example here, incoming calls from the ITSP are not successful.

0:04So when we have an incoming call into my environment, the OutPair100 is the in

0:10bound

0:10DOP here, and then the OutPair 102 is the Aband DOP here.

0:16So here we see the DOP here of 100, followed by the DOP here of 200.

0:20Here we have the IP address of Q, and also shown here is the IP address that's

0:26defined

0:27in our script from within CCM.

0:30I have a YouTube here, I do have login enabled, I'll go ahead and include my

0:34log, we'll do

0:35a debug CCM set with messages.

0:39So what we're going to do is make an inbound call into our environment.

0:42So I would attempt to call Pedro, I head down there, and we'll see what happens

0:47here

0:47in a second.

0:48So you might not hear that, but that's the tone that we get.

0:54Let's go ahead and send that log over to our TFTP server.

1:00We'll name this inbound1.txt.

1:08So here's a conversation between ITSP and Q.

1:11And you see here this 404 not found.

1:14Now previously we saw this when the directory number is this within the CCM

1:18database.

1:19What we see here at the DOP number is 1A13-555-2401.

1:26Let's go to CCM.

1:28We can verify that directory number doesn't exist.

1:30I should show you I did not delete the offline before I had record.

1:35It's a call routing, route panam report.

1:392401.

1:40And here we see the endpoint for Pedro, therefore line 1 has 2401.

1:47So you know that in this case the directory number does exist.

1:52So we see the ITSP, we see Q, but notice we don't have any communication here

1:57with CCM.

1:59So what happened here?

2:01So let's take a look at this 404 in our found.

2:04And this will have some additional piece of information within the warning

2:08header here.

2:09It says no matching outgoing DOP here.

2:12So remember I said this call lag, the ITSP over to Q, we use DOP here 100.

2:20And then the DOP here from Q over to CCM should use the DOP here, 102.

2:28So look at this, we see DOP here, 100.

2:30This is the inbound DOP here.

2:35Then DOP here, 102 is the ABAN DOP here pointing to CCM.

2:39In fact we see the IP address of our subscriber, or I should say our series in

2:43publisher there.

2:46Now maybe your ISPite upon the fact that this says shutdown.

2:51When a DOP here is shutdown, it cannot be used by Q.

2:54So let's go ahead and validate that is the fact here.

2:57Let's go to Q, let's do a show run section, DOP here voice, I need my space

3:04there.

3:05Let's look at 102.

3:08So indeed we see the shutdown keyword there.

3:11And this DOP here will be used from Q over to CCM for the ABAN DOP here.

3:20But we see from our CIP call flow, we get a 404 and within that 404, we do have

3:26a warning

3:27header that states no matching outgoing DOP here.

3:31And that would be correct for the reason being DOP here, 102 is shutdown.

3:36So let's go back over to Q.

3:39Let me clear my screen there.

3:40We do a config T. We'll do a DOP here.

3:45Voice 102.

3:47We'll do a no shutdown.

3:49So now we look at that DOP here once again.

3:53So at this point this DOP here should be active.

3:55So now I'm making a test phone call once again from the ITSP over the schedule.

3:59This phone should ring.

4:01And it does.

4:03Let's put a mute there.

4:05So let's go back to Q.

4:09So let's see what DOP here is being used by doing a show call active voice

4:12brief.

4:12And we're going to include the peer ID.

4:15So we see here we have DOP here, 100 as the AMBON DOP here and DOP here, 102 as

4:20the ABAN

4:20DOP here.

4:22Since the DOP here was shut, that's the reason that we received a 404 and I

4:28found in our

4:28CIP call flow with the warning header once again of no matching outgoing DOP

4:34here.

4:35So once again we went over DOP here during the CIP call.

4:39So we should have some background or be familiar with DOP here at the moment

4:44and we'll further

4:45discuss DOP here later in this course.

4:48What the takeaway is is that we saw that 404 with the no matching outgoing DOP

4:53here and

4:54it should make you think which DOP here is being used for that call lag for the

4:59ABAN

5:00call lag between Q and CUC up.

5:03And the finally nugget will look at another scenario where incoming calls for

5:07an ITSP

5:07are not successful.

5:08>> Okay.

0:00So in our net scenario, we have the same issue incoming calls for the ITSP are

0:03not successful

0:05and you'd like the previous niggas, the inbound up here for cube is down here

0:09100

0:10and the upbound up here from cube over to cu7 is down here one or two.

0:15So here we have the IP address of cube and also the silt trunk that's

0:20configured within cu7

0:22also has the IP address 10.0.3.2.2.3.

0:27Alright, so my debug is still turned down from the previous nugget. We'll go

0:30ahead and clear the log.

0:31Let's go ahead and make that call inbound to our environment one more time

0:36and after a second, we can hear that tone in the background. So let me call.

0:43Alright, so let's send that out back to our TFTP server when in this inbound

0:50two, that THC.

0:54So as we already know, here's the ITSP, we have cube and here we have cu7.

0:59So we have an invite from the ITSP that sent the cube,

1:04cu7 is back over on a train as we see here and then we see an invite sent to cu

1:107.

1:11Now that this communication is one way, so we don't receive any communication

1:16back from the server.

1:17Eventually what happens here is that we get a 4.08 request timeout.

1:23So the reason here we got the 4.08 request timeout is because cube was unable

1:29to get every response back from the server.

1:31So looking at our configuration here, we have our inbound.op here

1:36and we also have our abound.op here.

1:40The server that's now responding has the IP address of 10.0.4.55.

1:46In this diagram here, what is the IP address of our cu7 server? It is 10.0.4.0.

1:5250.

1:54So this .op here is doing a job. It's being used as the album call link and

1:57running the call to this IP address right there.

2:00But this IP address, at least in my environment, does not exist. So in order to

2:04correct the issue,

2:05we need to go back to the .op here. So let's go to config team.

2:10Let's go to .op here, voice 102 and I fact finger that and there we go.

2:20And in fact, before I make the change, let's go ahead and verify the current

2:22config of that .op here.

2:24So we can see here we have the wrong IP address.

2:27So now let's go back to .op here. We'll go ahead and do session target

2:33ipv4 and then we do 10.0.4.50. We'll hit enter.

2:40So now we should have the correct config here, which we do.

2:46So now what happens if I hit readout once again, we'll pet just for a ring.

2:50And we can see that is the case.

2:52So in this again, we saw another scenario where within the call flow, we got a

2:59408 request

3:00timeout for the reason being that the album call link from Q out to CECM was

3:06referencing the

3:06wrong IP address. Once we made a change to the appropriate .op here, at that

3:10point, we're able

3:11to write that call correctly.

3:12[BLANK_AUDIO]

0:00So this time we have a scenario where we're dealing with album calls.

0:03album calls to the ITSP are not successful.

0:06So for an album call, the inbound dial peer is going to be dialed up here 100,

0:12and the album dialed peer to the ITSP will be dialed here 201.

0:17So once again we have our IP address, our Qube, and also our CUCM configuration

0:22, etc.

0:25Let's go ahead and see what happens when Pedro makes a phone call out to the IT

0:29SP.

0:29So I'm going to choose a number here, that number being 1773-55-1234.

0:36Let's see what occurs here.

0:39And that's the tone that we hear.

0:43So let's go ahead and do a live packet capture here.

0:47So this packet capture is taken from the perspective of Pedro's phone.

0:50So let me start it.

0:52I'll continue without saving.

0:56Let's go ahead and make that phone call one more time.

0:58So we see a 100 train, it hangs there, and eventually we get a message here,

1:07and the response or the status is 480, temporarily not available.

1:12So in fact, if we look on Qube, or I did have a debug turned on, if I do a show

1:16log,

1:17we don't see any entries, so this tells us that we're not even hitting our Qube

1:24.

1:24So for kicks, let's do a packet capture on CUCM.

1:27So we'll start a capture here.

1:29We'll name this outbound test one.

1:32We'll hit enter there.

1:34We're for that to start.

1:36So we'll make that phone call once again, and the same should occur that call

1:40should

1:40not complete, and we should hit our tone soon.

1:43Here we go.

1:45So I'll hit control C to stop that capture.

1:48Let's go ahead and transfer it to our secure FTP server, the name being out

1:53bound.

1:54That's one.cap.

1:57So at this point, we'll enter in the information for our server, and we'll be

2:01for our transfer

2:01to complete.

2:02All right, so our transfer is completed.

2:07And what we see here is the communication between Pedro's phone and CUCM.

2:13So we still see this 480 temporarily not available.

2:17What we would expect to see here is some communication with 10.0.3.253, which

2:24is the IP address of our

2:28Qube.

2:29So CUCM communicates to Qube over a SipTron.

2:32So let me go to device and trunk.

2:36So here's our SipTron over the Qube, and I do have options ping turned on,

2:41which CUCM

2:42uses as a keep a light mechanism, like a heartbeat.

2:45Are you there?

2:46Are you there?

2:47And for SipTron status, we see no service, and it's been out of service for

2:51about nine

2:52minutes.

2:53So let's go to SipTron and if you scroll to the bottom there, there's a portion

3:00of the

3:00disk configuration where we configure the IP address.

3:04So we see here the IP address, 10.0.3.253.

3:09And going to Qube, I do a show IP interface brief, and now I just go to the

3:14sign that

3:15is the same IP address that we see here.

3:17If I were to ping that CUCM server, we can see that we can communicate with CUC

3:24M successfully.

3:26But if you're looking carefully, we see a destination port of 5090.

3:31Say by default we'll use 5060 or 5061, depending if you're doing a secure step.

3:37So obviously this port isn't correct.

3:42So going back to my slide here, that port's really hard to see, but it does

3:47save 5090.

3:49So let's go ahead and correct this.

3:50We'll put the port 5060, we'll hit save, and then we'll go ahead and do a reset

3:55on this

3:56trunk.

3:57So we'll go back to the bison trunk, and we'll give this a moment here to

4:01refresh.

4:02So I'll wait about one minute or so, and then refresh the screen.

4:08Alright now we see for our CUCM we are in full service, and time in full

4:12service, zero

4:13minutes because it just came up.

4:16So now if I were to make a call once again from Pedro over to the ITSP, I'd

4:20read that.

4:21Let me see the call is successful.

4:27So going back to Qube, let me clear my screen there.

4:30If I check what dial pairs are being used, the dial pair between CUCM and Qube

4:36is the

4:36inbound dial pair of 100, and the outbound dial pair out to the ITSP is dial

4:43pair 201.

4:44So in this nugget, you and I look at the scenario where outbound phone calls

4:47were not

4:48successful.

4:49So even though we had the correct dial pairs in place, we were receiving a 480

4:54temporary

4:55now available.

4:57And now it's because within CUCM for our CIPChunk configuration, we had the

5:01correct IP address

5:03with the incorrect port to find.

5:04[BLANK_AUDIO]

0:00and this nugget will go over troubleshooting media establishment and we'll do

0:03so from the

0:04perspective of Qube. So we can use these commands for many reasons but in our

0:10case for this nugget

0:11we want to ensure the media information that was negotiated. So let's go over

0:17to Qube. So what you

0:18and I will do first is pin up a call. So let me have a call from the ITSP over

0:23the pejorole.

0:24So this phone should be here shortly. We'll answer it. We'll go ahead and put

0:28both calls on you.

0:30And the first command we'll show is show call active voice compact.

0:36So first thing we see is the quality. So this should be the inbound

0:43quality and then the outbound quality for this call. We have answered here and

0:48this would be our

0:49quality number. We have originated here and this would be our call number. But

0:55we can see here

0:56the code that was negotiated by being G7 11. This T 41 tells us the duration of

1:03this call in seconds.

1:04So keep in mind this is an active phone call. So if I were to repeat that same

1:08command,

1:09we see that number increased. We see peer address which is the phone number

1:14involved in each party.

1:16Then we have the IP address and the port number for the RTP stream. In fact, if

1:21we go to CUCM,

1:22we see that prejudice phone has the IP address 104, which is the same with

1:28p address that we see here. It would be browse to his phone and go to stream

1:34one.

1:34We see for local address, we have the IP address of prejudice phone and that

1:39port of

1:4022,330. That's the port that we see right there. Now for remote address, we see

1:47the IP address of Q

1:49but port 8,014. And we'll see 8,014 when we look at a different command. So let

1:56's do a show,

1:57voice of RP, RTP connections.

2:04Let me see source in this nation called IDs. But here we see the local RTP port

2:10from the perspective

2:12of Q. We saw in the previous command that the app on call egg was called ID 227

2:18.

2:19So going back to our show voice of RP RTP connections, we see that call ID 227

2:27is using

2:28the local port on Q for 8,014. And that's the same port number that we see

2:33right there.

2:34In fact, let me go ahead and decrease the font just a little bit.

2:39So I was trying to decrease my font so we can align these columns. But here we

2:45can see the

2:46local port along with that remote port. So we see 22,330. That's also the port

2:53that we see right there.

2:55So going back to Q, let me go ahead and clear my screen there. Let's do a show

3:01call active voice

3:04brief. Let me scroll down a bit. And I want to focus on this body of touch

3:10right here.

3:11So once again, we have call ID 226 227. So we have the PR ID. So this is dialed

3:18here 100

3:19for the inbound dial here. Then we have dialed here 102 for the onbound dial

3:25here.

3:25So here we have the calling number. Then here we have the call number. So we

3:32have the IP address

3:33of the IP S P of the endpoint that being federal. But here we can also see

3:37which codec was being

3:39negotiated. And this case being G7 11 U law. These are three commands that we

3:46can use to verify

3:48the media that was negotiated. And we also have debug voice to IP CC API in out

3:54. This command

3:55here traces the entire path of the call from beginning 10. And it does so via

4:02the call control API.

4:04So offline, I went ahead and ran that debug and I exported to a file via TFTP.

4:13But you can get a

4:14good indication of how much information is in this file. Now keep in mind this

4:19was an inbound call

4:20from the IP SP over the Pedro. And you can see a lot of information here

4:25breaking down the

4:27execution of the whole entire call. So at this point, my goal is not to show

4:30you how to read

4:31this from beginning 10. Let me focus on a certain portion of this debug. So

4:37here, Q receives the

4:39capabilities from this call leg of 192. And we can see a codec specified here.

4:46Later,

4:46Q acknowledges this. This is coming from call like 191. Well, we can see the

4:52codec that we are

4:53acknowledging that being G7 11 U law. So once again, at this point, don't be

4:58too overwhelmed

5:00from the output here. My goal was to show you with these commands, we're able

5:05to see what media

5:06was negotiated for a call that was established. And then finally, nugget, we'll

5:11go ahead and examine

5:12other factors that we can look into when it comes to troubleshooting media

5:17establishment. Thank you.

5:18[BLANK_AUDIO]

0:00So next, we'll look at other factors that may come into play when it comes to

0:04troubleshooting

0:04media within Qube.

0:06So these are questions that we should be asking.

0:10And some of these questions we answer with the appropriate debug or show

0:15command.

0:16First question being, does this issue happen randomly?

0:18If the answer is no, then we easily could reproduce the issue, which makes it

0:23easier

0:24to get a packet captured, for example.

0:26We could also use the appropriate debug and show commands to help us troublesh

0:31oot the

0:31issue.

0:32If the answer is yes, it does happen randomly, that makes your job a little bit

0:37more difficult

0:38because oftentimes we need the event to happen in real time so we can collect

0:42logs.

0:43So you might have to enable the spanning of a port, spainby and acronym for

0:47switch port

0:48analyzer, and then hope that we can capture the event happening.

0:52Next, we should grab a detailed description of the issue.

0:56Is the problem making an inbox phone call or a bound?

1:00Is it calling a specific number, for example?

1:04Is the issue about the quality of the voice?

1:06Is it choppy?

1:07Is there a message that was played at some point during the call setup?

1:12Knowing somebody's answer is we hope you narrow down your troubleshooting or at

1:16least

1:16give you an idea where you need to big deal the troubleshoot.

1:20Our next question is the media, the RTP, flowing through Q.

1:26We have media flow through.

1:29We also have media flow around.

1:35With media flow through, which is the default in many cases, the media and the

1:40signaling

1:41packets terminate on Q.

1:44The media flow around as the name indicates, the signaling terminates on Q, but

1:51the media

1:52bypasses Q entirely and flows between source and destination.

1:56So in this case, if the answer to this question is no, then Q has nothing to do

2:00with the media.

2:02So any of you that we do have a problem with the media, we have to focus on

2:06source and

2:06destination, those endpoints and the networks in between those.

2:11So let's put devices involved in the call flow.

2:15This is good to get the entire picture or understanding of the call flow from

2:19beginning

2:19to end.

2:20So we can use debug and show commands once again to verify the IP addresses

2:26along with

2:26ports that are being used in the media path.

2:31Sometimes you may find it the wrong IP addresses and ports are being referenced

2:35.

2:35So next, which codec is being negotiated?

2:39So let's say you have remote sites, there are a number of nowhere.

2:44Any sites have low bandwidth and for that reason, we're using G729.

2:48And once again, with the appropriate show commands, if we find out that we're

2:51actually

2:52doing G711, especially over those low bandwidth links, at that point, that may

2:58explain why

2:59we have poor media quality.

3:01So now, so there are any ACLs or active controllers being used.

3:05And if so, are we blocking certain IP addresses or ports?

3:10And therefore, that's the reason that the media is not being established.

3:13Are there any firewalls involved in this path?

3:18Just like access control lists, if we're blocking certain IP addresses or ports

3:22, that

3:23definitely can cause audio issues.

3:26The Vining are the media bindings correct.

3:29And it should say, "Duh, not there."

3:31So when a media binding, we're binding an interface on cube and that interface

3:37has an

3:38IP address associated with it.

3:39And this is the IP address that cube advertisers.

3:42So for example, if the interface is 10.10.10.100, well, cube also has another

3:49interface, 10.11.101.

3:53This IP address of 101 should be the IP address advertised.

3:58For the reason being, our devices can route to this IP address.

4:02The binding was to this IP address and the devices cannot route to that IP

4:07address.

4:07And then at that point, we would have issues with the call set up and also with

4:12the media.

4:13And I'm going to be the first to tell you that the troubleshoot media is

4:16definitely a

4:17challenge.

4:19And once you see here, some of the questions that you may ask to narrow down

4:22your troubleshooting.

4:24I'm confident I won't fulfill an entire course just with troubleshooting media.

4:28But here, asking the right questions and knowing what commands that we should

4:31execute to find

4:32out further information will definitely give you a good starting point.

0:00So here in our last scenario, all hebound calls for the ITSP cannot be

0:04completed.

0:04In fact, here we see in the sip call flow that was provided, we've received a 4

0:0988 non-acceptable medium.

0:11All right, so let's verify this. We'll go ahead and do a debug CC sip messages.

0:17I do have login turned on, so let me clean my log. Let's bring up our phones.

0:23I'm going to hit readout here in the ITSP and see what happens.

0:29I hope you can hear that tone in the background.

0:31So that I've called it not complete. So let's go ahead and send that to our TFT

0:36P server.

0:37So you see invite me Q and everything seems to be pretty normal. We'll be look.

0:44The ITSP is offering D711. So from Q, we get back a 488 non-acceptable.

0:53So from Q, we get a 488 non-acceptable media. So we saw that the ITSP was

0:59offering G711.

1:00But Q for whatever reason did not like that and send back the 488.

1:05So in my environment, the dial up here, or I should say the inbound dial up

1:10here,

1:10that is used is dial up here 100. So let's go ahead and take a look at the dial

1:15up here.

1:16We'll do show run section dial up here voice 100.

1:22And we see a configuration here. What the dial up here is configured for an

1:26advanced audio coding

1:28codec. So what's occurring here is that the ITSP is offering G711 in its

1:33negotiation.

1:34So I put ITSP here. But Q based on the dial up here configuration,

1:41is only configured to accept this advanced audio coding codec. So therefore, we

1:46don't have a match

1:47here. And that's the reason Q sends back this 488 non-acceptable media. So we

1:53can fix this. We're

1:55going to dial up here voice 100. And for codec, we're going to hard code the G7

2:0111 U-Law.

2:02For the reason being the ITSP told me that they only support G711. So with that

2:09in place,

2:09if I make that phone call once again, and read dial, what happens here, they're

2:14quite

2:14now successful. So if I do a show call active voice brief,

2:22let me just put just a little bit there. We can't see dial up here 100 for the

2:29inbound dial up here and dial up here 102 for the up on down here. And now we

2:33have negotiated

2:34G711 as I quote it. So in this, again, we saw a call flow where we received a 4

2:4088 non-acceptable

2:41media. And it's important to know what dial up here is that we are expecting to

2:45be used.

2:46So in this case, dial up here 100 for any cause coming from the ITSP. And then

2:50looking at the

2:51configuration for that dial up here, we saw previously that we were advertising

2:55a codec

2:56that was not supported by the ITSP. They're modifying the dial up here to

3:01advertise the

3:02correct codec, resolve their issues.

3:04[BLANK_AUDIO]

0:00Congratulations on making it to the end of the skill. Next you and I go to our

0:03validation where we answer series of questions

0:06We're forcing the knowledge that you will not obtain in this skill. Just get

0:09started and dive in

0:10All right, we can see here. We have several images that we can reference. So

0:15question one

0:15What is the calling number?

0:18So let's go to our first image here. This is so called active voice compact

0:22And we can see here that we have the

0:26Answer or the originated the answer is the calling number or calling party and

0:32The originated is the called party

0:35So based on this screenshot the calling number is two four zero one and the

0:39call party is one seven seven three five five five

0:42One two three four so here Pedro made a album call out to the I2SP. Let's look

0:48at the other screenshot here

0:51So we also see the answer here. That's for the two four zero one the calling

0:55party and the originate

0:57They mean the cloud party

0:59With the number that ends with one two three four

1:01So let's go back to our question. So the calling number is Pedro at two four

1:07zero one

1:08I hit submit. We also saw that the cloud number was the number out on the I2SP

1:14That's the number here that ends with one two three four and I hit submit there

1:19And that's question what ports being used for media by pejos endpoint

1:24And here we have a clue here that the endpoint has the IP address of 10.0 that

1:293.104. So let's go back to our images

1:31So here on this first one

1:34Here we have Pedro's IP address and a port of

1:372358

1:40Let's look at the other image here and we also see here for Pedro the port

1:45being used

1:462358

1:50And

1:52Here for show VoIP RTP connections

1:54We can see for pejos endpoint of 10.0.3. The 104 we also have port

2:012358

2:04So going back to our question our answer is 2358

2:09So next what are the inbound and not bond up here is being used

2:16So let's go back and we saw in a previous look it that would show call active

2:21voice brief

2:21We scroll down a bit this output would show us the peer ID

2:26We can see that the appear 100 is being used for Pedro who is a calling party

2:31That's the person that initiated the phone call

2:33Then now peer 201 is being used for the album calling out to the I2SP

2:39So this number here is the call party

2:43So our answer would be for the inbound up here. That's 100. I'm going to be up

2:47on the up here

2:48to one so let's go back to our question there and

2:51So the inbound up here is 100 and the album is to one

2:56And our next question where do we see which code it was negotiated?

3:02So let's go back up and let's look at our first screenshot

3:06We can see here that g7 11 was negotiated

3:11And we look at the show call out the voice brief

3:13We also see g7 11 there

3:17Then we show voice of IP RTP connections that's information that we don't see

3:23within this upload

3:24So going back to our question the answer is g7 11 you law right here

3:30So in our final question what is a local port cube using for media for the call

3:36between Q and Pedro

3:39So going back up to our images the output that we want to focus on is this show

3:44voice of IP RTP connections

3:46So here is the IP address of Pedro's endpoint

3:49And we can see here the port being used locally on Q is

3:538,020 so with that being said let's go down and choose that answer

3:588,020 and there we go so with that our data instruction is complete and I will

4:04see you in that skill

4:05[BLANK_AUDIO]