[Home]

Summary:ASTERISK-04976: Asterisk forcing ulaw on passthrough
Reporter:Bluce Ree (tasker)Labels:
Date Opened:2005-09-04 11:31:47Date Closed:2007-06-29 12:19:48
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Both originating endpoints have been configured to only offer and accept G.729 codec. The set up has no G.729 codec module so as to test it in pure passthrough.

The only line in extensions.conf is a Dial command to transfer the call out to the destination to test if Asterisk will do pure passthrough.

[default]
exten => s,1,Dial(H323/${DNID}|60|g)

Here is how codecs are configured in h323.conf:

disallow=all
;allow=all              ; turns on all installed codecs
disallow=g723.1 ; Hm...  Proprietary, don't use it...
disallow=gsm            ; Always allow GSM, it's cool :)
disallow=ulaw
disallow=alaw
allow=g729

I explicitly added the disallow directives just in case.

Both ends are using Cisco AS5300. I've also tested this with various IP phones and always ended with the same result.

The call always fails with, "channel.c:2188 ast_request: No translator path exists for channel type H323 (native 4) to 256", even though all codecs have been disabled except for g729.


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

Here is an application trace showing the failure occuring immediately after the Dial() command is executed:

=============================================

== Starting H323/ip$62.54.71.88:41962/10171 at default,12345#15132315444,1 failed so falling back to exten 's'
   -- Executing Dial("H323/ip$62.54.71.88:41962/10171", "H323/12345#15132315444|60|g") in new stack
