Re: [asterisk-dev] Asterisk 16 Parking Lot Full behavior.

[Jonathan Rose]

On Fri, Dec 21, 2018 at 12:56 PM Steve Sether 
wrote:

> Thanks for suggesting TryExec.  It works perfectly as a workaround for what I 
> want to do, and I can play an error message when the park fails.
>
> Should I open up a bug report in Jira for this?  I assume it's open to the 
> public.
>
> On Thu, Dec 20, 2018 at 10:57 AM Jonathan Rose  motorolasolutions.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev=DwMCaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=I9plltkLC7vMkfdN5HENsgzacwOlcoNiqZ32EUHk4SU=RM7D1ybRfbtE8X5nnw3eLJtDsWQHbz8CGfqGGnKfh0A=>>
> wrote:
> > Since you know it's returning a non-zero value which is causing it to
> > hangup the call, you can work around this by putting your ParkAndAnnounce
> > as the arguments to a TryExec application. This does seem like a bug
> > though. It shouldn't be exiting non-zero, it should be exiting with zero
> > and setting an error value.
>
> --
> _
> -- Bandwidth and Colocation Provided by
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=I9plltkLC7vMkfdN5HENsgzacwOlcoNiqZ32EUHk4SU=JRifGwkazC8M-p_LPu_J9AIoioNlOe4f4cf1ckJl3tg=
> --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=I9plltkLC7vMkfdN5HENsgzacwOlcoNiqZ32EUHk4SU=RM7D1ybRfbtE8X5nnw3eLJtDsWQHbz8CGfqGGnKfh0A=


