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, resea...@businesstz.com 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


 snip

 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: sip:1003@10.10.10.129:48464
 To: SAMsip:1003@10.10.10.105;tag=0c90cc0c
 From: sip:1004@10.10.10.105;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

[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   : Set
  MD5Secret: Not set
  Remote Secret: Not set
  Context  : video-users
  Subscr.Cont. : Not set
  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   : Set
  MD5Secret: Not set
  Remote Secret: Not set
  Context  : video-users
  Subscr.Cont. : Not set
  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: sip:1003@10.10.10.129:48464
To: sip:1004@10.10.10.105
From: SAMsip:1003@10.10.10.105;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 

Re: [asterisk-users] Codec Negotiation problem

[Matthew Jordan]

On Thu, Jun 13, 2013 at 12:04 PM, resea...@businesstz.com 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


snip

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: sip:1003@10.10.10.129:48464
To: SAMsip:1003@10.10.10.105;tag=0c90cc0c
From: sip:1004@10.10.10.105;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

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

[David Vossel]

- Original Message -
 From: Ryan McGuire rdmcguir...@gmail.com
 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]

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 dvos...@digium.com wrote:

 - Original Message -
  From: Ryan McGuire rdmcguir...@gmail.com
  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]

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 rdmcguir...@gmail.com 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 dvos...@digium.com wrote:

 - Original Message -
  From: Ryan McGuire rdmcguir...@gmail.com
  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]

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 rdmcguir...@gmail.com 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 peer:

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

 Grandstream HT503 (fxo gateway):
 --
 disallow=all
 allow=ulawg729
   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 sip:2001@192.168.0.1;tag=4CD2B2A0-B94A2531
 To: sip:919785013620@192.168.0.1;user=phone
 [...]
 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
peer:

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

Grandstream HT503 (fxo gateway):
--
disallow=all
allow=ulawg729
  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 sip:2001@192.168.0.1;tag=4CD2B2A0-B94A2531
To: sip:919785013620@192.168.0.1;user=phone
[...]
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

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

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]

 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

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

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]

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)

