[Home]

Summary:ASTERISK-07875: Problem with forcing SIP_CODEC on an iax2 trunks
Reporter:richardp (richardp)Labels:
Date Opened:2006-10-04 21:37:25Date Closed:2006-11-16 17:42:20.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Ouput.txt
Description:I have two asterisk (HP DL 360's - RHEL ES 4) servers located in separate facilities that are connected via an IAX trunk. On each side of the trunk I am using ulaw. However, due to bandwidth constraints on the trunk I need to use G729 accross the trunk. I am using Snom360 phones which do both g729 and ulaw so I do not need the asterisk boxes to transcode. The issue is that asterisk tries to establish the call via ulaw before forcing SIP_CODEC so the  trunk call fails. (Please see the included file.) An even when the trunk allows ulaw the conversion to G729 causes further warnings (Please see included file).

Having looked through other bugs I found bug number 0000450 had little relevance as the code is different in 1.2.10 and 1.2.12.1. Bug 0002566 looked promising but no relevance as the fix suggested is still included on 4428 (version 1.2.10).

I am not familiar with the code however the error generated is related to chan_iax2 line 8003 as chan_iax2 doesn't seem to recognise c->nativeformats. I suspect that that this is related to tmp->nativeformats = capability (line 3431 in 1.2.10) Other bug reports indicate that this might need to be joincapability however I am just guessing.

If there is anything else I can give you please let me know.

****** ADDITIONAL INFORMATION ******

sip.conf

[general]
context=default
allowguest=no
bindport=5060
bindaddr=0.0.0.0
pedantic=no
disallow=all
allow=ulaw
allow=g729
musicclass=default
language=en
dtmfmode=rfc2833
subscribecontext=internal-sip


[901]
type=friend
context=internal-sip
host=dynamic
qualify=yes
username=901
callerid="User 0" <901>
callgroup=1
pickupgroup=1
restrictcid=no

iax.conf

[general]
diallow=all
bandwidth=low
jitterbuffer=no

[IAXTRUNK01]
type=friend
user=user
secret=opensaysme
host=192.168.240.52
mask=255.255.255.255
trunk=yes
context=iax2trunk
jitterbuffer=yes
forcejitterbuffer=no
maxjitterbuffer=1000
maxjitterinterps=10
resyncthreshold=1000
tos=lowdelay
disallow=all
allow=g729
;allow=ulaw
Comments:By: Serge Vecher (serge-v) 2006-10-05 08:29:48

why don't you just move allow=g729 above allow=ulaw in sip.conf?

allow=g729
allow=ulaw
By: Joshua C. Colp (jcolp) 2006-10-05 13:23:35

It would also be good to turn on debug in logger.conf and set debug 9.
By: Olle Johansson (oej) 2006-10-17 07:08:37

SIP_CODEC is not meant to have any effect on an IAX trunk. You need to configure each side of the trunk properly.
By: richardp (richardp) 2006-10-17 18:45:09

>why don't you just move allow=g729 above allow=ulaw in sip.conf?
>
>allow=g729
>allow=ulaw

I have tried this but then the force to ulaw for local calls doesn't work correctly.

>SIP_CODEC is not meant to have any effect on an IAX trunk. You need to configure each side of the trunk properly.

No. I am running the trunk over a satellite link I can't afford ulaw (bandwidth constraints) over the trunk so I have to disable ulaw on both sides from the start. And the only way to make this work at the moment is to allow ulaw and g729 down the trunk. This is not acceptable. But as I stated in my reply to a previous email this seems to be because the execution order means that the trunk tries to establish before the codec is forced to change. If you allow ulaw down the trunk the call establishes  and then changes to g729.
By: Serge Vecher (serge-v) 2006-10-23 13:13:20

the level of codec manipulation you require is currently not supported in Asterisk.
AFAIK, you have a couple of choices:
1) make g.729 the default codec across the board. I'm not sure why do you have to force it to ulaw g.711 on lan. The quality should be comparable.
2) Purchase g.729 codec licenses from Digium, so that you can enable transcoding between an ulaw (lan) leg and a g.729 (wan) leg in Asterisk.
3) Try the new codec negotiation algorithm in bug ASTERISK-4703 and see if the extended capabilities fit your needs there.
By: Joshua C. Colp (jcolp) 2006-11-16 17:42:19.000-0600

As serge-v noted, the level of codec control you seek is not currently available. What some people end up doing though is making separate user/peer entries with codec settings to control codec negotiation. This may be of help to you, if not I apologize. Good luck on your codec troubles.