Re: [asterisk-dev] ISDN UDI Call with Dial command

[Pawel Pastuszak]

Thanks you for the response, and the reason i ask here is because I need an
developer answer. Say this is the an way to set the caller id information
on an originate with out patching chan_dahdi to accept an environment
variable to switch to an UDI call.

Thanks,
Pawel


On Thu, May 8, 2014 at 7:17 PM, Richard Mudgett  wrote:

>
>
>
> On Thu, May 8, 2014 at 5:29 PM, Pawel Pastuszak 
> wrote:
>
>> Hello,
>>
>>
>> I have notice that if i uses Dial(DAHDI/g1d/1234) the d option doesn't get 
>> to chan_dahi but if i uses originate with d option i see the UDI call but 
>> not with dial can some help why is this?
>>
>>
>> Example of the originate
>>
>> channel originate dahdi/g1d/$number3 extension s@udi
>>
>>
>>
>> Example of my dialplan
>>
>> [udicall]
>>
>> exten => _XX.,1,Set(CALLERID(num)=1244)
>>
>> exten => _XX.,n,Dial(Dahdi/g1d/1234)
>>
>>
>> My call is to set the callerid on an Data Call (UDI).
>>
>>
> The 'd' option is very esoteric.  Its purpose is for use with originated
> calls
> because that is the only place where an originated call can specify that
> the outgoing call legs need digital transfer capability.
>
> Using the Dial application is going to get the 'd' option overridden by the
> calling channel executing the application because the transfer capability
> of the outgoing channel must match the incoming channel executing the
> Dial application.
>
> This question should have been asked on the asterisk-users list as it
> has nothing to do with the development of Asterisk itself.
>
> Richard
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] [Code Review] 3477: Japanese language patch for app_voicemail.c and say.c

[Kevin McCoy]

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

(Updated May 9, 2014, 3:36 a.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Created new review request with proper diffs. Japanese language support patch 
for sound files in app_voicemail.c and say.c, depends on entire sound file 
package currently available in release candidate format as per 
https://issues.asterisk.org/jira/browse/ASTERISK-23324
https://www.dropbox.com/s/axu6gfnf9fh40hz/asterisk-core-sounds-ja-wav-and-patch.tgz

Word order and plurals, dates, counts in Japanese are all significantly 
different than English, hence the need for this patch. Tested working with 
Asterisk 12.

Here is the installation procedure from the README contained in the RC archive:

--


Install Asterisk Sound Files:
mkdir /var/lib/asterisk/sounds/ja 
cd /var/lib/asterisk/sounds/ja 
wget 
http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-ja-gsm-current.tar.gz
 
tar xvfz asterisk-core-sounds-ja-gsm-current.tar.gz 
rm -f asterisk-core-sounds-ja-gsm-current.tar.gz 
chown -R asterisk.asterisk /var/lib/asterisk/sounds/ja

How To Change Default SIP Channel Language to Japanese

Using Asterisk (vanilla):
vi /etc/asterisk/sip.conf
Edit language variable to:
language = ja

Using FreePBX:
On the FreePBX menu -> Settings -> Asterisk SIP Settings -> Advanced General 
Settings section -> Language field 
Set Language field to : ja

Install Japanese Patch:
Download Asterisk 12 source
Change directory to Asterisk 12 source folder
Download the patches for say.c and app_voicemail.c
patch -p0 < say.c.20140226.jp.patch
patch -p0 < app_voicemail.c.20140226.jp.patch
Compile Asterisk 12 source as usual


--

I'm happy to answer questions about the code.


Diffs (updated)
-

  /trunk/main/say.c 413007 
  /trunk/apps/app_voicemail.c 413007 

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


Testing
---

Fixed code with diff r2 as requested. Please double check and give feedback.


Thanks,

Kevin McCoy

-- 
_
-- 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] 3477: Japanese language patch for app_voicemail.c and say.c

[Kevin McCoy]

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

(Updated May 9, 2014, 3:30 a.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Created new review request with proper diffs. Japanese language support patch 
for sound files in app_voicemail.c and say.c, depends on entire sound file 
package currently available in release candidate format as per 
https://issues.asterisk.org/jira/browse/ASTERISK-23324
https://www.dropbox.com/s/axu6gfnf9fh40hz/asterisk-core-sounds-ja-wav-and-patch.tgz

Word order and plurals, dates, counts in Japanese are all significantly 
different than English, hence the need for this patch. Tested working with 
Asterisk 12.

Here is the installation procedure from the README contained in the RC archive:

--


Install Asterisk Sound Files:
mkdir /var/lib/asterisk/sounds/ja 
cd /var/lib/asterisk/sounds/ja 
wget 
http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-ja-gsm-current.tar.gz
 
tar xvfz asterisk-core-sounds-ja-gsm-current.tar.gz 
rm -f asterisk-core-sounds-ja-gsm-current.tar.gz 
chown -R asterisk.asterisk /var/lib/asterisk/sounds/ja

How To Change Default SIP Channel Language to Japanese

Using Asterisk (vanilla):
vi /etc/asterisk/sip.conf
Edit language variable to:
language = ja

Using FreePBX:
On the FreePBX menu -> Settings -> Asterisk SIP Settings -> Advanced General 
Settings section -> Language field 
Set Language field to : ja

Install Japanese Patch:
Download Asterisk 12 source
Change directory to Asterisk 12 source folder
Download the patches for say.c and app_voicemail.c
patch -p0 < say.c.20140226.jp.patch
patch -p0 < app_voicemail.c.20140226.jp.patch
Compile Asterisk 12 source as usual


--

I'm happy to answer questions about the code.


Diffs (updated)
-

  /trunk/main/say.c 413007 
  /trunk/apps/app_voicemail.c 413007 

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


Testing
---

Fixed code with diff r2 as requested. Please double check and give feedback.


Thanks,

Kevin McCoy

-- 
_
-- 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] ISDN UDI Call with Dial command

[Richard Mudgett]

On Thu, May 8, 2014 at 5:29 PM, Pawel Pastuszak wrote:

> Hello,
>
>
> I have notice that if i uses Dial(DAHDI/g1d/1234) the d option doesn't get to 
> chan_dahi but if i uses originate with d option i see the UDI call but not 
> with dial can some help why is this?
>
>
> Example of the originate
>
> channel originate dahdi/g1d/$number3 extension s@udi
>
>
>
> Example of my dialplan
>
> [udicall]
>
> exten => _XX.,1,Set(CALLERID(num)=1244)
>
> exten => _XX.,n,Dial(Dahdi/g1d/1234)
>
>
> My call is to set the callerid on an Data Call (UDI).
>
>
The 'd' option is very esoteric.  Its purpose is for use with originated
calls
because that is the only place where an originated call can specify that
the outgoing call legs need digital transfer capability.

Using the Dial application is going to get the 'd' option overridden by the
calling channel executing the application because the transfer capability
of the outgoing channel must match the incoming channel executing the
Dial application.