[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

[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 sip:u...@192.168.1.150;tag=2383fb163ee6befa
To: sip:2...@192.168.1.150
Contact: sip:u...@192.168.1.102:5062;transport=udp
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: 
sip:u...@192.168.1.102:5062;transport=udp

[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 sip:u...@192.168.1.150;tag=2383fb163ee6befa
To: sip:2...@192.168.1.150
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: sip:2...@192.168.1.150
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 sip:u...@192.168.1.150;tag=2383fb163ee6befa
To: sip:2...@192.168.1.150;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: sip:2...@192.168.1.150
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 sip:u...@192.168.1.150;tag=2383fb163ee6befa
To: sip:2...@192.168.1.150;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: sip:2...@192.168.1.150
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 

Re: [asterisk-users] Codec negotiation

[Steve Davies]

On 26 June 2010 22:08, Ryan Wagoner rswago...@gmail.com 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

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 rswago...@gmail.com 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

[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 mke...@gmail.com 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 rswago...@gmail.com 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

[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

[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

[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

[Ryan Wagoner]

On Tue, Jun 29, 2010 at 6:42 PM, Philipp von Klitzing
klitz...@pool.informatik.rwth-aachen.de 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

[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

[asterisk-users] Codec negotiation for Thomson ST2030 and g729

[Vinz486]

Hi all,

i'm trouble with codec setup on an asterisk machine 1.4.18 and some
Thomson ST2030 as extensions.

In the users.conf file for internal extension i have:

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

Without any codec installed (i mean with original g729 of asterisk)
all go fine, calling from an extension to one other:

Peer User/ANRCall ID  Seq (Tx/Rx)  Format
 Hold Last Message
10.9.9.9 202 11a6323d2ff  00102/0  0x100 (g729)
 No   Tx: ACK
10.9.9.10201 a8749-c0a80  00101/1  0x100 (g729)
 No   Rx: ACK


Installing the open source binary of g279 (codec_g729.so in modules
dir) and restarting asterisk, the same call require transcoding:

Peer User/ANRCall ID  Seq (Tx/Rx)  Format
 Hold Last Message
10.9.9.9 202 1992c2d149e  00102/0  0x8 (alaw)
 No   Tx: ACK
10.9.9.10201 140a6d-c0a8  00101/1  0x100 (g729)
 No   Rx: ACK

The CALLED extension uses alaw instead of g729.

This uses a lot of CPU (up to 10% in my P3 machine).

Where is the trouble? Asterisk bug? Thomson do not recognize g729 GPL
as standard g729? I must set the framebuffer size?

If i set ONLY g729 as allowed codec all go fine: all calls uses the g729 codec.

Why codec negotian in the allow= list is not respected? Depends on
codec binary? It's strange...


Thanks to all...




---
PicoStreamer - the real WEB live streaming software
vinz486.com

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

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

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

Re: [asterisk-users] Codec negotiation for Thomson ST2030 and g729

[Olivier]

If my memory serves me right, we could use Thomson ST2030 and Asterisk 1.4.
Have you tried with another soft or hardphone  ?

2008/7/7 Vinz486 [EMAIL PROTECTED]:

 Hi all,

 i'm trouble with codec setup on an asterisk machine 1.4.18 and some
 Thomson ST2030 as extensions.

 In the users.conf file for internal extension i have:

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

 Without any codec installed (i mean with original g729 of asterisk)
 all go fine, calling from an extension to one other:

 Peer User/ANRCall ID  Seq (Tx/Rx)  Format
  Hold Last Message
 10.9.9.9 202 11a6323d2ff  00102/0  0x100 (g729)
  No   Tx: ACK
 10.9.9.10201 a8749-c0a80  00101/1  0x100 (g729)
  No   Rx: ACK


 Installing the open source binary of g279 (codec_g729.so in modules
 dir) and restarting asterisk, the same call require transcoding:

 Peer User/ANRCall ID  Seq (Tx/Rx)  Format
  Hold Last Message
 10.9.9.9 202 1992c2d149e  00102/0  0x8 (alaw)
  No   Tx: ACK
 10.9.9.10201 140a6d-c0a8  00101/1  0x100 (g729)
  No   Rx: ACK

 The CALLED extension uses alaw instead of g729.

 This uses a lot of CPU (up to 10% in my P3 machine).

 Where is the trouble? Asterisk bug? Thomson do not recognize g729 GPL
 as standard g729? I must set the framebuffer size?

 If i set ONLY g729 as allowed codec all go fine: all calls uses the g729
 codec.

 Why codec negotian in the allow= list is not respected? Depends on
 codec binary? It's strange...


 Thanks to all...




 ---
 PicoStreamer - the real WEB live streaming software
 vinz486.com

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

 AstriCon 2008 - September 22 - 25 Phoenix, Arizona
 Register Now: http://www.astricon.net

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

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

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

Re: [asterisk-users] Codec negotiation for Thomson ST2030 and g729

[Vinz486]

On Mon, Jul 7, 2008 at 12:18 PM, Olivier [EMAIL PROTECTED] wrote:
 If my memory serves me right, we could use Thomson ST2030 and Asterisk 1.4.
 Have you tried with another soft or hardphone  ?

Why not???

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

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

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

Re: [asterisk-users] Codec Negotiation

[O . Kamal]

I do not need g723.1 codec, this is not the problem, here is another
description of the problem:
The client offer 2 codecs (g729 and g723) for all calls, my server accept
only g729, so normally the client  server will negotiate the codec and both
sides agrees on g729, but this does not happened always, sometimes for some
reason, my server reject the call giving a codec error below, which means
that both sides did not nogotiate the codec correctly.

On 7/12/07, Jared Smith [EMAIL PROTECTED] wrote:


On Thu, 2007-07-12 at 14:39 -0400, Al Bochter wrote:
 So who do you pay to use the G723 codec?

It's possible to use the G.723.1 codec with Asterisk by buying a Digium
TC400B transcoder card[1].  Without that card, the best Asterisk can do
is to pass through the packets, but it can't doing any transcoding
to/from G.723.1 without the hardware card.

---
Jared Smith
Community Relations Manager
Digium, Inc.

[1] http://www.digium.com/en/products/hardware/tc400b.php


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

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

[O . Kamal]

I am having a problem with my asterisk gateway, it is accepting only G729,
the client is offering G729 and G723.1, however for some reasons, around 15%
of calls are rejected due to failed codec negotiation giving an codec error
No compatible codecs, not accepting this offer.

Anyone gone through this before?
___
--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 Negotiation

[Al Bochter]

So who do you pay to use the G723 codec?

Best regards,

Al Bochter
http://www.BochterServices.com

---
See what we are selling at auction 
http://www.epier.com/auctions.asp?bochterservices

---
Take a look at our online store
http://www.bochterservices.com/onlinestore/
---



O.Kamal wrote:

I am having a problem with my asterisk gateway, it is accepting only 
G729, the client is offering G729 and G723.1, however for some 
reasons, around 15% of calls are rejected due to failed codec 
negotiation giving an codec error No compatible codecs, not accepting 
this offer.


Anyone gone through this before?



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






Inbound (clean). Database: 000756-0, 07/12/2007 - 7/12/2007 2:21:04 PM




 

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

[ram]

On 7/12/07, O. Kamal [EMAIL PROTECTED] wrote:


I am having a problem with my asterisk gateway, it is accepting only G729,
the client is offering G729 and G723.1, however for some reasons, around
15% of calls are rejected due to failed codec negotiation giving an codec
error No compatible codecs, not accepting this offer.

Anyone gone through this before?



you can allow UA to accept other codecs
by adding allow=ulaw.others in sip.conf

ram
___
--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 Negotiation

[Jared Smith]

On Thu, 2007-07-12 at 14:39 -0400, Al Bochter wrote:
 So who do you pay to use the G723 codec?

It's possible to use the G.723.1 codec with Asterisk by buying a Digium
TC400B transcoder card[1].  Without that card, the best Asterisk can do
is to pass through the packets, but it can't doing any transcoding
to/from G.723.1 without the hardware card.

---
Jared Smith
Community Relations Manager
Digium, Inc.

[1] http://www.digium.com/en/products/hardware/tc400b.php


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

[Kevin P. Fleming]

- Douglas Garstang [EMAIL PROTECTED] wrote:
 I expected Asterisk to send G711 instead, as that's what is set in
 [general] in sip.conf

And as you've already learned, Asterisk will reorder the codecs in the outbound 
INVITE so that the codec used on the incoming channel is listed as first 
preference on the INVITE, so that it can minimize the number of times that 
transcoding is necessary.

-- 
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Nick Hoffman]

On Fri July 21 2006 18:33, Woodoo People .pGa! 
[EMAIL PROTECTED] wrote:
 don't forget the following:
 if canreinvite=yes, asterisk will NOT stay in mediapath, so, it going to
 ask both parties to negotiate codec, and say hello to the stream. (if
 both parties supports g729, and can negotiate it, no licence will be
 used) if canreinvite=no, * will STAY in mediapath, so both parties will
 negotiate with asterisk itself, and will not care about other side. that
 means, if caller has g729, and callee has g711, asterisk WILL transcode.
 if both parties have g729, asterisk will NOT transcode, but 2 licence
 will be used!

Hi there. In your last example, why would any g729 licenses be used? If 
both parties use g729, wouldn't the call just pass through Asterisk 
without any licenses being used?

Cheers,
-- Nick
e: [EMAIL PROTECTED]
p: +61 7 5591 3588
f: +61 7 5591 6588

If you receive this email by mistake, please notify us and do not make any 
use of the email.  We do not waive any privilege, confidentiality or 
copyright associated with it.
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Woodoo People .pGa!]

 I have two polycom phones. One on a slow link, and one on a fast one.
 I'm trying to set the phone on the slow link to use G729 as it's first 
 preference, and the phone on the fast link to use G711 as it's first 
 preference.
 
 sip.conf has:
 [general]
 allow=ulaw
 allow=g729
 
 [slow-link] ; Override codecs for slow link phone.
 allow = g729
 allow = ulaw
 
 When the slow link phone dialls the fast link phone, it sends G729 as it's 
 first preference in the INVITE to Asterisk. Asterisk then sends G729 as the 
 first preference in the INVITE to the fast link phone. Why doesn't Asterisk 
 send G711 instead?
 
 This raises an interesting question. If one phone uses G729, and one G711, 
 then Asterisk is going to have to transcode, and I am going to use up a G729 
 license. It would seem more beneficial for it to work the way it is now. That 
 is, both legs are using G729. Why is this better? It doesn't chew up a G729 
 license as there is no transcoding, and heck, if one of your call legs is 
 G729, then the G711 party isn't going to hear anything better anyway.
 
 Thoughts?

don't forget the following:
if canreinvite=yes, asterisk will NOT stay in mediapath, so, it going to ask 
both parties to negotiate codec, and say hello to the stream.
(if both parties supports g729, and can negotiate it, no licence will be used)
if canreinvite=no, * will STAY in mediapath, so both parties will negotiate 
with asterisk itself, and will not care about other side.
that means, if caller has g729, and callee has g711, asterisk WILL transcode. 
if both parties have g729, asterisk will NOT transcode, but
2 licence will be used!

as i experienced, the codec order in sip.conf [general]  will take priority 
over [user]  

-- 
WoodOO-[P]an[G]alaktikan[A]gent-People ][ http://shadow.pganet.com
[EMAIL PROTECTED]@RedHat.users
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Woodoo People .pGa!]

 No, we aren't intending to check for available g729 codecs  
 that's why we wanted to have ulaw as a backup when no g729 codecs  
 where available.
 
 That won't work.  If it's trying to use G729, it will still try even  
 when the licenses are all in use. So you need to either force it g729  
 and make sure there are always licenses for it available, or use ulaw  
 and make sure there is enough bandwidth.
 
 The other option is to write your own code that checks to verify the  
 licenses are free somehow, and then tampers with the codec  
 preferences?  I think Brett (trixter) has some ideas/work in this  
 direction already.

i heard somewhere, when g729 licences are gone, it will work as g711,
is this info FAKE? 


-- 
WoodOO-[P]an[G]alaktikan[A]gent-People ][ http://shadow.pganet.com
[EMAIL PROTECTED]@RedHat.users
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Marco Mouta]

Just an idea:

Put this Slow-Phone sip account into sip realtime database, and
outside of asterisk manage  to verify G729 licenses availability and
script it to your SIP-realtime.

This way every call to this SIP account will go to SIP realtime
database that is being changed by an external script that just
monitors your G729 licences, and keeps on track which codec is going
to be used: Ulaw or G729.

Don't know if this is a good idea, just a suggestion.

Best regards,
Marco Mouta

On 7/21/06, Woodoo People .pGa! [EMAIL PROTECTED] wrote:

 No, we aren't intending to check for available g729 codecs
 that's why we wanted to have ulaw as a backup when no g729 codecs
 where available.
 
 That won't work.  If it's trying to use G729, it will still try even
 when the licenses are all in use. So you need to either force it g729
 and make sure there are always licenses for it available, or use ulaw
 and make sure there is enough bandwidth.

 The other option is to write your own code that checks to verify the
 licenses are free somehow, and then tampers with the codec
 preferences?  I think Brett (trixter) has some ideas/work in this
 direction already.

i heard somewhere, when g729 licences are gone, it will work as g711,
is this info FAKE?


--
WoodOO-[P]an[G]alaktikan[A]gent-People ][ http://shadow.pganet.com
[EMAIL PROTECTED]@RedHat.users
___
--Bandwidth and Colocation provided by Easynews.com --

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




--
Com os melhores cumprimentos,

Marco Mouta
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Martin Joseph]

On Jul 21, 2006, at 3:01 AM, Woodoo People .pGa! wrote:


No, we aren't intending to check for available g729 codecs
that's why we wanted to have ulaw as a backup when no g729 codecs
where available.


That won't work.  If it's trying to use G729, it will still try even
when the licenses are all in use. So you need to either force it g729
and make sure there are always licenses for it available, or use ulaw
and make sure there is enough bandwidth.

The other option is to write your own code that checks to verify the
licenses are free somehow, and then tampers with the codec
preferences?  I think Brett (trixter) has some ideas/work in this
direction already.


i heard somewhere, when g729 licences are gone, it will work as g711,
is this info FAKE?


I believe that's incorrect.

___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

Can't put it in a realtime database. We have multiple Asterisk boxes in a 
cluster, and it's a well known fact that multiple Asterisk boxes using realime 
cannot query a common MySQL database. Sounds crazy, but true.

Doug.

 -Original Message-
 From: Marco Mouta [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 21, 2006 4:14 AM
 To: Asterisk Users Mailing List - Non-Commercial Discussion
 Subject: Re: [asterisk-users] Codec Negotiation
 
 
 Just an idea:
 
 Put this Slow-Phone sip account into sip realtime database, and
 outside of asterisk manage  to verify G729 licenses availability and
 script it to your SIP-realtime.
 
 This way every call to this SIP account will go to SIP realtime
 database that is being changed by an external script that just
 monitors your G729 licences, and keeps on track which codec is going
 to be used: Ulaw or G729.
 
 Don't know if this is a good idea, just a suggestion.
 
 Best regards,
 Marco Mouta
 
 On 7/21/06, Woodoo People .pGa! [EMAIL PROTECTED] wrote:
   No, we aren't intending to check for available g729 codecs
   that's why we wanted to have ulaw as a backup when no g729 codecs
   where available.
   
   That won't work.  If it's trying to use G729, it will 
 still try even
   when the licenses are all in use. So you need to either 
 force it g729
   and make sure there are always licenses for it available, 
 or use ulaw
   and make sure there is enough bandwidth.
  
   The other option is to write your own code that checks to 
 verify the
   licenses are free somehow, and then tampers with the codec
   preferences?  I think Brett (trixter) has some ideas/work in this
   direction already.
 
  i heard somewhere, when g729 licences are gone, it will 
 work as g711,
  is this info FAKE?
 
 
  --
  WoodOO-[P]an[G]alaktikan[A]gent-People ][ http://shadow.pganet.com
  
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
  ___
  --Bandwidth and Colocation provided by Easynews.com --
 
  asterisk-users mailing list
  To UNSUBSCRIBE or update options visit:
 http://lists.digium.com/mailman/listinfo/asterisk-users
 
 
 
 -- 
 Com os melhores cumprimentos,
 
 Marco Mouta
 ___
 --Bandwidth and Colocation provided by Easynews.com --
 
 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
 
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Brian Capouch]

Douglas Garstang wrote:

Can't put it in a realtime database. We have multiple Asterisk boxes in a 
cluster, and it's a well known fact that multiple Asterisk boxes using realime 
cannot query a common MySQL database. Sounds crazy, but true.



You spread some amazing well-known facts on this list.  As usual 
salted with your typical choice of words that implies that Asterisk has 
crazy flaws that no sane programmer would countenance.


I have a dozen or more Asterisk boxes that all query the exact same 
Realtime database.  The setup works fine, and the time to deploy a new 
station with very elaborate functionality is reduced to minutes.  The 
ability to rearrange behaviors on the fly is also a great feature.  I 
love ARA.


I use Postgres and not MySQL, but I can't believe that the choice is SQL 
engine would make a difference.


I think you confuse the requirements of your deployment scenario, which 
a few minutes ago on this list you yourself characterized as 
ridiculous, with underlying common features of Asterisk used in 
quotidian circumstances.


B.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

 -Original Message-
 From: Brian Capouch [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 21, 2006 11:33 AM
 To: Asterisk Users Mailing List - Non-Commercial Discussion
 Subject: Re: [asterisk-users] Codec Negotiation
 
 
 Douglas Garstang wrote:
  Can't put it in a realtime database. We have multiple 
 Asterisk boxes in a cluster, and it's a well known fact that 
 multiple Asterisk boxes using realime cannot query a common 
 MySQL database. Sounds crazy, but true.
  
 
 You spread some amazing well-known facts on this list.  As usual 
 salted with your typical choice of words that implies that 
 Asterisk has 
 crazy flaws that no sane programmer would countenance.
 
 I have a dozen or more Asterisk boxes that all query the exact same 
 Realtime database.  The setup works fine, and the time to 
 deploy a new 
 station with very elaborate functionality is reduced to minutes.  The 
 ability to rearrange behaviors on the fly is also a great feature.  I 
 love ARA.
 
 I use Postgres and not MySQL, but I can't believe that the 
 choice is SQL 
 engine would make a difference.
 
 I think you confuse the requirements of your deployment 
 scenario, which 
 a few minutes ago on this list you yourself characterized as 
 ridiculous, with underlying common features of Asterisk used in 
 quotidian circumstances.

Would you like me to dig up the posts from Keving Fleming stating that this is 
known not to work Brian?
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Brian Capouch]

Douglas Garstang wrote:




Would you like me to dig up the posts from Keving Fleming stating that this is 
known not to work Brian?


As I recall those posts have to do with the way your particular setup 
required ARA to work with a failover/redundant cluster system you were 
building.


Beyond that I'm not really interested in getting into a pissing contest. 
 I have ONE SQL table called extensions_table on ONE SQL server, but 
have maybe 20 SIP phones using that same database, placing calls from 
10-12 separate Asterisk instances.


I was calling into question your presenting a well-known fact  that 
appears to be incorrect.  If Kevin sees this and wants to chime in to 
support your statement and tell me that my experience is somehow an 
illusion, he's certainly welcome to do so.  I have experienced the taste 
of crow, and eat it when needed.  You?


Can certain situations be construed where ARA will not do exactly what 
the administrator wants?  Apparently, from reading some of your posts, true.


Can multiple Asterisk servers be set up to use a single database 
instance to store common configuration information?  Certainly true, 
from my and many other people's experiences.


The thrust of my post was to refute the fact, and to suggest you 
perhaps adopt a little less inflammatory rhetoric when you post to this 
list.


B.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

 -Original Message-
 From: Brian Capouch [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 21, 2006 12:08 PM
 To: Asterisk Users Mailing List - Non-Commercial Discussion
 Subject: Re: [asterisk-users] Codec Negotiation
 
 
 Douglas Garstang wrote:
 
  
  
  Would you like me to dig up the posts from Keving Fleming 
 stating that this is known not to work Brian?
 
 As I recall those posts have to do with the way your particular setup 
 required ARA to work with a failover/redundant cluster system 
 you were 
 building.
 
 Beyond that I'm not really interested in getting into a 
 pissing contest. 
   I have ONE SQL table called extensions_table on ONE SQL 
 server, but 
 have maybe 20 SIP phones using that same database, placing calls from 
 10-12 separate Asterisk instances.
 
 I was calling into question your presenting a well-known fact  that 
 appears to be incorrect.  If Kevin sees this and wants to chime in to 
 support your statement and tell me that my experience is somehow an 
 illusion, he's certainly welcome to do so.  I have 
 experienced the taste 
 of crow, and eat it when needed.  You?
 
 Can certain situations be construed where ARA will not do 
 exactly what 
 the administrator wants?  Apparently, from reading some of 
 your posts, true.
 
 Can multiple Asterisk servers be set up to use a single database 
 instance to store common configuration information?  Certainly true, 
 from my and many other people's experiences.
 
 The thrust of my post was to refute the fact, and to suggest you 
 perhaps adopt a little less inflammatory rhetoric when you 
 post to this 
 list.

Here's a post Kevin Fleming made to the group on Dec 12, 2005, in response to 
my question on this subject. 
I was quite clear about my question, and does not involve clustering, only N 
number of Asterisk boxes all pointed to the same database. It seems his reply 
is also quite clear.
It's good that it's working for you. I guess you got lucky.

Douglas Garstang wrote:
 Thanks while we're on the topic of realtime. Can realtime sipusers be 
 shared amongst multiple Asterisk boxes, to share a common location database? 
 I'm sitting here on a Sunday jerking around with it, having problems. I'd 
 like to know before I spend more Sundays doing the same thing if it's even 
 supposed to work or not.

Uhhh... you already quoted my previous message on that topic stating 
that it was not supported at this time. In any given situation, it may 
or may not work properly, depending on exactly what the servers and 
clients are doing.

Even if the code had been written, there will still be many issues 
involved in actually implementing it, including (but not limited to) NAT 
traversal, call limit handling, registration expiration and others. It 
also mandates that there can be _no_ caching of peer/user information in 
memory, which currently means there is no 'qualify' or MWI notification 
possible.

Doug
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[olivier.taylor]

I must agree,

we use 2 Ser in front of 4 asterisk sharing the same database cluster.

Olivier

Brian Capouch a écrit :

Douglas Garstang wrote:




Would you like me to dig up the posts from Keving Fleming stating 
that this is known not to work Brian?


As I recall those posts have to do with the way your particular setup 
required ARA to work with a failover/redundant cluster system you were 
building.


Beyond that I'm not really interested in getting into a pissing 
contest.  I have ONE SQL table called extensions_table on ONE SQL 
server, but have maybe 20 SIP phones using that same database, placing 
calls from 10-12 separate Asterisk instances.


I was calling into question your presenting a well-known fact  that 
appears to be incorrect.  If Kevin sees this and wants to chime in to 
support your statement and tell me that my experience is somehow an 
illusion, he's certainly welcome to do so.  I have experienced the 
taste of crow, and eat it when needed.  You?


Can certain situations be construed where ARA will not do exactly what 
the administrator wants?  Apparently, from reading some of your posts, 
true.


Can multiple Asterisk servers be set up to use a single database 
instance to store common configuration information?  Certainly true, 
from my and many other people's experiences.


The thrust of my post was to refute the fact, and to suggest you 
perhaps adopt a little less inflammatory rhetoric when you post to 
this list.


B.


___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

Well, I wish someone would tell Kevin Fleming that.

 -Original Message-
 From: olivier.taylor [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 21, 2006 1:04 PM
 To: Asterisk Users Mailing List - Non-Commercial Discussion
 Subject: Re: [asterisk-users] Codec Negotiation
 
 
 I must agree,
 
 we use 2 Ser in front of 4 asterisk sharing the same database cluster.
 
 Olivier
 
 Brian Capouch a écrit :
  Douglas Garstang wrote:
 
 
 
  Would you like me to dig up the posts from Keving Fleming stating 
  that this is known not to work Brian?
 
  As I recall those posts have to do with the way your 
 particular setup 
  required ARA to work with a failover/redundant cluster 
 system you were 
  building.
 
  Beyond that I'm not really interested in getting into a pissing 
  contest.  I have ONE SQL table called extensions_table on ONE SQL 
  server, but have maybe 20 SIP phones using that same 
 database, placing 
  calls from 10-12 separate Asterisk instances.
 
  I was calling into question your presenting a well-known 
 fact  that 
  appears to be incorrect.  If Kevin sees this and wants to 
 chime in to 
  support your statement and tell me that my experience is somehow an 
  illusion, he's certainly welcome to do so.  I have experienced the 
  taste of crow, and eat it when needed.  You?
 
  Can certain situations be construed where ARA will not do 
 exactly what 
  the administrator wants?  Apparently, from reading some of 
 your posts, 
  true.
 
  Can multiple Asterisk servers be set up to use a single database 
  instance to store common configuration information?  
 Certainly true, 
  from my and many other people's experiences.
 
  The thrust of my post was to refute the fact, and to suggest you 
  perhaps adopt a little less inflammatory rhetoric when you post to 
  this list.
 
  B.
 
 ___
 --Bandwidth and Colocation provided by Easynews.com --
 
 asterisk-users mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
 
___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Joshua Colp]

- Original Message -
From: Douglas Garstang
[mailto:[EMAIL PROTECTED]
To: [EMAIL PROTECTED], Asterisk
Users Mailing List - Non-Commercial Discussion
[mailto:[EMAIL PROTECTED]
Sent: Fri, 21 Jul 2006 16:21:15
-0300
Subject: RE: [asterisk-users] Codec Negotiation


 Well, I wish someone would tell Kevin Fleming that.
 

So... the realtime architecture can work when shared between servers - but not 
all the time, and it depends on certain variables.  Multiple servers can grab 
the same information from the database, but it doesn't mean they will be able 
to contact the phone for example. This is what Kevin was talking about. If a 
phone is behind NAT and registers to one Asterisk machine, the device doing the 
NAT will setup in it's memory a mapping of the external port to the internal 
IP+port. Depending on the implementation and setup, only the server that the 
phone registered to will be able to send packets back. Thus if you have 
failover to another server for example, that server will not be able to contact 
the phone.

Like I said, there's too many variables to make it work all the time...

Now - you can pull information in order for them to be able to place calls. 
That should be fine.

Joshua Colp
Digium
___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

 -Original Message-
 From: Joshua Colp [mailto:[EMAIL PROTECTED]
 Sent: Friday, July 21, 2006 9:38 AM
 To: Asterisk Users Mailing List - Non-Commercial Discussion
 Subject: RE: [asterisk-users] Codec Negotiation
 
 
 - Original Message -
 From: Douglas Garstang
 [mailto:[EMAIL PROTECTED]
 To: [EMAIL PROTECTED], Asterisk
 Users Mailing List - Non-Commercial Discussion
 [mailto:[EMAIL PROTECTED]
 Sent: Fri, 21 Jul 2006 16:21:15
 -0300
 Subject: RE: [asterisk-users] Codec Negotiation
 
 
  Well, I wish someone would tell Kevin Fleming that.
  
 
 So... the realtime architecture can work when shared between 
 servers - but not all the time, and it depends on certain 
 variables.  Multiple servers can grab the same information 
 from the database, but it doesn't mean they will be able to 
 contact the phone for example. This is what Kevin was talking 
 about. If a phone is behind NAT and registers to one Asterisk 
 machine, the device doing the NAT will setup in it's memory a 
 mapping of the external port to the internal IP+port. 
 Depending on the implementation and setup, only the server 
 that the phone registered to will be able to send packets 
 back. Thus if you have failover to another server for 
 example, that server will not be able to contact the phone.
 
 Like I said, there's too many variables to make it work all 
 the time...
 
 Now - you can pull information in order for them to be able 
 to place calls. That should be fine.

Don't know about that. I'm not sure why he brought NAT up, as I didn't mention 
it. Might be a red herring I think.
___
--Bandwidth and Colocation provided by Easynews.com --

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

[asterisk-users] Codec Negotiation

[Douglas Garstang]

I'm a 
little confused about Asterisk codec negotiation. Hopefully someone can 
help.

I have 
two phones, one on a slow link where I'd like to use G729, and one on a fast 
link where I'd like to use ulaw.

My 
sip.conf has:

[general]
allow=ulawallow=g729
...
[slow-phone]
allow=g729
allow=ulaw

Firstly, does setting the codec for the slow-link phone override the 
general settings? Of course it's not actually documented 
anywhere.

When 
the fast link phone calls the slow link phone, it sends ulaw and G729 in that 
order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it 
does not change the codec preference, and sends ulaw followed by G729. I end up 
with a call that's ulaw on both legs, which isn't what I want. 


I 
guess the settings in [slow-phone] aren't overriding the settings in [general]. 
That's bad...
How 
can I work around this?

Doug.

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Martin Joseph]

On Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote: I'm a little confused about Asterisk codec negotiation. Hopefully someone can help.   I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw.   My sip.conf has:   [general] allow=ulawallow=g729 ... [slow-phone] allow=g729 allow=ulaw   Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere.   When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want.    I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad... How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller.I think the calling parties codec preferences are respected.  That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also...I remember reading this described somewhere, but can't find the docs at the moment.HTH,Marty___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

Marty,

Ahhh I wasn't thinking about the fact that it would be keyed of the 
callers settings, rather than the callee's.

However, setting the slow-link phone to g729 isn't a very workable 
solution. We want to have ulaw as a backup, in case all of our g729 licenses are 
in use. Having the call completely fail in this case would be very bad. We 
should be able to have the slow-link phone negotiate to 
ulaw.

Doug.


  -Original Message-From: Martin Joseph 
  [mailto:[EMAIL PROTECTED]Sent: Thursday, July 20, 2006 11:31 
  AMTo: Asterisk Users Mailing List - Non-Commercial 
  DiscussionSubject: Re: [asterisk-users] Codec 
  Negotiation
  
  On Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote:
  
I'm a little confused about Asterisk codec negotiation. Hopefully 
someone can help.

I 
have two phones, one on a slow link where I'd like to use G729, and one on a 
fast link where I'd like to use ulaw.

My 
sip.conf has:

[general]
allow=ulawallow=g729
...
[slow-phone]
allow=g729
allow=ulaw

Firstly, does setting the codec for the slow-link phone override the 
general settings? Of course it's not actually documented 
anywhere.

When the fast link phone calls the slow link phone, it sends ulaw and 
G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow 
link phone, it does not change the codec preference, and sends ulaw followed 
by G729. I end up with a call that's ulaw on both legs, which isn't what I 
want. 

I 
guess the settings in [slow-phone] aren't overriding the settings in 
[general]. That's bad...
How can I work around this?As you 
  already stated in your previous post the slow phone codec pref does override 
  general when it's the caller.
  I think the calling parties codec preferences are respected. That 
  is why I suggested the last time you posted this that you "force" the slow 
  link to g729 (allow that only), as that will cause the calling party (fast) to 
  choose g729 also...
  
  I remember reading this described somewhere, but can't find the docs at 
  the moment.
  
  HTH,
  Marty
  
  
  
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Martin Joseph]

On Jul 20, 2006, at 11:00 AM, Douglas Garstang wrote:Subject: Re: [asterisk-users] Codec NegotiationOn Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote:I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general]allow=ulawallow=g729...[slow-phone]allow=g729allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad...How can I work around this?As you already stated in your previous post the slow phone codec pref does override general when it's the caller.I think the calling parties codec preferences are respected.  That is why I suggested the last time you posted this that you "force" the slow link to g729 (allow that only), as that will cause the calling party (fast) to choose g729 also...I remember reading this described somewhere, but can't find the docs at the moment.HTH,Marty Marty,   Ahhh I wasn't thinking about the fact that it would be keyed of the callers settings, rather than the callee's.   However, setting the slow-link phone to g729 isn't a very workable solution. We want to have ulaw as a backup, in case all of our g729 licenses are in use. Having the call completely fail in this case would be very bad. We should be able to have the slow-link phone negotiate to ulaw.  Are you intending to implement some logic to check for available g729 codecs?  Because asterisk doesn't do this for you...  What about using some form of unrestricted codec like GSM instead for the slow link?Don't know any great solutions for you...Marty___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

Sorry 
for the top posting. My email client is misbehaving.

Can't 
use gsm. The polycom phones only support g711/ulaw and g729.

No, we 
aren't intending to check for available g729 codecs that's why we wanted to 
have ulaw as a backup when no g729 codecs where available.


  -Original Message-From: Martin Joseph 
  [mailto:[EMAIL PROTECTED]Sent: Thursday, July 20, 2006 12:34 
  PMTo: Asterisk Users Mailing List - Non-Commercial 
  DiscussionSubject: Re: [asterisk-users] Codec 
  Negotiation
  
  On Jul 20, 2006, at 11:00 AM, Douglas Garstang wrote:
  

  Subject: Re: [asterisk-users] Codec 
  Negotiation
  
  On Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote:
  
I'm a little confused about Asterisk codec 
negotiation. Hopefully someone can help.

I have two phones, one on a slow link where I'd 
like to use G729, and one on a fast link where I'd like to use 
ulaw.

My sip.conf has:

[general]
allow=ulawallow=g729
...
[slow-phone]
allow=g729
allow=ulaw

Firstly, does setting the codec for the 
slow-link phone override the general settings? Of course it's not 
actually documented anywhere.

When the fast link phone calls the slow link 
phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk 
relays the INVITE to the slow link phone, it does not change the codec 
preference, and sends ulaw followed by G729. I end up with a call that's 
ulaw on both legs, which isn't what I want.

I guess the settings in [slow-phone] aren't 
overriding the settings in [general]. That's 
bad...
How can I work around 
this?As you already stated in your 
  previous post the slow phone codec pref does override general when it's 
  the caller.
  I think the calling parties codec preferences are respected. 
  That is why I suggested the last time you posted this that you "force" the 
  slow link to g729 (allow that only), as that will cause the calling party 
  (fast) to choose g729 also...
  
  I remember reading this described somewhere, but can't find the docs 
  at the moment.
  
  HTH,
  Marty
  
  
  
Marty,

Ahhh I wasn't thinking about the fact that it would be keyed of 
the callers settings, rather than the callee's.

However, setting the slow-link phone to g729 isn't a very workable 
solution. We want to have ulaw as a backup, in case all of our g729 licenses 
are in use. Having the call completely fail in this case would be very bad. 
We should be able to have the slow-link phone negotiate to 
ulaw.

  Are you intending to implement some logic to check for available g729 
  codecs? Because asterisk doesn't do this for you...
  
  What about using some form of unrestricted codec like GSM instead for the 
  slow link?
  
  Don't know any great solutions for you...
  Marty
  
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Martin Joseph]

On Jul 20, 2006, at 11:41 AM, Douglas Garstang wrote: Sorry for the top posting. My email client is misbehaving.   Can't use gsm. The polycom phones only support g711/ulaw and g729.   No, we aren't intending to check for available g729 codecs that's why we wanted to have ulaw as a backup when no g729 codecs where available.  That won't work.  If it's trying to use G729, it will still try even when the licenses are all in use. So you need to either force it g729 and make sure there are always licenses for it available, or use ulaw and make sure there is enough bandwidth.The other option is to write your own code that checks to verify the licenses are free somehow, and then tampers with the codec preferences?  I think Brett (trixter) has some ideas/work in this direction already.Marty   -Original Message-From: Martin Joseph   [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 20, 2006 12:34   PMTo: Asterisk Users Mailing List - Non-Commercial   DiscussionSubject: Re: [asterisk-users] Codec   NegotiationOn Jul 20, 2006, at 11:00 AM, Douglas Garstang wrote:Subject: Re: [asterisk-users] Codec   NegotiationOn Jul 20, 2006, at 10:16 AM, Douglas Garstang wrote:  I'm a little confused about Asterisk codec negotiation. Hopefully someone can help. I have two phones, one on a slow link where I'd like to use G729, and one on a fast link where I'd like to use ulaw. My sip.conf has: [general]allow=ulawallow=g729...[slow-phone]allow=g729allow=ulaw Firstly, does setting the codec for the slow-link phone override the general settings? Of course it's not actually documented anywhere. When the fast link phone calls the slow link phone, it sends ulaw and G729 in that order to Asterisk. When Asterisk relays the INVITE to the slow link phone, it does not change the codec preference, and sends ulaw followed by G729. I end up with a call that's ulaw on both legs, which isn't what I want. I guess the settings in [slow-phone] aren't overriding the settings in [general]. That's bad...How can I work around this?As you already stated in your   previous post the slow phone codec pref does override general when it's   the caller.  I think the calling parties codec preferences are respected.    That is why I suggested the last time you posted this that you "force" the   slow link to g729 (allow that only), as that will cause the calling party   (fast) to choose g729 also...I remember reading this described somewhere, but can't find the docs   at the moment.HTH,  Marty  Marty, Ahhh I wasn't thinking about the fact that it would be keyed of the callers settings, rather than the callee's. However, setting the slow-link phone to g729 isn't a very workable solution. We want to have ulaw as a backup, in case all of our g729 licenses are in use. Having the call completely fail in this case would be very bad. We should be able to have the slow-link phone negotiate to ulaw.   Are you intending to implement some logic to check for available g729   codecs?  Because asterisk doesn't do this for you...  What about using some form of unrestricted codec like GSM instead for the   slow link?Don't know any great solutions for you...  Marty  ___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:   http://lists.digium.com/mailman/listinfo/asterisk-users ___
--Bandwidth and Colocation provided by Easynews.com --

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

[asterisk-users] Codec Negotiation

[Douglas Garstang]

I have two polycom phones. One on a slow link, and one on a fast one.
I'm trying to set the phone on the slow link to use G729 as it's first 
preference, and the phone on the fast link to use G711 as it's first preference.

sip.conf has:
[general]
allow=ulaw
allow=g729

[slow-link] ; Override codecs for slow link phone.
allow = g729
allow = ulaw

When the slow link phone dialls the fast link phone, it sends G729 as it's 
first preference in the INVITE to Asterisk. Asterisk then sends G729 as the 
first preference in the INVITE to the fast link phone. Why doesn't Asterisk 
send G711 instead?

This raises an interesting question. If one phone uses G729, and one G711, then 
Asterisk is going to have to transcode, and I am going to use up a G729 
license. It would seem more beneficial for it to work the way it is now. That 
is, both legs are using G729. Why is this better? It doesn't chew up a G729 
license as there is no transcoding, and heck, if one of your call legs is G729, 
then the G711 party isn't going to hear anything better anyway.

Thoughts?





___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-users] Codec Negotiation

[Martin Joseph]

On Jul 17, 2006, at 9:25 AM, Douglas Garstang wrote:


I have two polycom phones. One on a slow link, and one on a fast one.
I'm trying to set the phone on the slow link to use G729 as it's first 
preference, and the phone on the fast link to use G711 as it's first 
preference.


sip.conf has:
[general]
allow=ulaw
allow=g729

[slow-link] ; Override codecs for slow link phone.
allow = g729
allow = ulaw

When the slow link phone dialls the fast link phone, it sends G729 as 
it's first preference in the INVITE to Asterisk. Asterisk then sends 
G729 as the first preference in the INVITE to the fast link phone. Why 
doesn't Asterisk send G711 instead?

Because you set the calling to prefer g729? What did you expect?


This raises an interesting question. If one phone uses G729, and one 
G711, then Asterisk is going to have to transcode, and I am going to 
use up a G729 license. It would seem more beneficial for it to work 
the way it is now.
Exactly.  In fact I would generally force g729 in that case (ie 
disallow all but g729).
That is, both legs are using G729. Why is this better? It doesn't chew 
up a G729 license as there is no transcoding, and heck, if one of your 
call legs is G729, then the G711 party isn't going to hear anything 
better anyway.

Yes this is clearly a win.

___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-users] Codec Negotiation

[Douglas Garstang]

 -Original Message-
 From: Martin Joseph [mailto:[EMAIL PROTECTED]
 Sent: Monday, July 17, 2006 11:40 AM
 To: Asterisk Users Mailing List - Non-Commercial Discussion
 Subject: Re: [asterisk-users] Codec Negotiation
 
 
 
 On Jul 17, 2006, at 9:25 AM, Douglas Garstang wrote:
 
  I have two polycom phones. One on a slow link, and one on a 
 fast one.
  I'm trying to set the phone on the slow link to use G729 as 
 it's first 
  preference, and the phone on the fast link to use G711 as 
 it's first 
  preference.
 
  sip.conf has:
  [general]
  allow=ulaw
  allow=g729
 
  [slow-link] ; Override codecs for slow link phone.
  allow = g729
  allow = ulaw
 
  When the slow link phone dialls the fast link phone, it 
 sends G729 as 
  it's first preference in the INVITE to Asterisk. Asterisk 
 then sends 
  G729 as the first preference in the INVITE to the fast link 
 phone. Why 
  doesn't Asterisk send G711 instead?
 Because you set the calling to prefer g729? What did you expect?

I expected Asterisk to send G711 instead, as that's what is set in [general] in 
sip.conf
___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Users] Codec negotiation

[Thomas Kenyon]

If I have an incoming call which uses G.711u, which then gets
transferred to a phone which has G.729 selected as its first preference
(with 711 as a third).

Is it normal behaviour for asterisk to transcode the call to G.729
rather than keep it as 711?

Does anyone know if when T.38 support is complete, it can be treated as
if it were a codec, ie. can put allow=g729 allow=t38 in sip/iax.conf ?


___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Users] codec negotiation

[Ronald Wiplinger]

We have four settings for the codec.

How will it be negotiated?
How should it be negotiated in relation to the available bandwidth?
Is there an influence by using canreinvite=yes ?

Phone A has a setting for the priority of codec
Sip.conf has (maybe even different) settings for the priority of codec 
of this phone A

Sip.conf has codec settings for the destination phone B
Phone B has (maybe even different) settings for the priority of codec

Which codec will be taken?
a. if the call goes via * ?
b. if the call will be completed with canreinvite=yes ?

Which codec should be enforce depending on the bandwidth?

Thanks for thinking with me ;-)


bye

Ronald Wiplinger
___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Users] codec negotiation with SPA-3K

[Steve Kennedy]

I'm having trouble with Asterisk-1.2.4 negotiating codecs with a Sipura
3000 which is running the latest v3 firmware.

The SPA-3K seems to use the preferred codec only and doesn't
negotiate? The SPA is set to no in use only preferred codec.

Does anyone know if Sipura will support gsm at some point?

I this a bug with the SPA or codec negotiation stuff?


Thanks

Steve

-- 
NetTek Ltd  UK mob +44-(0)7775 755503
UK +44-(0)20 79932612 / US +1-(310)8577715 / Fax +44-(0)20 7483 2455
Skype/GoogleTalk/AIM/Gizmo stevekennedyuk / MSN [EMAIL PROTECTED]
Euro Tech News Blog http://eurotechnews.blogspot.com
___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Users] Codec negotiation

[Ronald Voermans]

Hi 
All,

I've set up an 
Asterisk box with a SIP trunk to our PSTN provider. I've configured two incoming 
phonenumbers. One phonenumber is for voice-calls, the other one for receiving 
faxes. I want the incoming voice-calls to be coded by the G.729 codec, and the 
fax-number by G.711. Can I make a codec-negotation based on the called 
number?

If you need more 
info on this, i can send it to you.

Thank you all for 
your answer(s)!

Regards,

Ronald 
Voermans
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Users] Codec negotiation

