Package: asterisk Version: 1:1.0.5-2 Severity: important
-- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages asterisk depends on: ii asterisk-config 1:1.0.5-2 config files for asterisk ii asterisk-sounds-main 1:1.0.5-2 sound files for asterisk ii libasound2 1.0.8-3 ALSA library ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libedit2 2.9.cvs.20040827-1 BSD editline and history libraries ii libgsm1 1.0.10-13 Shared libraries for GSM speech co ii libncurses5 5.4-4 Shared libraries for terminal hand ii libpq3 7.4.7-2 PostgreSQL C client library ii libpri1 1.0.4-2 Primary Rate ISDN specification li ii libspeex1 1.0.rel.4-1 The Speex Speech Codec ii libssl0.9.7 0.9.7e-2 SSL shared libraries ii libtonezone1 1:1.0.4-3 tonezone library (runtime) ii unixodbc 2.2.4-11 ODBC tools libraries ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information I've had problems with Asterisk 1.0.5-2. It seems that the ack messages to a 200 OK message (i.e ack'ing a 'go to channel') message are malformed. I have two systems, one, which works, running asterisk 1.0.2 and 1.0.5 which is faulty. The good system registers with SER as 4748880, the bad system registers as 4980066. Aside from that, the configurations of the two are identical. In both tests, I am trying to call 044989644. As the following ack messages show, the key difference is in the Contact: field. The good system shows the calling party, the bad system shows the called number in the Contact: field. I downgraded the 1.0.5 system to 1.0.2 (taking care to keep the configs untouched) and it spluttered into life. This proves the other elements of the system are OK (i.e phones/SER etc) Practically speaking the fault makes itself apparent by outbound calls clearing prematurely. On a Cisco AS5300 voice gateway, once the timer expires after 19/20 seconds, the call is cleared. The AS5300 seems to ignore the malformed ack, and repeats the 200 OK message - presumably because it gets no understandable Ack, it repeats itself. Inbound calls are OK. [Good] U 202.53.189.50:5060 -> 202.7.4.40:5060 ACK sip:[EMAIL PROTECTED]:5060 SIP/2.0..Max-Forwards: 10..Via: SIP/2.0/UDP 202.53.189.50;branch=0..Via: SIP/2.0/UDP 202.53.189.20:5 060;branch=z9hG4bK24d4aca4..From: "4748880" <sip:[EMAIL PROTECTED]>;tag=as45321fc3..To: <sip:[EMAIL PROTECTED]>;tag=B44866E0-1F8 ..Contact: <sip:[EMAIL PROTECTED]>..Call-ID: [EMAIL PROTECTED]: 103 ACK..User-Agent: Aste risk PBX..Content-Length: 0.... [bad] U 202.53.189.50:5060 -> 202.7.4.40:5060 ACK sip:[EMAIL PROTECTED]:5060 SIP/2.0..Max-Forwards: 10..Via: SIP/2.0/UDP 202.53.189.50;branch=0..Via: SIP/2.0/UDP 161.29.255.254: 5060;branch=z9hG4bK78460bfc..From: "4980066" <sip:[EMAIL PROTECTED]>;tag=as149ab473..To: <sip:[EMAIL PROTECTED]>;tag=B44A670C-BC3 ..Contact: <sip:[EMAIL PROTECTED]>..Call-ID: [EMAIL PROTECTED]: 103 ACK..User-Agen t: Asterisk PBX..Content-Length: 0.... Cheers jamie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]