[asterisk-users] Codec opus returned invalid number of samples

[Fourhundred Thecat]

Hello,

I am getting these warnings in the logs when using linphone client:

  WARNING: Codec opus returned invalid number of samples

these are probably harmless warnings (the call works fine), but it just
floods the logs unnecessarily

any way to fix this problem, or suppress the warnings?


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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Codec question

[Eric Wieling]

turn off g726.

On 6/17/20 4:34 PM, Jerry Geis wrote:

Ok - updating the firmware on teh device - factory reset, re-config.
Capabilities: us - (g726|slin16|ulaw|alaw|gsm), peer - 
audio=(ulaw|alaw|g726|slin16)/video=(nothing)/text=(nothing), combined - 
(g726|slin16|ulaw|alaw)

Looking much better.

Jerry

On Wed, Jun 17, 2020 at 4:01 PM Jerry Geis > wrote:


I thought - what about the software - maybe it needs updated.
After doing so I get a list:

Audio codecs
PCMU (8000 Hz)
PCMA (8000 Hz)
opus (48000 Hz)
L16/16000 (16000 Hz)
G.726-32 (8000 Hz)
L16/8000 (8000 Hz)
speex/16000 (16000 Hz)
speex/8000 (8000 Hz)




--
http://help.nyigc.net/

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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Codec question

[Jerry Geis]

Ok - updating the firmware on teh device - factory reset, re-config.
Capabilities: us - (g726|slin16|ulaw|alaw|gsm), peer -
audio=(ulaw|alaw|g726|slin16)/video=(nothing)/text=(nothing), combined -
(g726|slin16|ulaw|alaw)
Looking much better.

Jerry

On Wed, Jun 17, 2020 at 4:01 PM Jerry Geis  wrote:

> I thought - what about the software - maybe it needs updated.
> After doing so I get a list:
>
> Audio codecs
> PCMU (8000 Hz)
> PCMA (8000 Hz)
> opus (48000 Hz)
> L16/16000 (16000 Hz)
> G.726-32 (8000 Hz)
> L16/8000 (8000 Hz)
> speex/16000 (16000 Hz)
> speex/8000 (8000 Hz)
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Codec question

[Jerry Geis]

I thought - what about the software - maybe it needs updated.
After doing so I get a list:

Audio codecs
PCMU (8000 Hz)
PCMA (8000 Hz)
opus (48000 Hz)
L16/16000 (16000 Hz)
G.726-32 (8000 Hz)
L16/8000 (8000 Hz)
speex/16000 (16000 Hz)
speex/8000 (8000 Hz)
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Codec question

[Jerry Geis]

Docs said this:
Audio Codecs: G.711, G.726, WAV, MP3.

This is all it shows:
Got SDP version 3801411990 and unique parts [- 3801411989 IN IP4
192.168.2.3]
Found RTP audio format 0
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|alaw|gsm), peer -
audio=(ulaw)/video=(nothing)/text=(nothing), combined - (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1
(telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.2.3:4138

Something is not right.

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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Codec question

[George Joseph]

On Wed, Jun 17, 2020 at 11:13 AM Jerry Geis  wrote:

> I see this device :
> Axis C8033 Audio Bridge Quick Specs:
> Communications Protocol: SIP.
> Ethernet Ports: 1x 10/100.
> PoE: 802.3af/at Type 1 Class 2.
> Additional Interfaces:
> Audio: one-way/two-way, mono.
> Audio Codecs: G.711, G.726, WAV, MP3.
> Edge Storage: microSD, microSDHC, microSDXC.
> Operating Temperature: 4°F - 122°F.
>
> What is Codec WAV and MP3  to asterisk ???
>

The literals "wav" and "mp3" are unknown as far as media handling goes.
 We'd need to see what payload types they translate them to.   If you can
get a real SDP from one of those devices we could say more.



>
> Jerry
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users



-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Codec question

[Jerry Geis]

I see this device :
Axis C8033 Audio Bridge Quick Specs:
Communications Protocol: SIP.
Ethernet Ports: 1x 10/100.
PoE: 802.3af/at Type 1 Class 2.
Additional Interfaces:
Audio: one-way/two-way, mono.
Audio Codecs: G.711, G.726, WAV, MP3.
Edge Storage: microSD, microSDHC, microSDXC.
Operating Temperature: 4°F - 122°F.

What is Codec WAV and MP3  to asterisk ???

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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] codec opus on centos 6 with asterisk 16

[Jean Aunis]

Hello,

Did you install the "opus" RPM ?

Regards

Jean

Le 09/09/2019 à 13:08, Israel Gottlieb a écrit :

Hi list
does anyone know how i could use codec opus with asterisk 16 when 
using centos 6

the prebuilt binary from digium doesnt load


Thanks,
Israel


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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] codec opus on centos 6 with asterisk 16

[Israel Gottlieb]

Hi list
does anyone know how i could use codec opus with asterisk 16 when using
centos 6
the prebuilt binary from digium doesnt load


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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] codec negotiation or transcoding issue

[Lợi Đặng]

Asterisk might be unable to transcode rtp type from downstream to upstream,
or vice versa.
There's a bug reported here, for asterisk 12 or above, using chan_sip.
https://issues.asterisk.org/jira/browse/ASTERISK-25676
It says that you could avoid the bug by using chan_pjsip, but you still
encounter it?
Turn `core set debug 5` to see whether you have `Unsupported payload type
received` like I once did?
rgds,

On Wed, Mar 15, 2017 at 1:40 AM Faheem Muhammad 
wrote:

> Hi,
> I'm facing strange issue while establishing inbound calls from SIP trunks.
> Provider A is sending (G729,Alaw,uLaw) offer and asterisk dial the peer
> with its preferred codec order(G729,aLaw, uLaw). The peer's phone send the
> codec list as (uLaw, speex) in 200 OK replay. The Peer's phone has selected
> only uLaw and speed in this case.
>
> Ideally Asterisk should establish the call on uLaw codec, but Asterisk
> establish the call with two codec for this call. For downstream RTP is
> established with G729 and for upstream RTP is established with uLaw codec.
> This behavior cause the one way audio for some phones like Eyebeam 1.5.9
> but Phonerlite latest version allow it and there is no audio issue.
>
> Is it normal SIP RFC 3261 behavior or there is something wrong with codec
> negotiation or transcoding?
>
> I'm using Asterisk 13.14.0 with realtime chan_pjsip compiled with bundled
> pjproject on centos 6.8_x64. I have tested it with Asterisk 11.x with
> chan_sip and it works fine.
>
> Please advise me how can I setup the call based on late negotiation
> mechanism?
>
> Thank you!
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] codec negotiation or transcoding issue

[Faheem Muhammad]

Hi,
I'm facing strange issue while establishing inbound calls from SIP trunks.
Provider A is sending (G729,Alaw,uLaw) offer and asterisk dial the peer
with its preferred codec order(G729,aLaw, uLaw). The peer's phone send the
codec list as (uLaw, speex) in 200 OK replay. The Peer's phone has selected
only uLaw and speed in this case.

Ideally Asterisk should establish the call on uLaw codec, but Asterisk
establish the call with two codec for this call. For downstream RTP is
established with G729 and for upstream RTP is established with uLaw codec.
This behavior cause the one way audio for some phones like Eyebeam 1.5.9
but Phonerlite latest version allow it and there is no audio issue.

Is it normal SIP RFC 3261 behavior or there is something wrong with codec
negotiation or transcoding?

I'm using Asterisk 13.14.0 with realtime chan_pjsip compiled with bundled
pjproject on centos 6.8_x64. I have tested it with Asterisk 11.x with
chan_sip and it works fine.

Please advise me how can I setup the call based on late negotiation
mechanism?

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

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Codec Negotiation problem

[research]

Hi Matt

Thanks for your response. I have tried with two GXV3175 with same result.
Let me dig deep on this to find out the route cause

Sam
Matthew Jordan wrote:
> On Thu, Jun 13, 2013 at 12:04 PM,  wrote:
>
>> Hi there
>>
>> I have asterisk 10.11.1 which seems to have problem negotiating codec.
>>
>> Scenario: SIP PHONE1 (XLite) extension 1003, allowed codecs alaw, h263p
>> and SIP phone2 (Grandstream GXV3175) extension 1004, allowed codec alaw,
>> h263p. I have tried similar combination of codecs and SIP phone but when
>> making a video call, it report "Peer doesn't provide video". It seems
>> Asterisk is failing to set capability correct. Both codecs are enabled
>> on
>> the SIP Phones
>>
>>
> 
>
> The 200 OK response from the called XLite phone is declining the video
> stream:
>
> <--- SIP read from UDP:10.10.10.129:48464 --->
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 10.10.10.105:5060;branch=z9hG4bK368135b0;rport=5060
> Contact: 
> To: "SAM";tag=0c90cc0c
> From: ;tag=as24914503
> Call-ID: MmNjOTczNDU5YjZmYjAyNWMxY2Q1MDZjODdhYzQwZjA
> CSeq: 102 INVITE
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO
> Content-Type: application/sdp
> Supported: replaces, eventlist
> User-Agent: X-Lite release 4.5.2 stamp 70142
> Content-Length: 234
>
> v=0
> o=- 13015615910543193 2 IN IP4 10.10.10.129
> s=X-Lite 4 release 4.5.2 stamp 70142
> c=IN IP4 10.10.10.129
> t=0 0
> m=audio 53188 RTP/AVP 8 101
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=sendrecv
> m=video 0 RTP/AVP 115
> <->
> --- (12 headers 10 lines) ---
> Found RTP audio format 8
> Found RTP audio format 101
> Found audio description format telephone-event for ID 101
> Capabilities: us - (alaw|h263p), peer -
> audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
>
> Note that the port for the video stream is set to 0.
>
> Asterisk is doing the correct thing: it notes that the answer to its offer
> declined the video stream, so it disables video for the call between the
> two endpoints.
>
> Matt
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Negotiation problem

[Matthew Jordan]

On Thu, Jun 13, 2013 at 12:04 PM,  wrote:

> Hi there
>
> I have asterisk 10.11.1 which seems to have problem negotiating codec.
>
> Scenario: SIP PHONE1 (XLite) extension 1003, allowed codecs alaw, h263p
> and SIP phone2 (Grandstream GXV3175) extension 1004, allowed codec alaw,
> h263p. I have tried similar combination of codecs and SIP phone but when
> making a video call, it report "Peer doesn't provide video". It seems
> Asterisk is failing to set capability correct. Both codecs are enabled on
> the SIP Phones
>
>


The 200 OK response from the called XLite phone is declining the video
stream:

<--- SIP read from UDP:10.10.10.129:48464 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.105:5060;branch=z9hG4bK368135b0;rport=5060
Contact: 
To: "SAM";tag=0c90cc0c
From: ;tag=as24914503
Call-ID: MmNjOTczNDU5YjZmYjAyNWMxY2Q1MDZjODdhYzQwZjA
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces, eventlist
User-Agent: X-Lite release 4.5.2 stamp 70142
Content-Length: 234

v=0
o=- 13015615910543193 2 IN IP4 10.10.10.129
s=X-Lite 4 release 4.5.2 stamp 70142
c=IN IP4 10.10.10.129
t=0 0
m=audio 53188 RTP/AVP 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 0 RTP/AVP 115
<->
--- (12 headers 10 lines) ---
Found RTP audio format 8
Found RTP audio format 101
Found audio description format telephone-event for ID 101
Capabilities: us - (alaw|h263p), peer -
audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)

Note that the port for the video stream is set to 0.

Asterisk is doing the correct thing: it notes that the answer to its offer
declined the video stream, so it disables video for the call between the
two endpoints.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec Negotiation problem

[research]

Hi there

I have asterisk 10.11.1 which seems to have problem negotiating codec.

Scenario: SIP PHONE1 (XLite) extension 1003, allowed codecs alaw, h263p
and SIP phone2 (Grandstream GXV3175) extension 1004, allowed codec alaw,
h263p. I have tried similar combination of codecs and SIP phone but when
making a video call, it report "Peer doesn't provide video". It seems
Asterisk is failing to set capability correct. Both codecs are enabled on
the SIP Phones