[Florian Overkamp]

Hi,

Ronald Voermans wrote:
I've set up an Asterisk box with a SIP trunk to our PSTN provider. I've 
configured two incoming phonenumbers. One phonenumber is for 
voice-calls, the other one for receiving faxes. I want the incoming 
voice-calls to be coded by the G.729 codec, and the fax-number by G.711. 
Can I make a codec-negotation based on the called number?


Nope, but maybe you could separate the traffic in to different SIP peers.


If you need more info on this, i can send it to you.


If you want we could figure something out. Just curious: Which PSTN 
provider are you using ?



Florian
___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [Asterisk-Users] Codec negotiation

[Ronald Voermans]

Florian,

What exactly do you mean by seperating traffic in to differt SIP peers?

The situation is as follows:

I have OpenSer connected to our SIP provider/PSTN Provider (the answer
to your question: Enertel).

Asterisk registers to OpenSer, which then forwards the call to PSTN.
Asterisk registers two numbers at OpenSer; one phonenumber and one
faxnumber. I also made two entries in sip.conf. However, the host=... Is
the same for both numbers. So incoming calls are always matched to one
(1) peer/entry in sip.conf. Hence the problem with negotiating the right
codec (g.729 for voice, g.711 for fax). 


Met vriendelijke groet,
---
R.L.L.M. Voermans
Access  Hosting
E-mail: [EMAIL PROTECTED]
Tel.: +31 (0)161 - 88.88.88
Fax: +31 (0)161 - 88.88.99
Global-e
Raadhuisstraat 32
5126 CJ GILZE
http://www.global-e.nl
---