Sep  4 12:22:38 WARNING[15417]: channel.c:2188 ast_request: No translator path exists for channel type H323 (native 4) to 256
Sep  4 12:22:38 NOTICE[15417]: app_dial.c:1101 dial_exec_full: Unable to create channel of type 'H323' (cause 0 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
=============================================


Here is an H.323 trace showing that the incoming call is G.729:

=============================================

modemcab== New H.323 Connection created.
   -- Setting up Call
   -- bCall token:  [ip$62.54.71.88:40022/8812]
   -- bCalling party name:  []
   -- bCalling party number:  [16137283374]
   -- bCalled party name:  [12345#16132254441]
   -- bCalled party number:  [12345#16132254441]
modemcab--Received SETUP message
Allowed Codecs:LI>
modemcab Table:LI>
  G.729A <1>*CLI>
  G.729 <2>5*CLI>
  UserInput/hookflash <3>
  UserInput/RFC2833 <4>
Set:cable245*CLI>
  0:cable245*CLI>
    0:ble245*CLI>
      G.729A <1>>
      G.729 <2>I>
    1:ble245*CLI>
      UserInput/hookflash <3>
    2:ble245*CLI>
      UserInput/RFC2833 <4>
modemcable245*CLI>
modemcab=-= In OnAnswerCall for call 8812
modemcable245*CL- Progress Indicator: 0
modemcable245*CL- Inserting PI of 0 into ALERTING message
modemcab-- Started logical channel: sending G.729
modemcable245*CL-- channelsOpen = 1
modemcable245*CLExternal RTP Session Starting
modemcable245*CLRTP channel id 1 parameters:
modemcable245*CL-- remoteIpAddress: 24.23.19.6
modemcable245*CL-- remotePort: 1724
modemcable245*CL-- ExternalIpAddress: 69.20.2.44
modemcable245*CL-- ExternalPort: 17256
modemcab-- Started logical channel: receiving G.729
modemcable245*CL-- channelsOpen = 2
modemcable245*CLExternal RTP Session Starting
modemcable245*CLRTP channel id 1 parameters:
Sep  4 12:02:48 WARNING[17730]: channel.c:2188 ast_request: No translator path exists for channel type H323 (native 4) to 256
Sep  4 12:02:48 NOTICE[17730]: app_dial.c:1101 dial_exec_full: Unable to create channel of type 'H323' (cause 0 - Unknown)
modemcab-- Sending RELEASE COMPLETE
modemcab-- ClearCall: Request to clear call with token ip$62.54.71.88:40022/8812, cause EndedByRemoteUser
modemcable245*CLchannelsOpen = 1
               channelsOpen = 0
modemcabExternalRTPChannel Destroyed
modemcabExternalRTPChannel Destroyed
modemcab-- ClearCall: Request to clear call with token ip$62.54.71.88:40022/8812, cause EndedByTransportFail
-- 16137283374, umb-ep1 [62.54.71.88] has cleared the call
       == H.323 Connection deleted.
Comments:By: Michael Jerris (mikej) 2005-09-04 14:19:51

what happens if you get rid of all of the disallow= lines except for disallow=all?
By: Bluce Ree (tasker) 2005-09-04 16:19:59

Same problem. I added the all the "disallow" lines as a last resort when I ran out of options.

I just tried removing "allow=g729" and leaving nothing but "disallow=all" and here's the result. It still tries to transcode from g729 to "-2033664":

==========================

Sep  4 17:12:12 WARNING[19530]: channel.c:455 ast_best_codec: Don't know any of 0xffe0f800 formats
 == Starting H323/ip$62.45.6.12:59666/8034 at default,1234#16134448181,1 failed so falling back to exten 's'
   -- Executing Dial("H323/ip$62.45.6.12:59666/8034", "H323/1234#16134448181|60|g") in new stack
Sep  4 17:12:12 WARNING[19530]: channel.c:2188 ast_request: No translator path exists for channel type H323 (native 4) to -2033664
Sep  4 17:12:12 NOTICE[19530]: app_dial.c:1101 dial_exec_full: Unable to create channel of type 'H323' (cause 0 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing Hangup("H323/ip$62.45.6.12:59666/8034", "") in new stack
 == Spawn extension (default, s, 3) exited non-zero on 'H323/ip$62.45.6.12:59666/8034'
By: Bluce Ree (tasker) 2005-09-04 17:34:28

I've traced the bug down to the channel's capabilities not being set properly.

=======
Function called:

struct ast_channel *ast_request(const char *type, int format, void *data, int *cause)

...

     while(chan) {
               if (!strcasecmp(type, chan->tech->type)) {
                       capabilities = chan->tech->capabilities;
                       fmt = format;
                       res = ast_translator_best_choice(&fmt, &capabilities);


========

The "capabilities" variable is set to '4', which is ulaw. If I modify the "capabilities" member of the struct "oh323_tech" in chan_h323.c as below, G.729A passes through without a problem:

============
static const struct ast_channel_tech oh323_tech = {
       .type = type,
       .description = tdesc,
       .capabilities = AST_FORMAT_ULAW|AST_FORMAT_G729A,
...
============

It looks like the channel driver is ignoring the allow / disallow list when setting the channel type's capabilities.
By: Paul Cadach (pcadach) 2005-09-05 11:50:22

Full call trace is required to verify is codec negotiation is correct. Please, look at recommendations at ASTERISK-4862 for grab full call trace.
By: Bluce Ree (tasker) 2005-09-05 15:28:19

I added a trace log in "ast_translator_best_choice()" from "translate.c" and I see it being called 3 times during the inbound call, with the last being called from "channel.c". As you can see, the codec is properly chosen on the first two passes but not the last, when channel.c returns a failure warning.

Here is the trace:
===========================

Sep  5 16:10:39 WARNING[4872]: translate.c:465 ast_translator_best_choice: RESULTS:  (native 256) to 256

Sep  5 16:10:39 WARNING[4872]: translate.c:465 ast_translator_best_choice: RESULTS:  (native 256) to 256

Sep  5 16:10:40 WARNING[4872]: translate.c:465 ast_translator_best_choice: RESULTS:  (native 4) to 256

Sep  5 16:10:40 WARNING[17730]: channel.c:2188 ast_request: No translator path exists for channel type H323 (native 4) to 256

===========================

When I added a trace log to show what capabilities are registered in the chan struct, "chan->tech->capabilities" in "ast_request()" from channel.c, the only capability listed there is ulaw. That struct is initialized by Asterisk and should contain what codecs are allowed loaded from the config file. Instead, it is reset to its default set during struct initialization and prior to loading from the config file, hence the reason why it worked when I added AST_FORMAT_G729 to the default initialization at creation of the struct. It's not a negotiation problem.
By: Michael Jerris (mikej) 2005-09-25 15:44:27

Where in the code is it resetting but not based upon the config file (or alternatively initializing without consideration for the config options before use)?
By: Bluce Ree (tasker) 2005-10-09 11:30:49

That's where I was hoping someone could provide some insight. If I knew where this occurred, I would fix it.

Can someone point me in the right direction as to where else this particular block is initialized?
By: Tilghman Lesher (tilghman) 2005-10-09 14:17:26

Asterisk is not a gatekeeper; it's a gateway.  You need to have at least one G.729 license for it to negotiate G.729, even in passthrough mode.
By: jerjer (jerjer) 2005-10-11 21:46:12

I have boxes that used to do G.729 pass-thru without any licenses - that's why it is called pass-thru.  However one CANNOT use any dial modifers (T,t,r,etc) and no prompts can be played, of course.


Something is odd - It seems the far end is asking for ulaw and you want G.729.   Attach a h.323 trace 4 and H.323 debug output
By: Matt O'Gorman (mogorman) 2005-11-08 13:48:40.000-0600

any more updates on this bug, its been just over a month.  realize it is real bug but can you help us recreate or give access to your box, as members of the community do have it working.
By: hisitepu (hisitepu) 2005-11-24 19:58:36.000-0600

I have experienced the same problem and I found out there is a different initializer in chan_sip.c:
---
static const struct ast_channel_tech sip_tech = {
       .type = channeltype,
       .description = "Session Initiation Protocol (SIP)",
       .capabilities = ((AST_FORMAT_MAX_AUDIO << 1) - 1),
       ...
---
and in chan_h323.c:
---
static const struct ast_channel_tech oh323_tech = {
       .type = type,
       .description = tdesc,
       .capabilities = AST_FORMAT_ULAW,
       ...
---

After i replace the AST_FORMAT_ULAW in chan_h323.c with ((AST_FORMAT_MAX_AUDIO << 1) - 1), passthrough g729 work find. But g723 passthrough still got no audio at all. Any idea?
By: Matt O'Gorman (mogorman) 2006-01-08 10:38:34.000-0600

jejer another user using chan_h323.  I think his patch is all he needs but i have no way to test.  not sure why g723.1 wouldnt work in pass through
By: Matt O'Gorman (mogorman) 2006-02-16 13:19:21.000-0600

can the bug reporter or jerjer respond to this issue?  it has been idling for over a month.
By: Joshua C. Colp (jcolp) 2007-06-29 12:19:47

This issue should already be fixed.