Summary:ASTERISK-07429: output of ${SIPPEER(peer:status)) is trimmed
Reporter:k-egg (k-egg)Labels:
Date Opened:2006-07-31 09:46:18Date Closed:2011-06-07 14:08:18
Versions:Frequency of
Description:returns "OK_" instead of "OK"


Comments:By: Joshua C. Colp (jcolp) 2006-07-31 10:47:06

Do you mean that all you get back is OK_?

By: k-egg (k-egg) 2006-07-31 10:54:32

should i get more?

i.e "OK (121 ms)"?

By: Joshua C. Colp (jcolp) 2006-07-31 10:55:22

yes, you should - I just double checked the 1.2.7

By: k-egg (k-egg) 2006-07-31 10:57:44

i wonder why i dont get more...
OK_ is all i get, hmm...

(show version output is:
Asterisk SVN-tag-

By: Joshua C. Colp (jcolp) 2006-07-31 11:05:16

I just grabbed a fresh copy of that and confirmed it should be OK (121 ms) - can you just do a simple Noop to test it with the dialplan you used plus the console output so we can confirm?

By: Joshua C. Colp (jcolp) 2006-07-31 11:07:06

I meant post the dialplan and console output here

By: k-egg (k-egg) 2006-07-31 11:09:38

exten => *111*,1,NoOp(${SIPPEER(301:status)})

Executing Goto("mISDN/1-1", "*111*|1") in new stack
   -- Goto (macro-exec_app,*111*,1)
   -- Executing NoOp("mISDN/1-1", "OK ") in new stack

By: k-egg (k-egg) 2006-07-31 11:10:17

sip show peers

Name/username              Host            Dyn Nat ACL Port     Status
7503/7503                  (Unspecified)    D          0        Unmonitored
302/302              D          5060     OK (6 ms)
301/301              D          5060     OK (25 ms)

By: Joshua C. Colp (jcolp) 2006-07-31 11:12:01

I'll lab this up in a bit and see if it happens for me too, and what the cause might be. Rather strange though.

By: k-egg (k-egg) 2006-07-31 11:15:06

yeah, strange, indeed.
do you still need me? otherwise i would shut my pc down.

By: Joshua C. Colp (jcolp) 2006-07-31 11:17:57

Nope, you may go. LOL

By: Joshua C. Colp (jcolp) 2006-07-31 11:56:28

Using the latest 1.2 from SVN I was unable to recreate this issue. Can you upgrade and see if it still exists?

By: k-egg (k-egg) 2006-08-01 02:08:14

as i now know what :status should return, i can arrange my dialplan

i dislike to upgrade at the moment; i don't use Sippeer :status to get the time information, so it's not a problem for me. i just need the "OK", so i will do a CUT(foo=status,' ',1) or someting that works like this, to make the Dialplan work if i ever upgrade.

Thx for your help

By: Joshua C. Colp (jcolp) 2006-08-01 11:23:54

I was unable to reproduce this and don't even see how it would be possible. If you do upgrade and this issue is still there, please reopen this. Thanks!

By: k-egg (k-egg) 2006-08-11 04:44:56

plz look here...


ther is an other one having same problem.

By: Serge Vecher (serge-v) 2006-08-11 09:30:18

slavon: what Asterisk release are you seeing the chopped output for SIPPEER on?

By: Badalian Vyacheslav (slavon) 2006-08-12 04:54:32


office / # emerge -pv asterisk
[ebuild   R   ] net-misc/asterisk-1.2.9_p1  USE="mmx mysql ssl -alsa -bri -curl -debug -doc -gtk -h323 -hardened -lowmem -nosamples -odbc -osp -postgres -pri -speex -sqlite -ukcid -zaptel" 0 kB

Gentoo packages not bump version to 1.2.10 =(

By: Serge Vecher (serge-v) 2006-08-14 08:58:45

k-egg: are running gentoo too?

By: k-egg (k-egg) 2006-08-14 09:00:17

nope, this machine is a suse 10.1

By: Badalian Vyacheslav (slavon) 2006-08-14 09:34:18

This about my system

office ~ # emerge --info
Portage 2.1.1_pre5-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17-gentoo-r5 i686)
System uname: 2.6.17-gentoo-r5 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz
Gentoo Base System version 1.12.4
Last Sync: Mon, 14 Aug 2006 10:30:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17
CFLAGS="-O2 -march=i686 -pipe -msse -msse2 -mmmx"
CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=i686 -pipe -msse -msse2 -mmmx"
FEATURES="autoconfig distcc distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
USE="x86 apm asterisk avi berkdb bitmap-fonts cli crypt cups dlloader dri eds elibc_glibc emboss encode foomaticdb fortran gd gdbm gif gpm gstreamer iconv imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg kernel_linux libg++ libwww mad mikmod mmx motif mp3 mpeg mysql ncurses nls nptl nptlonly ogg pam pcre pdflib perl png pppd python qt3 qt4 quicktime readline reflection session spell spl sse sse2 ssl tcpd tiff type1-fonts udev userland_GNU vorbis xml xmms xorg xv zip zlib"

office ~ # gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1)

By: k-egg (k-egg) 2006-08-14 10:21:40

okay, on 1.2.10 the problem is gone... but i think, it would be nice to have a bugfix in

[edited below:]

the thing i don't  understand, why everybody(!) here uses (that leet) "latest version from svn" to verify bugs... not the version, the bug was reportet on. i think this is not the best way of doing it. ppl could save time, not reporting bugs in version nobody (from the "officials") cares about anymore! just report bugs on "latetest svn"... wich is not available in any (standard) linux  distributon.

I thing you could save time, not tagging the trunk anymore and just say: "okay, we have trunk, so get latest version from there and die happy! we dont't make any releases anymore... we didn't care about releases anyway"

so... to stop you, Sorry for blaming, bashing and soon, but THIS had to be sayed in opinion, even if i stept on somebodys feed (german saying). Sorry at all. But i am/was angry and... so either dont care, about what i sayed before, or if you think there is a truth in it...

Kind Regards


By: Joshua C. Colp (jcolp) 2006-08-14 11:32:03

When I tested this issue originally I used a fresh checkout of the tag from SVN, and also a fresh check out of the 1.2 branch so it's not exactly accurate that everyone tests using the latest version. We do ask that you do this yourself though, as bugs that exist in previous versions often get fixed in the latest release as we can't go back and fix a release that tons of people have already downloaded. As for going back and trying to track it down in order to backport it to, I believe that's a waste of time on our part. We make new releases in order to get the new bug fixes out there and while we realize that some individuals have to stick to a specific version I personally don't think it should be up to us to keep those up to date as well. Hopefully you can understand where I'm coming from.

By: Serge Vecher (serge-v) 2006-08-14 12:47:24

alright: since this is fixed in 1.2.10, are we ready for closure then? I realize that a certain distribution may not have a 1.2.10 package available yet, but then there is always a tried-and-true-compile-it-yourself-option.

By: k-egg (k-egg) 2006-08-15 02:49:10

again, sorry for beeing that abusive. i felt a little pissed on; yesterday... . I dont belive it's an easy job to handle all those bug.. ahh people.
What i wonder is, why you didn't have that issue when you used but anyway... i think i will stay on 1.2.10 now, but i wonder where that bug was.

btw: since i started with asterisk i compiled it myself from source, not using any packet manager, but yesterday, as i wanted to install asterisk on my gentoo box, i had to use the packet manager, cause latest stuff from mISDN didn't work for me. Funny.

@vechers: so,
- we know thet ther is a (very little) bug in and
- we don't know where.
- we know that the bug is gone in 1.2.10
- we don't know why.
- we documented this.
(- i know that joshnet didn't only tried fresh from SVN. but he could have sayed, yes i got the bug in as well and it's gone in latest version. i think this answer would have satisfied me.)

From my side there is nothing to say against closing that bug...
... and living happily ever after ;)

By: Serge Vecher (serge-v) 2006-08-15 08:34:27

slavon, k-egg: thanks for confirmation. As joshnet said, we don't fix bugs in a specific release by re-releasing the release (if you know what I mean). All bugs in a specific release (1.2.x) are first fixed in a 1.2 svn branch, which after a period of time is released as a subsequent release (1.2.x+1).

I will close this issue at this point, since the problem is gone in the latest release 1.2.10. If anybody feels like doing research and narrowing down the exact breakage and fixage, please find me on #asterisk-bugs and I will happily add a note to the archives for you.