[asterisk-dev] asterisk-dev Digest, Vol 66, Issue 50
Mohammed Lambat
duxy786 at googlemail.com
Wed Jan 20 17:15:09 CST 2010
Jazakallah
Sent from my iPhone
On 20 Jan 2010, at 22:22, asterisk-dev-request at lists.digium.com wrote:
> Send asterisk-dev mailing list submissions to
> asterisk-dev at lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> or, via email, send a message with subject or body 'help' to
> asterisk-dev-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-dev-owner at lists.digium.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of asterisk-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: New Spandsp FAX Backend (Matthew Nicholson)
> 2. [Code Review] rtp timestamp to timeval calculation fix
> (David Vossel)
> 3. Re: [Code Review] rtp timestamp to timeval calculation fix
> (Kevin Fleming)
> 4. Re: [Code Review] rtp timestamp to timeval calculation fix
> (David Vossel)
> 5. Re: New Spandsp FAX Backend (Matthew Nicholson)
> 6. DAHDI-Linux 2.2.1 and DAHDI-Tools 2.2.1 Released
> (Asterisk Development Team)
> 7. Re: [Code Review] directmediapermit/directmediadeny support
> to restrict which peers can do directmedia based on ip address
> (David Vossel)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 Jan 2010 14:16:40 -0600
> From: Matthew Nicholson <mnicholson at digium.com>
> Subject: Re: [asterisk-dev] New Spandsp FAX Backend
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <1264018600.11706.238.camel at solo.digium.internal>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2010-01-20 at 12:53 +0100, Kristijan Vrban wrote:
>> just tried with current spandsp0.0.6~pre17
>>
>> [CC] res_fax_spandsp.c -> res_fax_spandsp.o
>> res_fax_spandsp.c:114: error: field ?fax_state? has incomplete type
>> res_fax_spandsp.c:115: error: field ?t38_state? has incomplete type
>> res_fax_spandsp.c: In function ?spandsp_fax_start?:
>> res_fax_spandsp.c:573: error: dereferencing pointer to incomplete
>> type
>> res_fax_spandsp.c:586: error: dereferencing pointer to incomplete
>> type
>> res_fax_spandsp.c: In function ?spandsp_fax_cli_show_session?:
>> res_fax_spandsp.c:675: error: dereferencing pointer to incomplete
>> type
>> res_fax_spandsp.c:675: error: dereferencing pointer to incomplete
>> type
>> make[1]: *** [res_fax_spandsp.o] Error 1
>> make: *** [res] Error 2
>
> I'll take a look at this. I have been testing with spandsp 0.0.5.
>
>
> --
> Matthew Nicholson
> Digium, Inc. | Software Developer
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 20 Jan 2010 20:34:43 -0000
> From: "David Vossel" <dvossel at digium.com>
> Subject: [asterisk-dev] [Code Review] rtp timestamp to timeval
> calculation fix
> To: "David Vossel" <dvossel at digium.com>, "Asterisk Developers"
> <asterisk-dev at lists.digium.com>
> Message-ID: <20100120203443.12701.27473 at hotblack.digium.internal>
> Content-Type: text/plain; charset="utf-8"
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/468/
> -----------------------------------------------------------
>
> Review request for Asterisk Developers.
>
>
> Summary
> -------
>
> ------Problem
> The rtp timestamp field, from best I understand, starts at a marked
> value and increments by the number of samples contained in each
> packet. When we receive a rtp timestamp we attempt to convert that
> value into a timeval to keep up with the actual time the timestamp
> represents. This value is very important because it ends up
> representing the ast_frame's delivery timeval. The delivery timeval
> is used during ast_translate to predict time the next frame should
> arrive. If rtp incorrectly calculates the frame's delivery timeval,
> ast_translate will attempt to compensate for the new delivery time
> by adding the difference between what it expects and what it
> received to the translated frame's delivery time.
>
> So, in ast_translate if the incoming frame's delivery time is 20ms
> above our expected next incoming time, the next outgoing delivery
> time has 20ms added to it.
>
> Right now the conversion between the rtp timestamp to timeval
> appears to only be accurate for 8000khz audio. The problem is
> primarily in how we calculate the tv_usec portion of the timeval.
>
> -----Current method of timestamp to timeval calculation
> Ideally the sec and usec result from all of these calculations
> should be the same since they represent the same length of audio.
>
> --8000 kHz Example
> timestamp = 1422080 (8888 packets, 160 samples, 20ms ulaw)
> rate = 8000;
>
> sec = timestamp / rate
> usec = (timestamp % rate) * 125
> result is sec: 177 usec: 760000
>
> --16000 kHz example
> timestamp = 2844160 (8888 packets, 320 samples, 20ms siren7)
> rate = 16000;
>
> sec = timestamp / rate
> usec = (timestamp % rate) * 125
> result is sec: 177 usec: 1520000
>
> --32000 kHz example
> timestamp = 5688320 (8888 packets, 640 samples, 20ms siren14)
> rate = 16000;
>
> sec = timestamp / rate
> usec = (timestamp % rate) * 125
> result is sec: 177 usec: 3040000
>
> The usec value is incorrect for both the 16000kHz and 32000kHz
> calculation. This results in 16000kHz delivery looking like it
> contains twice as much audio than it does, and 32000kHz containing 4
> times as much. In fact, the usec values for 16000kHz and 32000kHz
> are even above the max usec value allowed. We attempt to account
> for this error by using the sanitize_tv function.
>
> -----New method of timestamp to timeval calculation
>
> -- Method 1: modifying current method.
> sec = timestamp / rate
> usec = (((timestamp % rate) / (rate / 8000))) * 125
>
> -- Method 2: use time.h api.
> timeval = ast_samp2tv(timestamp, rate);
>
>
> Method 2 is the one this patch currently implements. Unless the rtp
> timestamp does not always reflect the number of samples incremented,
> I don't see any reason not to use this method. Both methods have
> been tested.
>
>
> Diffs
> -----
>
> /trunk/res/res_rtp_asterisk.c 241620
>
> Diff: https://reviewboard.asterisk.org/r/468/diff
>
>
> Testing
> -------
>
> siren7 to siren14 translation now works. siren7 to ulaw works,
> siren14 to ulaw works.
>
>
> Thanks,
>
> David
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 20 Jan 2010 20:50:58 -0000
> From: "Kevin Fleming" <kpfleming at digium.com>
> Subject: Re: [asterisk-dev] [Code Review] rtp timestamp to timeval
> calculation fix
> To: "David Vossel" <dvossel at digium.com>, "Kevin Fleming"
> <kpfleming at digium.com>, "Asterisk Developers"
> <asterisk-dev at lists.digium.com>
> Message-ID: <20100120205058.13470.46301 at hotblack.digium.internal>
> Content-Type: text/plain; charset="utf-8"
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/468/#review1382
> -----------------------------------------------------------
>
> Ship it!
>
>
> This looks like exactly the right fix. Nice work.
>
> - Kevin
>
>
> On 2010-01-20 14:34:43, David Vossel wrote:
>>
>> -----------------------------------------------------------
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviewboard.asterisk.org/r/468/
>> -----------------------------------------------------------
>>
>> (Updated 2010-01-20 14:34:43)
>>
>>
>> Review request for Asterisk Developers.
>>
>>
>> Summary
>> -------
>>
>> ------Problem
>> The rtp timestamp field, from best I understand, starts at a marked
>> value and increments by the number of samples contained in each
>> packet. When we receive a rtp timestamp we attempt to convert that
>> value into a timeval to keep up with the actual time the timestamp
>> represents. This value is very important because it ends up
>> representing the ast_frame's delivery timeval. The delivery
>> timeval is used during ast_translate to predict time the next frame
>> should arrive. If rtp incorrectly calculates the frame's delivery
>> timeval, ast_translate will attempt to compensate for the new
>> delivery time by adding the difference between what it expects and
>> what it received to the translated frame's delivery time.
>>
>> So, in ast_translate if the incoming frame's delivery time is 20ms
>> above our expected next incoming time, the next outgoing delivery
>> time has 20ms added to it.
>>
>> Right now the conversion between the rtp timestamp to timeval
>> appears to only be accurate for 8000khz audio. The problem is
>> primarily in how we calculate the tv_usec portion of the timeval.
>>
>> -----Current method of timestamp to timeval calculation
>> Ideally the sec and usec result from all of these calculations
>> should be the same since they represent the same length of audio.
>>
>> --8000 kHz Example
>> timestamp = 1422080 (8888 packets, 160 samples, 20ms ulaw)
>> rate = 8000;
>>
>> sec = timestamp / rate
>> usec = (timestamp % rate) * 125
>> result is sec: 177 usec: 760000
>>
>> --16000 kHz example
>> timestamp = 2844160 (8888 packets, 320 samples, 20ms siren7)
>> rate = 16000;
>>
>> sec = timestamp / rate
>> usec = (timestamp % rate) * 125
>> result is sec: 177 usec: 1520000
>>
>> --32000 kHz example
>> timestamp = 5688320 (8888 packets, 640 samples, 20ms siren14)
>> rate = 16000;
>>
>> sec = timestamp / rate
>> usec = (timestamp % rate) * 125
>> result is sec: 177 usec: 3040000
>>
>> The usec value is incorrect for both the 16000kHz and 32000kHz
>> calculation. This results in 16000kHz delivery looking like it
>> contains twice as much audio than it does, and 32000kHz containing
>> 4 times as much. In fact, the usec values for 16000kHz and
>> 32000kHz are even above the max usec value allowed. We attempt to
>> account for this error by using the sanitize_tv function.
>>
>> -----New method of timestamp to timeval calculation
>>
>> -- Method 1: modifying current method.
>> sec = timestamp / rate
>> usec = (((timestamp % rate) / (rate / 8000))) * 125
>>
>> -- Method 2: use time.h api.
>> timeval = ast_samp2tv(timestamp, rate);
>>
>>
>> Method 2 is the one this patch currently implements. Unless the
>> rtp timestamp does not always reflect the number of samples
>> incremented, I don't see any reason not to use this method. Both
>> methods have been tested.
>>
>>
>> Diffs
>> -----
>>
>> /trunk/res/res_rtp_asterisk.c 241620
>>
>> Diff: https://reviewboard.asterisk.org/r/468/diff
>>
>>
>> Testing
>> -------
>>
>> siren7 to siren14 translation now works. siren7 to ulaw works,
>> siren14 to ulaw works.
>>
>>
>> Thanks,
>>
>> David
>>
>>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 20 Jan 2010 21:03:36 -0000
> From: "David Vossel" <dvossel at digium.com>
> Subject: Re: [asterisk-dev] [Code Review] rtp timestamp to timeval
> calculation fix
> To: "David Vossel" <dvossel at digium.com>, "Asterisk Developers"
> <asterisk-dev at lists.digium.com>
> Message-ID: <20100120210336.13914.52586 at hotblack.digium.internal>
> Content-Type: text/plain; charset="utf-8"
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/468/#review1383
> -----------------------------------------------------------
>
>
> Lets assume everywhere I refer to 8000kHz audio or 16000kHz audio I
> really mean 8kHz audio or 16kHz audio :)
>
> - David
>
>
> On 2010-01-20 14:34:43, David Vossel wrote:
>>
>> -----------------------------------------------------------
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviewboard.asterisk.org/r/468/
>> -----------------------------------------------------------
>>
>> (Updated 2010-01-20 14:34:43)
>>
>>
>> Review request for Asterisk Developers.
>>
>>
>> Summary
>> -------
>>
>> ------Problem
>> The rtp timestamp field, from best I understand, starts at a marked
>> value and increments by the number of samples contained in each
>> packet. When we receive a rtp timestamp we attempt to convert that
>> value into a timeval to keep up with the actual time the timestamp
>> represents. This value is very important because it ends up
>> representing the ast_frame's delivery timeval. The delivery
>> timeval is used during ast_translate to predict time the next frame
>> should arrive. If rtp incorrectly calculates the frame's delivery
>> timeval, ast_translate will attempt to compensate for the new
>> delivery time by adding the difference between what it expects and
>> what it received to the translated frame's delivery time.
>>
>> So, in ast_translate if the incoming frame's delivery time is 20ms
>> above our expected next incoming time, the next outgoing delivery
>> time has 20ms added to it.
>>
>> Right now the conversion between the rtp timestamp to timeval
>> appears to only be accurate for 8000khz audio. The problem is
>> primarily in how we calculate the tv_usec portion of the timeval.
>>
>> -----Current method of timestamp to timeval calculation
>> Ideally the sec and usec result from all of these calculations
>> should be the same since they represent the same length of audio.
>>
>> --8000 kHz Example
>> timestamp = 1422080 (8888 packets, 160 samples, 20ms ulaw)
>> rate = 8000;
>>
>> sec = timestamp / rate
>> usec = (timestamp % rate) * 125
>> result is sec: 177 usec: 760000
>>
>> --16000 kHz example
>> timestamp = 2844160 (8888 packets, 320 samples, 20ms siren7)
>> rate = 16000;
>>
>> sec = timestamp / rate
>> usec = (timestamp % rate) * 125
>> result is sec: 177 usec: 1520000
>>
>> --32000 kHz example
>> timestamp = 5688320 (8888 packets, 640 samples, 20ms siren14)
>> rate = 16000;
>>
>> sec = timestamp / rate
>> usec = (timestamp % rate) * 125
>> result is sec: 177 usec: 3040000
>>
>> The usec value is incorrect for both the 16000kHz and 32000kHz
>> calculation. This results in 16000kHz delivery looking like it
>> contains twice as much audio than it does, and 32000kHz containing
>> 4 times as much. In fact, the usec values for 16000kHz and
>> 32000kHz are even above the max usec value allowed. We attempt to
>> account for this error by using the sanitize_tv function.
>>
>> -----New method of timestamp to timeval calculation
>>
>> -- Method 1: modifying current method.
>> sec = timestamp / rate
>> usec = (((timestamp % rate) / (rate / 8000))) * 125
>>
>> -- Method 2: use time.h api.
>> timeval = ast_samp2tv(timestamp, rate);
>>
>>
>> Method 2 is the one this patch currently implements. Unless the
>> rtp timestamp does not always reflect the number of samples
>> incremented, I don't see any reason not to use this method. Both
>> methods have been tested.
>>
>>
>> Diffs
>> -----
>>
>> /trunk/res/res_rtp_asterisk.c 241620
>>
>> Diff: https://reviewboard.asterisk.org/r/468/diff
>>
>>
>> Testing
>> -------
>>
>> siren7 to siren14 translation now works. siren7 to ulaw works,
>> siren14 to ulaw works.
>>
>>
>> Thanks,
>>
>> David
>>
>>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 20 Jan 2010 15:21:39 -0600
> From: Matthew Nicholson <mnicholson at digium.com>
> Subject: Re: [asterisk-dev] New Spandsp FAX Backend
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <1264022499.11706.239.camel at solo.digium.internal>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2010-01-20 at 12:53 +0100, Kristijan Vrban wrote:
>> just tried with current spandsp0.0.6~pre17
>>
>> [CC] res_fax_spandsp.c -> res_fax_spandsp.o
>> res_fax_spandsp.c:114: error: field ?fax_state? has incomplete type
>> res_fax_spandsp.c:115: error: field ?t38_state? has incomplete type
>> res_fax_spandsp.c: In function ?spandsp_fax_start?:
>> res_fax_spandsp.c:573: error: dereferencing pointer to incomplete
>> type
>> res_fax_spandsp.c:586: error: dereferencing pointer to incomplete
>> type
>> res_fax_spandsp.c: In function ?spandsp_fax_cli_show_session?:
>> res_fax_spandsp.c:675: error: dereferencing pointer to incomplete
>> type
>> res_fax_spandsp.c:675: error: dereferencing pointer to incomplete
>> type
>> make[1]: *** [res_fax_spandsp.o] Error 1
>> make: *** [res] Error 2
>>
>> kristijan
>
> I believe I have fixed this in the latests version. Please update
> your
> checkout and try again.
>
> --
> Matthew Nicholson
> Digium, Inc. | Software Developer
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 20 Jan 2010 16:06:49 -0600
> From: Asterisk Development Team <asteriskteam at digium.com>
> Subject: [asterisk-dev] DAHDI-Linux 2.2.1 and DAHDI-Tools 2.2.1
> Released
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> <asterisk-users at lists.digium.com>, Asterisk Developers list
> <asterisk-dev at lists.digium.com>, asterisk-announce at lists.digium.com
> Message-ID: <4B577E79.1000800 at digium.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The Asterisk Development Team is pleased to announce the release of
> DAHDI-Linux and DAHDI-Tools version 2.2.1.
>
> DAHDI-Linux 2.2.1, DAHDI-Tools 2.2.1, and DAHDI-Linux-Complete
> are available for immediate download at
> http://downloads.asterisk.org/pub/telephony/dahdi-linux
> http://downloads.asterisk.org/pub/telephony/dahdi-tools
> http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete
>
> These releases contain bug fixes and modifications to accommodate
> interface changes in Linux kernels up to 2.6.32. A few of the more
> noteworthy changes in these releases from the previous release
> are:
>
> * Reference counts are properly maintained on the echo canceller
> modules
> (issue #13504).
>
> * Better alarm debouncing for wct4xxp and wcte12xp drivers
> per AT&T 54016.
>
> * Support for extra HFC-4S and HFC-8S BRI cards in wcb4xxp.
>
> * dahdi_dummy will not lock up when a time-shift is detected (issue
> #15647).
>
> * T1 CAS support in the xpp "PRI" (E1/T1) module.
>
> * T1 CAS configuration generation support in dahdi_genconf. Default
> remains ISDN.
>
> * Much less verbose xpp firmware loading.
>
> * wcfxo resets DAA on initialization (issue #14232).
>
> * VPMADT032 firmware update to 1.20.
>
> For a full list of changes in these releases, please see the
> ChangeLogs at
> http://svn.asterisk.org/svn/dahdi/linux/tags/2.2.1/ChangeLog and
> http://svn.asterisk.org/svn/dahdi/tools/tags/2.2.1/ChangeLog
>
> Issues found in these releases can be reported at
> http://issues.asterisk.org
>
> Thank you for your continued support of Asterisk!
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 20 Jan 2010 22:22:34 -0000
> From: "David Vossel" <dvossel at digium.com>
> Subject: Re: [asterisk-dev] [Code Review]
> directmediapermit/directmediadeny support to restrict which peers
> can
> do directmedia based on ip address
> To: , "David Vossel" <dvossel at digium.com>, "Asterisk Developers"
> <asterisk-dev at lists.digium.com>
> Message-ID: <20100120222234.20099.59538 at hotblack.digium.internal>
> Content-Type: text/plain; charset="utf-8"
>
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/467/#review1384
> -----------------------------------------------------------
>
>
>
> /trunk/channels/chan_sip.c
> <https://reviewboard.asterisk.org/r/467/#comment3136>
>
> I don't understand the purpose of storing off olddirectmediaha if
> all we are concerned about is freeing it at the end of the
> function. If it isn't used anywhere, and the peer's directmediaha
> is set to NULL, why should we hold on to it? We do the same thing
> with oldha. Maybe I'm just missing something here.
>
>
> - David
>
>
> On 2010-01-20 04:05:13, raarts wrote:
>>
>> -----------------------------------------------------------
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviewboard.asterisk.org/r/467/
>> -----------------------------------------------------------
>>
>> (Updated 2010-01-20 04:05:13)
>>
>>
>> Review request for Asterisk Developers.
>>
>>
>> Summary
>> -------
>>
>> In some networks not all phones are fully routed, i.e. not all
>> phones can ping each other. This patch adds a way to restrict
>> directmedia for certain peers between certain networks. Only
>> implemented for the SIP channel.
>>
>> See https://issues.asterisk.org/view.php?id=16645
>>
>>
>> Diffs
>> -----
>>
>> /trunk/channels/chan_sip.c 241101
>> /trunk/configs/sip.conf.sample 241101
>> /trunk/main/acl.c 241101
>>
>> Diff: https://reviewboard.asterisk.org/r/467/diff
>>
>>
>> Testing
>> -------
>>
>> I tested this in our lab where phones where located on separate
>> VLAN's. The phones that were on the same VLAN talked directly to
>> eachother, and phones that weren't didn't.
>>
>>
>> Thanks,
>>
>> raarts
>>
>>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> --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
>
> End of asterisk-dev Digest, Vol 66, Issue 50
> ********************************************
More information about the asterisk-dev
mailing list