asterisk users - Sep 2007 - sip.conf best practices?

All - I've been wrestling with how to best structure the sip device
accounts on a new asterisk server I'm deploying.  All of the sip
devices (currently only Linksys SPA941s) will reside on the same
subnet as the server, and I have already set up a decent automatic
provisioning system for the phones.  When the rollout is complete,
there will be about 100 SIP devices authenticating and routing calls
through this server.  The question is what to use for the username
portion of the SIP account.

Part of me says that I should standardize on using each phone's MAC
address as the sip account UID, like so:

; Joe Smith, x123
[000E08DA0409]
secret = blahblah
... and so on and so forth

Doing it that way is nice for standardization's sake, but it makes the
dialplan quite a bit more complex.

The obvious alternative is to use the extension as the sip UID:

; Joe Smith, x123
[123]
secret = blahblah
...

This makes the dialplan *much* more simple, but when looking through
sip.conf, it's not as immediately obvious what device should be
authenticating with that account.

Since this is my first large-ish asterisk deployment, I'm seeking the
advice of those who have gone before me.  What tactic (one of the
above options or otherwise) is best to keep your sip.conf sane?

Thanks!
-Erik

-- 
Erik Anderson
http://andersonfam.org

Use the extension, and use grep to determine which account uses which
phone. For example I provision my spa9xx phones from a subdirectory on
apache called spa which on slackware is at: /var/www/htdocs/spa/
doing:
grep 123 /var/www/htdocs/spa/* will tell you which phone it is.

On 9/18/07, Erik Anderson <erikerik at gmail.com>
wrote:
> All - I've been wrestling with how to best structure the sip device
> accounts on a new asterisk server I'm deploying.  All of the sip
> devices (currently only Linksys SPA941s) will reside on the same
> subnet as the server, and I have already set up a decent automatic
> provisioning system for the phones.  When the rollout is complete,
> there will be about 100 SIP devices authenticating and routing calls
> through this server.  The question is what to use for the username
> portion of the SIP account.
>
> Part of me says that I should standardize on using each phone's MAC
> address as the sip account UID, like so:
>
> ; Joe Smith, x123
> [000E08DA0409]
> secret = blahblah
> ... and so on and so forth
>
> Doing it that way is nice for standardization's sake, but it makes the
> dialplan quite a bit more complex.
>
> The obvious alternative is to use the extension as the sip UID:
>
> ; Joe Smith, x123
> [123]
> secret = blahblah
> ...
>
> This makes the dialplan *much* more simple, but when looking through
> sip.conf, it's not as immediately obvious what device should be
> authenticating with that account.
>
> Since this is my first large-ish asterisk deployment, I'm seeking the
> advice of those who have gone before me.  What tactic (one of the
> above options or otherwise) is best to keep your sip.conf sane?
>
> Thanks!
> -Erik
>
> --
> Erik Anderson
> http://andersonfam.org
>
> _______________________________________________
>
> Sign up now for AstriCon 2007!  September 25-28th. 
http://www.astricon.net/
>
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>

Realtime and sip_buddies in mysql works well for very large
installations.

PaulH

On Tue, 2007-09-18 at 22:11 -0500, Erik Anderson wrote:
> All - I've been wrestling with how to best structure the sip device
> accounts on a new asterisk server I'm deploying.  All of the sip
> devices (currently only Linksys SPA941s) will reside on the same
> subnet as the server, and I have already set up a decent automatic
> provisioning system for the phones.  When the rollout is complete,
> there will be about 100 SIP devices authenticating and routing calls
> through this server.  The question is what to use for the username
> portion of the SIP account.
> 
> Part of me says that I should standardize on using each phone's MAC
> address as the sip account UID, like so:
> 
> ; Joe Smith, x123
> [000E08DA0409]
> secret = blahblah
> ... and so on and so forth
> 
> Doing it that way is nice for standardization's sake, but it makes the
> dialplan quite a bit more complex.
> 
> The obvious alternative is to use the extension as the sip UID:
> 
> ; Joe Smith, x123
> [123]
> secret = blahblah
> ...
> 
> This makes the dialplan *much* more simple, but when looking through
> sip.conf, it's not as immediately obvious what device should be
> authenticating with that account.
> 
> Since this is my first large-ish asterisk deployment, I'm seeking the
> advice of those who have gone before me.  What tactic (one of the
> above options or otherwise) is best to keep your sip.conf sane?
> 
> Thanks!
> -Erik
>

>The obvious alternative is to use the extension as the sip UID:
Use the extension as the UID and add the mac address as a comment. Like so:

[123]
; Joe Smith
;mac=000E08DA0409
secret = blahblah
... and so on and so forth

This will give the best of both worlds. The mac is readily available and the
dialplan is clear. I usually try to go one further and setup dhcp to set the
last octet of the IP address to the extension number. This makes it easy to
point a browser to the phone for configuration as well.

John

We use the MAC of the phone (all lower case) with a -a, -b, -c, etc 
tacked onto the end of the MAC to specify the line appearance.

One thing you MUST remember is that a sip.conf entry is NOT an 
extension.  Extensions are totally different from sip.conf entries. 
sip.conf entries are DEVICES.

Using the extension as the SIP account ID will cause MORE work as you 
have requests for oddball and custom call routing.

We do something like this as an extension:

exten => 3727,1,Set(FAX_DEST=pmas at stirling.org)
exten => 3727,n,Set(DIAL_DEST=SIP/0004f211f9a6-a)
exten => 3727,n,Set(CFBL_DEST=SIP/0004f211f9a6-b)
exten => 3727,n,Macro(std-exten-v2)

The std-exten-v2 handles the call based on the variables set before the 
macro is run.

Here is another example:

exten => 3733,1,Set(DIAL_DEST=SIP/0004f2127e9c-a)
exten => 3733,n,Set(CFBL_DEST==SIP/0004f2127e9c-b)
exten => 3733,n,Set(CFNA_DEST=Local/912124012455 at local-access)
exten => 3733,n,Set(OPER_DEST=Local/912124012455 at local-access)
exten => 3733,n,Set(FAX_DEST=bshelton at era.com)
exten => 3733,n,Macro(std-exten-v2)


Telecom newbies seem to think dialplans can be simple or short or 
elegant.  They are not.  Dialplans are ugly and complex beasts.  Users 
want custom call routing, users want this, users want that, etc.  No 
matter how hard you try to make your dialplan simple, it won't stay that 
way.



Erik Anderson wrote:
> All - I've been wrestling with how to best structure the sip device
> accounts on a new asterisk server I'm deploying.  All of the sip
> devices (currently only Linksys SPA941s) will reside on the same
> subnet as the server, and I have already set up a decent automatic
> provisioning system for the phones.  When the rollout is complete,
> there will be about 100 SIP devices authenticating and routing calls
> through this server.  The question is what to use for the username
> portion of the SIP account.
> 
> Part of me says that I should standardize on using each phone's MAC
> address as the sip account UID, like so:
> 
> ; Joe Smith, x123
> [000E08DA0409]
> secret = blahblah
> ... and so on and so forth
> 
> Doing it that way is nice for standardization's sake, but it makes the
> dialplan quite a bit more complex.
> 
> The obvious alternative is to use the extension as the sip UID:
> 
> ; Joe Smith, x123
> [123]
> secret = blahblah
> ...
> 
> This makes the dialplan *much* more simple, but when looking through
> sip.conf, it's not as immediately obvious what device should be
> authenticating with that account.
> 
> Since this is my first large-ish asterisk deployment, I'm seeking the
> advice of those who have gone before me.  What tactic (one of the
> above options or otherwise) is best to keep your sip.conf sane?
> 
> Thanks!
> -Erik
>

Erik Anderson wrote:
> All - I've been wrestling with how to best structure the sip device
> accounts on a new asterisk server I'm deploying.  All of the sip
> devices (currently only Linksys SPA941s) will reside on the same
> subnet as the server, and I have already set up a decent automatic
> provisioning system for the phones.  When the rollout is complete,
> there will be about 100 SIP devices authenticating and routing calls
> through this server.  The question is what to use for the username
> portion of the SIP account.
>
> Part of me says that I should standardize on using each phone's MAC
> address as the sip account UID, like so:
>
> ; Joe Smith, x123
> [000E08DA0409]
> secret = blahblah
> ... and so on and so forth
>
> Doing it that way is nice for standardization's sake, but it makes the
> dialplan quite a bit more complex.
>
> The obvious alternative is to use the extension as the sip UID:
>
> ; Joe Smith, x123
> [123]
> secret = blahblah
> ...
>
> This makes the dialplan *much* more simple, but when looking through
> sip.conf, it's not as immediately obvious what device should be
> authenticating with that account.
>
> Since this is my first large-ish asterisk deployment, I'm seeking the
> advice of those who have gone before me.  What tactic (one of the
> above options or otherwise) is best to keep your sip.conf sane?
>
> Thanks!
> -Erik
>
>   
Hi Erik,

We have around 100 devices and most of our changes are adds for new 
users/devices with occasional re-assignment of devices. We manage our  
users and devices with some simple scripts and good old vi for exceptions.

Our extensions.conf has a list of global vars that tie an extension to a 
sip (or iax, or whatever) device. (I think this is straight from TFOT v1)

eg EXT_100=SIP/100

This allows us to redirect extensions to different devices or make 
extensions ring on multiple devices by changing that var alone (no need 
to alter macros or other dialplan elements)

eg EXT_100=SIP/101&SIP/102

The device-specific hardware and the SIP configurations are generated 
from a master "map" that contains a line per device including
technology
and extension, MAC, user display name and email address.

Scripts create the phone hardware configs with device type determined by 
MAC address (eg. Aastra, Grandstream or Cisco) from the "map" file and
add the user to sip.conf and voicemail.conf.

sip.conf ...

[grandstream]
; Aastra 480i phones for general office
... (general SIP settings)
context=office-dial

[aastra-cc]
; Aastra 480i phones for Call Centre only
... (general SIP settings)
context=cc-dial

[100](grandstream)
username=100
secret=*******
mailbox=100
callerid="Joe Bloggs" <100>

[101](aastra-cc)
username=101
secret=*******
mailbox=101
callerid="Agent 99" <101>


Initially we only had one "class" of user, general office types using 
Grandstreams. When we migrated the Call Centre to Asterisk, they were 
the only users with Aastra phones, apart from one or two in the general 
office. So each "class" of user had a different hardware type and was 
easy to automate, the exceptions are currently handled with manual edits.

This system is working well and is stable but not sufficiently flexible 
for the future. Our company is growing rapidly and since we will no 
longer be buying Grandstream devices, more Aastras are appearing in the 
general office environment. This means we now have two "classes" of 
users that require different configs for the same device type, general 
office users and Call Centre agents.  This means a choice will have to 
be made between updating the scripts to cope with the two user classes 
or moving to realtime. Where's my Magic 8-ball... :-)

regards,

Drew

-- 
Drew Gibson

Systems Administrator
OANDA Corporation
www.oanda.com

Hi all,

I have an interesting problem with Asterisk 1.4.11 - 3 SIP phones:

[phone1]
allow=g722
allow=alaw
....

[phone2]
allow=alaw
allow=g722
....

[phone3]
allow=alaw


Now, when I try to call:
1. phone1 calling phone2, I got through, using G.722 codec
2. phone2 calling phone1, I get through, using Alaw
3. phone3 calling phone1 or phone2, OK using Alaw
But:
4. phone1 calling phone3 fails:

[Sep 20 10:14:32] WARNING[30706]: chan_sip.c:2963 sip_call: No audio
format found to offer. Cancelling call to phone3


Any ideas what could be wrong?
Many thanks for any suggestion....

Ondrej

The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you
are not an intended recipient, you must not use, disclose, copy, distribute or
retain this e-mail or any part thereof. If you have received this e-mail in
error, please notify the sender by return e-mail and delete all copies of this
e-mail from your computer system(s).
Please direct any additional queries to: communications at s3group.com.
Thank You.

Ondrej Valousek wrote:
> [Sep 20 10:14:32] WARNING[30706]: chan_sip.c:2963 sip_call: No audio
> format found to offer. Cancelling call to phone3
Asterisk 1.4 does not have G.722 transcoding, only passthrough support.
It can connect G.722 channels together, and record or playback G.722
audio files, but that is all.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)

Well I know.
My problem is, that the phone offering g722 could do alaw as well.
I expected asterisk should just chose alaw for the communication - no
transcoding is necessary then...

Please help.
Thanks,

Ondrej

Kevin P. Fleming wrote:
> Ondrej Valousek wrote:
>
>   
>> [Sep 20 10:14:32] WARNING[30706]: chan_sip.c:2963 sip_call: No audio
>> format found to offer. Cancelling call to phone3
>>     
>
> Asterisk 1.4 does not have G.722 transcoding, only passthrough support.
> It can connect G.722 channels together, and record or playback G.722
> audio files, but that is all.
>
>   

The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you
are not an intended recipient, you must not use, disclose, copy, distribute or
retain this e-mail or any part thereof. If you have received this e-mail in
error, please notify the sender by return e-mail and delete all copies of this
e-mail from your computer system(s).
Please direct any additional queries to: communications at s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown,
Dublin 18

Ondrej Valousek wrote:
> My problem is, that the phone offering g722 could do alaw as well.
> I expected asterisk should just chose alaw for the communication - no
> transcoding is necessary then...
That is not how Asterisk works, and is well known in the community as
something that users would like to see changed, but has not yet been
done. Asterisk negotiates the codecs (formats) for each call leg pretty
much independently of the others, so if a G.722 endpoint initiates the
first call leg, and the destination call leg cannot accept G.722, and
there is no transcoder available, then the call will fail. If the
non-G.722 endpoint initiates the first call leg then the call will
likely go through, which is somewhat unfortunate :-)

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)

Hi Kevin,

Thanks for the answer - Hopefully this feature will be available some
day. My opinion is, look for a transcoder only if the two (or more)
parties does not offer any matching codec.
Good to hear it is being worked on....
Best regards,

Ondrej

Kevin P. Fleming wrote:
> Ondrej Valousek wrote:
>
>   
>> My problem is, that the phone offering g722 could do alaw as well.
>> I expected asterisk should just chose alaw for the communication - no
>> transcoding is necessary then...
>>     
>
> That is not how Asterisk works, and is well known in the community as
> something that users would like to see changed, but has not yet been
> done. Asterisk negotiates the codecs (formats) for each call leg pretty
> much independently of the others, so if a G.722 endpoint initiates the
> first call leg, and the destination call leg cannot accept G.722, and
> there is no transcoder available, then the call will fail. If the
> non-G.722 endpoint initiates the first call leg then the call will
> likely go through, which is somewhat unfortunate :-)
>
>   

The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you
are not an intended recipient, you must not use, disclose, copy, distribute or
retain this e-mail or any part thereof. If you have received this e-mail in
error, please notify the sender by return e-mail and delete all copies of this
e-mail from your computer system(s).
Please direct any additional queries to: communications at s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown,
Dublin 18

I would like to point out that G.722 is a really awesome codec for  
wideband.  Asterisk has some changes that will need to be made to  
support variable audio rates.  We did this in FreeSWITCH from the  
start.  I think Asterisk will be doing similar things to bridge an 8k  
to 16k channel via resample.  FreeSWITCH can already do this so you  
could use FreeSWITCH in conjunction with Asterisk to solve this for  
now.  FreeSWITCH can also do Wideband conferencing.  In addition you  
can mix and match 8k and 16k conference participants.  Just thought I  
would throw that out there as a way to bridge the gap.

/b

On Oct 5, 2007, at 1:13 AM, Ondrej Valousek wrote:
> Hi Kevin,
>
> Thanks for the answer - Hopefully this feature will be available some
> day. My opinion is, look for a transcoder only if the two (or more)
> parties does not offer any matching codec.
> Good to hear it is being worked on....
> Best regards,
>
> Ondrej
>
> Kevin P. Fleming wrote:
>> Ondrej Valousek wrote:
>>
>>
>>> My problem is, that the phone offering g722 could do alaw as well.
>>> I expected asterisk should just chose alaw for the communication  
>>> - no
>>> transcoding is necessary then...
>>>
>>
>> That is not how Asterisk works, and is well known in the community as
>> something that users would like to see changed, but has not yet been
>> done. Asterisk negotiates the codecs (formats) for each call leg  
>> pretty
>> much independently of the others, so if a G.722 endpoint initiates  
>> the
>> first call leg, and the destination call leg cannot accept G.722, and
>> there is no transcoder available, then the call will fail. If the
>> non-G.722 endpoint initiates the first call leg then the call will
>> likely go through, which is somewhat unfortunate :-)
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071005/8315bf6f/attachment.htm

Hi Brian,

No I do not need g722 that seriously - I just thought - we all in the
company have phones that support it, we are all on switched LAN (so
bandwidth is not a problem) - so why not use it?
At this point I would like to know why you think it is awesome? I know
the are some extensions/improvements to this codec but these are
unfortunately not free so no use for asterisk.

Thanks,
Ondrej

Brian West wrote:
> I would like to point out that G.722 is a really awesome codec for
> wideband.  Asterisk has some changes that will need to be made to
> support variable audio rates.  We did this in FreeSWITCH from the
> start.  I think Asterisk will be doing similar things to bridge an 8k
> to 16k channel via resample.  FreeSWITCH can already do this so you
> could use FreeSWITCH in conjunction with Asterisk to solve this for
> now.  FreeSWITCH can also do Wideband conferencing.  In addition you
> can mix and match 8k and 16k conference participants.  Just thought I
> would throw that out there as a way to bridge the gap.
>
> /b
>
> On Oct 5, 2007, at 1:13 AM, Ondrej Valousek wrote:
>
>> Hi Kevin,
>>
>>
>> Thanks for the answer - Hopefully this feature will be available some
>>
>> day. My opinion is, look for a transcoder only if the two (or more)
>>
>> parties does not offer any matching codec.
>>
>> Good to hear it is being worked on....
>>
>> Best regards,
>>
>>
>> Ondrej
>>
>>
>> Kevin P. Fleming wrote:
>>
>>> Ondrej Valousek wrote:
>>>
>>>
>>>
>>>> My problem is, that the phone offering g722 could do alaw as
well.
>>>>
>>>> I expected asterisk should just chose alaw for the
communication - no
>>>>
>>>> transcoding is necessary then...
>>>>
>>>>
>>>
>>> That is not how Asterisk works, and is well known in the community
as
>>>
>>> something that users would like to see changed, but has not yet
been
>>>
>>> done. Asterisk negotiates the codecs (formats) for each call leg
pretty
>>>
>>> much independently of the others, so if a G.722 endpoint initiates
the
>>>
>>> first call leg, and the destination call leg cannot accept G.722,
and
>>>
>>> there is no transcoder available, then the call will fail. If the
>>>
>>> non-G.722 endpoint initiates the first call leg then the call will
>>>
>>> likely go through, which is somewhat unfortunate :-)
>>>
>>>
>>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you
are not an intended recipient, you must not use, disclose, copy, distribute or
retain this e-mail or any part thereof. If you have received this e-mail in
error, please notify the sender by return e-mail and delete all copies of this
e-mail from your computer system(s).
Please direct any additional queries to: communications at s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown,
Dublin 18

You can hear and understand someone much better with g722... more  
emotion is transfered over the phone when using g722.

G722 is free and in the clear. G722.1 and G722.2 are not.

We have the G722 code in FreeSWITCH donated to us by Steve  
Underwood.  What a great guy.

/b

On Oct 5, 2007, at 8:05 AM, Ondrej Valousek wrote:
> At this point I would like to know why you think it is awesome? I know
> the are some extensions/improvements to this codec but these are
> unfortunately not free so no use for asterisk.
>
> Thanks,
> Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071005/66a2ab4d/attachment.htm

On Fri, Oct 05, 2007 at 08:12:34AM -0500, Brian West
wrote:
> You can hear and understand someone much better with g722... more  
> emotion is transfered over the phone when using g722.
> 
> G722 is free and in the clear. G722.1 and G722.2 are not.
But speex *Is* free. Including wideband.

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

Bad translation - I understood "awesome" = bad :-)
I agree - That is why I wanted to start using it asap - hopefully the
full support in Asterisk will be here soon.
O.

Brian West wrote:
> You can hear and understand someone much better with g722... more
> emotion is transfered over the phone when using g722.
>
> G722 is free and in the clear. G722.1 and G722.2 are not.
>
> We have the G722 code in FreeSWITCH donated to us by Steve Underwood. 
> What a great guy.
>
> /b
>
> On Oct 5, 2007, at 8:05 AM, Ondrej Valousek wrote:
>
>> At this point I would like to know why you think it is awesome? I know
>>
>> the are some extensions/improvements to this codec but these are
>>
>> unfortunately not free so no use for asterisk.
>>
>>
>> Thanks,
>>
>> Ondrej
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you
are not an intended recipient, you must not use, disclose, copy, distribute or
retain this e-mail or any part thereof. If you have received this e-mail in
error, please notify the sender by return e-mail and delete all copies of this
e-mail from your computer system(s).
Please direct any additional queries to: communications at s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: Whelan House, South County Business Park, Leopardstown,
Dublin 18

But its way too heavy on the CPU.

/b

On Oct 5, 2007, at 8:34 AM, Tzafrir Cohen wrote:
>
> But speex *Is* free. Including wideband.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071005/b3bdcc4d/attachment.htm

Tzafrir Cohen wrote:
> On Fri, Oct 05, 2007 at 08:12:34AM -0500, Brian West wrote:
>> You can hear and understand someone much better with g722... more  
>> emotion is transfered over the phone when using g722.
>>
>> G722 is free and in the clear. G722.1 and G722.2 are not.
> 
> But speex *Is* free. Including wideband.
> 
How many hardware vendors do support Speex ? From small gateways to big 
trunking gateways ?
I suspect Wideband is one amazing value-proposition for VOIP, in 
countries where bandwidth savings is not the problem to be solved anymore.

Brian West wrote:
> I would like to point out that G.722 is a really awesome codec for 
> wideband.  Asterisk has some changes that will need to be made to 
> support variable audio rates.  We did this in FreeSWITCH from the 
> start.  I think Asterisk will be doing similar things to bridge an 8k 
> to 16k channel via resample.  FreeSWITCH can already do this so you 
> could use FreeSWITCH in conjunction with Asterisk to solve this for 
> now.  FreeSWITCH can also do Wideband conferencing.  In addition you 
> can mix and match 8k and 16k conference participants.  Just thought I 
> would throw that out there as a way to bridge the gap.
Its not that great. MP3 at the same bit rate would be considerably 
better. :-) It is, however, unencumbered and not massively heavy in 
compute load.

Steve