[asterisk-dev] asterisk-dev Digest, Vol 63, Issue 52
Justin Newman
nt_jnewman at yahoo.com
Thu Oct 22 14:04:56 CDT 2009
-----Original Message-----
From: asterisk-dev-request at lists.digium.com
Date: Thu, 22 Oct 2009 09:47:24
To: <asterisk-dev at lists.digium.com>
Subject: asterisk-dev Digest, Vol 63, Issue 52
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: [Code Review] SIP: Pineapple (Michiel van Baak)
2. Re: [Code Review] SIP: Pineapple (Kevin P. Fleming)
3. Re: [Code Review] SIP: Pineapple (Alexander Harrowell)
4. Re: [Code Review] SIP: Pineapple (Tzafrir Cohen)
5. Re: [Code Review] SIP: Pineapple (Kevin P. Fleming)
6. Re: [Code Review] SIP: Pineapple (Nick Lewis)
7. Choppy Audio with JACK (app_jack) (Esben Stien)
8. Re: Choppy Audio with JACK (app_jack) (russell at digium.com)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Oct 2009 13:18:41 +0200
From: Michiel van Baak <michiel at vanbaak.info>
Subject: Re: [asterisk-dev] [Code Review] SIP: Pineapple
To: asterisk-dev at lists.digium.com
Message-ID: <20091022111840.GA17003 at shellbox.vanbaak.info>
Content-Type: text/plain; charset=us-ascii
On 11:20, Thu 22 Oct 09, Alexander Harrowell wrote:
> On Thursday 22 October 2009 10:47:18 Olle E. Johansson wrote:
> > 22 okt 2009 kl. 11.30 skrev Nick Lewis:
> > > oej
> > >
> > > re new types: I like the proposal to have peer types related to the
> > > actual network architecture rather than the barmy type=user/peer/
> > > friend
> > > but I find the actual words you have chosen to be confusing. The
> > > relationship that you name "service" is what I regard as a sip trunk
> > > and
> > > which I get from my internet telephony service provider.
>
> Yes - is it really a common use case to have end points or trunks that are
> one-way (as the current typing implies)? I'm sure there will be fancy
> deployments that have phones attached that are only ever used for inbound, or
> that send their outbound traffic to a different carrier than they receive inbound
> from. But I would suspect 90-odd % of Asterisk instances have a SIP carrier on
> one side carrying both inbound and outbound (i.e. a "friend" in currentspeak)
> and Linksys desk phones on the other that both receive and place calls.
No.
It's pretty common to have a couple of ITSP's configured to do
least-cost-routing based on the number you are calling.
One of the ITSP's will be responsible for inbound calls on your main
numbers.
But in mosts setups we did we have more of those because of DID's in
different countries etc.
And we have a good couple of setups that have an asterisk box specific
for routing, it grabs the calls from ITSP and landlines and routes those
calls to other boxen. Most of them use a different route when setting up
an outbound call.
Many many possibilities that dont match the simple setup you described.
> _______________________________________________
> --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
--
Michiel van Baak
michiel at vanbaak.eu
http://michiel.vanbaak.eu
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD
"Why is it drug addicts and computer aficionados are both called users?"
------------------------------
Message: 2
Date: Thu, 22 Oct 2009 07:20:27 -0500
From: "Kevin P. Fleming" <kpfleming at digium.com>
Subject: Re: [asterisk-dev] [Code Review] SIP: Pineapple
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <4AE04E0B.3020102 at digium.com>
Content-Type: text/plain; charset=ISO-8859-1
Nick Lewis wrote:
>> The whole pedantic option needs to go away and be the default mode.
>> Always.
>
> +1
Along that line, I'm a couple of days away from being able to make
'pedantic mode dialog matching' the default, which required adding some
functionality to astobj2 so that pedantic-mode matching would no longer
require traversing the entire container of SIP dialogs. In addition,
this patch will add parsing and matching of Via header branch-ID tags,
which will solve some problems that occur when Asterisk receives forked
requests from SIP proxies.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org
------------------------------
Message: 3
Date: Thu, 22 Oct 2009 13:28:39 +0100
From: Alexander Harrowell <alexander.harrowell at stlpartners.com>
Subject: Re: [asterisk-dev] [Code Review] SIP: Pineapple
To: asterisk-dev at lists.digium.com
Message-ID: <200910221328.55004.alexander.harrowell at stlpartners.com>
Content-Type: text/plain; charset="iso-8859-1"
On Thursday 22 October 2009 12:18:41 Michiel van Baak wrote:
>
> No.
> It's pretty common to have a couple of ITSP's configured to do
> least-cost-routing based on the number you are calling.
> One of the ITSP's will be responsible for inbound calls on your main
> numbers.
> But in mosts setups we did we have more of those because of DID's in
> different countries etc.
>
> And we have a good couple of setups that have an asterisk box specific
> for routing, it grabs the calls from ITSP and landlines and routes those
> calls to other boxen. Most of them use a different route when setting up
> an outbound call.
>
> Many many possibilities that dont match the simple setup you described.
>
Indeed, and there's no reason not to cater for them. It just seems deeply
weird to have a syntax so very different from the way SIP, and telephony in
general, usually works. User/peer/friend doesn't, for example, make any
distinction between an end point and a router.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20091022/68088f34/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20091022/68088f34/attachment-0001.pgp
------------------------------
Message: 4
Date: Thu, 22 Oct 2009 14:52:29 +0200
From: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
Subject: Re: [asterisk-dev] [Code Review] SIP: Pineapple
To: asterisk-dev at lists.digium.com
Message-ID: <20091022125229.GZ3144 at xorcom.com>
Content-Type: text/plain; charset=us-ascii
On Thu, Oct 22, 2009 at 07:20:27AM -0500, Kevin P. Fleming wrote:
> Nick Lewis wrote:
>
> >> The whole pedantic option needs to go away and be the default mode.
> >> Always.
> >
> > +1
>
> Along that line, I'm a couple of days away from being able to make
> 'pedantic mode dialog matching' the default, which required adding some
> functionality to astobj2 so that pedantic-mode matching would no longer
> require traversing the entire container of SIP dialogs. In addition,
> this patch will add parsing and matching of Via header branch-ID tags,
> which will solve some problems that occur when Asterisk receives forked
> requests from SIP proxies.
I guess some people really need that functionality.
But is all of it needed?
;pedantic=yes ; Enable checking of tags in headers,
; international character conversions in URIs
; and multiline formatted headers for strict
; SIP compatibility (defaults to "no")
If there a reasonable chance that a potential broken device that needs
such a backward-compatibility[1] option actually diverts from the
standard in all fronts? Or would it make sense to split it into several
sub-options (technically: make it a bit field)?
[1] Be compatible with those who got things backwards.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
------------------------------
Message: 5
Date: Thu, 22 Oct 2009 08:07:01 -0500
From: "Kevin P. Fleming" <kpfleming at digium.com>
Subject: Re: [asterisk-dev] [Code Review] SIP: Pineapple
To: asterisk-dev at lists.digium.com
Message-ID: <4AE058F5.7040106 at digium.com>
Content-Type: text/plain; charset=ISO-8859-1
Tzafrir Cohen wrote:
> If there a reasonable chance that a potential broken device that needs
> such a backward-compatibility[1] option actually diverts from the
> standard in all fronts? Or would it make sense to split it into several
> sub-options (technically: make it a bit field)?
In the 5+ years I've been involved with Asterisk, I cannot remember any
case where someone enabled pedantic mode and then had to disable it
because a device was unable to interoperate with Asterisk. With that
said, though, the vast majority of Asterisk systems never have pedantic
mode enabled, so that's not a very representative sample of the possible
endpoint problems we might experience.
Given what 'pedantic' currently controls, I really can't come up with
any scenarios where an endpoint could expect us to work properly by
*not* doing the pedantic checking/parsing. All of the pedantic toggles
just increase Asterisk's RFC compliance.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming at digium.com
Check us out at www.digium.com & www.asterisk.org
------------------------------
Message: 6
Date: Thu, 22 Oct 2009 14:24:20 +0100
From: "Nick Lewis" <Nick.Lewis at atltelecom.com>
Subject: Re: [asterisk-dev] [Code Review] SIP: Pineapple
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Message-ID: <3F97ACBE506F6849A6AEDA62A123928F385A82 at email.atl.local>
Content-Type: text/plain; charset="us-ascii"
>In the 5+ years I've been involved with Asterisk, I cannot remember any
>case where someone enabled pedantic mode and then had to disable it
>because a device was unable to interoperate with Asterisk. With that
>said, though, the vast majority of Asterisk systems never have pedantic
>mode enabled, so that's not a very representative sample of the
possible
>endpoint problems we might experience.
I first enabled pedantics because (i) my phones produced multiline
headers and (ii) I needed to dial numbers containing a hash. Bizarrely
asterisk rejects correctly escaped # characters unless pedantics is
enabled. One might have assumed that it would accept both escaped and
unescaped hash characters when pedantic=no but accept only correctly
escaped hash characters when pedantic=yes
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.
_____________________________________________________________________
Disclaimer of Liability
ATL Telecom Ltd shall not be held liable for any improper or incorrect use of the information described and/or contained herein and assumes no responsibility for anyones use of the information. In no event shall ATL Telecom Ltd be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement or substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this system, even if advised of the possibility of such damage.
Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons Cardiff, CF3 0FB
Registered in Wales Number 4335781
All goods and services supplied by ATL Telecom Ltd are supplied subject to ATL Telecom Ltd standard terms and conditions, available upon request.
------------------------------
Message: 7
Date: Thu, 22 Oct 2009 16:33:37 +0200
From: Esben Stien <b0ef at esben-stien.name>
Subject: [asterisk-dev] Choppy Audio with JACK (app_jack)
To: asterisk-dev at lists.digium.com
Message-ID: <87my3j7b26.fsf at quasar.esben-stien.name>
Content-Type: text/plain; charset=us-ascii
I'm playing with the app_jack module and experience very noisy choppy
audio.
It seems to setup the JACK channels fine, but the audio has lots of
dropouts.
In the terminal, I get repeatedly this message:
[Oct 22 16:07:06] ERROR[29065]: app_jack.c:559 queue_voice_frame: Output
buffer filled ... need to increase its size
..while the conversation is active.
The sample rate conversion seems fine. I inserted a log call after the
resample_factor was set:
*resample_factor = to_srate / from_srate;
ast_log(LOG_ERROR,"factor=%f \n",*resample_factor);
..which outputs:
[Oct 22 16:07:06] ERROR[29065]: app_jack.c:221 alloc_resampler: factor=12.000000
[Oct 22 16:07:06] ERROR[29068]: app_jack.c:221 alloc_resampler: factor=0.083333
I run JACK at 96kHz, which factor here confirms to have found. 8kHz*12=96kHz.
I'm running on GNU/Linux with asterisk-SVN from today. I'm running
jack-1.9.4 (SVN).
I have quite an extensive setup of JACK apps, so I know that JACK itself
is not a problem.
Any pointers as to what I can try?.
--
Esben Stien is b0ef at e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
------------------------------
Message: 8
Date: Thu, 22 Oct 2009 09:47:23 -0500 (CDT)
From: russell at digium.com
Subject: Re: [asterisk-dev] Choppy Audio with JACK (app_jack)
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <D13B235B-5FCC-4554-B541-1B938F6A6E69 at digium.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
It looks to be as simple as needing to increase the buffer size in
between Asterisk and JACK. I never tested with a sample rate anywhere
close to 96 kHz. I'm not at a computer so I can't point to the exact
code right now.
I wonder if I made the buffers a static size. We should have them as
a dynamic size based on the sample rate in use. I am traveling this
weekend, but I will take a look when I get to a computer.
--
Russell Bryant
(Sent from mobile device)
On Oct 22, 2009, at 8:44 AM, Esben Stien <b0ef at esben-stien.name> wrote:
> I'm playing with the app_jack module and experience very noisy choppy
> audio.
>
> It seems to setup the JACK channels fine, but the audio has lots of
> dropouts.
>
> In the terminal, I get repeatedly this message:
>
> [Oct 22 16:07:06] ERROR[29065]: app_jack.c:559 queue_voice_frame:
> Output
> buffer filled ... need to increase its size
>
> ..while the conversation is active.
>
> The sample rate conversion seems fine. I inserted a log call after the
> resample_factor was set:
>
> *resample_factor = to_srate / from_srate;
> ast_log(LOG_ERROR,"factor=%f \n",*resample_factor);
>
> ..which outputs:
>
> [Oct 22 16:07:06] ERROR[29065]: app_jack.c:221 alloc_resampler:
> factor=12.000000
> [Oct 22 16:07:06] ERROR[29068]: app_jack.c:221 alloc_resampler:
> factor=0.083333
>
> I run JACK at 96kHz, which factor here confirms to have found.
> 8kHz*12=96kHz.
>
> I'm running on GNU/Linux with asterisk-SVN from today. I'm running
> jack-1.9.4 (SVN).
>
> I have quite an extensive setup of JACK apps, so I know that JACK
> itself
> is not a problem.
>
> Any pointers as to what I can try?.
>
> --
> Esben Stien is b0ef at e s a
> http://www. s t n m
> irc://irc. b - i . e/%23contact
> sip:b0ef@ e e
> jid:b0ef@ n n
>
> _______________________________________________
> --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
End of asterisk-dev Digest, Vol 63, Issue 52
********************************************
More information about the asterisk-dev
mailing list