-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Florian Overkamp
Verzonden: donderdag 9 februari 2006 18:27
Aan: Asterisk Users Mailing List - Non-Commercial Discussion
Onderwerp: Re: [Asterisk-Users] Codec negotiation

Hi,

Ronald Voermans wrote:
 I've set up an Asterisk box with a SIP trunk to our PSTN provider. 
 I've configured two incoming phonenumbers. One phonenumber is for 
 voice-calls, the other one for receiving faxes. I want the incoming 
 voice-calls to be coded by the G.729 codec, and the fax-number by
G.711.
 Can I make a codec-negotation based on the called number?

Nope, but maybe you could separate the traffic in to different SIP
peers.

 If you need more info on this, i can send it to you.

If you want we could figure something out. Just curious: Which PSTN
provider are you using ?


Florian
___
--Bandwidth and Colocation provided by Easynews.com --

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



___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Users] Codec negotiation

[Florian Overkamp]

Hi Ronald,

Ronald Voermans wrote:

What exactly do you mean by seperating traffic in to differt SIP peers?

The situation is as follows:

I have OpenSer connected to our SIP provider/PSTN Provider (the answer
to your question: Enertel).


Ah 'kay.


Asterisk registers to OpenSer, which then forwards the call to PSTN.
Asterisk registers two numbers at OpenSer; one phonenumber and one
faxnumber. I also made two entries in sip.conf. However, the host=... Is
the same for both numbers. So incoming calls are always matched to one
(1) peer/entry in sip.conf. Hence the problem with negotiating the right
codec (g.729 for voice, g.711 for fax). 