--- (12 headers 9 lines) ---
Found RTP audio format 8
Found RTP audio format 101
Found audio description format telephone-event for ID 101
Capabilities: us - (alaw|h263p), peer -
audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1
(telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.10.10.129:53188
Peer doesn't provide video

Here is a sip show peer output and log when making calls.

localhost*CLI> sip show peer 1003


  * Name   : 1003
  Description  :
  Secret   : 
  MD5Secret: 
  Remote Secret: 
  Context  : video-users
  Subscr.Cont. : 
  Language :
  AMA flags: Unknown
  Transfer mode: open
  CallingPres  : Presentation Allowed, Not Screened
  Callgroup:
  Pickupgroup  :
  MOH Suggest  :
  Mailbox  : 1003@device
  VM Extension : asterisk
  LastMsgsSent : 0/0
  Call limit   : 2147483647
  Max forwards : 0
  Dynamic  : Yes
  Callerid : "device" <1003>
  MaxCallBR: 384 kbps
  Expire   : 3605
  Insecure : no
  Force rport  : Yes
  ACL  : Yes
  DirectMedACL : No
  T.38 support : No
  T.38 EC mode : Unknown
  T.38 MaxDtgrm: -1
  DirectMedia  : Yes
  PromiscRedir : No
  User=Phone   : No
  Video Support: Yes
  Text Support : No
  Ign SDP ver  : No
  Trust RPID   : No
  Send RPID: No
  Subscriptions: Yes
  Overlap dial : No
  DTMFmode : rfc2833
  Timer T1 : 500
  Timer B  : 32000
  ToHost   :
  Addr->IP : 10.10.10.129:48464
  Defaddr->IP  : (null)
  Prim.Transp. : UDP
  Allowed.Trsp : UDP
  Def. Username: 1003
  SIP Options  : (none)
  Codecs   : (alaw|h263p)
  Codec Order  : (alaw:20,h263p:0)
  Auto-Framing :  No
  Status   : OK (8 ms)
  Useragent: X-Lite release 4.5.2 stamp 70142
  Reg. Contact : sip:1003@10.10.10.129:48464;rinstance=cf0c3558f05c89dc
  Qualify Freq : 6 ms
  Sess-Timers  : Accept
  Sess-Refresh : uas
  Sess-Expires : 1800 secs
  Min-Sess : 90 secs
  RTP Engine   : asterisk
  Parkinglot   :
  Use Reason   : No
  Encryption   : No

localhost*CLI> sip show peer 1004


  * Name   : 1004
  Description  :
  Secret   : 
  MD5Secret: 
  Remote Secret: 
  Context  : video-users
  Subscr.Cont. : 
  Language :
  AMA flags: Unknown
  Transfer mode: open
  CallingPres  : Presentation Allowed, Not Screened
  Callgroup:
  Pickupgroup  :
  MOH Suggest  :
  Mailbox  : 1004@device
  VM Extension : asterisk
  LastMsgsSent : 0/0
  Call limit   : 2147483647
  Max forwards : 0
  Dynamic  : Yes
  Callerid : "device" <1004>
  MaxCallBR: 384 kbps
  Expire   : 893
  Insecure : no
  Force rport  : Yes
  ACL  : Yes
  DirectMedACL : No
  T.38 support : No
  T.38 EC mode : Unknown
  T.38 MaxDtgrm: -1
  DirectMedia  : Yes
  PromiscRedir : No
  User=Phone   : No
  Video Support: Yes
  Text Support : No
  Ign SDP ver  : No
  Trust RPID   : No
  Send RPID: No
  Subscriptions: Yes
  Overlap dial : No
  DTMFmode : rfc2833
  Timer T1 : 500
  Timer B  : 32000
  ToHost   :
  Addr->IP : 10.10.10.107:21769
  Defaddr->IP  : (null)
  Prim.Transp. : UDP
  Allowed.Trsp : UDP
  Def. Username: 1004
  SIP Options  : (none)
  Codecs   : (alaw|h263p)
  Codec Order  : (alaw:20,h263p:0)
  Auto-Framing :  No
  Status   : OK (2 ms)
  Useragent: Grandstream GXV3175v2 1.0.1.19
  Reg. Contact : sip:1004@10.10.10.107:21769
  Qualify Freq : 6 ms
  Sess-Timers  : Accept
  Sess-Refresh : uas
  Sess-Expires : 1800 secs
  Min-Sess : 90 secs
  RTP Engine   : asterisk
  Parkinglot   :
  Use Reason   : No
  Encryption   : No

localhost*CLI>

<->
--- (8 headers 0 lines) ---

<--- SIP read from UDP:10.10.10.129:48464 --->
INVITE sip:1004@10.10.10.105 SIP/2.0
Via: SIP/2.0/UDP
10.10.10.129:48464;branch=z9hG4bK-d8754z-25f65c322686d22e-1---d8754z-;rport
Max-Forwards: 70
Contact: 
To: 
From: "SAM";tag=0c90cc0c
Call-ID: MmNjOTczNDU5YjZmYjAyNWMxY2Q1MDZjODdhYzQwZjA
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: replaces
User-Agent: X-Lite release 4.5.2 stamp 70142
Authorization: Digest
username="1003",realm="10.10.10.105",nonce="05e8af6e",uri="sip:1004@10.10.10.105",response="20e63a04aa86d6ec1d1e045c05159b39",algorithm=MD5
Content-Length: 418

v=0
o=- 13015615910543193 1 IN IP4 10.10.10.129
s=X-Lite 4 release 4.5.2 stamp 70142
c=IN IP4 10.10.10.129
t=0 0
m=audio 53188 RTP/AVP 8 0 101
a=rtpmap:101 tel

[asterisk-users] Codec Mismatch

[Gopalakrishnan N]

Sometimes in huge call volume am facing this type of error,

[Jun  4 08:42:46] WARNING[8459][C-79fa]: channel.c:5075 ast_write:
Codec mismatch on channel Local/8038@xss-call-out-4774;1 setting write
format to slin from ulaw native formats (ulaw)
[Jun  4 08:43:04] WARNING[8285][C-79da]: channel.c:5075 ast_write:
Codec mismatch on channel Local/6513@xss-call-out-4775;1 setting write
format to slin from ulaw native formats (ulaw)
[Jun  4 08:43:10] WARNING[8790][C-7a2c]: channel.c:5075 ast_write:
Codec mismatch on channel Local/18002662279@xss-call-out-4778;1 setting
write format to slin from ulaw native formats (ulaw)
[Jun  4 08:43:23] WARNING[8355][C-79e6]: channel.c:5075 ast_write:
Codec mismatch on channel Local/2896@xss-call-out-4779;1 setting write
format to slin from ulaw native formats (ulaw)
[Jun  4 08:43:25] WARNING[7577][C-798a]: channel.c:5075 ast_write:
Codec mismatch on channel Local/2896@xss-call-out-477a;1 setting write
format to slin from ulaw native formats (ulaw)


basically Asterisk will do the slin to ulaw, hope there should not be any
problem...

But am not sure why am getting this error? will this affect my call?
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Metaspace]

Well, I don't know if this has been resolved yet, but I struggled with this
issue very seriously for about 12 straight hours:
I had an Asterisk 1.4 box with a Digium FXO/FXS card and an Asterisk 1.8 box i
just built with no cards. I migrated all extensions to the new box. All are
Cisco phones using the latest Chan-SCCP v4.0.

All I needed was a straight-forward IAX trunk between the two boxes so I could
use the FXO/FXS card in the old one until the Cisco 3102 adapter arrives.

PROBLEM: whatever I did, the new box always suggested g729 and the old one could
not switch from alaw to that and I had exactly the issues JOSEPH describes.

After much reading and even more trial and error I came to a 

SOLUTION:

Ensure that the order of codecs is the same in both boxes, both in the IAX.CONF
file and the SCCP.CONF file. This would probably also mean the SIP.CONF file for
those using SIP.
In other words if you have the following lines (or whatever is relevant to you)
EXACTLY the same way in BOTH the IAX.CONF and the SIP/SCCP.CONF of BOTH ASTERISK
boxes then you should stand a pretty good chance to have the system talk the
same codec when they connect.

EXAMPLE - the [general] section of IAX, SIP and SCCP:

disallow=all
allow=ulaw
allow=alaw
allow=g729
allow=gsm

.

It worked for me! ;)


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] codec priorities

[Jeff LaCoursiere]

Hello,

I am about to start playing with wideband codecs in our lab, and was
hoping to get some clarification on a few things.

To date I've pretty much forced the use of G.711 on all legs of all
calls, and life has been grand.  Now we are distributing phones with
G.722 and speex capability, and I would like to use those codecs if it
can somehow be determined that the end legs have the capability.  There
may be several asterisk servers in between, however.

My first question is - is the order in which I specify "allow" in the
sip.conf entry the priority order asterisk will negotiate with the
phone?

Assuming the above is true, will it *always* negotiate G.722 if I make
it first, even if the call, within the same asterisk server, ends up
going out a dahdi trunk?  How about if, again in the same asterisk
server, it ends up going to a SIP endpoint that *cannot* do G.722?

What about a different scenario involving two asterisk servers, SIP
trunked together with the ability to do G.722 or G.711.  If a SIP
endpoint on one asterisk server can only do G.711, will the the call to
and endpoint on the other side (lets say that can also only do G.711)
get transcoded "up" to G.722 to cross the trunk, then back "down" to
G.711 on the other side?

I vaguely recall a conversation about this some time ago but couldn't
find it in the archives.  I'm afraid I know the answer - that asterisk
doesn't try to find the most efficient codec for the call and that if I
decide to let my fancy new phones do G.722 or speex, then transcoding
will often be involved.  I'd love to understand the complications in
this better... seems like it would be a fantastic feature to be able to
negotiate end to end and pick the most efficient codec.

Cheers,

j


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] codec mismatch on channel

[Danny Nicholas]

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, February 22, 2012 2:35 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] codec mismatch on channel

I get this on 1.8.x as well.  I assume it is a harmless bug.

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Andrew Nowrot
Sent: Wednesday, February 22, 2012 3:32 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] codec mismatch on channel

Hi

I am keep getting this warning message when doing attendant transfer:

WARNING[6027] channel.c: Codec mismatch on channel
Local/XX@Inside-1f32;1 setting write format to slin from alaw native formats
(alaw)

What can I do to lose it.

I am using asterisk 10.1.2

Best regards

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] codec mismatch on channel

[Danny Nicholas]

I think it's a warning as opposed to a "bug".  If the call were happening
all in "Tecnology" (SIP/DAHDI/etc), the warning would be because your
channel didn't support the codec (I can't do alaw so I'm gonna talk in
slin).  The LOCAL channel by definition (AFAIK) doesn't specifically
support/deny any codec format.

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Eric Wieling
Sent: Wednesday, February 22, 2012 2:35 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] codec mismatch on channel

I get this on 1.8.x as well.  I assume it is a harmless bug.

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Andrew Nowrot
Sent: Wednesday, February 22, 2012 3:32 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] codec mismatch on channel

Hi

I am keep getting this warning message when doing attendant transfer:

WARNING[6027] channel.c: Codec mismatch on channel
Local/XX@Inside-1f32;1 setting write format to slin from alaw native formats
(alaw)

What can I do to lose it.

I am using asterisk 10.1.2

Best regards

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] codec mismatch on channel

[Eric Wieling]

I get this on 1.8.x as well.  I assume it is a harmless bug.

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Andrew Nowrot
Sent: Wednesday, February 22, 2012 3:32 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] codec mismatch on channel

Hi

I am keep getting this warning message when doing attendant transfer:

WARNING[6027] channel.c: Codec mismatch on channel
Local/XX@Inside-1f32;1 setting write format to slin from alaw native formats 
(alaw)

What can I do to lose it.

I am using asterisk 10.1.2

Best regards

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to 
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec

[Dustin fails]

Anyone using the G729 codec to create a h.323 trunk between an Avaya
Communication manager and Asterisk Freepbx System and works? I don't have
the G729 codec installed on the Asterisk and running G711MU on avaya and
getting invalid codec when calling from Avaya to Asterisk.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Joseph]

On 12/27/11 18:23, Olivier wrote:

2011/12/27, Eric Wieling :

We are running 1.8.8.0.



Then the issue you're having differs from the one I had (which
appeared and disappeared instantly when I upgraded to 1.8.7 and 1.8.8
respectively).



Upgrading to 1.8.8 DID NOT HELP
I'm getting the same error message:
Call rejected by ... Unable to negotiate codec

  == Using UDPTL CoS mark 5
  == Using SIP RTP CoS mark 5
-- Executing [4@internal:1] Dial("SIP/11-", 
"IAX2/home_server:@192.168.141.1/4,30,rw") in new stack
-- Called IAX2/home_server:@192.168.141.1/4
[Dec 27 19:10:42] WARNING[15968]: chan_iax2.c:10672 socket_process: Call 
rejected by 192.168.141.1: Unable to negotiate codec
-- Hungup 'IAX2/192.168.141.1:4569-24'
  == Everyone is busy/congested at this time (1:0/0/1)
-- Executing [4@internal:2] Hangup("SIP/11-", "") in new stack
  == Spawn extension (internal, 4, 2) exited non-zero on 'SIP/11-'


--
Joseph

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Olivier]

2011/12/27, Eric Wieling :
> We are running 1.8.8.0.
>

Then the issue you're having differs from the one I had (which
appeared and disappeared instantly when I upgraded to 1.8.7 and 1.8.8
respectively).

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Joseph]

On 12/27/11 08:16, Ryan Wagoner wrote:

  On Fri, Dec 23, 2011 at 10:40 AM, Eric Wieling  wrote:

I'm getting various codec related warnings after upgrading to 1.8.  Did
I miss something in the UPGRADE file?  Does Asterisk no longer transcode
8-)?

WARNING[11123]: channel.c:4909 ast_write: Codec mismatch on channel
DAHDI/i1/12124221200-74 setting write format to g722 from ulaw native
formats 0x4 (ulaw)

And

WARNING[11120]: channel.c:4909 ast_write: Codec mismatch on channel
SIP/interglobe-sip-01e6 setting write format to g722 from ulaw
native formats 0x4 (ulaw)

  When I upgraded to 1.8.7 I had a bunch of those warnings. I had backported
  the below patch which was included in a 1.8.8 release candidate. Since
  1.8.8 has been released I would just upgrade to that.

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

  Ryan


Thanks folks, I've upgraded today to 1.8.8.0 and will test and report the 
result later on.

--
Joseph

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Eric Wieling]

We are running 1.8.8.0.

-Original Message-
From: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Ryan Wagoner
Sent: Tuesday, December 27, 2011 8:16 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Codec warnings after upgrade to 1.8

On Fri, Dec 23, 2011 at 10:40 AM, Eric Wieling  wrote:


I'm getting various codec related warnings after upgrading to 1.8.  Did 
I miss something in the UPGRADE file?  Does Asterisk no longer transcode 8-)?

WARNING[11123]: channel.c:4909 ast_write: Codec mismatch on channel 
DAHDI/i1/12124221200-74 setting write format to g722 from ulaw native formats 
0x4 (ulaw)

And

WARNING[11120]: channel.c:4909 ast_write: Codec mismatch on channel 
SIP/interglobe-sip-01e6 setting write format to g722 from ulaw native 
formats 0x4 (ulaw)




When I upgraded to 1.8.7 I had a bunch of those warnings. I had backported the 
below patch which was included in a 1.8.8 release candidate. Since 1.8.8 has 
been released I would just upgrade to that.

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

Ryan


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Ryan Wagoner]

On Fri, Dec 23, 2011 at 10:40 AM, Eric Wieling  wrote:

> I'm getting various codec related warnings after upgrading to 1.8.  Did I
> miss something in the UPGRADE file?  Does Asterisk no longer transcode 8-)?
>
> WARNING[11123]: channel.c:4909 ast_write: Codec mismatch on channel
> DAHDI/i1/12124221200-74 setting write format to g722 from ulaw native
> formats 0x4 (ulaw)
>
> And
>
> WARNING[11120]: channel.c:4909 ast_write: Codec mismatch on channel
> SIP/interglobe-sip-01e6 setting write format to g722 from ulaw native
> formats 0x4 (ulaw)
>
>
When I upgraded to 1.8.7 I had a bunch of those warnings. I had backported
the below patch which was included in a 1.8.8 release candidate. Since
1.8.8 has been released I would just upgrade to that.

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

Ryan
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Olivier]

Could you try with 1.8.8.0 ?
I think this one includes a fix for that error.

2011/12/26, Joseph :
> On 12/23/11 10:40, Eric Wieling wrote:
>>I'm getting various codec related warnings after upgrading to 1.8.  Did I
>> miss something in the UPGRADE file?  Does Asterisk no longer transcode
>> 8-)?
>>
>>WARNING[11123]: channel.c:4909 ast_write: Codec mismatch on channel
>> DAHDI/i1/12124221200-74 setting write format to g722 from ulaw native
>> formats 0x4 (ulaw)
>>
>>And
>>
>>WARNING[11120]: channel.c:4909 ast_write: Codec mismatch on channel
>> SIP/interglobe-sip-01e6 setting write format to g722 from ulaw native
>> formats 0x4 (ulaw)
>>
>>--
>>_
>>-- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>New to Asterisk? Join us for a live introductory webinar every Thurs:
>>   http://www.asterisk.org/hello
>>
>>asterisk-users mailing list
>>To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
> This is similar error I'm getting on asterisk 1.8.7 when trying to
> communicate with codec: ulaw with asterisk 1.4
>
> When I try to dialin on asterisk-1.4.39 I get an error:
> NOTICE[2414]: chan_iax2.c:9541 socket_process: Rejected connect
> attempt from 192.168.141.8, requested/capability 0x2/0x703
> incompatible with our capability 0xc.
> NOTICE[2417]: chan_iax2.c:9541 socket_process: Rejected connect
> attempt from 192.168.141.8, requested/capability 0x2/0x703
> incompatible with our capability 0xc.
>
> On asterisk-1.8.7 I get:
>   WARNING[4277]: chan_iax2.c:10666 socket_process: Call rejected by
> 192.168.141.1: Unable to negotiate codec
>
> If you find a solution please let me know.
>
>
>
>
>
> --
> Joseph
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
>

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec warnings after upgrade to 1.8

[Joseph]

On 12/23/11 10:40, Eric Wieling wrote:

I'm getting various codec related warnings after upgrading to 1.8.  Did I miss 
something in the UPGRADE file?  Does Asterisk no longer transcode 8-)?

WARNING[11123]: channel.c:4909 ast_write: Codec mismatch on channel 
DAHDI/i1/12124221200-74 setting write format to g722 from ulaw native formats 
0x4 (ulaw)

And

