What is this active 'call'?

voip7372 · ‎01-18-2017

I see this when I do a 'show call active voice compact' and it's showing up when I do 'show sccp connection'. It appears to be for transcoding, but I'm skeptical if it's really a live transcoding session. It's been there for over a day now in our CUBE router. Our other CUBE router is completely idle (we're not using them in production just yet for SIP calls from the PSTN, but they are setup for providing transcoding, conference and MTP resources to CUCM).

Is something stuck and needs to be cleared or do you think this is truly a valid active session? It's a 4351 router with a 256 channel PVDM4 module. The only IP you see there is the CUCM server (but I changed the IP for public posting).

If it's something that's really stuck, how would I clear that without rebooting the entire router? I already tried resetting the PVDM4 module but the call or whatever it is is still there (test dsp device 0/4 all reset).

CUBE#show call act voi com
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
Total call-legs: 2
216 ORG T14523629 g711ulaw VOIP P 172.16.5.38:31300
14561 ORG T175995 g711ulaw VOIP P 172.16.5.38:30412

CUBE#
CUBE#show sccp conn
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

50627241 50544340 xcode inactive g711u 10548 30412 172.16.5.38

Total number of active session(s) 1, and connection(s) 1

CUBE#show voice dsp group all
DSP groups on slot 0/4 slot id 4
dsp 1:
State: UP, firmware: 40.2.7
Max signal/voice channel: 64/64
Max credits: 960, Voice credits: 960, Video credits: 0
num_of_sig_chnls_allocated: 0
Transcoding channels allocated: 32
Group: FLEX_GROUP_XCODE, complexity: HIGH
Shared credits: 0, reserved credits: 960
Transcoding channels allocated: 0
Credits used (rounded-up): 0
Slot: 0/4
Device idx: 0
Dsp Type: SP2700

dsp 2:
State: UP, firmware: 40.2.7
Max signal/voice channel: 64/64
Max credits: 960, Voice credits: 960, Video credits: 0
num_of_sig_chnls_allocated: 0
Transcoding channels allocated: 32
Group: FLEX_GROUP_XCODE, complexity: HIGH
Shared credits: 0, reserved credits: 960
Transcoding channels allocated: 0
Credits used (rounded-up): 0
Slot: 0/4
Device idx: 0
Dsp Type: SP2700

dsp 3:
State: UP, firmware: 40.2.7
Max signal/voice channel: 64/64
Max credits: 960, Voice credits: 960, Video credits: 0
num_of_sig_chnls_allocated: 0
Transcoding channels allocated: 32
Group: FLEX_GROUP_XCODE, complexity: HIGH
Shared credits: 0, reserved credits: 960
Transcoding channels allocated: 0
Credits used (rounded-up): 0
Slot: 0/4
Device idx: 0
Dsp Type: SP2700

dsp 4:
State: UP, firmware: 40.2.7
Max signal/voice channel: 64/64
Max credits: 960, Voice credits: 960, Video credits: 0
num_of_sig_chnls_allocated: 0
Transcoding channels allocated: 12
Group: FLEX_GROUP_VOICE, complexity: FLEX
Shared credits: 3, reserved credits: 0
Signaling channels allocated: 0
Voice channels allocated: 0
Credits used (rounded-up): 0
Group: FLEX_GROUP_XCODE, complexity: HIGH
Shared credits: 0, reserved credits: 90
Transcoding channels allocated: 0
Credits used (rounded-up): 0
Group: FLEX_GROUP_CONF, complexity: CONFERENCE
Shared credits: 0, reserved credits: 732
Codec: CONF_G729, maximum participants: 8
Sessions per dsp: 10
Group: FLEX_GROUP_HW_MTP, complexity: LOW
Shared credits: 0, reserved credits: 135
Transcoding channels allocated: 0
Credits used (rounded-up): 0
Slot: 0/4
Device idx: 0
Dsp Type: SP2700

Jitender Bhandari · ‎01-18-2017

Hi,

So "no sccp" and then wait for 2-3 seconds and then do SCCP to see if that clears the session.

Only do above if it is not production otherwise it will drop all calls that are using DSP sessions.

If the above clears the issue it could be a stale connection.

JB

voip7372 · ‎01-18-2017

Ok, I just tried that. The odd thing is the call was still there even after 'no sccp'. I did show call active voice com and I still saw the call. I did sccp again. Call is still there...whatever it is.

Jitender Bhandari · ‎01-18-2017

So all call does not have to use DSP session on CUBE, but when you do show sccp conn are you still seeing that inactive session?

JB

voip7372 · ‎01-18-2017

If I'm understanding correctly, yes. I don't anything in use for this command below (if that's what you're referring to). And the call is still there...

CUBE#show voice dsp active

DSP DSP DSPWARE CURR BOOT PAK TX/RX
TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT PACK COUNT
==== === == ======== ========== ===== ======= === == ========= == ===== ============

----------------------------FLEX VOICE CARD 0/4 -----------------------
-------
*DSP ACTIVE VOICE CHANNELS*
DSP DSPWARE VOX DSP SIG DSP PAK TX/RX
TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT PACK COUNT
====== ========== ======== === == == ========= ===== === == == === == ==== ============
------------------------END OF FLEX VOICE CARD 0/4 --------------------
--------

Jitender Bhandari · ‎01-18-2017

Which means there is an active call, and all calls do not require transcoding. Also with CUBE calls do not require DSP resources till the time transcoding is required.

JB

voip7372 · ‎01-18-2017

Ok, thanks. It just looked odd to me and I wanted to verify if it was something I need to deal with.

As far as our incoming calls from the PSTN SIP provider, I don't see it using any transcoding in use when I answer the call. Now you have me wondering. If you have time to answer...my phone says it's using G711 when I answer the SIP call from the PSTN. CUBE also says the call is using G711. But we get G729 from the phone company for these calls, so which entity is doing the transcoding? I would have expected to see the router (CUBE) doing the transcoding since this is the same router I have in the device pool for the media resources for my phone.

Here's what I see for my live call to my phone...the entry with G711 as the codec (real phone numbers and IP's changed for public posting):