Hrm, yes for inbound the problem is with the host=.. matching. Maybe 
Olle has a good suggestion on this :-P.


However, if you control the OpenSer yourself you could easily bind 
another IP, or perhaps use OpenSer rules to do the trick ?


Asterisk SIP stack doesn't seem suited for this type of traffic 
separation I guess...


Florian
___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [Asterisk-Users] Codec negotiation

[Ronald Voermans]

Yes,

But without going deeper into OpenSer (since this IS a Asterisk list):
With OpenSer I'm using RTPPRoxy. I don't think i can manage rtpproxy to
bind to multiple addresses. I'll look for that anyway.

Thanks, 

Regards,
Ronald.

-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Namens Florian Overkamp
Verzonden: donderdag 9 februari 2006 23:38
Aan: Asterisk Users Mailing List - Non-Commercial Discussion
Onderwerp: Re: [Asterisk-Users] Codec negotiation

Hi Ronald,

Ronald Voermans wrote:
 What exactly do you mean by seperating traffic in to differt SIP
peers?
 
 The situation is as follows:
 
 I have OpenSer connected to our SIP provider/PSTN Provider (the answer

 to your question: Enertel).

Ah 'kay.

 Asterisk registers to OpenSer, which then forwards the call to PSTN.
 Asterisk registers two numbers at OpenSer; one phonenumber and one 
 faxnumber. I also made two entries in sip.conf. However, the host=... 
 Is the same for both numbers. So incoming calls are always matched to 
 one
 (1) peer/entry in sip.conf. Hence the problem with negotiating the 
 right codec (g.729 for voice, g.711 for fax).

Hrm, yes for inbound the problem is with the host=.. matching. Maybe
Olle has a good suggestion on this :-P.

However, if you control the OpenSer yourself you could easily bind
another IP, or perhaps use OpenSer rules to do the trick ?

Asterisk SIP stack doesn't seem suited for this type of traffic
separation I guess...

Florian
___
--Bandwidth and Colocation provided by Easynews.com --

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



___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Users] Codec negotiation (not the same old stuff)

[Dan Austin]

Title: Codec negotiation (not the same old stuff)






I have a H.323 device, let's call it stupid, that supports all variants of G.729. That should be

good, but no. When it negotiates a call between Asterisk and a phone that supports all

varients of G.729, it gets it wrong. Asterisk sends G.729A and the phone sends G.729,

at which point the device transcodes the call, but changes the packetization.


I'm looking for a way to get Asterisk to offer plain old G.729, so the device (stupid) can

just bridge the RTP. My research shows this should not be required, since G.729 and

G.729A are compatible and don't need transcoding.


I'm trying to get an answer from the device manufacturer, but I do not have high hopes.


If it matters, I am using chan_ooh323 with Asterisk 1.2.0.


Thanks,

Dan




___
--Bandwidth and Colocation sponsored by Easynews.com --

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

[Asterisk-Users] codec negotiation with CISCO 7960 and Firefly softphone

[raymond]

Hi all,

When I am making call with with my Cisco 7960 SIP phone, I 
found only codec g711 works. 

The network call is like this:

CISCO AS5300 ---sip Asterisk sip--- 
CISCO7960

Peer 
User/ANR Call ID Seq 
(Tx/Rx) Formatcisco7960  
30511694 152828207b0 00102/0 
ulawciscoAS5300  
34169980 31A6EE0B-AF 00101/00101 
gsm 
Codec in CISCO 
AS5300
 
g711alaw G.711 A Law 64000 bps 
g711ulaw G.711 u Law 64000 bps 
g723ar53 G.723.1 ANNEX-A 5300 bps 
g723ar63 G.723.1 ANNEX-A 6300 bps 
g723r53 G.723.1 5300 bps 
g723r63 G.723.1 6300 bps 
g729br8 G.729 ANNEX-B 8000 
bps g729r8 G.729 8000 
bps gsmefr GSMEFR 
12200 bps gsmfr 
GSMFR 13200 bps
I already did the 
following config in sip.conf
allow=g723allow=g729allow=gsmallow=ulawallow=alaw
However, it seems that 
only codec gsm work fines. However, it still occupy more bandwidth. 
Just would like to know if asterisk can do codec g723 or g729? 
Anyone has 
encountered this problem or am I missing any config in asterisk? 


Thanks.

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

Re: [Asterisk-Users] Codec negotiation

[Rod Bacon]

Further to this, does anyone know if there is a simple way to set the party 
priority in codec negotiation? (NOT the codec priority)

In other words, I want the calling (client) preferences to be considered 
FIRST.

Currently, my logs show
Accepting AUTHENTICATED call from 203.89.xxx.xx:
   requested format = ulaw,
   requested prefs = (),
   actual format = ilbc,
   host prefs = (ilbc|g729|gsm|speex|g726|alaw|ulaw),
   priority = mine
As can be seen, the request was for ulaw, which IS in the list, but the 
request is ignored because priority = mine.

Can priority = caller? Or is this caused by the fact that requested 
prefs is empty?


- Original Message - 
From: Mark Eissler [EMAIL PROTECTED]
Sent: Wednesday, January 26, 2005 8:51 AM
Subject: [Asterisk-Users] Codec negotiation


Can't you just create a different context for inbound and outbound
calls? Then specify your codec preference order in there. I don't think
you can specify the bandwidth= parameter within a context other than
the global one though.
-mark
On Jan 25, 2005, at 6:13 PM, [EMAIL PROTECTED] wrote:
I don't want that... because
- for outbound calls I want priority to be g729 first
- for inbound calls I want no priority at all (e.g. the calling
asterisk
to decide which codec we will use)
The last doesn't happen..
This by the way DID happen correctly with previous versions of asterisk
(1.0.3 for example) the current CVS-HEAD version doesn't
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mohammed
Salim
Sent: dinsdag 25 januari 2005 22:10
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: RE: [Asterisk-Users] Codec negotiation
The order matters in asterisk so if you want GSM to take priority over
G729,
simply put that ahead of the G729... so your settings should be:
Allow=all
Allow=gsm
Allow=g729
Allow=ulaw
Allow=alaw
Try that and see if it works.
Regards,
Mohammed Salim
EZZI Telecom, Inc.

--
Mark Eissler, [EMAIL PROTECTED]
Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com


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

[Asterisk-Users] Codec negotiation problems

[Daniel Corbe]

My PBX seems to have just started showing wierd codec negotiation problems.

I'm not all of a sudden getting this on certain phone numbers on my system:

Feb  8 22:19:19 NOTICE[1125329728]: channel.c:1683
ast_set_read_format: Unable to find a path from ULAW to G729A
Feb  8 22:19:19 NOTICE[1125329728]: channel.c:1650
ast_set_write_format: Unable to find a path from G729A to ULAW
-- SIP/2101-aaf2 answered SIP/19544342000-375a
-- Attempting native bridge of SIP/19544342000-375a and SIP/2101-aaf2
-- Attempting native bridge of SIP/19544342000-375a and SIP/2101-aaf2
Feb  8 22:19:19 NOTICE[1225991488]: channel.c:1683
ast_set_read_format: Unable to find a path from G729A to ULAW
Feb  8 22:19:19 NOTICE[1225991488]: channel.c:1650
ast_set_write_format: Unable to find a path from ULAW to G729A
Feb  8 22:19:19 WARNING[1225991488]: chan_sip.c:1797 sip_write: Asked
to transmit frame type 256, while native formats is 4 (read/write =
4/4)

Regards,
Daniel
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [Asterisk-Users] Codec negotiation

[Mark Eissler]

Can't you just create a different context for inbound and outbound 
calls? Then specify your codec preference order in there. I don't think 
you can specify the bandwidth= parameter within a context other than 
the global one though.

-mark
On Jan 25, 2005, at 6:13 PM, [EMAIL PROTECTED] wrote:
I don't want that... because
- for outbound calls I want priority to be g729 first
- for inbound calls I want no priority at all (e.g. the calling 
asterisk
to decide which codec we will use)

The last doesn't happen..
This by the way DID happen correctly with previous versions of asterisk
(1.0.3 for example) the current CVS-HEAD version doesn't
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mohammed
Salim
Sent: dinsdag 25 januari 2005 22:10
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: RE: [Asterisk-Users] Codec negotiation
The order matters in asterisk so if you want GSM to take priority over
G729,
simply put that ahead of the G729... so your settings should be:
Allow=all
Allow=gsm
Allow=g729
Allow=ulaw
Allow=alaw
Try that and see if it works.
Regards,
Mohammed Salim
EZZI Telecom, Inc.

--
Mark Eissler, [EMAIL PROTECTED]
Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

RE: [Asterisk-Users] Codec negotiation

[Dave Cotton]

On Tue, 2005-01-25 at 16:10 -0500, Mohammed Salim wrote:
 The order matters in asterisk so if you want GSM to take priority over G729,
 simply put that ahead of the G729... so your settings should be:
 
 Allow=all

This would allow everything so the next lines would be redundant.
Disallow=all

then:

 Allow=gsm
 Allow=g729
 Allow=ulaw
 Allow=alaw


-- 
Dave Cotton [EMAIL PROTECTED]

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

[Asterisk-Users] Codec negotiation

[niels]

Hello 

On every Incoming SIP and IAX call I see the following in asterisk
debug:

Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm,
requested prefs = (), actual format = g729, my prefs =
(g729|gsm|g723|g726|ulaw|alaw) priority = mine 

The problem is that the codec preference on both parties is different 

The calling party has preference gsm/g729/etc
The called party (the one you see this debug from) has preference
g729/gsm/etc 

The problem is.. This call is now set up with G729... And I want it
rather to be decided by the callING party (thus want the call to be
negotiated GSM)

What can I do about this? (I just want that if I receive a call the
calling party decides the codec, and not my side) 

My IAX.conf and SIP.conf have the following allow settings now

Allow=all
Allow=g729
Allow=gsm
Allow=ulaw
Allow=alaw


Help :-)


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

Re: [Asterisk-Users] Codec negotiation

[Mark Eissler]

The codec is selected by asterisk depending upon the codecs that you 
have allowed for the particular channel context and your setting of the 
bandwidth= parameter.

It would be nice if you could set things up so that an inbound call 
could force * to a higher bandwidth codec when needed (for example, an 
inbound fax call, let's say) but AFAIK this is not possible.

-mark
On Jan 25, 2005, at 10:18 AM, [EMAIL PROTECTED] wrote:
Hello
On every Incoming SIP and IAX call I see the following in asterisk
debug:
Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm,
requested prefs = (), actual format = g729, my prefs =
(g729|gsm|g723|g726|ulaw|alaw) priority = mine
The problem is that the codec preference on both parties is different
The calling party has preference gsm/g729/etc
The called party (the one you see this debug from) has preference
g729/gsm/etc
The problem is.. This call is now set up with G729... And I want it
rather to be decided by the callING party (thus want the call to be
negotiated GSM)
What can I do about this? (I just want that if I receive a call the
calling party decides the codec, and not my side)
My IAX.conf and SIP.conf have the following allow settings now
Allow=all
Allow=g729
Allow=gsm
Allow=ulaw
Allow=alaw
Help :-)
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users
--
Mark Eissler, [EMAIL PROTECTED]
Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com
___
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