WARNING[11120]: channel.c:4909 ast_write: Codec mismatch on channel 
SIP/interglobe-sip-01e6 setting write format to g722 from ulaw native 
formats 0x4 (ulaw)

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

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


This is similar error I'm getting on asterisk 1.8.7 when trying to communicate 
with codec: ulaw with asterisk 1.4

When I try to dialin on asterisk-1.4.39 I get an error:
NOTICE[2414]: chan_iax2.c:9541 socket_process: Rejected connect
attempt from 192.168.141.8, requested/capability 0x2/0x703
incompatible with our capability 0xc.
NOTICE[2417]: chan_iax2.c:9541 socket_process: Rejected connect
attempt from 192.168.141.8, requested/capability 0x2/0x703
incompatible with our capability 0xc.

On asterisk-1.8.7 I get:
 WARNING[4277]: chan_iax2.c:10666 socket_process: Call rejected by 
192.168.141.1: Unable to negotiate codec

If you find a solution please let me know.





--
Joseph

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

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

[asterisk-users] Codec warnings after upgrade to 1.8

[Eric Wieling]

I'm getting various codec related warnings after upgrading to 1.8.  Did I miss 
something in the UPGRADE file?  Does Asterisk no longer transcode 8-)?

WARNING[11123]: channel.c:4909 ast_write: Codec mismatch on channel 
DAHDI/i1/12124221200-74 setting write format to g722 from ulaw native formats 
0x4 (ulaw)

And

WARNING[11120]: channel.c:4909 ast_write: Codec mismatch on channel 
SIP/interglobe-sip-01e6 setting write format to g722 from ulaw native 
formats 0x4 (ulaw)

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec warning polluting the CLI since 1.8

[Mike]

Hi,

 

I've just upgraded to 1.8.6 on one server and I've been getting a lot of
codec warning, like this:

 

WARNING[21211]: chan_sip.c:6341 sip_write: Asked to transmit frame type
ulaw, while native formats is 0x100 (g729) read/write = 0x100 (g729)/0x100
(g729)

 

I do have a Digium transcoder card, and it's almost unused at the moment
(testing 1.8 phase). Calls seem to work, but this warning is flooding my CLI
(comes in hundreds of times at once then stops) making debugging very
difficult. What can create this? I did not have this issue with 1.6.2.20 (or
any previous version for that matter)

 

Regards,

 

Mike

 

 

 

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)

[Ryan McGuire]

This is an excerpt from rfc3264 in regards to modifying an existing
session by the way:

"At any point during the session, either participant MAY issue a new
   offer to modify characteristics of the session.  It is fundamental to
   the operation of the offer/answer model that the exact same
   offer/answer procedure defined above is used for modifying parameters
   of an existing session."

I understand the implementation would likely be complicated -- I
noticed a ticket dating back to 2005 in regards to this. I'm wondering
if the user communities' demand for this functionality is enough to
justify adding it to the roadmap?

-Ryan

On Thu, Aug 4, 2011 at 11:06 AM, Ryan McGuire  wrote:
>
> Thanks for the reply David,
> I guess I don't understand an issue in implementing the offer/answer model 
> (rfc3264). If asterisk receives an invite and knows the egress peer's 
> capabilities, why not respond to the sdp in the initial invite with modified 
> sdp containing only g729?
> So asterisk knows that it is going to dial a peer that supports only g729 
> when it gets an invite from a peer that supports both ulaw and g729. Using 
> the offer / answer model it would look like this:
> Peer -> Invite (SDP:ulaw,g729) -> Asterisk
> Peer <- 100 Trying (w/ SDP -- g729 only) <- Asterisk
> Peer -> 200 OK (w/ SDP g729) -> Asterisk
> I understand your point about not knowing what may happen after initial call 
> setup, but the same implementation would apply in the event of a reinvite.
> Maybe this could be an option (allow_rfc3264=yes or something of that nature).
> Thanks again,
> -Ryan
>
> On Thu, Aug 4, 2011 at 9:58 AM, David Vossel  wrote:
>>
>> - Original Message -
>> > From: "Ryan McGuire" 
>> > To: asterisk-users@lists.digium.com
>> > Sent: Wednesday, August 3, 2011 9:47:42 AM
>> > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format 
>> > found to offer)
>> > From looking into this, it appears as if this is due to Asterisk
>> > negotiating the legs separately as if they were not related to the
>> > same call. So the ingress leg negotiates ulaw, and despite it knowing
>> > that the peer also supports g729 fails the call since it's already
>> > decided on ulaw and the egress leg only accepts g729.
>> >
>> >
>> > If this is design intent I'm wondering if there is demand enough to
>> > justify a feature request?
>> >
>> >
>> > Any advice on how I can work around this issue?
>> >
>> >
>> > Thanks,
>> >
>> >
>> > -Ryan
>>
>> This is a much more complicated issue than Asterisk negotiating each call 
>> leg separate of one another.  Even if we give one call leg information about 
>> call setup occurring on the other call leg it is about to be bridged to, we 
>> are dependent on the endpoints honoring the codec preference priority we 
>> send them to avoid translation between one codec and another during the 
>> bridge... Honoring the preference order in the SDP does not always occur, 
>> which means that any effort in this area would only work in a perfect 
>> scenario.
>>
>> Even if we get call legs to negotiate perfectly before being bridged during 
>> call setup, we are not guaranteed that translation will not occur later if 
>> the call is transfered or parked.  Regardless of what we do, if your setup 
>> allows ulaw and g729 for sip peers, you will always run the risk of a codec 
>> mixmatch...  You may however be able to avoid this for some cases by using 
>> the sip.conf preferred_codec_only option.  I believe that will limit the 
>> codecs negotiated during call setup to the single codec currently chosen on 
>> the other call leg. The problem with this is that we are not guaranteed the 
>> call leg supplying the codec will not change later.
>>
>> --
>> David Vossel
>> Digium, Inc. | Software Developer, Open Source Software
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> Check us out at: www.digium.com & www.asterisk.org
>> The_Boy_Wonder in #asterisk-dev
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>               http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)

[Ryan McGuire]

Thanks for the reply David,

I guess I don't understand an issue in implementing the offer/answer model
(rfc3264). If asterisk receives an invite and knows the egress peer's
capabilities, why not respond to the sdp in the initial invite with modified
sdp containing only g729?

So asterisk knows that it is going to dial a peer that supports only g729
when it gets an invite from a peer that supports both ulaw and g729. Using
the offer / answer model it would look like this:

Peer -> Invite (SDP:ulaw,g729) -> Asterisk
Peer <- 100 Trying (w/ SDP -- g729 only) <- Asterisk
Peer -> 200 OK (w/ SDP g729) -> Asterisk

I understand your point about not knowing what may happen after initial call
setup, but the same implementation would apply in the event of a reinvite.

Maybe this could be an option (allow_rfc3264=yes or something of that
nature).

Thanks again,

-Ryan

On Thu, Aug 4, 2011 at 9:58 AM, David Vossel  wrote:

> - Original Message -
> > From: "Ryan McGuire" 
> > To: asterisk-users@lists.digium.com
> > Sent: Wednesday, August 3, 2011 9:47:42 AM
> > Subject: Re: [asterisk-users] Codec negotiation issue (no audio format
> found to offer)
> > From looking into this, it appears as if this is due to Asterisk
> > negotiating the legs separately as if they were not related to the
> > same call. So the ingress leg negotiates ulaw, and despite it knowing
> > that the peer also supports g729 fails the call since it's already
> > decided on ulaw and the egress leg only accepts g729.
> >
> >
> > If this is design intent I'm wondering if there is demand enough to
> > justify a feature request?
> >
> >
> > Any advice on how I can work around this issue?
> >
> >
> > Thanks,
> >
> >
> > -Ryan
>
> This is a much more complicated issue than Asterisk negotiating each call
> leg separate of one another.  Even if we give one call leg information about
> call setup occurring on the other call leg it is about to be bridged to, we
> are dependent on the endpoints honoring the codec preference priority we
> send them to avoid translation between one codec and another during the
> bridge... Honoring the preference order in the SDP does not always occur,
> which means that any effort in this area would only work in a perfect
> scenario.
>
> Even if we get call legs to negotiate perfectly before being bridged during
> call setup, we are not guaranteed that translation will not occur later if
> the call is transfered or parked.  Regardless of what we do, if your setup
> allows ulaw and g729 for sip peers, you will always run the risk of a codec
> mixmatch...  You may however be able to avoid this for some cases by using
> the sip.conf preferred_codec_only option.  I believe that will limit the
> codecs negotiated during call setup to the single codec currently chosen on
> the other call leg. The problem with this is that we are not guaranteed the
> call leg supplying the codec will not change later.
>
> --
> David Vossel
> Digium, Inc. | Software Developer, Open Source Software
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: www.digium.com & www.asterisk.org
> The_Boy_Wonder in #asterisk-dev
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)

[David Vossel]

- Original Message -
> From: "Ryan McGuire" 
> To: asterisk-users@lists.digium.com
> Sent: Wednesday, August 3, 2011 9:47:42 AM
> Subject: Re: [asterisk-users] Codec negotiation issue (no audio format found 
> to offer)
> From looking into this, it appears as if this is due to Asterisk
> negotiating the legs separately as if they were not related to the
> same call. So the ingress leg negotiates ulaw, and despite it knowing
> that the peer also supports g729 fails the call since it's already
> decided on ulaw and the egress leg only accepts g729.
> 
> 
> If this is design intent I'm wondering if there is demand enough to
> justify a feature request?
> 
> 
> Any advice on how I can work around this issue?
> 
> 
> Thanks,
> 
> 
> -Ryan

This is a much more complicated issue than Asterisk negotiating each call leg 
separate of one another.  Even if we give one call leg information about call 
setup occurring on the other call leg it is about to be bridged to, we are 
dependent on the endpoints honoring the codec preference priority we send them 
to avoid translation between one codec and another during the bridge... 
Honoring the preference order in the SDP does not always occur, which means 
that any effort in this area would only work in a perfect scenario.

Even if we get call legs to negotiate perfectly before being bridged during 
call setup, we are not guaranteed that translation will not occur later if the 
call is transfered or parked.  Regardless of what we do, if your setup allows 
ulaw and g729 for sip peers, you will always run the risk of a codec 
mixmatch...  You may however be able to avoid this for some cases by using the 
sip.conf preferred_codec_only option.  I believe that will limit the codecs 
negotiated during call setup to the single codec currently chosen on the other 
call leg. The problem with this is that we are not guaranteed the call leg 
supplying the codec will not change later.

-- 
David Vossel
Digium, Inc. | Software Developer, Open Source Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
The_Boy_Wonder in #asterisk-dev

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation issue (no audio format found to offer)

[Ryan McGuire]

>From looking into this, it appears as if this is due to Asterisk negotiating
the legs separately as if they were not related to the same call. So the
ingress leg negotiates ulaw, and despite it knowing that the peer also
supports g729 fails the call since it's already decided on ulaw and the
egress leg only accepts g729.

If this is design intent I'm wondering if there is demand enough to justify
a feature request?

Any advice on how I can work around this issue?

Thanks,

-Ryan

On Tue, Aug 2, 2011 at 3:51 PM, Ryan McGuire  wrote:

