asterisk users - Oct 2005 - dropped calls when g729 is used on sip leg

Hello - I have 8 polycom 501s all setup great using ulaw.  We have put 
them through a pretty rigorous torture over the last 4 months, and 
they've performed famously.  No dropped calls ever.

We invested in some g729 licenses.  changed my ipmid.cfg so that g729 is 
priority 1 and ulaw is priority 2.  I added allow=g729 to my extension's 
sip.conf entry, where existed before disallow=all and allow=ulaw.

told asterisk to do a reload, and tried dialing out on a zap line.  It 
was obvious from the call quality that g729 had been selected, and I 
double-checked and triple-checked by
1) a sip show peer 112 shows:
   Codecs       : 0x104 (ulaw|g729)
   Codec Order  : (g729,ulaw)

and 2) the status of the current call as reported by the phone's menu 
system  shows it using g729 as well.

So, great.  lower network usage, and the quality is good.  And if I call 
another polycom configured the same way, they drop asterisk per 
canreinvite=yes, and continue their happy g729 way.

After an indeterminate amount of time, sometimes 30 seconds and 
sometimes 5 minutes, one of two things happens: first, sometimes, the 
zap leg just disappears.  I don't get any messages on the CLI at verbose 
level 30 and debug level 30.  The SIP leg stays connected, but the audio 
trails out into a lovely mash of codec ether before silence.  The phone 
remains off-hook when this happens, and it just remains silent.  So I 
didn't think sip debug logs would help, but I will post them if someone 
thinks it might help.  Secondly, sometimes, the zap leg doesn't 
disappear, but audio is not delivered from the g729-using polycoms to 
the zap callee.  I hear them but they are just hello?  hello?.  Neither 
of these things happen when the phones runs in ulaw.

Does anyone have any idea where to look? I'll post whatever logs anyone 
thinks might help.

I'm using 1.2.0b1, but this occurred with my CVS HEAD of around 
7/20/2005 as well.

Thanks!

Mojo



-- 
Mojo <mojo@horanappraisals.com>
Office Manger, Horan & Company, LLC
(907) 747-6666 x112

Is it at all possible asterisk is receiving a SIP message from the phone 
causing it to drop the zap channel?  I've got vad turned off in the 
polycom configs.  Guess I'll comb the sip debug logs.

I've got callprogress turned off.  I'll try verbosity and debug levels 
greater than 30 to see if anything gives.

Thanks for any suggestions you all might have :)

Moj

Mojo with Horan & Company, LLC wrote:
> Hello - I have 8 polycom 501s all setup great using ulaw.  We have put 
> them through a pretty rigorous torture over the last 4 months, and 
> they've performed famously.  No dropped calls ever.
> 
> We invested in some g729 licenses.  changed my ipmid.cfg so that g729 is 
> priority 1 and ulaw is priority 2.  I added allow=g729 to my
extension's
> sip.conf entry, where existed before disallow=all and allow=ulaw.
> 
> told asterisk to do a reload, and tried dialing out on a zap line.  It 
> was obvious from the call quality that g729 had been selected, and I 
> double-checked and triple-checked by
> 1) a sip show peer 112 shows:
>    Codecs       : 0x104 (ulaw|g729)
>    Codec Order  : (g729,ulaw)
> 
> and 2) the status of the current call as reported by the phone's menu 
> system  shows it using g729 as well.
> 
> So, great.  lower network usage, and the quality is good.  And if I call 
> another polycom configured the same way, they drop asterisk per 
> canreinvite=yes, and continue their happy g729 way.
> 
> After an indeterminate amount of time, sometimes 30 seconds and 
> sometimes 5 minutes, one of two things happens: first, sometimes, the 
> zap leg just disappears.  I don't get any messages on the CLI at
verbose
> level 30 and debug level 30.  The SIP leg stays connected, but the audio 
> trails out into a lovely mash of codec ether before silence.  The phone 
> remains off-hook when this happens, and it just remains silent.  So I 
> didn't think sip debug logs would help, but I will post them if someone
> thinks it might help.  Secondly, sometimes, the zap leg doesn't 
> disappear, but audio is not delivered from the g729-using polycoms to 
> the zap callee.  I hear them but they are just hello?  hello?.  Neither 
> of these things happen when the phones runs in ulaw.
> 
> Does anyone have any idea where to look? I'll post whatever logs anyone
> thinks might help.
> 
> I'm using 1.2.0b1, but this occurred with my CVS HEAD of around 
> 7/20/2005 as well.
> 
> Thanks!
> 
> Mojo
> 
> 
> 
-- 
Mojo <mojo@horanappraisals.com>
Office Manger, Horan & Company, LLC
(907) 747-6666 x112