RE: [Asterisk-Users] Codec negotiation

[Mohammed Salim]

The order matters in asterisk so if you want GSM to take priority over G729,
simply put that ahead of the G729... so your settings should be:

Allow=all
Allow=gsm
Allow=g729
Allow=ulaw
Allow=alaw

Try that and see if it works.

Regards,
Mohammed Salim
EZZI Telecom, Inc.
 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Eissler
Sent: Tuesday, January 25, 2005 2:22 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Codec negotiation

The codec is selected by asterisk depending upon the codecs that you 
have allowed for the particular channel context and your setting of the 
bandwidth= parameter.

It would be nice if you could set things up so that an inbound call 
could force * to a higher bandwidth codec when needed (for example, an 
inbound fax call, let's say) but AFAIK this is not possible.

-mark

On Jan 25, 2005, at 10:18 AM, [EMAIL PROTECTED] wrote:


 Hello

 On every Incoming SIP and IAX call I see the following in asterisk
 debug:

 Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm,
 requested prefs = (), actual format = g729, my prefs =
 (g729|gsm|g723|g726|ulaw|alaw) priority = mine

 The problem is that the codec preference on both parties is different

 The calling party has preference gsm/g729/etc
 The called party (the one you see this debug from) has preference
 g729/gsm/etc

 The problem is.. This call is now set up with G729... And I want it
 rather to be decided by the callING party (thus want the call to be
 negotiated GSM)

 What can I do about this? (I just want that if I receive a call the
 calling party decides the codec, and not my side)

 My IAX.conf and SIP.conf have the following allow settings now

 Allow=all
 Allow=g729
 Allow=gsm
 Allow=ulaw
 Allow=alaw


 Help :-)


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

--
Mark Eissler, [EMAIL PROTECTED]
Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com

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

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

RE: [Asterisk-Users] Codec negotiation

[niels]

I don't want that... because 

- for outbound calls I want priority to be g729 first
- for inbound calls I want no priority at all (e.g. the calling asterisk
to decide which codec we will use)

The last doesn't happen..

This by the way DID happen correctly with previous versions of asterisk
(1.0.3 for example) the current CVS-HEAD version doesn't 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mohammed
Salim
Sent: dinsdag 25 januari 2005 22:10
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: RE: [Asterisk-Users] Codec negotiation

The order matters in asterisk so if you want GSM to take priority over
G729,
simply put that ahead of the G729... so your settings should be:

Allow=all
Allow=gsm
Allow=g729
Allow=ulaw
Allow=alaw

Try that and see if it works.

Regards,
Mohammed Salim
EZZI Telecom, Inc.
 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Eissler
Sent: Tuesday, January 25, 2005 2:22 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Codec negotiation

The codec is selected by asterisk depending upon the codecs that you 
have allowed for the particular channel context and your setting of the 
bandwidth= parameter.

It would be nice if you could set things up so that an inbound call 
could force * to a higher bandwidth codec when needed (for example, an 
inbound fax call, let's say) but AFAIK this is not possible.

-mark

On Jan 25, 2005, at 10:18 AM, [EMAIL PROTECTED] wrote:


 Hello

 On every Incoming SIP and IAX call I see the following in asterisk
 debug:

 Accepting AUTHENTICATED call from 10.10.10.10, requested format = gsm,
 requested prefs = (), actual format = g729, my prefs =
 (g729|gsm|g723|g726|ulaw|alaw) priority = mine

 The problem is that the codec preference on both parties is different

 The calling party has preference gsm/g729/etc
 The called party (the one you see this debug from) has preference
 g729/gsm/etc

 The problem is.. This call is now set up with G729... And I want it
 rather to be decided by the callING party (thus want the call to be
 negotiated GSM)

 What can I do about this? (I just want that if I receive a call the
 calling party decides the codec, and not my side)

 My IAX.conf and SIP.conf have the following allow settings now

 Allow=all
 Allow=g729
 Allow=gsm
 Allow=ulaw
 Allow=alaw


 Help :-)


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

--
Mark Eissler, [EMAIL PROTECTED]
Mixtur Interactive, Inc. [EMAIL PROTECTED] http://www.mixtur.com

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

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

[Asterisk-Users] Codec Negotiation Problem

[Carlos Medina]

Hi there, i had installed on all my servers the codec_g729b which is the old voiceage, so a month ago i updated the codec to codec_g729a. After that i started to get this message on my asterisk console:

Dec 16 09:19:26 NOTICE[1288699200]: rtp.c:293 process_rfc3389: Don't know how to handle RFC3389 for receive codec 256Dec 16 09:19:26 NOTICE[1288699200]: rtp.c:264 process_rfc3389: RFC3389 support incomplete. Turn off on client if possible
Im only using g729 on all my servers, i have some IAX conections with only g729 too. I think its a negotiation problem but with the old version i didnt have this error.

If anyone knows how to fix this would be very helpful.

Thanks for your help

Carlos Andres Medina
		Do you Yahoo!? 
Send holiday email and support a worthy cause. Do good.___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re[2]: [Asterisk-Users] Codec negotiation

[Tamas J]

Saturday, November 20, 2004, 7:03:53 PM, Steven wrote:
SC On Sat, 2004-11-20 at 18:48 +0100, Tamas J wrote:
 Hello!
 
 I would like to know wether it is possible to have end-to-end codec
 negotiation in iax2?
 What I mean is...
 
 In case the user dials a number available through PSTN, let's force to
 use alaw (the client is in LAN) to overcome unneeded transcoding:
 iaxphone-1st asterisk - PSTN
 
 In case the same user dials a number available throug a chain of IAX2
 peers (e.g. 2 peers), try to negotiate the codec end-to-end to consume
 less resources for transcoding on asterisk servers (of course, in that
 case we don't want to use g711, but ilbc, speex or gsm).
 iaxphone-1st asterisk-2nd asterisk-PSTN
 Or maybe:
 iaxphone-1st asterisk-2nd asterisk-iaxpohone
 
 Is there a way to do that? If yes, how?

If 1st asterisk - 2nd asterisk is a link that
If 1st asterisk - negotiates the ILBC, gsm,
SC or speex, when the call transfers, it should negotiate the codec. Of
SC course part of the interesting effect here is that unless there is NAT
SC or something similar in the way, IAX is going to try and get out of each
SC section if it can. So you may end up with the end result being iaxphone
- iaxphone and they might be negotiating with each other.
Thanks for the fast response!
Yes, when the call is transfered, it's logical that parties can
negotiate codecs. However is there a way to negotiate end-to-end
without call transfer?

Is it possible to make this?
iaxComm - asterisk - E1 PSTN
  +-- IAX operator
When the softphone dials to local PSTN number, let's choose alaw or
ulaw codec (to avoid speex/ilbc/gsm - alaw/ulaw transcoding) and if
the call goes out through IAX, let's choose low bandwidth codec (there
should be a preferred one, e.g. softphone and iax trunk use speex).
What I would like is to avoid unneeded transcoding and save on CPU
resources.

What I tryed is to put for sofphone:
disallow=all
allow=speex
allow=alaw
allow=ulaw
When the call went to PSTN it used speex. How can I tell to asterisk
to use alaw (or ulaw while iaxComm looks not supporting alaw) in this
case?
I guess when I would exchange the order and put speex to the and, it
will chose ulaw (oops, I tryed and it selected Speex again), but in
this case who will do g711-speex?

What is my goal with this?
I would like to encode to speex at the softphone's side, thus I can
save CPU power on asterisk box. (and if I put 10-20... more
softphones, I won't run out with CPU, because when it comes to local
call, there won't be transcoding either and when it will go out to iax
peer, it will just pass-through).

Any idea, hint?

Thanks in advance,
Tamas

ps: sorry for the possible a newbie or/and dumb question...


___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[Asterisk-Users] Codec negotiation

[Tamas J]

Hello!

I would like to know wether it is possible to have end-to-end codec
negotiation in iax2?
What I mean is...

In case the user dials a number available through PSTN, let's force to
use alaw (the client is in LAN) to overcome unneeded transcoding:
iaxphone-1st asterisk - PSTN