> Running build 1.8.5.0 (compiled from source) I seem to be having an issue
> with codec negotiation. I have a Grandstream HT503 FXO port connected to a
> pstn line, a Polycom SP501, and a SIP trunk with callwithus.
>
> What I'm essentially looking to accomplish is for ulaw or g729 (preferably
> ulaw) to be used to the Grandstream FXO or any other internal endpoint, and
> for g729 only to be used outbound to my SIP trunk.
>
> Here are the basics of my config, showing the codec list from "sip show
> peer ":
>
> Polycom SP501 (desk phone):
> --
> disallow=all
> allow=ulaw&g729
>   Codecs   : 0x104 (ulaw|g729)
>   Codec Order  : (ulaw:20,g729:20)
>
> Grandstream HT503 (fxo gateway):
> --
> disallow=all
> allow=ulaw&g729
>   Codecs   : 0x104 (ulaw|g729)
>   Codec Order  : (ulaw:20,g729:20)
>
> CallWithUs (SIP trunk):
> --
> disallow=all
> allow=g729
>   Codecs   : 0x100 (g729)
>   Codec Order  : (g729:20)
>
> When I place an outbound call from the Polycom to callwithus, the invite
> from the pcom shows both ulaw and g729 in the SDP:
> INVITE sip:@192.168.0.1;user=phone SIP/2.0
> Via: SIP/2.0/UDP 192.168.0.201;branch=z9hG4bKc8aa981a8B8FF58D
> From: "Office" ;tag=4CD2B2A0-B94A2531
> To: 
> [...]
> m=audio 2258 RTP/AVP 18 0 8 101
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
>
> Asterisk sees this:
> [Aug  2 15:00:31] VERBOSE[1918] chan_sip.c: Capabilities: us - 0x104
> (ulaw|g729), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0
> (nothing)/text=0x0 (nothing), combined - 0x104 (ulaw|g729)
>
> The call goes out the callwithus trunk:
> [Aug  2 15:00:31] VERBOSE[1315] pbx.c: -- Executing
> [s@macro-dialout-trunk:19] Dial("SIP/2001-0047",
> "SIP/CallWithUs/**,300,tTwW") in new stack
>
> And then this, no INVITE goes out to callwithus at all:
> [Aug  2 15:00:31] WARNING[1315] chan_sip.c: No audio format found to offer.
> Cancelling call to **
> [Aug  2 15:00:31] VERBOSE[1315] app_dial.c: -- Couldn't call
> SIP/CallWithUs/**
>
> Similarly, if I set the Grandstream FXO trunk to ulaw only, the call fails
> as well. It seems as if allowing only a single codec is the issue, if I
> change the priorities of all codecs to g729 first and ulaw second, the call
> goes through as g729 successfully.
>
> Smells like a bug to me, but I may be overlooking something in my config.
>
> Thanks,
>
> -Ryan
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec negotiation issue (no audio format found to offer)

[Ryan McGuire]

Running build 1.8.5.0 (compiled from source) I seem to be having an issue
with codec negotiation. I have a Grandstream HT503 FXO port connected to a
pstn line, a Polycom SP501, and a SIP trunk with callwithus.

What I'm essentially looking to accomplish is for ulaw or g729 (preferably
ulaw) to be used to the Grandstream FXO or any other internal endpoint, and
for g729 only to be used outbound to my SIP trunk.

Here are the basics of my config, showing the codec list from "sip show peer
":

Polycom SP501 (desk phone):
--
disallow=all
allow=ulaw&g729
  Codecs   : 0x104 (ulaw|g729)
  Codec Order  : (ulaw:20,g729:20)

Grandstream HT503 (fxo gateway):
--
disallow=all
allow=ulaw&g729
  Codecs   : 0x104 (ulaw|g729)
  Codec Order  : (ulaw:20,g729:20)

CallWithUs (SIP trunk):
--
disallow=all
allow=g729
  Codecs   : 0x100 (g729)
  Codec Order  : (g729:20)

When I place an outbound call from the Polycom to callwithus, the invite
from the pcom shows both ulaw and g729 in the SDP:
INVITE sip:@192.168.0.1;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.201;branch=z9hG4bKc8aa981a8B8FF58D
From: "Office" ;tag=4CD2B2A0-B94A2531
To: 
[...]
m=audio 2258 RTP/AVP 18 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

Asterisk sees this:
[Aug  2 15:00:31] VERBOSE[1918] chan_sip.c: Capabilities: us - 0x104
(ulaw|g729), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0
(nothing)/text=0x0 (nothing), combined - 0x104 (ulaw|g729)

The call goes out the callwithus trunk:
[Aug  2 15:00:31] VERBOSE[1315] pbx.c: -- Executing
[s@macro-dialout-trunk:19] Dial("SIP/2001-0047",
"SIP/CallWithUs/**,300,tTwW") in new stack

And then this, no INVITE goes out to callwithus at all:
[Aug  2 15:00:31] WARNING[1315] chan_sip.c: No audio format found to offer.
Cancelling call to **
[Aug  2 15:00:31] VERBOSE[1315] app_dial.c: -- Couldn't call
SIP/CallWithUs/**

Similarly, if I set the Grandstream FXO trunk to ulaw only, the call fails
as well. It seems as if allowing only a single codec is the issue, if I
change the priorities of all codecs to g729 first and ulaw second, the call
goes through as g729 successfully.

Smells like a bug to me, but I may be overlooking something in my config.

Thanks,

-Ryan
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec translation from gsm to other codecs or from other codecs to gsm

[Eric Wieling]

Could it be this bug? https://issues.asterisk.org/jira/browse/ASTERISK-17742

> -Original Message-
> From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-
> boun...@lists.digium.com] On Behalf Of bilal ghayyad
> Sent: Sunday, July 31, 2011 7:48 AM
> To: asterisk-users@lists.digium.com
> Subject: [asterisk-users] Codec translation from gsm to other codecs or from
> other codecs to gsm
> 
> Hi All;
> 
> The asterisk version is 1.8.4.2
> 
> Why codec translation from and to gsm is not possible? I think it was
> possible in previous versions.
> 
> I am missing something to have this codec translation possibility?
> 
> Please advise.
> 
> Regards
> Bilal
> 
> --
> ___
> __
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>http://www.asterisk.org/hello
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec translation from gsm to other codecs or from other codecs to gsm

[Alex Balashov]

On 07/31/2011 07:48 AM, bilal ghayyad wrote:

Hi All;

The asterisk version is 1.8.4.2

Why codec translation from and to gsm is not possible? I think it was possible 
in previous versions.

I am missing something to have this codec translation possibility?


What gives you the impression that it is not possible?


--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

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

[asterisk-users] Codec translation from gsm to other codecs or from other codecs to gsm

[bilal ghayyad]

Hi All;

The asterisk version is 1.8.4.2

Why codec translation from and to gsm is not possible? I think it was possible 
in previous versions.

I am missing something to have this codec translation possibility?

Please advise.

Regards
Bilal

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[faisal]

Hi,
 
If you will send call without answering on asterisk and have directrtpsetup=yes 
in sip.conf codec negociation will always be between UAs so any matched codec 
will work fine. If you are answering call on asterisk then dialing it out to 
next UA then you need to add canreinvite=yes for both UAs.

Regards,

Faisal


P peers calling each other:
A (g722, alaw) calls B (alaw,ulaw) via asterisk.

My setup:

allow=g722,alaw
preferred_codec_only=no

Note that when B calls A, codec alaw is used on both ends, fine, but it does 
not seem to work the reverse way (A is using g722, B is using alaw, asterisk is 
doing transcoding).
Is it possible?

Thanks,

Ondrej
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec negotiation

[Ondrej Valousek]

 Hi List,

I am using asterisk 1.8.1. and I want to avoid transcoding when 2 SIP peers 
calling each other:
A (g722, alaw) calls B (alaw,ulaw) via asterisk.

My setup:

allow=g722,alaw
preferred_codec_only=no

Note that when B calls A, codec alaw is used on both ends, fine, but it does not seem to work the reverse way (A is using g722, B is using 
alaw, asterisk is doing transcoding).

Is it possible?

Thanks,

Ondrej
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Zeeshan Zakaria]

This is at least the third post under the subject 'Codec Choice' by the same
sender. Why don't you stay within your first thread? Does posting over and
over again increases chances of getting a solution? If so, then maybe I
should try the same, as seems like an increasing trend on this list.

Zeeshan A Zakaria

--
www.ilovetovoip.com

On 2010-08-24 7:13 AM, "Deepika Nijhawan" 
wrote:

 Hi,



Group () and Group_Count () will need to be used on certain extension. What
if there are lot of clients on the kit with different routings some going to
dahdi and some to different sip interconnects, how can we do it on whole kit
basis. Or let me know if there is any other way to use these functions to
achieve this.



Thanks,

D





--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec choice

[Deepika Nijhawan]

Hi, 

 

Group () and Group_Count () will need to be used on certain extension. What
if there are lot of clients on the kit with different routings some going to
dahdi and some to different sip interconnects, how can we do it on whole kit
basis. Or let me know if there is any other way to use these functions to
achieve this.

 

Thanks,

D

 

 

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Steve Edwards]

On Fri, 20 Aug 2010, Sherwood McGowan wrote:

> Good point my man...You drinking yet?

Let me check to see if I still have a pulse -- yep!

-- 
Thanks in advance,
-
Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
Newline  Fax: +1-760-731-3000

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Sherwood McGowan]

Steve,

Good point my man...You drinking yet? LOL...I had forgotten about the
GROUP and GROUP_COUNT functions, that is a much better way (in that it
already existed and doesn't require me to write more code :] )

Slainte!

On Fri, Aug 20, 2010 at 7:37 PM, Steve Edwards
 wrote:
> On Fri, 20 Aug 2010, Sherwood McGowan wrote:
>
>> 1. Set up a Global Variable that will store that kit's current number of 
>> calls
>> 2. Check that variable when a call starts (but before you dial out)
>> 3. If the number of calls is <49 (since the current call will make
>> 50), use codec A via the CHANNEL() function, otherwise use codec B
>> using the same function.
>> 4. Increment the variable
>> 5. place call
>> 6., upon hangup, decrement the variable
>
> Not really paying close attention to what you're trying to do, but...
>
> The GROUP() and GROUP_COUNT() functions automagically take care of the
> increment and decrement cruft in a "race condition free" sort of way.
>
> Both methods still leave a small "window of opportunity" in comparing the
> count with the threshold.
>
> --
> Thanks in advance,
> -
> Steve Edwards       sedwa...@sedwards.com      Voice: +1-760-468-3867 PST
> Newline                                              Fax: +1-760-731-3000
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Steve Edwards]

On Fri, 20 Aug 2010, Sherwood McGowan wrote:

> 1. Set up a Global Variable that will store that kit's current number of calls
> 2. Check that variable when a call starts (but before you dial out)
> 3. If the number of calls is <49 (since the current call will make
> 50), use codec A via the CHANNEL() function, otherwise use codec B
> using the same function.
> 4. Increment the variable
> 5. place call
> 6., upon hangup, decrement the variable

Not really paying close attention to what you're trying to do, but...

The GROUP() and GROUP_COUNT() functions automagically take care of the 
increment and decrement cruft in a "race condition free" sort of way.

Both methods still leave a small "window of opportunity" in comparing the 
count with the threshold.

-- 
Thanks in advance,
-
Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
Newline  Fax: +1-760-731-3000

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Sherwood McGowan]

1. Set up a Global Variable that will store that kit's current number of calls
2. Check that variable when a call starts (but before you dial out)
3. If the number of calls is <49 (since the current call will make
50), use codec A via the CHANNEL() function, otherwise use codec B
using the same function.
4. Increment the variable
5. place call
6., upon hangup, decrement the variable

Cheers

On Fri, Aug 20, 2010 at 9:06 AM, Deepika Nijhawan
 wrote:
> Hi,
>
>
>
> Thanks. Actually can it be done on whole kit basis rather than for an
> extension or peer.  Like if there are lot of inbound sip interconnects on a
> kit , how can we send first 50% simultaneous calls to dahdi with codec A and
> after that with codec B.
>
>
>
> Thanks,
>
> D
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec choice

[Deepika Nijhawan]

Hi,

 

Thanks. Actually can it be done on whole kit basis rather than for an
extension or peer.  Like if there are lot of inbound sip interconnects on a
kit , how can we send first 50% simultaneous calls to dahdi with codec A and
after that with codec B.

 

Thanks, 

D

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Steve Edwards]

> On Thu, Aug 19, 2010 at 3:14 AM, Deepika Nijhawan
>>
>> Does anyone has an idea how to tell asterisk to use codec A for first 
>> 50 calls and then codec B for rest of the calls.

On Thu, 19 Aug 2010, Sherwood McGowan wrote:

> the easiest way I can think of is to use a global variable that you 
> increment each time a new call spawns, and once it's over your threshold 
> (50 in this case) use the CHANNEL() function to set the audio format to 
> the codec you want (google voip-info function CHANNEL)

Your question is not specific enough. Do you mean the "first 50 calls" or 
"50 simultaneous calls?"

I suspect the latter and the GROUP() and GROUP_COUNT() functions are the 
way to go.

-- 
Thanks in advance,
-
Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
Newline  Fax: +1-760-731-3000

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec choice

[Deepika Nijhawan]

Ok. And how will we do for getting sip inbound calls from different ips and
sending them to dahdi.

 

 

Thanks,

D

 

 

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Geraint Lee]

i do this by having 2 peers setup, one has a call limit of 10 and uses g729,
the rest of the calls get sent to the second peer which uses ulaw.

all calls attempt peer 1 if there's channels available it uses it if not it
just moves through the dialplan to use the second one.

On 19 August 2010 09:14, Deepika Nijhawan wrote:

>  Hi,
>
>
>
> Does anyone has an idea how to tell asterisk to use codec A for first 50
> calls and then codec B for rest of the calls.
>
>
>
> Thanks,
>
> Deepika
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Sherwood McGowan]

On Thu, Aug 19, 2010 at 3:37 AM, Steve Howes  wrote:
>
> On 19 Aug 2010, at 09:14, Deepika Nijhawan wrote:
>> Does anyone has an idea how to tell asterisk to use codec A for first 50 
>> calls and then codec B for rest of the calls.
>
> You could create two separate trunks, one for each codec?
>
> S
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

Good Point! LOL, I went with a much more complicated method...sleep
deprivation at it's finest perhaps?

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Steve Howes]

On 19 Aug 2010, at 09:14, Deepika Nijhawan wrote:
> Does anyone has an idea how to tell asterisk to use codec A for first 50 
> calls and then codec B for rest of the calls.

You could create two separate trunks, one for each codec?

S
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec choice

[Sherwood McGowan]

On Thu, Aug 19, 2010 at 3:14 AM, Deepika Nijhawan
 wrote:
> Hi,
>
>
>
> Does anyone has an idea how to tell asterisk to use codec A for first 50
> calls and then codec B for rest of the calls.
>
>
>
> Thanks,
>
> Deepika
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

the easiest way I can think of is to use a global variable that you
increment each time a new call spawns, and once it's over your
threshold (50 in this case) use the CHANNEL() function to set the
audio format to the codec you want (google voip-info function CHANNEL)

Cheers

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec choice

[Deepika Nijhawan]

Hi, 

 

Does anyone has an idea how to tell asterisk to use codec A for first 50
calls and then codec B for rest of the calls.

 

Thanks, 

Deepika

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Miguel Molina]

El 09/08/10 05:30, michel freiha escribió:

Hello Miguel molina,

I did what you asked, but still the voice is too bad

Regards

On Thu, Aug 5, 2010 at 11:38 PM, Miguel Molina 
mailto:mmol...@millenium.com.co>> wrote:


El 05/08/10 14:50, Tim Nelson escribió:

- "michel freiha" 
 wrote:
>
> Dear Sir,
>
> I tried to convert ilbc to ulaw and get the same result...Bad
Voice Quality
>
> Regards
>

Again, iLBC is poor quality to begin with. You can't take a poor
audio sample and make it better by converting it to a codec with
better 'resolution'. An audio sample full of robot voice is going
to sound like the same robot voice even if you transcode it to a
better quality codec, whether that is G.729, G.711u, or the
latest 'HD Voice' codecs.

--Tim

This just made me remember some comment on the iax.conf sample file...

disallow=lpc10; Icky sound quality...  Mr. Roboto.

Cheers,

-- 
Ing. Miguel Molina

Grupo de Tecnología
Millenium Phone Center
 



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

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



Hi,

I didn't ask nothing... but as Tim said you are encouraged to change the 
iLBC codec to other (could be GSM) and do some tests. Play with several 
codecs and see which one fits your needs or whether this is not a codec 
or transcoding issue.


Regards,

--
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[michel freiha]

Hello Miguel molina,

I did what you asked, but still the voice is too bad

Regards

On Thu, Aug 5, 2010 at 11:38 PM, Miguel Molina wrote:

>  El 05/08/10 14:50, Tim Nelson escribió:
>
> - "michel freiha"   wrote:
> >
> > Dear Sir,
> >
> > I tried to convert ilbc to ulaw and get the same result...Bad Voice
> Quality
> >
> > Regards
> >
>
>  Again, iLBC is poor quality to begin with. You can't take a poor audio
> sample and make it better by converting it to a codec with better
> 'resolution'. An audio sample full of robot voice is going to sound like the
> same robot voice even if you transcode it to a better quality codec, whether
> that is G.729, G.711u, or the latest 'HD Voice' codecs.
>
>  --Tim
>
> This just made me remember some comment on the iax.conf sample file...
>
> disallow=lpc10; Icky sound quality...  Mr. Roboto.
>
> Cheers,
>
> --
> Ing. Miguel Molina
> Grupo de Tecnología
> Millenium Phone Center
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Jeff Brower]

Steve-

>   On 08/07/2010 03:15 AM, Jeff Brower wrote:
>> Steve-
>>
>>> El 05/08/10 14:50, Tim Nelson escribió:
 - "michel freiha"wrote:
> Dear Sir,
>
> I tried to convert ilbc to ulaw and get the same result...Bad Voice
 Quality
> Regards
>
 Again, iLBC is poor quality to begin with. You can't take a poor audio
 sample and make it better by converting it to a codec with better
 'resolution'. An audio sample full of robot voice is going to sound
 like the same robot voice even if you transcode it to a better quality
 codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.

 --Tim
>>> This just made me remember some comment on the iax.conf sample file...
>>>
>>> disallow=lpc10; Icky sound quality...  Mr. Roboto.
>> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good 
>> job with pitch detection so it tends to
>> have
>> a
>> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or 
>> less should not be using LPC10.
>>
>> -Jeff
> MELPe is patent encumbered,
 Not if used for govt/defense purposes.  For commercial-only purposes, TI 
 will waive royalty fees if their chip is
 used
 in the product.  It would have been nice if Digium had considered the many 
 advantages of using a DSP pioneer such
 as
 TI before putting a Mindspeed chip on their TC400B card.
>>> I think all the IP for MELP is now in the hands of Compandent, and TI no
>>> longer has the ability to waive royalties.
>> That is not correct.  Compandent has filed copyrights on certain files 
>> associated with a C549 chip assembly language
>> implementation they did under contract to NSA around 2001.  TI has patent 
>> rights on 2400 bps, TI + Microsoft on 1200
>> bps, and TI + Microsoft + Thales Group on 600 bps.  Microsoft's IP came 
>> about as a result of acquiring a company
>> called SignalCom around 2001.  If the noise pre-processor is used, then 
>> there is some AT&T IP.  To verify this, you
>> can search dsprelated.com (specifically, look for posts discussing this 
>> issue on comp.dsp), and you can also read
>> the
>> "Compandent IPR" section of the MELPe Wikipedia page
>> (http://en.wikipedia.org/wiki/Mixed_Excitation_Linear_Prediction).  That 
>> section was authored by the Compandent's
>> founder, Oded Gottesman.  Oded is a super sharp, very hard working guy.
>>
>> Compandent also claims a copyright on some C code in the file melp_syn.c 
>> (synthesis filter).  I have read
>> discussions
>> by DSP experts indicating the copyrighted section of code can be implemented 
>> in alternative ways, but Oded may say
>> that's not accurate.
> That guy is PITA. He must have driven a lot of people away from MELP by
> the way he acts. He really annoys the regulars in the comp.dsp group by
> posting astroturf questions about MELP, and giving astroturf replies
> about how fantastic it is. That probably shapes a lot of my attitude to
> MELP. :-)
>>> Either way, government use
>>> and use with TI silicon are two niches that might work out well, and
>>> everything else is a problem for several more years. If you are going to
>>> pay royalties for a low bit rate codec, IMBE is probably a better option.
>> I would disagree because IMBE source is not available.  MELPe source is 
>> available and can be downloaded online.
> Depends what you mean by available. IMBE is patented, just like MELP is
> patented. Licence either, and implementations are available.

I meant that MELPe C source code is available for non-commercial purposes 
(academic, R&D, bug fixes and other source
level improvements) without payment and without signing a license agreement 
with a corporation (such as Digital Voice
with IMBE).

> IMBE has
> the great benefit of being widely used for commercial and amateur low
> bit rate channels. For example, amateur radio uses IMBE - an anomaly
> which is one of the drivers for David Rowe's work on an open low bit
> rate codec. Transcoding at low bit rates is a disaster, so using a codec
> you won't need to transcode is a big plus.

Yes all good points.  IMBE and AMBE have surely been successful, testaments to 
the Digital Voice guys and their
pioneering work in the LBR codec area.

>>> TI is a good option, but what do you have against Mindspeed? Choosing a
>>> good option for this kind of card is mostly about managing the patent
>>> licence fees. I assume Mindspeed gave Digium the best option for doing
>>> that, within Digium's volume constraints.
>> My understanding in talking to Digium engineers at Globalcom and other trade 
>> shows back in 2006 is they were worried
>> about interfacing the TI TNET series devices over the PCI bus.  They would 
>> have needed an FPGA with some non-trivial
>> logic programming, so I understand their decision.  But if they had got past 
>> their FPGA "writer's

Re: [asterisk-users] Codec Conversion

[Steve Underwood]

  On 08/07/2010 03:15 AM, Jeff Brower wrote:
> Steve-
>
>> El 05/08/10 14:50, Tim Nelson escribió:
>>> - "michel freiha"wrote:
 Dear Sir,

 I tried to convert ilbc to ulaw and get the same result...Bad Voice
>>> Quality
 Regards

>>> Again, iLBC is poor quality to begin with. You can't take a poor audio
>>> sample and make it better by converting it to a codec with better
>>> 'resolution'. An audio sample full of robot voice is going to sound
>>> like the same robot voice even if you transcode it to a better quality
>>> codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.
>>>
>>> --Tim
>> This just made me remember some comment on the iax.conf sample file...
>>
>> disallow=lpc10; Icky sound quality...  Mr. Roboto.
> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job 
> with pitch detection so it tends to have
> a
> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or 
> less should not be using LPC10.
>
> -Jeff
 MELPe is patent encumbered,
>>> Not if used for govt/defense purposes.  For commercial-only purposes, TI 
>>> will waive royalty fees if their chip is
>>> used
>>> in the product.  It would have been nice if Digium had considered the many 
>>> advantages of using a DSP pioneer such as
>>> TI before putting a Mindspeed chip on their TC400B card.
>> I think all the IP for MELP is now in the hands of Compandent, and TI no
>> longer has the ability to waive royalties.
> That is not correct.  Compandent has filed copyrights on certain files 
> associated with a C549 chip assembly language
> implementation they did under contract to NSA around 2001.  TI has patent 
> rights on 2400 bps, TI + Microsoft on 1200
> bps, and TI + Microsoft + Thales Group on 600 bps.  Microsoft's IP came about 
> as a result of acquiring a company
> called SignalCom around 2001.  If the noise pre-processor is used, then there 
> is some AT&T IP.  To verify this, you
> can search dsprelated.com (specifically, look for posts discussing this issue 
> on comp.dsp), and you can also read the
> "Compandent IPR" section of the MELPe Wikipedia page
> (http://en.wikipedia.org/wiki/Mixed_Excitation_Linear_Prediction).  That 
> section was authored by the Compandent's
> founder, Oded Gottesman.  Oded is a super sharp, very hard working guy.
>
> Compandent also claims a copyright on some C code in the file melp_syn.c 
> (synthesis filter).  I have read discussions
> by DSP experts indicating the copyrighted section of code can be implemented 
> in alternative ways, but Oded may say
> that's not accurate.
That guy is PITA. He must have driven a lot of people away from MELP by 
the way he acts. He really annoys the regulars in the comp.dsp group by 
posting astroturf questions about MELP, and giving astroturf replies 
about how fantastic it is. That probably shapes a lot of my attitude to 
MELP. :-)
>> Either way, government use
>> and use with TI silicon are two niches that might work out well, and
>> everything else is a problem for several more years. If you are going to
>> pay royalties for a low bit rate codec, IMBE is probably a better option.
> I would disagree because IMBE source is not available.  MELPe source is 
> available and can be downloaded online.
Depends what you mean by available. IMBE is patented, just like MELP is 
patented. Licence either, and implementations are available. IMBE has 
the great benefit of being widely used for commercial and amateur low 
bit rate channels. For example, amateur radio uses IMBE - an anomaly 
which is one of the drivers for David Rowe's work on an open low bit 
rate codec. Transcoding at low bit rates is a disaster, so using a codec 
you won't need to transcode is a big plus.


>> TI is a good option, but what do you have against Mindspeed? Choosing a
>> good option for this kind of card is mostly about managing the patent
>> licence fees. I assume Mindspeed gave Digium the best option for doing
>> that, within Digium's volume constraints.
> My understanding in talking to Digium engineers at Globalcom and other trade 
> shows back in 2006 is they were worried
> about interfacing the TI TNET series devices over the PCI bus.  They would 
> have needed an FPGA with some non-trivial
> logic programming, so I understand their decision.  But if they had got past 
> their FPGA "writer's block", they could
> have put one TNETV3010 chip on there, even smaller than the Mindspeed and 
> without the heat sink, and had twice the
> channel capacity as they do now.
TI have had DSP chips with a PCI interface for years, so that 
explanation doesn't make a lot of sense. Of course, these days you need 
a PCI-E interface. I'm not so sure about the status of those in DSP chips.
>> so there is still a place for LPC10 [...]

> e>>  I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to 
> its 

Re: [asterisk-users] Codec Conversion

[Jeff Brower]

Steve-

> El 05/08/10 14:50, Tim Nelson escribió:
>> - "michel freiha"   wrote:
>>> Dear Sir,
>>>
>>> I tried to convert ilbc to ulaw and get the same result...Bad Voice
>> Quality
>>> Regards
>>>
>> Again, iLBC is poor quality to begin with. You can't take a poor audio
>> sample and make it better by converting it to a codec with better
>> 'resolution'. An audio sample full of robot voice is going to sound
>> like the same robot voice even if you transcode it to a better quality
>> codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.
>>
>> --Tim
> This just made me remember some comment on the iax.conf sample file...
>
> disallow=lpc10; Icky sound quality...  Mr. Roboto.
 LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job 
 with pitch detection so it tends to have
 a
 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or 
 less should not be using LPC10.

 -Jeff
>>> MELPe is patent encumbered,
>> Not if used for govt/defense purposes.  For commercial-only purposes, TI 
>> will waive royalty fees if their chip is
>> used
>> in the product.  It would have been nice if Digium had considered the many 
>> advantages of using a DSP pioneer such as
>> TI before putting a Mindspeed chip on their TC400B card.
>
> I think all the IP for MELP is now in the hands of Compandent, and TI no
> longer has the ability to waive royalties.

That is not correct.  Compandent has filed copyrights on certain files 
associated with a C549 chip assembly language
implementation they did under contract to NSA around 2001.  TI has patent 
rights on 2400 bps, TI + Microsoft on 1200
bps, and TI + Microsoft + Thales Group on 600 bps.  Microsoft's IP came about 
as a result of acquiring a company
called SignalCom around 2001.  If the noise pre-processor is used, then there 
is some AT&T IP.  To verify this, you
can search dsprelated.com (specifically, look for posts discussing this issue 
on comp.dsp), and you can also read the
"Compandent IPR" section of the MELPe Wikipedia page
(http://en.wikipedia.org/wiki/Mixed_Excitation_Linear_Prediction).  That 
section was authored by the Compandent's
founder, Oded Gottesman.  Oded is a super sharp, very hard working guy.

Compandent also claims a copyright on some C code in the file melp_syn.c 
(synthesis filter).  I have read discussions
by DSP experts indicating the copyrighted section of code can be implemented in 
alternative ways, but Oded may say
that's not accurate.

> Either way, government use
> and use with TI silicon are two niches that might work out well, and
> everything else is a problem for several more years. If you are going to
> pay royalties for a low bit rate codec, IMBE is probably a better option.

I would disagree because IMBE source is not available.  MELPe source is 
available and can be downloaded online.

> TI is a good option, but what do you have against Mindspeed? Choosing a
> good option for this kind of card is mostly about managing the patent
> licence fees. I assume Mindspeed gave Digium the best option for doing
> that, within Digium's volume constraints.

My understanding in talking to Digium engineers at Globalcom and other trade 
shows back in 2006 is they were worried
about interfacing the TI TNET series devices over the PCI bus.  They would have 
needed an FPGA with some non-trivial
logic programming, so I understand their decision.  But if they had got past 
their FPGA "writer's block", they could
have put one TNETV3010 chip on there, even smaller than the Mindspeed and 
without the heat sink, and had twice the
channel capacity as they do now.

>>> so there is still a place for LPC10 [...]
e>> I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to 
its age and expiration of patents, LPC10
>> might be a basis for a 2400 bps open source codec.  But enormous improvement 
>> would be needed to come close to MELPe
>> performance.
>>
>>
> MELPe is definitely a compandent thing, and TI cannot waive fees for
> that. MELP and MELPe are derived from LPC10. Any attempt to improve
> LPC10 would take you down a similar road, though you would need to skirt
> around the patents.

Again, not correct.  Suggest to research the many online independent sources, 
or contact NSA (who initiated the
overall MELPe effort in the 1990s, in response to a need to significantly 
improve over LPC10) and who can give you a
complete IP list.

> Do you really consider MELPe to be an enormous improvement over LPC10?
> Its still pretty lousy compared to a number of options at about 5kbps,
> and RTP overheads mean the gain from going lower than 5k isn't that big.
> The main reason LPC10 and MELPe offer a low bit rate in RTP is the
> minimum packet you can pack 22.5ms frames into sanely is a 90ms one.

In MOS terms, yes.  In VoIP terms, I agree it's not clear cut.  At 2400 bps, a 
90 msec packet would

Re: [asterisk-users] Codec Conversion

[Steve Underwood]

  On 08/06/2010 04:43 PM, Jeff Brower wrote:
> Steve-
>
>>On 08/06/2010 05:40 AM, Jeff Brower wrote:
>>> Miguel-
>>>
 El 05/08/10 14:50, Tim Nelson escribió:
> - "michel freiha"   wrote:
>> Dear Sir,
>>
>> I tried to convert ilbc to ulaw and get the same result...Bad Voice
> Quality
>> Regards
>>
> Again, iLBC is poor quality to begin with. You can't take a poor audio
> sample and make it better by converting it to a codec with better
> 'resolution'. An audio sample full of robot voice is going to sound
> like the same robot voice even if you transcode it to a better quality
> codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.
>
> --Tim
 This just made me remember some comment on the iax.conf sample file...

 disallow=lpc10; Icky sound quality...  Mr. Roboto.
>>> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job 
>>> with pitch detection so it tends to have a
>>> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or 
>>> less should not be using LPC10.
>>>
>>> -Jeff
>> MELPe is patent encumbered,
> Not if used for govt/defense purposes.  For commercial-only purposes, TI will 
> waive royalty fees if their chip is used
> in the product.  It would have been nice if Digium had considered the many 
> advantages of using a DSP pioneer such as
> TI before putting a Mindspeed chip on their TC400B card.

I think all the IP for MELP is now in the hands of Compandent, and TI no 
longer has the ability to waive royalties. Either way, government use 
and use with TI silicon are two niches that might work out well, and 
everything else is a problem for several more years. If you are going to 
pay royalties for a low bit rate codec, IMBE is probably a better option.

TI is a good option, but what do you have against Mindspeed? Choosing a 
good option for this kind of card is mostly about managing the patent 
licence fees. I assume Mindspeed gave Digium the best option for doing 
that, within Digium's volume constraints.
>> so there is still a place for LPC10 [...]
> I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to its 
> age and expiration of patents, LPC10
> might be a basis for a 2400 bps open source codec.  But enormous improvement 
> would be needed to come close to MELPe
> performance.
>
>
MELPe is definitely a compandent thing, and TI cannot waive fees for 
that. MELP and MELPe are derived from LPC10. Any attempt to improve 
LPC10 would take you down a similar road, though you would need to skirt 
around the patents.

Do you really consider MELPe to be an enormous improvement over LPC10? 
Its still pretty lousy compared to a number of options at about 5kbps, 
and RTP overheads mean the gain from going lower than 5k isn't that big. 
The main reason LPC10 and MELPe offer a low bit rate in RTP is the 
minimum packet you can pack 22.5ms frames into sanely is a 90ms one. 
90ms RTP *really* cuts the overheads, compared to the more typical 20ms 
or 30ms packets used for G.729.

As others have mentioned, David Rowe is working on a modern 2400bps 
codec. He did a burst of work some time ago, and then put it aside while 
busy with other things. He recently told me he is restarting the work, 
and he wants to get that codec into good shape before the end of this year.

Steve

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Michael Graves]

On Fri, 06 Aug 2010 07:40:44 -0500, Michael Graves wrote:

>On Fri, 6 Aug 2010 03:43:33 -0500 (CDT), Jeff Brower wrote:
>
>
>
>>> MELPe is patent encumbered,
>>
>>Not if used for govt/defense purposes.  For commercial-only purposes, TI will 
>>waive royalty fees if their chip is used
>>in the product.  It would have been nice if Digium had considered the many 
>>advantages of using a DSP pioneer such as
>>TI before putting a Mindspeed chip on their TC400B card.
>>
>>> so there is still a place for LPC10 [...]
>>
>>I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to its 
>>age and expiration of patents, LPC10
>>might be a basis for a 2400 bps open source codec.  But enormous improvement 
>>would be needed to come close to MELPe
>>performance.
>>
>>-Jeff
>
>I wonder where David Rowe's newer CODEC2 fits into this discussion?
>(http://codec2.org/)
>
>Clearly it's not implemented anywhere yet, but it may prove yet useful
>in very bandwidth constrained applications. Oh yes. It's completely
>open source and should not be subject to patent issues.
>
>Michael

The more appropriate link should have been
http://www.rowetel.com/blog/?page_id=452

Michael
--
Michael Graves
mgravesmstvp.com
http://www.mgraves.org
o713-861-4005
c713-201-1262
sip:mgra...@mstvp.onsip.com
skype mjgraves
Twitter mjgraves




-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Michael Graves]

On Fri, 6 Aug 2010 03:43:33 -0500 (CDT), Jeff Brower wrote:



>> MELPe is patent encumbered,
>
>Not if used for govt/defense purposes.  For commercial-only purposes, TI will 
>waive royalty fees if their chip is used
>in the product.  It would have been nice if Digium had considered the many 
>advantages of using a DSP pioneer such as
>TI before putting a Mindspeed chip on their TC400B card.
>
>> so there is still a place for LPC10 [...]
>
>I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to its 
>age and expiration of patents, LPC10
>might be a basis for a 2400 bps open source codec.  But enormous improvement 
>would be needed to come close to MELPe
>performance.
>
>-Jeff

I wonder where David Rowe's newer CODEC2 fits into this discussion?
(http://codec2.org/)

Clearly it's not implemented anywhere yet, but it may prove yet useful
in very bandwidth constrained applications. Oh yes. It's completely
open source and should not be subject to patent issues.

Michael
--
Michael Graves
mgravesmstvp.com
http://www.mgraves.org
o713-861-4005
c713-201-1262
sip:mgra...@mstvp.onsip.com
skype mjgraves
Twitter mjgraves




-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Jeff Brower]

Steve-

>   On 08/06/2010 05:40 AM, Jeff Brower wrote:
>> Miguel-
>>
>>> El 05/08/10 14:50, Tim Nelson escribió:
 - "michel freiha"  wrote:
> Dear Sir,
>
> I tried to convert ilbc to ulaw and get the same result...Bad Voice
 Quality
> Regards
>
 Again, iLBC is poor quality to begin with. You can't take a poor audio
 sample and make it better by converting it to a codec with better
 'resolution'. An audio sample full of robot voice is going to sound
 like the same robot voice even if you transcode it to a better quality
 codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.

 --Tim
>>> This just made me remember some comment on the iax.conf sample file...
>>>
>>> disallow=lpc10; Icky sound quality...  Mr. Roboto.
>> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job 
>> with pitch detection so it tends to have a
>> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or less 
>> should not be using LPC10.
>>
>> -Jeff
> MELPe is patent encumbered,

Not if used for govt/defense purposes.  For commercial-only purposes, TI will 
waive royalty fees if their chip is used
in the product.  It would have been nice if Digium had considered the many 
advantages of using a DSP pioneer such as
TI before putting a Mindspeed chip on their TC400B card.

> so there is still a place for LPC10 [...]

I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to its 
age and expiration of patents, LPC10
might be a basis for a 2400 bps open source codec.  But enormous improvement 
would be needed to come close to MELPe
performance.

-Jeff


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Steve Underwood]

  On 08/06/2010 05:40 AM, Jeff Brower wrote:
> Miguel-
>
>> El 05/08/10 14:50, Tim Nelson escribió:
>>> - "michel freiha"  wrote:
 Dear Sir,

 I tried to convert ilbc to ulaw and get the same result...Bad Voice
>>> Quality
 Regards

>>> Again, iLBC is poor quality to begin with. You can't take a poor audio
>>> sample and make it better by converting it to a codec with better
>>> 'resolution'. An audio sample full of robot voice is going to sound
>>> like the same robot voice even if you transcode it to a better quality
>>> codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.
>>>
>>> --Tim
>> This just made me remember some comment on the iax.conf sample file...
>>
>> disallow=lpc10; Icky sound quality...  Mr. Roboto.
> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job 
> with pitch detection so it tends to have a
> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or less 
> should not be using LPC10.
>
> -Jeff
MELPe is patent encumbered, so there is still a place for LPC10. LPC10 
should sound a lot better than the one in Asterisk. The Asterisk codec 
is broken.

Steve


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Miguel Molina]

>> This just made me remember some comment on the iax.conf sample file...
>>
>> disallow=lpc10; Icky sound quality...  Mr. Roboto.
>>  
> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job 
> with pitch detection so it tends to have a
> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or less 
> should not be using LPC10.
>
> -Jeff
>
>
OK, on years I have working with asterisk I never have used, tested or 
even heard that old codec. I was just quoting the funny comment...

Cheers,

-- 
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Jeff Brower]

Miguel-

> El 05/08/10 14:50, Tim Nelson escribió:
>> - "michel freiha"  wrote:
>> >
>> > Dear Sir,
>> >
>> > I tried to convert ilbc to ulaw and get the same result...Bad Voice
>> Quality
>> >
>> > Regards
>> >
>>
>> Again, iLBC is poor quality to begin with. You can't take a poor audio
>> sample and make it better by converting it to a codec with better
>> 'resolution'. An audio sample full of robot voice is going to sound
>> like the same robot voice even if you transcode it to a better quality
>> codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.
>>
>> --Tim
> This just made me remember some comment on the iax.conf sample file...
>
> disallow=lpc10; Icky sound quality...  Mr. Roboto.

LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job with 
pitch detection so it tends to have a
'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or less 
should not be using LPC10.

-Jeff


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Miguel Molina]

El 05/08/10 14:50, Tim Nelson escribió:

- "michel freiha"  wrote:
>
> Dear Sir,
>
> I tried to convert ilbc to ulaw and get the same result...Bad Voice 
Quality

>
> Regards
>

Again, iLBC is poor quality to begin with. You can't take a poor audio 
sample and make it better by converting it to a codec with better 
'resolution'. An audio sample full of robot voice is going to sound 
like the same robot voice even if you transcode it to a better quality 
codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.


--Tim

This just made me remember some comment on the iax.conf sample file...

disallow=lpc10; Icky sound quality...  Mr. Roboto.

Cheers,

--
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Jeff Brower]

Michel-

> I tried to convert ilbc to ulaw and get the same
> result...Bad Voice Quality

I think you have to be more specific when you say "bad voice quality".  Like 
what?  Worse than a cellphone call?  Gaps
of audio missing?  Robotic or "cyborg" sound?  Static?  A background tone or 
buzzing?

iLBC isn't any worse voice quality than other LBR codecs (GSM-AMR, EVRC, etc).  
If you want land-line quality and what
you're hearing is cellphone quality, then you're asking too much.  Otherwise, 
suggest to be specific and detailed in
describing your problem.

-Jeff

> On Thu, Aug 5, 2010 at 4:13 PM, Tim Nelson  wrote:
>
>> - "michel freiha"  wrote:
>> >
>> > Dear All,
>> >
>> > i would like to ask please if someone tried to make a codec conversion
>> from ilbc to g729, because i did that but the voice quality was too bad and
>> a lot of disconnection..
>> >
>> > Can i get your feedback regarding this issue please?
>> >
>> > regards
>>
>> I can't comment on your 'disconnection' as you don't say if that means the
>> call is disconnected or you're getting stuttered audio. Regardless, iLBC has
>> one of the lowest bitrates of the available codecs and as such the voice
>> quality is not spectacular to begin with. Take 'not so good' audio and try
>> to convert it to another audio format, and the deficiencies can be
>> exacerbated.
>>
>> --Tim


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Tim Nelson]

- "michel freiha"  wrote: 
> 
> Dear Sir, 
> 
> I tried to convert ilbc to ulaw and get the same result...Bad Voice Quality 
> 
> Regards 
> 


Again, iLBC is poor quality to begin with. You can't take a poor audio sample 
and make it better by converting it to a codec with better 'resolution'. An 
audio sample full of robot voice is going to sound like the same robot voice 
even if you transcode it to a better quality codec, whether that is G.729, 
G.711u, or the latest 'HD Voice' codecs. 


--Tim -- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[michel freiha]

Dear Sir,

I tried to convert ilbc to ulaw and get the same result...Bad Voice Quality

Regards

On Thu, Aug 5, 2010 at 4:13 PM, Tim Nelson  wrote:

> - "michel freiha"  wrote:
> >
> > Dear All,
> >
> > i would like to ask please if someone tried to make a codec conversion
> from ilbc to g729, because i did that but the voice quality was too bad and
> a lot of disconnection..
> >
> > Can i get your feedback regarding this issue please?
> >
> > regards
>
> I can't comment on your 'disconnection' as you don't say if that means the
> call is disconnected or you're getting stuttered audio. Regardless, iLBC has
> one of the lowest bitrates of the available codecs and as such the voice
> quality is not spectacular to begin with. Take 'not so good' audio and try
> to convert it to another audio format, and the deficiencies can be
> exacerbated.
>
> --Tim
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec Conversion

[Tim Nelson]

- "michel freiha"  wrote: 
> 
> Dear All, 
> 
> i would like to ask please if someone tried to make a codec conversion from 
> ilbc to g729, because i did that but the voice quality was too bad and a lot 
> of disconnection.. 
> 
> Can i get your feedback regarding this issue please? 
> 
> regards 


I can't comment on your 'disconnection' as you don't say if that means the call 
is disconnected or you're getting stuttered audio. Regardless, iLBC has one of 
the lowest bitrates of the available codecs and as such the voice quality is 
not spectacular to begin with. Take 'not so good' audio and try to convert it 
to another audio format, and the deficiencies can be exacerbated. 


--Tim -- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Philipp von Klitzing]

> Only when I configure my Grandstream to use only G726 (I have 8 
> choices), I see that the g726-codec is used.
> When I configure 7 x g726 and 1 x alaw, then again alaw is used !
> 
> Is it normal that Asterisk has such a great preference for alaw ?! The
> moment the peer suggests codec alaw (even if it is last choice), alaw is
> chosen by Asterisk for the communication.

Please look at the first part of my last message (order of codecs in the 
[general] section) and apply changes there, followed by a "sip reload".

Philipp


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec Conversion

[michel freiha]

Dear All,

i would like to ask please if someone tried to make a codec conversion from
ilbc to g729, because i did that but the voice quality was too bad and a lot
of disconnection..

Can i get your feedback regarding this issue please?

regards
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Jonas Kellens]

On 08/03/2010 04:21 PM, Philipp von Klitzing wrote:
> Also:
>
> There are at least two implementations of the g726 codec, i.e. g726 and
> g726aal2. For this also look at the g726nonstandard setting in sip.conf.
> It is quite possible that your problem is here.
>

I have the following setting in sip.conf :

g726nonstandard = no  ; If the peer negotiates G726-32 audio, 
use AAL2 packing
 ; order instead of RFC3551 packing 
order (this is required
 ; for Sipura and Grandstream ATAs, 
among others). This is
 ; contrary to the RFC3551 
specification, the peer _should_
 ; be negotiating AAL2-G726-32 instead

(so it uses RFC3551)

> For quick testing to see if the codec works at all: Configure your phones
> to do g726 only (so no alaw/ualaw at all).
>

Only when I configure my Grandstream to use only G726 (I have 8 
choices), I see that the g726-codec is used.
When I configure 7 x g726 and 1 x alaw, then again alaw is used !

Is it normal that Asterisk has such a great preference for alaw ?! The 
moment the peer suggests codec alaw (even if it is last choice), alaw is 
chosen by Asterisk for the communication.



Kind regards,

Jonas.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Philipp von Klitzing]

Hi!

> In the [general] section of sip.conf I have :
> 
> disallow=all
> allow=g726
> allow=alaw
> allow=g729
> allow=gsm

So change the order there and see what happens.

> > * look at the variable SIP_CODEC for the inbound (first) call leg, and
> > in Asterisk 1.8 (or 1.6.2?) also at SIP_CODEC_OUTBOUND
> 
> When I read the value of this variable just before the Dial()-statement,
> it is empty.

You need to set it, not read it.

Philipp


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Philipp von Klitzing]

Also:

There are at least two implementations of the g726 codec, i.e. g726 and 
g726aal2. For this also look at the g726nonstandard setting in sip.conf. 
It is quite possible that your problem is here.

For quick testing to see if the codec works at all: Configure your phones 
to do g726 only (so no alaw/ualaw at all).

Philipp


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Jonas Kellens]

Hello Philipp,

thank you for your answer.


On 08/03/2010 01:21 PM, Philipp von Klitzing wrote:
>> Question 3 :
>> How can I get g726 as first preferred codec ??
>>  
> Which Asterisk version are you using?
>

Using Asterisk 1.4.30

> * check if you have disallow/allow settings in the [general] section of
> sip.conf. Depending on your Asterisk version only the order in [general]
> would be respected, but not the order in the individual sip peer/user
> definition
>

In the [general] section of sip.conf I have :

disallow=all
allow=g726
allow=alaw
allow=g729
allow=gsm

> * look at the variable SIP_CODEC for the inbound (first) call leg, and in
> Asterisk 1.8 (or 1.6.2?) also at SIP_CODEC_OUTBOUND
>

When I read the value of this variable just before the Dial()-statement, 
it is empty.



Jonas.


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Philipp von Klitzing]

Hi!

> Question 1 :
> [Aug 2 13:56:57] Capabilities: us - 0x90a (gsm|alaw|g726|g729), peer -
> audio=0x808 (alaw|g726)/video=0x0 (nothing), combined - 0x808 (alaw|g726)
> why is combined alaw|g726 and not g726|alaw (reverse) ??

Guess: Here the order presented has no meaning for the order of codec 
negotiation.

> Question 2 :
> why do I see on my Grandstream phone that the codec being used is alaw in
> stead of g726 ??

Because that is what the phone and Asterisk have negotiated. ;-)

> Question 3 :
> How can I get g726 as first preferred codec ??

Which Asterisk version are you using?

* check if you have disallow/allow settings in the [general] section of 
sip.conf. Depending on your Asterisk version only the order in [general] 
would be respected, but not the order in the individual sip peer/user 
definition

* look at the variable SIP_CODEC for the inbound (first) call leg, and in 
Asterisk 1.8 (or 1.6.2?) also at SIP_CODEC_OUTBOUND

* many Asterisk operators have applied the third party "codec negotiation 
patch"

Philipp


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec negotiation : expecting G726, getting G711a (alaw)

[Jonas Kellens]

Hello list,

Grandstream GXP2010 phone calling to Snom 320, Asterisk in the middle.

Grandstream allows for 8 different codec specifications. I have defined 
them as 4 x G726 & 4 x alaw.
Snom allow for 7 different codec specifications. I have defined them as 
3 x G726 & 4 x G729.


The SIP peers are both defined as :

disallow=all
allow=g726
allow=alaw
allow=g729
allow=gsm



This is the SIP trace :


INVITE sip:2...@192.168.1.150 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9
From: "User" ;tag=2383fb163ee6befa
To: 
Contact: 
Supported: replaces, timer, path
Proxy-Authorization: Digest username="user", realm="domain.be", 
algorithm=MD5, uri="sip:2...@192.168.1.150", nonce="1ae22736", 
response="c90d0d9bf1f3c2bbc020651a5b67b608"

Call-ID: 8910dbc6f2d5f...@192.168.1.102
CSeq: 35396 INVITE
*User-Agent: Grandstream GXP2010 1.2.1.4*
Max-Forwards: 70
Allow: 
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE

Content-Type: application/sdp
Content-Length: 250

v=0
o=user 8000 8001 IN IP4 192.168.1.102
s=SIP Call
c=IN IP4 192.168.1.102
t=0 0
m=audio 10126 RTP/AVP 2 8 101
a=sendrecv
*a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000*
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11

<->
[Aug  2 13:56:57] --- (14 headers 12 lines) ---
[Aug  2 13:56:57] Sending to 192.168.1.102 : 5062 (NAT)
[Aug  2 13:56:57] Using INVITE request as basis request - 
8910dbc6f2d5f...@192.168.1.102

[Aug  2 13:56:57] Found user 'user'
[Aug  2 13:56:57] Found RTP audio format 2
[Aug  2 13:56:57] Found RTP audio format 8
[Aug  2 13:56:57] Found RTP audio format 101
[Aug  2 13:56:57] Found audio description format G726-32 for ID 2
[Aug  2 13:56:57] Found audio description format PCMA for ID 8
[Aug  2 13:56:57] Found audio description format telephone-event for ID 101
*[Aug  2 13:56:57] Capabilities: us - 0x90a (gsm|alaw|g726|g729), peer - 
audio=0x808 (alaw|g726)/video=0x0 (nothing), combined - 0x808 (alaw|g726)*
[Aug  2 13:56:57] Non-codec capabilities (dtmf): us - 0x1 
(telephone-event), peer - 0x1 (telephone-event), combined - 0x1 
(telephone-event)

[Aug  2 13:56:57] Peer audio RTP is at port 192.168.1.102:10126
[Aug  2 13:56:57] Looking for 20 in from-STERKEN (domain 192.168.1.150)
[Aug  2 13:56:57] list_route: hop: 


[Aug  2 13:56:57]
<--- Transmitting (NAT) to 192.168.1.102:5062 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 
192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9;received=192.168.1.102

From: "User" ;tag=2383fb163ee6befa
To: 
Call-ID: 8910dbc6f2d5f...@192.168.1.102
CSeq: 35396 INVITE
User-Agent: my-asterisk-server
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Length: 0


<->
[Aug  2 13:56:57] --- (11 headers 0 lines) ---
[Aug  2 13:56:57] SIP Response message for INCOMING dialog NOTIFY arrived
[Aug  2 13:56:57] -- SIP/sterkendries2-0054 is ringing
[Aug  2 13:56:57]
<--- Transmitting (NAT) to 192.168.1.102:5062 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 
192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9;received=192.168.1.102

From: "User" ;tag=2383fb163ee6befa
To: ;tag=as655a8251
Call-ID: 8910dbc6f2d5f...@192.168.1.102
CSeq: 35396 INVITE
*User-Agent: my-asterisk-server*
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Length: 0

---
[Aug  2 13:57:00]  Extension Changed 20[105002-blf] new state InUse for 
Notify User user
[Aug  2 13:57:00] -- SIP/sterkendries2-0054 answered 
SIP/user-0053

[Aug  2 13:57:00] Audio is at 192.168.1.150 port 11500
[Aug  2 13:57:00] Adding codec 0x8 (alaw) to SDP
[Aug  2 13:57:00] Adding codec 0x800 (g726) to SDP
[Aug  2 13:57:00] Adding non-codec 0x1 (telephone-event) to SDP
[Aug  2 13:57:00]
<--- Reliably Transmitting (NAT) to 192.168.1.102:5062 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
192.168.1.102:5062;branch=z9hG4bK1dc39a962389c1a9;received=192.168.1.102

From: "User" ;tag=2383fb163ee6befa
To: ;tag=as655a8251
Call-ID: 8910dbc6f2d5f...@192.168.1.102
CSeq: 35396 INVITE
*User-Agent: my-asterisk-server*
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 267

v=0
o=root 1947 1947 IN IP4 192.168.1.150
s=session
c=IN IP4 192.168.1.150
t=0 0
m=audio 11500 RTP/AVP 8 2 101
*a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000*
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


<->
[Aug  2 13:57:00] --- (11 headers 0 lines) ---
[Aug  2 13:57:00] SIP Response message for INCOMING dialog NOTIFY arrived
[Aug  2 13:57:00]
<--- SIP read from 192.168.1.102:5062 --->
ACK sip:2...@192.168.1.150 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.102:5062;branch=z9hG4bK76a685e83ba8aef8
From: "User" ;tag=2383fb163ee6befa
To: ;tag=as655a8251
Contact: 
Supported: path
Proxy-Authorization: Digest username="user", realm="domain.be", 
algorithm=MD5, uri="sip:2.

Re: [asterisk-users] Codec negotiation

[Ryan Wagoner]

On Tue, Jun 29, 2010 at 6:42 PM, Philipp von Klitzing
 wrote:
> Hi!
>
>> Because the codec is already chosen before the call is made, and you
>> told it that g722 is permitted.
>>
>> There are all sorts of discussions in play about codec negotiation,
>> but at this point in time, if you want different behaviour you'll need to
>> go and code it yourself
>
> Look at the list archive - there is a codec negotiation patch around:
>
> http://lists.digium.com/pipermail/asterisk-users/2010-
> February/244835.html
>
> The OP might also want to consider to use different lines to the same
> PBX, one for normal narrowband, and another one for g722.
>
> Philipp
>
>
> --

Thanks! I'm going to try setting the _SIP_CODEC variable for outbound
calls to force ulaw. This should solve the issue. Having two lines
would work but I can't sell this to a customer. There has got to be a
better way to have Asterisk handle this. With Asterisk in the middle
of the RTP stream it knows what both parties support. If it turns out
Asterisk is transcoding it could check for a common codec and
renegotiate one endpoint.

Ryan

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[Philipp von Klitzing]

Hi!

> Does the 1.4.26.2-patch also work with asterisk 1.4.30 ??

Most probably - who on this list would you like to test it for you? ;->

Philipp


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[Philipp von Klitzing]

Hi!

> Because the codec is already chosen before the call is made, and you
> told it that g722 is permitted.
> 
> There are all sorts of discussions in play about codec negotiation,
> but at this point in time, if you want different behaviour you'll need to
> go and code it yourself

Look at the list archive - there is a codec negotiation patch around:

http://lists.digium.com/pipermail/asterisk-users/2010-
February/244835.html

The OP might also want to consider to use different lines to the same 
PBX, one for normal narrowband, and another one for g722.

Philipp


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[Jonas Kellens]

Does the 1.4.26.2-patch also work with asterisk 1.4.30 ??

I have reported a codec-issue, but there is no solution. Will this patch 
also answer my question ??

https://issues.asterisk.org/view.php?id=17020


Jonas.


On 06/29/2010 09:42 PM, Mindaugas Kezys wrote:

Try this: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch

Regards,
Mindaugas Kezys

Kolmisoft UAB
VoIP Billing Solutions
e-mail: i...@kolmisoft.com
URL: http://www.kolmisoft.com


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[mike mosier]

>From what I have seen if your sip provider does not take g722 then you will
have problems with outgoing calls. When I tried this, the same way you did,
I could make calles externally but had no audio each way reguardless of what
I tried to pass to the sip provider. Best bet is to use what your sip
provider can use or find another provider that that can do g722. That's what
I did when I wanted to use g726.

my2cents

On Tue, Jun 29, 2010 at 2:42 PM, Mindaugas Kezys  wrote:

> Try this: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch
>
> Regards,
> Mindaugas Kezys
>
> Kolmisoft UAB
> VoIP Billing Solutions
> e-mail: i...@kolmisoft.com
> URL: http://www.kolmisoft.com
>
>
> -Original Message-
> From: asterisk-users-boun...@lists.digium.com
> [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Steve Davies
> Sent: Tuesday, June 29, 2010 7:51 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] Codec negotiation
>
> On 26 June 2010 22:08, Ryan Wagoner  wrote:
> > I have Polycom phones that support the g722 codec. Adding allow=g722
> > to the [general] section of sip.conf works great and I can make calls
> > between the phones using g722. However Asterisk is negotiating g722
> > for calls going out my voip provider and transcoding these to ulaw. In
> > sip.conf for the provider I have deny=all and allow=ulaw. This can
> > cause potential audio degrading and wastes cpu cycles. If Asterisk
> > knows the trunk only supports ulaw why would it offer g722 to the
> > phone.
> >
> > Ryan
>
> Because the codec is already chosen before the call is made, and you
> told it that g722 is permitted.
>
> There are all sorts of discussions in play about codec negotiation,
> but at this point in time, if you want different behaviour you'll need
> to go and code it yourself, and cross-channeltype this is not going to
> be trivial :)
>
> Cheers,
> Steve
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[Mindaugas Kezys]

Try this: http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch

Regards,
Mindaugas Kezys

Kolmisoft UAB 
VoIP Billing Solutions
e-mail: i...@kolmisoft.com
URL: http://www.kolmisoft.com


-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Steve Davies
Sent: Tuesday, June 29, 2010 7:51 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Codec negotiation

On 26 June 2010 22:08, Ryan Wagoner  wrote:
> I have Polycom phones that support the g722 codec. Adding allow=g722
> to the [general] section of sip.conf works great and I can make calls
> between the phones using g722. However Asterisk is negotiating g722
> for calls going out my voip provider and transcoding these to ulaw. In
> sip.conf for the provider I have deny=all and allow=ulaw. This can
> cause potential audio degrading and wastes cpu cycles. If Asterisk
> knows the trunk only supports ulaw why would it offer g722 to the
> phone.
>
> Ryan

Because the codec is already chosen before the call is made, and you
told it that g722 is permitted.

There are all sorts of discussions in play about codec negotiation,
but at this point in time, if you want different behaviour you'll need
to go and code it yourself, and cross-channeltype this is not going to
be trivial :)

Cheers,
Steve

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec negotiation

[Steve Davies]

On 26 June 2010 22:08, Ryan Wagoner  wrote:
> I have Polycom phones that support the g722 codec. Adding allow=g722
> to the [general] section of sip.conf works great and I can make calls
> between the phones using g722. However Asterisk is negotiating g722
> for calls going out my voip provider and transcoding these to ulaw. In
> sip.conf for the provider I have deny=all and allow=ulaw. This can
> cause potential audio degrading and wastes cpu cycles. If Asterisk
> knows the trunk only supports ulaw why would it offer g722 to the
> phone.
>
> Ryan

Because the codec is already chosen before the call is made, and you
told it that g722 is permitted.

There are all sorts of discussions in play about codec negotiation,
but at this point in time, if you want different behaviour you'll need
to go and code it yourself, and cross-channeltype this is not going to
be trivial :)

Cheers,
Steve

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec negotiation

[Ryan Wagoner]

I have Polycom phones that support the g722 codec. Adding allow=g722
to the [general] section of sip.conf works great and I can make calls
between the phones using g722. However Asterisk is negotiating g722
for calls going out my voip provider and transcoding these to ulaw. In
sip.conf for the provider I have deny=all and allow=ulaw. This can
cause potential audio degrading and wastes cpu cycles. If Asterisk
knows the trunk only supports ulaw why would it offer g722 to the
phone.

Ryan

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec G.129 A vs A/B

[Steve Underwood]

On 06/04/2010 02:27 AM, Kyle Kienapfel wrote:
> http://en.wikipedia.org/wiki/G.729
> Looks like theres A and B and no "A/B" so theres nothing to worry about
>
What's the point of quoting a page, if you are not actually going to 
read it?
> On Thu, Jun 3, 2010 at 9:09 AM, Alejandro Cabrera Obed
>   wrote:
>
>> Dear all, I've read that Asterisk supports only the G.729 A audio
>> codec. I have several Grandstream IP phones with G.729 A/B codec
>> implementation.
>>
>> Does G.729 A/B mean both version A and version B, or A/B is a new
>> version different from A and B and it's not supported by Asterisk ???
>>  
G.729 is the base codec, which hardly anyone uses

G.729 Annex A is a stripped down version which doesn't sound as good, 
but takes only half the compute power. This is the one almost everyone 
uses - who cares about voice quality, anyway? The bit stream is 
identical to G.729, so they are fully interworkable. For thos reason SDP 
does not distinguish between G.729 and G.729A.

G.729 Annex B is a CNG/VAD add on for either of the above codecs. This 
feature may be turned on and off in the SDP, using the annexb parameter. 
A codec which cannot support Annex B is, therefore, always able to 
interwork with a codec that does support it.

G.729AB or G.729A/B are the usual ways people described a codec which 
uses the Annex A version of the encoding and decoding, and which 
supports CNG/VAD.

Steve


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec G.129 A vs A/B

[Kyle Kienapfel]

http://en.wikipedia.org/wiki/G.729
Looks like theres A and B and no "A/B" so theres nothing to worry about

On Thu, Jun 3, 2010 at 9:09 AM, Alejandro Cabrera Obed
 wrote:
> Dear all, I've read that Asterisk supports only the G.729 A audio
> codec. I have several Grandstream IP phones with G.729 A/B codec
> implementation.
>
> Does G.729 A/B mean both version A and version B, or A/B is a new
> version different from A and B and it's not supported by Asterisk ???
>
> Thanks a lot
>
> Alejandro
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec G.129 A vs A/B

[Alejandro Cabrera Obed]

Dear all, I've read that Asterisk supports only the G.729 A audio
codec. I have several Grandstream IP phones with G.729 A/B codec
implementation.

Does G.729 A/B mean both version A and version B, or A/B is a new
version different from A and B and it's not supported by Asterisk ???

Thanks a lot

Alejandro

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec preference

[jonas kellens]

I would also add the following :

sip.conf has :

[general]
disallow=all
allow=g729
allow=alaw
allow=gsm

And again the same in the sip peer definition :

disallow=all
allow=g729
allow=alaw
allow=gsm


sip debug shows :

[Mar 12 15:28:23] Found audio description format G729 for ID 18
[Mar 12 15:28:23] Found audio description format PCMA for ID 8
[Mar 12 15:28:23] Found audio description format GSM for ID 3
[Mar 12 15:28:23] Found audio description format telephone-event for ID
101
[Mar 12 15:28:23] Capabilities: us - 0xa (gsm|alaw), peer - audio=0x10e
(gsm|alaw|g729)/video=0x0 (nothing), combined - 0xa (gsm|alaw)

On an outgoing call from my Grandstream (with codecs G729, PCMA, GSM) to
Asterisk.

What happened here with the G729 codec ??

Using Asterisk 1.4.25.1



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec preference

[jonas kellens]

If I have this is sip.conf :

[general]
disallow=all
allow=g729
allow=alaw

The prefered codecs set in my Grandstream phone is G729, alaw.

In the sip peer definition I have commented out 'disallow=' and
'allow='.

The prefered codecs set in the Zoiper softphone is alaw, gsm.

In the sip peer definition I have commented out 'disallow=' and
'allow='.

When making a call from the Grandstream to the Zoiper softphone, with
Asterisk staying in the media path (canreinvite=no), you would expect
all 3 of them to use alaw.
But this is what happens :

The Grandstream :
v=0
o=test3 8000 8001 IN IP4 192.168.1.101 (<-- Grandstream IP-address)
s=SIP Call
c=IN IP4 192.168.1.101
t=0 0
m=audio 10082 RTP/AVP 18 8 101
a=sendrecv
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11

[Mar 12 11:44:14] Found RTP audio format 18
[Mar 12 11:44:14] Found RTP audio format 8
[Mar 12 11:44:14] Found RTP audio format 101
[Mar 12 11:44:14] Peer audio RTP is at port 192.168.1.101:10082
[Mar 12 11:44:14] Found audio description format G729 for ID 18
[Mar 12 11:44:14] Found audio description format PCMA for ID 8
[Mar 12 11:44:14] Found audio description format telephone-event for ID
101
[Mar 12 11:44:14] Capabilities: us - 0x108 (alaw|g729), peer -
audio=0x108 (alaw|g729)/video=0x0 (nothing), combined - 0x108 (alaw|
g729)
[Mar 12 11:44:14] Non-codec capabilities (dtmf): us - 0x1
(telephone-event), peer - 0x1 (telephone-event), combined - 0x1
(telephone-event)
[Mar 12 11:44:14] Peer audio RTP is at port 192.168.1.101:10082

[Mar 12 11:44:14] -- Called test1 (<-- the Zoiper softphone)
[Mar 12 11:44:14] -- Got SIP response 415 "Unsupported Media Type"
back from 192.168.1.106 (IP-address of Zoiper softphone)


So what happens here with the codec negotiation between Asterisk and the
Zoiper softphone ??

Making the call the other way around (Zoiper calls Grandstream) the call
succeeds and the codec is alaw... like it should be.
I do get the warnings :
[Mar 12 11:53:30] WARNING[23703]: channel.c:3340
ast_channel_make_compatible: No path to translate from
SIP/test3-0a168b48(256) to SIP/test1-0a166d00(8)
[Mar 12 11:53:31] -- SIP/test3-0a168b48 is ringing
[Mar 12 11:53:34] WARNING[23670]: channel.c:2961 set_format: Unable to
find a codec translation path from 0x8 (alaw) to 0x100 (g729)
[Mar 12 11:53:34] WARNING[23670]: channel.c:2961 set_format: Unable to
find a codec translation path from 0x8 (alaw) to 0x100 (g729)
[Mar 12 11:53:34] -- SIP/test3-0a168b48 answered SIP/test1-0a166d00
[Mar 12 11:53:34] -- Packet2Packet bridging SIP/test1-0a166d00 and
SIP/test3-0a168b48

(I know there are G729-licences to translate from G729 to alaw, but if
both support alaw, then alaw should be the negotiated codec, no ?!)

Can this be explained ?


Thanks.
Jonas.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec preference

[jonas kellens]

Sip.conf :

[general]
;context=default
allowguest=no
allowoverlap=no
allowtransfer=yes
realm=mydomain
bindport=5060
bindaddr=X.X.X.X
maxexpiry=1800 
minexpiry=60 
mohinterpret=default
mohsuggest=default
language=be
useragent=mycorp
dtmfmode = rfc2833 
alwaysauthreject = yes 
;contactdeny=0.0.0.0/0.0.0.0
;contactpermit=172.16.0.0/255.255.0.0
rtptimeout=60
rtpholdtimeout=300
;sipdebug = yes
;recordhistory=yes
;dumphistory=yes 
registertimeout=60
registerattempts=60 
rtcachefriends=yes 
;rtsavesysname=yes  
;rtupdate=yes 
;rtautoclear=yes 
;ignoreregexpire=yes
jbenable = yes
jbforce = no
allowsubscribe=yes
limitonpeer = yes
notifyringing=yes
notifyhold=yes

then come the registrations...


Jonas.


On Fri, 2010-03-12 at 11:47 +0530, Prince Singh wrote:

> Post your Asterisk's sip.conf
> 
> 
> On Thu, Mar 11, 2010 at 10:39 PM, jonas kellens
>  wrote:
> 
> How can I set the prefered codec between 2 calling parties ??
> 
> My Grandstream supports G729, alaw and gsm... in this order.
> The Zoiper softphone has alaw and gsm as codecs... in that
> order.
> 
> Although there should be a matching codec found, my
> Grandstream can not call the Zoiper softphone.
> 
> CLI shows :
> 
> [Mar 11 17:47:21] WARNING[22367]: channel.c:3340
> ast_channel_make_compatible: No path to translate from
> SIP/mygrandstream-09c599e0(2) to SIP/zoiper-09cd57f8(256)
> [Mar 11 17:47:21] -- Got SIP response 415 "Unsupported
> Media Type" back from 192.168.1.106 (<-- zoiper)
> 
> SIP debug :
> 
> [Mar 11 17:55:57] Peer audio RTP is at port
> 192.168.1.101:10110 (<-- the Grandstream)
> [Mar 11 17:55:57] Found audio description format PCMA for ID 8
> [Mar 11 17:55:57] Found audio description format GSM for ID 3
> [Mar 11 17:55:57] Found audio description format PCMU for ID 0
> [Mar 11 17:55:57] Found audio description format G729 for ID
> 18
> [Mar 11 17:55:57] Found audio description format
> telephone-event for ID 101
> [Mar 11 17:55:57] Capabilities: us - 0x10a (gsm|alaw|g729),
> peer - audio=0x10e (gsm|ulaw|alaw|g729)/video=0x0 (nothing),
> combined - 0x10a (gsm|alaw|g729)
> [Mar 11 17:55:57] Non-codec capabilities (dtmf): us - 0x1
> (telephone-event), peer - 0x1 (telephone-event), combined -
> 0x1 (telephone-event)
> ...
> [Mar 11 17:55:57] Audio is at 192.168.1.150 port 11586 (<-- my
> Asterisk)
> [Mar 11 17:55:57] Adding codec 0x100 (g729) to SDP
> [Mar 11 17:55:57] Adding non-codec 0x1 (telephone-event) to
> SDP
> 
> This is what Asterisk sends to the Zoiper in the INVITE
> (sdp) :
> 
> Content-Type: application/sdp
> Content-Length: 263
> v=0
> o=root 3208 3208 IN IP4 192.168.1.150
> s=session
> c=IN IP4 192.168.1.150
> t=0 0
> m=audio 11586 RTP/AVP 18 101
> a=rtpmap:18 G729/8000
> 
> Why isn't Asterisk negotiating with the Zoiper for the
> alaw-codec ??
> 
> The sip-configuration (realtime MySQL) for the Grandstream
> is :
> 
> allow : g729;alaw;gsm
> 
> and the Zoiper softphone :
> 
> allow : alaw;gsm;g729
> 
> 
> Kind regards,
> 
> Jonas.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec preference

[Prince Singh]

Post your Asterisk's sip.conf

On Thu, Mar 11, 2010 at 10:39 PM, jonas kellens wrote:

>  How can I set the prefered codec between 2 calling parties ??
>
> My Grandstream supports *G729, alaw and gsm*... in this order.
> The Zoiper softphone has *alaw and gsm* as codecs... in that order.
>
> Although there should be a matching codec found, my Grandstream can not
> call the Zoiper softphone.
>
> CLI shows :
>
> [Mar 11 17:47:21] WARNING[22367]: channel.c:3340
> ast_channel_make_compatible: No path to translate from
> SIP/mygrandstream-09c599e0(2) to SIP/zoiper-09cd57f8(256)
> [Mar 11 17:47:21] -- Got SIP response 415 "Unsupported Media Type" back
> from 192.168.1.106 (<-- zoiper)
>
> SIP debug :
>
> [Mar 11 17:55:57] Peer audio RTP is at port 192.168.1.101:10110 (<-- the
> Grandstream)
> [Mar 11 17:55:57] Found audio description format PCMA for ID 8
> [Mar 11 17:55:57] Found audio description format GSM for ID 3
> [Mar 11 17:55:57] Found audio description format PCMU for ID 0
> [Mar 11 17:55:57] Found audio description format G729 for ID 18
> [Mar 11 17:55:57] Found audio description format telephone-event for ID 101
> [Mar 11 17:55:57] Capabilities: us - 0x10a (gsm|alaw|g729), peer -
> audio=0x10e (gsm|ulaw|alaw|g729)/video=0x0 (nothing), combined - 0x10a
> (gsm|alaw|g729)
> [Mar 11 17:55:57] Non-codec capabilities (dtmf): us - 0x1
> (telephone-event), peer - 0x1 (telephone-event), combined - 0x1
> (telephone-event)
> ...
> [Mar 11 17:55:57] Audio is at 192.168.1.150 port 11586 (<-- my Asterisk)
> [Mar 11 17:55:57] Adding codec 0x100 (g729) to SDP
> [Mar 11 17:55:57] Adding non-codec 0x1 (telephone-event) to SDP
>
> This is what Asterisk sends to the Zoiper in the INVITE (sdp) :
>
> Content-Type: application/sdp
> Content-Length: 263
> v=0
> o=root 3208 3208 IN IP4 192.168.1.150
> s=session
> c=IN IP4 192.168.1.150
> t=0 0
> m=audio 11586 RTP/AVP 18 101
> a=rtpmap:18 G729/8000
>
> Why isn't Asterisk negotiating with the Zoiper for the alaw-codec ??
>
> The sip-configuration (realtime MySQL) for the Grandstream is :
>
> allow : *g729;alaw;gsm*
>
> and the Zoiper softphone :
>
> allow : *alaw;gsm;g729*
>
>
> Kind regards,
>
> Jonas.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>



-- 
Regards,
Prince Singh

Drishti-Soft Solutions Pvt Ltd
62-A, First Floor,
Maruti Industrial Area,
Sector - 18, Gurgaon - 122016
Haryana, India.

P: 91 124 4771000
F: 91 124 4039120
W: http://www.drishti-soft.com
B: http://blog.drishti-soft.com

DISCLAIMER

This message may contain confidential, proprietary or legally Privileged
information. In case you are not the original intended Recipient of the
message, you must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message and you are requested to delete it
and inform the sender.
Any views expressed in this message are those of the individual sender
unless otherwise stated. Nothing contained in this message shall be
construed as an offer or acceptance of any offer by Drishti-Soft Solutions
Pvt Ltd ("Drishti") unless sent with that express intent and with due
authority of Drishti.
Drishti has taken enough precautions to prevent the spread of viruses.
However the company accepts no liability for any damage caused by any virus
transmitted by this email.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec preference

[jonas kellens]

How can I set the prefered codec between 2 calling parties ??

My Grandstream supports G729, alaw and gsm... in this order.
The Zoiper softphone has alaw and gsm as codecs... in that order.

Although there should be a matching codec found, my Grandstream can not
call the Zoiper softphone.

CLI shows :

[Mar 11 17:47:21] WARNING[22367]: channel.c:3340
ast_channel_make_compatible: No path to translate from
SIP/mygrandstream-09c599e0(2) to SIP/zoiper-09cd57f8(256)
[Mar 11 17:47:21] -- Got SIP response 415 "Unsupported Media Type"
back from 192.168.1.106 (<-- zoiper)

SIP debug :

[Mar 11 17:55:57] Peer audio RTP is at port 192.168.1.101:10110 (<-- the
Grandstream)
[Mar 11 17:55:57] Found audio description format PCMA for ID 8
[Mar 11 17:55:57] Found audio description format GSM for ID 3
[Mar 11 17:55:57] Found audio description format PCMU for ID 0
[Mar 11 17:55:57] Found audio description format G729 for ID 18
[Mar 11 17:55:57] Found audio description format telephone-event for ID
101
[Mar 11 17:55:57] Capabilities: us - 0x10a (gsm|alaw|g729), peer -
audio=0x10e (gsm|ulaw|alaw|g729)/video=0x0 (nothing), combined - 0x10a
(gsm|alaw|g729)
[Mar 11 17:55:57] Non-codec capabilities (dtmf): us - 0x1
(telephone-event), peer - 0x1 (telephone-event), combined - 0x1
(telephone-event)
...
[Mar 11 17:55:57] Audio is at 192.168.1.150 port 11586 (<-- my Asterisk)
[Mar 11 17:55:57] Adding codec 0x100 (g729) to SDP
[Mar 11 17:55:57] Adding non-codec 0x1 (telephone-event) to SDP

This is what Asterisk sends to the Zoiper in the INVITE (sdp) :

Content-Type: application/sdp
Content-Length: 263
v=0
o=root 3208 3208 IN IP4 192.168.1.150
s=session
c=IN IP4 192.168.1.150
t=0 0
m=audio 11586 RTP/AVP 18 101
a=rtpmap:18 G729/8000

Why isn't Asterisk negotiating with the Zoiper for the alaw-codec ??

The sip-configuration (realtime MySQL) for the Grandstream is :

allow : g729;alaw;gsm

and the Zoiper softphone :

allow : alaw;gsm;g729


Kind regards,

Jonas.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] Codec translation in Asterisk

[Asterisk User]

Nobody to take this one!

Am I missing anything in knowing following issue?

--Hi Group,

--Can anybody explain me in detail how the codec translation happens on
--asterisk side when 2 endpoints have different codecs?

--Thanking you in advance.


SM

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

[asterisk-users] Codec translation in Asterisk

[Asterisk User]

Hi Group,

Can anybody explain me in detail how the codec translation happens on
asterisk side when 2 endpoints have different codecs?

Thanking you in advance.

--SM

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

Re: [asterisk-users] codec conversion

[Jeff LaCoursiere]

On Tue, 2 Feb 2010, Steve Edwards wrote:

> On Tue, 2 Feb 2010, wassim darwich wrote:
>
>> Thanks for?your reply,ill give?you my situation, iam using my asterisk box 
>> as a switch ,so my client is sending me ulaw and my voip provider?only 
>> accept g723 ,So what i have to do is to receive?g711?codec and convert them 
>> to g723 at?asterisk ,i tried this before but i saw the cpu?usage is 
>> overloaded when doing conversion ,Iam using asterisk 1.4.22 ,So what do you 
>> advice me.
>
> Get your client to switch to g723 or your provider to switch to ulaw. If that 
> is not possible, get more CPU resources:
>
> 1) Eliminate any unrelated processes (X, Apache, MySQL, Tetris). Make sure 
> Asterisk is running with elevated priority.
>
> 2) If your other processes (AGIs?) are written in scripting languages (Perl, 
> PHP), re-code them in compiled languages (C).
>
> 3) Use more powerful processors (faster clock, more cores, more processors).
>
> 4) Split the load across multiple hosts. This has the added advantage of not 
> putting all your eggs in one basket -- you can take a host out of service for 
> maintenance or upgrades.
>
> 5) If you are swapping, more RAM may help.
>

Don't forget the fancy Digium codec translator card thingy!

j

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

Re: [asterisk-users] codec conversion

[Steve Edwards]

On Tue, 2 Feb 2010, wassim darwich wrote:

Thanks for?your reply,ill give?you my situation, iam using my asterisk 
box as a switch ,so my client is sending me ulaw and my voip 
provider?only accept g723 ,So what i have to do is to receive?g711?codec 
and convert them to g723 at?asterisk ,i tried this before but i saw the 
cpu?usage is overloaded when doing conversion ,Iam using asterisk 1.4.22 
,So what do you advice me.


Get your client to switch to g723 or your provider to switch to ulaw. If 
that is not possible, get more CPU resources:


1) Eliminate any unrelated processes (X, Apache, MySQL, Tetris). Make sure 
Asterisk is running with elevated priority.


2) If your other processes (AGIs?) are written in scripting languages 
(Perl, PHP), re-code them in compiled languages (C).


3) Use more powerful processors (faster clock, more cores, more 
processors).


4) Split the load across multiple hosts. This has the added advantage of 
not putting all your eggs in one basket -- you can take a host out of 
service for maintenance or upgrades.


5) If you are swapping, more RAM may help.

--
Thanks in advance,
-
Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
Newline  Fax: +1-760-731-3000-- 
_
-- 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

[asterisk-users] codec conversion

[wassim darwich]

Hi:
Thanks for your reply,ill give you my situation, iam using my asterisk box as a 
switch ,so my client is sending me ulaw and my voip provider only accept g723 
,So what i have to do is to receive g711 codec and convert them to g723 
at asterisk ,i tried this before but i saw the cpu usage is overloaded when 
doing conversion ,Iam using asterisk 1.4.22 ,So what do you advice me.


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