Yeah, I'd still say that counts as a bug. The fact that there is an easy
enough work-around in your case (plus it's ParkAndAnnounce) might slow
resolution down a bit though.

Good luck.
-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Asterisk 16 Parking Lot Full behavior.

[Jonathan Rose]

Since you know it's returning a non-zero value which is causing it to
hangup the call, you can work around this by putting your ParkAndAnnounce
as the arguments to a TryExec application. This does seem like a bug
though. It shouldn't be exiting non-zero, it should be exiting with zero
and setting an error value.

On Thu, Dec 20, 2018 at 10:24 AM Steve Sether 
wrote:

> I've been focusing on a few other things lately, so it's taken me a bit to 
> circle back to this.
>
> The call doesn't appear to move to the next line in the dialplan when the lot 
> is full.
>
> The console output looks like this:
>
> -- Executing [blind@parkCall:3] NoOp("SIP/usitest--0024", 
> ""Before blind parkAndAnnounce"") in new stack
> -- Executing [blind@parkCall:4] 
> ParkAndAnnounce("SIP/usitest--0024", 
> "usitest-main,c(callParking_timeout,s,1)t(600),silence/1:PARKED,Local/usitest-64167f3a547e@parkCall_do_park")
>  in new stack
> [2018-12-20 10:02:22] NOTICE[8035][C-0016]: parking/parking_bridge.c:150 
> generate_parked_user: Failed to get parking space in lot 'usitest-main'. All 
> full.
> == Spawn extension (parkCall, blind, 4) exited non-zero on 
> 'SIP/usitest--0024'
>
>
>
> The relevant part of the dialplan looks like this:
>
>  same => n,NoOp("Before blind parkAndAnnounce")
>  same => 
> n,ParkAndAnnounce(${DYNAMICPARKINGNAME},c(callParking_timeout,s,1)t(${HASH(lot_info,park_time)}),silence/1:PARKED,Local/${DIALEDPEERNUMBER}@parkCall_do_park)
>  same => n,NoOp("After blind parkAndAnnounce")
>
> I can provide any more information anyone requests.
>
> On Wed, Nov 28, 2018 at 13:05 PM Jonathan Rose 
>  >
> wrote:
>
> > That's a bit of a flawed approach. The highest parking space can be
> > occupied while other spots are open. Parked calls don't get shuffled to
> > lower spots as lower numbered parking spots are freed up. Plus there are
> > multiple modes for selecting the parking space for a call. That would be a
> > safer method to use for findslot=first since you'd only hit false negatives
> > if the parking lot was filling up for at least a little while, but if
> > findslot=next then you could any number of calls in the parking lot when
> > that space has a user in it.
>
> > I checked through the park_and_announce application for differences in how
> > it would handle a transfer and didn't really see anything that should cause
> > these kinds of differences. If parking fails it looks like it'll move on in
> > the dialplan in the same fashion as the regular park application. So I
> > don't really think that's the culprit here.
>
> > Consider running us through an example of it happening with verbosity set
> > to 3 so that we can get running dialplan output
>
> --
> _
> -- Bandwidth and Colocation Provided by
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=gQ9QRcKPRY19PWapuCTKjacOL6Sat8UCIVj8G4ZSMoU=n_sSshKmKcRUA672c_2jR_PhPN41s2AzpHvYT7ry8qQ=
> --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=gQ9QRcKPRY19PWapuCTKjacOL6Sat8UCIVj8G4ZSMoU=tLfx3WibHLD9ypbxNpYHcbjIQM_IENrzkBIFmrGDkRI=



-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Asterisk 16 Parking Lot Full behavior.

[Jonathan Rose]

That's a bit of a flawed approach. The highest parking space can be
occupied while other spots are open. Parked calls don't get shuffled to
lower spots as lower numbered parking spots are freed up. Plus there are
multiple modes for selecting the parking space for a call. That would be a
safer method to use for findslot=first since you'd only hit false negatives
if the parking lot was filling up for at least a little while, but if
findslot=next then you could any number of calls in the parking lot when
that space has a user in it.

I checked through the park_and_announce application for differences in how
it would handle a transfer and didn't really see anything that should cause
these kinds of differences. If parking fails it looks like it'll move on in
the dialplan in the same fashion as the regular park application. So I
don't really think that's the culprit here.

Consider running us through an example of it happening with verbosity set
to 3 so that we can get running dialplan output.

On Wed, Nov 28, 2018 at 12:14 PM John Kiniston 
wrote:

> If you are using parking hints you can query the state of the hint and see
> if the highest numbered spot is available.
>
> ExecIf($["${EXTENSION_STATE(709@parkedcalls)}" =
> "INUSE]?Playback(lot-full))
>
>
> On Wed, Nov 28, 2018 at 10:19 AM Steve Sether 
> wrote:
>
>> >*ParkAndAnnounce
>> *
>> > I actually missed this detail from the original email. Yeah,
>> > ParkAndAnnounce might also behave a lot differently since it's going to
>> > involve the origination of channels. Honestly instead of relying on that
>> > you could simply have some script listen to manager for ParkedCall events
>> > and have that make the announcements for you. Might be better than relying
>> > on a separate and generally less battle tested approach to parking.
>>
>> Hi Jonathan,
>>
>> We're a PBX service provider that's multi-homed, so on Asterisk 11 we 
>> already have a custom solution that does mapping between virtual parking 
>> lots and the real parking lot.  It resembles a virtual memory manager in 
>> many ways. With the new parking lot in Asterisk 13+ supporting templates and 
>> creating a parking lot on-the-fly, I wanted to try to eliminate this 
>> complexity since it would reduce our complexity quite a bit.  So I suppose 
>> we could go back to that, but I'd rather not if possible.
>>
>> For similar reasons, we can't stop supporting the Park feature of the 
>> Polycomm phones either since our customers rely on it.
>>
>> It doesn't sound like I'm doing anything wrong, or there's any easy way 
>> around this other than scripting a solution to just see if the lot is full 
>> before performing a park.
>>
>> Is there anyone from Digium that can respond to this?  Dropping the call 
>> just doesn't seem like the "right thing" for ParkAndAnnounce to do.  Can 
>> this be fixed in some way?  I could see simply just playing a message to the 
>> parkee when the call is full, and using whatever the timeout behavior is set 
>> to.  Alternatively if Asterisk simply returned the call to timeout behavior, 
>> and possibly set a channel variable like to indicate the lot is full, we 
>> could then play the message or do whatever was appropriate.
>>
>> Even adding a dialplan command to query the number of free spaces in a lot 
>> would be helpful (though still suffer from race conditions mentioned above).
>>
>> I don't think we'd want to try to fix this ourselves with a patch.  We're 
>> not really C programmers, and haven't any aspirations to go down that road.
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com
>> 
>> --
>>
>> Astricon is coming up October 9-11!  Signup is available at:
>> https://www.asterisk.org/community/astricon-user-conference
>> 
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>> 
>
>
>
> --
> A human being should be able to change a diaper, plan an invasion, butcher
> a hog, conn a ship, design a building, write a sonnet, balance accounts,
> build a wall, set a 

Re: [asterisk-dev] Asterisk 16 Parking Lot Full behavior.

[Jonathan Rose]

>ParkAndAnnounce

I actually missed this detail from the original email. Yeah,
ParkAndAnnounce might also behave a lot differently since it's going to
involve the origination of channels. Honestly instead of relying on that
you could simply have some script listen to manager for ParkedCall events
and have that make the announcements for you. Might be better than relying
on a separate and generally less battle tested approach to parking.

On Mon, Nov 26, 2018 at 4:32 PM Steve Sether  wrote:

> I'm testing the behavior of when the parking lot is full.  I came across
> this post from Asterisk 12 beta, 5 years ago that describes the behavior
> I'm seeing.
>
> I call ParkAndAnnounce, and when the lot is full  Asterisk drops the call,
> and sends a BYE to the caller.  This just doesn't work for us.
>
> Is there any way to get around this problem?  Ideally what I'd like to
> happen is to retain the call, and defer to a context to deal with that
> situation.  Alternatively, is there a decent way to determine if a lot is
> full?  This isn't an ideal case, since you'd then have to deal with race
> conditions, but it's better than simply dropping the call when the lot is
> full.
>
>
> The original discussion is here:
>
> http://lists.digium.com/pipermail/asterisk-dev/2013-November/063565.html
> 
>
>
> For context, this is the message:
>
>
> >  >* Out of morbid curiosity, could you test the same type of transfer
> *>* against Asterisk 12's parking system?
> *>  >* Also, is this a blind or attended transfer? As in, does the person
> *>* transferring the call hear the parking failed message, and does that
> *>* person then get hung up on, or is it the transferee the one that
> *>* actually attempted parking and failed?
> *>  >* --
> *>* Jonathan R. Rose
> *>* Digium, Inc. | Software Engineer
> *>* 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> *>* direct +1 256 428 6139
> *>
>
> Jonathan,
>
> I was able to test this in Asterisk 12.0.0-beta1.
>
> Parking works fine, but when parking lot is full, Asterisk sends SIP BYE to 
> both parker and parkee (transferer, transferee) and the call is hung up. 
> Compared to 18.23, Asterisk is left in a stable state though (in 1.8.23, I 
> guess because the parking fails after the channels are masqueraded, Asterisk 
> and phones turn unstable)
>
> Test scenario:
> 123 called 125. 125 tried to park 123. Parking failed (parking lot is full). 
> Asterisk sent both phones SIP BYE, call is hung up.
>
>
> --
> _
> -- Bandwidth and Colocation Provided by
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E=1QHEstuYPqNJZFqPhmLE1y8lB8IHxSTQkopS5hIcp5s=
> --
>
> Astricon is coming up October 9-11!  Signup is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.asterisk.org_community_astricon-2Duser-2Dconference=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E=s12RV_nKi-FmKUEM2cwZ4eVwOau8LKRRW3w-yQmxNy8=
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E=_zvbJSEyBW5-WqKuWULB7AbcLeZjrTzhGs6H62UEOE0=



-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Astricon is coming up October 9-11!  Signup is available at: 
https://www.asterisk.org/community/astricon-user-conference

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 16 Parking Lot Full behavior.

[Jonathan Rose]

This might work better in general if you use DTMF feature transfers to park
instead of trying to use an on-phone transfer button to send the call to a
park extension. Asterisk has internal logic to check an extension that you
send a parked call to and will rely on res_parking functionality to
actually perform the park and terminate the call if it's successful.
Different SIP devices handle transfers in different ways and it can it can
be hard to know how any of them will behave with certainty if you are
relying on their features for doing your parking.

That said, I tried this using some Polycoms a few minutes ago to confirm
how it behaves when using a typical SIP refer transfer and for me at least
the call remained live after performing the transfer. The Polycom itself
did have the original call in a held state, but that's a consequence of how
the Polycom handles the call while performing a blind transfer.  If the
parked calls fails, Asterisk should respond to the invite used for the
transfer with a SIP BYE prior to sending a 200 OK unless you have something
in your dialplan set up to answer the call ahead of that point. If a
Polycom receives a BYE before connecting while attempting a blind transfer,
it shouldn't disconnect from the original call. But I'm not sure what is in
your configuration or the exact method you are using to transfer so it's
hard to really nail anything down.

It's not really the kind of work I'm doing these days, but I'll provide
advice if I can. Best of luck to you.

On Mon, Nov 26, 2018 at 4:32 PM Steve Sether  wrote:

> I'm testing the behavior of when the parking lot is full.  I came across
> this post from Asterisk 12 beta, 5 years ago that describes the behavior
> I'm seeing.
>
> I call ParkAndAnnounce, and when the lot is full  Asterisk drops the call,
> and sends a BYE to the caller.  This just doesn't work for us.
>
> Is there any way to get around this problem?  Ideally what I'd like to
> happen is to retain the call, and defer to a context to deal with that
> situation.  Alternatively, is there a decent way to determine if a lot is
> full?  This isn't an ideal case, since you'd then have to deal with race
> conditions, but it's better than simply dropping the call when the lot is
> full.
>
>
> The original discussion is here:
>
> http://lists.digium.com/pipermail/asterisk-dev/2013-November/063565.html
> 
>
>
> For context, this is the message:
>
>
> >  >* Out of morbid curiosity, could you test the same type of transfer
> *>* against Asterisk 12's parking system?
> *>  >* Also, is this a blind or attended transfer? As in, does the person
> *>* transferring the call hear the parking failed message, and does that
> *>* person then get hung up on, or is it the transferee the one that
> *>* actually attempted parking and failed?
> *>  >* --
> *>* Jonathan R. Rose
> *>* Digium, Inc. | Software Engineer
> *>* 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> *>* direct +1 256 428 6139
> *>
>
> Jonathan,
>
> I was able to test this in Asterisk 12.0.0-beta1.
>
> Parking works fine, but when parking lot is full, Asterisk sends SIP BYE to 
> both parker and parkee (transferer, transferee) and the call is hung up. 
> Compared to 18.23, Asterisk is left in a stable state though (in 1.8.23, I 
> guess because the parking fails after the channels are masqueraded, Asterisk 
> and phones turn unstable)
>
> Test scenario:
> 123 called 125. 125 tried to park 123. Parking failed (parking lot is full). 
> Asterisk sent both phones SIP BYE, call is hung up.
>
>
> --
> _
> -- Bandwidth and Colocation Provided by
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E=1QHEstuYPqNJZFqPhmLE1y8lB8IHxSTQkopS5hIcp5s=
> --
>
> Astricon is coming up October 9-11!  Signup is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.asterisk.org_community_astricon-2Duser-2Dconference=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E=s12RV_nKi-FmKUEM2cwZ4eVwOau8LKRRW3w-yQmxNy8=
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.digium.com_mailman_listinfo_asterisk-2Ddev=DwIGaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=-uu3x_H4k0MES1wWNCI4ttxRdu3OeJ64Rsl0xxS0R6E=_zvbJSEyBW5-WqKuWULB7AbcLeZjrTzhGs6H62UEOE0=



-- 

*Jonathan R. Rose*Senior Systems 

Re: [asterisk-dev] Channels in a bridge

[Jonathan Rose]

Using ast_channel_get_bridge(struct ast_channel *chan), you can get a
reference for the bridge. The channel needs to be locked before you use
that function and you'll need to cleanup the bridge reference when you are
done with it. From there you can use the bridge reference to get the list
of channels (channel snapshots more specifically) on the bridge fairly
trivially using ast_bridge_peers(struct ast_bridge *bridge). You'll have
channel names that way at least which, if you really need to, can be used
to get the channels themselves using ast_channel_get_by_name.

I'm not sure how much that helps. I'm assuming you are using Asterisk 12+
since the bridging API is only usable in those versions.

On Fri, Jun 2, 2017 at 7:17 AM, Wray Ferrell  wrote:

> Hi,
>
> Is there anyway for a channel to know the other channels in their current
> bridge? The reason I ask is I have a customer application that negotiates a
> port using the SIP SDP for out of call signalling using UDP. For security
> purposes they want to route all traffic through their box which is running
> Asterisk instead of allowing the two phones to set up a direct socket
> between them. In other words both phones will negotiate a port with
> Asterisk and I need to take the incoming message from phone A and send it
> on the Phone B. So I added some fields to the configuration file and now
> Asterisk is listening on the negotiated ports for incoming messages. The
> problem is since the message is out of the call I get just the data and the
> IP address/Port it was sent from. Since I saved the negotiated port in the
> sip_pvt structure, I can iterate over all the active dialogs to get the
> sip_pvt structure for the channel, but I don't know how to reach the other
> channel in the call. It seems to me that writing my own channel tech
> doesn't help because of the lack of a call-id associated with the message
> so I was hoping to piggyback on the existing call by stuffing the data in a
> SIP info messge and calling __sip_xmit with the sip_pvt pointer for the
> other call leg. Or maybe there is a more elegant way to solve this issue?
>
> Thanks, Wray
>
>
> --
> _
> -- 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
>



-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Anyone interested in having file/line number shown in dialplan show output?

[Jonathan Rose]

On Wed, Dec 7, 2016 at 1:42 PM, Corey Farrell  wrote:

> Overall I like it.  I think leaving pbx_ael out of this is best as it
> might not be straight forward.  Anyone who wants pbx_ael to provide
> information about config sources can create a follow-up patch once the
> core functionality is implemented.
>
> Some thoughts:
> * It would be nice if the registrar ("pbx_config:") were omitted when
> config file/line are available.
> * I assume we can strip 'ast_config_AST_CONFIG_DIR' from included
> config filenames?
>
> I suspect both of these things could be done in follow-up patches, I
> just want to consider limited terminal width and try to avoid unneeded
> wrapping.
>

Omitting registrar when config file is available is certainly doable. It
might be worth holding out for additional opinions on that one, though
I can't imagine people actually *needing* to know the registrar when
they have the config file under normal circumstances.

Stripping the config directory shouldn't be too hard. Might just end up
stripping all the path info in general and just leaving the file name...
if people need to know the full path they can simply watch the verbose
output at startup.
-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Anyone interested in having file/line number shown in dialplan show output?

[Jonathan Rose]

I've been working through a lot of complicated dialplan setups lately,
mostly written in AEL. Doing so has left me painfully aware of the fact
that it can sometimes be hard to trace a dialplan through its various
extensions. More so in pbx_ael of course where what you write isn't
necessarily matched in an easy to read way to the extensions you create,
but even in pbx_config it can get slightly tricky to follow when included
files are involved or there is heavy use of 'n' to assign priority.

So far I've written a patch against trunk which adds in the basic
functionality I'm describing and applies it to extensions created by
pbx_config. I'm not sure if I should bother following it through to
completion since the benefits in pbx_config are limited, I'm unsure of how
many people actually use AEL to write their dialplans, and I'm not entirely
sure if I'm sharp enough to figure out how to add it to AEL in a
non-cataclysmic manner anyway. But I figured I'd at least post here to
gauge people's interest.

Linked is a picture showing illustrating the difference in my experimental
patch. It would also be fairly trivial to add a similar file/line number
tag to verbose 3 "channel ran extension" messages with the patch I've
written.

http://imgur.com/LCh61fx

-- 

*Jonathan R. Rose*Senior Systems Engineer

Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Measuring Asterisk performance

[Jonathan Rose]

On Wed, Sep 28, 2016 at 4:30 AM, Nitesh Bansal 
wrote:

> Hello,
>
> I'm trying to understand if I could use a system metric like load average,
> cpu usage... to
> decide if Asterisk is overloaded and if it is overloaded, I would like to
> stop routing the traffic
> to that box.
>
> Is there any recommended system metric which you guys use to measure the
> Asterisk load,
> or may be is there any metric within Asterisk which could indicate that
> system is slowing down?
>
> Thanks,
> Nitesh
>
> --
> _
> -- 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
>

Hey Nitesh, Matt Jordan wrote an interesting post on statsd for the
Asterisk blog a while back. If you've got some kind of multiple cluster
enviornment you could use statsd to compile CPU usage, disk I/O usage,
current number of channels/bridges, and all kinds of other useful
statistics that could help you balance the load.

http://blogs.asterisk.org/2016/02/03/integrating-asterisk-with-statsd/

-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Advice for having a bug fixed

[Jonathan Rose]

On Thu, Jul 21, 2016 at 10:16 AM, Jonathan Rose <
jonathan.r...@motorolasolutions.com> wrote:

>
> On Thu, Jul 21, 2016 at 2:30 AM, Leandro Dardini <ldard...@gmail.com>
> wrote:
>
>> Hello,
>> I am looking for an advice for having a bug fixed. I am talking about
>> ASTERISK-25468
>>
>> https://issues.asterisk.org/jira/browse/ASTERISK-25468
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D25468=CwMFaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=8oweXmTYv6iT31umA06yAyB-fu-jpgwKlSkZFJiouSQ=VltNLrZUyU2uK9cFJIPt-Tt5sBxawYnD9EzcSzH1D0A=>
>>
>> I tried posting a bounty for this issue, but got no feedback.
>>
>> Is chan_sip definitively abandoned and no fixes will be done?
>>
>> Is the bounty too low? Which can be a reasonable price to have it fixed?
>>
>> Is the bug too big to be fixed?
>>
>> Leandro
>>
>> --
>> _
>> -- 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
>>
>
> chan_sip isn't definitively abandoned since Asterisk 11 doesn't have
> chan_pjsip and Asterisk 11 doesn't go
>  security fix only until October. I don't think the problem is with the
> value of the bounty (although obviously
> if someone thinks they might hit the lottery instead of just getting a
> week's pay or so that could make a
> difference)... it's just that the pool of people who are familiar with
> this code is pretty small and are likely
> strapped for bandwidth at the moment.
>
> One thing that would probably get people to jump on the task is if you
> could provide a simple means of
> reproducing the deadlock from relatively clean configuration.
>
> --
>
> *Jonathan R. Rose*Senior Systems Engineer
>
> Emergency CallWorks
> Motorola Solutions
>
> email: jonathan.r...@motorolasolutions.com
>

Oh, and it goes without saying (but I'm going to write it anyway), but an
alternative to relying on randos
is to get a Digium support contract. It's much more reliable than hoping
someone with spare time and a
working knowledge of the Asterisk source feels like they need a little
extra money. But probably also
more expensive.

-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Advice for having a bug fixed

[Jonathan Rose]

On Thu, Jul 21, 2016 at 2:30 AM, Leandro Dardini  wrote:

> Hello,
> I am looking for an advice for having a bug fixed. I am talking about
> ASTERISK-25468
>
> https://issues.asterisk.org/jira/browse/ASTERISK-25468
> 
>
> I tried posting a bounty for this issue, but got no feedback.
>
> Is chan_sip definitively abandoned and no fixes will be done?
>
> Is the bounty too low? Which can be a reasonable price to have it fixed?
>
> Is the bug too big to be fixed?
>
> Leandro
>
> --
> _
> -- 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
>

chan_sip isn't definitively abandoned since Asterisk 11 doesn't have
chan_pjsip and Asterisk 11 doesn't go
 security fix only until October. I don't think the problem is with the
value of the bounty (although obviously
if someone thinks they might hit the lottery instead of just getting a
week's pay or so that could make a
difference)... it's just that the pool of people who are familiar with this
code is pretty small and are likely
strapped for bandwidth at the moment.

One thing that would probably get people to jump on the task is if you
could provide a simple means of
reproducing the deadlock from relatively clean configuration.

-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Development of asterisk 1.4.23 Can we please get some development?

[Jonathan Rose]

On Thu, Jul 14, 2016 at 3:27 PM, Loren Tedford 
wrote:

> First off i want to say thanks for the fast replies and want to say no I
> don't plan on putting out a job offer.. But was just interested in some
> help in general of putting in at least the basics we require into
> asterisk.. You guys have moved so far on and forgotten about us back here
> in the stone age.. Its ok we will keep working on it and hopefully we get
> some where.. It was only just a thought that maybe some of you all would be
> interested in at least helping release a security patch for 1.4.23 on some
> of the known issues of back in that time.. Thanks again..
>


Having been in the midst of a similarly complicated upgrade procedure for a
custom branch of Asterisk for the past few months myself, I get the
frustration... but it's not that you were forgotten. All of the releases
were made available to you and you had the opportunity to address breaking
changes incrementally rather than letting it build into a monster. You all
are the ones who forgot about the software you were using and let it build
up technical debt for ten years.
-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Development of asterisk 1.4.23 Can we please get some development?

[Jonathan Rose]

>
>
> Is it possible that anyone in the development team would help us make our
> version of asterisk better.. Or so I should say the original version of
> asterisk better.
>
>
Not a snowball's chance in hell.

> So.. Is anyone in the active development group interested in helping us
get past 1.4.23 and up to the current versions of asterisk?

There are a number of resources for upgrading between different versions of
Asterisk, but each major revision brings some additional complications to
deal with. It could be worse though, 11 is only 4 major revisions away from
where you are.

If you are looking for someone to do the work, you should probably put out
a job offer.

-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] [BOUNTY] Bug Fixes

[Jonathan Rose]

>
>
> Well, there are a couple of reasons. The first is that I don't really know
> what it's going to take to fix these issues, I just have a decent idea of
> what
> kind of story point estimates we would have given these issues back when I
> was doing this kind of work and I also have a decent idea of the kinds
> of problems that might be contributing to these issues are... I also know
> a good approximation for an average number of story points that Digium's
> developers complete each week which is why I think this is going to be as
> much work as it is. I fully expect this list of tasks to be riddled with
> little
> gotchas and for a lot of them to have a decent amount of startup time just
> in figuring out how to reproduce them. The other reason I haven't fixed
> them is because I don't get payed to work on Asterisk anymore and the
> promise of maybe getting five-hundred dollars for what I predict to be over
> 80 hours worth of work (and would quite likely be a lot more since
> res_pjsip isn't one of my core areas of experience) just isn't worth the
> effort.
> This isn't about the complexities by the way, all the PJSIP components of
> Asterisk are actually rather self-contained.
>
> I mean, feel free to give it a shot, but this bounty is hardly a real
> incentive.
>

Aaaand I just realized the post I was responding to was directed at the guy
offering the bounty. My bad.
-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] [BOUNTY] Bug Fixes

[Jonathan Rose]

On Mon, Jul 11, 2016 at 10:40 AM, Phil Mickelson <p...@cbasoftware.com>
wrote:

> I'm sorry.  And, I know this is going to sound like a flame and I truly
> don't mean it to be (okay, maybe I do) but I'd like to respond to your last
> email.
>
> If you know what it's going to take to fix this and you already know the
> fix why don't you just do it?  If not, perhaps you'd be better off leaving
> it up to the people you want to give it a try?  As we're all aware Asterisk
> is a very complex and interwoven system.  Make a small change and you can
> easily screw up three other things.
>
> Please keep this in mind when you're so flippant about what the effort is
> going to be.
>
> Regards,
> Phil Mickelson
>
>
> On Mon, Jul 11, 2016 at 11:21 AM, Jonathan Rose <
> jonathan.r...@motorolasolutions.com> wrote:
>
>>
>> On Mon, Jul 11, 2016 at 6:37 AM, Ross Beer <ross.b...@outlook.com> wrote:
>>
>>> Hi Sean,
>>>
>>>
>>> $500 in total as they shouldn't need too much work.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Ross
>>>
>>>
>>> --
>>> *From:* asterisk-dev-boun...@lists.digium.com <
>>> asterisk-dev-boun...@lists.digium.com> on behalf of Sean Bright <
>>> sean.bri...@gmail.com>
>>> *Sent:* 11 July 2016 12:25
>>> *To:* Asterisk Developers Mailing List
>>> *Subject:* Re: [asterisk-dev] [BOUNTY] Bug Fixes
>>>
>>> On 7/7/2016 8:22 AM, Ross Beer wrote:
>>>
>>> Currently, there are a few open issues with the Asterisk project which
>>> require urgent fixes:
>>>
>>>
>>> https://issues.asterisk.org/jira/browse/ASTERISK-26145
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D26145=CwMFAw=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=zCl-FHRKIx0gvzfHPekjb0HwFirftHtm0FSReT6N2NM=c_Nu8w-tAcEYocN6fsb1K9bKahSygGjofMzn-a_jqmc=>
>>>
>>> https://issues.asterisk.org/jira/browse/ASTERISK-26174
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D26174=CwMFAw=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=zCl-FHRKIx0gvzfHPekjb0HwFirftHtm0FSReT6N2NM=ToY9Y2oq34iBXDgFQwRMYiDobpKBzWGdN-nptt9PStM=>
>>>
>>> https://issues.asterisk.org/jira/browse/ASTERISK-26166
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D26166=CwMFAw=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=zCl-FHRKIx0gvzfHPekjb0HwFirftHtm0FSReT6N2NM=UJP22dCDyIqbrxDeNCudnDFNJAoen-IYFLm-bt31Kfg=>
>>>
>>> https://issues.asterisk.org/jira/browse/ASTERISK-26164
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D26164=CwMFAw=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=zCl-FHRKIx0gvzfHPekjb0HwFirftHtm0FSReT6N2NM=DMNwG4zPIZHDwysgRJTqdLuobWtv6hb4NU-iF-WKeCg=>
>>>
>>> https://issues.asterisk.org/jira/browse/ASTERISK-26112
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D26112=CwMFAw=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=zCl-FHRKIx0gvzfHPekjb0HwFirftHtm0FSReT6N2NM=usFuFhVdeSkiOzlH0U9fLYsAy8ZybNMcV9DPM9GcWf4=>
>>> https://issues.asterisk.org/jira/browse/ASTERISK-26113
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.asterisk.org_jira_browse_ASTERISK-2D26113=CwMFAw=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=zCl-FHRKIx0gvzfHPekjb0HwFirftHtm0FSReT6N2NM=9YG8ZqzjC00P_-XrgQIWf7xLqSbrQBuKLcxwWFZ6fkk=>
>>>
>>>
>>> I am therefore offering $500 USD for these to be resolved.
>>>
>>>
>>> Is that $500 each or $500 total?
>>>
>>> Kind Regards,
>>> Sean
>>>
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.api-2Ddigital.com=CwMFaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=ZgGb2GW0S0UGbyRNsqbq-NrHAIMbe_bUKXIBO0nIyr8=98wMtAnbtvjHskGHMADF5U_b4hbvuK8vHmMmJlmKphs=>
>>> --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>

Re: [asterisk-dev] [BOUNTY] Bug Fixes

[Jonathan Rose]

On Mon, Jul 11, 2016 at 6:37 AM, Ross Beer  wrote:

> Hi Sean,
>
>
> $500 in total as they shouldn't need too much work.
>
>
> Regards,
>
>
> Ross
>
>
> --
> *From:* asterisk-dev-boun...@lists.digium.com <
> asterisk-dev-boun...@lists.digium.com> on behalf of Sean Bright <
> sean.bri...@gmail.com>
> *Sent:* 11 July 2016 12:25
> *To:* Asterisk Developers Mailing List
> *Subject:* Re: [asterisk-dev] [BOUNTY] Bug Fixes
>
> On 7/7/2016 8:22 AM, Ross Beer wrote:
>
> Currently, there are a few open issues with the Asterisk project which
> require urgent fixes:
>
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26145
> 
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26174
> 
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26166
> 
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26164
> 
>
> https://issues.asterisk.org/jira/browse/ASTERISK-26112
> 
> https://issues.asterisk.org/jira/browse/ASTERISK-26113
> 
>
>
> I am therefore offering $500 USD for these to be resolved.
>
>
> Is that $500 each or $500 total?
>
> Kind Regards,
> Sean
>
>
> --
> _
> -- 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



>they shouldn't need too much work.

I don't think we would have estimated the lot of these to be less than a
couple weeks worth of work back when I was working at Digium.



-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] Asterisk Load Performance

[Jonathan Rose]

On Tue, Jul 5, 2016 at 3:43 PM, Michael Petruzzello <
michael.petruzze...@civi.com> wrote:

> On Wed, Jun 29 at 11:14:04 AM, Richard Mudgett >
> wrote:
> > Each softmix bridge has only one thread performing all of the media
> mixing
> > for the bridge.  To
> > get better mixing performance for such a large conference, you will need
> to
> > create several
> > softmix bridges in a hierarchy with the bridges linked by local channels.
>
> A bridge is only able to handle around 2000-2500 channels, so I created 15
> bridges with 14 channels bridging the bridges together.
>
> When doing this an error I see a lot is WARNING[98920]: channel.c:1101
> __ast_queue_frame: Exceptionally long voice queue length queuing to
> Local/**@default-;2, which then turns into WARNING[47525]:
> pjproject:0 :  sip_transactio .Unable to register INVITE transaction
> (key exists) and ERROR[47525]: res_pjsip.c:2777 ast_sip_create_dialog_uas:
> Could not create dialog with endpoint sippeer. Object already exists
> (PJ_EEXISTS). Finally the following repeats over and over again, [Jun 30
> 12:22:21] ERROR[84189][C-0958]: netsock2.c:305 ast_sockaddr_resolve:
> getaddrinfo("domain.name
> ",
> "(null)", ...): Temporary failure in name resolution
> [Jun 30 12:22:21] WARNING[84189][C-0958]: acl.c:800 resolve_first:
> Unable to lookup 'domain.name
> 
> '.
>
> The last error just keeps on repeating and calls can no longer join (only
> around 3,500 make it on before this starts to occur). Calling in manually I
> receive an "all circuits are busy" message.
>
> I'm going to try halving the number of bridges, but is there anything else
> I can do to improve performance? This seems to be the last hurdle to use
> one server for 10,000 callers.
>

If you don't need all of your participants actually to be speaking at a
time (and I hope not with that kind of volume), you could use holding
bridges for the vast majority of the partipants. Link the bridges using a
local channel with the Hold bridge side being set to use the 'announcer'
bridge role and the hold bridge will effectively just be voiceless
conference participants. If you want, you can listen for DTMF events to
move the participants back and forth between the different bridges.

-- 

*Jonathan R. Rose*Senior Systems Engineer

Emergency CallWorks
Motorola Solutions

email: jonathan.r...@motorolasolutions.com
-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/
---

(Updated April 8, 2015, 1:15 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Committed in revision 434425


Bugs: ASTERISK-24933
https://issues.asterisk.org/jira/browse/ASTERISK-24933


Repository: Asterisk


Description
---

Description:
Two Asterisk boxes each have the other as endpoints with authentication set.
First Asterisk box originates a call to the second using the PJSIP endpoint.
The first Asterisk box uses an extension with sendfax, the second uses
an extension with receivefax.

The session starts fairly normally, but resolution never appears in fax show
session output. After a while (~25 seconds) the call drops and the fax fails.
Error messages shown are as follows:
Sender: The call dropped prematurely
Receiver: Disconnected after permitted retries

Note that when not using authentication, the FAX will complete as expected.
When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
also complete as expected with authentication, but if chan_pjsip is the sender
it will fail regardless of whether the recipient is chan_sip or chan_pjsip.

The problem is caused by duplication of a framehook in res_pjsip_t38 which
occurs on the second invite sent out when responding to the auth challenge.

Fix:
In order to fix this, I added a simple flag to the pjsip session struct that 
would
be raised when the framehook is first attached to prevent duplication. I 
wouldn't
be surprised if there were a better way to do this.


Diffs
-

  /certified/branches/13.1/res/res_pjsip_t38.c 433316 

Diff: https://reviewboard.asterisk.org/r/4577/diff/


Testing
---

I've duplicated and modified the t38 PJSIP fax test in the testsuite to include 
authentication. It fails without the patch and passes with the patch. I also 
tested this locally with my two Asterisk machines in the above scenario. I'll 
be linking the test after putting it on Gerrit.


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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/
---

(Updated April 6, 2015, 1:16 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Reduce paranoia, trust that all is well.


Bugs: ASTERISK-24933
https://issues.asterisk.org/jira/browse/ASTERISK-24933


Repository: Asterisk


Description
---

Description:
Two Asterisk boxes each have the other as endpoints with authentication set.
First Asterisk box originates a call to the second using the PJSIP endpoint.
The first Asterisk box uses an extension with sendfax, the second uses
an extension with receivefax.

The session starts fairly normally, but resolution never appears in fax show
session output. After a while (~25 seconds) the call drops and the fax fails.
Error messages shown are as follows:
Sender: The call dropped prematurely
Receiver: Disconnected after permitted retries

Note that when not using authentication, the FAX will complete as expected.
When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
also complete as expected with authentication, but if chan_pjsip is the sender
it will fail regardless of whether the recipient is chan_sip or chan_pjsip.

The problem is caused by duplication of a framehook in res_pjsip_t38 which
occurs on the second invite sent out when responding to the auth challenge.

Fix:
In order to fix this, I added a simple flag to the pjsip session struct that 
would
be raised when the framehook is first attached to prevent duplication. I 
wouldn't
be surprised if there were a better way to do this.


Diffs (updated)
-

  /certified/branches/13.1/res/res_pjsip_t38.c 433316 

Diff: https://reviewboard.asterisk.org/r/4577/diff/


Testing
---

I've duplicated and modified the t38 PJSIP fax test in the testsuite to include 
authentication. It fails without the patch and passes with the patch. I also 
tested this locally with my two Asterisk machines in the above scenario. I'll 
be linking the test after putting it on Gerrit.


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] Change in testsuite[master]: Testsuite: New test for FAX via PJSIP T38 with authentication

[Jonathan Rose (Code Review)]

Jonathan Rose has uploaded a new patch set (#4).

Change subject: Testsuite: New test for FAX via PJSIP T38 with authentication
..

Testsuite: New test for FAX via PJSIP T38 with authentication

Add a test for PJSIP t38 with authentication based on normal t38 test
The test will start two instances of Asterisk. The first will originate
a PJSIP call with authentication to the second using an extension that
will run sendFax. The second will receive the call and direct it to an
extension that runs receiveFax. As the fax completes, user events are
issued to verify that the FAX completed successfully.

ASTERISK-24933
Reported by: Jonathan Rose
Change-Id: If37cf20857ae3c0b35e0637a0a2cb7e7d6226df6
---
A tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast1/pjsip.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/pjsip.conf
A tests/fax/pjsip/t38_with_auth/run-test
A tests/fax/pjsip/t38_with_auth/send.tiff
A tests/fax/pjsip/t38_with_auth/test-config.yaml
M tests/fax/pjsip/tests.yaml
8 files changed, 188 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/28/28/4
-- 
To view, visit https://gerrit.asterisk.org/28
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If37cf20857ae3c0b35e0637a0a2cb7e7d6226df6
Gerrit-PatchSet: 4
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com

-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

 On April 6, 2015, 8:59 a.m., Joshua Colp wrote:
  /certified/branches/13.1/res/res_pjsip_t38.c, lines 514-524
  https://reviewboard.asterisk.org/r/4577/diff/2/?file=73560#file73560line514
 
  You aren't actually using the framehook id for anything. The sheer 
  presence of the datastore itself is what you care about. As a result you 
  don't need to create space to store the framehook id. You can just create 
  the datastore and attach it.

Yeah, I was fairly sure I didn't actually need the framehook id on the 
datastore... just felt like this was the common construct for this sort of 
thing and was a little cautious about having a datastore with no actual data in 
it. I suppose it's not a big deal though.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/#review15069
---


On April 3, 2015, 12:03 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 3, 2015, 12:03 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

 On April 6, 2015, 11:16 a.m., Joshua Colp wrote:
  /certified/branches/13.1/res/res_pjsip_t38.c, lines 493-498
  https://reviewboard.asterisk.org/r/4577/diff/3/?file=73632#file73632line493
 
  How could this occur?

As far as I know, it should never occur. I'm probably being paranoid.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/#review15075
---


On April 6, 2015, 11:14 a.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 6, 2015, 11:14 a.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/
---

(Updated April 6, 2015, 11:14 a.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Remove framehook ID from datastore.  Now the datastore is just sort of... a 
boolean flag by means of existence I guess.


Bugs: ASTERISK-24933
https://issues.asterisk.org/jira/browse/ASTERISK-24933


Repository: Asterisk


Description
---

Description:
Two Asterisk boxes each have the other as endpoints with authentication set.
First Asterisk box originates a call to the second using the PJSIP endpoint.
The first Asterisk box uses an extension with sendfax, the second uses
an extension with receivefax.

The session starts fairly normally, but resolution never appears in fax show
session output. After a while (~25 seconds) the call drops and the fax fails.
Error messages shown are as follows:
Sender: The call dropped prematurely
Receiver: Disconnected after permitted retries

Note that when not using authentication, the FAX will complete as expected.
When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
also complete as expected with authentication, but if chan_pjsip is the sender
it will fail regardless of whether the recipient is chan_sip or chan_pjsip.

The problem is caused by duplication of a framehook in res_pjsip_t38 which
occurs on the second invite sent out when responding to the auth challenge.

Fix:
In order to fix this, I added a simple flag to the pjsip session struct that 
would
be raised when the framehook is first attached to prevent duplication. I 
wouldn't
be surprised if there were a better way to do this.


Diffs (updated)
-

  /certified/branches/13.1/res/res_pjsip_t38.c 433316 

Diff: https://reviewboard.asterisk.org/r/4577/diff/


Testing
---

I've duplicated and modified the t38 PJSIP fax test in the testsuite to include 
authentication. It fails without the patch and passes with the patch. I also 
tested this locally with my two Asterisk machines in the above scenario. I'll 
be linking the test after putting it on Gerrit.


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] Change in testsuite[master]: Add a test for PJSIP t38 with authentication based on normal...

[Jonathan Rose (Code Review)]

Hello Ashley Sanders,

I'd like you to reexamine a change.  Please visit

https://gerrit.asterisk.org/22

to look at the new patch set (#4).

Change subject: Add a test for PJSIP t38 with authentication based on normal 
t38 test
..

Add a test for PJSIP t38 with authentication based on normal t38 test

Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
---
A tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast1/pjsip.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/pjsip.conf
A tests/fax/pjsip/t38_with_auth/run-test
A tests/fax/pjsip/t38_with_auth/send.tiff
A tests/fax/pjsip/t38_with_auth/test-config.yaml
M tests/fax/pjsip/tests.yaml
8 files changed, 175 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/22/22/4
-- 
To view, visit https://gerrit.asterisk.org/22
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
Gerrit-PatchSet: 4
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com

-- 
_
-- 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] Change in testsuite[master]: Address review feedback

[Jonathan Rose (Code Review)]

Jonathan Rose has uploaded a new change for review.

  https://gerrit.asterisk.org/28

Change subject: Address review feedback
..

Address review feedback

Change-Id: If37cf20857ae3c0b35e0637a0a2cb7e7d6226df6
---
M tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
M tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
M tests/fax/pjsip/t38_with_auth/run-test
M tests/fax/pjsip/t38_with_auth/test-config.yaml
4 files changed, 62 insertions(+), 52 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/28/28/1

diff --git a/tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf 
b/tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
index 55a81b4..83e0d5b 100644
--- a/tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
+++ b/tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
@@ -1,7 +1,7 @@
 [sendfax]
 exten = 1234,1,noop
-exten = 1234,n,SendFax(${ASTDATADIR}/send.tiff)
+ same = n,SendFax(${ASTDATADIR}/send.tiff)
 
 exten = h,1,noop
-exten = h,n,UserEvent(FaxStatus,operation: send,status: 
${FAXOPT(status)},statusstr: ${FAXOPT(statusstr)},error: ${FAXOPT(error)})
+ same = n,UserEvent(FaxStatus,operation: send,status: 
${FAXOPT(status)},statusstr: ${FAXOPT(statusstr)},error: ${FAXOPT(error)})
 
diff --git a/tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf 
b/tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
index 03f2714..8d5dc7f 100644
--- a/tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
+++ b/tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
@@ -1,6 +1,6 @@
 [receivefax]
 exten = 1234,1,noop
-exten = 1234,n,ReceiveFax(${ASTDATADIR}/receive.tiff)
+ same = n,ReceiveFax(${ASTDATADIR}/receive.tiff)
 
 exten = h,1,noop
-exten = h,n,UserEvent(FaxStatus,operation: receive,status: 
${FAXOPT(status)},statusstr: ${FAXOPT(statusstr)},error: ${FAXOPT(error)})
+ same = n,UserEvent(FaxStatus,operation: receive,status: 
${FAXOPT(status)},statusstr: ${FAXOPT(statusstr)},error: ${FAXOPT(error)})
diff --git a/tests/fax/pjsip/t38_with_auth/run-test 
b/tests/fax/pjsip/t38_with_auth/run-test
old mode 100644
new mode 100755
index 8af0d4d..30fc635
--- a/tests/fax/pjsip/t38_with_auth/run-test
+++ b/tests/fax/pjsip/t38_with_auth/run-test
@@ -1,8 +1,9 @@
 #!/usr/bin/env python
 # vim: sw=3 et:
 '''
-Copyright (C) 2011, Digium, Inc.
+Copyright (C) 2015, Digium, Inc.
 Matthew Nicholson mnichol...@digium.com
+Jonathan Rose jr...@digium.com
 
 This program is free software, distributed under the terms of
 the GNU General Public License Version 2.
@@ -11,73 +12,81 @@
 import sys
 import logging
 import os
-import re
 import shutil
 
-from twisted.internet import reactor
-
 sys.path.append(lib/python)
-from asterisk.asterisk import Asterisk
+
+from twisted.internet import reactor
 from asterisk.test_case import TestCase
 
-logger = logging.getLogger(__name__)
+LOGGER = logging.getLogger(__name__)
+
 
 class T38Test(TestCase):
-   event_count = 0
-   success_count = 0
+Test class for performing the test. Manages files, originates FAX call,
+and monitors a user event to verify that the fax completed successfully on
+the sender end of the call.
+
 
-   def __init__(self):
-  TestCase.__init__(self)
-  self.reactor_timeout = 120
-  self.create_asterisk(2)
+def __init__(self):
+Create Asterisk instances and copy our test fax to where the sender
+will send it from.
+
 
-  # copy the tiff file we are going to send to a good known location
-  shutil.copy(%s/send.tiff % 
(os.path.dirname(os.path.realpath(__file__)),), %s%s % (self.ast[0].base, 
self.ast[0].directories['astdatadir']))
+super(T38Test, self).__init__()
+self.reactor_timeout = 120
+self.create_asterisk(2)
 
-   def ami_connect(self, ami):
-  if ami.id == 0:
+# copy the tiff file we are going to send to a good known location
+shutil.copy(%s/send.tiff % (os.path.dirname(
+os.path.realpath(__file__)),), %s%s %
+(self.ast[0].base, self.ast[0].directories['astdatadir']))
 
- ami.registerEvent('UserEvent', self.fax_result)
- df = ami.originate(PJSIP/ast2-t38/sip:1234@127.0.0.2, sendfax, 
1234, 1)
+def ami_connect(self, ami):
+Upon connecting to AMI on the first Asterisk instance, originate
+a call that will send the fax to the second Asterisk instance. Also
+register for UserEvents.
+
 
- def handle_failure(reason):
-logging.error(error sending originate:)
-logging.error(reason.getTraceback())
-self.stop_reactor()
+if ami.id == 0:
+ami.registerEvent('UserEvent', self.fax_result)
+deferred = ami.originate(PJSIP/ast2-t38/sip:1234@127.0.0.2,
+ sendfax, 1234, 1)
+deferred.addErrback

[asterisk-dev] Change in testsuite[master]: Add a test for PJSIP t38 with authentication based on normal...

[Jonathan Rose (Code Review)]

Jonathan Rose has uploaded a new patch set (#2).

Change subject: Add a test for PJSIP t38 with authentication based on normal 
t38 test The test will start two instances of Asterisk. The first will 
originate a PJSIP call with authentication to the second using an extension 
that will run sendFax. The second will receive 
..

Add a test for PJSIP t38 with authentication based on normal t38 test
The test will start two instances of Asterisk. The first will originate
a PJSIP call with authentication to the second using an extension that
will run sendFax. The second will receive the call and direct it to an
extension that runs receiveFax. As the fax completes, user events are
issued to verify that the FAX completed successfully.

ASTERISK-24933
Change-Id: If37cf20857ae3c0b35e0637a0a2cb7e7d6226df6
---
M tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
M tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
M tests/fax/pjsip/t38_with_auth/run-test
M tests/fax/pjsip/t38_with_auth/test-config.yaml
4 files changed, 62 insertions(+), 52 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/28/28/2
-- 
To view, visit https://gerrit.asterisk.org/28
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If37cf20857ae3c0b35e0637a0a2cb7e7d6226df6
Gerrit-PatchSet: 2
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com

-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/#review15046
---



/certified/branches/13.1/res/res_pjsip_t38.c
https://reviewboard.asterisk.org/r/4577/#comment25722

s/for the channel/for the endpoint/


- Jonathan Rose


On April 3, 2015, 12:03 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 3, 2015, 12:03 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 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] Change in testsuite[master]: Add a test for PJSIP t38 with authentication based on normal...

[Jonathan Rose (Code Review)]

Jonathan Rose has abandoned this change.

Change subject: Add a test for PJSIP t38 with authentication based on normal 
t38 test
..


Abandoned

I'm abandoning this one since the patch got mangled. Go over to c/28

-- 
To view, visit https://gerrit.asterisk.org/22
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: abandon
Gerrit-Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
Gerrit-PatchSet: 4
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com

-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/
---

(Updated April 3, 2015, 12:03 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Convert flag to datastore


Bugs: ASTERISK-24933
https://issues.asterisk.org/jira/browse/ASTERISK-24933


Repository: Asterisk


Description
---

Description:
Two Asterisk boxes each have the other as endpoints with authentication set.
First Asterisk box originates a call to the second using the PJSIP endpoint.
The first Asterisk box uses an extension with sendfax, the second uses
an extension with receivefax.

The session starts fairly normally, but resolution never appears in fax show
session output. After a while (~25 seconds) the call drops and the fax fails.
Error messages shown are as follows:
Sender: The call dropped prematurely
Receiver: Disconnected after permitted retries

Note that when not using authentication, the FAX will complete as expected.
When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
also complete as expected with authentication, but if chan_pjsip is the sender
it will fail regardless of whether the recipient is chan_sip or chan_pjsip.

The problem is caused by duplication of a framehook in res_pjsip_t38 which
occurs on the second invite sent out when responding to the auth challenge.

Fix:
In order to fix this, I added a simple flag to the pjsip session struct that 
would
be raised when the framehook is first attached to prevent duplication. I 
wouldn't
be surprised if there were a better way to do this.


Diffs (updated)
-

  /certified/branches/13.1/res/res_pjsip_t38.c 433316 

Diff: https://reviewboard.asterisk.org/r/4577/diff/


Testing
---

I've duplicated and modified the t38 PJSIP fax test in the testsuite to include 
authentication. It fails without the patch and passes with the patch. I also 
tested this locally with my two Asterisk machines in the above scenario. I'll 
be linking the test after putting it on Gerrit.


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] Change in testsuite[master]: Add a test for PJSIP t38 with authentication based on normal...

[Jonathan Rose (Code Review)]

Hello Ashley Sanders,

I'd like you to reexamine a change.  Please visit

https://gerrit.asterisk.org/22

to look at the new patch set (#2).

Change subject: Add a test for PJSIP t38 with authentication based on normal 
t38 test The test will start two instances of Asterisk. The first will 
originate a PJSIP call with authentication to the second using an extension 
that will run sendFax. The second will receive 
..

Add a test for PJSIP t38 with authentication based on normal t38 test
The test will start two instances of Asterisk. The first will originate
a PJSIP call with authentication to the second using an extension that
will run sendFax. The second will receive the call and direct it to an
extension that runs receiveFax. As the fax completes, user events are
issued to verify that the FAX completed successfully. Addresses a bug
detailed in ASTERISK-24933

Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
---
A tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast1/pjsip.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/pjsip.conf
A tests/fax/pjsip/t38_with_auth/run-test
A tests/fax/pjsip/t38_with_auth/test-config.yaml
M tests/fax/pjsip/tests.yaml
7 files changed, 175 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/22/22/2
-- 
To view, visit https://gerrit.asterisk.org/22
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
Gerrit-PatchSet: 2
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com

-- 
_
-- 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] Change in testsuite[master]: Add a test for PJSIP t38 with authentication based on normal...

[Jonathan Rose (Code Review)]

Hello Ashley Sanders,

I'd like you to reexamine a change.  Please visit

https://gerrit.asterisk.org/22

to look at the new patch set (#3).

Change subject: Add a test for PJSIP t38 with authentication based on normal 
t38 test The test will start two instances of Asterisk. The first will 
originate a PJSIP call with authentication to the second using an extension 
that will run sendFax. The second will receive 
..

Add a test for PJSIP t38 with authentication based on normal t38 test
The test will start two instances of Asterisk. The first will originate
a PJSIP call with authentication to the second using an extension that
will run sendFax. The second will receive the call and direct it to an
extension that runs receiveFax. As the fax completes, user events are
issued to verify that the FAX completed successfully.

ASTERISK-24933

Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
---
A tests/fax/pjsip/t38_with_auth/configs/ast1/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast1/pjsip.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/extensions.conf
A tests/fax/pjsip/t38_with_auth/configs/ast2/pjsip.conf
A tests/fax/pjsip/t38_with_auth/run-test
A tests/fax/pjsip/t38_with_auth/test-config.yaml
M tests/fax/pjsip/tests.yaml
7 files changed, 175 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/22/22/3
-- 
To view, visit https://gerrit.asterisk.org/22
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
Gerrit-PatchSet: 3
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com

-- 
_
-- 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] Change in testsuite[master]: Add a test for PJSIP t38 with authentication based on normal...

[Jonathan Rose (Code Review)]

Jonathan Rose has posted comments on this change.

Change subject: Add a test for PJSIP t38 with authentication based on normal 
t38 test
..


Patch Set 1:

(2 comments)

https://gerrit.asterisk.org/#/c/22/1/tests/fax/pjsip/t38_with_auth/run-test
File tests/fax/pjsip/t38_with_auth/run-test:

Line 6: 
 Should you add your name to the authors list?
Now that I actually have changes in the code? Sure.


Line 26:event_count = 0
 If you aren't using this class as a singleton, you don't need to have these
Probably not the best course of action to change anything based on what you see 
in this file.  It was just a direct copy of something slightly modified from 
something that was written in 2011 before we revamped a bunch of the testsuite 
stuff.


-- 
To view, visit https://gerrit.asterisk.org/22
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Id8fd9683dc1b61e7b1afd2b6ede857921beebb88
Gerrit-PatchSet: 1
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Jonathan Rose jr...@digium.com
Gerrit-Reviewer: Matt Jordan mjor...@digium.com
Gerrit-HasComments: Yes

-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

 On April 2, 2015, 6:13 p.m., Kevin Harwell wrote:
  It is probably always the case that framehooks should not be attached 
  twice. If this is true then it might be better to add a check in 
  'ast_framehook_attach' that first makes sure the hook is not already in the 
  list. If so don't add it again.
 
 rmudgett wrote:
 It is specific framehooks that cannot be attached twice.  It is not a 
 general requirement/property of the framehook concept.
 
 Kevin Harwell wrote:
 Just curious, but what's a case where a framehook should be attached 
 twice?
 
 Jonathan Rose wrote:
 You could have multiple mixmonitors attached by separate parts of the 
 dialplan saving to different files as an example.

Well, that might be audiohooks instead of framehooks actually... but it's the 
same concept.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/#review15034
---


On April 2, 2015, 2:08 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 2, 2015, 2:08 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
   /certified/branches/13.1/include/asterisk/res_pjsip_session.h 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

 On April 2, 2015, 6:13 p.m., Kevin Harwell wrote:
  It is probably always the case that framehooks should not be attached 
  twice. If this is true then it might be better to add a check in 
  'ast_framehook_attach' that first makes sure the hook is not already in the 
  list. If so don't add it again.
 
 rmudgett wrote:
 It is specific framehooks that cannot be attached twice.  It is not a 
 general requirement/property of the framehook concept.
 
 Kevin Harwell wrote:
 Just curious, but what's a case where a framehook should be attached 
 twice?

You could have multiple mixmonitors attached by separate parts of the dialplan 
saving to different files as an example.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/#review15034
---


On April 2, 2015, 2:08 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 2, 2015, 2:08 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
   /certified/branches/13.1/include/asterisk/res_pjsip_session.h 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577/
---

Review request for Asterisk Developers and Joshua Colp.


Bugs: ASTERISK-24933
https://issues.asterisk.org/jira/browse/ASTERISK-24933


Repository: Asterisk


Description
---

Description:
Two Asterisk boxes each have the other as endpoints with authentication set.
First Asterisk box originates a call to the second using the PJSIP endpoint.
The first Asterisk box uses an extension with sendfax, the second uses
an extension with receivefax.

The session starts fairly normally, but resolution never appears in fax show
session output. After a while (~25 seconds) the call drops and the fax fails.
Error messages shown are as follows:
Sender: The call dropped prematurely
Receiver: Disconnected after permitted retries

Note that when not using authentication, the FAX will complete as expected.
When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
also complete as expected with authentication, but if chan_pjsip is the sender
it will fail regardless of whether the recipient is chan_sip or chan_pjsip.

The problem is caused by duplication of a framehook in res_pjsip_t38 which
occurs on the second invite sent out when responding to the auth challenge.

Fix:
In order to fix this, I added a simple flag to the pjsip session struct that 
would
be raised when the framehook is first attached to prevent duplication. I 
wouldn't
be surprised if there were a better way to do this.


Diffs
-

  /certified/branches/13.1/res/res_pjsip_t38.c 433316 
  /certified/branches/13.1/include/asterisk/res_pjsip_session.h 433316 

Diff: https://reviewboard.asterisk.org/r/4577/diff/


Testing
---

I've duplicated and modified the t38 PJSIP fax test in the testsuite to include 
authentication. It fails without the patch and passes with the patch. I also 
tested this locally with my two Asterisk machines in the above scenario. I'll 
be linking the test after putting it on Gerrit.


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] 4488: Super Awesome Company: Phase 1 - Patch 2 - Outside Connectivity!

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4488/#review14906
---

Ship it!


Go ahead and ship it after uncommenting that format stuff and I suppose doing a 
quick glance to see if you missed anything else in testing.

- Jonathan Rose


On March 24, 2015, 4:53 p.m., rnewton wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4488/
 ---
 
 (Updated March 24, 2015, 4:53 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Howdy, here is another patch for the Super Awesome Company configuration. We 
 are still in phase 1. The general requirements are posted on the wiki: 
 https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company
 
 The specific requirements this patch meets are below:
 
 pjsip.conf
 
  * SIP ITSP configuration example and have place holders for the required 
 authentication bits.
  ** Assume that Asterisk does not have a public IP address, and sits behind a 
 NAT with its desk phones.
  * Have outbound registration to the SIP trunk, and an endpoint that 
 represents the SIP trunk.
  * Inbound calls received from the SIP trunk should go into their own context.
 
 extensions.conf
 
  * Match the outbound dial request so that it can only dial US area codes.
  ** Don't let people dial 900 numbers, international numbers, or any other 
 numbers that could result in a charge
  * Inbound calls from the SIP trunk should hit a basic Auto Attendant that 
 prompts them for the extension to dial, after greeting them to SAC.
  * If an inbound call matches a DID that maps to a specific extension/device, 
 dial that extension/device directly.
 
 Billing
 
  * Make sure CDRs output all calls that are from/to the SIP trunk. These 
 should be logged to a CSV.
  * For intra-office calls, kill the CDRs.
 
 Additional Requirements Noted:
 
  * For outbound calls, each SAC employee’s 10-digit DID number is provided as 
 their Caller ID.
  * Voicemail may be accessed remotely by employees who dial 256-555-1234. 
 When employees dial voicemail remotely, they must input both their mailbox 
 number and their pin code.
  * 7, 10 and 10+1 digit dialing for local and long distance calls.
  * Internal dialing of otherwise inbound features, 
  ** 1100 to reach the main IVR.
  * The IVR options possible without getting into Phase 2.
 
 
 Diffs
 -
 
   /branches/13/configs/basic-pbx/pjsip.conf 43 
   /branches/13/configs/basic-pbx/modules.conf 43 
   /branches/13/configs/basic-pbx/logger.conf 43 
   /branches/13/configs/basic-pbx/extensions.conf 43 
   /branches/13/configs/basic-pbx/cdr_custom.conf PRE-CREATION 
   /branches/13/configs/basic-pbx/cdr.conf PRE-CREATION 
 
 Diff: https://reviewboard.asterisk.org/r/4488/diff/
 
 
 Testing
 ---
 
 Setup with a Digium Cloud Services trunk and a few internal phones.
 Internal to Internal calls.
 Calls Internal to voicemail and other features.
 External to internal DID calls.
 External to internal feature calls.
 
 Basically tried to call as many ways as I could through all the various 
 features. Everything seemed to work.
 
 
 Thanks,
 
 rnewton
 


-- 
_
-- 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] 4504: SAC: Add conferences for employees / employees+customers

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4504/
---

(Updated March 27, 2015, 5:25 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and rnewton.


Changes
---

Committed in revision 433656


Repository: Asterisk


Description
---

From: https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company

SAC requires two conference rooms, one for use by employees only and one for 
use by employees and customers (outside connectivity still needs to be 
established so that 555-6500 can be added and customers can actually dial into 
said conference)


Diffs
-

  /branches/13/configs/basic-pbx/modules.conf 432996 
  /branches/13/configs/basic-pbx/extensions.conf 432996 
  /branches/13/configs/basic-pbx/confbridge.conf PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4504/diff/


Testing
---

Made sure app_confbridge loaded and internal users were able to dial into the 
conferences.


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] 4503: SAC: Configure customer advocate/sales queues

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4503/
---

(Updated March 27, 2015, 5:35 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 433658


Repository: Asterisk


Description
---

As described on the wiki at: 

 The Sales Queue may be reached externally by dialing 256-555-1200, or 
 internally by dialing 1200.
 The Customer Experience Queue may be reached externally by dialing 
 256-555-1250, or internally by dialing 1250.

 Sales Queue
 Calls to the Sales Queue should ring Terry, Garnet and Franny in ring-all 
 fashion
 If no one answers a call to the Sales Queue after 5 minutes, the caller 
 should be directed
 to the Operator so that the Operator can take a message and have a Sales 
 person contact the
 caller at a later time.

 Customer Advocate Queue
 Calls to the Customer Advocate Queue should ring Maria, Dusty and Tommie in 
 ring-all
 fashion. If no one answers a call to the Customer Advocate queue after 20 
 minutes, the
 caller should be directed to the Operator so that the Operator can take a 
 message and
 have a Customer Advocate contact the caller at a later time.

NOTE: This review is accidentally against trunk, but the patch is perfectly 
portable, so that shouldn't be a problem.

NOTE 2: External extensions for the queues still need to be added since the 
outside connectivity patch hasn't been merged yet
https://reviewboard.asterisk.org/r/4488/diff/#index_header


Diffs
-

  /trunk/configs/basic-pbx/queues.conf PRE-CREATION 
  /trunk/configs/basic-pbx/modules.conf 432443 
  /trunk/configs/basic-pbx/extensions.conf 432443 

Diff: https://reviewboard.asterisk.org/r/4503/diff/


Testing
---

Had some phones register as agents in the queues as well as the operator, made 
sure the queue members were dialed in ring-all fashion and that the timeouts 
occurred and the operator was dialed as expected.


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] 4488: Super Awesome Company: Phase 1 - Patch 2 - Outside Connectivity!

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4488/#review14850
---


- Jonathan Rose


On March 24, 2015, 4:53 p.m., rnewton wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4488/
 ---
 
 (Updated March 24, 2015, 4:53 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Howdy, here is another patch for the Super Awesome Company configuration. We 
 are still in phase 1. The general requirements are posted on the wiki: 
 https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company
 
 The specific requirements this patch meets are below:
 
 pjsip.conf
 
  * SIP ITSP configuration example and have place holders for the required 
 authentication bits.
  ** Assume that Asterisk does not have a public IP address, and sits behind a 
 NAT with its desk phones.
  * Have outbound registration to the SIP trunk, and an endpoint that 
 represents the SIP trunk.
  * Inbound calls received from the SIP trunk should go into their own context.
 
 extensions.conf
 
  * Match the outbound dial request so that it can only dial US area codes.
  ** Don't let people dial 900 numbers, international numbers, or any other 
 numbers that could result in a charge
  * Inbound calls from the SIP trunk should hit a basic Auto Attendant that 
 prompts them for the extension to dial, after greeting them to SAC.
  * If an inbound call matches a DID that maps to a specific extension/device, 
 dial that extension/device directly.
 
 Billing
 
  * Make sure CDRs output all calls that are from/to the SIP trunk. These 
 should be logged to a CSV.
  * For intra-office calls, kill the CDRs.
 
 Additional Requirements Noted:
 
  * For outbound calls, each SAC employee’s 10-digit DID number is provided as 
 their Caller ID.
  * Voicemail may be accessed remotely by employees who dial 256-555-1234. 
 When employees dial voicemail remotely, they must input both their mailbox 
 number and their pin code.
  * 7, 10 and 10+1 digit dialing for local and long distance calls.
  * Internal dialing of otherwise inbound features, 
  ** 1100 to reach the main IVR.
  * The IVR options possible without getting into Phase 2.
 
 
 Diffs
 -
 
   /branches/13/configs/basic-pbx/pjsip.conf 43 
   /branches/13/configs/basic-pbx/modules.conf 43 
   /branches/13/configs/basic-pbx/logger.conf 43 
   /branches/13/configs/basic-pbx/extensions.conf 43 
   /branches/13/configs/basic-pbx/cdr_custom.conf PRE-CREATION 
   /branches/13/configs/basic-pbx/cdr.conf PRE-CREATION 
 
 Diff: https://reviewboard.asterisk.org/r/4488/diff/
 
 
 Testing
 ---
 
 Setup with a Digium Cloud Services trunk and a few internal phones.
 Internal to Internal calls.
 Calls Internal to voicemail and other features.
 External to internal DID calls.
 External to internal feature calls.
 
 Basically tried to call as many ways as I could through all the various 
 features. Everything seemed to work.
 
 
 Thanks,
 
 rnewton
 


-- 
_
-- 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] 4488: Super Awesome Company: Phase 1 - Patch 2 - Outside Connectivity!

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4488/#review14849
---



/branches/13/configs/basic-pbx/pjsip.conf
https://reviewboard.asterisk.org/r/4488/#comment25456

Was this intended to be commented out like this?


- Jonathan Rose


On March 24, 2015, 4:53 p.m., rnewton wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4488/
 ---
 
 (Updated March 24, 2015, 4:53 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Howdy, here is another patch for the Super Awesome Company configuration. We 
 are still in phase 1. The general requirements are posted on the wiki: 
 https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company
 
 The specific requirements this patch meets are below:
 
 pjsip.conf
 
  * SIP ITSP configuration example and have place holders for the required 
 authentication bits.
  ** Assume that Asterisk does not have a public IP address, and sits behind a 
 NAT with its desk phones.
  * Have outbound registration to the SIP trunk, and an endpoint that 
 represents the SIP trunk.
  * Inbound calls received from the SIP trunk should go into their own context.
 
 extensions.conf
 
  * Match the outbound dial request so that it can only dial US area codes.
  ** Don't let people dial 900 numbers, international numbers, or any other 
 numbers that could result in a charge
  * Inbound calls from the SIP trunk should hit a basic Auto Attendant that 
 prompts them for the extension to dial, after greeting them to SAC.
  * If an inbound call matches a DID that maps to a specific extension/device, 
 dial that extension/device directly.
 
 Billing
 
  * Make sure CDRs output all calls that are from/to the SIP trunk. These 
 should be logged to a CSV.
  * For intra-office calls, kill the CDRs.
 
 Additional Requirements Noted:
 
  * For outbound calls, each SAC employee’s 10-digit DID number is provided as 
 their Caller ID.
  * Voicemail may be accessed remotely by employees who dial 256-555-1234. 
 When employees dial voicemail remotely, they must input both their mailbox 
 number and their pin code.
  * 7, 10 and 10+1 digit dialing for local and long distance calls.
  * Internal dialing of otherwise inbound features, 
  ** 1100 to reach the main IVR.
  * The IVR options possible without getting into Phase 2.
 
 
 Diffs
 -
 
   /branches/13/configs/basic-pbx/pjsip.conf 43 
   /branches/13/configs/basic-pbx/modules.conf 43 
   /branches/13/configs/basic-pbx/logger.conf 43 
   /branches/13/configs/basic-pbx/extensions.conf 43 
   /branches/13/configs/basic-pbx/cdr_custom.conf PRE-CREATION 
   /branches/13/configs/basic-pbx/cdr.conf PRE-CREATION 
 
 Diff: https://reviewboard.asterisk.org/r/4488/diff/
 
 
 Testing
 ---
 
 Setup with a Digium Cloud Services trunk and a few internal phones.
 Internal to Internal calls.
 Calls Internal to voicemail and other features.
 External to internal DID calls.
 External to internal feature calls.
 
 Basically tried to call as many ways as I could through all the various 
 features. Everything seemed to work.
 
 
 Thanks,
 
 rnewton
 


-- 
_
-- 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] 4510: app_confbridge (13): file playback blocks dtmf

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4510/#review14801
---



branches/13/apps/app_confbridge.c
https://reviewboard.asterisk.org/r/4510/#comment25397

No parameters list.


- Jonathan Rose


On March 19, 2015, 4:59 p.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4510/
 ---
 
 (Updated March 19, 2015, 4:59 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24864
 https://issues.asterisk.org/jira/browse/ASTERISK-24864
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This is the Asterisk 13 version of the following: 
 https://reviewboard.asterisk.org/r/4477/
 
 Attempting to execute DTMF in a confbridge while file playback (prompt, 
 announcement, etc) is occurring is not allowed. You have to wait until the 
 sound file has completed before entering DTMF. This patch fixes it so that 
 app_confbridge now monitors for dtmf key presses during file playback. If a 
 key is pressed playback stops and it executes the matched menu option. Unlike 
 the Asterisk 11 patch this version does not re-queue the dtmf frame, but 
 instead uses an already available function that monitors for dtmf presses 
 during playback.
 
 
 Diffs
 -
 
   branches/13/main/bridge_channel.c 433195 
   branches/13/include/asterisk/bridge_channel.h 433195 
   branches/13/apps/app_confbridge.c 433195 
 
 Diff: https://reviewboard.asterisk.org/r/4510/diff/
 
 
 Testing
 ---
 
 Manual testing done. Setup a basic conference bridge that allowed both 
 regular and admin users to enter. Ran through various menu options to make 
 sure the sound file playback would stop (no longer have to wait) and a new 
 option was executed when appropriate. Also ran the app_confbridge testsuite 
 tests to make sure they still passed.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- 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] 4511: Audit ast_pjsip_rdata_get_endpoint() usage for ref leaks.

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4511/#review14749
---

Ship it!


Ship It!

- Jonathan Rose


On March 17, 2015, 10:04 p.m., rmudgett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4511/
 ---
 
 (Updated March 17, 2015, 10:04 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Valgrind found some memory leaks associated with
 ast_pjsip_rdata_get_endpoint().  The leaks would manifest when sending
 responses to OPTIONS requests, processing MESSAGE requests, and
 res_pjsip supplements implementing the incoming_request callback.
 
 * Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in
 res/res_pjsip.c:supplement_on_rx_request(),
 res/res_pjsip/pjsip_options.c:send_options_response(),
 res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and
 res/res_pjsip_messaging.c:send_response().
 
 * Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in
 res/res_pjsip_nat.c:nat_on_rx_message().
 
 * Fixed inconsistent but benign return value in
 res/res_pjsip/pjsip_options.c:options_on_rx_request().
 
 
 Diffs
 -
 
   /branches/13/res/res_pjsip_nat.c 433089 
   /branches/13/res/res_pjsip_messaging.c 433089 
   /branches/13/res/res_pjsip/pjsip_options.c 433089 
   /branches/13/res/res_pjsip.c 433089 
 
 Diff: https://reviewboard.asterisk.org/r/4511/diff/
 
 
 Testing
 ---
 
 Added temporary logging messages to show that incoming OPTIONS and MESSAGE
 requests hit the code that leaked the endpoint object refs.
 
 
 Thanks,
 
 rmudgett
 


-- 
_
-- 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] 4503: SAC: Configure customer advocate/sales queues

[Jonathan Rose]

 On March 17, 2015, 4:44 p.m., Mark Michelson wrote:
  Everything looks good here. Should this review stay open for the external 
  extensions to be added, or will that be a separate review?

I'll leave both reviews open for now.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4503/#review14730
---


On March 16, 2015, 10:37 a.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4503/
 ---
 
 (Updated March 16, 2015, 10:37 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 As described on the wiki at: 
 
  The Sales Queue may be reached externally by dialing 256-555-1200, or 
  internally by dialing 1200.
  The Customer Experience Queue may be reached externally by dialing 
  256-555-1250, or internally by dialing 1250.
 
  Sales Queue
  Calls to the Sales Queue should ring Terry, Garnet and Franny in ring-all 
  fashion
  If no one answers a call to the Sales Queue after 5 minutes, the caller 
  should be directed
  to the Operator so that the Operator can take a message and have a Sales 
  person contact the
  caller at a later time.
 
  Customer Advocate Queue
  Calls to the Customer Advocate Queue should ring Maria, Dusty and Tommie in 
  ring-all
  fashion. If no one answers a call to the Customer Advocate queue after 20 
  minutes, the
  caller should be directed to the Operator so that the Operator can take a 
  message and
  have a Customer Advocate contact the caller at a later time.
 
 NOTE: This review is accidentally against trunk, but the patch is perfectly 
 portable, so that shouldn't be a problem.
 
 NOTE 2: External extensions for the queues still need to be added since the 
 outside connectivity patch hasn't been merged yet
 https://reviewboard.asterisk.org/r/4488/diff/#index_header
 
 
 Diffs
 -
 
   /trunk/configs/basic-pbx/queues.conf PRE-CREATION 
   /trunk/configs/basic-pbx/modules.conf 432443 
   /trunk/configs/basic-pbx/extensions.conf 432443 
 
 Diff: https://reviewboard.asterisk.org/r/4503/diff/
 
 
 Testing
 ---
 
 Had some phones register as agents in the queues as well as the operator, 
 made sure the queue members were dialed in ring-all fashion and that the 
 timeouts occurred and the operator was dialed as expected.
 
 
 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] 4503: SAC: Configure customer advocate/sales queues

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4503/
---

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

As described on the wiki at: 

 The Sales Queue may be reached externally by dialing 256-555-1200, or 
 internally by dialing 1200.
 The Customer Experience Queue may be reached externally by dialing 
 256-555-1250, or internally by dialing 1250.

 Sales Queue
 Calls to the Sales Queue should ring Terry, Garnet and Franny in ring-all 
 fashion
 If no one answers a call to the Sales Queue after 5 minutes, the caller 
 should be directed
 to the Operator so that the Operator can take a message and have a Sales 
 person contact the
 caller at a later time.

 Customer Advocate Queue
 Calls to the Customer Advocate Queue should ring Maria, Dusty and Tommie in 
 ring-all
 fashion. If no one answers a call to the Customer Advocate queue after 20 
 minutes, the
 caller should be directed to the Operator so that the Operator can take a 
 message and
 have a Customer Advocate contact the caller at a later time.

NOTE: This review is accidentally against trunk, but the patch is perfectly 
portable, so that shouldn't be a problem.

NOTE 2: External extensions for the queues still need to be added since the 
outside connectivity patch hasn't been merged yet
https://reviewboard.asterisk.org/r/4488/diff/#index_header


Diffs
-

  /trunk/configs/basic-pbx/queues.conf PRE-CREATION 
  /trunk/configs/basic-pbx/modules.conf 432443 
  /trunk/configs/basic-pbx/extensions.conf 432443 

Diff: https://reviewboard.asterisk.org/r/4503/diff/


Testing
---

Had some phones register as agents in the queues as well as the operator, made 
sure the queue members were dialed in ring-all fashion and that the timeouts 
occurred and the operator was dialed as expected.


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] 4504: SAC: Add conferences for employees / employees+customers

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4504/
---

Review request for Asterisk Developers and rnewton.


Repository: Asterisk


Description
---

From: https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company

SAC requires two conference rooms, one for use by employees only and one for 
use by employees and customers (outside connectivity still needs to be 
established so that 555-6500 can be added and customers can actually dial into 
said conference)


Diffs
-

  /branches/13/configs/basic-pbx/modules.conf 432996 
  /branches/13/configs/basic-pbx/extensions.conf 432996 
  /branches/13/configs/basic-pbx/confbridge.conf PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4504/diff/


Testing
---

Made sure app_confbridge loaded and internal users were able to dial into the 
conferences.


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] 4488: Super Awesome Company: Phase 1 - Patch 2 - Outside Connectivity!

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4488/#review14688
---



/branches/13/configs/basic-pbx/extensions.conf
https://reviewboard.asterisk.org/r/4488/#comment25241

Since we already know what the numbers for these queues are going to be, 
you could probably go ahead and put the GOTO operations in there and stub them 
out.


- Jonathan Rose


On March 13, 2015, 9:32 a.m., rnewton wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4488/
 ---
 
 (Updated March 13, 2015, 9:32 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Howdy, here is another patch for the Super Awesome Company configuration. We 
 are still in phase 1. The general requirements are posted on the wiki: 
 https://wiki.asterisk.org/wiki/display/AST/Super+Awesome+Company
 
 The specific requirements this patch meets are below:
 
 pjsip.conf
 
  * SIP ITSP configuration example and have place holders for the required 
 authentication bits.
  ** Assume that Asterisk does not have a public IP address, and sits behind a 
 NAT with its desk phones.
  * Have outbound registration to the SIP trunk, and an endpoint that 
 represents the SIP trunk.
  * Inbound calls received from the SIP trunk should go into their own context.
 
 extensions.conf
 
  * Match the outbound dial request so that it can only dial US area codes.
  ** Don't let people dial 900 numbers, international numbers, or any other 
 numbers that could result in a charge
  * Inbound calls from the SIP trunk should hit a basic Auto Attendant that 
 prompts them for the extension to dial, after greeting them to SAC.
  * If an inbound call matches a DID that maps to a specific extension/device, 
 dial that extension/device directly.
 
 Billing
 
  * Make sure CDRs output all calls that are from/to the SIP trunk. These 
 should be logged to a CSV.
  * For intra-office calls, kill the CDRs.
 
 Additional Requirements Noted:
 
  * For outbound calls, each SAC employee’s 10-digit DID number is provided as 
 their Caller ID.
  * Voicemail may be accessed remotely by employees who dial 256-555-1234. 
 When employees dial voicemail remotely, they must input both their mailbox 
 number and their pin code.
  * 7, 10 and 10+1 digit dialing for local and long distance calls.
  * Internal dialing of otherwise inbound features, 
  ** 1100 to reach the main IVR.
  * The IVR options possible without getting into Phase 2.
 
 
 Diffs
 -
 
   /branches/13/configs/basic-pbx/pjsip.conf 432866 
   /branches/13/configs/basic-pbx/modules.conf 432866 
   /branches/13/configs/basic-pbx/logger.conf 432866 
   /branches/13/configs/basic-pbx/extensions.conf 432866 
 
 Diff: https://reviewboard.asterisk.org/r/4488/diff/
 
 
 Testing
 ---
 
 Setup with a Digium Cloud Services trunk and a few internal phones.
 Internal to Internal calls.
 Calls Internal to voicemail and other features.
 External to internal DID calls.
 External to internal feature calls.
 
 Basically tried to call as many ways as I could through all the various 
 features. Everything seemed to work.
 
 
 Thanks,
 
 rnewton
 


-- 
_
-- 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] 4373: Manager Action ModuleLoad gives incorrect response when used to reload modules

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4373/
---

(Updated Jan. 27, 2015, 11:22 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and jbigelow.


Changes
---

Committed in revision 431153


Repository: Asterisk


Description
---

ModuleLoad actions give the wrong response when used to reload a module. On 
success, it will issue a 'no such module' error instead of a success response 
even though the module was reloaded successfully.


Diffs
-

  /branches/13/main/manager.c 431112 

Diff: https://reviewboard.asterisk.org/r/4373/diff/


Testing
---

Before Patch:

Action: ModuleLoad
LoadType: reload
Module: pbx_config.so

Response: Error
Message: No such module.

CLI output showed the module was actually reloaded successfully.

After Patch:

Action: ModuleLoad
LoadType: reload
Module: pbx_config.so

Response: Success
Message: Module reloaded.


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] 4373: Manager Action ModuleLoad gives incorrect response when used to reload modules

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4373/
---

Review request for Asterisk Developers and jbigelow.


Repository: Asterisk


Description
---

ModuleLoad actions give the wrong response when used to reload a module. On 
success, it will issue a 'no such module' error instead of a success response 
even though the module was reloaded successfully.


Diffs
-

  /branches/12/main/manager.c 431112 

Diff: https://reviewboard.asterisk.org/r/4373/diff/


Testing
---

Before Patch:

Action: ModuleLoad
LoadType: reload
Module: pbx_config.so

Response: Error
Message: No such module.

CLI output showed the module was actually reloaded successfully.

After Patch:

Action: ModuleLoad
LoadType: reload
Module: pbx_config.so

Response: Success
Message: Module reloaded.


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] 4373: Manager Action ModuleLoad gives incorrect response when used to reload modules

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4373/
---

(Updated Jan. 26, 2015, 2:16 p.m.)


Review request for Asterisk Developers and jbigelow.


Changes
---

Switch to 13, address finding.

That moment when you start doing Asterisk work again and feel like Rip Van 
Winkle...


Repository: Asterisk


Description
---

ModuleLoad actions give the wrong response when used to reload a module. On 
success, it will issue a 'no such module' error instead of a success response 
even though the module was reloaded successfully.


Diffs (updated)
-

  /branches/13/main/manager.c 431112 

Diff: https://reviewboard.asterisk.org/r/4373/diff/


Testing
---

Before Patch:

Action: ModuleLoad
LoadType: reload
Module: pbx_config.so

Response: Error
Message: No such module.

CLI output showed the module was actually reloaded successfully.

After Patch:

Action: ModuleLoad
LoadType: reload
Module: pbx_config.so

Response: Success
Message: Module reloaded.


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] 4050: Add ability for Channel Drivers to provide Presence State information

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4050/#review13858
---



/trunk/main/channel.c
https://reviewboard.asterisk.org/r/4050/#comment24338

Nothing you did in channel.c appears to require this inclusion.



/trunk/main/pbx.c
https://reviewboard.asterisk.org/r/4050/#comment24337

Consider an assertion here?


This could probably use a unit test, especially since you didn't add any 
support for this feature to any of the existing channel drivers in this patch.

I would imagine a unit test to do the following:

1 - Create a channel tech with a presence_provider function (see 
res/parking/parking_tests for an example of a temporary tech just used for a 
unit test)
2 - Create a channel using that tech
3 - Use your presence provider function to retrieve the presence state of the 
channel
4 - Change the presence state of the channel
5 - Check presence state again
6 - release the channel

- Jonathan Rose


On Oct. 16, 2014, 11:26 p.m., gareth wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4050/
 ---
 
 (Updated Oct. 16, 2014, 11:26 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24363
 https://issues.asterisk.org/jira/browse/ASTERISK-24363
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This patch adds the ability for channel drivers to supply presence 
 information in a similar manner to device state.
 
 eg: exten = XXX,hint,,Technology/Resource
 
 
 Diffs
 -
 
   /trunk/main/presencestate.c 425756 
   /trunk/main/pbx.c 425756 
   /trunk/main/channel.c 425756 
   /trunk/include/asterisk/channel.h 425756 
 
 Diff: https://reviewboard.asterisk.org/r/4050/diff/
 
 
 Testing
 ---
 
 Code is originally written as part of ASTERISK-13145 which has undergone 
 extensive testing.
 
 
 Thanks,
 
 gareth
 


-- 
_
-- 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] 4120: res_pjsip_acl: contact ACL permits are being interpreted incorrectly

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4120/
---

(Updated Nov. 20, 2014, 9:46 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 428333


Repository: Asterisk


Description
---

In the attempt to skip past the 'contact' part of the variable name before 
passing it into the acl handler, we have a momentary lapse of sanity and forget 
that '_allow' isn't 'allow' and ast_append_acl interprets it as another deny.


Diffs
-

  /branches/12/res/res_pjsip_acl.c 426232 

Diff: https://reviewboard.asterisk.org/r/4120/diff/


Testing
---

deny=0.0.0.0/24
allow=ip address of a device that tries to register

Note that I have to reload pjsip after startup in order for the ACL to work... 
that seems like a bug surely.  In any event, with the patch the device 
successfully registers.  Without the patch, the registration is blocked by the 
ACL.


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] 4109: Documentation: CDR unanswered behavior

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4109/
---

(Updated Nov. 14, 2014, 11:42 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 427901


Bugs: https://issues.asterisk.org/jira/browse/ASTERISK-24279

https://issues.asterisk.org/jira/browse/https://issues.asterisk.org/jira/browse/ASTERISK-24279


Repository: Asterisk


Description
---

Fixes the documentation of the cdr.conf option 'Unanswered' to hopefully more 
accurately explain the behavior. Culled some less than accurate, somewhat 
misleading information and explained a little bit about what kinds of calls 
will be skipped from logs under this context.

In addition, fixing a bit of missing documentation and a dead link on the wiki:

https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=22088359selectedPageVersions=15selectedPageVersions=13

I'm not sure if I'm entirely satisfied with my definition for Unanswered.


Diffs
-

  /branches/12/main/cdr.c 426095 
  /branches/12/configs/cdr.conf.sample 426095 

Diff: https://reviewboard.asterisk.org/r/4109/diff/


Testing
---

I checked some simple calling scenarios involve app_dial in one case and call 
files in another to make sure that the behavior didn't differ from the 
definition... at least in those scenarios.


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] 4120: res_pjsip_acl: contact ACL permits are being interpreted incorrectly

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4120/
---

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

In the attempt to skip past the 'contact' part of the variable name before 
passing it into the acl handler, we have a momentary lapse of sanity and forget 
that '_allow' isn't 'allow' and ast_append_acl interprets it as another deny.


Diffs
-

  /branches/12/res/res_pjsip_acl.c 426232 

Diff: https://reviewboard.asterisk.org/r/4120/diff/


Testing
---

deny=0.0.0.0/24
allow=ip address of a device that tries to register

Note that I have to reload pjsip after startup in order for the ACL to work... 
that seems like a bug surely.  In any event, with the patch the device 
successfully registers.  Without the patch, the registration is blocked by the 
ACL.


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] 4117: Fix building chan_phone on big endian systems

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4117/#review13603
---

Ship it!


Ship It!

- Jonathan Rose


On Oct. 28, 2014, 12:46 p.m., Tzafrir Cohen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4117/
 ---
 
 (Updated Oct. 28, 2014, 12:46 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: https://issues.asterisk.org/jira/browse/ASTERISK-24458
 
 https://issues.asterisk.org/jira/browse/https://issues.asterisk.org/jira/browse/ASTERISK-24458
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 A left over from the formats conversion.
 
 Note: there seem to be a few other left-over AST_FORMAT_SLINEAR, mostly in 
 comments. Fix those as well?
 
 
 Diffs
 -
 
   /branches/13/channels/chan_phone.c 426440 
 
 Diff: https://reviewboard.asterisk.org/r/4117/diff/
 
 
 Testing
 ---
 
 Big endian platforms (sparc, powerpc, s390x) on buildd.debian.org now build.
 
 
 Thanks,
 
 Tzafrir Cohen
 


-- 
_
-- 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] 4085: ExtensionStatus: Add additional documentation describing the ExtensionStatus event

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4085/
---

(Updated Oct. 24, 2014, 10:18 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Changes
---

Committed in revision 426120


Repository: Asterisk


Description
---

Some internals developers pointed out that this event was poorly documented, 
particularly when it comes to Status and StatusText which really need to be 
explained in order to be useful.


Diffs
-

  /branches/13/main/manager.c 425546 

Diff: https://reviewboard.asterisk.org/r/4085/diff/


Testing
---

Checked the output of

 manager show event ExtensionStatus

Exten
Name of the extension.
Context
Context that owns the extension.
Hint
Devices mapped to the extension which determine the extension status
Status
Numerical data indicating the status of the extension based on its
devices. Negative values indicate that the extension was removed (-2)
or deactivated (-1). Zero indicates that the extension is idle. Positive
values work as bitflags and may combine to indicate different things.
For example 1 would mean inuse, 2 would mean busy, and the two can add
together additively into 3 to mean that a line is both inuse and busy.
Each of the major classifications is a power of two and they can
potentailly be added in any combination.
-2 - Removed - The extension was removed. Not additive.
-1 - Deactivated - The extension's hit was removed. Not additive.
0 - Idle - No device INUSE or BUSY. Not additive.
1 - In Use - one or more devices INUSE. Additive.
2 - Busy - All devices are BUSY. Additive.
4 - Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED.
Additive.
8 - Ringing - All devices are RINGING. Additive.
16 - Onhold - All devices are ONHOLD. Additive.
StatusText
Human readable representation of the status. The options are also
more strictly defined and may only be one thing from the following
enumerator.
Idle - No device INUSE or BUSY.
InUse - One or more devices are INUSE.
Busy - All devices are BUSY.
Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED
Ringing - All devices are RINGING
InUseRinging - All devices are RINGING and one or more devices are
INUSE
Hold - All devices are ONHOLD.
InUseHold - All devices are ONHOLD and one or more devices are INUSE
Unknown - None of the above descriptions matched the status
value


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] 4109: Documentation: CDR unanswered behavior

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4109/
---

Review request for Asterisk Developers.


Bugs: https://issues.asterisk.org/jira/browse/ASTERISK-24279

https://issues.asterisk.org/jira/browse/https://issues.asterisk.org/jira/browse/ASTERISK-24279


Repository: Asterisk


Description
---

Fixes the documentation of the cdr.conf option 'Unanswered' to hopefully more 
accurately explain the behavior. Culled some less than accurate, somewhat 
misleading information and explained a little bit about what kinds of calls 
will be skipped from logs under this context.

In addition, fixing a bit of missing documentation and a dead link on the wiki:

https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=22088359selectedPageVersions=15selectedPageVersions=13

I'm not sure if I'm entirely satisfied with my definition for Unanswered.


Diffs
-

  /branches/12/main/cdr.c 426095 
  /branches/12/configs/cdr.conf.sample 426095 

Diff: https://reviewboard.asterisk.org/r/4109/diff/


Testing
---

I checked some simple calling scenarios involve app_dial in one case and call 
files in another to make sure that the behavior didn't differ from the 
definition... at least in those scenarios.


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] 4085: ExtensionStatus: Add additional documentation describing the ExtensionStatus event

[Jonathan Rose]

 On Oct. 15, 2014, 4:30 p.m., Mark Michelson wrote:
  /branches/13/main/manager.c, line 1225
  https://reviewboard.asterisk.org/r/4085/diff/1/?file=68352#file68352line1225
 
  In an experiment, I had one busy and one inuse device in a hint, and 
  the ExtensionStatus showed 2 as the status. So I don't think all devices 
  have to be busy for 2 to be shown. In fact, I think all of the all devices 
  are ... explanations in this section are incorrect.
  
  I believe the device state aggregation rules determine which status is 
  reported here when multiple devices have different statuses. If you have a 
  look at ast_devstate_aggregate_add() in devicestate.c, you can find how the 
  device states combine to form an extension state.
  
  Now, having pointed this out, I don't think it's really necessary to 
  try to transcribe that code into an English explanation. I think it's 
  acceptable to state for each individual state here that Asterisk has 
  determined that the combined state of the devices is that extension state, 
  as well as a high-level explanation of what that extension state means. If 
  people want a deeper explanation of how Asterisk came to that conclusion, 
  we can write a wiki article that goes more in-depth.

I got these rules directly from the comments describing the 
ast_extension_states enumerator in pbx.h, so they might need a look at some 
point.

I'll do as you suggested though and not attempt to describe specific rules for 
how they are determined.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4085/#review13529
---


On Oct. 15, 2014, 2:01 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4085/
 ---
 
 (Updated Oct. 15, 2014, 2:01 p.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and Mark Michelson.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Some internals developers pointed out that this event was poorly documented, 
 particularly when it comes to Status and StatusText which really need to be 
 explained in order to be useful.
 
 
 Diffs
 -
 
   /branches/13/main/manager.c 425546 
 
 Diff: https://reviewboard.asterisk.org/r/4085/diff/
 
 
 Testing
 ---
 
 Checked the output of
 
  manager show event ExtensionStatus
 
 Exten
 Name of the extension.
 Context
 Context that owns the extension.
 Hint
 Devices mapped to the extension which determine the extension status
 Status
 Numerical data indicating the status of the extension based on its
 devices. Negative values indicate that the extension was removed (-2)
 or deactivated (-1). Zero indicates that the extension is idle. Positive
 values work as bitflags and may combine to indicate different things.
 For example 1 would mean inuse, 2 would mean busy, and the two can add
 together additively into 3 to mean that a line is both inuse and busy.
 Each of the major classifications is a power of two and they can
 potentailly be added in any combination.
 -2 - Removed - The extension was removed. Not additive.
 -1 - Deactivated - The extension's hit was removed. Not additive.
 0 - Idle - No device INUSE or BUSY. Not additive.
 1 - In Use - one or more devices INUSE. Additive.
 2 - Busy - All devices are BUSY. Additive.
 4 - Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED.
 Additive.
 8 - Ringing - All devices are RINGING. Additive.
 16 - Onhold - All devices are ONHOLD. Additive.
 StatusText
 Human readable representation of the status. The options are also
 more strictly defined and may only be one thing from the following
 enumerator.
 Idle - No device INUSE or BUSY.
 InUse - One or more devices are INUSE.
 Busy - All devices are BUSY.
 Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED
 Ringing - All devices are RINGING
 InUseRinging - All devices are RINGING and one or more devices are
 INUSE
 Hold - All devices are ONHOLD.
 InUseHold - All devices are ONHOLD and one or more devices are INUSE
 Unknown - None of the above descriptions matched the status
 value
 
 
 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] 4085: ExtensionStatus: Add additional documentation describing the ExtensionStatus event

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4085/
---

(Updated Oct. 16, 2014, 2:06 p.m.)


Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Changes
---

Updated to respond to mmichelson's findings.  Hopefully this is adequate.

*CLI manager show event ExtensionStatus
Event: ExtensionStatus
[Synopsis]
Raised when a hint changes due to a device state change.

[Syntax]
Event: ExtensionStatus
Exten: value
Context: value
Hint: value
Status: value
StatusText: value

[Arguments]
Exten
Name of the extension.
Context
Context that owns the extension.
Hint
Hint set for the extension
Status
Numerical value of the extension status. Extension status is
determined by the combined device state of all items contained in the
hint.
-2 - The extension was removed from the dialplan.
-1 - The extension's hint was removed from the dialplan.
0 - 'Idle' - Related device(s) are in an idle state.
1 - 'InUse' - Related device(s) are in active calls but may take
more calls.
2 - 'Busy' - Related device(s) are in active calls and may not take
any more calls.
4 - 'Unavailable' - Related device(s) are not reachable.
8 - 'Ringing' - Related device(s) are currently ringing.
9 - 'InUseRinging' - Related device(s) are currently ringing and
in active calls.
16 - 'Hold' - Related device(s) are currently on hold.
17 - 'InUseHold' - Related device(s) are currently on hold and in
active calls.
StatusText
Text representation of 'Status'.
Idle
InUse
Busy
Unavailable
Ringing
InUseRinging
Hold
InUseHold
Unknown - Status does not match any of the above values.


Repository: Asterisk


Description
---

Some internals developers pointed out that this event was poorly documented, 
particularly when it comes to Status and StatusText which really need to be 
explained in order to be useful.


Diffs (updated)
-

  /branches/13/main/manager.c 425546 

Diff: https://reviewboard.asterisk.org/r/4085/diff/


Testing
---

Checked the output of

 manager show event ExtensionStatus

Exten
Name of the extension.
Context
Context that owns the extension.
Hint
Devices mapped to the extension which determine the extension status
Status
Numerical data indicating the status of the extension based on its
devices. Negative values indicate that the extension was removed (-2)
or deactivated (-1). Zero indicates that the extension is idle. Positive
values work as bitflags and may combine to indicate different things.
For example 1 would mean inuse, 2 would mean busy, and the two can add
together additively into 3 to mean that a line is both inuse and busy.
Each of the major classifications is a power of two and they can
potentailly be added in any combination.
-2 - Removed - The extension was removed. Not additive.
-1 - Deactivated - The extension's hit was removed. Not additive.
0 - Idle - No device INUSE or BUSY. Not additive.
1 - In Use - one or more devices INUSE. Additive.
2 - Busy - All devices are BUSY. Additive.
4 - Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED.
Additive.
8 - Ringing - All devices are RINGING. Additive.
16 - Onhold - All devices are ONHOLD. Additive.
StatusText
Human readable representation of the status. The options are also
more strictly defined and may only be one thing from the following
enumerator.
Idle - No device INUSE or BUSY.
InUse - One or more devices are INUSE.
Busy - All devices are BUSY.
Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED
Ringing - All devices are RINGING
InUseRinging - All devices are RINGING and one or more devices are
INUSE
Hold - All devices are ONHOLD.
InUseHold - All devices are ONHOLD and one or more devices are INUSE
Unknown - None of the above descriptions matched the status
value


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] 4085: ExtensionStatus: Add additional documentation describing the ExtensionStatus event

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4085/
---

Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Repository: Asterisk


Description
---

Some internals developers pointed out that this event was poorly documented, 
particularly when it comes to Status and StatusText which really need to be 
explained in order to be useful.


Diffs
-

  /branches/13/main/manager.c 425546 

Diff: https://reviewboard.asterisk.org/r/4085/diff/


Testing
---

Checked the output of

 manager show event ExtensionStatus

Exten
Name of the extension.
Context
Context that owns the extension.
Hint
Devices mapped to the extension which determine the extension status
Status
Numerical data indicating the status of the extension based on its
devices. Negative values indicate that the extension was removed (-2)
or deactivated (-1). Zero indicates that the extension is idle. Positive
values work as bitflags and may combine to indicate different things.
For example 1 would mean inuse, 2 would mean busy, and the two can add
together additively into 3 to mean that a line is both inuse and busy.
Each of the major classifications is a power of two and they can
potentailly be added in any combination.
-2 - Removed - The extension was removed. Not additive.
-1 - Deactivated - The extension's hit was removed. Not additive.
0 - Idle - No device INUSE or BUSY. Not additive.
1 - In Use - one or more devices INUSE. Additive.
2 - Busy - All devices are BUSY. Additive.
4 - Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED.
Additive.
8 - Ringing - All devices are RINGING. Additive.
16 - Onhold - All devices are ONHOLD. Additive.
StatusText
Human readable representation of the status. The options are also
more strictly defined and may only be one thing from the following
enumerator.
Idle - No device INUSE or BUSY.
InUse - One or more devices are INUSE.
Busy - All devices are BUSY.
Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED
Ringing - All devices are RINGING
InUseRinging - All devices are RINGING and one or more devices are
INUSE
Hold - All devices are ONHOLD.
InUseHold - All devices are ONHOLD and one or more devices are INUSE
Unknown - None of the above descriptions matched the status
value


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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/
---

(Updated Oct. 15, 2014, 2:05 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Committed in revision 425611


Bugs: ASTERISK-24413
https://issues.asterisk.org/jira/browse/ASTERISK-24413


Repository: Asterisk


Description
---

This patch simply follows the suggested fix of specifying the format for test 
channels in the same manner as was done for the CDR unit tests.


Diffs
-

  /branches/13/res/parking/parking_tests.c 425404 

Diff: https://reviewboard.asterisk.org/r/4075/diff/


Testing
---

Ran tests prior to patch and got assertions.  Assertions no longer occurred 
with the patch in place.


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] 4071: scheduler: Fix a bug introduced by adding a delete flag to scheduled tasks

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4071/
---

(Updated Oct. 14, 2014, 1:49 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Changes
---

Committed in revision 425503


Bugs: ASTERISK-24321
https://issues.asterisk.org/jira/browse/ASTERISK-24321


Repository: Asterisk


Description
---

This issue was discovered by a rather complicated series of tests by PQ and 
it's somewhat intermittent relying on hitting the same race conditions that 
were being solved by r422070. When this problem hits the __sip_ack method in 
chan_sip in particular, things go south quickly.

The gist of it is that when we attempt to remove an existing task, we mark it 
for deletion and it is later removed from the scheduler. The deleted entry 
doesn't get free'd on account of the scheduler caching task structures so that 
we don't waste a bunch of effort reallocating all of the task structures every 
time a task needs to be created/torn down. When we wanted to remove a task that 
was currently executing, we couldn't do this immediately so we would apply a 
deleted flag. Unfortunately we didn't bother to clear the deleted flag when 
pulling it back off of the cache to create a new task.  Oops.  In any event, 
shenanigans ensued because the new task would be created already doomed and 
while they would be reported as successfully scheduled, ast_sched_runq would 
immediately delete the new task without replacing it the chan_sip __sip_ack 
function was anticipating that the tasks would stick around until it deleted 
them.

The fix is mind-numbingly simple for how long it took to me to figure out what 
the heck was going on... just remember to clear the deleted flag from scheduler 
entries when pulling them off the cache.


Diffs
-

  /branches/12/main/sched.c 425241 

Diff: https://reviewboard.asterisk.org/r/4071/diff/


Testing
---

We had a series of tests that, pre-patch would yield an assertion looking like 
the following:

[Oct 10 13:12:57] ERROR[18046][C-000e]: chan_sip.c:4428 __sip_ack: FRACK!, 
Failed assertion s != NULL, id=1570 (0)
Got 14 backtrace records
#0: [0x823d4fa] asterisk(__ast_assert_failed+0x7b) [0x823d4fa]
#1: [0x81fe913] asterisk(_ast_sched_del+0x2b3) [0x81fe913]
#2: [0xfeb248] /usr/lib/asterisk/modules/chan_sip.so [0xfeb248]
#3: [0x106c930] /usr/lib/asterisk/modules/chan_sip.so [0x106c930]
#4: [0x106d1e9] /usr/lib/asterisk/modules/chan_sip.so [0x106d1e9]
#5: [0x106cdb4] /usr/lib/asterisk/modules/chan_sip.so [0x106cdb4]
#6: [0x8171359] asterisk(ast_io_wait+0x14d) [0x8171359]
#7: [0x106f0f8] /usr/lib/asterisk/modules/chan_sip.so [0x106f0f8]
#8: [0x82399d5] asterisk [0x82399d5]d an infinite loop in the do_monitor thread 
couple with this set of log messages:

indicating that we were anticipating to find a scheduler entry that wasn't in 
the scheduler

Similar assertions occurred from other modules that involved schedulers but no 
chan_sip, but those didn't clearly break the world.

Typically a walk through the specified tests (which involved lots of chan_sip 
calls entering queues and lots of reloading of chan_sip and app_queue) would 
cause this breakdown to occur within one or two walks across the test series 
suggested. After performing the full set of tests 5 times each across Asterisk 
on two separate occasions without seeing any assertions of this type and 
without having chan_sip break down, I retested without the patch and quickly 
ran into the problem again. I think it's safe to say that I got it.


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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/
---

(Updated Oct. 14, 2014, 4:10 p.m.)


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Address a finding.

I also noticed that adding formats to this test caused the test channels to 
immediately be kicked out of the parking bridges causing the park_retrieval 
test to fail. To fix that I gave the channels read/write functions and a 
makeshift technology to use.


Bugs: ASTERISK-24413
https://issues.asterisk.org/jira/browse/ASTERISK-24413


Repository: Asterisk


Description
---

This patch simply follows the suggested fix of specifying the format for test 
channels in the same manner as was done for the CDR unit tests.


Diffs (updated)
-

  /branches/13/res/parking/parking_tests.c 425404 

Diff: https://reviewboard.asterisk.org/r/4075/diff/


Testing
---

Ran tests prior to patch and got assertions.  Assertions no longer occurred 
with the patch in place.


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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/
---

(Updated Oct. 14, 2014, 4:49 p.m.)


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Improve the read function by making it just return the ast_null_frame pointer.


Bugs: ASTERISK-24413
https://issues.asterisk.org/jira/browse/ASTERISK-24413


Repository: Asterisk


Description
---

This patch simply follows the suggested fix of specifying the format for test 
channels in the same manner as was done for the CDR unit tests.


Diffs (updated)
-

  /branches/13/res/parking/parking_tests.c 425404 

Diff: https://reviewboard.asterisk.org/r/4075/diff/


Testing
---

Ran tests prior to patch and got assertions.  Assertions no longer occurred 
with the patch in place.


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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/
---

Review request for Asterisk Developers and Matt Jordan.


Bugs: ASTERISK-24413
https://issues.asterisk.org/jira/browse/ASTERISK-24413


Repository: Asterisk


Description
---

This patch simply follows the suggested fix of specifying the format for test 
channels in the same manner as was done for the CDR unit tests.


Diffs
-

  /branches/13/res/parking/parking_tests.c 425404 

Diff: https://reviewboard.asterisk.org/r/4075/diff/


Testing
---

Ran tests prior to patch and got assertions.  Assertions no longer occurred 
with the patch in place.


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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

 On Oct. 13, 2014, 4:58 p.m., rmudgett wrote:
  /branches/13/res/parking/parking_tests.c, lines 60-64
  https://reviewboard.asterisk.org/r/4075/diff/1/?file=68013#file68013line60
 
  Why is chan in parentheses?

Because I lazily copied this function from a macro and overlooked all of these 
things.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/#review13506
---


On Oct. 13, 2014, 3:59 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4075/
 ---
 
 (Updated Oct. 13, 2014, 3:59 p.m.)
 
 
 Review request for Asterisk Developers and Matt Jordan.
 
 
 Bugs: ASTERISK-24413
 https://issues.asterisk.org/jira/browse/ASTERISK-24413
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This patch simply follows the suggested fix of specifying the format for test 
 channels in the same manner as was done for the CDR unit tests.
 
 
 Diffs
 -
 
   /branches/13/res/parking/parking_tests.c 425404 
 
 Diff: https://reviewboard.asterisk.org/r/4075/diff/
 
 
 Testing
 ---
 
 Ran tests prior to patch and got assertions.  Assertions no longer occurred 
 with the patch in place.
 
 
 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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/
---

(Updated Oct. 13, 2014, 5:18 p.m.)


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Addressed rmudgett's findings.


Bugs: ASTERISK-24413
https://issues.asterisk.org/jira/browse/ASTERISK-24413


Repository: Asterisk


Description
---

This patch simply follows the suggested fix of specifying the format for test 
channels in the same manner as was done for the CDR unit tests.


Diffs (updated)
-

  /branches/13/res/parking/parking_tests.c 425404 

Diff: https://reviewboard.asterisk.org/r/4075/diff/


Testing
---

Ran tests prior to patch and got assertions.  Assertions no longer occurred 
with the patch in place.


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] 4075: parking/tests: Running res_parking unit tests would cause assertions and possibly a crash due to attempting to play MOH on a channel with no formats

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4075/
---

(Updated Oct. 13, 2014, 5:45 p.m.)


Review request for Asterisk Developers and Matt Jordan.


Changes
---

fix finding where I got silly.


Bugs: ASTERISK-24413
https://issues.asterisk.org/jira/browse/ASTERISK-24413


Repository: Asterisk


Description
---

This patch simply follows the suggested fix of specifying the format for test 
channels in the same manner as was done for the CDR unit tests.


Diffs (updated)
-

  /branches/13/res/parking/parking_tests.c 425404 

Diff: https://reviewboard.asterisk.org/r/4075/diff/


Testing
---

Ran tests prior to patch and got assertions.  Assertions no longer occurred 
with the patch in place.


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] 4071: scheduler: Fix a bug introduced by adding a delete flag to scheduled tasks

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4071/
---

Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Bugs: ASTERISK-24321
https://issues.asterisk.org/jira/browse/ASTERISK-24321


Repository: Asterisk


Description
---

This issue was discovered by a rather complicated series of tests by PQ and 
it's somewhat intermittent relying on hitting the same race conditions that 
were being solved by r422070. When this problem hits the __sip_ack method in 
chan_sip in particular, things go south quickly.

The gist of it is that when we attempt to remove an existing task, we mark it 
for deletion and it is later removed from the scheduler. The deleted entry 
doesn't get free'd on account of the scheduler caching task structures so that 
we don't waste a bunch of effort reallocated all of the task structures every 
time a task needs to be created/torn down. When we wanted to remove a task that 
was currently executing, we couldn't do this immediately so we would apply a 
deleted flag. Unfortunately we didn't bother to clear the deleted flag when 
pulling it back off of the cache to create a new task.  Oops.  In any event, 
shenanigans ensued because the new task would be created already doomed and 
while they would be reported as successfully scheduled, ast_sched_runq would 
immediately delete the new task without replacing it the chan_sip __sip_ack 
function was anticipating that the tasks would stick around until it deleted 
them.

The fix is mind-numbingly simple for how long it took to me to figure out what 
the heck was going on... just remember to clear the deleted flag from scheduler 
entries when pulling them off the cache.


Diffs
-

  /branches/12/main/sched.c 425241 

Diff: https://reviewboard.asterisk.org/r/4071/diff/


Testing
---

We had a series of tests that, pre-patch would yield an assertion looking like 
the following:

[Oct 10 13:12:57] ERROR[18046][C-000e]: chan_sip.c:4428 __sip_ack: FRACK!, 
Failed assertion s != NULL, id=1570 (0)
Got 14 backtrace records
#0: [0x823d4fa] asterisk(__ast_assert_failed+0x7b) [0x823d4fa]
#1: [0x81fe913] asterisk(_ast_sched_del+0x2b3) [0x81fe913]
#2: [0xfeb248] /usr/lib/asterisk/modules/chan_sip.so [0xfeb248]
#3: [0x106c930] /usr/lib/asterisk/modules/chan_sip.so [0x106c930]
#4: [0x106d1e9] /usr/lib/asterisk/modules/chan_sip.so [0x106d1e9]
#5: [0x106cdb4] /usr/lib/asterisk/modules/chan_sip.so [0x106cdb4]
#6: [0x8171359] asterisk(ast_io_wait+0x14d) [0x8171359]
#7: [0x106f0f8] /usr/lib/asterisk/modules/chan_sip.so [0x106f0f8]
#8: [0x82399d5] asterisk [0x82399d5]d an infinite loop in the do_monitor thread 
couple with this set of log messages:

indicating that we were anticipating to find a scheduler entry that wasn't in 
the scheduler

Similar assertions occurred from other modules that involved schedulers but no 
chan_sip, but those didn't clearly break the world.

Typically a walk through the specified tests (which involved lots of chan_sip 
calls entering queues and lots of reloading of chan_sip and app_queue) would 
cause this breakdown to occur within one or two walks across the test series 
suggested. After performing the full set of tests 5 times each across Asterisk 
on two separate occasions without seeing any assertions of this type and 
without having chan_sip break down, I retested without the patch and quickly 
ran into the problem again. I think it's safe to say that I got it.


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] 4071: scheduler: Fix a bug introduced by adding a delete flag to scheduled tasks

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4071/
---

(Updated Oct. 10, 2014, 1:49 p.m.)


Review request for Asterisk Developers, Matt Jordan and Mark Michelson.


Bugs: ASTERISK-24321
https://issues.asterisk.org/jira/browse/ASTERISK-24321


Repository: Asterisk


Description (updated)
---

This issue was discovered by a rather complicated series of tests by PQ and 
it's somewhat intermittent relying on hitting the same race conditions that 
were being solved by r422070. When this problem hits the __sip_ack method in 
chan_sip in particular, things go south quickly.

The gist of it is that when we attempt to remove an existing task, we mark it 
for deletion and it is later removed from the scheduler. The deleted entry 
doesn't get free'd on account of the scheduler caching task structures so that 
we don't waste a bunch of effort reallocating all of the task structures every 
time a task needs to be created/torn down. When we wanted to remove a task that 
was currently executing, we couldn't do this immediately so we would apply a 
deleted flag. Unfortunately we didn't bother to clear the deleted flag when 
pulling it back off of the cache to create a new task.  Oops.  In any event, 
shenanigans ensued because the new task would be created already doomed and 
while they would be reported as successfully scheduled, ast_sched_runq would 
immediately delete the new task without replacing it the chan_sip __sip_ack 
function was anticipating that the tasks would stick around until it deleted 
them.

The fix is mind-numbingly simple for how long it took to me to figure out what 
the heck was going on... just remember to clear the deleted flag from scheduler 
entries when pulling them off the cache.


Diffs
-

  /branches/12/main/sched.c 425241 

Diff: https://reviewboard.asterisk.org/r/4071/diff/


Testing
---

We had a series of tests that, pre-patch would yield an assertion looking like 
the following:

[Oct 10 13:12:57] ERROR[18046][C-000e]: chan_sip.c:4428 __sip_ack: FRACK!, 
Failed assertion s != NULL, id=1570 (0)
Got 14 backtrace records
#0: [0x823d4fa] asterisk(__ast_assert_failed+0x7b) [0x823d4fa]
#1: [0x81fe913] asterisk(_ast_sched_del+0x2b3) [0x81fe913]
#2: [0xfeb248] /usr/lib/asterisk/modules/chan_sip.so [0xfeb248]
#3: [0x106c930] /usr/lib/asterisk/modules/chan_sip.so [0x106c930]
#4: [0x106d1e9] /usr/lib/asterisk/modules/chan_sip.so [0x106d1e9]
#5: [0x106cdb4] /usr/lib/asterisk/modules/chan_sip.so [0x106cdb4]
#6: [0x8171359] asterisk(ast_io_wait+0x14d) [0x8171359]
#7: [0x106f0f8] /usr/lib/asterisk/modules/chan_sip.so [0x106f0f8]
#8: [0x82399d5] asterisk [0x82399d5]d an infinite loop in the do_monitor thread 
couple with this set of log messages:

indicating that we were anticipating to find a scheduler entry that wasn't in 
the scheduler

Similar assertions occurred from other modules that involved schedulers but no 
chan_sip, but those didn't clearly break the world.

Typically a walk through the specified tests (which involved lots of chan_sip 
calls entering queues and lots of reloading of chan_sip and app_queue) would 
cause this breakdown to occur within one or two walks across the test series 
suggested. After performing the full set of tests 5 times each across Asterisk 
on two separate occasions without seeing any assertions of this type and 
without having chan_sip break down, I retested without the patch and quickly 
ran into the problem again. I think it's safe to say that I got it.


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] 4020: RLS Tests: off nominal tests for lists of lists (MWI and presence)

[Jonathan Rose]

 it also failed.


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] 4013: Alembic: Add 'outgoing' enum value to sippeers directmedia enumerator

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4013/
---

(Updated Oct. 2, 2014, 2:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Committed in revision 424372


Bugs: ASTERISK-23781
https://issues.asterisk.org/jira/browse/ASTERISK-23781


Repository: Asterisk


Description
---

The SIP directmedia value 'outgoing' was overlooked when creating the table and 
needs to be added. Unfortunately this means dropping the column and rebuilding 
it with a new enum.


Diffs
-

  
/branches/12/contrib/ast-db-manage/config/versions/10aedae86a32_add_outgoing_enum_va.py
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4013/diff/


Testing
---

upgraded, checked to see if I could put 'outgoing' in the directmedia column. 
Downgraded, upgraded again to make sure things didn't explode.

All on a postgres database


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] 4046: audiohooks: Reevaluate the bridge technology when an audiohook is added or removed.

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4046/#review13443
---

Ship it!


Code looks good and I confirmed that the patch fixes the behavior I noted on 
the issue. Ship it, ship it good.

- Jonathan Rose


On Oct. 2, 2014, 4:35 p.m., rmudgett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4046/
 ---
 
 (Updated Oct. 2, 2014, 4:35 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24195
 https://issues.asterisk.org/jira/browse/ASTERISK-24195
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Adding a mixmonitor to a channel causes the bridge to change technologies 
 from native to simple_bridge so the call can be recorded.  However, when the 
 mixmonitor is stopped the bridge does not switch back to the native 
 technology.
 
 * Added unbridge requests to reevaluate the bridge when a channel audiohook 
 is removed.
 
 * Moved the unbridge request into ast_audiohook_attach() ensure that the 
 bridge reevaluates whenever an audiohook is attached.  This simplified the 
 mixmonitor and chan_spy start code as well.
 
 * Added defensive code to stop_mixmonitor_full() in case additional arguments 
 are ever added to the StopMixMonitor application.
 
 * Made ast_framehook_detach() not do an unbridge request if the framehook 
 does not exist.
 
 * Made ast_framehook_list_fixup() do an unbridge request if there are any 
 framehooks.  Also simplified the loop.
 
 
 Diffs
 -
 
   /branches/12/main/framehook.c 424382 
   /branches/12/main/audiohook.c 424382 
   /branches/12/apps/app_mixmonitor.c 424382 
   /branches/12/apps/app_chanspy.c 424382 
 
 Diff: https://reviewboard.asterisk.org/r/4046/diff/
 
 
 Testing
 ---
 
 1 Made SIP A call SIP B such that directmedia was possible.
 2 Added a MixMonitor recorder to SIP A using AMI MixMonitor action.
 3 The bridge technology changed to simple_bridge
 4 Stopped the MixMonitor recorder using AMI StopMixMonitor action.
 5 The bridge technology now changes to native with the patch.
 
 
 Thanks,
 
 rmudgett
 


-- 
_
-- 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] 4045: chan_sip: process_sdp leaks on an error path

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4045/#review13444
---

Ship it!


Pretty obvious little oversight, looks good to go.

- Jonathan Rose


On Oct. 1, 2014, 9:43 p.m., Corey Farrell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4045/
 ---
 
 (Updated Oct. 1, 2014, 9:43 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24385
 https://issues.asterisk.org/jira/browse/ASTERISK-24385
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 process_sdp leaks on an error path where crypto lines are expected but not 
 provided.
 
 It appears this was fixed during the media format updates.  Version 13+ does 
 goto process_sdp_cleanup, I have not tested in 13+, but in 11/12 it is an 
 error to run offered_media_list_destroy during this error handler.  This bug 
 was found via tests/channels/SIP/SDP_offer_answer and 
 tests/channels/SIP/noload_res_srtp_attempt_srtp.  In both cases the tests 
 currently cause a leak in 11/12.  If the code is updated to goto 
 process_sdp_cleanup it causes these tests to fail, that is why I created the 
 label process_sdp_cleanup_b to skip offered_media_list_destroy.
 
 
 Diffs
 -
 
   /branches/11/channels/chan_sip.c 424335 
 
 Diff: https://reviewboard.asterisk.org/r/4045/diff/
 
 
 Testing
 ---
 
 Yes
 
 
 Thanks,
 
 Corey Farrell
 


-- 
_
-- 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] 4017: chan_pjsip: Don't attempt to apply formats if there aren't any capabilities defined when creating a new channel

[Jonathan Rose]

+100)
#8: [0x60f7bc] main/threadpool.c:1152 execute_tasks()
#9: [0x606d04] main/taskprocessor.c:768 ast_taskprocessor_execute() 
(0x606c04+100)
#10: [0x60dfec] main/threadpool.c:351 threadpool_execute()
#11: [0x60f4a2] main/threadpool.c:1072 worker_active()
#12: [0x60f25e] main/threadpool.c:993 worker_start()
#13: [0x61b9a5] main/utils.c:1201 dummy_start()
-- Executing [1603@default:1] Dial(PJSIP/1601-, PJSIP/1603) in 
new stack
[Sep 22 16:00:59] ERROR[2][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:00:59] WARNING[2][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:00:59] WARNING[2][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack
[Sep 22 16:01:05] WARNING[11026]: res_pjsip_mwi.c:679 mwi_new_subscribe: AOR 
1601 has no configured mailboxes. MWI subscription failed


And for comparison sake... the output in 13 with the patch applied:
*CLI -- Executing [1603@default:1] Dial(PJSIP/1601-, 
PJSIP/1603) in new stack
[Sep 22 16:01:59] ERROR[12441][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:01:59] WARNING[12441][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:01:59] WARNING[12441][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack

Oooh, now isn't that clean.


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] 4020: RLS Tests: off nominal tests for lists of lists (MWI and presence)

[Jonathan Rose]

 On Sept. 30, 2014, 11:17 a.m., opticron wrote:
  /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/sipp/list_subscribe.xml,
   line 40
  https://reviewboard.asterisk.org/r/4020/diff/1/?file=67557#file67557line40
 
  Do not reuse variables for regex matching.

Really no point in these anyway, they are just something left over from the 
scenario I based this on.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4020/#review13407
---


On Sept. 24, 2014, 5:28 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4020/
 ---
 
 (Updated Sept. 24, 2014, 5:28 p.m.)
 
 
 Review request for Asterisk Developers and Mark Michelson.
 
 
 Bugs: ASTERISK-23873
 https://issues.asterisk.org/jira/browse/ASTERISK-23873
 
 
 Repository: testsuite
 
 
 Description
 ---
 
 A series tests meant to cover the off-nominal test descriptions for lists of 
 lists described on this wiki page:
 https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan
 
 
 Diffs
 -
 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/tests.yaml
  5643 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/tests.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/tests.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/test-config.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/sipp/presence_subscription.xml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/pjsip.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/extensions.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/test-config.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/sipp/list_subscribe.xml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/pjsip.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/extensions.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/test-config.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/sipp/list_subscribe.xml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/pjsip.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/extensions.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/tests.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/test-config.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/sipp/mwi_subscription.xml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/configs/ast1/pjsip.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/test-config.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/sipp/list_subscribe.xml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/configs/ast1/pjsip.conf
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/test-config.yaml
  PRE-CREATION 
   
 /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication

Re: [asterisk-dev] [Code Review] 4020: RLS Tests: off nominal tests for lists of lists (MWI and presence)

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4020/
---

(Updated Sept. 30, 2014, 3:54 p.m.)


Review request for Asterisk Developers and Mark Michelson.


Changes
---

Address opticron's findings


Bugs: ASTERISK-23873
https://issues.asterisk.org/jira/browse/ASTERISK-23873


Repository: testsuite


Description
---

A series tests meant to cover the off-nominal test descriptions for lists of 
lists described on this wiki page:
https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan


Diffs (updated)
-

  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/tests.yaml
 5643 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/sipp/presence_subscription.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/sipp/mwi_subscription.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/configs/ast1/pjsip.conf
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4020/diff/


Testing
---

Ran each test to confirm that they passed, checked the SIP messages involved in 
the tests to make sure passing was sane.
Varied the expectations of the test to make sure that the tests would fail if 
the expectations didn't match the results.
Varied the parameters for things like eventlist support to guarantee that the 
tests that expected eventlist support failed if they didn't have it and that 
the tests that expected not to have eventlist support and had it also failed.


Thanks,

Jonathan Rose

Re: [asterisk-dev] [Code Review] 4017: chan_pjsip: Don't attempt to apply formats if there aren't any capabilities defined when creating a new channel

[Jonathan Rose]

 ast_taskprocessor_execute() 
(0x606c04+100)
#8: [0x60f7bc] main/threadpool.c:1152 execute_tasks()
#9: [0x606d04] main/taskprocessor.c:768 ast_taskprocessor_execute() 
(0x606c04+100)
#10: [0x60dfec] main/threadpool.c:351 threadpool_execute()
#11: [0x60f4a2] main/threadpool.c:1072 worker_active()
#12: [0x60f25e] main/threadpool.c:993 worker_start()
#13: [0x61b9a5] main/utils.c:1201 dummy_start()
-- Executing [1603@default:1] Dial(PJSIP/1601-, PJSIP/1603) in 
new stack
[Sep 22 16:00:59] ERROR[2][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:00:59] WARNING[2][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:00:59] WARNING[2][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack
[Sep 22 16:01:05] WARNING[11026]: res_pjsip_mwi.c:679 mwi_new_subscribe: AOR 
1601 has no configured mailboxes. MWI subscription failed


And for comparison sake... the output in 13 with the patch applied:
*CLI -- Executing [1603@default:1] Dial(PJSIP/1601-, 
PJSIP/1603) in new stack
[Sep 22 16:01:59] ERROR[12441][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:01:59] WARNING[12441][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:01:59] WARNING[12441][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack

Oooh, now isn't that clean.


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] 4020: RLS Tests: off nominal tests for lists of lists (MWI and presence)

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4020/
---

Review request for Asterisk Developers and Mark Michelson.


Bugs: ASTERISK-23873
https://issues.asterisk.org/jira/browse/ASTERISK-23873


Repository: testsuite


Description
---

A series tests meant to cover the off-nominal test descriptions for lists of 
lists described on this wiki page:
https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan


Diffs
-

  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/tests.yaml
 5643 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/sipp/presence_subscription.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/sipp/mwi_subscription.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/configs/ast1/pjsip.conf
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4020/diff/


Testing
---

Ran each test to confirm that they passed, checked the SIP messages involved in 
the tests to make sure passing was sane.
Varied the expectations of the test to make sure that the tests would fail if 
the expectations didn't match the results.
Varied the parameters for things like eventlist support to guarantee that the 
tests that expected eventlist support failed if they didn't have it and that 
the tests that expected not to have eventlist support and had it also failed.


Thanks,

Jonathan Rose

-- 
_
-- Bandwidth and Colocation

Re: [asterisk-dev] [Code Review] 4013: Alembic: Add 'outgoing' enum value to sippeers directmedia enumerator

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4013/
---

(Updated Sept. 23, 2014, 10:41 a.m.)


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Hey hey, so instead of dropping the tables I was able to do a safe altering of 
the tables by doing some postgres specific shenanigans. I've also made sure it 
works against mysql.
Basically, going forward everything is fine.  Going backwards, we change any 
instances of 'outgoing' in the table to NULL prior to changing the type.


Bugs: ASTERISK-23781
https://issues.asterisk.org/jira/browse/ASTERISK-23781


Repository: Asterisk


Description
---

The SIP directmedia value 'outgoing' was overlooked when creating the table and 
needs to be added. Unfortunately this means dropping the column and rebuilding 
it with a new enum.


Diffs (updated)
-

  
/branches/12/contrib/ast-db-manage/config/versions/10aedae86a32_add_outgoing_enum_va.py
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4013/diff/


Testing
---

upgraded, checked to see if I could put 'outgoing' in the directmedia column. 
Downgraded, upgraded again to make sure things didn't explode.

All on a postgres database


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] 4017: chan_pjsip: Don't attempt to apply formats if there aren't any capabilities defined when creating a new channel

[Jonathan Rose]

 execute_tasks()
#9: [0x606d04] main/taskprocessor.c:768 ast_taskprocessor_execute() 
(0x606c04+100)
#10: [0x60dfec] main/threadpool.c:351 threadpool_execute()
#11: [0x60f4a2] main/threadpool.c:1072 worker_active()
#12: [0x60f25e] main/threadpool.c:993 worker_start()
#13: [0x61b9a5] main/utils.c:1201 dummy_start()
-- Executing [1603@default:1] Dial(PJSIP/1601-, PJSIP/1603) in 
new stack
[Sep 22 16:00:59] ERROR[2][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:00:59] WARNING[2][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:00:59] WARNING[2][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack
[Sep 22 16:01:05] WARNING[11026]: res_pjsip_mwi.c:679 mwi_new_subscribe: AOR 
1601 has no configured mailboxes. MWI subscription failed


And for comparison sake... the output in 13 with the patch applied:
*CLI -- Executing [1603@default:1] Dial(PJSIP/1601-, 
PJSIP/1603) in new stack
[Sep 22 16:01:59] ERROR[12441][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:01:59] WARNING[12441][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:01:59] WARNING[12441][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack

Oooh, now isn't that clean.


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] 4013: Alembic: Add 'outgoing' enum value to sippeers directmedia enumerator

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4013/
---

Review request for Asterisk Developers and Matt Jordan.


Bugs: ASTERISK-23781
https://issues.asterisk.org/jira/browse/ASTERISK-23781


Repository: Asterisk


Description
---

The SIP directmedia value 'outgoing' was overlooked when creating the table and 
needs to be added. Unfortunately this means dropping the column and rebuilding 
it with a new enum.


Diffs
-

  
/branches/12/contrib/ast-db-manage/config/versions/10aedae86a32_add_outgoing_enum_va.py
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4013/diff/


Testing
---

upgraded, checked to see if I could put 'outgoing' in the directmedia column. 
Downgraded, upgraded again to make sure things didn't explode.


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] 4013: Alembic: Add 'outgoing' enum value to sippeers directmedia enumerator

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4013/
---

(Updated Sept. 22, 2014, 1:24 p.m.)


Review request for Asterisk Developers and Matt Jordan.


Changes
---

Add mention that postgres was used to test.


Bugs: ASTERISK-23781
https://issues.asterisk.org/jira/browse/ASTERISK-23781


Repository: Asterisk


Description
---

The SIP directmedia value 'outgoing' was overlooked when creating the table and 
needs to be added. Unfortunately this means dropping the column and rebuilding 
it with a new enum.


Diffs
-

  
/branches/12/contrib/ast-db-manage/config/versions/10aedae86a32_add_outgoing_enum_va.py
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4013/diff/


Testing (updated)
---

upgraded, checked to see if I could put 'outgoing' in the directmedia column. 
Downgraded, upgraded again to make sure things didn't explode.

All on a postgres database


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] 4017: chan_pjsip: Don't attempt to apply formats if there aren't any capabilities defined when creating a new channel

[Jonathan Rose]

)
#10: [0x60dfec] main/threadpool.c:351 threadpool_execute()
#11: [0x60f4a2] main/threadpool.c:1072 worker_active()
#12: [0x60f25e] main/threadpool.c:993 worker_start()
#13: [0x61b9a5] main/utils.c:1201 dummy_start()
-- Executing [1603@default:1] Dial(PJSIP/1601-, PJSIP/1603) in 
new stack
[Sep 22 16:00:59] ERROR[2][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:00:59] WARNING[2][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:00:59] WARNING[2][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack
[Sep 22 16:01:05] WARNING[11026]: res_pjsip_mwi.c:679 mwi_new_subscribe: AOR 
1601 has no configured mailboxes. MWI subscription failed


And for comparison sake... the output in 13 with the patch applied:
*CLI -- Executing [1603@default:1] Dial(PJSIP/1601-, 
PJSIP/1603) in new stack
[Sep 22 16:01:59] ERROR[12441][C-]: translate.c:1280 
ast_translator_best_choice: Cannot determine best translation path since one 
capability supports no formats
failed to extend from 64 to 98
[Sep 22 16:01:59] WARNING[12441][C-]: channel.c:5888 ast_request: No 
translator path exists for channel type PJSIP (native 
(g723|ulaw|alaw|gsm|g726|g726aal2|adpcm|slin|slin|slin|slin|)) to (nothing)
[Sep 22 16:01:59] WARNING[12441][C-]: app_dial.c:2431 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 58 - Bearer capability not 
available)
  == Everyone is busy/congested at this time (1:0/0/1)
-- Auto fallthrough, channel 'PJSIP/1601-' status is 'CHANUNAVAIL'
-- Executing [h@default:1] NoOp(PJSIP/1601-, AGI Exit Status: ) 
in new stack

Oooh, now isn't that clean.


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] 3999: chan_iax2: Jitterbuffer causes crash in Asterisk 13 on account of format changes

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3999/
---

(Updated Sept. 19, 2014, 9:56 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Committed in revision 423524


Bugs: ASTERISK-24265
https://issues.asterisk.org/jira/browse/ASTERISK-24265


Repository: Asterisk


Description
---

This only occurs when the chan_iax jitterbuffer options are set and no when 
setting jitterbuffers via diaplan or anything like that.

The first time __get_from_jb is called, voiceformat has not been set on the IAX 
pvt. Trying to call ast_format_get_default_ms on a NULL pointer fails. This 
worked previously because Asterisk 12 and prior simply modified an ast_format 
on the stack, so when it used ast_codec_interp_len on that format pointer there 
was no possibility for it to be a NULL pointer... just one that doesn't have a 
real format associated with it.

One thing I might not be doing right here is that I'm using an interpolation 
value of 0 for a NULL format. Previously Asterisk would just check to see if 
the format was ILBC and if it was, return 30 and otherwise return 20... so it 
might be more appropriate to use 20 instead of 0.  It doesn't appear to make a 
difference for the sake of behavior.


Diffs
-

  /branches/13/channels/chan_iax2.c 423149 

Diff: https://reviewboard.asterisk.org/r/3999/diff/


Testing
---

Ran basic call from a PJSIP peer to an IAX peer with the following:

[general]

; The important parts
jitterbuffer=yes
forcejitterbuffer=yes


[deskbox]
type=friend
requirecalltoken = no
username = deskbox
secret = secret
host = dynamic
transfer = no
dtmfmode = auto
encryption = no
qualify = 300
context = default
disallow=all
allow=ulaw
allow=alaw
; Most of this is probably unnecessary for reproduction


Without the patch this would crash in 13 but work fine in 12.
With the patch, behavior strongly resembles 12 with the initial call into 
__get_from_jb attempting to jb_get and getting JB_OK back and then later, when 
the call was actually answered, the voice format would change and the function 
would call again with the proper format and the jitterbuffer would get started 
properly.


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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
---

(Updated Sept. 19, 2014, 10:10 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Committed in revision 423525


Bugs: ASTERISK-24237
https://issues.asterisk.org/jira/browse/ASTERISK-24237


Repository: Asterisk


Description
---

Reproduction: 
pj123 calls 1601
pj123 does a SIP blonde transfer to 1603
1603 answers
FRACK occurs
all are PJSIP endpoints.

Basically what happens is there is a second outbound dial from another pj123 
channel. Before the dial is answered, the pj123 gets masqueraded out of the 
picture and replaced with a channel that isn't in the dial state.

This patch fixes that by advancing the incoming channel to the dial state in 
the channel breakdown function of a datastore on the pj123 channel. Honestly, 
I'm not sure this is entirely adequate, but it seems to work in all of the 
conditions I've tried so far and it doesn't impede normal attended transfers. I 
might need to try and figure out what happens if I masquerade in a channel that 
is already dialing though. I'm not sure if that's something we can really 
expect to happen under normal conditions, but that seems like something that 
would screw up this approach.

Note that I think this patch is the right idea, I just don't know if I need to 
account for the possibility that the channel that masquerades into pj123's 
dialing channel might not be in the neutral state.


Diffs
-

  /branches/12/main/stasis_channels.c 422882 

Diff: https://reviewboard.asterisk.org/r/3990/diff/


Testing
---

Ran against reproduction of the above scenario. Assertion was gone and the CDR 
results were as follows:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
 21:48:51,2014-09-11 21:48:53,2014-09-11 
21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
,123,,default, 
123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
 21:48:55,,2014-09-11 21:48:57,2,0,NO 
ANSWER,DOCUMENTATION,1410472135.6,
,1601,1603,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,

And dial events reported by AMI:
http://pastebin.com/tWuwL7xa
(note that there is a mismatch between the number of dial end and dial begin 
events... not sure if this is a problem, but I might be able to fix it just by 
updating the old chan, not sure what status code to use though).

Ran against normal attended transfer, feature attended transfers, and blind 
transfers with no noticeable effect.

Ran against testsuite blonde transfer tests, some attended transfer tests, some 
blind transfer tests, and all pjsip transfer tests (at least ones that will run 
on my box... a few won't due to sipp version requirements that I really need to 
get around to fixing eventually) for comparison purposes. All passed exhibiting 
the same behavior as before as far as warning messages and such go.


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] 3999: chan_iax2: Jitterbuffer causes crash in Asterisk 13 on account of format changes

[Jonathan Rose]

 On Sept. 18, 2014, 8:12 a.m., Joshua Colp wrote:
  /branches/13/channels/chan_iax2.c, line 4126
  https://reviewboard.asterisk.org/r/3999/diff/1/?file=67373#file67373line4126
 
  Despite it not changing behavior I'd still use 20 here to match 12.

Alright, fixed that. The only difference in the code is that 20 is there 
instead of 0, so I think I'll hold off on actually posting another review for 
now.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3999/#review13329
---


On Sept. 16, 2014, 4:28 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3999/
 ---
 
 (Updated Sept. 16, 2014, 4:28 p.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24265
 https://issues.asterisk.org/jira/browse/ASTERISK-24265
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This only occurs when the chan_iax jitterbuffer options are set and no when 
 setting jitterbuffers via diaplan or anything like that.
 
 The first time __get_from_jb is called, voiceformat has not been set on the 
 IAX pvt. Trying to call ast_format_get_default_ms on a NULL pointer fails. 
 This worked previously because Asterisk 12 and prior simply modified an 
 ast_format on the stack, so when it used ast_codec_interp_len on that format 
 pointer there was no possibility for it to be a NULL pointer... just one that 
 doesn't have a real format associated with it.
 
 One thing I might not be doing right here is that I'm using an interpolation 
 value of 0 for a NULL format. Previously Asterisk would just check to see if 
 the format was ILBC and if it was, return 30 and otherwise return 20... so it 
 might be more appropriate to use 20 instead of 0.  It doesn't appear to make 
 a difference for the sake of behavior.
 
 
 Diffs
 -
 
   /branches/13/channels/chan_iax2.c 423149 
 
 Diff: https://reviewboard.asterisk.org/r/3999/diff/
 
 
 Testing
 ---
 
 Ran basic call from a PJSIP peer to an IAX peer with the following:
 
 [general]
 
 ; The important parts
 jitterbuffer=yes
 forcejitterbuffer=yes
 
 
 [deskbox]
 type=friend
 requirecalltoken = no
 username = deskbox
 secret = secret
 host = dynamic
 transfer = no
 dtmfmode = auto
 encryption = no
 qualify = 300
 context = default
 disallow=all
 allow=ulaw
 allow=alaw
 ; Most of this is probably unnecessary for reproduction
 
 
 Without the patch this would crash in 13 but work fine in 12.
 With the patch, behavior strongly resembles 12 with the initial call into 
 __get_from_jb attempting to jb_get and getting JB_OK back and then later, 
 when the call was actually answered, the voice format would change and the 
 function would call again with the proper format and the jitterbuffer would 
 get started properly.
 
 
 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] 3995: res_pjsip_endpoint_identifier_ip: Can't parse identify with match value containing CIDR

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3995/
---

(Updated Sept. 18, 2014, 11:44 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Committed in revision 423417


Bugs: ASTERISK-24290
https://issues.asterisk.org/jira/browse/ASTERISK-24290


Repository: Asterisk


Description
---

Using a value such as '10.24.0.0/16' would fail to match because 
ast_sockaddr_resolve can only parse the following formats:

 * hostname:port
 * host.example.com:port
 * a.b.c.d
 * a.b.c.d:port
 * a:b:c:...:d
 * [a:b:c:...:d]
 * [a:b:c:...:d]:port

When the format doesn't match one of these, the function fails and we bail.

To get around this, I simply checked for the presence of a '/' in the identify 
string and used ast_append_ha directly with the address if it was present.


Diffs
-

  /branches/12/res/res_pjsip_endpoint_identifier_ip.c 423062 

Diff: https://reviewboard.asterisk.org/r/3995/diff/


Testing
---

Used CLI command 'pjsip show endpoint 1603' with an endpoint that had the 
following identifier:

[1603]
type=identify
match=10.24.18.13/16
endpoint=1603


Before, the address would fail to parse and the command would show no identifier
After, the address would parse correctly and show '10.24.0.0/16' for the 
identifier as seen in:

 Endpoint:  1603/1603Not in use
0 of inf
Aor:  1603   5
  Contact:  1603/sip:1603@10.24.18.13:5060;obUnknown
   nan
   Identify:  10.24.0.0/16

I tried a few other things, such as not using a CIDR and using a hostname to 
verify that there wasn't any obvious deviation in behavior introduced by the 
patch.


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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

 On Sept. 18, 2014, 12:22 p.m., Matt Jordan wrote:
  /branches/12/main/stasis_channels.c, line 383
  https://reviewboard.asterisk.org/r/3990/diff/3/?file=67394#file67394line383
 
  This will terminate the dial masquerade datastore on the first dial 
  completion message.
  
  Say I'm in a parallel dial. I've dialled Alice, Bob, and Charlie. I 
  complete the dial to Alice, and publish my message. That removes the 
  datastore.
  
  Can I be masqueraded out before I also complete the dial with Bob and 
  Charlie?

Good point.  Perhaps what I should be doing here is removing individual entries 
from the existing dialstore rather than removing it wholesale.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/#review13339
---


On Sept. 18, 2014, 10:59 a.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3990/
 ---
 
 (Updated Sept. 18, 2014, 10:59 a.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24237
 https://issues.asterisk.org/jira/browse/ASTERISK-24237
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Reproduction: 
 pj123 calls 1601
 pj123 does a SIP blonde transfer to 1603
 1603 answers
 FRACK occurs
 all are PJSIP endpoints.
 
 Basically what happens is there is a second outbound dial from another pj123 
 channel. Before the dial is answered, the pj123 gets masqueraded out of the 
 picture and replaced with a channel that isn't in the dial state.
 
 This patch fixes that by advancing the incoming channel to the dial state in 
 the channel breakdown function of a datastore on the pj123 channel. Honestly, 
 I'm not sure this is entirely adequate, but it seems to work in all of the 
 conditions I've tried so far and it doesn't impede normal attended transfers. 
 I might need to try and figure out what happens if I masquerade in a channel 
 that is already dialing though. I'm not sure if that's something we can 
 really expect to happen under normal conditions, but that seems like 
 something that would screw up this approach.
 
 Note that I think this patch is the right idea, I just don't know if I need 
 to account for the possibility that the channel that masquerades into pj123's 
 dialing channel might not be in the neutral state.
 
 
 Diffs
 -
 
   /branches/12/main/stasis_channels.c 422882 
 
 Diff: https://reviewboard.asterisk.org/r/3990/diff/
 
 
 Testing
 ---
 
 Ran against reproduction of the above scenario. Assertion was gone and the 
 CDR results were as follows:
 
 ,123,1601,default, 
 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
  21:48:51,2014-09-11 21:48:53,2014-09-11 
 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
 ,123,,default, 
 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
  21:48:55,,2014-09-11 21:48:57,2,0,NO 
 ANSWER,DOCUMENTATION,1410472135.6,
 ,1601,1603,default, 
 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
 Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,
 
 And dial events reported by AMI:
 http://pastebin.com/tWuwL7xa
 (note that there is a mismatch between the number of dial end and dial begin 
 events... not sure if this is a problem, but I might be able to fix it just 
 by updating the old chan, not sure what status code to use though).
 
 Ran against normal attended transfer, feature attended transfers, and blind 
 transfers with no noticeable effect.
 
 Ran against testsuite blonde transfer tests, some attended transfer tests, 
 some blind transfer tests, and all pjsip transfer tests (at least ones that 
 will run on my box... a few won't due to sipp version requirements that I 
 really need to get around to fixing eventually) for comparison purposes. All 
 passed exhibiting the same behavior as before as far as warning messages and 
 such go.
 
 
 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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

 On Sept. 18, 2014, 12:22 p.m., Matt Jordan wrote:
  /branches/12/main/stasis_channels.c, line 383
  https://reviewboard.asterisk.org/r/3990/diff/3/?file=67394#file67394line383
 
  This will terminate the dial masquerade datastore on the first dial 
  completion message.
  
  Say I'm in a parallel dial. I've dialled Alice, Bob, and Charlie. I 
  complete the dial to Alice, and publish my message. That removes the 
  datastore.
  
  Can I be masqueraded out before I also complete the dial with Bob and 
  Charlie?
 
 Jonathan Rose wrote:
 Good point.  Perhaps what I should be doing here is removing individual 
 entries from the existing dialstore rather than removing it wholesale.

I've checked through your suggested scenario with some added sleeps and it 
looks like what you've described is technically possible.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/#review13339
---


On Sept. 18, 2014, 10:59 a.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3990/
 ---
 
 (Updated Sept. 18, 2014, 10:59 a.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24237
 https://issues.asterisk.org/jira/browse/ASTERISK-24237
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Reproduction: 
 pj123 calls 1601
 pj123 does a SIP blonde transfer to 1603
 1603 answers
 FRACK occurs
 all are PJSIP endpoints.
 
 Basically what happens is there is a second outbound dial from another pj123 
 channel. Before the dial is answered, the pj123 gets masqueraded out of the 
 picture and replaced with a channel that isn't in the dial state.
 
 This patch fixes that by advancing the incoming channel to the dial state in 
 the channel breakdown function of a datastore on the pj123 channel. Honestly, 
 I'm not sure this is entirely adequate, but it seems to work in all of the 
 conditions I've tried so far and it doesn't impede normal attended transfers. 
 I might need to try and figure out what happens if I masquerade in a channel 
 that is already dialing though. I'm not sure if that's something we can 
 really expect to happen under normal conditions, but that seems like 
 something that would screw up this approach.
 
 Note that I think this patch is the right idea, I just don't know if I need 
 to account for the possibility that the channel that masquerades into pj123's 
 dialing channel might not be in the neutral state.
 
 
 Diffs
 -
 
   /branches/12/main/stasis_channels.c 422882 
 
 Diff: https://reviewboard.asterisk.org/r/3990/diff/
 
 
 Testing
 ---
 
 Ran against reproduction of the above scenario. Assertion was gone and the 
 CDR results were as follows:
 
 ,123,1601,default, 
 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
  21:48:51,2014-09-11 21:48:53,2014-09-11 
 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
 ,123,,default, 
 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
  21:48:55,,2014-09-11 21:48:57,2,0,NO 
 ANSWER,DOCUMENTATION,1410472135.6,
 ,1601,1603,default, 
 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
 Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,
 
 And dial events reported by AMI:
 http://pastebin.com/tWuwL7xa
 (note that there is a mismatch between the number of dial end and dial begin 
 events... not sure if this is a problem, but I might be able to fix it just 
 by updating the old chan, not sure what status code to use though).
 
 Ran against normal attended transfer, feature attended transfers, and blind 
 transfers with no noticeable effect.
 
 Ran against testsuite blonde transfer tests, some attended transfer tests, 
 some blind transfer tests, and all pjsip transfer tests (at least ones that 
 will run on my box... a few won't due to sipp version requirements that I 
 really need to get around to fixing eventually) for comparison purposes. All 
 passed exhibiting the same behavior as before as far as warning messages and 
 such go.
 
 
 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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
---

(Updated Sept. 18, 2014, 1:21 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Address mjordan's masquerade during parallel dial between events that happen 
with the canceled dial and the events that happen on the dial that stays alive. 
 It's kind of weird.

I addressed it by changing the function that was purging the datastore entirely 
to remove only items belonging to the same channel. Hopefully I didn't miss 
anything important.


Bugs: ASTERISK-24237
https://issues.asterisk.org/jira/browse/ASTERISK-24237


Repository: Asterisk


Description
---

Reproduction: 
pj123 calls 1601
pj123 does a SIP blonde transfer to 1603
1603 answers
FRACK occurs
all are PJSIP endpoints.

Basically what happens is there is a second outbound dial from another pj123 
channel. Before the dial is answered, the pj123 gets masqueraded out of the 
picture and replaced with a channel that isn't in the dial state.

This patch fixes that by advancing the incoming channel to the dial state in 
the channel breakdown function of a datastore on the pj123 channel. Honestly, 
I'm not sure this is entirely adequate, but it seems to work in all of the 
conditions I've tried so far and it doesn't impede normal attended transfers. I 
might need to try and figure out what happens if I masquerade in a channel that 
is already dialing though. I'm not sure if that's something we can really 
expect to happen under normal conditions, but that seems like something that 
would screw up this approach.

Note that I think this patch is the right idea, I just don't know if I need to 
account for the possibility that the channel that masquerades into pj123's 
dialing channel might not be in the neutral state.


Diffs (updated)
-

  /branches/12/main/stasis_channels.c 422882 

Diff: https://reviewboard.asterisk.org/r/3990/diff/


Testing
---

Ran against reproduction of the above scenario. Assertion was gone and the CDR 
results were as follows:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
 21:48:51,2014-09-11 21:48:53,2014-09-11 
21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
,123,,default, 
123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
 21:48:55,,2014-09-11 21:48:57,2,0,NO 
ANSWER,DOCUMENTATION,1410472135.6,
,1601,1603,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,

And dial events reported by AMI:
http://pastebin.com/tWuwL7xa
(note that there is a mismatch between the number of dial end and dial begin 
events... not sure if this is a problem, but I might be able to fix it just by 
updating the old chan, not sure what status code to use though).

Ran against normal attended transfer, feature attended transfers, and blind 
transfers with no noticeable effect.

Ran against testsuite blonde transfer tests, some attended transfer tests, some 
blind transfer tests, and all pjsip transfer tests (at least ones that will run 
on my box... a few won't due to sipp version requirements that I really need to 
get around to fixing eventually) for comparison purposes. All passed exhibiting 
the same behavior as before as far as warning messages and such go.


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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/#review13342
---



/branches/12/main/stasis_channels.c
https://reviewboard.asterisk.org/r/3990/#comment23819

Oops, I need a break here.


- Jonathan Rose


On Sept. 18, 2014, 1:21 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3990/
 ---
 
 (Updated Sept. 18, 2014, 1:21 p.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24237
 https://issues.asterisk.org/jira/browse/ASTERISK-24237
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Reproduction: 
 pj123 calls 1601
 pj123 does a SIP blonde transfer to 1603
 1603 answers
 FRACK occurs
 all are PJSIP endpoints.
 
 Basically what happens is there is a second outbound dial from another pj123 
 channel. Before the dial is answered, the pj123 gets masqueraded out of the 
 picture and replaced with a channel that isn't in the dial state.
 
 This patch fixes that by advancing the incoming channel to the dial state in 
 the channel breakdown function of a datastore on the pj123 channel. Honestly, 
 I'm not sure this is entirely adequate, but it seems to work in all of the 
 conditions I've tried so far and it doesn't impede normal attended transfers. 
 I might need to try and figure out what happens if I masquerade in a channel 
 that is already dialing though. I'm not sure if that's something we can 
 really expect to happen under normal conditions, but that seems like 
 something that would screw up this approach.
 
 Note that I think this patch is the right idea, I just don't know if I need 
 to account for the possibility that the channel that masquerades into pj123's 
 dialing channel might not be in the neutral state.
 
 
 Diffs
 -
 
   /branches/12/main/stasis_channels.c 422882 
 
 Diff: https://reviewboard.asterisk.org/r/3990/diff/
 
 
 Testing
 ---
 
 Ran against reproduction of the above scenario. Assertion was gone and the 
 CDR results were as follows:
 
 ,123,1601,default, 
 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
  21:48:51,2014-09-11 21:48:53,2014-09-11 
 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
 ,123,,default, 
 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
  21:48:55,,2014-09-11 21:48:57,2,0,NO 
 ANSWER,DOCUMENTATION,1410472135.6,
 ,1601,1603,default, 
 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
 Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,
 
 And dial events reported by AMI:
 http://pastebin.com/tWuwL7xa
 (note that there is a mismatch between the number of dial end and dial begin 
 events... not sure if this is a problem, but I might be able to fix it just 
 by updating the old chan, not sure what status code to use though).
 
 Ran against normal attended transfer, feature attended transfers, and blind 
 transfers with no noticeable effect.
 
 Ran against testsuite blonde transfer tests, some attended transfer tests, 
 some blind transfer tests, and all pjsip transfer tests (at least ones that 
 will run on my box... a few won't due to sipp version requirements that I 
 really need to get around to fixing eventually) for comparison purposes. All 
 passed exhibiting the same behavior as before as far as warning messages and 
 such go.
 
 
 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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
---

(Updated Sept. 18, 2014, 1:25 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Add a break in the function to remove an entry from the datastore.  I don't 
think it's possible to have the same channel in there for two separate events, 
but there's no sense in continuing to traverse past the found entry anyway.


Bugs: ASTERISK-24237
https://issues.asterisk.org/jira/browse/ASTERISK-24237


Repository: Asterisk


Description
---

Reproduction: 
pj123 calls 1601
pj123 does a SIP blonde transfer to 1603
1603 answers
FRACK occurs
all are PJSIP endpoints.

Basically what happens is there is a second outbound dial from another pj123 
channel. Before the dial is answered, the pj123 gets masqueraded out of the 
picture and replaced with a channel that isn't in the dial state.

This patch fixes that by advancing the incoming channel to the dial state in 
the channel breakdown function of a datastore on the pj123 channel. Honestly, 
I'm not sure this is entirely adequate, but it seems to work in all of the 
conditions I've tried so far and it doesn't impede normal attended transfers. I 
might need to try and figure out what happens if I masquerade in a channel that 
is already dialing though. I'm not sure if that's something we can really 
expect to happen under normal conditions, but that seems like something that 
would screw up this approach.

Note that I think this patch is the right idea, I just don't know if I need to 
account for the possibility that the channel that masquerades into pj123's 
dialing channel might not be in the neutral state.


Diffs (updated)
-

  /branches/12/main/stasis_channels.c 422882 

Diff: https://reviewboard.asterisk.org/r/3990/diff/


Testing
---

Ran against reproduction of the above scenario. Assertion was gone and the CDR 
results were as follows:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
 21:48:51,2014-09-11 21:48:53,2014-09-11 
21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
,123,,default, 
123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
 21:48:55,,2014-09-11 21:48:57,2,0,NO 
ANSWER,DOCUMENTATION,1410472135.6,
,1601,1603,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,

And dial events reported by AMI:
http://pastebin.com/tWuwL7xa
(note that there is a mismatch between the number of dial end and dial begin 
events... not sure if this is a problem, but I might be able to fix it just by 
updating the old chan, not sure what status code to use though).

Ran against normal attended transfer, feature attended transfers, and blind 
transfers with no noticeable effect.

Ran against testsuite blonde transfer tests, some attended transfer tests, some 
blind transfer tests, and all pjsip transfer tests (at least ones that will run 
on my box... a few won't due to sipp version requirements that I really need to 
get around to fixing eventually) for comparison purposes. All passed exhibiting 
the same behavior as before as far as warning messages and such go.


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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

 On Sept. 18, 2014, 3:10 p.m., rmudgett wrote:
  /branches/12/main/stasis_channels.c, line 1257
  https://reviewboard.asterisk.org/r/3990/diff/5/?file=67398#file67398line1257
 
  dial_masquerade() is called with several locks held: the global 
  channels lock, old_chan, and new_chan.
  
  The calls to ast_channel_publish_dial_forward() will then try to lock 
  cur-peer.
  
  I'm just noting this situation because locking more than one channel at 
  a time normally has a deadlock potential.  However, since the global 
  channels container lock is held it should be safe enough.


 On Sept. 18, 2014, 3:10 p.m., rmudgett wrote:
  /branches/12/main/stasis_channels.c, lines 381-394
  https://reviewboard.asterisk.org/r/3990/diff/5/?file=67398#file67398line381
 
  Why is the caller channel lock held for the 
  ast_channel_publish_dial_forward() call?
  
  A dead lock can happen holding the caller lock because 
  ast_channel_publish_dial_forward() locks caller and peer in turn.

Well, I want to keep the lock held in case a masquerade happens before I do 
ast_channel_publish_dial_forward... not sure how realistic such a scenario is, 
probably not very, but perhaps I should just do a lock_both here instead?


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/#review13345
---


On Sept. 18, 2014, 1:25 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3990/
 ---
 
 (Updated Sept. 18, 2014, 1:25 p.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24237
 https://issues.asterisk.org/jira/browse/ASTERISK-24237
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Reproduction: 
 pj123 calls 1601
 pj123 does a SIP blonde transfer to 1603
 1603 answers
 FRACK occurs
 all are PJSIP endpoints.
 
 Basically what happens is there is a second outbound dial from another pj123 
 channel. Before the dial is answered, the pj123 gets masqueraded out of the 
 picture and replaced with a channel that isn't in the dial state.
 
 This patch fixes that by advancing the incoming channel to the dial state in 
 the channel breakdown function of a datastore on the pj123 channel. Honestly, 
 I'm not sure this is entirely adequate, but it seems to work in all of the 
 conditions I've tried so far and it doesn't impede normal attended transfers. 
 I might need to try and figure out what happens if I masquerade in a channel 
 that is already dialing though. I'm not sure if that's something we can 
 really expect to happen under normal conditions, but that seems like 
 something that would screw up this approach.
 
 Note that I think this patch is the right idea, I just don't know if I need 
 to account for the possibility that the channel that masquerades into pj123's 
 dialing channel might not be in the neutral state.
 
 
 Diffs
 -
 
   /branches/12/main/stasis_channels.c 422882 
 
 Diff: https://reviewboard.asterisk.org/r/3990/diff/
 
 
 Testing
 ---
 
 Ran against reproduction of the above scenario. Assertion was gone and the 
 CDR results were as follows:
 
 ,123,1601,default, 
 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
  21:48:51,2014-09-11 21:48:53,2014-09-11 
 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
 ,123,,default, 
 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
  21:48:55,,2014-09-11 21:48:57,2,0,NO 
 ANSWER,DOCUMENTATION,1410472135.6,
 ,1601,1603,default, 
 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
 Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,
 
 And dial events reported by AMI:
 http://pastebin.com/tWuwL7xa
 (note that there is a mismatch between the number of dial end and dial begin 
 events... not sure if this is a problem, but I might be able to fix it just 
 by updating the old chan, not sure what status code to use though).
 
 Ran against normal attended transfer, feature attended transfers, and blind 
 transfers with no noticeable effect.
 
 Ran against testsuite blonde transfer tests, some attended transfer tests, 
 some blind transfer tests, and all pjsip transfer tests (at least ones that 
 will run on my box... a few won't due to sipp version requirements that I 
 really need to get around to fixing eventually) for comparison purposes. All 
 passed exhibiting the same behavior as before as far as warning messages and 
 such go.
 
 
 Thanks,
 
 Jonathan Rose
 


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev

Re: [asterisk-dev] [Code Review] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
---

(Updated Sept. 18, 2014, 4:48 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Hit rmudgett's findings.


Bugs: ASTERISK-24237
https://issues.asterisk.org/jira/browse/ASTERISK-24237


Repository: Asterisk


Description
---

Reproduction: 
pj123 calls 1601
pj123 does a SIP blonde transfer to 1603
1603 answers
FRACK occurs
all are PJSIP endpoints.

Basically what happens is there is a second outbound dial from another pj123 
channel. Before the dial is answered, the pj123 gets masqueraded out of the 
picture and replaced with a channel that isn't in the dial state.

This patch fixes that by advancing the incoming channel to the dial state in 
the channel breakdown function of a datastore on the pj123 channel. Honestly, 
I'm not sure this is entirely adequate, but it seems to work in all of the 
conditions I've tried so far and it doesn't impede normal attended transfers. I 
might need to try and figure out what happens if I masquerade in a channel that 
is already dialing though. I'm not sure if that's something we can really 
expect to happen under normal conditions, but that seems like something that 
would screw up this approach.

Note that I think this patch is the right idea, I just don't know if I need to 
account for the possibility that the channel that masquerades into pj123's 
dialing channel might not be in the neutral state.


Diffs (updated)
-

  /branches/12/main/stasis_channels.c 422882 

Diff: https://reviewboard.asterisk.org/r/3990/diff/


Testing
---

Ran against reproduction of the above scenario. Assertion was gone and the CDR 
results were as follows:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
 21:48:51,2014-09-11 21:48:53,2014-09-11 
21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
,123,,default, 
123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
 21:48:55,,2014-09-11 21:48:57,2,0,NO 
ANSWER,DOCUMENTATION,1410472135.6,
,1601,1603,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,

And dial events reported by AMI:
http://pastebin.com/tWuwL7xa
(note that there is a mismatch between the number of dial end and dial begin 
events... not sure if this is a problem, but I might be able to fix it just by 
updating the old chan, not sure what status code to use though).

Ran against normal attended transfer, feature attended transfers, and blind 
transfers with no noticeable effect.

Ran against testsuite blonde transfer tests, some attended transfer tests, some 
blind transfer tests, and all pjsip transfer tests (at least ones that will run 
on my box... a few won't due to sipp version requirements that I really need to 
get around to fixing eventually) for comparison purposes. All passed exhibiting 
the same behavior as before as far as warning messages and such go.


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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
---

(Updated Sept. 18, 2014, 5:50 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Fix reference leak rmudgett pointed out.


Bugs: ASTERISK-24237
https://issues.asterisk.org/jira/browse/ASTERISK-24237


Repository: Asterisk


Description
---

Reproduction: 
pj123 calls 1601
pj123 does a SIP blonde transfer to 1603
1603 answers
FRACK occurs
all are PJSIP endpoints.

Basically what happens is there is a second outbound dial from another pj123 
channel. Before the dial is answered, the pj123 gets masqueraded out of the 
picture and replaced with a channel that isn't in the dial state.

This patch fixes that by advancing the incoming channel to the dial state in 
the channel breakdown function of a datastore on the pj123 channel. Honestly, 
I'm not sure this is entirely adequate, but it seems to work in all of the 
conditions I've tried so far and it doesn't impede normal attended transfers. I 
might need to try and figure out what happens if I masquerade in a channel that 
is already dialing though. I'm not sure if that's something we can really 
expect to happen under normal conditions, but that seems like something that 
would screw up this approach.

Note that I think this patch is the right idea, I just don't know if I need to 
account for the possibility that the channel that masquerades into pj123's 
dialing channel might not be in the neutral state.


Diffs (updated)
-

  /branches/12/main/stasis_channels.c 422882 

Diff: https://reviewboard.asterisk.org/r/3990/diff/


Testing
---

Ran against reproduction of the above scenario. Assertion was gone and the CDR 
results were as follows:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
 21:48:51,2014-09-11 21:48:53,2014-09-11 
21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
,123,,default, 
123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
 21:48:55,,2014-09-11 21:48:57,2,0,NO 
ANSWER,DOCUMENTATION,1410472135.6,
,1601,1603,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,

And dial events reported by AMI:
http://pastebin.com/tWuwL7xa
(note that there is a mismatch between the number of dial end and dial begin 
events... not sure if this is a problem, but I might be able to fix it just by 
updating the old chan, not sure what status code to use though).

Ran against normal attended transfer, feature attended transfers, and blind 
transfers with no noticeable effect.

Ran against testsuite blonde transfer tests, some attended transfer tests, some 
blind transfer tests, and all pjsip transfer tests (at least ones that will run 
on my box... a few won't due to sipp version requirements that I really need to 
get around to fixing eventually) for comparison purposes. All passed exhibiting 
the same behavior as before as far as warning messages and such go.


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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

 On Sept. 16, 2014, 12:21 p.m., Matt Jordan wrote:
  /branches/12/main/dial.c, lines 1312-1316
  https://reviewboard.asterisk.org/r/3990/diff/1/?file=67328#file67328line1312
 
  Instead of setting the consume flag, remove the datastore and free it:
  
  if (!ast_channel_datastore_remove(old_chan, ds)) {
  ast_datastore_free(ds);
  }
  
  Note that it is safe to do that here, as the list traversal in 
  channel.c assumes that this can occur.
  
  That also removes the need for de-refing the peer_chan here, as your 
  destructor will take care of it for you.

Unfortunately, ds is a pointer to a datastore's data and not to the data 
itself. I'll go ahead and rename the variable to make that clearer.  In the 
meantime I guess I could try to fetch the datastore in the normal manner and 
destroy it that way.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/#review13312
---


On Sept. 11, 2014, 4:59 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3990/
 ---
 
 (Updated Sept. 11, 2014, 4:59 p.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24237
 https://issues.asterisk.org/jira/browse/ASTERISK-24237
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Reproduction: 
 pj123 calls 1601
 pj123 does a SIP blonde transfer to 1603
 1603 answers
 FRACK occurs
 all are PJSIP endpoints.
 
 Basically what happens is there is a second outbound dial from another pj123 
 channel. Before the dial is answered, the pj123 gets masqueraded out of the 
 picture and replaced with a channel that isn't in the dial state.
 
 This patch fixes that by advancing the incoming channel to the dial state in 
 the channel breakdown function of a datastore on the pj123 channel. Honestly, 
 I'm not sure this is entirely adequate, but it seems to work in all of the 
 conditions I've tried so far and it doesn't impede normal attended transfers. 
 I might need to try and figure out what happens if I masquerade in a channel 
 that is already dialing though. I'm not sure if that's something we can 
 really expect to happen under normal conditions, but that seems like 
 something that would screw up this approach.
 
 Note that I think this patch is the right idea, I just don't know if I need 
 to account for the possibility that the channel that masquerades into pj123's 
 dialing channel might not be in the neutral state.
 
 
 Diffs
 -
 
   /branches/12/main/stasis_channels.c 422882 
   /branches/12/main/dial.c 422882 
   /branches/12/include/asterisk/dial.h 422882 
 
 Diff: https://reviewboard.asterisk.org/r/3990/diff/
 
 
 Testing
 ---
 
 Ran against reproduction of the above scenario. Assertion was gone and the 
 CDR results were as follows:
 
 ,123,1601,default, 
 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
  21:48:51,2014-09-11 21:48:53,2014-09-11 
 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
 ,123,,default, 
 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
  21:48:55,,2014-09-11 21:48:57,2,0,NO 
 ANSWER,DOCUMENTATION,1410472135.6,
 ,1601,1603,default, 
 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
 Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,
 
 And dial events reported by AMI:
 http://pastebin.com/tWuwL7xa
 (note that there is a mismatch between the number of dial end and dial begin 
 events... not sure if this is a problem, but I might be able to fix it just 
 by updating the old chan, not sure what status code to use though).
 
 Ran against normal attended transfer, feature attended transfers, and blind 
 transfers with no noticeable effect.
 
 Ran against testsuite blonde transfer tests, some attended transfer tests, 
 some blind transfer tests, and all pjsip transfer tests (at least ones that 
 will run on my box... a few won't due to sipp version requirements that I 
 really need to get around to fixing eventually) for comparison purposes. All 
 passed exhibiting the same behavior as before as far as warning messages and 
 such go.
 
 
 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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

 On Sept. 16, 2014, 12:21 p.m., Matt Jordan wrote:
  /branches/12/main/dial.c, line 1320
  https://reviewboard.asterisk.org/r/3990/diff/1/?file=67328#file67328line1320
 
  Remember that some things are going to want to do a string comparison 
  against the type name. Use a more reasonable string name.
  
  Also: CDRs are a bad name here. You aren't doing this just for CDRs - 
  you're doing it so that Stasis preserves a sane view of the world for all 
  of its message consumers. CDRs just happens to be the noisiest consumer.

I've gone with 'stasis-chan-dial-masq', but I'm not sure if that's adequately 
descriptive.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/#review13312
---


On Sept. 11, 2014, 4:59 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3990/
 ---
 
 (Updated Sept. 11, 2014, 4:59 p.m.)
 
 
 Review request for Asterisk Developers, Matt Jordan and rmudgett.
 
 
 Bugs: ASTERISK-24237
 https://issues.asterisk.org/jira/browse/ASTERISK-24237
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Reproduction: 
 pj123 calls 1601
 pj123 does a SIP blonde transfer to 1603
 1603 answers
 FRACK occurs
 all are PJSIP endpoints.
 
 Basically what happens is there is a second outbound dial from another pj123 
 channel. Before the dial is answered, the pj123 gets masqueraded out of the 
 picture and replaced with a channel that isn't in the dial state.
 
 This patch fixes that by advancing the incoming channel to the dial state in 
 the channel breakdown function of a datastore on the pj123 channel. Honestly, 
 I'm not sure this is entirely adequate, but it seems to work in all of the 
 conditions I've tried so far and it doesn't impede normal attended transfers. 
 I might need to try and figure out what happens if I masquerade in a channel 
 that is already dialing though. I'm not sure if that's something we can 
 really expect to happen under normal conditions, but that seems like 
 something that would screw up this approach.
 
 Note that I think this patch is the right idea, I just don't know if I need 
 to account for the possibility that the channel that masquerades into pj123's 
 dialing channel might not be in the neutral state.
 
 
 Diffs
 -
 
   /branches/12/main/stasis_channels.c 422882 
   /branches/12/main/dial.c 422882 
   /branches/12/include/asterisk/dial.h 422882 
 
 Diff: https://reviewboard.asterisk.org/r/3990/diff/
 
 
 Testing
 ---
 
 Ran against reproduction of the above scenario. Assertion was gone and the 
 CDR results were as follows:
 
 ,123,1601,default, 
 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
  21:48:51,2014-09-11 21:48:53,2014-09-11 
 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
 ,123,,default, 
 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
  21:48:55,,2014-09-11 21:48:57,2,0,NO 
 ANSWER,DOCUMENTATION,1410472135.6,
 ,1601,1603,default, 
 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
 Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,
 
 And dial events reported by AMI:
 http://pastebin.com/tWuwL7xa
 (note that there is a mismatch between the number of dial end and dial begin 
 events... not sure if this is a problem, but I might be able to fix it just 
 by updating the old chan, not sure what status code to use though).
 
 Ran against normal attended transfer, feature attended transfers, and blind 
 transfers with no noticeable effect.
 
 Ran against testsuite blonde transfer tests, some attended transfer tests, 
 some blind transfer tests, and all pjsip transfer tests (at least ones that 
 will run on my box... a few won't due to sipp version requirements that I 
 really need to get around to fixing eventually) for comparison purposes. All 
 passed exhibiting the same behavior as before as far as warning messages and 
 such go.
 
 
 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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
---

(Updated Sept. 17, 2014, 12:57 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
---

Attempt to do things the way mjordan suggested.

Here's a CDR log for a blonde transfer to a parallel dial too:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-17
 17:54:37,2014-09-17 17:54:38,2014-09-17 
17:54:44,7,5,ANSWERED,DOCUMENTATION,1410976477.0,
,1601,1604,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-17 17:54:44,2014-09-17 17:54:44,2014-09-17 
17:54:48,4,4,NO ANSWER,DOCUMENTATION,1410976477.1,
,1601,1604,default, 
1601,PJSIP/1601-0001,Local/1604_2@default-;1,AppDial,(Outgoing
 Line),2014-09-17 17:54:44,2014-09-17 17:54:44,2014-09-17 
17:54:53,8,8,ANSWERED,DOCUMENTATION,1410976477.1,
,123,1604_2,default, 
123,Local/1604_2@default-;2,,Playback,tt-weasels,2014-09-17 
17:54:43,2014-09-17 17:54:48,2014-09-17 
17:54:53,9,4,ANSWERED,DOCUMENTATION,1410976483.8,
,1601,1604,default, 
1601,PJSIP/pj123-0002,Local/1604_2@default-;1,Dial,LOCAL/1604_2@defaultPJSIP/1603,,tT,2014-09-17
 17:54:43,,2014-09-17 17:54:44,0,0,NO 
ANSWER,DOCUMENTATION,1410976483.6,
,1601,1604,default, 
1601,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,LOCAL/1604_2@defaultPJSIP/1603,,tT,2014-09-17
 17:54:43,,2014-09-17 17:54:44,0,0,NO 
ANSWER,DOCUMENTATION,1410976483.6,

In this case, the local channel picked up first.


Bugs: ASTERISK-24237
https://issues.asterisk.org/jira/browse/ASTERISK-24237


Repository: Asterisk


Description
---

Reproduction: 
pj123 calls 1601
pj123 does a SIP blonde transfer to 1603
1603 answers
FRACK occurs
all are PJSIP endpoints.

Basically what happens is there is a second outbound dial from another pj123 
channel. Before the dial is answered, the pj123 gets masqueraded out of the 
picture and replaced with a channel that isn't in the dial state.

This patch fixes that by advancing the incoming channel to the dial state in 
the channel breakdown function of a datastore on the pj123 channel. Honestly, 
I'm not sure this is entirely adequate, but it seems to work in all of the 
conditions I've tried so far and it doesn't impede normal attended transfers. I 
might need to try and figure out what happens if I masquerade in a channel that 
is already dialing though. I'm not sure if that's something we can really 
expect to happen under normal conditions, but that seems like something that 
would screw up this approach.

Note that I think this patch is the right idea, I just don't know if I need to 
account for the possibility that the channel that masquerades into pj123's 
dialing channel might not be in the neutral state.


Diffs (updated)
-

  /branches/12/main/stasis_channels.c 422882 

Diff: https://reviewboard.asterisk.org/r/3990/diff/


Testing
---

Ran against reproduction of the above scenario. Assertion was gone and the CDR 
results were as follows:

,123,1601,default, 
123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11
 21:48:51,2014-09-11 21:48:53,2014-09-11 
21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0,
,123,,default, 
123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11
 21:48:55,,2014-09-11 21:48:57,2,0,NO 
ANSWER,DOCUMENTATION,1410472135.6,
,1601,1603,default, 
1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing 
Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 
21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1,

And dial events reported by AMI:
http://pastebin.com/tWuwL7xa
(note that there is a mismatch between the number of dial end and dial begin 
events... not sure if this is a problem, but I might be able to fix it just by 
updating the old chan, not sure what status code to use though).

Ran against normal attended transfer, feature attended transfers, and blind 
transfers with no noticeable effect.

Ran against testsuite blonde transfer tests, some attended transfer tests, some 
blind transfer tests, and all pjsip transfer tests (at least ones that will run 
on my box... a few won't due to sipp version requirements that I really need to 
get around to fixing eventually) for comparison purposes. All passed exhibiting 
the same behavior as before as far as warning messages and such go.


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] 3995: res_pjsip_endpoint_identifier_ip: Can't parse identify with match value containing CIDR

[Jonathan Rose]

 On Sept. 16, 2014, 1:16 p.m., Scott Griepentrog wrote:
  /branches/12/res/res_pjsip_endpoint_identifier_ip.c, lines 162-166
  https://reviewboard.asterisk.org/r/3995/diff/1/?file=67358#file67358line162
 
  The implementation of ast_append_ha supports comma separated values, 
  but pjsip.conf.sample doesn't clearly indicate support nor lack of support 
  for commas, although it does show examples of multiple match lines to 
  accomplish the same thing.
  
  Assuming that we are expressly not going to support something like this:
  
  match=sip.example.com,1.2.3.4/10
  
  Then this code is fine, otherwise would need to be reworked to parse 
  the , values out first.
 

Personally, I feel inclined to either not allow commas in the case of the 
example you mentioned or else perform comma separation while parsing the config 
rather than allow ast_apply_ha handle it. Right now if that were used I think 
it would fail since ast_apply_ha doesn't do host name matching... and otherwise 
we'd have an issue when people try to use comma separation with anything other 
than a collection of host addresses with at least one of them containing the 
CIDR pattern.

I'll defer that decision to someone else though. Neither is particularly 
difficult to implement, I'm just not sure which is preferred.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3995/#review13315
---


On Sept. 15, 2014, 1:52 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3995/
 ---
 
 (Updated Sept. 15, 2014, 1:52 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24290
 https://issues.asterisk.org/jira/browse/ASTERISK-24290
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Using a value such as '10.24.0.0/16' would fail to match because 
 ast_sockaddr_resolve can only parse the following formats:
 
  * hostname:port
  * host.example.com:port
  * a.b.c.d
  * a.b.c.d:port
  * a:b:c:...:d
  * [a:b:c:...:d]
  * [a:b:c:...:d]:port
 
 When the format doesn't match one of these, the function fails and we bail.
 
 To get around this, I simply checked for the presence of a '/' in the 
 identify string and used ast_append_ha directly with the address if it was 
 present.
 
 
 Diffs
 -
 
   /branches/12/res/res_pjsip_endpoint_identifier_ip.c 423062 
 
 Diff: https://reviewboard.asterisk.org/r/3995/diff/
 
 
 Testing
 ---
 
 Used CLI command 'pjsip show endpoint 1603' with an endpoint that had the 
 following identifier:
 
 [1603]
 type=identify
 match=10.24.18.13/16
 endpoint=1603
 
 
 Before, the address would fail to parse and the command would show no 
 identifier
 After, the address would parse correctly and show '10.24.0.0/16' for the 
 identifier as seen in:
 
  Endpoint:  1603/1603Not in use   
  0 of inf
 Aor:  1603   5
   Contact:  1603/sip:1603@10.24.18.13:5060;obUnknown  
  nan
Identify:  10.24.0.0/16
 
 I tried a few other things, such as not using a CIDR and using a hostname to 
 verify that there wasn't any obvious deviation in behavior introduced by the 
 patch.
 
 
 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] 3995: res_pjsip_endpoint_identifier_ip: Can't parse identify with match value containing CIDR

[Jonathan Rose]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3995/
---

(Updated Sept. 17, 2014, 5:29 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Added comma separation support to ip_identify_match_handler.

For a test, I did the following:
[1603]
type=identify
match=10.24.18.13/16,10.26.18.13/16,www.example.com
endpoint=1603

and got:

 Endpoint:  1603/1603Unavailable   
0 of inf
Aor:  1603   5
   Identify:  
10.24.0.0/16,10.26.0.0/16,93.184.216.119/32,2606:2800:220:6d:26bf:1447:1097:aa7/128


in my pjsip show endpoint output


Bugs: ASTERISK-24290
https://issues.asterisk.org/jira/browse/ASTERISK-24290


Repository: Asterisk


Description
---

Using a value such as '10.24.0.0/16' would fail to match because 
ast_sockaddr_resolve can only parse the following formats:

 * hostname:port
 * host.example.com:port
 * a.b.c.d
 * a.b.c.d:port
 * a:b:c:...:d
 * [a:b:c:...:d]
 * [a:b:c:...:d]:port

When the format doesn't match one of these, the function fails and we bail.

To get around this, I simply checked for the presence of a '/' in the identify 
string and used ast_append_ha directly with the address if it was present.


Diffs (updated)
-

  /branches/12/res/res_pjsip_endpoint_identifier_ip.c 423062 

Diff: https://reviewboard.asterisk.org/r/3995/diff/


Testing
---

Used CLI command 'pjsip show endpoint 1603' with an endpoint that had the 
following identifier:

[1603]
type=identify
match=10.24.18.13/16
endpoint=1603


Before, the address would fail to parse and the command would show no identifier
After, the address would parse correctly and show '10.24.0.0/16' for the 
identifier as seen in:

 Endpoint:  1603/1603Not in use
0 of inf
Aor:  1603   5
  Contact:  1603/sip:1603@10.24.18.13:5060;obUnknown
   nan
   Identify:  10.24.0.0/16

I tried a few other things, such as not using a CIDR and using a hostname to 
verify that there wasn't any obvious deviation in behavior introduced by the 
patch.


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