Re: [asterisk-dev] SIP Presence using SIP SIMPLE: How?
Thanks Olle for the explanation. Is such a feature planned, so that the presence status of a hinted extensions can be updated via SIP? Is anybody interested in such a feature? PS: Switching to Kamailio is not an option as there are some required features in Asterisk that I would really miss. --- Dennis Guse Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Sun, Apr 27, 2014 at 8:50 PM, Olle E. Johansson o...@edvina.net wrote: On 27 Apr 2014, at 20:01, Dennis Guse dennis.g...@qu.tu-berlin.de wrote: Hallo, I have successfully activated hints and those are working (NOTIFY is send by Asterisk on (un)-register to the subscribed clients). And the presence state can be set using CustomPresence, by calling the dialplan function PRESENCE_STATE [1]. However, I have some trouble, if clients are setting there presence state the sip way [2], but using Asterisk as proxy (no P2P presence). The clients do not send there presence updates to Asterisk, because is not subscribing on them (there is no SUBSCRIBE-message from Asterisk to a hinted client). How do I get Asterisk to subscribe on the clients, so Asterisk can the presence update and can relay it? Or is this not implemented? It is not implemented and Asterisk is not a proxy. Use Kamailio if you want full presence. /O Software: Asterisk is 11.7 on an Ubuntu 14.04 The clients we use are based upon PJSIP 2.1. [1] https://wiki.asterisk.org/wiki/display/AST/Presence+State [2] http://www.ietf.org/rfc/rfc3856.txt --- Dennis Guse -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SIP Presence using SIP SIMPLE: How?
On 28 Apr 2014, at 10:15, Dennis Guse dennis.g...@qu.tu-berlin.de wrote: Thanks Olle for the explanation. Is such a feature planned, so that the presence status of a hinted extensions can be updated via SIP? Is anybody interested in such a feature? I have an old branch that supports PUBLISH for this. If there's funding, I can plan on working on this later this year. PS: Switching to Kamailio is not an option as there are some required features in Asterisk that I would really miss. You don't have to switch to Kamailio, you have to ADD kamailio to your network and keep Asterisk. /O --- Dennis Guse Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Sun, Apr 27, 2014 at 8:50 PM, Olle E. Johansson o...@edvina.net wrote: On 27 Apr 2014, at 20:01, Dennis Guse dennis.g...@qu.tu-berlin.de wrote: Hallo, I have successfully activated hints and those are working (NOTIFY is send by Asterisk on (un)-register to the subscribed clients). And the presence state can be set using CustomPresence, by calling the dialplan function PRESENCE_STATE [1]. However, I have some trouble, if clients are setting there presence state the sip way [2], but using Asterisk as proxy (no P2P presence). The clients do not send there presence updates to Asterisk, because is not subscribing on them (there is no SUBSCRIBE-message from Asterisk to a hinted client). How do I get Asterisk to subscribe on the clients, so Asterisk can the presence update and can relay it? Or is this not implemented? It is not implemented and Asterisk is not a proxy. Use Kamailio if you want full presence. /O Software: Asterisk is 11.7 on an Ubuntu 14.04 The clients we use are based upon PJSIP 2.1. [1] https://wiki.asterisk.org/wiki/display/AST/Presence+State [2] http://www.ietf.org/rfc/rfc3856.txt --- Dennis Guse -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Dundi library
Thanks for the feedback. Corey, thanks for the work on the library.
Meanwhile I implemented the workaround: let Kamailio forward the request
to an Asterisk server which does the lookup and responds with a 302
redirect to (Transfer()) the proper Asterisk server.
Using SIP for the query has the advantage that the query is handled
asynchronous inside Kamailio. For INVITEs it is quite easy (as they are
handled in the Asterisk dialplan of the Asterisk server which does the
DUNDI query). But it was a bit more complicated than expected as I also
have to do the lookups also for REGISTERs, SUBSCRIBE Therefore I
implemented a hack in Kamailio, faking another INVITE transaction
while putting the original transcation on hold. (yes there are plenty of
hacks you can do in Kamailio).
Basically it works but I have not tested it in detail. If you are
interested take a look at the Kamailio config below.
regards
Klaus
dundi.host = 1.2.3.4:5060 desc Asterisk which performs the DUNDI
query. Host:Port
dundi.deftarget = 2.3.4.5:5160 desc Default Asterisk server if DUNDI
lookup failed. Host:Port
route[RELAY_TO_DUNDI] {
$var(dundicache) = $sht(dundicache=$tU);
if( $var(dundicache) == 0) {
xlogl(L_INFO,$tU not found in cache, quering
Dundi-Asterisk for DUNDI lookup...);
if(t_suspend()) {
# build a new transaction, use From and To URI
to store
# the transaction identifiers
xlogl(L_INFO,transaction suspended
[$T(id_index):$T(id_label)]\n);
$uac_req(method)=INVITE;
$uac_req(ruri)=sip: + $tU + @ +
$sel(cfg_get.dundi.host);
$uac_req(furi)=sip: + $T(id_index) + @proxy;
$uac_req(turi)=sip: + $T(id_label) + @proxy;
$uac_req(callid)=$(mb{s.md5});
uac_req_send();
exit;
} else {
xlogl(L_ERR,Failed to suspend transaction
... 500);
send_reply(500,Failed to suspend transaction);
exit;
}
} else if( $var(dundicache) == unknown ) {
xlogl(L_INFO,$tU found in cache but unknown, sending
to $(sel(cfg_get.dundi.deftarget)));
$du=sip: + $sel(cfg_get.dundi.deftarget);
} else {
xlogl(L_INFO,$tU found in cache, sending to
$var(dundicache));
$du=sip: + $var(dundicache);
}
add_contact_alias();
if (!t_relay()) {
sl_reply_error();
}
exit;
}
event_route [tm:local-request] {
# Handle locally generated requests
xlogl(L_INFO, local-request: Routing locally generated $rm
to $ru:);
t_on_reply(REPLY_DUNDI);
# 2 seconds prober timeout
t_set_fr(0, 2000);
}
onreply_route[REPLY_DUNDI] {
xlogl(L_INFO,REPLY_DUNDI: response received from $si:);
$var(index) = $(fU{s.int});
$var(label) = $(tU{s.int});
if (t_check_status(3[0-9][0-9])) {
# this reply route is only executed for DUNDI
responses, thus, no need to check the source
$var(target)= @msg.header.Contact[0].nameaddr.uri.host;
xlogl(L_INFO,REPLY_DUNDI: Tindex=$var(index),
Tlabel=$var(label), target=$var(target));
$sht(dundicache=$fU:$tU)=$var(target);
t_continue($var(index), $var(label), AFTER_DUNDI);
} else {
xlogl(L_ERR, Unexpected response from Dundi server);
t_continue($var(index), $var(label), AFTER_DUNDI);
}
}
route[AFTER_DUNDI] {
xlogl(L_INFO,AFTER_DUNDI: transaction
$T(id_index):$T(id_label) continues );
$var(target) = $sht(dundicache=$T(id_index):$T(id_label));
if ($(var(target){s.len}) 1) {
$du = sip: + $var(target);
$ru = $ou;
xlogl(L_INFO, Got redirect from Dundi server, target
is $ru, sending to $du);
$sht(dundicache=$tU)=$var(target);
r_relay();
exit;
} else {
xlogl(L_ERROR,AFTER_DUNDI: no target found ... using
default);
$du=sip: + $sel(cfg_get.dundi.deftarget);
$ru = $ou;
$sht(dundicache=$tU)=unknown;
r_relay();
exit;
}
exit;
}
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] problem in cross compiling asterisk
I did a Google search and a common result of cannot find -lresolv is the use of FreeBSD. Are you compiling on a FreeBSD system? My understanding of FreeBSD is that this linker flag simply is not needed, so you may be safe to just remove the flag from the Makefile. If that does not work for you, then the only other workaround I can think of at the moment is to compile on Linux instead. The core Asterisk developers use a variety of Linux distros, so you should be fine to use whichever you are most comfortable with. On Sat, Apr 26, 2014 at 4:12 PM, Mohammed Essaid Mezerreg moh.ess...@gmail.com wrote: hello, while cross-compling asterisk to run on openrisc 1200 I recieved this errors [LD] abstract_jb.o acl.o adsi.o alaw.o aoc.o app.o ast_expr2.o ast_expr2f.o asterisk.o astfd.o astmm.o astobj2.o audiohook.o autochan.o autoservice.o bridging.o callerid.o ccss.o cdr.o cel.o channel.o chanvars.o cli.o config.o data.o datastore.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o enum.o event.o features.o file.o fixedjitterbuf.o frame.o framehook.o fskmodem.o global_datastores.o hashtab.o heap.o http.o image.o indications.o io.o jitterbuf.o loader.o lock.o logger.o manager.o md5.o netsock.o netsock2.o pbx.o plc.o poll.o privacy.o rtp_engine.o say.o sched.o security_events.o sha1.o slinfactory.o srv.o ssl.o stdtime/localtime.o strcompat.o strings.o stun.o syslog.o taskprocessor.o tcptls.o tdd.o term.o test.o threadstorage.o timing.o translate.o udptl.o ulaw.o utils.o version.o xml.o xmldoc.o editline/libedit.a db1-ast/libdb1.a - asterisk /opt/or1k-toolchain/lib/gcc/or1k-linux-uclibc/4.9.0/../../../../or1k-linux-uclibc/bin/ld: cannot find -lresolv utils.o: In function `ast_gethostbyname': /home/mohessaid/asterisk-1.8.19.0/main/utils.c:228: warning: gethostbyname_r is obsolescent, use getnameinfo() instead. collect2: error: ld returned 1 exit status make[1]: *** [asterisk] Error 1 make: *** [main] Error 2 can anyone please help with a solution -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] problem in cross compiling asterisk
no, I am not using FreeBSD, I am using CentOS 6.5, and I tried to omit the
-lresolv but it didn't work but lot of errors keep showing off because of
this changement. I am using the uClibc toolchains from opencores to achieve
this coss compiling process and before this error I encountred lot of some
other errors like this one which prove that asterisk don't support uclibc
yet:
I had some error in compiling ael_lex the errors comes from the ael.flex in
this line:
[CC] ael/ael_lex.c - ael/ael_lex.o
ael.flex: In function ‘ael_yylex’:
ael.flex:601:43: error: ‘GLOB_BRACE’ undeclared (first use in this function)
ael.flex:601:43: note: each undeclared identifier is reported only once for
each function it appears in
make[1]: *** [ael/ael_lex.o] Error 1
make: *** [res] Error 2
and when I looked in the ael.flex I find this:
#ifdef SOLARIS
glob_ret = glob(fnamebuf, GLOB_NOCHECK, NULL, globbuf);
#else
glob_ret = glob(fnamebuf, GLOB_NOMAGIC|GLOB_BRACE, NULL,
globbuf);
#endif
and the else block is the place where the compilation stack and when I went
to the configuration result I found that the checking action fro
GLOB_NOMAGIC and GLOB_BRACE is a no.
after that I went to the glob.h header in my toolchain to find this line:
#if 1 /* uClibc gnu glob does not support these */
# define GLOB_ALTDIRFUNC (1 9)/* Use gl_opendir et al functions. */
# define GLOB_BRACE (1 10)/* Expand {a,b} to a b. */
# define GLOB_NOMAGIC (1 11)/* If no magic chars, return the
pattern. */
# define GLOB_TILDE (1 12)/* Expand ~user and ~ to home directories.
*/
# define GLOB_ONLYDIR (1 13)/* Match only directories. */
# define GLOB_TILDE_CHECK (1 14)/* Like GLOB_TILDE but return an error
if the user name is not available. */
so these constant are not supported by uClibc which mean that asterisk
didn't treat uclibc cases or in another way asterisk still don't support
uclibc.
I solved this problem anyway but still the problem in linking the asterisk
object in the end of the process
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 3488: RAII_VAR: nested functions aren't portable. Adapting RAII_VAR to use clang/llvm blocks to get the same/similar functionality.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3488/ --- Review request for Asterisk Developers. Summary (updated) - RAII_VAR: nested functions aren't portable. Adapting RAII_VAR to use clang/llvm blocks to get the same/similar functionality. Bugs: ASTERISK-20850 https://issues.asterisk.org/jira/browse/ASTERISK-20850 Repository: Asterisk Description (updated) --- RAII_VAR: nested functions aren't portable. Adapting RAII_VAR to use clang/llvm blocks to get the same/similar functionality. Making it possible again to use clang as a compiler, instead of depending on gcc completely. Compile instructions: ./bootstrap.sh CC=clang CXX=clang++ ./configure --enable-dev-mode Needed to set DISABLE_INLINE to get passed the double declaration error in api-inline.h, i guess someone needs to figure out how to get this passed clang, correctly make menuselect.makeopts menuselect/menuselect --enable DISABLE_INLINE Needed to suppresse some of the warnings to get clang to compile (for now), clang can be a little panicky, but for a good reason. -Wno-unknown-warning-option. When gcc doesn't know a compiler option it returns NON-ZERO errorlevel, clang returns ZERO errorlevel, which is annoying. Even the linux kernel developers group complained about this. Will be fixed/changed (hopefully soon). For now, when checking clang compiler options, you would need to grep and parse the error output -Wno-error needed to quite down clang being panicky (Standard asterisk -Werror is a good idea in general, but not when compiling against a 'new' compiler ) ASTCFLAGS=-Wno-unknown-warning-option -Wno-error make make install RAII_VAR seems to work, but i guess there is still a bit of work before clang support for the rest of asterisk can be announced. Diffs - /trunk/makeopts.in 413043 /trunk/main/Makefile 413043 /trunk/include/asterisk/utils.h 413043 /trunk/configure.ac 413043 /trunk/Makefile 413043 Diff: https://reviewboard.asterisk.org/r/3488/diff/ Testing --- Thanks, Diederik de Groot -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3488: RAII_VAR: nested functions aren't portable. Adapting RAII_VAR to use clang/llvm blocks to get the same/similar functionality.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3488/ --- (Updated April 28, 2014, 1:28 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-20850 https://issues.asterisk.org/jira/browse/ASTERISK-20850 Repository: Asterisk Description --- RAII_VAR: nested functions aren't portable. Adapting RAII_VAR to use clang/llvm blocks to get the same/similar functionality. Making it possible again to use clang as a compiler, instead of depending on gcc completely. Compile instructions: ./bootstrap.sh CC=clang CXX=clang++ ./configure --enable-dev-mode Needed to set DISABLE_INLINE to get passed the double declaration error in api-inline.h, i guess someone needs to figure out how to get this passed clang, correctly make menuselect.makeopts menuselect/menuselect --enable DISABLE_INLINE Needed to suppresse some of the warnings to get clang to compile (for now), clang can be a little panicky, but for a good reason. -Wno-unknown-warning-option. When gcc doesn't know a compiler option it returns NON-ZERO errorlevel, clang returns ZERO errorlevel, which is annoying. Even the linux kernel developers group complained about this. Will be fixed/changed (hopefully soon). For now, when checking clang compiler options, you would need to grep and parse the error output -Wno-error needed to quite down clang being panicky (Standard asterisk -Werror is a good idea in general, but not when compiling against a 'new' compiler ) ASTCFLAGS=-Wno-unknown-warning-option -Wno-error make make install RAII_VAR seems to work, but i guess there is still a bit of work before clang support for the rest of asterisk can be announced. Diffs - /trunk/makeopts.in 413043 /trunk/main/Makefile 413043 /trunk/include/asterisk/utils.h 413043 /trunk/configure.ac 413043 /trunk/Makefile 413043 Diff: https://reviewboard.asterisk.org/r/3488/diff/ Testing --- Thanks, Diederik de Groot -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3417: Add AMI events for all device state and presence state changes
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3417/ --- (Updated April 28, 2014, 9:40 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 413060 Repository: Asterisk Description --- AMI does not emit events when device state or presence state changes. The closest things that exist currently are the ExtenstionStatus and PresenceStatus events, which inform about device state and presence state events as they pertain to hints in the dialplan. These new events are raised for every device state change or presence state change in Asterisk. Diffs - /trunk/res/res_manager_presencestate.c PRE-CREATION /trunk/res/res_manager_devicestate.c PRE-CREATION /trunk/main/presencestate.c 412583 /trunk/main/devicestate.c 412583 Diff: https://reviewboard.asterisk.org/r/3417/diff/ Testing --- See /r/3418 Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3418: Test the DeviceStateChange and PresenceStateChange AMI events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3418/ --- (Updated April 28, 2014, 9:43 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5000 Repository: testsuite Description --- These are simple tests that ensure the new events introduced in /r/3417 are being emitted properly. If you're curious why I didn't use an orderedheadermatch AMI event instance in my test-config.yaml files here, it's because if I do that, then there's no way to detect that the test has completed before the reactor timeout. These tests run in ~4 seconds instead of about ~30 as a result. Diffs - /asterisk/trunk/tests/manager/tests.yaml 4836 /asterisk/trunk/tests/manager/presence_state_changed/test-config.yaml PRE-CREATION /asterisk/trunk/tests/manager/presence_state_changed/ami_presence_state.py PRE-CREATION /asterisk/trunk/tests/manager/device_state_changed/test-config.yaml PRE-CREATION /asterisk/trunk/tests/manager/device_state_changed/ami_device_state.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3418/diff/ Testing --- Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3471: Filesystem based dynamic MoH classes
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3471/ --- (Updated April 28, 2014, 3:26 p.m.) Status -- This change has been discarded. Review request for Asterisk Developers. Bugs: ASTERISK-23636 https://issues.asterisk.org/jira/browse/ASTERISK-23636 Repository: Asterisk Description --- This patch introduces another approach to dynamically controlled MoH. Unlike realtime this way is file based. As a switch between normal and alternative behavior, boolean variable 'dynamic' is used in MoH config file. By setting dynamic=yes new behavior is switched on. How dynamic behavior works All static MoH classes in musiconhold.conf and realtime are ignored, except [default] class. On the other hand dynamic class named 'default' is ignored too. New variable 'dynamic_dir' defines directory, where dynamic classes are defined. Each first level subdirectory of dynamic_dir defines one MoH class with same name as directory name. If class directory contains playlist file 'playlist.txt' content of the file defines audiofiles in class and their order. Otherwise directory is scanned same way as for standard MoH class with mode=files. Playlist expects one file on line, without path and without extension. Files must be placed in class directory. If first line of playlist contains exactly one character '%', files will be ordered randomly. Diffs - /trunk/res/res_musiconhold.c 412900 /trunk/configs/musiconhold.conf.sample 412900 /trunk/CHANGES 412900 Diff: https://reviewboard.asterisk.org/r/3471/diff/ Testing --- Original 'static' behavior with dynamic=no Dynamic class without playlist Dynamic class with playlist Random ordering with % on first line of playlist % as audio file name Thanks, Vitezslav Novy -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3476: Memory Pre- and Post-Test Condition
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3476/#review11762 --- ./asterisk/trunk/lib/python/asterisk/memory_test_condition.py https://reviewboard.asterisk.org/r/3476/#comment21568 if not pre_cond ./asterisk/trunk/sample-yaml/memorytestcondition-config.yaml.sample https://reviewboard.asterisk.org/r/3476/#comment21567 Are these options necessary for using the memory test conditions? If not, you should just remove these from the sample. ./asterisk/trunk/sample-yaml/memorytestcondition-config.yaml.sample https://reviewboard.asterisk.org/r/3476/#comment21566 The units need to be specified here (bytes? kilobytes?) - Mark Michelson On April 25, 2014, 8:42 p.m., Benjamin Keith Ford wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3476/ --- (Updated April 25, 2014, 8:42 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-18429 https://issues.asterisk.org/jira/browse/ASTERISK-18429 Repository: testsuite Description --- This testcondition can be enabled for any test using the keyword 'memory' under testconditions. The purpose of this testcondition is to check the memory allocated before and after the test, and make sure they are within a certain range. If the test wants to look at something specific (such as channel.c), then each allocation that you want to look at can also be specified in under 'allocations'. If both the global memory and individual allocations are to be checked by the test, that option can be enabled by setting 'both' to value True. Diffs - ./asterisk/trunk/test-config.yaml 4944 ./asterisk/trunk/sample-yaml/memorytestcondition-config.yaml.sample PRE-CREATION ./asterisk/trunk/lib/python/asterisk/test_conditions.py 4944 ./asterisk/trunk/lib/python/asterisk/test_case.py 4944 ./asterisk/trunk/lib/python/asterisk/memory_test_condition.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3476/diff/ Testing --- Thanks, Benjamin Keith Ford -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3476: Memory Pre- and Post-Test Condition
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3476/ --- (Updated April 28, 2014, 3:46 p.m.) Review request for Asterisk Developers. Changes --- - Updated some logic and comments - Removed unnecessary text in the sample yaml Bugs: ASTERISK-18429 https://issues.asterisk.org/jira/browse/ASTERISK-18429 Repository: testsuite Description --- This testcondition can be enabled for any test using the keyword 'memory' under testconditions. The purpose of this testcondition is to check the memory allocated before and after the test, and make sure they are within a certain range. If the test wants to look at something specific (such as channel.c), then each allocation that you want to look at can also be specified in under 'allocations'. If both the global memory and individual allocations are to be checked by the test, that option can be enabled by setting 'both' to value True. Diffs (updated) - ./asterisk/trunk/test-config.yaml 4944 ./asterisk/trunk/sample-yaml/memorytestcondition-config.yaml.sample PRE-CREATION ./asterisk/trunk/lib/python/asterisk/test_conditions.py 4944 ./asterisk/trunk/lib/python/asterisk/test_case.py 4944 ./asterisk/trunk/lib/python/asterisk/memory_test_condition.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3476/diff/ Testing --- Thanks, Benjamin Keith Ford -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3479: chan_pjsip: Call pickup test.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3479/#review11763 --- /asterisk/trunk/tests/channels/pjsip/call_pickup/run-test https://reviewboard.asterisk.org/r/3479/#comment21569 You shouldn't need this import anymore /asterisk/trunk/tests/channels/pjsip/call_pickup/run-test https://reviewboard.asterisk.org/r/3479/#comment21570 You should be able to remove this entire method - Matt Jordan On April 26, 2014, 5:57 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3479/ --- (Updated April 26, 2014, 5:57 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- This is a modified version of the normal call pickup test which uses chan_pjsip instead of chan_sip to test call pickup functionality. Diffs - /asterisk/trunk/tests/channels/pjsip/call_pickup/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/call_pickup/run-test PRE-CREATION /asterisk/trunk/tests/channels/pjsip/call_pickup/configs/ast2/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/call_pickup/configs/ast2/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/call_pickup/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/call_pickup/configs/ast1/features.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/call_pickup/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3479/diff/ Testing --- I tested the test by running the test. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3480: chan_pjsip: Implement get_pvt_uniqueid channel technology callback.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3480/#review11764 --- Ship it! Ship It! - Matt Jordan On April 25, 2014, 11:43 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3480/ --- (Updated April 25, 2014, 11:43 a.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- This change implements the get_pvt_uniqueid channel technology callback in chan_pjsip which returns the call-id of the underlying dialog in use. Diffs - /branches/12/channels/chan_pjsip.c 413007 Diff: https://reviewboard.asterisk.org/r/3480/diff/ Testing --- Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3428/#review11765 --- What happened to the channel test? - Matt Jordan On April 25, 2014, 4:21 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3428/ --- (Updated April 25, 2014, 4:21 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23433 https://issues.asterisk.org/jira/browse/ASTERISK-23433 Repository: testsuite Description --- The YAML files have pretty apt descriptions. Channel version: * Originate a channel * Playback a tone * Pause it * Unpause it * Restart it * Delete the tone playback * Delete the channel * Validate all the events Bridge version: * Originate a channel * Create a bridge * Add the channel to the bridge * Start a tone playback on the bridge * Delete the tone playback * Delete the channel * Validate all the events Diffs - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 Diff: https://reviewboard.asterisk.org/r/3428/diff/ Testing --- Ran tests, varied results, the usual. They aren't especially changed from the tests they are based on (in each case there is an existing baseline test in the same folder which handles sounds). Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges
On April 28, 2014, 12:06 p.m., Matt Jordan wrote: What happened to the channel test? It appears to have gotten up and walked away. I'll fix it. - Jonathan --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3428/#review11765 --- On April 25, 2014, 4:21 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3428/ --- (Updated April 25, 2014, 4:21 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23433 https://issues.asterisk.org/jira/browse/ASTERISK-23433 Repository: testsuite Description --- The YAML files have pretty apt descriptions. Channel version: * Originate a channel * Playback a tone * Pause it * Unpause it * Restart it * Delete the tone playback * Delete the channel * Validate all the events Bridge version: * Originate a channel * Create a bridge * Add the channel to the bridge * Start a tone playback on the bridge * Delete the tone playback * Delete the channel * Validate all the events Diffs - /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 Diff: https://reviewboard.asterisk.org/r/3428/diff/ Testing --- Ran tests, varied results, the usual. They aren't especially changed from the tests they are based on (in each case there is an existing baseline test in the same folder which handles sounds). Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3428/ --- (Updated April 28, 2014, 12:17 p.m.) Review request for Asterisk Developers. Changes --- Made sure channels tests made it into the diff this time. Bugs: ASTERISK-23433 https://issues.asterisk.org/jira/browse/ASTERISK-23433 Repository: testsuite Description --- The YAML files have pretty apt descriptions. Channel version: * Originate a channel * Playback a tone * Pause it * Unpause it * Restart it * Delete the tone playback * Delete the channel * Validate all the events Bridge version: * Originate a channel * Create a bridge * Add the channel to the bridge * Start a tone playback on the bridge * Delete the tone playback * Delete the channel * Validate all the events Diffs (updated) - /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/tones/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/tones/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py PRE-CREATION /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 Diff: https://reviewboard.asterisk.org/r/3428/diff/ Testing --- Ran tests, varied results, the usual. They aren't especially changed from the tests they are based on (in each case there is an existing baseline test in the same folder which handles sounds). Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3481: Websocket: Add locking around session access and modification
On April 25, 2014, 2:04 p.m., Matt Jordan wrote: branches/11/res/res_http_websocket.c, lines 526-530 https://reviewboard.asterisk.org/r/3481/diff/1/?file=57910#file57910line526 So, while locking may solve the issue, there's something more insidious about this part of the code that doesn't sit well with me. (Note: this is the actual culprit that causes a crash in the websocket write) I'm not sure that the way this is currently handled is the right way to handle a AST_WEBSOCKET_OPCODE_CLOSE. The session destructor will already close the the file descriptor. Ideally, we'd just let the destruction of the session do this work for us. It feels like the right way to handle this may be to just let the caller of ast_websocket_read know that they were told that the session needs to die. That would let them de-ref the session appropriately. If a concurrent write was occurring at the same time, when the write completes, the session would be terminated. Now, whether or not it's allowed to have a write complete when you've just been told to close the websocket is another question. If not, then we have to keep all of the locking in here. There is provision for this situation in the RFC stating that the side of the connection wishing to close the connection must wait for a close acknowledgement to shut down the TCP connection. I'd like to keep the locking in place for ast_websocket_close and ast_websocket_write as there is a chance of interleaved writes since the header and payload in ast_websocket_write are written in two different fwrite()s. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/#review11756 --- On April 25, 2014, 1:46 p.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/ --- (Updated April 25, 2014, 1:46 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23605 https://issues.asterisk.org/jira/browse/ASTERISK-23605 Repository: Asterisk Description --- This resolves a race condition where data could be written to a NULL FILE pointer causing a crash as a websocket connection was in the process of shutting down by adding locking to accesses and modifications of the websocket session struct. Diffs - branches/11/res/res_http_websocket.c 413007 Diff: https://reviewboard.asterisk.org/r/3481/diff/ Testing --- Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
On April 28, 2014, 5:14 p.m., Matt Jordan wrote: /branches/12/res/res_pjsip_refer.c, lines 898-906 https://reviewboard.asterisk.org/r/3485/diff/1/?file=57945#file57945line898 This feels like the wrong way to solve this problem. Having a 'parked' variable bleed up into this handling feels like we've got a design flaw in how we're handling parking. refer_progress_bridge *should* be detecting that the channel entered into a holding bridge. That should be sending the 200 notification. If that isn't happening, then there is some other bug here that this solution is masking. The problem here is that the stasis subscription that sets up refer_progress_bridge never gets the opportunity to get set up. refer_blind_callback() is called on the local channel that ends up running dialplan during a blind transfer. When transferring to parking, such a local channel is typically not created since the transferee channel is moved directly from its current bridge into the parking bridge. Thus all the progress-tracking code is bypassed. It was my suggestion to use a separate return value to indicate a successful transfer had occurred due to being parked (or more generically, the transfer was successful and was entirely complete). There's no bug that the solution is masking, it's just that parking bypasses the typical blind transfer process, and so it has to be taken into account. The problem is that transfers to parking require special handling, and that unfortunately bleeds out to others. - Mark --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11766 --- On April 25, 2014, 10:48 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 25, 2014, 10:48 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs - /branches/12/res/res_pjsip_refer.c 412824 /branches/12/main/manager.c 412824 /branches/12/main/bridge_basic.c 412824 /branches/12/main/bridge.c 412824 /branches/12/include/asterisk/bridge.h 412824 /branches/12/channels/chan_unistim.c 412824 /branches/12/channels/chan_skinny.c 412824 /branches/12/channels/chan_sip.c 412824 /branches/12/channels/chan_oss.c 412824 /branches/12/channels/chan_iax2.c 412824 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11770 --- I've got a new patch in the works for this that adds the transfer_channel_cb stuff to the parking function. I've tested it with two-party bridges so far and it seems to work fine without having to add special logic to the consumers of the blind transfer function for handling parked calls. - Jonathan Rose On April 25, 2014, 5:48 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 25, 2014, 5:48 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs - /branches/12/res/res_pjsip_refer.c 412824 /branches/12/main/manager.c 412824 /branches/12/main/bridge_basic.c 412824 /branches/12/main/bridge.c 412824 /branches/12/include/asterisk/bridge.h 412824 /branches/12/channels/chan_unistim.c 412824 /branches/12/channels/chan_skinny.c 412824 /branches/12/channels/chan_sip.c 412824 /branches/12/channels/chan_oss.c 412824 /branches/12/channels/chan_iax2.c 412824 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 28, 2014, 2:10 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Changes --- Ok, this changes the angle of approach significantly. Instead of making an exception for parking as far as the PJSIP logic goes, we forward the new_channel_cb into the parking blind transfer function and use it on whichever channel is going to get parked (either local or the one being transferred). I've now tested this on both two party bridges and multi party bridges and it seems to work without fail. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs (updated) - /branches/12/res/parking/parking_bridge_features.c 413071 /branches/12/main/parking.c 413071 /branches/12/main/bridge.c 413071 /branches/12/include/asterisk/parking.h 413071 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11771 --- Ship it! Yes, I like this much better! Much better than what I had originally suggested. - Mark Michelson On April 28, 2014, 7:10 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 28, 2014, 7:10 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs - /branches/12/res/parking/parking_bridge_features.c 413071 /branches/12/main/parking.c 413071 /branches/12/main/bridge.c 413071 /branches/12/include/asterisk/parking.h 413071 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11772 --- /branches/12/res/parking/parking_bridge_features.c https://reviewboard.asterisk.org/r/3485/#comment21577 Oops, accidentally used a tab instead of a space here. It's fixed in my local copy. - Jonathan Rose On April 28, 2014, 2:10 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 28, 2014, 2:10 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs - /branches/12/res/parking/parking_bridge_features.c 413071 /branches/12/main/parking.c 413071 /branches/12/main/bridge.c 413071 /branches/12/include/asterisk/parking.h 413071 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11774 --- Ship it! Ship It! - Matt Jordan On April 28, 2014, 2:10 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 28, 2014, 2:10 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs - /branches/12/res/parking/parking_bridge_features.c 413071 /branches/12/main/parking.c 413071 /branches/12/main/bridge.c 413071 /branches/12/include/asterisk/parking.h 413071 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang
On April 28, 2014, 12:14 p.m., Matt Jordan wrote: /branches/12/res/res_pjsip_refer.c, lines 898-906 https://reviewboard.asterisk.org/r/3485/diff/1/?file=57945#file57945line898 This feels like the wrong way to solve this problem. Having a 'parked' variable bleed up into this handling feels like we've got a design flaw in how we're handling parking. refer_progress_bridge *should* be detecting that the channel entered into a holding bridge. That should be sending the 200 notification. If that isn't happening, then there is some other bug here that this solution is masking. Mark Michelson wrote: The problem here is that the stasis subscription that sets up refer_progress_bridge never gets the opportunity to get set up. refer_blind_callback() is called on the local channel that ends up running dialplan during a blind transfer. When transferring to parking, such a local channel is typically not created since the transferee channel is moved directly from its current bridge into the parking bridge. Thus all the progress-tracking code is bypassed. It was my suggestion to use a separate return value to indicate a successful transfer had occurred due to being parked (or more generically, the transfer was successful and was entirely complete). There's no bug that the solution is masking, it's just that parking bypasses the typical blind transfer process, and so it has to be taken into account. The problem is that transfers to parking require special handling, and that unfortunately bleeds out to others. Okay, that makes sense now how we ended up on this solution, but I agree with your later comment - I like the new approach much better. Keeping consumers unaware of whether or not the destination happens to be the craziness that is parking is a win. - Matt --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/#review11766 --- On April 28, 2014, 2:10 p.m., Jonathan Rose wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3485/ --- (Updated April 28, 2014, 2:10 p.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Repository: Asterisk Description --- If a PJSIP endpoint attempts to blind transfer to a parking extension, there is an override to the normal transfer logic that can make things act a little weird. We noticed that this would leave various phones hanging on transfer screens without progressing. When the transfer was considered successful, PJSIP deferred the actual action of sending the 200 notify and the actual trigger for that happening never occurs when the transfer is to a parking extension. In order to handle this, the bridge function that handles blind transfers now returns a different value if a call was parked and if the channel driver needs to react differently in this case, it can. In the case of PJSIP, we respond to transfers to park by immediately sending the notify with 200 OK sip frag instead of deferring the action. Diffs - /branches/12/res/parking/parking_bridge_features.c 413071 /branches/12/main/parking.c 413071 /branches/12/main/bridge.c 413071 /branches/12/include/asterisk/parking.h 413071 Diff: https://reviewboard.asterisk.org/r/3485/diff/ Testing --- Before patch: * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until it either manually hangs up or 60 seconds pass and Asterisk terminates the session. After the patch: * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer screen and goes back to idle mode. Thanks, Jonathan Rose -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3476: Memory Pre- and Post-Test Condition
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3476/#review11775 --- Ship it! Ship It! - Mark Michelson On April 28, 2014, 3:46 p.m., Benjamin Keith Ford wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3476/ --- (Updated April 28, 2014, 3:46 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-18429 https://issues.asterisk.org/jira/browse/ASTERISK-18429 Repository: testsuite Description --- This testcondition can be enabled for any test using the keyword 'memory' under testconditions. The purpose of this testcondition is to check the memory allocated before and after the test, and make sure they are within a certain range. If the test wants to look at something specific (such as channel.c), then each allocation that you want to look at can also be specified in under 'allocations'. If both the global memory and individual allocations are to be checked by the test, that option can be enabled by setting 'both' to value True. Diffs - ./asterisk/trunk/test-config.yaml 4944 ./asterisk/trunk/sample-yaml/memorytestcondition-config.yaml.sample PRE-CREATION ./asterisk/trunk/lib/python/asterisk/test_conditions.py 4944 ./asterisk/trunk/lib/python/asterisk/test_case.py 4944 ./asterisk/trunk/lib/python/asterisk/memory_test_condition.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3476/diff/ Testing --- Thanks, Benjamin Keith Ford -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 3489: testsuite: Improve logging
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3489/ --- Review request for Asterisk Developers. Repository: testsuite Description --- This patch changes up the logging in the Asterisk Test Suite. It dramatically reduces the amount of logging done in the logs/ directory by default (although this can always be bumped up), and it redirects the vast majority of the test suite logs to the actual sandboxed test run directories themselves. When we first added Python logging (it didn't always used to be there!) there were far fewer tests. Having all tests dump into the same log files actually felt like a benefit, since during test development (or when developing many tests) it made it easier to debug test failures. Over time, however, this approach has run into a number of problems: (1) Many of the tests are much 'chattier' than they used to be. Having twisted, starpy, websockets, requests, and other libraries dump information has greatly increased the number of log messages. Not to mention logging out every SIPp screen received... (2) There are a lot more tests than there were when this was added. (3) Tailing a log file is not always the best way to debug. Sometimes you have to search through an entire log file for one run. Finding the error becomes problematic when your editor of choice chokes on the size of the file. Hence, this patch. Logging now works in the following way: (1) The test_case.TestCase class now always sets up the logging. The logging set up done by test_runner was removed (as it only logged out a few messages before an instance of TestCase was created anyway). (2) A global logger can still be configured in logger.conf. It now only sets up a logger of INFO messages and higher. This allows a test executor to watch which tests are being run, without getting spammed. During test development, the log message level can be increased to DEBUG. (3) TestCase now places the Asterisk directories created by the test execution in a further subfolder, run_N (where N increases with each execution of that test). Where before you might have: tests/my_test/ast1 tests/my_test/ast2 tests/my_test/ast3 tests/my_test/ast4 You will now have: tests/my_test/run_1/ast1 tests/my_test/run_1/ast2 tests/my_test/run_2/ast1 tests/my_test/run_2/ast2 This lets you determine which Asterisk instances belong together, and also makes it possible for only the erroring test run to be archived when a test fails (as opposed to every Asterisk directory) (4) TestCase now creates a DEBUG and INFO log file(s) in the run directory. These contain the full Asterisk logs for the test run. Diffs - /asterisk/trunk/runtests.py 5002 /asterisk/trunk/logger.conf 5002 /asterisk/trunk/lib/python/asterisk/test_runner.py 5002 /asterisk/trunk/lib/python/asterisk/test_case.py 5002 /asterisk/trunk/lib/python/asterisk/asterisk.py 5002 Diff: https://reviewboard.asterisk.org/r/3489/diff/ Testing --- I've actually been running an instance of the test suite with this set up for several months, using it for development of several tests and generally tweaking it. I finally felt like it was good enough. Tested: * Failing tests archive appropriately * Crashing Asterisk gets archived * Global log file is still created with expected message levels * Test specific log files are created appropriately with expected message levels * Tested a pluggable module based test (pbx/dialplan) and a 'traditional' Python test (channels/SIP/sip_hold) Thanks, Matt Jordan -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 3490: Testsuite: Ensure that repeated device states and presence states behave as expected
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3490/
---
Review request for Asterisk Developers.
Bugs: ASTERISK-23672
https://issues.asterisk.org/jira/browse/ASTERISK-23672
Repository: testsuite
Description
---
In ASTERISK-23672, it was reported that when the presence state of an entity
was changed such that the state was the same but the subtype or message
differed from what was previously set, NOTIFYs were not sent to SIP
subscribers. Looking at the code, it appeared that res_pjsip_exten_state was
being overzealous in trying to filter out repeated state changes and that the
core PBX code already performed the necessary filtering.
I made the following change to res_pjsip_exten_state.c, which I'm not placing
in its own review due to its small size:
Index: res/res_pjsip_exten_state.c
===
--- res/res_pjsip_exten_state.c (revision 412578)
+++ res/res_pjsip_exten_state.c (working copy)
@@ -334,11 +334,6 @@
struct notify_task_data *task_data;
struct exten_state_subscription *exten_state_sub = data;
- if (exten_state_sub-last_exten_state == info-exten_state
- exten_state_sub-last_presence_state == info-presence_state) {
- return 0;
- }
-
if (!(task_data = alloc_notify_task_data(exten, exten_state_sub,
info))) {
return -1;
}
I then created three testsuite tests to ensure that behavior is as we expect
for it to be:
devstate_repeat: This relies on the device state for a custom device state to
be not in use initially. A subscriber subscribes to a custom device state. We
then set a device state change for the custom device state to be not in use.
Since there is no change in the device state, no NOTIFY should be sent to the
subscriber.
presencestate_repeat: This sets an initial presence state for a CustomPresence
entity. A SIP subscriber subscribes to the custom presence state. We then set
the presence state to the exact same value again and ensure that no additional
NOTIFYs are sent to the subscriber.
presencestate_repeat_okay: This sets an initial presence state for a
CustomPresence entity. A SIP subscriber subscribes to the custom presence
state. We then change the presence state twice. The first change keeps the same
state and message and changes the subtype. The second change keeps the same
state and subtype and changes the message. These should result in two
additional NOTIFYs being sent to the subscriber.
Diffs
-
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/tests.yaml 5004
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat_okay/test-config.yaml
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat_okay/sipp/subscribe.xml
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat_okay/repeat_presence_state.py
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat_okay/configs/ast1/pjsip.conf
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat_okay/configs/ast1/extensions.conf
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat/test-config.yaml
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat/sipp/subscribe.xml
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat/repeat_presence_state.py
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat/configs/ast1/pjsip.conf
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/presencestate_repeat/configs/ast1/extensions.conf
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/devstate_repeat/test-config.yaml
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/devstate_repeat/sipp/subscribe.xml
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/devstate_repeat/repeat_device_state.py
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/devstate_repeat/configs/ast1/pjsip.conf
PRE-CREATION
/asterisk/trunk/tests/channels/pjsip/subscriptions/presence/devstate_repeat/configs/ast1/extensions.conf
PRE-CREATION
Diff: https://reviewboard.asterisk.org/r/3490/diff/
Testing
---
Prior to the diff mentioned in the description, devstate_repeat and
presencestate_repeat would pass, but presencestate_repeat_okay would not. With
the diff above applied, all three tests pass.
Thanks,
Mark Michelson
--
_
--
[asterisk-dev] A thread for format work
Like a normal person, I decided to poke at the format work while watching
tornadoes track North and South of Huntsville (because really, what else
are you going to do?) After looking through Josh's notes on the wiki [1]
and the code in the team branch [2], I decided to tackle bridge_native_rtp
(as it was the first thing that didn't compile). After hacking through it a
bit, I had a few questions. Since this is going to be a recurring theme
while working on this, a thread seemed in order.
So: if you decide to work on this or take a poke at it and have some
questions about things, feel free to respond to this thread.
Anyway, without further ado:
There is a portion of bridge_native_rtp that attempts to check if the
channels are still compatible. If not, it breaks the native bridge so that
the bridging framework can attempt a more suitable mixing technology. Part
of the check looks at the packetization attribute of the formats in use:
read_ptime0 =
(ast_codec_pref_getsize(ast_rtp_instance_get_codecs(instance0)-pref,
ast_channel_rawreadformat(c0-chan))).cur_ms;
read_ptime1 =
(ast_codec_pref_getsize(ast_rtp_instance_get_codecs(instance1)-pref,
ast_channel_rawreadformat(c1-chan))).cur_ms;
write_ptime0 =
(ast_codec_pref_getsize(ast_rtp_instance_get_codecs(instance0)-pref,
ast_channel_rawwriteformat(c0-chan))).cur_ms;
write_ptime1 =
(ast_codec_pref_getsize(ast_rtp_instance_get_codecs(instance1)-pref,
ast_channel_rawwriteformat(c1-chan))).cur_ms;
if (read_ptime0 != write_ptime1 || read_ptime1 != write_ptime0) {
ast_debug(1, Packetization differs between RTP streams (%d != %d
or %d != %d). Cannot native bridge in RTP\n,
read_ptime0, write_ptime1, read_ptime1, write_ptime0);
return 0;
}
That is, if the packetization between the read/write of each channel pair
is not the same, break the bridge.
Right now, there aren't compatible calls with this code in the branch.
So... questions!
(1) Where will the packetization of a format on a channel reside? With the
format on the channel? Or with the capability of the channel?
(2) Should we even be bothering with the codec's preferred packetization
here? It doesn't really matter what a codec prefers at this point - if an
SDP negotiated a different packetization rate, that's what we care about...
(3) Are all these questions moot, and should I just go ahead and add the
proposed framing size functions from the wiki:
{quote}
Framing size
The framing size controls the length of media frames (in milliseconds).
Previously this was stored in a separate structure but has now been rolled
into ast_format_cap. To allow control two API calls will be added.
void ast_format_cap_framing_set(struct ast_format_cap *cap, const struct
ast_format *format, unsigned int framing);
unsigned int ast_format_cap_framing_get(const struct ast_format_cap *cap,
const struct ast_format *format);
{quote}
[1] https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
[2] https://origsvn.digium.com/svn/asterisk/team/group/media_formats
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com http://asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
