voice gateway and POTS issue

Unanswered Question
Sep 16th, 2008

I currently run CCM 4.1 and 1 remote site. The remote site is running a 2811 router. We had a PRI installed in it but removed it and added 4 FXO ports and 4 analog lines from the telco.

We send all calls from there to untiy thats located in our main site.

The remote site is connected to us via FiOS and a VPN tunnel.

We can call the remote site and the remote site can call us. The problem is when a call comes over the PSTN. Unity answers but if you attempt to transfer to someone, the transfer attempts to go and then disconnects.

We have a plar on the voice port that sends it to unity. I changed that to a IP phone and called the number. I am able to pick up the IP phone and talk. But if I attempt to transfer the call the same thing happens. As soon as I push transfer, it disconnects.

I know its not a codec because the router has all the settings in it and I had set it to g711

Is this due to the analog lines?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Michael Owuor Tue, 09/16/2008 - 05:46

Hi Donald,

A few questions which may shed more light on he issue...

Were you able to perform transfers when the PSTN was fronted by a PRI?

If a remote phone calls a hq phone (removing the PSTN from the picture), can that call then be transferred?

How are the FXO ports and 2811 configured in CallManager - H.323 or MGCP gateway?



D0nprintup_2 Tue, 09/16/2008 - 05:48

1) We were able to do this setup before when it was a PRI.

2) If a remote phone calls, yes it can be transfered

3) it is configured H323

I ran some debugs and I noticed before the call disconnects on the gateway I get

001443: Sep 16 09:46:33.186 EDT: Codec COmplexity is not high

001444: Sep 16 09:46:33.186 EDT: //148/AD369FC28181/CCAPI/cc_api_caps_ack:

Destination Interface=0x65591730, Destination Call Id=149, Source Call Id=148


Caps(Codec=g729r8(0x4), Fax Rate=FAX_RATE_VOICE(0x2), Vad=ON(0x2),

Modem=OFF(0x0), Codec Bytes=20, Signal Type=2, Seq Num Start=6348)

001445: Sep 16 09:46:33.186 EDT: //148/AD369FC28181/CCAPI/cc_api_voice_mode_even


Call Id=148

001446: Sep 16 09:46:33.186 EDT: //148/AD369FC28181/CCAPI/cc_api_voice_mode_even


Call Entry(Context=0x661C9220)

001447: Sep 16 09:46:33.186 EDT: htsp_process_event: [0/1/3, FXOLS_CONNECT, E_HT


001448: Sep 16 09:46:37.134 EDT: //149/AD369FC28181/CCAPI/cc_api_call_disconnect


Cause Value=41, Interface=0x65591730, Call Id=149

001449: Sep 16 09:46:37.134 EDT: //149/AD369FC28181/CCAPI/cc_api_call_disconnect


Call Entry(Responsed=TRUE, Cause Value=41, Retry Count=0)

001450: Sep 16 09:46:37.134 EDT: //148/AD369FC28181/CCAPI/ccConferenceDestroy:

Conference Id=0x46, Tag=0x0

001451: Sep 16 09:46:37.134 EDT: //148/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_don


Now disconnect due to error 41, isnt that a temp failure due to a network issue

Michael Owuor Tue, 09/16/2008 - 06:54


Were the PRI calls also being sent directly to Unity or would they go to the phones directly?

Where is the call being transferred to? If to an external number, do internal transfers work?

If you can, please capture and post here the output of debug h225 asn1 and debug h245 asn1 collected from the remote gateway while recreating the problem.



D0nprintup_2 Tue, 09/16/2008 - 07:05

When we had the PRI installed, it went directly to unity too.

Once in unity, most people use the address book to transfer to their phones. internal and external transfers will not work when calling into the POTS line

(File attached)

Below is the output. I called into the line and it sends the call to unity. Once in unity I select 9 to dial an ext. I dialed 3711

D0nprintup_2 Tue, 09/16/2008 - 07:45


I found my issue. THanks for the suggestions, it got me thinking and reading. I broke out my call manager fundamentals book and started to read about H225 and 245. I found the problem was "Empty Capability set support"

I then went into the gateway and checked media end point and now it works.

I thank you again asking me those questions that got me thinking.

Michael Owuor Tue, 09/16/2008 - 07:52

Good catch, Donald. From your traces, here's the empty capability set received by the gateway:

001955: Sep 16 11:01:24.118 EDT: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :


sequenceNumber 2

protocolIdentifier { 0 0 8 245 0 3 }


You'll notice from the trace that the next one it receives to negotiate capabilities with the transfer-to party is full of capabilities.

Did you also notice that the call is indeed using g.729?

Thanks again for the update. +5.



D0nprintup_2 Tue, 09/16/2008 - 08:21

yeah the call is 729. Now that call transfers are working, it brought up another issue.

Everyone at this remote site calls into the pots line. They get transfered to unity and then select an ext back at the remote site. Now it will transfer but when the IP phone at the remote site answers it disconnects.

So sending the call from the POTS line back to the remote site IP phone will not work.

I am debuging voip calls to see the issue. I fix one problem and another one pops up. good news is I think im getting to the finish line after this hurtle

Michael Owuor Tue, 09/16/2008 - 10:20

Hi Donald,

Lets take a look at the same debugs as before, and also the CCM traces collected hile recreating the current problem.



D0nprintup_2 Tue, 09/16/2008 - 12:41

This is the debug. I can see the call being attempted to transfer. Then it lists a disconnect

heres the rundown now.

I call XXXXXXX and connect to the remote pots. It sends me to unity and I press an option and exter an extension (of someone back at the remote site)

Unity calls that ext. The person can see the phone ring and it shows its from voicemail. As soon as then pick up it disconnects.

So the call goes over the wan to unity and then attempts to go back. Unity can call just fine, its when it attempts to join them theres the problem

Michael Owuor Tue, 09/16/2008 - 12:54

Do you mind trying to eliminate a codec issue be enforcing G.711 throughout? Hard code it on the voip dial peer that sends the call from the remote gateway to Unity, and then also ensure the region that the Unity server and the remote phones/gateway are in specify G.711 between them.

Hopefully we'll get a different result.

Be sure to capture the h225, h245, as well as the ccm traces from CallManager.



D0nprintup_2 Tue, 09/16/2008 - 13:06

yeah Im in the process of forcing G711. I looked through the original call manager traces and I can track the call all the way through to the BASIC_CALL_RELEASE

I see where unity releases the call too and tears down the conference (I am assuming its the hold state while its calling the ext)

Michael Owuor Tue, 09/16/2008 - 13:38

That's true. From the CallManager's perspective, Unity is performing a transfer just like any other CallManager controlled phone would. In this case, one of the Unity voice mail ports is the phone, and the sequence of events are the same.

What type of transfer does Unity do? I think we prefer a blind (Release To Switch) transfer in this case.




This Discussion