CUBE#show call act voi com
<callID> A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
Total call-legs: 4
216 ORG T14527276 g711ulaw VOIP P 172.16.5.38:31300
14561 ORG T179643 g711ulaw VOIP P 172.16.5.38:30412
23744 ANS T34 g711ulaw VOIP P+18585552035 172.51.211.132:10732
23745 ORG T34 g711ulaw VOIP P+16145551260 172.16.200.163:22502

CUBE#show voice dsp active

DSP DSP DSPWARE CURR BOOT PAK TX/RX
TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT PACK COUNT
==== === == ======== ========== ===== ======= === == ========= == ===== ============

----------------------------FLEX VOICE CARD 0/4 -----------------------
-------
*DSP ACTIVE VOICE CHANNELS*
DSP DSPWARE VOX DSP SIG DSP PAK TX/RX
TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT PACK COUNT
====== ========== ======== === == == ========= ===== === == == === == ==== ============
------------------------END OF FLEX VOICE CARD 0/4 --------------------
--------

voip7372 · ‎01-18-2017

Disregard. I just realized I had the CUBE router one step below the CUCM server in the MGRL. I'll move it to the top now and re-test. I think it was using the CUCM server for transcoding.

Jitender Bhandari · ‎01-18-2017

So does not matter who invokes the transcoder CUCM or CUBE, you would see DSP session once either invokes it.

(Rate if it helps)

JB

Jitender Bhandari · ‎01-18-2017

So the transcoder can either be invoked by CUCM or CUBE. Strange that you see g729 on phone as Sh voice call status is not showing g729 codec.

for testing you can make a test call and do "show sccp connection" before and after to see if DSP are invoked.

JB

voip7372 · ‎01-18-2017

I'm seeing G711 on my phone (not G729) and in the router for the active call, but the PSTN is set to use G729 for the incoming SIP calls. I'm not sure why the phone is using G711 unless it's because the Region the phone is in is the same Region the SIP trunk is in and G711 is the codec defined for calls within its own region. Make sense? Could that be the reason it's negotiating to G711?

I still don't see any transcoding in use on the CUBE even after moving its resources to the top of the MRGL for this region/location.

UPDATE: Ok, I just noticed that the telco sent the call in on the other router (not the one where I'm located)....and the router where I'm located IS showing sccp connection for transcoding during this call. So, call came in on CUBE 1 (other city) and CUBE 2 is what did the trancoding (my city/location). I'd still like to know if my idea about why it's using G711 is correct if you have time to reply. Thanks

voip7372 · ‎01-18-2017

Just to finish up the thought...

To fix my audio codec issue so it will definitely use G729 all the way to the phone, I created a new device pool and a new region. The new region has G729 as the first choice in the audio codec preference list and the setting in the region is to use the preference list for G729 between the the SIP trunk and the other regions (except for the MS UM region that we need G711 for since MS UM doesn't support G729). I assigned that new device pool (that has the new G729 region) to the SIP trunks that lead to CUBE and now my calls are G729 all the way through and there's no transcoding needed :-)

voip7372 · ‎01-18-2017

UPDATE: Ok, I just noticed that the telco sent the call in on the other router (not the one where I'm located)....and the router where I'm located IS showing sccp connection for transcoding during this call. So, call came in on CUBE 1 (other city) and CUBE 2 is what did the trancoding (my city/location). I'd still like to know if my idea about why it's using G711 is correct if you have time to reply.

I'm not sure why the phone is using G711 unless it's because the Region the phone is in is the same Region the SIP trunk is in and G711 is the codec defined for calls within its own region. Make sense? Could that be the reason it's negotiating to G711?

Jitender Bhandari · ‎01-18-2017

So in order to find that out, you will have to pull CUCM traces, if transcoding should be used locally. So you have DSP resources used for other CUBE for transcoder you would fix this by creating two MRG and place transcoder of CUBE 1 in one and transcoder for CUBE 2 in other and then arrange the order in MRGL. If you keep both transcoder in same MRG then round-robin would be used.

JB

voip7372 · ‎01-18-2017

Sorry, maybe the way I asked about this was confusing. I think I have enough info to go on now. I'll do some more testing and make sure it's behaving as we expect.