In case the same user dials a number available throug a chain of IAX2
peers (e.g. 2 peers), try to negotiate the codec end-to-end to consume
less resources for transcoding on asterisk servers (of course, in that
case we don't want to use g711, but ilbc, speex or gsm).
iaxphone-1st asterisk-2nd asterisk-PSTN
Or maybe:
iaxphone-1st asterisk-2nd asterisk-iaxpohone

Is there a way to do that? If yes, how?

Thanks in advance,
TamasJ

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [Asterisk-Users] Codec negotiation

[Steven Critchfield]

On Sat, 2004-11-20 at 18:48 +0100, Tamas J wrote:
 Hello!
 
 I would like to know wether it is possible to have end-to-end codec
 negotiation in iax2?
 What I mean is...
 
 In case the user dials a number available through PSTN, let's force to
 use alaw (the client is in LAN) to overcome unneeded transcoding:
 iaxphone-1st asterisk - PSTN
 
 In case the same user dials a number available throug a chain of IAX2
 peers (e.g. 2 peers), try to negotiate the codec end-to-end to consume
 less resources for transcoding on asterisk servers (of course, in that
 case we don't want to use g711, but ilbc, speex or gsm).
 iaxphone-1st asterisk-2nd asterisk-PSTN
 Or maybe:
 iaxphone-1st asterisk-2nd asterisk-iaxpohone
 
 Is there a way to do that? If yes, how?

If 1st asterisk - 2nd asterisk is a link that negotiates the ILBC, gsm,
or speex, when the call transfers, it should negotiate the codec. Of
course part of the interesting effect here is that unless there is NAT
or something similar in the way, IAX is going to try and get out of each
section if it can. So you may end up with the end result being iaxphone
- iaxphone and they might be negotiating with each other.
-- 
Steven Critchfield [EMAIL PROTECTED]

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[Asterisk-Users] Codec negotiation

[[EMAIL PROTECTED]]

It seems that older version of asterisk does the codec negotiation fine. 
I have one machine running CVS-12/19/03 and this can negotiate codec 
g729 and gsm fine.

The newer version cvs-1/27/04 does not negotiate codec correctly. The 
ougoing connection can only go either g729 or gsm.

--
David Kwok
FWD#/IAXTEL# : 17001813482 ext 1002


smime.p7s
Description: S/MIME Cryptographic Signature

[Asterisk-Users] codec negotiation prob solved?

[Philipp von Klitzing]

FYI - bug 1043 has been fixed on Feb 18:

From my log, below, you will see that ast_rtp_bridge is not comparing 
the codecs properly. Asterisk is currently comparing the integers, and 
not the bits of the codec. 

In the below example codec0 = 260. That means Codec0 allows both 256 
(g729) and 4 (uLaw). So that would mean that Codec0 and Codec1 do have a 
Codec Match. 

Asterisk needs to do a bit compare, and not a int compare in this case.

-- SIP/dialnet-8bac answered SIP/chris0-df00 
-- Attempting native bridge of SIP/chris0-df00 and SIP/dialnet-8bac 
Feb 16 11:27:48 WARNING[68889520]: rtp.c:1204 ast_rtp_bridge: codec0 = 
260 is not codec1 = 256, cannot native bridge. 
Feb 16 11:27:50 NOTICE[68889520]: rtp.c:264 process_rfc3389: RFC3389 
support incomplete. Turn off on client if possible 
Feb 16 11:27:50 NOTICE[68889520]: rtp.c:293 process_rfc3389: Don't know 
how to handle RFC3389 for receive codec 256 


___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [Asterisk-Users] codec negotiation

[Michael Graves]

Why do you need 729? I just called your IAXTel number using GSM and
connected fine.

Michael

On Wed, 18 Feb 2004 08:29:48 +0100, dkwok wrote:

I have outgoing connection to iaxtel and another iax server A.

iax server A only accept g729 codec while iaxtel is something I am not 
quite sure of. At the moment iaxtel only accepts gsm. I remember 
previously it does accept g729.

my problem due to the switching between codec when making outgoing calls 
to these servers.

my iax.conf has these lines:

[general]

disallow=all
allow=gsm
allow=g729

I believe the general context define the codec to be used when making 
outgoing calls. The peer context below general context is to governed 
codec to be used for incoming calls. Is this correct?

now if I specificly disallow g729 in the general context I can make 
calls to iaxtel. however i cannot make calls to server A as it only 
accepts g729. After I allow g729, I can make call to server A but the 
call made to iaxtel cannot go through.

The console indicates that the call is accepted by iaxtel using codec 
729A, then it says the circuit is too busy.

Is there a clever way of governing the codec use for each outgoing 
connection in order to avoid the issue in codec negotiation?

-- 
David Kwok

Iaxtel/FWD # 17001813482 ext 1002

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


--
Michael Graves   [EMAIL PROTECTED]
Sr. Product Specialist  www.pixelpower.com
Pixel Power Inc. [EMAIL PROTECTED]

I believe there comes a time when everything just falls in line. 
- Pat Benatar, from All Fired Up.
 
** Tag(s) inserted by Bandit Tagger98 - http://www.gbar.dtu.dk/~c918704


___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[Asterisk-Users] codec negotiation

[dkwok]

I have outgoing connection to iaxtel and another iax server A.

iax server A only accept g729 codec while iaxtel is something I am not 
quite sure of. At the moment iaxtel only accepts gsm. I remember 
previously it does accept g729.

my problem due to the switching between codec when making outgoing calls 
to these servers.

my iax.conf has these lines:

[general]

disallow=all
allow=gsm
allow=g729
I believe the general context define the codec to be used when making 
outgoing calls. The peer context below general context is to governed 
codec to be used for incoming calls. Is this correct?

now if I specificly disallow g729 in the general context I can make 
calls to iaxtel. however i cannot make calls to server A as it only 
accepts g729. After I allow g729, I can make call to server A but the 
call made to iaxtel cannot go through.

The console indicates that the call is accepted by iaxtel using codec 
729A, then it says the circuit is too busy.

Is there a clever way of governing the codec use for each outgoing 
connection in order to avoid the issue in codec negotiation?

--
David Kwok
Iaxtel/FWD # 17001813482 ext 1002

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

[Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!

[SamW]

Hello,

I have been trying to get my coders to work without a conversion. I have 
read all the available asterisk documentation and support groups without 
any luck. Here is my issue. (Please feel free to ask questions if you do 
not understand what I am talking about.)

I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if 
sip-server request g711)

I have 2 SIP-services to which I have to deliver the call in 2 coder 
formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and 
g711, SIP-B only accept g711.

I do not have any g729 licence, but I believe the * should negotiate to 
have the correct passthrough coders as ATA is capable of both coders. (I 
think even if you have the licenses, * should try avoid codec-conversions 
when ever it can)

Here is my settings in sip.conf. I will only list the required codec 
related lines, for easy understanding,

[general]
disallow=all
allow=g729
allow=ulaw
allow=alaw
register = [EMAIL PROTECTED]
register = [EMAIL PROTECTED]
[sip-a]

disallow=all
allow=ulaw
[sip-b]
...
disallow=all
allow=g729
[ATA]
.
canreinvite=no
Here is what happens when I look at the SIP packets from linux. (ethereal)

Case 1 : ATA Dialing out through sip-a

ATA indicate that it can have following, codecs in SDP packet, in following 
order
ATA -- asterisk  INVITE message
	g729
	ulaw
	alaw
asterisk  -- sip-a INVITE message (Note that already the order of coders 
are changed. Is this how it should be I do not know. And how * decide what 
order of coders to send to sip-a)
	alaw
	ulaw
	g729
sip-a -- asterisk Session Progress Message
	ulaw
asterisk -- ATA Session in Progress Message
	ulaw
	alaw
	g729
asterisk -- ATA send a BYE message and hang up.

at this point asterisk indicate it cannot native bridge message. I do not 
know why asterisk behaves like this, and I do think if asterisk send the 
message back to ATA with g729 in its message it should have worked fith 
nating bridging.

WARNING[1248642112]: File channel.c, Line 1853 
(ast_channel_make_compatible): No path to translate from 
SIP/sip-a-1e15(256) to SIP/4097-96d8(4)

	

Case 2 : ATA calling sip-b
===
	
ATA indicate that it can have following, codecs in SDP packet, in following 
order
ATA -- asterisk  INVITE message
	g729
	ulaw
	alaw
asterisk  -- sip-b INVITE message (Note that unlike case 1, the decision 
by * in this case is OK. * only send one available coder info to the sip-b, 
which is correct as per my config)
	ulaw

sip-b -- asterisk Session Progress Message
	ulaw
asterisk -- ATA Session in Progress Message (Here again * sending multiple 
choices to the ATA, I expect this to be only one request as * already know 
from sip-b, that sip-b can only do ulaw. * know from 2 ways here one from 
Session Progress message above and other from sip-b context that sip-b can 
only do ulaw.) I am confused 
	ulaw
	alaw
	g729

Asterisk send a BYE message to sip-b and send a 403 Forbidden Message to 
ATA and hang-up the call here.

asterisk -- sip-a send a BYE message and hang up.
asterisk - ATA 403 Forbidden
NOTICE[1248642112]: File channel.c, Line 1478 (ast_set_read_format): Unable 
to find a path from G729A to ULAW
NOTICE[1248642112]: File channel.c, Line 1448 (ast_set_write_format): 
Unable to find a path from ULAW to G729A

=

Summery ;
Why this is happening this way, (Do I not understand how to configure or is 
this a bug?)
As the coder negotiation is not well documented anywhere can you please 
help me figure out how to configure the coder negotion.

IMHO, I belive that for each context, we need to have a way to force which 
coder to choose.   True that * can code convert with license, but when you 
code/decode it will always be lossy and will loose quality of sound.  If 
one side is fixed for a particular codec, and the other side is flexible 
for a negotiation, I should see that flexible side should get adjusted to 
the correct codec. It do not seem to happen.

Thank you in advance and appreciate your help.

- Sam 

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!

[Steven Critchfield]

I think your problem comes from a misunderstanding of how the calls are
placed. With your canreinvite=no in the ATA section, you end up with the
ATA negotiating with asterisk for a call leg. Then you have asterisk
negotiating for the other call leg. Since the RTP stream is going
through asterisk, it behaves with how asterisk is capable. If there had
been a reinvite, then the ATA and the remote end would then be able to
negotiate a different codec.



On Mon, 2004-01-05 at 01:29, SamW wrote:
 Hello,
 
 I have been trying to get my coders to work without a conversion. I have 
 read all the available asterisk documentation and support groups without 
 any luck. Here is my issue. (Please feel free to ask questions if you do 
 not understand what I am talking about.)
 
 I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if 
 sip-server request g711)
 
 I have 2 SIP-services to which I have to deliver the call in 2 coder 
 formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and 
 g711, SIP-B only accept g711.
 
 I do not have any g729 licence, but I believe the * should negotiate to 
 have the correct passthrough coders as ATA is capable of both coders. (I 
 think even if you have the licenses, * should try avoid codec-conversions 
 when ever it can)
 
 
 Here is my settings in sip.conf. I will only list the required codec 
 related lines, for easy understanding,
 
 [general]
 disallow=all
 allow=g729
 allow=ulaw
 allow=alaw
 
 register = [EMAIL PROTECTED]
 register = [EMAIL PROTECTED]
 
 [sip-a]
 
 disallow=all
 allow=ulaw
 
 
 [sip-b]
 ...
 disallow=all
 allow=g729
 
 [ATA]
 .
 canreinvite=no
 
 Here is what happens when I look at the SIP packets from linux. (ethereal)
 
 
 Case 1 : ATA Dialing out through sip-a
 
 
 
 ATA indicate that it can have following, codecs in SDP packet, in following 
 order
 ATA -- asterisk  INVITE message
   g729
   ulaw
   alaw
 asterisk  -- sip-a INVITE message (Note that already the order of coders 
 are changed. Is this how it should be I do not know. And how * decide what 
 order of coders to send to sip-a)
   alaw
   ulaw
   g729
 sip-a -- asterisk Session Progress Message
   ulaw
 asterisk -- ATA Session in Progress Message
   ulaw
   alaw
   g729
 asterisk -- ATA send a BYE message and hang up.
 
 at this point asterisk indicate it cannot native bridge message. I do not 
 know why asterisk behaves like this, and I do think if asterisk send the 
 message back to ATA with g729 in its message it should have worked fith 
 nating bridging.
 
 WARNING[1248642112]: File channel.c, Line 1853 
 (ast_channel_make_compatible): No path to translate from 
 SIP/sip-a-1e15(256) to SIP/4097-96d8(4)
 
   
 
 Case 2 : ATA calling sip-b
 ===
   
 ATA indicate that it can have following, codecs in SDP packet, in following 
 order
 ATA -- asterisk  INVITE message
   g729
   ulaw
   alaw
 asterisk  -- sip-b INVITE message (Note that unlike case 1, the decision 
 by * in this case is OK. * only send one available coder info to the sip-b, 
 which is correct as per my config)
   ulaw
 
 sip-b -- asterisk Session Progress Message
   ulaw
 asterisk -- ATA Session in Progress Message (Here again * sending multiple 
 choices to the ATA, I expect this to be only one request as * already know 
 from sip-b, that sip-b can only do ulaw. * know from 2 ways here one from 
 Session Progress message above and other from sip-b context that sip-b can 
 only do ulaw.) I am confused 
   ulaw
   alaw
   g729
 
 Asterisk send a BYE message to sip-b and send a 403 Forbidden Message to 
 ATA and hang-up the call here.
 
 asterisk -- sip-a send a BYE message and hang up.
 asterisk - ATA 403 Forbidden
 
 NOTICE[1248642112]: File channel.c, Line 1478 (ast_set_read_format): Unable 
 to find a path from G729A to ULAW
 NOTICE[1248642112]: File channel.c, Line 1448 (ast_set_write_format): 
 Unable to find a path from ULAW to G729A
 
 
 =
 
 Summery ;
 Why this is happening this way, (Do I not understand how to configure or is 
 this a bug?)
 As the coder negotiation is not well documented anywhere can you please 
 help me figure out how to configure the coder negotion.
 
 IMHO, I belive that for each context, we need to have a way to force which 
 coder to choose.   True that * can code convert with license, but when you 
 code/decode it will always be lossy and will loose quality of sound.  If 
 one side is fixed for a particular codec, and the other side is flexible 
 for a negotiation, I should see that flexible side should get adjusted to 
 the correct codec. It do not seem to happen.
 
 
 Thank you in advance and appreciate your help.
 
 
 - Sam 
 
 ___
 Asterisk-Users mailing list
 [EMAIL PROTECTED]
 

RE: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!

[SW]

Try using canreinvite=yes in all three contexts. Would that screw-up ATA, I
do not know, cause I have no Cisco's ?

SW

Message: 5
Date: Mon, 05 Jan 2004 02:29:49 -0500
From: SamW [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Asterisk-Users] Codec Negotiation Does not seem to work as
expected ?? Help  Please !!
Reply-To: [EMAIL PROTECTED]

Hello,

I have been trying to get my coders to work without a conversion. I have
read all the available asterisk documentation and support groups without
any luck. Here is my issue. (Please feel free to ask questions if you do
not understand what I am talking about.)

I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if
sip-server request g711)

I have 2 SIP-services to which I have to deliver the call in 2 coder
formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and
g711, SIP-B only accept g711.

