[Asterisk-Users] More HEAD wierdness (chan_sip, jitterbuffer/PLC problems)

[Kristian Kielhofner]

Hello,

	After checking out CVS HEAD from yesterday (for those new 
PLC/Jitterbuffer patches), I was affected by bug 3795 with my Polycom 
IP600's.  After seing it resolved as of this morning (thanks Mark), I 
decided to try again...

	I can answer incoming calls.  No problem there.  Putting calls on hold, 
however, results in my Polycom IP600 indicating the call on hold, but 
the caller does not hear any music.  If I go through enough cycles of 
holding/resuming the call, the IP600 eventually locks up in hold, with 
the resume softkey doing nothing.  The only way to get out is to have 
the caller hangup or reset the phone.  If the caller hangs up, the 
Polycom drops the call, and a few seconds later the caller's phone rings 
as though the Polycom was calling it back.  If you answer the call you 
hear nothing and the call is dropped after about one second.

	Similar behavior on my 7960.  I can place the call on hold, but the 
caller hears no music.  Same with before, if I cycle hold/resume enough, 
the phone locks up.  Only the Cisco just drops the call.

	The SIP debug of the conversation between * and the IP 600 (firmware 
1.4.1) can be found below.  I can provide the Cisco as well (7.2).

http://www.krisk.org/asterisk/sip_debug.log

	Now for more on MOH.  I am using native MOH with my files in ulaw 
format.  I setup an extension for running MusicOnHold, and have been 
listening to my hold music for 8 minutes with my Polycom IP600, so I 
know that * sees the files and can play them.  However, if someone calls 
in over IAX and executes that same extension, MOH plays for a couple of 
seconds and stops.  No word on the * console as to what happened.

	I use g729 almost exclusively.  I am confused as to the status of g729 
with the new PLC/jitterbuffer stuff, but that doesn't seem to be it 
because I can transcode from ulaw -> g729 on the phone with my MOH 
extension with no problems.  "sip show channels" shows that the channel 
is using g729, and the MOH plays for forever and ever.  My iax.conf has 
trunk=no trunktimestamps=no and jitterbuffer=yes.  If I set 
jitterbuffer=no, MOH works perfectly.  So it appears to be the 
jitterbuffer in IAX that is causing problems with MOH there.

	I hope that this message wasn't too verbose, but I hope that any of 
these PLC/jitterbuffer problems can get ironed out, because it looks 
awesome!!!

--
Kristian Kielhofner