Re: [asterisk-dev] Asterisk-11.5.1 Confbridge Dailout using pbx_exce new user not placed into current conference
hkc323 hkc323 at gmail.com writes: SOLVED NOW -- _ -- 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?
Hi Olle, adding Kamailio is one option, but I must admit that I don't want to complicate the existing setup any more and Asterisk is working quite well. Actually I can live without the feature - it would just make things more nicer ;) About adding this feature - I can only offer some my work time (and one of my co-workers) to implement this feature. We could start this probably in June. But as I am not an experienced Asterisk-Developer it would be great, if you (or somebody else) could help me in finding the best starting point... Cheers, Dennis 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 Mon, Apr 28, 2014 at 10:26 AM, Olle E. Johansson o...@edvina.net wrote: 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 -- _ -- 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] A thread for format work
Matthew Jordan wrote:
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?
It has to reside in the RTP engine layer and optionally can (but I've
written it so it is) in the format capabilities layer.
It has to be in the RTP layer so that the underlying stack can know how
to set up the smoother so packets contain the right amount of media.
It can optionally be in format capabilities so that further down the
road the smoothing logic can be moved out of RTP and into the core.
(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...
The naming of the structure above is misleading because it was extended.
It contains negotiated codec preferences and packetization.
(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}
The ability to set the framing per-format, globally in a capabilities
structure, and to get the framing already exists. What doesn't exist is
adding a format and then setting the framing as two separate API calls.
That is something that could be added but to make sure you set the right
format (format capabilities can contain multiple formats of the same
codec) you have to keep that format around, in which case why not just
add/set in the same API call?
Cheers,
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com www.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
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/ --- (Updated April 29, 2014, 6:19 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 413088 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] 3479: chan_pjsip: Call pickup test.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3479/ --- (Updated April 29, 2014, 11:29 a.m.) Review request for Asterisk Developers. Changes --- Incorporate some further feedback 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 (updated) - /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] A thread for format work
On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp jc...@digium.com wrote: Matthew Jordan wrote: (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? It has to reside in the RTP engine layer and optionally can (but I've written it so it is) in the format capabilities layer. It has to be in the RTP layer so that the underlying stack can know how to set up the smoother so packets contain the right amount of media. It can optionally be in format capabilities so that further down the road the smoothing logic can be moved out of RTP and into the core. I'd say it makes sense then for the information to reside in an ast_format_cap structure. The RTP engine can use that as its storage mechanism, and it makes it easier to extract to the core if needed. Storing it in two places could get confusing and lead to errors. snip (3) Are all these questions moot, and should I just go ahead and add the proposed framing size functions from the wiki: snip The ability to set the framing per-format, globally in a capabilities structure, and to get the framing already exists. What doesn't exist is adding a format and then setting the framing as two separate API calls. That is something that could be added but to make sure you set the right format (format capabilities can contain multiple formats of the same codec) you have to keep that format around, in which case why not just add/set in the same API call? We may end up needing that API call sometime down the road. For example, if an Offer arrives with a new ptime attribute, it may be easier to modify an existing ast_format_cap structure rather than create a new one. But currently I just need the packetization values. What API call provides them? I must be missing it, because I couldn't seem to find it in format_cap.h. (I could be just going crazy however) Matt -- 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
Re: [asterisk-dev] A thread for format work
On Tue, Apr 29, 2014 at 6:49 AM, Matthew Jordan mjor...@digium.com wrote: On Tue, Apr 29, 2014 at 6:15 AM, Joshua Colp jc...@digium.com wrote: snip The ability to set the framing per-format, globally in a capabilities structure, and to get the framing already exists. What doesn't exist is adding a format and then setting the framing as two separate API calls. That is something that could be added but to make sure you set the right format (format capabilities can contain multiple formats of the same codec) you have to keep that format around, in which case why not just add/set in the same API call? We may end up needing that API call sometime down the road. For example, if an Offer arrives with a new ptime attribute, it may be easier to modify an existing ast_format_cap structure rather than create a new one. But currently I just need the packetization values. What API call provides them? I must be missing it, because I couldn't seem to find it in format_cap.h. (I could be just going crazy however) Disregard! ast_format_cap_get_framing it is. -- 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
Re: [asterisk-dev] A thread for format work
Matthew Jordan wrote: snip snip The ability to set the framing per-format, globally in a capabilities structure, and to get the framing already exists. What doesn't exist is adding a format and then setting the framing as two separate API calls. That is something that could be added but to make sure you set the right format (format capabilities can contain multiple formats of the same codec) you have to keep that format around, in which case why not just add/set in the same API call? We may end up needing that API call sometime down the road. For example, if an Offer arrives with a new ptime attribute, it may be easier to modify an existing ast_format_cap structure rather than create a new one. But currently I just need the packetization values. Since ptime in SIP applies to the media stream (and not to a specific media format) you can actually set a global framing value using ast_format_cap_set_framing. This applies to all media formats within a capabilities structure, unless one is specified for the format explicitly. What API call provides them? I must be missing it, because I couldn't seem to find it in format_cap.h. (I could be just going crazy however) For getting them you use ast_format_cap_get_framing. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com www.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
Re: [asterisk-dev] A thread for format work
On Tue, Apr 29, 2014 at 6:55 AM, Joshua Colp jc...@digium.com wrote: Matthew Jordan wrote: snip snip The ability to set the framing per-format, globally in a capabilities structure, and to get the framing already exists. What doesn't exist is adding a format and then setting the framing as two separate API calls. That is something that could be added but to make sure you set the right format (format capabilities can contain multiple formats of the same codec) you have to keep that format around, in which case why not just add/set in the same API call? We may end up needing that API call sometime down the road. For example, if an Offer arrives with a new ptime attribute, it may be easier to modify an existing ast_format_cap structure rather than create a new one. But currently I just need the packetization values. Since ptime in SIP applies to the media stream (and not to a specific media format) you can actually set a global framing value using ast_format_cap_set_framing. This applies to all media formats within a capabilities structure, unless one is specified for the format explicitly. Yup. That's why I was thinking that ast_format_cap is the most logical place to store it. What API call provides them? I must be missing it, because I couldn't seem to find it in format_cap.h. (I could be just going crazy however) For getting them you use ast_format_cap_get_framing. So something like: read_ptime0 = ast_format_cap_get_framing(cap0, ast_channel_rawreadformat(c0-chan)); read_ptime1 = ast_format_cap_get_framing(cap1, ast_channel_rawreadformat(c1-chan)); write_ptime0 = ast_format_cap_get_framing(cap0, ast_channel_rawwriteformat(c0-chan)); write_ptime1 = ast_format_cap_get_framing(cap1, ast_channel_rawwriteformat(c1-chan)); My concern here is that the capabilities are obtained from the channel driver via the get_codec callbacks. I'm not sure that's correct, since the previous approach got the codecs from the rtp instance via ast_rtp_instance_get_codecs. However, as that is an AST_VECTOR of ast_formats, there's not a clean way to turn that into an ast_format_cap. Do we need a call that turns the vector of formats into a capabilities structure? Or is what comes back from the get_codecs callback sufficient? -- 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
Re: [asterisk-dev] A thread for format work
Matthew Jordan wrote: snip So something like: read_ptime0 = ast_format_cap_get_framing(cap0, ast_channel_rawreadformat(c0-chan)); read_ptime1 = ast_format_cap_get_framing(cap1, ast_channel_rawreadformat(c1-chan)); write_ptime0 = ast_format_cap_get_framing(cap0, ast_channel_rawwriteformat(c0-chan)); write_ptime1 = ast_format_cap_get_framing(cap1, ast_channel_rawwriteformat(c1-chan)); My concern here is that the capabilities are obtained from the channel driver via the get_codec callbacks. I'm not sure that's correct, since the previous approach got the codecs from the rtp instance via ast_rtp_instance_get_codecs. However, as that is an AST_VECTOR of ast_formats, there's not a clean way to turn that into an ast_format_cap. Do we need a call that turns the vector of formats into a capabilities structure? Or is what comes back from the get_codecs callback sufficient? For the purposes of the above call the framing on the channels themselves will match what is being used - so doing everything using the nativeformats capabilities of the channel will be equivalent to the old code. The only difference is everything is stored on the channel and being accessed there. The question becomes... how do we notify the RTP side of stuff for *setting up* the smoother. Since format capabilities are reference counted we could pass in the same structure as the channel nativeformats, and have it access that. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com www.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
Re: [asterisk-dev] [Code Review] 3481: Websocket: Add locking around session access and modification
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/#review11778 --- branches/11/res/res_http_websocket.c https://reviewboard.asterisk.org/r/3481/#comment21582 Is there any need for this since it should always be non-NULL now? branches/11/res/res_http_websocket.c https://reviewboard.asterisk.org/r/3481/#comment21583 I don't see a close_sent change in here. branches/11/res/res_http_websocket.c https://reviewboard.asterisk.org/r/3481/#comment21584 I'd remove this or change the message - otherwise you'll get it twice. - Joshua Colp On April 28, 2014, 6:18 p.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/ --- (Updated April 28, 2014, 6:18 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] 3481: Websocket: Add locking around session access and modification
On April 29, 2014, 7:28 a.m., Joshua Colp wrote: branches/11/res/res_http_websocket.c, line 125 https://reviewboard.asterisk.org/r/3481/diff/2/?file=58003#file58003line125 Is there any need for this since it should always be non-NULL now? There is at least one code path where this can still occur on session creation. On April 29, 2014, 7:28 a.m., Joshua Colp wrote: branches/11/res/res_http_websocket.c, line 195 https://reviewboard.asterisk.org/r/3481/diff/2/?file=58003#file58003line195 I don't see a close_sent change in here. close_sent is set to 1 on line 206. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/#review11778 --- On April 28, 2014, 1:18 p.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/ --- (Updated April 28, 2014, 1:18 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] 3481: Websocket: Add locking around session access and modification
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/ --- (Updated April 29, 2014, 8:14 a.m.) Review request for Asterisk Developers. Changes --- Remove duplicate log message. 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 (updated) - branches/11/res/res_http_websocket.c 413072 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] 3481: Websocket: Add locking around session access and modification
On April 29, 2014, 12:28 p.m., Joshua Colp wrote: branches/11/res/res_http_websocket.c, line 195 https://reviewboard.asterisk.org/r/3481/diff/2/?file=58003#file58003line195 I don't see a close_sent change in here. opticron wrote: close_sent is set to 1 on line 206. I meant: I don't see where you've added close_sent to the ast_websocket structure. ^_^ - Joshua --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/#review11778 --- On April 29, 2014, 1:14 p.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/ --- (Updated April 29, 2014, 1:14 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 413072 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] 3481: Websocket: Add locking around session access and modification
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/#review11781 --- Ship it! Ship It! - Joshua Colp On April 29, 2014, 1:48 p.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3481/ --- (Updated April 29, 2014, 1:48 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 413072 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] 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/
---
(Updated April 29, 2014, 2:20 p.m.)
Review request for Asterisk Developers.
Changes
---
Removed unnecessary import of SIPpTestCase from .py files.
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 (updated)
-
/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
Re: [asterisk-dev] [Code Review] 3472: res_pjsip_sdp_rtp: Fix issue with unholding when it shouldn't.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3472/#review11782 --- Ship it! /branches/12/res/res_pjsip_sdp_rtp.c https://reviewboard.asterisk.org/r/3472/#comment21588 I guess people don't use SRTP+video/text that often... - opticron On April 23, 2014, 6:06 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3472/ --- (Updated April 23, 2014, 6:06 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23558 https://issues.asterisk.org/jira/browse/ASTERISK-23558 Repository: Asterisk Description --- The code for queueing hold and unhold currently favors unholding over holding. This means that if an SDP is received with host information but with a stream state of sendonly the code will incorrectly stop musiconhold if it has been started. The attached change fixes this by favoring hold instead of unhold. If an SDP is received with 0.0.0.0 OR sendonly and hold has not been started then it is started. If it has already been started no change occurs. Otherwise if musiconhold has been started it is stopped. Diffs - /branches/12/res/res_pjsip_sdp_rtp.c 412900 Diff: https://reviewboard.asterisk.org/r/3472/diff/ Testing --- Ran test before fixing and confirmed broken. Ran test after fixing and confirmed fixed. 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] 3472: res_pjsip_sdp_rtp: Fix issue with unholding when it shouldn't.
On April 29, 2014, 2:25 p.m., opticron wrote: /branches/12/res/res_pjsip_sdp_rtp.c, lines 1080-1081 https://reviewboard.asterisk.org/r/3472/diff/1/?file=57771#file57771line1080 I guess people don't use SRTP+video/text that often... activate isn't really used by res_rtp_asterisk, except for DTLS-SRTP these days - Joshua --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3472/#review11782 --- On April 23, 2014, 11:06 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3472/ --- (Updated April 23, 2014, 11:06 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23558 https://issues.asterisk.org/jira/browse/ASTERISK-23558 Repository: Asterisk Description --- The code for queueing hold and unhold currently favors unholding over holding. This means that if an SDP is received with host information but with a stream state of sendonly the code will incorrectly stop musiconhold if it has been started. The attached change fixes this by favoring hold instead of unhold. If an SDP is received with 0.0.0.0 OR sendonly and hold has not been started then it is started. If it has already been started no change occurs. Otherwise if musiconhold has been started it is stopped. Diffs - /branches/12/res/res_pjsip_sdp_rtp.c 412900 Diff: https://reviewboard.asterisk.org/r/3472/diff/ Testing --- Ran test before fixing and confirmed broken. Ran test after fixing and confirmed fixed. 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] 3473: res_pjsip_sdp_rtp: Add tests for receiving same SDP when call is already held.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3473/#review11784 --- /asterisk/trunk/tests/channels/pjsip/hold/sipp/phone_B_duplicate_hold.xml https://reviewboard.asterisk.org/r/3473/#comment21592 This should wait for the 200 OK response to the BYE. /asterisk/trunk/tests/channels/pjsip/hold/sipp/phone_B_hold_update.xml https://reviewboard.asterisk.org/r/3473/#comment21590 UPDATEs don't need ACKs. /asterisk/trunk/tests/channels/pjsip/hold/sipp/phone_B_hold_update.xml https://reviewboard.asterisk.org/r/3473/#comment21591 This should wait for the 200 OK response to the BYE. - opticron On April 23, 2014, 6:06 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3473/ --- (Updated April 23, 2014, 6:06 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23558 https://issues.asterisk.org/jira/browse/ASTERISK-23558 Repository: testsuite Description --- This adds two additional scenario files to the PJSIP hold tests which send another INVITE and an UPDATE containing the same SDP that originally put the call on hold. Diffs - /asterisk/trunk/tests/channels/pjsip/hold/sipp/phone_B_hold_update.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/hold/sipp/phone_B_duplicate_hold.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/hold/run-test 4983 Diff: https://reviewboard.asterisk.org/r/3473/diff/ Testing --- Ran and confirmed happy (after fixes were applied). 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
[asterisk-dev] [Code Review] 3491: res_pjsip: Allow cipher to be specified by name
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3491/ --- Review request for Asterisk Developers. Bugs: ASTERISK-23498 https://issues.asterisk.org/jira/browse/ASTERISK-23498 Repository: Asterisk Description --- The cipher option in res_pjsip currently requires that the cipher be specified using the OpenSSL identifier instead of the name. This change makes it so that the name is turned into the respective identifier, allowing the cipher option to accept the name instead! Diffs - /branches/12/res/res_pjsip/config_transport.c 413101 Diff: https://reviewboard.asterisk.org/r/3491/diff/ Testing --- Before patch: Configured cipher using name, received Unsupported log message. After patch: Configured cipher using name, received no log message. 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] 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 29, 2014, 10:47 a.m.) Review request for Asterisk Developers, Matt Jordan and Mark Michelson. Changes --- Missed a couple calls to ast_parking_blind_transfer_park in the last review. This should be all of them. 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 /branches/12/channels/sig_analog.c 413071 /branches/12/channels/chan_mgcp.c 413071 /branches/12/channels/chan_dahdi.c 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
[asterisk-dev] [Code Review] 3494: ARI: Add the ability to raise an arbitrary User Event from the Applications resource
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3494/
---
Review request for Asterisk Developers.
Bugs: ASTERISK-22697
https://issues.asterisk.org/jira/browse/ASTERISK-22697
Repository: Asterisk
Description
---
This changes the implementation of UserEvent stasis messaging and adds
additional features:
1) Existing channel_user_event stasis messaging replaced with new
multi_object_blob in stasis_user.c
2) Multi object blob provides ability to signal blob + any number of channel,
bridge, or endpoint snapshots
3) Changed existing Userevent() app to use new multi object blob - but still
publishes to channel
4) Added ARI implementation of userevent as
/ari/applications/{applicationName}/user/{eventName}
5) ARI generated userevent messages are published to application, and also to
AMI if channel present
Diffs
-
/branches/12/rest-api/api-docs/events.json 413115
/branches/12/rest-api/api-docs/applications.json 413115
/branches/12/res/stasis/app.c 413115
/branches/12/res/res_stasis.c 413115
/branches/12/res/res_ari_applications.c 413115
/branches/12/res/ari/resource_applications.c 413115
/branches/12/res/ari/resource_applications.h 413115
/branches/12/res/ari/ari_model_validators.c 413115
/branches/12/res/ari/ari_model_validators.h 413115
/branches/12/main/stasis_user.c PRE-CREATION
/branches/12/main/stasis_channels.c 413115
/branches/12/main/manager_channels.c 413115
/branches/12/main/asterisk.c 413115
/branches/12/include/asterisk/stasis_user.h PRE-CREATION
/branches/12/include/asterisk/stasis_channels.h 413115
/branches/12/include/asterisk/stasis_app.h 413115
/branches/12/apps/app_userevent.c 413115
Diff: https://reviewboard.asterisk.org/r/3494/diff/
Testing
---
Tested with valgrind to insure no invalid references. Some leaks found which
have been attributed to other code to be fixed separately.
Thanks,
Scott Griepentrog
--
_
-- 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] 3495: res_stasis: Add missing PROGRESS indications to functions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3495/ --- Review request for Asterisk Developers. Bugs: ASTERISK-23560 https://issues.asterisk.org/jira/browse/ASTERISK-23560 Repository: Asterisk Description --- Some media related functions fail to indicate progress if the channel is unanswered. This can cause the media to get ignored by the other side. This change adds the the indications. Diffs - /branches/12/res/stasis/control.c 413101 Diff: https://reviewboard.asterisk.org/r/3495/diff/ Testing --- Invoked the different actions and confirmed progress was indicated if unanswered. 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
[asterisk-dev] [Code Review] 3496: testsuite: add valgrind support
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3496/ --- Review request for Asterisk Developers. Repository: testsuite Description --- This patch adds support for running Asterisk under Valgrind (said Val-Grinned) to check for memory allocation and reference problems. To use, add -V to ./runtests.py and get a cup of coffee. Any errors will be displayed in a stack trace format. Tests can also activate valgrind in the yaml configuration. By default, only confirmed leaks will be shown - thoses where all copies of the pointer to the allocation have been released. Additional leak checking can be enabled. Diffs - /asterisk/trunk/tests/rest_api/tests.yaml 5006 /asterisk/trunk/runtests.py 5006 /asterisk/trunk/logger.conf 5006 /asterisk/trunk/lib/python/asterisk/valgrind.py PRE-CREATION /asterisk/trunk/lib/python/asterisk/test_config.py 5006 /asterisk/trunk/lib/python/asterisk/test_case.py 5006 /asterisk/trunk/lib/python/asterisk/asterisk.py 5006 /asterisk/trunk/configs/valgrind.supp PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3496/diff/ Testing --- Used to locate reference problems on Userevent issue, and incorporated several improvements over the prior attempt. Thanks, Scott Griepentrog -- _ -- 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] 3027: Valgrind support in TestSuite
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3027/ --- (Updated April 29, 2014, 1:28 p.m.) Status -- This change has been discarded. Review request for Asterisk Developers. Repository: testsuite Description --- This patch adds support for running Asterisk under Valgrind (say: Val-Grinned) to check for all sorts of nasty runtime bugs. This started off with a post to asterisk-dev list by nitesh.ban...@gmail.com, and he wrote and contributed the initial version. So if you find this useful, be sure to thank him. Then I made extensive changes and additions, so if the code stinks, blame me. The following has been done: - Check runtests.py arguments for --valgrind and --valgrind-gensupp flags, pass via environ to TestCase.py - Note previously existing instances of ast# logs to insure we only process new log/xml files - Increase reactor timeout by x5 when valgrind enabled - Patch to reactor_stop() to insure it does even when exceptions occur in deferred stack - Add valgrind with correct arguments into executable path - After run, check valgrind.xml for errors, parse and condense them into something more managable - If -gensup mode enabled, write suppressions to logs/(test)/ast#/valgrind.supp that can be added (manually) - A default valgrind.supp suppressions file is in configs/ to prevent complaints about known unfixables Notes: - valgrind can be triggered by argument to runtests.py, export VALGRIND=true, or in test-config.yaml - configs/valgrind.supp will be used if found, but tests/(test)/configs/valgrind.supp will take precedence - valgrind-gensupp mode will create example suppressions file, during which no suppressions occur Diffs - /asterisk/trunk/runtests.py 4350 /asterisk/trunk/lib/python/asterisk/asterisk.py 4350 /asterisk/trunk/lib/python/asterisk/Valgrind.py PRE-CREATION /asterisk/trunk/lib/python/asterisk/TestConfig.py 4350 /asterisk/trunk/lib/python/asterisk/TestCase.py 4350 /asterisk/trunk/configs/valgrind.supp PRE-CREATION /asterisk/trunk/README.txt 4350 Diff: https://reviewboard.asterisk.org/r/3027/diff/ Testing --- Tested on 64bit and 32bit CentOS, including low cpu power conditions. Some sporadic timing issues affecting AMI/twisted operation have been seen and will be corrected. Thanks, Scott Griepentrog -- _ -- 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] 3495: res_stasis: Add missing PROGRESS indications to functions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3495/#review11785 --- Ship it! Ship It! - Matt Jordan On April 29, 2014, 11:51 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3495/ --- (Updated April 29, 2014, 11:51 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23560 https://issues.asterisk.org/jira/browse/ASTERISK-23560 Repository: Asterisk Description --- Some media related functions fail to indicate progress if the channel is unanswered. This can cause the media to get ignored by the other side. This change adds the the indications. Diffs - /branches/12/res/stasis/control.c 413101 Diff: https://reviewboard.asterisk.org/r/3495/diff/ Testing --- Invoked the different actions and confirmed progress was indicated if unanswered. 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] 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/#review11786
---
Ship it!
Ship It!
- Matt Jordan
On April 29, 2014, 9:20 a.m., Mark Michelson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3490/
---
(Updated April 29, 2014, 9:20 a.m.)
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-dev] [Code Review] 3501: testsuite: add tests for ari userevents
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3501/ --- Review request for Asterisk Developers. Bugs: ASTERISK-22697 https://issues.asterisk.org/jira/browse/ASTERISK-22697 Repository: testsuite Description --- Tests added: 1) userevents/channel - check that the dialplan app Userevent() generated event produces correct ARI/AMI events 2) userevents/multi - check that various forms of the ARI userevent generate correct ARI AMI events 3) userevents/invalid - check that correct result code is returned for invalid input cases Changes to ari.py made to add expected: ### return code checking for HTTP requests. Diffs - /asterisk/trunk/tests/rest_api/applications/userevents/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/multi/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/multi/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/multi/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/invalid/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/invalid/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/channel/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/userevents/channel/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/tests.yaml 5006 /asterisk/trunk/lib/python/asterisk/ari.py 5006 Diff: https://reviewboard.asterisk.org/r/3501/diff/ Testing --- Tests pass with userevent code. Also tested with r3496 valgrind support to insure no invalid references. Thanks, Scott Griepentrog -- _ -- 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] 3491: res_pjsip: Allow cipher to be specified by name
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3491/#review11787 --- Ship it! Ship It! - Sean Bright On April 29, 2014, 3:21 p.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3491/ --- (Updated April 29, 2014, 3:21 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23498 https://issues.asterisk.org/jira/browse/ASTERISK-23498 Repository: Asterisk Description --- The cipher option in res_pjsip currently requires that the cipher be specified using the OpenSSL identifier instead of the name. This change makes it so that the name is turned into the respective identifier, allowing the cipher option to accept the name instead! Diffs - /branches/12/res/res_pjsip/config_transport.c 413101 Diff: https://reviewboard.asterisk.org/r/3491/diff/ Testing --- Before patch: Configured cipher using name, received Unsupported log message. After patch: Configured cipher using name, received no log message. 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
[asterisk-dev] [Code Review] 3505: app_chanspy: Fix a bug where barge mode only works on the first connection when multiple sessions are spied on for a channel
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3505/ --- Review request for Asterisk Developers. Bugs: ASTERISK-23381 https://issues.asterisk.org/jira/browse/ASTERISK-23381 Repository: Asterisk Description --- This is a cleanup of the patches posted by Robert Moss for ASTERISK-23381 - A stalled review of the patch exists here: https://reviewboard.asterisk.org/r/3331/diff/1/#index_header This version is made to apply to Asterisk 11 since the bug was first reported there. Diffs - /branches/11/apps/app_chanspy.c 413071 Diff: https://reviewboard.asterisk.org/r/3505/diff/ Testing --- 1. SIP/A calls a spy application which spies on SIP/B with the DTMF option (4 for spy mode, 5 for whisper mode, 6 for barge) 2. SIP/B calls SIP/C 3. Check to see if audio is flowing from A to B and from A to C... should start as neither. (A always hears both of the others though) * press DTMF 5 - now audio should flow from A to B, but from not A to C * press DTMF 6 - now audio should flow from A to B and A to C 4. Hang up SIP/B 5. Have SIP/B call SIP/C again 6. The spy should reconnect automatically and be in barge mode - audio should flow from A to B and A to C * press DTMF 5 - audio should flow from A to B, but not from A to C * press DTMF 4 - audio should not flow from A to either phone Prior to patch: Audio from A to C could not be heard in the first check After the patch: Audio from A to C can be heard in the first check All other checks work as expected in both situations. 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
[asterisk-dev] [Code Review] 3506: format improvements: Port bridge_native_rtp over to new format capability API
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3506/ --- Review request for Asterisk Developers, Joshua Colp and Kevin Harwell. Repository: Asterisk Description --- This patch updates bridge_native_rtp to use the new media format capability API... And that's about it. Diffs - /team/group/media_formats/bridges/bridge_native_rtp.c 413086 Diff: https://reviewboard.asterisk.org/r/3506/diff/ Testing --- 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
Re: [asterisk-dev] A thread for format work
bridge_native_rtp up for review. One down, three hundred to go... But onward anyway. Next on the list: format attributes! The new specification calls for setting attributes using ast_format_set_attr, which takes in a key/value pair along with the format to set the attribute on. While this seems like the appropriate place to store the attribute (since the attribute describes the format), there's some problems with setting the attribute after format creation. Namely: (1) A format object is immutable by convention. However, setting an attribute on a format is a mutable operation, which means we either (a) should set all attributes on format creation or (b) setting an attribute actually returns a copy of the format. Both of these approaches have drawbacks. (2) Setting an attribute technically gets mapped back to a format attribute interface. This interface shouldn't require massive changes, but does need to be exposed through the format API as it generates the SDP attributes. How we expose that may need some tweaking, as ideally something using the format API won't care too much how it gets the SDP - just that it gets it. :: Setting Attributes :: The biggest sticky point is clearly #1. I don't think we should lose the immutability convention - that feels bad, since there's a lot of benefit to treating a format as a read-only object (no locking!) - and a format shouldn't change very often. In order to maintain mutability, I'd remove the public format attribute setting function and instead do the following: (1) We set attributes only as the result of parsing an SDP. Currently, this is the only time we set attributes. ast_format_sdp_parse would be modified to return an ast_format. Calling that function should result in either NULL (failure) or a new ast_format, which should replace the format passed to the function (which would be the burden of the channel driver). Most of the work of duplicating the existing format and safely putting formats onto it could happen within format.c. In that case, there isn't much need for an individual 'add this format' function. (2) Since the only time we add attributes is during SDP generation, there isn't any need for a public API that sets formats. The variable parameters that can be passed to ast_format_set are - from what I can tell - never passed. (3) Producing the attributes is really just a matter of generating the SDP. This should be a public function in format.h that maps down to the attribute interface. :: Getting Attributes :: Since the format is read-only, it's safe to get the format attributes from a format object. There is one place where this is done using ast_format_isset. ast_format_get_value is never used. As the object is immutable, a public accessor for an attribute key could be used that returns a const char *, which would fulfil both functions. Thoughts? Flames? -- 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