I don't know what to look for in my sip debug logs, can anybody suggest 
what sorts of messages my phones might unexpectedly give asterisk 
causing it to drop the zap leg?

Mojo with Horan & Company, LLC wrote:
> Hello - I have 8 polycom 501s all setup great using ulaw.  We have put 
> them through a pretty rigorous torture over the last 4 months, and 
> they've performed famously.  No dropped calls ever.
> 
> We invested in some g729 licenses.  changed my ipmid.cfg so that g729 is 
> priority 1 and ulaw is priority 2.  I added allow=g729 to my
extension's
> sip.conf entry, where existed before disallow=all and allow=ulaw.
> 
> told asterisk to do a reload, and tried dialing out on a zap line.  It 
> was obvious from the call quality that g729 had been selected, and I 
> double-checked and triple-checked by
> 1) a sip show peer 112 shows:
>    Codecs       : 0x104 (ulaw|g729)
>    Codec Order  : (g729,ulaw)
> 
> and 2) the status of the current call as reported by the phone's menu 
> system  shows it using g729 as well.
> 
> So, great.  lower network usage, and the quality is good.  And if I call 
> another polycom configured the same way, they drop asterisk per 
> canreinvite=yes, and continue their happy g729 way.
> 
> After an indeterminate amount of time, sometimes 30 seconds and 
> sometimes 5 minutes, one of two things happens: first, sometimes, the 
> zap leg just disappears.  I don't get any messages on the CLI at
verbose
> level 30 and debug level 30.  The SIP leg stays connected, but the audio 
> trails out into a lovely mash of codec ether before silence.  The phone 
> remains off-hook when this happens, and it just remains silent.  So I 
> didn't think sip debug logs would help, but I will post them if someone
> thinks it might help.  Secondly, sometimes, the zap leg doesn't 
> disappear, but audio is not delivered from the g729-using polycoms to 
> the zap callee.  I hear them but they are just hello?  hello?.  Neither 
> of these things happen when the phones runs in ulaw.
> 
> Does anyone have any idea where to look? I'll post whatever logs anyone
> thinks might help.
> 
> I'm using 1.2.0b1, but this occurred with my CVS HEAD of around 
> 7/20/2005 as well.
> 
> Thanks!
> 
> Mojo
> 
> 
> 
-- 
Mojo <mojo@horanappraisals.com>
Office Manger, Horan & Company, LLC
(907) 747-6666 x112

With verbose and debug both on 255, here's all I get at the CLI.  The X 
is during the call, at the instant the Zap leg seems to drop, almost 
concurrently with the 'Hungup Zap/1-1'.

    -- Executing Macro("SIP/112-a88a",
"internaldialout|7476011") in new
stack
     -- Executing ChanIsAvail("SIP/112-a88a",
"ZAP/1&ZAP/2&ZAP/3") in
new stack
     -- Hungup 'Zap/1-1'
     -- Executing Cut("SIP/112-a88a",
"theChannel=AVAILCHAN||1") in new
stack
     -- Executing Dial("SIP/112-a88a", "Zap/1/7476011||TW")
in new stack
     -- Called 1/7476011
     -- Zap/1-1 answered SIP/112-a88a
X
     -- Hungup 'Zap/1-1'
Oct  7 11:07:15 WARNING[5895]: channel.c:709 channel_find_locked: 
Avoided initial deadlock for '0x853ae28', 10 retries!