This question should have been asked on the asterisk-users list as it
has nothing to do with the development of Asterisk itself.

Richard
-- 
_
-- 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] ISDN UDI Call with Dial command

[Pawel Pastuszak]

Hello,


I have notice that if i uses Dial(DAHDI/g1d/1234) the d option doesn't
get to chan_dahi but if i uses originate with d option i see the UDI
call but not with dial can some help why is this?


Example of the originate

channel originate dahdi/g1d/$number3 extension s@udi



Example of my dialplan

[udicall]

exten => _XX.,1,Set(CALLERID(num)=1244)

exten => _XX.,n,Dial(Dahdi/g1d/1234)


My call is to set the callerid on an Data Call (UDI).


Thanks,

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

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

Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges

[Jonathan Rose]

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

(Updated May 8, 2014, 5:09 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 5026


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


Repository: testsuite


Description
---

The YAML files have pretty apt descriptions.

Channel version:
* Originate a channel
* Playback a tone
* Pause it
* Unpause it
* Restart it
* Delete the tone playback
* Delete the channel
* Validate all the events

Bridge version:
* Originate a channel
* Create a bridge
* Add the channel to the bridge
* Start a tone playback on the bridge
* Delete the tone playback
* Delete the channel
* Validate all the events


Diffs
-

  
/asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/playback/tones/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/playback/tones/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 
  /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py 
PRE-CREATION 
  /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 

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


Testing
---

Ran tests, varied results, the usual.  They aren't especially changed from the 
tests they are based on (in each case there is an existing baseline test in the 
same folder which handles sounds).


Thanks,

Jonathan Rose

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

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

Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges

[Jonathan Rose]

> On May 8, 2014, 3:14 p.m., Mark Michelson wrote:
> > /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py, line 
> > 16
> > 
> >
> > Does this instance variable get used anywhere?

Should have been channel_id. It ends up not mattering too much since on_start 
writes the variable into TEST, but yeah, definitely should correct that.


- Jonathan


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


On May 7, 2014, 1:58 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3428/
> ---
> 
> (Updated May 7, 2014, 1:58 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23433
> https://issues.asterisk.org/jira/browse/ASTERISK-23433
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> The YAML files have pretty apt descriptions.
> 
> Channel version:
> * Originate a channel
> * Playback a tone
> * Pause it
> * Unpause it
> * Restart it
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> Bridge version:
> * Originate a channel
> * Create a bridge
> * Add the channel to the bridge
> * Start a tone playback on the bridge
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> 
> Diffs
> -
> 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 
> 
> Diff: https://reviewboard.asterisk.org/r/3428/diff/
> 
> 
> Testing
> ---
> 
> Ran tests, varied results, the usual.  They aren't especially changed from 
> the tests they are based on (in each case there is an existing baseline test 
> in the same folder which handles sounds).
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges

[Scott Griepentrog]

> On May 6, 2014, 1:57 p.m., opticron wrote:
> > /asterisk/trunk/tests/rest_api/channels/playback/tones/test-config.yaml, 
> > lines 39-43
> > 
> >
> > Are these channel state changes important to the test? There doesn't 
> > seem to be much detail here.
> 
> Jonathan Rose wrote:
> I don't think so, but they were present in the existing channel playback 
> test (which was just for sounds).

They are not important to the test, but were an attempt to not have any events 
logged as not matching.


- Scott


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


On May 7, 2014, 1:58 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3428/
> ---
> 
> (Updated May 7, 2014, 1:58 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23433
> https://issues.asterisk.org/jira/browse/ASTERISK-23433
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> The YAML files have pretty apt descriptions.
> 
> Channel version:
> * Originate a channel
> * Playback a tone
> * Pause it
> * Unpause it
> * Restart it
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> Bridge version:
> * Originate a channel
> * Create a bridge
> * Add the channel to the bridge
> * Start a tone playback on the bridge
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> 
> Diffs
> -
> 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 
> 
> Diff: https://reviewboard.asterisk.org/r/3428/diff/
> 
> 
> Testing
> ---
> 
> Ran tests, varied results, the usual.  They aren't especially changed from 
> the tests they are based on (in each case there is an existing baseline test 
> in the same folder which handles sounds).
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang

[Jonathan Rose]

> On May 8, 2014, 3:22 p.m., Joshua Colp wrote:
> > /branches/12/res/res_pjsip_refer.c, lines 185-193
> > 
> >
> > I need time to grok your other changes and the possible repercussions 
> > but I'll comment on this right now. Would this get called twice since the 
> > framehook is invoked when detached?
> 
> Jonathan Rose wrote:
> Yep, it's hitting it twice.  Guess I need to make sure it doesn't push a 
> second notify.

I'm not sure if this is the proper and elegant way to do this, but I just added 
a check for if the event value is AST_FRAMEHOOK_EVENT_DETACHED and if it is, 
I'm returning early right now.  It fixes the behavior, but it might be cleaner 
if I just put the whole thing in as a check for if the event type is ATTACHED 
seeing as this is to handle hangups prior to actually attaching the frame hook 
and all.


- Jonathan


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


On May 8, 2014, 12:40 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3485/
> ---
> 
> (Updated May 8, 2014, 12:40 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and Mark Michelson.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> If a PJSIP endpoint attempts to blind transfer to a parking extension, there 
> is an override to the normal transfer logic that can make things act a little 
> weird. We noticed that this would leave various phones hanging on transfer 
> screens without progressing. When the transfer was considered successful, 
> PJSIP deferred the actual action of sending the 200 notify and the actual 
> trigger for that happening never occurs when the transfer is to a parking 
> extension.
> 
> In order to handle this, the bridge function that handles blind transfers now 
> returns a different value if a call was parked and if the channel driver 
> needs to react differently in this case, it can.  In the case of PJSIP, we 
> respond to transfers to park by immediately sending the notify with 200 OK 
> sip frag instead of deferring the action.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 413303 
>   /branches/12/res/parking/parking_bridge_features.c 413303 
>   /branches/12/res/parking/parking_applications.c 413303 
>   /branches/12/main/parking.c 413303 
>   /branches/12/main/bridge.c 413303 
>   /branches/12/include/asterisk/parking.h 413303 
>   /branches/12/channels/sig_analog.c 413303 
>   /branches/12/channels/chan_sip.c 413303 
>   /branches/12/channels/chan_mgcp.c 413303 
>   /branches/12/channels/chan_dahdi.c 413303 
> 
> Diff: https://reviewboard.asterisk.org/r/3485/diff/
> 
> 
> Testing
> ---
> 
> Before patch:
> * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until 
> it either manually hangs up or 60 seconds pass and Asterisk terminates the 
> session.
> 
> After the patch:
> * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer 
> screen and goes back to idle mode.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang

[Jonathan Rose]

> On May 8, 2014, 3:22 p.m., Joshua Colp wrote:
> > /branches/12/res/res_pjsip_refer.c, lines 185-193
> > 
> >
> > I need time to grok your other changes and the possible repercussions 
> > but I'll comment on this right now. Would this get called twice since the 
> > framehook is invoked when detached?

Yep, it's hitting it twice.  Guess I need to make sure it doesn't push a second 
notify.


- Jonathan


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


On May 8, 2014, 12:40 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3485/
> ---
> 
> (Updated May 8, 2014, 12:40 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and Mark Michelson.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> If a PJSIP endpoint attempts to blind transfer to a parking extension, there 
> is an override to the normal transfer logic that can make things act a little 
> weird. We noticed that this would leave various phones hanging on transfer 
> screens without progressing. When the transfer was considered successful, 
> PJSIP deferred the actual action of sending the 200 notify and the actual 
> trigger for that happening never occurs when the transfer is to a parking 
> extension.
> 
> In order to handle this, the bridge function that handles blind transfers now 
> returns a different value if a call was parked and if the channel driver 
> needs to react differently in this case, it can.  In the case of PJSIP, we 
> respond to transfers to park by immediately sending the notify with 200 OK 
> sip frag instead of deferring the action.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 413303 
>   /branches/12/res/parking/parking_bridge_features.c 413303 
>   /branches/12/res/parking/parking_applications.c 413303 
>   /branches/12/main/parking.c 413303 
>   /branches/12/main/bridge.c 413303 
>   /branches/12/include/asterisk/parking.h 413303 
>   /branches/12/channels/sig_analog.c 413303 
>   /branches/12/channels/chan_sip.c 413303 
>   /branches/12/channels/chan_mgcp.c 413303 
>   /branches/12/channels/chan_dahdi.c 413303 
> 
> Diff: https://reviewboard.asterisk.org/r/3485/diff/
> 
> 
> Testing
> ---
> 
> Before patch:
> * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until 
> it either manually hangs up or 60 seconds pass and Asterisk terminates the 
> session.
> 
> After the patch:
> * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer 
> screen and goes back to idle mode.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3512: media formats: Convert the translation core over

[Kevin Harwell]

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

(Updated May 8, 2014, 3:37 p.m.)


Review request for Asterisk Developers.


Changes
---

Updated based upon review feedback.


Bugs: SWP-6725
https://issues.asterisk.org/jira/browse/SWP-6725


Repository: Asterisk


Description
---

Updated the translation core (translate.c) to use the new media format API.


Diffs (updated)
-

  team/group/media_formats-reviewed/main/translate.c 413541 
  team/group/media_formats-reviewed/main/format.c 413541 
  team/group/media_formats-reviewed/main/codec.c 413541 
  team/group/media_formats-reviewed/include/asterisk/format.h 413541 

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


Testing
---


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] 3512: media formats: Convert the translation core over

[Kevin Harwell]

> On May 8, 2014, 1 p.m., Mark Michelson wrote:
> > team/group/media_formats-reviewed/include/asterisk/codec.h, lines 180-189
> > 
> >
> > 1) Document that this function appends the names onto the buf rather 
> > than just setting the input buf to the codec names.
> > 2) Returning an ast_str ** is awkward and unnecessary. If you wanted to 
> > make this return something, a more natural way might be to do something 
> > like:
> > 
> > struct ast_str *ast_codec_get_names(const struct ast_codec *codec, 
> > struct ast_str *buf);
> > 
> > And then require that it gets called like:
> > 
> > str = ast_codec_get_names(codec, str);
> > 
> > As it is, I'm fine with it just returning void (or possibly a pass/fail 
> > int).

This method has been dropped.


> On May 8, 2014, 1 p.m., Mark Michelson wrote:
> > team/group/media_formats-reviewed/main/codec.c, lines 355-364
> > 
> >
> > This won't compile since buf is undeclared.
> > 
> > I can see two ways of fixing this.
> > 1) Switch to using ao2_callback_data() and pass the buf into this 
> > callback.
> > 
> > 2) Since you're doing a straight pointer comparison, will the same 
> > codec ever exist in the container more than once? If not, then instead of 
> > performing an ao2_callback to append codec names to an ast_str, change the 
> > ao2_callback to find the single matching codec and perform the string 
> > append in ast_codec_get_names().

