Hi Phil,

Have you tried using hook flash a second time instead of the conference button?

If it doesn't help, capture the following for a scenario where you try to conference and we can see what' s going wrong

"debug voice ccapi inout"

"debug sccp det"

"debug ephone detail mac-address "

Also grab a "show run", "show telephony-service", "show voice dsp det", "show sccp" and a "show stcapp dev summ".

Hi Kshitij,

I have finally got the guys in Sofia to run some tests!

They tried the hookflash after the first call, but it just cut the call off.

I have attached the debugs and show commands that you wanted. There are two calls captured:

Call 1: x447 dialled x403, which diverted to a local mobile number (00887275334), x447 then dialled 2007696 on a voip call across the WAN. The conference was created without any issues.

Call 2: x447 dialled local mobile number, then dialled external International number, when conference key was pressed the international number and the local mobile number were connected, but the conference phone just heard an audible tone. He tried to explain the tone to me and it seems like it was fast busy, but I cannot be sure because of the language barrier!

I will continue to look at the output to see if I can work out what is going on.

Phil

Hi Kshitij,

I have finally managed to get the guys in Sofia to do testing!

Hookflash just causes the original call to be dropped.

I have attached the show commands and the debugs. The guys tested with two conference calls as below:

Call 1 - x447 dials x403 which is diverted to a local mobile, places on hold while another call is placed across the WAN via a VoIP call to 200 7696. Conference connects and all parties are heard as you would expect.

Call 2 - x447 dials local mobile number directly, places on hold while another call is placed internationally to 00442073387696, when the call is answered the originating extension (447) gets a fast busy tone (I think it is a fast busy tone, language barriers cause a problem in determining exactly what the tone was!). The two numbers that are called are in a conference on their own.

I will continue to look through the debug output to see if I can spot what is going wrong.

Thanks,

Phil

I have found something interesting in the debug output:

On the first call which was successful at 09:03:10.384 there is a SoftKeyEventMessage displayed and two lines down it is detected as a conference softkey.

On the second call which was unsuccessful at 09:05:46.749 ther is a SoftKeyEventMessage displayed and two lines down it is detected as a transfer softkey.

Now I just need to work out why the softkey was detected as transfer instead of conference!

Any help would be appreciated.

Phil

It appears that it is seeing the second hookflash as an on-hook event.  The following is from

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t2/ht1ccmqs.html

Have you tried another (simpler) analog phone on the line to see if it mighth have something to do with the Polycom?  You might have to further tweak the hookflash duration settings?

HTH,

Art

Thanks for the info Art, I had already been through the documentation. What I do not understand about the documentation is how does the CME know what the hookflash is supposed to do i.e how does it know that you want to transfer or conference when the same button is pressed for each one?

I have just run some more tests:

Conferencing works when all parties that are dialled are internal, or that the internal party dialled forwards their number to a mobile or another external number.

Conferencing doesn't work when an external number is dialled and then another external or internal is dialled. This results in a transfer between the two parties dialled and the originating extension drops out.

Is there perhaps a limitaion to analogue extensions and external conferencing?

Hi Phil,

Per the snippet, it determines transfer vs. conference by the hookflash duration.  If it perceives you hang up it decides transfer:

During a call, press hookflash to receive a dial tone. Dial number for transfer and either stay online to announce or hang up. The call is transferred when you hang up.

If it perceives a hookflash it decides conference.

As to the other test you did - very starnge, almost indicates a potential bug.

I would still suggest trying it with a normal analog handset or buttset to see what happens.  If it is the same than you have eleiminated the Polycom as a factor.  If it is different than you have eliminated a bug, and likely need to tweak hookflash.

Cheers!

Art

Hi Art,

Unfortunately the CME is in Sofia, Bulgaria and the only analogue phones we have are the Polycoms. I'll have to ship one over to them to be able to test. In the meantime i'll raise a TAC case just in case there is a bug.

Cheers,

Phil

Under Telephony-Services I had transfer-pattern .T blind configured. Cisco advised to change this to transfer-pattern .T and this solved the problem!

It was strange as this command didn't affect the IP phones when it was configured as .T blind, it only affected the analogue phones under skinny control.

Phil,

I'm glad to hear you have it working.  I agree the behavior is a bit odd, but then again we run into those things with IPT now and again don't we

Thanks for the update - it is another thing to be aware of.

Happy Trails,

Art