I do not have any g729 licence, but I believe the * should negotiate to
have the correct passthrough coders as ATA is capable of both coders. (I
think even if you have the licenses, * should try avoid codec-conversions
when ever it can)


Here is my settings in sip.conf. I will only list the required codec
related lines, for easy understanding,

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

register = [EMAIL PROTECTED]
register = [EMAIL PROTECTED]

[sip-a]

disallow=all
allow=ulaw


[sip-b]
...
disallow=all
allow=g729

[ATA]
.
canreinvite=no


___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

RE: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!

[Samath]

Thanks for all who is helping.

I tried, canreinvite=yes on all contexts but that do not seem to work as
well. But the issue is not related to negotiating between end points,
but for me, asterisk do not have a proper configuration scheme which
works, to the requirement of the user. The Code-Negotiation in * for me
is buggy or featureless in Asterisk. 

The way to negotiate coders is to give priority to bridge-native without
a coder translation/conversion when ever possible, if we do not hard
tell * to do so. There could be users need to give priority to coder
translation (If you pay royalty fees to g729 may be!!). So my
expectation is we should have a way to tell * what order we like to have
coders negotiated for different contexts (or end points). 

I did some more digging into the problem and here is what I see. 

I changed the configuration as follows, (added disallow/allow to ATA
context, and I keep canreinvite=no as to show that * misbehaves in codec
negotiation by it self)


[general]

disallow=all
allow=g729
allow=ulaw
allow=alaw
register = [EMAIL PROTECTED]
register = [EMAIL PROTECTED]

[sip-a]

canreinvite=no
disallow=all
allow=ulaw


[sip-b]
...
canreinvite=no
disallow=all
allow=g729

[ATA]
.
canreinvite=yes
disallow=all
allow=g729


When ever I only allow g729 in ATA-context, during a call setup asterisk
send the SIP:Session Progress Message with only g729 listed in SDP
headers. Then I can make calls through to sip-a.

Then if I change [ATA] context to following(change allow=alaw), I can
make calls through sip-b. But not sip-a. [This is expected and is OK]
Here the * only send ulaw in its Session In progress request to ATA. *
do not list g729 in its request to '*'. Then ATA switches to the correct
codec and start sending rtp packets correctly. 

[ATA]
.
canreinvite=no
disallow=all
allow=ulaw


My point now is if * can send only the negotiated codec from sip-a or
sip-b then the ATA will act correctly. But when I configure for both
coders, as below, 

[ATA]
.
canreinvite=no
disallow=all
allow=g729
allow=ulaw


asterisk misbehaves, by sending both ulaw and g729 in the request to the
ATA and '*' gets confused by it self and drop the call. Also I have
noticed that allow order given in the [ATA] context have no effect.
Example, if I change context to have the following order, I expect * to
atleast send the request in the order it is shown in the context. But it
always, send the request to ATA in the order,  g729 and then ulaw. I do
not understand where '*' is deciding the order of the coders to send.
Ex. 

[ATA]
.
canreinvite=no
disallow=all
allow=ulaw
allow=g729

I think sip-a, sip-b and ATA is acting correctly, but '*' do not have a
way to configure the codec negotiation (There is but misbehave??). If we
users can agree, on this and if it is a requirement for us, should we be
able to file a bug-report? or send a request to the developers?? Lets
talk? I am willing to participate in any test that needs to be carried
out. 

Thanks,

SamW


___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [Asterisk-Users] Codec Negotiation Does not seem to work as e xpected ?? Help Please !!

[SamW]

Title: Re: [Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!





Steve,

My Problem is not a problem, with the codec negotiation between end points. But when asterisk does it with canreinvite=no, * do not do it right. I replied with a lengthy discussion about my findings here, This behavior can be reproduced. But '*' do not seem to do the negotiation correctly. 

http://lists.digium.com/pipermail/asterisk-users/2004-January/032197.html


I think your problem comes from a misunderstanding of how the calls are

placed. With your canreinvite=no in the ATA section, you end up with the

ATA negotiating with asterisk for a call leg. Then you have asterisk

negotiating for the other call leg. Since the RTP stream is going

through asterisk, it behaves with how asterisk is capable. If there had

been a reinvite, then the ATA and the remote end would then be able to

negotiate a different codec.



On Mon, 2004-01-05 at 01:29, SamW wrote:

 Hello,

 

 I have been trying to get my coders to work without a conversion. I have 

 read all the available asterisk documentation and support groups without 

 any luck. Here is my issue. (Please feel free to ask questions if you do 

 not understand what I am talking about.)

 

 I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if 

 sip-server request g711)

 

 I have 2 SIP-services to which I have to deliver the call in 2 coder 

 formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and 

 g711, SIP-B only accept g711.

 

 I do not have any g729 licence, but I believe the * should negotiate to 

 have the correct passthrough coders as ATA is capable of both coders. (I 

 think even if you have the licenses, * should try avoid codec-conversions 

 when ever it can)

 

 

 Here is my settings in sip.conf. I will only list the required codec 

 related lines, for easy understanding,

 

 [general]

 disallow=all

 allow=g729

 allow=ulaw

 allow=alaw

 

 register = [EMAIL PROTECTED]

 register = [EMAIL PROTECTED]

 

 [sip-a]

 

 disallow=all

 allow=ulaw

 

 

 [sip-b]

 ...

 disallow=all

 allow=g729

 

 [ATA]

 .

 canreinvite=no

 

 Here is what happens when I look at the SIP packets from linux. (ethereal)

 

 

 Case 1 : ATA Dialing out through sip-a

 

 

 

 ATA indicate that it can have following, codecs in SDP packet, in following 

 order

 ATA -- asterisk INVITE message

  g729

  ulaw

  alaw

 asterisk -- sip-a INVITE message (Note that already the order of coders 

 are changed. Is this how it should be I do not know. And how * decide what 

 order of coders to send to sip-a)

  alaw

  ulaw

  g729

 sip-a -- asterisk Session Progress Message

  ulaw

 asterisk -- ATA Session in Progress Message

  ulaw

  alaw

  g729

 asterisk -- ATA send a BYE message and hang up.

 

 at this point asterisk indicate it cannot native bridge message. I do not 

 know why asterisk behaves like this, and I do think if asterisk send the 

 message back to ATA with g729 in its message it should have worked fith 

 nating bridging.

 

 WARNING[1248642112]: File channel.c, Line 1853 

 (ast_channel_make_compatible): No path to translate from 

 SIP/sip-a-1e15(256) to SIP/4097-96d8(4)

 

  

 

 Case 2 : ATA calling sip-b

 ===

  

 ATA indicate that it can have following, codecs in SDP packet, in following 

 order

 ATA -- asterisk INVITE message

  g729

  ulaw

  alaw

 asterisk -- sip-b INVITE message (Note that unlike case 1, the decision 

 by * in this case is OK. * only send one available coder info to the sip-b, 

 which is correct as per my config)

  ulaw

 

 sip-b -- asterisk Session Progress Message

  ulaw

 asterisk -- ATA Session in Progress Message (Here again * sending multiple 

 choices to the ATA, I expect this to be only one request as * already know 

 from sip-b, that sip-b can only do ulaw. * know from 2 ways here one from 

 Session Progress message above and other from sip-b context that sip-b can 

 only do ulaw.) I am confused 

  ulaw

  alaw

  g729

 

 Asterisk send a BYE message to sip-b and send a 403 Forbidden Message to 

 ATA and hang-up the call here.

 

 asterisk -- sip-a send a BYE message and hang up.

 asterisk - ATA 403 Forbidden

 

 NOTICE[1248642112]: File channel.c, Line 1478 (ast_set_read_format): Unable 

 to find a path from G729A to ULAW

 NOTICE[1248642112]: File channel.c, Line 1448 (ast_set_write_format): 

 Unable to find a path from ULAW to G729A

 

 

 =

 

 Summery ;

 Why this is happening this way, (Do I not understand how to configure or is 

 this a bug?)

 As the coder negotiation is not well documented anywhere can you please 

 help me figure out how to configure the coder negotion.

 

 IMHO, I belive that for each context, we need to have a way to force which 

 coder to choose. True that * can code convert

Re: [Asterisk-Users] codec negotiation

[Nguyen Hoang Lan]

Hello Eduardo,

Wednesday, December 17, 2003, 1:08:00 AM, you wrote:

EG Hi list,

EG I'm with a little problem on codec negotiation between a cisco827 and
EG asterisk.

EG My sip.conf is like that: 

EG [general]
EG port = 5060
EG bindaddr = 0.0.0.0
EG context = default
EG amaflags = default
EG allow=g729
EG allow=gsm 
EG allow=alaw
EG allow=ulaw
EG ;disallow=all

EG and cisco like that:

EG dial-peer voice 6 voip
EG  destination-pattern 0T
EG  session protocol sipv2
EG  session target ipv4:asterisk-ip
EG  dtmf-relay rtp-nte
EG  codec g711alaw
EG  no vad   
EG ! 

EG When I try to make a call, cisco shows codec g711alaw, but asterisk
EG shows codec g729A (i have the licenses) and there is no audio. When I
EG try disallow=g729, the same occurs, but this time asterisk shows codec
EG gsm.

EG The only way to make a call is allowing only alaw. But this is not
EG convenience, since i need to use g279 with another endpoint (working
EG ok). 

EG Why this negotiation problem happens?

Try to add to cisco peer (not shown in your mail)

[cisco]

disallow=all
allow=alaw



-- 
Best regards,
 Nguyenmailto:[EMAIL PROTECTED]

___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

[Asterisk-Users] codec negotiation

[Eduardo Goncalves]

Hi list,

I'm with a little problem on codec negotiation between a cisco827 and
asterisk.

My sip.conf is like that: 

[general]
port = 5060
bindaddr = 0.0.0.0
context = default
amaflags = default
allow=g729
allow=gsm 
allow=alaw
allow=ulaw
;disallow=all

and cisco like that:

dial-peer voice 6 voip
 destination-pattern 0T
 session protocol sipv2
 session target ipv4:asterisk-ip
 dtmf-relay rtp-nte
 codec g711alaw
 no vad   
! 

When I try to make a call, cisco shows codec g711alaw, but asterisk
shows codec g729A (i have the licenses) and there is no audio. When I
try disallow=g729, the same occurs, but this time asterisk shows codec
gsm.

The only way to make a call is allowing only alaw. But this is not
convenience, since i need to use g279 with another endpoint (working
ok). 

Why this negotiation problem happens?

Thanks
Eduardo
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [Asterisk-Users] codec negotiation

[Andrew Thompson]

- Original Message -
From: Eduardo Goncalves [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 16, 2003 1:08 PM
Subject: [Asterisk-Users] codec negotiation


 Hi list,

 I'm with a little problem on codec negotiation between a cisco827 and
 asterisk.

 My sip.conf is like that:

 [general]
 port = 5060
 bindaddr = 0.0.0.0
 context = default
 amaflags = default
 allow=g729
 allow=gsm
 allow=alaw
 allow=ulaw
 ;disallow=all

 and cisco like that:

 dial-peer voice 6 voip
  destination-pattern 0T
  session protocol sipv2
  session target ipv4:asterisk-ip
  dtmf-relay rtp-nte
  codec g711alaw
  no vad
 !

 When I try to make a call, cisco shows codec g711alaw, but asterisk
 shows codec g729A (i have the licenses) and there is no audio. When I
 try disallow=g729, the same occurs, but this time asterisk shows codec
 gsm.

 The only way to make a call is allowing only alaw. But this is not
 convenience, since i need to use g279 with another endpoint (working
 ok).



You could try setting the codec before dialing that particular provider.
Except I don't see the command now that I'm trying to find it...

 Why this negotiation problem happens?

Can't help on that one...


 Thanks
 Eduardo

-
Andrew Thompson http://aktzero.com/
Your eyes are weary from staring at the CRT. You feel sleepy. Notice how
restful it is to watch the cursor blink. Close your eyes. The opinions
stated above are yours. You cannot imagine why you ever felt otherwise.



___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users