Mojo with Horan & Company, LLC wrote:
> Hello - I have 8 polycom 501s all setup great using ulaw.  We have put 
> them through a pretty rigorous torture over the last 4 months, and 
> they've performed famously.  No dropped calls ever.
> 
> We invested in some g729 licenses.  changed my ipmid.cfg so that g729 is 
> priority 1 and ulaw is priority 2.  I added allow=g729 to my
extension's
> sip.conf entry, where existed before disallow=all and allow=ulaw.
> 
> told asterisk to do a reload, and tried dialing out on a zap line.  It 
> was obvious from the call quality that g729 had been selected, and I 
> double-checked and triple-checked by
> 1) a sip show peer 112 shows:
>    Codecs       : 0x104 (ulaw|g729)
>    Codec Order  : (g729,ulaw)
> 
> and 2) the status of the current call as reported by the phone's menu 
> system  shows it using g729 as well.
> 
> So, great.  lower network usage, and the quality is good.  And if I call 
> another polycom configured the same way, they drop asterisk per 
> canreinvite=yes, and continue their happy g729 way.
> 
> After an indeterminate amount of time, sometimes 30 seconds and 
> sometimes 5 minutes, one of two things happens: first, sometimes, the 
> zap leg just disappears.  I don't get any messages on the CLI at
verbose
> level 30 and debug level 30.  The SIP leg stays connected, but the audio 
> trails out into a lovely mash of codec ether before silence.  The phone 
> remains off-hook when this happens, and it just remains silent.  So I 
> didn't think sip debug logs would help, but I will post them if someone
> thinks it might help.  Secondly, sometimes, the zap leg doesn't 
> disappear, but audio is not delivered from the g729-using polycoms to 
> the zap callee.  I hear them but they are just hello?  hello?.  Neither 
> of these things happen when the phones runs in ulaw.
> 
> Does anyone have any idea where to look? I'll post whatever logs anyone
> thinks might help.
> 
> I'm using 1.2.0b1, but this occurred with my CVS HEAD of around 
> 7/20/2005 as well.
> 
> Thanks!
> 
> Mojo
> 
> 
> 
-- 
Mojo <mojo@horanappraisals.com>
Office Manger, Horan & Company, LLC
(907) 747-6666 x112

This post is exactly my problem:
http://lists.digium.com/pipermail/asterisk-users/2005-July/117988.html

Has anybody encountered this and been able to solve it and use g729 
successfully?  Are there other g729 implementations available as a codec 
for asterisk?

Mojo

Mojo with Horan & Company, LLC wrote:
> Hello - I have 8 polycom 501s all setup great using ulaw.  We have put 
> them through a pretty rigorous torture over the last 4 months, and 
> they've performed famously.  No dropped calls ever.
> 
> We invested in some g729 licenses.  changed my ipmid.cfg so that g729 is 
> priority 1 and ulaw is priority 2.  I added allow=g729 to my
extension's
> sip.conf entry, where existed before disallow=all and allow=ulaw.
> 
> told asterisk to do a reload, and tried dialing out on a zap line.  It 
> was obvious from the call quality that g729 had been selected, and I 
> double-checked and triple-checked by
> 1) a sip show peer 112 shows:
>    Codecs       : 0x104 (ulaw|g729)
>    Codec Order  : (g729,ulaw)
> 
> and 2) the status of the current call as reported by the phone's menu 
> system  shows it using g729 as well.
> 
> So, great.  lower network usage, and the quality is good.  And if I call 
> another polycom configured the same way, they drop asterisk per 
> canreinvite=yes, and continue their happy g729 way.
> 
> After an indeterminate amount of time, sometimes 30 seconds and 
> sometimes 5 minutes, one of two things happens: first, sometimes, the 
> zap leg just disappears.  I don't get any messages on the CLI at
verbose
> level 30 and debug level 30.  The SIP leg stays connected, but the audio 
> trails out into a lovely mash of codec ether before silence.  The phone 
> remains off-hook when this happens, and it just remains silent.  So I 
> didn't think sip debug logs would help, but I will post them if someone
> thinks it might help.  Secondly, sometimes, the zap leg doesn't 
> disappear, but audio is not delivered from the g729-using polycoms to 
> the zap callee.  I hear them but they are just hello?  hello?.  Neither 
> of these things happen when the phones runs in ulaw.
> 
> Does anyone have any idea where to look? I'll post whatever logs anyone
> thinks might help.
> 
> I'm using 1.2.0b1, but this occurred with my CVS HEAD of around 
> 7/20/2005 as well.
> 
> Thanks!
> 
> Mojo
> 
> 
> 
-- 
Mojo <mojo@horanappraisals.com>
Office Manger, Horan & Company, LLC
(907) 747-6666 x112