After talking it over with Josh it turns out that there is no need for the name 
lookup at all.  This was an artifact of the old code that did not store the 
name with the codec, so it had to be looked up.   Also Josh mentioned it might 
be helpful to print out the sample rate along with the name, so I I'll add that 
in as well.


> On May 8, 2014, 1 p.m., Mark Michelson wrote:
> > team/group/media_formats-reviewed/main/translate.c, lines 714-715
> > 
> >
> > Does a comparison between different sample rates of signed linear 
> > codecs return AST_FORMAT_CMP_EQUAL? If not, then this functions differently 
> > from the old code.

It doesn't properly check.  I should be able to check against the codec name 
since all slin codecs have the name "slin".


- Kevin


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


On May 8, 2014, 12:16 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3512/
> ---
> 
> (Updated May 8, 2014, 12:16 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: SWP-6725
> https://issues.asterisk.org/jira/browse/SWP-6725
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Updated the translation core (translate.c) to use the new media format API.
> 
> 
> Diffs
> -
> 
>   team/group/media_formats-reviewed/main/translate.c 413539 
>   team/group/media_formats-reviewed/main/format.c 413539 
>   team/group/media_formats-reviewed/main/codec.c 413539 
>   team/group/media_formats-reviewed/include/asterisk/format.h 413539 
>   team/group/media_formats-reviewed/include/asterisk/codec.h 413539 
> 
> Diff: https://reviewboard.asterisk.org/r/3512/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang

[Joshua Colp]

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



/branches/12/res/res_pjsip_refer.c


I need time to grok your other changes and the possible repercussions but 
I'll comment on this right now. Would this get called twice since the framehook 
is invoked when detached?


- Joshua Colp


On May 8, 2014, 5:40 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3485/
> ---
> 
> (Updated May 8, 2014, 5:40 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and Mark Michelson.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> If a PJSIP endpoint attempts to blind transfer to a parking extension, there 
> is an override to the normal transfer logic that can make things act a little 
> weird. We noticed that this would leave various phones hanging on transfer 
> screens without progressing. When the transfer was considered successful, 
> PJSIP deferred the actual action of sending the 200 notify and the actual 
> trigger for that happening never occurs when the transfer is to a parking 
> extension.
> 
> In order to handle this, the bridge function that handles blind transfers now 
> returns a different value if a call was parked and if the channel driver 
> needs to react differently in this case, it can.  In the case of PJSIP, we 
> respond to transfers to park by immediately sending the notify with 200 OK 
> sip frag instead of deferring the action.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 413303 
>   /branches/12/res/parking/parking_bridge_features.c 413303 
>   /branches/12/res/parking/parking_applications.c 413303 
>   /branches/12/main/parking.c 413303 
>   /branches/12/main/bridge.c 413303 
>   /branches/12/include/asterisk/parking.h 413303 
>   /branches/12/channels/sig_analog.c 413303 
>   /branches/12/channels/chan_sip.c 413303 
>   /branches/12/channels/chan_mgcp.c 413303 
>   /branches/12/channels/chan_dahdi.c 413303 
> 
> Diff: https://reviewboard.asterisk.org/r/3485/diff/
> 
> 
> Testing
> ---
> 
> Before patch:
> * Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until 
> it either manually hangs up or 60 seconds pass and Asterisk terminates the 
> session.
> 
> After the patch:
> * Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer 
> screen and goes back to idle mode.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3505: app_chanspy: Fix a bug where barge mode only works on the first connection when multiple sessions are spied on for a channel

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On May 8, 2014, 7:31 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3505/
> ---
> 
> (Updated May 8, 2014, 7:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23381
> https://issues.asterisk.org/jira/browse/ASTERISK-23381
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This is a cleanup of the patches posted by Robert Moss for ASTERISK-23381 - A 
> stalled review of the patch exists here: 
> https://reviewboard.asterisk.org/r/3331/diff/1/#index_header
> 
> This version is made to apply to Asterisk 11 since the bug was first reported 
> there.
> 
> 
> Diffs
> -
> 
>   /branches/11/apps/app_chanspy.c 413071 
> 
> Diff: https://reviewboard.asterisk.org/r/3505/diff/
> 
> 
> Testing
> ---
> 
> 1. SIP/A calls a spy application which spies on SIP/B with the DTMF option (4 
> for spy mode, 5 for whisper mode, 6 for barge)
> 2. SIP/B calls SIP/C
> 3. Check to see if audio is flowing from A to B and from A to C... should 
> start as neither. (A always hears both of the others though)
>  * press DTMF 5
>   - now audio should flow from A to B, but from not A to C
>  * press DTMF 6
>   - now audio should flow from A to B and A to C
> 4. Hang up SIP/B
> 5. Have SIP/B call SIP/C again
> 6. The spy should reconnect automatically and be in barge mode
>   - audio should flow from A to B and A to C
>  * press DTMF 5
>   - audio should flow from A to B, but not from A to C
>  * press DTMF 4
>   - audio should not flow from A to either phone
> 
> 
> Prior to patch: Audio from A to C could not be heard in the first check
> After the patch: Audio from A to C can be heard in the first check
> 
> All other checks work as expected in both situations.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3428: Testsuite: ARI Playback Tones tests for channels and bridges

[Mark Michelson]

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

Ship it!



/asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py


Does this instance variable get used anywhere?


- Mark Michelson


On May 7, 2014, 6:58 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3428/
> ---
> 
> (Updated May 7, 2014, 6:58 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23433
> https://issues.asterisk.org/jira/browse/ASTERISK-23433
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> The YAML files have pretty apt descriptions.
> 
> Channel version:
> * Originate a channel
> * Playback a tone
> * Pause it
> * Unpause it
> * Restart it
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> Bridge version:
> * Originate a channel
> * Create a bridge
> * Add the channel to the bridge
> * Start a tone playback on the bridge
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> 
> Diffs
> -
> 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones_w_tonezone/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/playback/tests.yaml 4991 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml 4991 
> 
> Diff: https://reviewboard.asterisk.org/r/3428/diff/
> 
> 
> Testing
> ---
> 
> Ran tests, varied results, the usual.  They aren't especially changed from 
> the tests they are based on (in each case there is an existing baseline test 
> in the same folder which handles sounds).
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3489: testsuite: Improve logging

[Mark Michelson]

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



/asterisk/trunk/runtests.py


Assert that run_num > 0


- Mark Michelson


On April 28, 2014, 8:18 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3489/
> ---
> 
> (Updated April 28, 2014, 8:18 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This patch changes up the logging in the Asterisk Test Suite. It dramatically 
> reduces the amount of logging done in the logs/ directory by default 
> (although this can always be bumped up), and it redirects the vast majority 
> of the test suite logs to the actual sandboxed test run directories 
> themselves.
> 
> When we first added Python logging (it didn't always used to be there!) there 
> were far fewer tests. Having all tests dump into the same log files actually 
> felt like a benefit, since during test development (or when developing many 
> tests) it made it easier to debug test failures. Over time, however, this 
> approach has run into a number of problems:
> (1) Many of the tests are much 'chattier' than they used to be. Having 
> twisted, starpy, websockets, requests, and other libraries dump information 
> has greatly increased the number of log messages. Not to mention logging out 
> every SIPp screen received...
> (2) There are a lot more tests than there were when this was added.
> (3) Tailing a log file is not always the best way to debug. Sometimes you 
> have to search through an entire log file for one run. Finding the error 
> becomes problematic when your editor of choice chokes on the size of the file.
> 
> Hence, this patch.
> 
> Logging now works in the following way:
> (1) The test_case.TestCase class now always sets up the logging. The logging 
> set up done by test_runner was removed (as it only logged out a few messages 
> before an instance of TestCase was created anyway).
> (2) A global logger can still be configured in logger.conf. It now only sets 
> up a logger of INFO messages and higher. This allows a test executor to watch 
> which tests are being run, without getting spammed. During test development, 
> the log message level can be increased to DEBUG.
> (3) TestCase now places the Asterisk directories created by the test 
> execution in a further subfolder, run_N (where N increases with each 
> execution of that test). Where before you might have:
> 
> tests/my_test/ast1
> tests/my_test/ast2
> tests/my_test/ast3
> tests/my_test/ast4
> 
> You will now have:
> 
> tests/my_test/run_1/ast1
> tests/my_test/run_1/ast2
> tests/my_test/run_2/ast1
> tests/my_test/run_2/ast2
> 
> This lets you determine which Asterisk instances belong together, and also 
> makes it possible for only the erroring test run to be archived when a test 
> fails (as opposed to every Asterisk directory)
> (4) TestCase now creates a DEBUG and INFO log file(s) in the run directory. 
> These contain the full Asterisk logs for the test run.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5002 
>   /asterisk/trunk/logger.conf 5002 
>   /asterisk/trunk/lib/python/asterisk/test_runner.py 5002 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5002 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5002 
> 
> Diff: https://reviewboard.asterisk.org/r/3489/diff/
> 
> 
> Testing
> ---
> 
> I've actually been running an instance of the test suite with this set up for 
> several months, using it for development of several tests and generally 
> tweaking it. I finally felt like it was "good enough".
> 
> Tested:
> * Failing tests archive appropriately
> * Crashing Asterisk gets archived
> * Global log file is still created with expected message levels
> * Test specific log files are created appropriately with expected message 
> levels
> * Tested a pluggable module based test (pbx/dialplan) and a 'traditional' 
> Python test (channels/SIP/sip_hold)
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3505: app_chanspy: Fix a bug where barge mode only works on the first connection when multiple sessions are spied on for a channel

[Jonathan Rose]

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

(Updated May 8, 2014, 2:31 p.m.)


Review request for Asterisk Developers.


Changes
---

Nah, you weren't crazy. I thought I had determined the change to be unnecessary 
for some reason, but then I realized the cause of the bug was slightly 
different than how I thought it was when I first reproduced it.

Instead I'm getting rid of the first call to attach the audiohook and keeping 
the one inside the loop. If the channel isn't bridged with anything when the 
attach_barge function is called, then it will keep trying until it can attach 
one.


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


Repository: Asterisk


Description
---

This is a cleanup of the patches posted by Robert Moss for ASTERISK-23381 - A 
stalled review of the patch exists here: 
https://reviewboard.asterisk.org/r/3331/diff/1/#index_header

This version is made to apply to Asterisk 11 since the bug was first reported 
there.


Diffs (updated)
-

  /branches/11/apps/app_chanspy.c 413071 

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


Testing
---

1. SIP/A calls a spy application which spies on SIP/B with the DTMF option (4 
for spy mode, 5 for whisper mode, 6 for barge)
2. SIP/B calls SIP/C
3. Check to see if audio is flowing from A to B and from A to C... should start 
as neither. (A always hears both of the others though)
 * press DTMF 5
  - now audio should flow from A to B, but from not A to C
 * press DTMF 6
  - now audio should flow from A to B and A to C
4. Hang up SIP/B
5. Have SIP/B call SIP/C again
6. The spy should reconnect automatically and be in barge mode
  - audio should flow from A to B and A to C
 * press DTMF 5
  - audio should flow from A to B, but not from A to C
 * press DTMF 4
  - audio should not flow from A to either phone


Prior to patch: Audio from A to C could not be heard in the first check
After the patch: Audio from A to C can be heard in the first check

All other checks work as expected in both situations.


Thanks,

Jonathan Rose

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

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

Re: [asterisk-dev] [Code Review] 3388: media_formats: Move chan_mgcp, chan_unistim, and chan_skinny over.

[Kevin Harwell]

> On May 8, 2014, 1:22 p.m., Kevin Harwell wrote:
> > /team/group/media_formats-reviewed/channels/chan_skinny.c, lines 4846-4847
> > 
> >
> > bugbug.

oops, looks like Matt already mentioned this one.  Just drop.


- Kevin


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


On May 5, 2014, 6:11 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3388/
> ---
> 
> (Updated May 5, 2014, 6:11 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This moves the chan_mgcp, chan_unistim, and chan_skinny modules over to the 
> media formats API.
> 
> 
> Diffs
> -
> 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 413300 
>   /team/group/media_formats-reviewed/channels/chan_unistim.c 413300 
>   /team/group/media_formats-reviewed/channels/chan_skinny.c 413300 
>   /team/group/media_formats-reviewed/channels/chan_mgcp.c 413300 
> 
> Diff: https://reviewboard.asterisk.org/r/3388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3388: media_formats: Move chan_mgcp, chan_unistim, and chan_skinny over.

[Kevin Harwell]

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



/team/group/media_formats-reviewed/channels/chan_mgcp.c


Problem from old code: 'global_capability' needs to be released for the 
module load failure paths.  As well as 'mgcp_tech.capabilities'



/team/group/media_formats-reviewed/channels/chan_skinny.c


bugbug.



/team/group/media_formats-reviewed/channels/chan_unistim.c


I think these need to be moved to be under the 'buffed_failed' tag.  A 
couple of paths goto 'buff_failed', but need items released.


- Kevin Harwell


On May 5, 2014, 6:11 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3388/
> ---
> 
> (Updated May 5, 2014, 6:11 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This moves the chan_mgcp, chan_unistim, and chan_skinny modules over to the 
> media formats API.
> 
> 
> Diffs
> -
> 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 413300 
>   /team/group/media_formats-reviewed/channels/chan_unistim.c 413300 
>   /team/group/media_formats-reviewed/channels/chan_skinny.c 413300 
>   /team/group/media_formats-reviewed/channels/chan_mgcp.c 413300 
> 
> Diff: https://reviewboard.asterisk.org/r/3388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3512: media formats: Convert the translation core over

[Mark Michelson]

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



team/group/media_formats-reviewed/include/asterisk/codec.h


1) Document that this function appends the names onto the buf rather than 
just setting the input buf to the codec names.
2) Returning an ast_str ** is awkward and unnecessary. If you wanted to 
make this return something, a more natural way might be to do something like:

struct ast_str *ast_codec_get_names(const struct ast_codec *codec, struct 
ast_str *buf);

And then require that it gets called like:

str = ast_codec_get_names(codec, str);

As it is, I'm fine with it just returning void (or possibly a pass/fail 
int).



team/group/media_formats-reviewed/main/codec.c


This won't compile since buf is undeclared.

I can see two ways of fixing this.
1) Switch to using ao2_callback_data() and pass the buf into this callback.

2) Since you're doing a straight pointer comparison, will the same codec 
ever exist in the container more than once? If not, then instead of performing 
an ao2_callback to append codec names to an ast_str, change the ao2_callback to 
find the single matching codec and perform the string append in 
ast_codec_get_names().



team/group/media_formats-reviewed/main/translate.c


Does a comparison between different sample rates of signed linear codecs 
return AST_FORMAT_CMP_EQUAL? If not, then this functions differently from the 
old code.


- Mark Michelson


On May 8, 2014, 5:16 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3512/
> ---
> 
> (Updated May 8, 2014, 5:16 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: SWP-6725
> https://issues.asterisk.org/jira/browse/SWP-6725
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Updated the translation core (translate.c) to use the new media format API.
> 
> 
> Diffs
> -
> 
>   team/group/media_formats-reviewed/main/translate.c 413539 
>   team/group/media_formats-reviewed/main/format.c 413539 
>   team/group/media_formats-reviewed/main/codec.c 413539 
>   team/group/media_formats-reviewed/include/asterisk/format.h 413539 
>   team/group/media_formats-reviewed/include/asterisk/codec.h 413539 
> 
> Diff: https://reviewboard.asterisk.org/r/3512/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] 3388: media_formats: Move chan_mgcp, chan_unistim, and chan_skinny over.

[Matt Jordan]

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



/team/group/media_formats-reviewed/channels/chan_mgcp.c


I'd declare these on separate lines. Just a thought.



/team/group/media_formats-reviewed/channels/chan_mgcp.c


I enjoy this comment, because I have no reference for what it means... but 
you've kept the comment. Excellent.



/team/group/media_formats-reviewed/channels/chan_skinny.c


I'm not sure we can just remove this from chan_skinny :-)

If it's not currently possible to print out the codec preference order in 
some fashion, we should at least put in a BUGBUG to come back and add this when 
there's an API call for it.



/team/group/media_formats-reviewed/channels/chan_skinny.c


Add BUGBUG for this as well


- Matt Jordan


On May 5, 2014, 6:11 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3388/
> ---
> 
> (Updated May 5, 2014, 6:11 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This moves the chan_mgcp, chan_unistim, and chan_skinny modules over to the 
> media formats API.
> 
> 
> Diffs
> -
> 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 413300 
>   /team/group/media_formats-reviewed/channels/chan_unistim.c 413300 
>   /team/group/media_formats-reviewed/channels/chan_skinny.c 413300 
>   /team/group/media_formats-reviewed/channels/chan_mgcp.c 413300 
> 
> Diff: https://reviewboard.asterisk.org/r/3388/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3485: pjsip: Fix a bug where transferring to a parking extension causes calls to hang

[Jonathan Rose]

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

(Updated May 8, 2014, 12:40 p.m.)


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


Changes
---

This new patch delays execution of the new_channel_cb as well as returning from 
the parking function when a new_channel_cb is specified until after the parking 
announcement is complete. Digium phones were able to listen to those 
announcements and the old patch was forcing them to hang up immediately.


Repository: Asterisk


Description
---

If a PJSIP endpoint attempts to blind transfer to a parking extension, there is 
an override to the normal transfer logic that can make things act a little 
weird. We noticed that this would leave various phones hanging on transfer 
screens without progressing. When the transfer was considered successful, PJSIP 
deferred the actual action of sending the 200 notify and the actual trigger for 
that happening never occurs when the transfer is to a parking extension.

In order to handle this, the bridge function that handles blind transfers now 
returns a different value if a call was parked and if the channel driver needs 
to react differently in this case, it can.  In the case of PJSIP, we respond to 
transfers to park by immediately sending the notify with 200 OK sip frag 
instead of deferring the action.


Diffs (updated)
-

  /branches/12/res/res_pjsip_refer.c 413303 
  /branches/12/res/parking/parking_bridge_features.c 413303 
  /branches/12/res/parking/parking_applications.c 413303 
  /branches/12/main/parking.c 413303 
  /branches/12/main/bridge.c 413303 
  /branches/12/include/asterisk/parking.h 413303 
  /branches/12/channels/sig_analog.c 413303 
  /branches/12/channels/chan_sip.c 413303 
  /branches/12/channels/chan_mgcp.c 413303 
  /branches/12/channels/chan_dahdi.c 413303 

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


Testing
---

Before patch:
* Blind transfer on Polycom SPIP: Phone is on the blind transfer screen until 
it either manually hangs up or 60 seconds pass and Asterisk terminates the 
session.

After the patch:
* Blind transfer on Polycom SPIP: Phone immediately leaves the blind transfer 
screen and goes back to idle mode.


Thanks,

Jonathan Rose

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

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

Re: [asterisk-dev] [Code Review] 3477: Japanese language patch for app_voicemail.c and say.c

[Joshua Colp]

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



/trunk/apps/app_voicemail.c


Some minor redness.



/trunk/apps/app_voicemail.c


Why the change? Is this a bugfix?


- Joshua Colp


On May 8, 2014, 7:08 a.m., Kevin McCoy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3477/
> ---
> 
> (Updated May 8, 2014, 7:08 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Created new review request with proper diffs. Japanese language support patch 
> for sound files in app_voicemail.c and say.c, depends on entire sound file 
> package currently available in release candidate format as per 
> https://issues.asterisk.org/jira/browse/ASTERISK-23324
> https://www.dropbox.com/s/axu6gfnf9fh40hz/asterisk-core-sounds-ja-wav-and-patch.tgz
> 
> Word order and plurals, dates, counts in Japanese are all significantly 
> different than English, hence the need for this patch. Tested working with 
> Asterisk 12.
> 
> Here is the installation procedure from the README contained in the RC 
> archive:
> 
> --
> 
> 
> Install Asterisk Sound Files:
> mkdir /var/lib/asterisk/sounds/ja 
> cd /var/lib/asterisk/sounds/ja 
> wget 
> http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-ja-gsm-current.tar.gz
>  
> tar xvfz asterisk-core-sounds-ja-gsm-current.tar.gz 
> rm -f asterisk-core-sounds-ja-gsm-current.tar.gz 
> chown -R asterisk.asterisk /var/lib/asterisk/sounds/ja
> 
> How To Change Default SIP Channel Language to Japanese
> 
> Using Asterisk (vanilla):
> vi /etc/asterisk/sip.conf
> Edit language variable to:
> language = ja
> 
> Using FreePBX:
> On the FreePBX menu -> Settings -> Asterisk SIP Settings -> Advanced General 
> Settings section -> Language field 
> Set Language field to : ja
> 
> Install Japanese Patch:
> Download Asterisk 12 source
> Change directory to Asterisk 12 source folder
> Download the patches for say.c and app_voicemail.c
> patch -p0 < say.c.20140226.jp.patch
> patch -p0 < app_voicemail.c.20140226.jp.patch
> Compile Asterisk 12 source as usual
> 
> 
> --
> 
> I'm happy to answer questions about the code.
> 
> 
> Diffs
> -
> 
>   /trunk/main/say.c 413007 
>   /trunk/apps/app_voicemail.c 413007 
> 
> Diff: https://reviewboard.asterisk.org/r/3477/diff/
> 
> 
> Testing
> ---
> 
> Fixed code with diff r2 as requested. Please double check and give feedback.
> 
> 
> Thanks,
> 
> Kevin McCoy
> 
>

-- 
_
-- 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] 3512: media formats: Convert the translation core over

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On May 8, 2014, 5:16 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3512/
> ---
> 
> (Updated May 8, 2014, 5:16 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: SWP-6725
> https://issues.asterisk.org/jira/browse/SWP-6725
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Updated the translation core (translate.c) to use the new media format API.
> 
> 
> Diffs
> -
> 
>   team/group/media_formats-reviewed/main/translate.c 413539 
>   team/group/media_formats-reviewed/main/format.c 413539 
>   team/group/media_formats-reviewed/main/codec.c 413539 
>   team/group/media_formats-reviewed/include/asterisk/format.h 413539 
>   team/group/media_formats-reviewed/include/asterisk/codec.h 413539 
> 
> Diff: https://reviewboard.asterisk.org/r/3512/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] 3515: media_formats: Move chan_pjsip over.

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On May 5, 2014, 9:07 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3515/
> ---
> 
> (Updated May 5, 2014, 9:07 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change moves chan_pjsip and the other PJSIP modules over to the new 
> media formats work.
> 
> 
> Diffs
> -
> 
>   /team/group/media_formats-reviewed/res/res_pjsip_session.c 413300 
>   /team/group/media_formats-reviewed/res/res_pjsip_sdp_rtp.c 413300 
>   /team/group/media_formats-reviewed/res/res_pjsip/pjsip_configuration.c 
> 413300 
>   /team/group/media_formats-reviewed/include/asterisk/res_pjsip_session.h 
> 413300 
>   /team/group/media_formats-reviewed/include/asterisk/res_pjsip.h 413300 
>   /team/group/media_formats-reviewed/include/asterisk/format_cache.h 413300 
>   /team/group/media_formats-reviewed/channels/pjsip/dialplan_functions.c 
> 413300 
>   /team/group/media_formats-reviewed/channels/chan_pjsip.c 413300 
> 
> Diff: https://reviewboard.asterisk.org/r/3515/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3512: media formats: Convert the translation core over

[Kevin Harwell]

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

(Updated May 8, 2014, 12:16 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed review findings.  Moved the setting of particular frame details to 
happen on the private structure creation (in newpvt function) as these values 
only really need to be set once.


Bugs: SWP-6725
https://issues.asterisk.org/jira/browse/SWP-6725


Repository: Asterisk


Description
---

Updated the translation core (translate.c) to use the new media format API.


Diffs (updated)
-

  team/group/media_formats-reviewed/main/translate.c 413539 
  team/group/media_formats-reviewed/main/format.c 413539 
  team/group/media_formats-reviewed/main/codec.c 413539 
  team/group/media_formats-reviewed/include/asterisk/format.h 413539 
  team/group/media_formats-reviewed/include/asterisk/codec.h 413539 

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


Testing
---


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

[asterisk-dev] Wrong entity field in NOTIFY??

[Eugen Dedu]

Hi asterisk devs,

Since several years we (opal, ekiga VoIP community) noticed that there 
is a problem in the NOTIFY messages created by asterisk (entity 
attribute is set to the subscriber instead of the subscribed) and I 
finally decided to contact you to see whether such a visible bug has 
been around for so many years or we simply miss something evident.  (See 
the log of http://sourceforge.net/p/opalvoip/code/26681 for example for 
a workaround.)


When umfoxd subscribes to 1002's presence, like this for example:

SUBSCRIBE sip:1...@xivo.xyz.fr SIP/2.0
CSeq: 2 SUBSCRIBE
Via: SIP/2.0/UDP 
157.163.3.246:5060;branch=z9hG4bK52829d51-8f0c-1910-8da9-080027f515ee;rport

User-Agent: Ekiga/4.0.2
Authorization: Digest username="umfodx", realm="xivo", nonce="1c356c20", 
uri="sip:1...@xivo.xyz.fr", algorithm=MD5, 
response="4f62a8e41ee3c464ff1bf6124b7dda76"

From: ;tag=1b7f9d51-8f0c-1910-8da4-080027f515ee
Call-ID: e47b9d51-8f0c-1910-8da2-080027f515ee@Windows7-PC
Supported: eventlist
To: 
Accept: application/pidf+xml
Accept: multipart/related
Accept: application/rlmi+xml
Contact: 
Allow: 
INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK

Expires: 300
Event: presence
Content-Length: 0
Max-Forwards: 70


umfoxd receives afterwards NOTIFY messages, like this for example:

NOTIFY sip:umfodx@157.163.3.246 SIP/2.0
CSeq: 102 NOTIFY
Via: SIP/2.0/UDP 157.163.1.45:5060;branch=z9hG4bK1ebf2f30;rport
User-Agent: XiVO PBX
From: ;tag=as7426eebf
Call-ID: e47b9d51-8f0c-1910-8da2-080027f515ee@Windows7-PC
To: ;tag=1b7f9d51-8f0c-1910-8da4-080027f515ee
Contact: 
Subscription-State: active
Event: presence
Content-Type: application/pidf+xml
Content-Length: 499
Max-Forwards: 70





Ready

sip:1...@xivo.xyz.fr
open



The problem is that in the above message the entity attribute is umfoxd 
(the subscriber) instead of 1002 (the publisher).


From RFC 3863:
The  element MUST have an 'entity' attribute. The value of the 
'entity' attribute is the 'pres' URL of the PRESENTITY publishing this 
presence document.


Regards,
--
Eugen
http://eugen.dedu.free.fr

--
_
-- 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] 3521: chan_dahdi/sig_pri: Prevent unnecessary PROGRESS events when overlap dialing is enabled.

[Matt Jordan]

> On May 7, 2014, 10:49 a.m., Matt Jordan wrote:
> > /branches/1.8/channels/sig_pri.c, lines 5275-5290
> > 
> >
> > This is really hard to read, particularly with the level of indentation 
> > that is required here.
> > 
> > Is there is any way the detection of match_more / need_dialtone can be 
> > put into small functions, that would be... nice.
> > 
> > match_more = can_pri_match_more(e, pri);
> > need_dialtone = do_i_need_dialtone(match_more, e, pri);
> > 
> > Something like that.
> 
> rmudgett wrote:
> They could be put into encapsulating functions but I'm not sure there is 
> much benefit over just setting the boolean variables as done here.  
> Admittedly, pri_dchannel() has long been in need of refactoring into smaller 
> functions.
> 
> Is it the starting indentation level causing reviewboard to wrap the 
> lines awkwardly that is the main problem?
>

Well, yes - but at the same time, that's not Review Board's problem. To quote 
Linus:

{quote}
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen.  The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
{quote}

Yes, this means we're screwed in so many places in Asterisk it's not really 
funny (and no, I'm not advocating for 8 character indentations), but when our 
indentations with 4-character spacing pushes the code so far over that it can't 
render properly in Review Board, that's a sign that a change is warranted.


- Matt


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


On May 1, 2014, 9:35 p.m., rmudgett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3521/
> ---
> 
> (Updated May 1, 2014, 9:35 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: AST-1338
> https://issues.asterisk.org/jira/browse/AST-1338
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This review and https://reviewboard.asterisk.org/r/3520/ work together to 
> allow Asterisk to control the inband audio available progress indication ie 
> on the SETUP_ACKNOWLEDGE message when dialtone is present.
> 
> When overlap dialing is enabled, the lack of inband audio available 
> information in the SETUP_ACKNOWLEDGE events causes an interoperability 
> problem with SIP.  sig_pri doesn't know if there is dialtone present when a 
> SETUP_ACKNOWLEDGE is received so it assumes it is there and posts an 
> AST_CONTROL_PROGRESS frame.  The SIP channel driver then sends out a 183 
> Session Progress and blocks the desired 180 Ringing message when the ALERTING 
> message comes in.
> 
> * Made the configure script detect if the installed version of libpri 
> supports the SETUP_ACKNOWLEDGE enhancements.
> 
> * Using the new API, made generate an AST_CONTROL_PROGRESS frame on an 
> incoming SETUP_ACKNOWLEDGE message when the message indicates inband audio is 
> present insetad of assuming that dialtone is present.
> 
> * Using the new API, made SETUP_ACKNOWLEDGE send out an inband audio 
> available indication only if dialtone is expected.  The change also makes the 
> fallback behaviour of sending the PROGRESS message better by sending it only 
> if dialtone is expected.
> 
> * Changed receiving a PROCEEDING message to not generate an 
> AST_CONTROL_PROGRESS frame if the progress indication ie indicates 
> non-end-to-end-ISDN.  This helps interoperability with SIP.
> 
> * Changed sending a PROCEEDING message in response to an 
> AST_CONTROL_PROCEEDING frame to not indicate inband audio available.  It was 
> silly to do so anyway because the channel driver doesn't know if inband audio 
> is even available.  This helps interoperability with SIP.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/include/asterisk/autoconfig.h.in 413194 
>   /branches/1.8/configure.ac 413194 
>   /branches/1.8/configure UNKNOWN 
>   /branches/1.8/channels/sig_pri.c 413194 
> 
> Diff: https://reviewboard.asterisk.org/r/3521/diff/
> 
> 
> Testing
> ---
> 
> Sent calls over an ISDN trunk with overlap dialing enabled that did and did 
> not present dialtone for more digits.
> Observed that the inband audio available progress indication ie was sent when 
> needed on the SETUP_ACKNOWLEDGE message.
> Added a debug message that indicated when Asterisk did and did not receive 
> the inband audio indication for the SETUP_ACKNOWLEDGE message.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-- 

Re: [asterisk-dev] [Code Review] 3522: Allow framehooks to be queried for what frame types they consume.

[rmudgett]

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

Ship it!


Ship It!

- rmudgett


On May 8, 2014, 9:59 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3522/
> ---
> 
> (Updated May 8, 2014, 9:59 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23497
> https://issues.asterisk.org/jira/browse/ASTERISK-23497
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Framehooks currently provide no mechanism for anything to determine what 
> frame types they are consuming. This is problematic for logic which uses this 
> information to determine what to do (such as native bridging). This means 
> that code has had to block certain things (such as RTP native bridging) if 
> *any* framehooks are present - even if they are not interested in the media 
> at all. The attached change adds some functionality to improve this:
> 
> 1. An optional callback has been added to the framehook interface which 
> allows the framehook implementation to be queried for whether it is consuming 
> a frame type or not. If this callback is not implemented it is assumed they 
> are consuming all types, which is the previous behavior.
> 2. Some framehooks have had the callback implemented.
> 3. The unbridge softhangup flag is now being set when a framehook is attached 
> or detached to trigger a re-evaluation within the bridge universe.
> 
> These together allow the bridge_native_rtp module to be smarter about when to 
> prevent its use.
> 
> 
> Diffs
> -
> 
>   /branches/12/main/framehook.c 413538 
>   /branches/12/main/channel.c 413538 
>   /branches/12/main/bridge_basic.c 413538 
>   /branches/12/include/asterisk/framehook.h 413538 
>   /branches/12/include/asterisk/channel.h 413538 
>   /branches/12/bridges/bridge_native_rtp.c 413538 
> 
> Diff: https://reviewboard.asterisk.org/r/3522/diff/
> 
> 
> Testing
> ---
> 
> Performed numerous attended transfers across SIP and PJSIP. Before patch 
> simple_bridge would be used after completion for attended. After patch the 
> expected native_rtp would be used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3522: Allow framehooks to be queried for what frame types they consume.

[Joshua Colp]

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

(Updated May 8, 2014, 2:59 p.m.)


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

Framehooks currently provide no mechanism for anything to determine what frame 
types they are consuming. This is problematic for logic which uses this 
information to determine what to do (such as native bridging). This means that 
code has had to block certain things (such as RTP native bridging) if *any* 
framehooks are present - even if they are not interested in the media at all. 
The attached change adds some functionality to improve this:

1. An optional callback has been added to the framehook interface which allows 
the framehook implementation to be queried for whether it is consuming a frame 
type or not. If this callback is not implemented it is assumed they are 
consuming all types, which is the previous behavior.
2. Some framehooks have had the callback implemented.
3. The unbridge softhangup flag is now being set when a framehook is attached 
or detached to trigger a re-evaluation within the bridge universe.

These together allow the bridge_native_rtp module to be smarter about when to 
prevent its use.


Diffs (updated)
-

  /branches/12/main/framehook.c 413538 
  /branches/12/main/channel.c 413538 
  /branches/12/main/bridge_basic.c 413538 
  /branches/12/include/asterisk/framehook.h 413538 
  /branches/12/include/asterisk/channel.h 413538 
  /branches/12/bridges/bridge_native_rtp.c 413538 

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


Testing
---

Performed numerous attended transfers across SIP and PJSIP. Before patch 
simple_bridge would be used after completion for attended. After patch the 
expected native_rtp would be used.


Thanks,

Joshua Colp

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

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

Re: [asterisk-dev] [Code Review] 3477: Japanese language patch for app_voicemail.c and say.c

[Kevin McCoy]

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

(Updated May 8, 2014, 7:08 a.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Created new review request with proper diffs. Japanese language support patch 
for sound files in app_voicemail.c and say.c, depends on entire sound file 
package currently available in release candidate format as per 
https://issues.asterisk.org/jira/browse/ASTERISK-23324
https://www.dropbox.com/s/axu6gfnf9fh40hz/asterisk-core-sounds-ja-wav-and-patch.tgz

Word order and plurals, dates, counts in Japanese are all significantly 
different than English, hence the need for this patch. Tested working with 
Asterisk 12.

Here is the installation procedure from the README contained in the RC archive:

--


Install Asterisk Sound Files:
mkdir /var/lib/asterisk/sounds/ja 
cd /var/lib/asterisk/sounds/ja 
wget 
http://downloads.asterisk.org/pub/telephony/sounds/asterisk-core-sounds-ja-gsm-current.tar.gz
 
tar xvfz asterisk-core-sounds-ja-gsm-current.tar.gz 
rm -f asterisk-core-sounds-ja-gsm-current.tar.gz 
chown -R asterisk.asterisk /var/lib/asterisk/sounds/ja

How To Change Default SIP Channel Language to Japanese

Using Asterisk (vanilla):
vi /etc/asterisk/sip.conf
Edit language variable to:
language = ja

Using FreePBX:
On the FreePBX menu -> Settings -> Asterisk SIP Settings -> Advanced General 
Settings section -> Language field 
Set Language field to : ja

Install Japanese Patch:
Download Asterisk 12 source
Change directory to Asterisk 12 source folder
Download the patches for say.c and app_voicemail.c
patch -p0 < say.c.20140226.jp.patch
patch -p0 < app_voicemail.c.20140226.jp.patch
Compile Asterisk 12 source as usual


--

I'm happy to answer questions about the code.


Diffs
-

  /trunk/main/say.c 413007 
  /trunk/apps/app_voicemail.c 413007 

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


Testing (updated)
---

Fixed code with diff r2 as requested. Please double check and give feedback.


Thanks,

Kevin McCoy

-- 
_
-- 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