asterisk users - Nov 2003 - "Unable to find path from G729A to ULAW" on Sipphone.com

I seem to be having a problem with transcoding and/or agreeing on a
valid codec.  I am running a new image pulled from CVS at 1:30 PM CST.
The issue occurs when I try to make a call to a toll-free number over
sipphone.com.

Here's what I see in the console:

NOTICE[1259545280]: File channel.c, Line 1478 (ast_set_read_format):
Unable to find a path from G729A to ULAW
NOTICE[1259545280]: File channel.c, Line 1448 (ast_set_write_format):
Unable to find a path from ULAW to G729A

Before somebody tells me "UTFG", I ALREADY HAVE.  Somebody else had a
similar issue last week and there was no real resolution posted.  So
here it is again.  I have all of the codecs that I support enabled in my
sip.conf.  Here is the relevant section:

;
; SIP Configuration for Asterisk
;
[general]
port = 5060                     ; Port to bind to
bindaddr = 0.0.0.0              ; Address to bind to
context = default               ; Default for incoming calls
srvlookup = yes         ; Enable SRV lookups on outbound calls
pedantic = yes                  ; Enable slow, pedantic checking for
Pingtel
;tos=lowdelay
;tos=184
maxexpirey=3600         ; Max length of incoming registration we allow
defaultexpirey=120              ; Default length of incoming/outoing
registration
;notifymimetype=text/plain      ; Allow overriding of mime type in
NOTIFY
;videosupport=yes               ; Turn on support for SIP video
disallow=all                    ; Disallow all codecs
allow=ulaw                      ; Allow codecs in order of preference
allow=alaw                      ; Allow codecs in order of preference
allow=gsm
allow=ilbc

register => 17476692375:[MYSECRET]@sipphone.com/1101

[sipphone]
type=peer
username=17476692375
secret=[MYSECRET]
host=proxy01.sipphone.com
fromuser=SteveSokol
fromdomain=sipphone.com
canreinvite=no

; ==END OF SIP.CONF FILE==
The issue occurs whenever any calls that route over the sipphone peer
are made to a toll-free number.  The calling phone (either my GS100 or
my X-LITE softphone) rings two or three times then gives me busy.  Here
is the entire debug output:

    -- Executing Dial("SIP/1101-1f83",
"SIP/18884510851@sipphone.com|20|tr") in new stack
    -- Called 18884510851@sipphone.com
NOTICE[1234379840]: File channel.c, Line 1478 (ast_set_read_format):
Unable to find a path from G729A to ULAW
NOTICE[1234379840]: File channel.c, Line 1448 (ast_set_write_format):
Unable to find a path from ULAW to G729A
    -- SIP/sipphone.com-e7b3 is making progress passing it to
SIP/1101-1f83
    -- SIP/sipphone.com-e7b3 answered SIP/1101-1f83
    -- Attempting native bridge of SIP/1101-1f83 and
SIP/sipphone.com-e7b3
NOTICE[1242768320]: File channel.c, Line 1478 (ast_set_read_format):
Unable to find a path from G729A to ULAW
NOTICE[1242768320]: File channel.c, Line 1448 (ast_set_write_format):
Unable to find a path from ULAW to G729A
WARNING[1234379840]: File chan_sip.c, Line 1159 (sip_write): Asked to
transmit frame type 4, while native formats is 256 (read/write = 4/4)
  == Spawn extension (default, 918884510851, 1) exited non-zero on
'SIP/1101-1f83'

The problem does NOT occur when I call another sipphone.com user (i.e.
GS100 -> Asterisk -> Sipphone -> GS100).  Those calls go through just
fine.  The toll free calls were working last week.  Is it me, or is it
Sipphone.com?

Any suggestions would be greatly appreciated.

Steve

asterisk-users-admin@lists.digium.com wrote:
> I seem to be having a problem with transcoding and/or agreeing on a
> valid codec.  I am running a new image pulled from CVS at 1:30 PM
CST.
> The issue occurs when I try to make a call to a toll-free number
over
> sipphone.com. 
> 
> Here's what I see in the console:
> 
> NOTICE[1259545280]: File channel.c, Line 1478 (ast_set_read_format):
> Unable to find a path from G729A to ULAW
> NOTICE[1259545280]: File channel.c, Line 1448
(ast_set_write_format):
> Unable to find a path from ULAW to G729A
> 
> Before somebody tells me "UTFG", I ALREADY HAVE.  Somebody else
had
a
> similar issue last week and there was no real resolution posted.  So
> here it is again.  I have all of the codecs that I support
> enabled in my
> sip.conf.  Here is the relevant section:
> 
> ;
> ; SIP Configuration for Asterisk
> ;
> [general]
> port = 5060                     ; Port to bind to
> bindaddr = 0.0.0.0              ; Address to bind to
> context = default               ; Default for incoming calls
> srvlookup = yes         ; Enable SRV lookups on outbound calls
> pedantic = yes                  ; Enable slow, pedantic checking for
> Pingtel ;tos=lowdelay
> ;tos=184
> maxexpirey=3600         ; Max length of incoming registration we
allow
> defaultexpirey=120              ; Default length of incoming/outoing
> registration ;notifymimetype=text/plain      ; Allow overriding of
> mime type in NOTIFY ;videosupport=yes               ; Turn on
support
> for SIP video disallow=all                    ; Disallow all codecs
> allow=ulaw                      ; Allow codecs in order of
preference
> allow=alaw                      ; Allow codecs in order of
preference
> allow=gsm allow=ilbc
> 
> register => 17476692375:[MYSECRET]@sipphone.com/1101
> 
> [sipphone]
> type=peer
> username=17476692375
> secret=[MYSECRET]
> host=proxy01.sipphone.com
> fromuser=SteveSokol
> fromdomain=sipphone.com
> canreinvite=no
> 
> ; ==END OF SIP.CONF FILE==> 
> The issue occurs whenever any calls that route over the sipphone
peer
> are made to a toll-free number.  The calling phone (either my GS100
or
> my X-LITE softphone) rings two or three times then gives me
> busy.  Here
> is the entire debug output:
> 
>     -- Executing Dial("SIP/1101-1f83",
> "SIP/18884510851@sipphone.com|20|tr") in new stack
>     -- Called 18884510851@sipphone.com
> NOTICE[1234379840]: File channel.c, Line 1478 (ast_set_read_format):
> Unable to find a path from G729A to ULAW
> NOTICE[1234379840]: File channel.c, Line 1448
(ast_set_write_format):
> Unable to find a path from ULAW to G729A
>     -- SIP/sipphone.com-e7b3 is making progress passing it to
> SIP/1101-1f83 
>     -- SIP/sipphone.com-e7b3 answered SIP/1101-1f83
>     -- Attempting native bridge of SIP/1101-1f83 and
> SIP/sipphone.com-e7b3 NOTICE[1242768320]: File channel.c, Line 1478
> (ast_set_read_format): Unable to find a path from G729A to ULAW
> NOTICE[1242768320]: File channel.c, Line 1448
(ast_set_write_format):
> Unable to find a path from ULAW to G729A
> WARNING[1234379840]: File chan_sip.c, Line 1159 (sip_write): Asked
to
> transmit frame type 4, while native formats is 256 (read/write 4/4)
>   == Spawn extension (default, 918884510851, 1) exited non-zero on
> 'SIP/1101-1f83' 
> 
> The problem does NOT occur when I call another sipphone.com user
(i.e.
> GS100 -> Asterisk -> Sipphone -> GS100).  Those calls go through
just
> fine.  The toll free calls were working last week.  Is it me, or is
> it Sipphone.com? 
> 
> Any suggestions would be greatly appreciated.
> 
> Steve
I've been having the same types of problems (I'm probably the guy
you're referring to who had the same problems last week).  This is the
solution I have found to work reliably so far.

Configure the Grandstream BT101 with the following codecs, in the
following order:
choice 1: G.729A/B (g729)
choice 2: PCMU (ulaw)
choice 3: PCMA (alaw)
choice 4: G.729A/B (g729)
choice 5: PCMU (ulaw)
choice 6: PCMA (alaw)

Configure the codecs in sip.conf like this:
disallow=all
allow=all
allow=ulaw
allow=alaw
allow=g729

Configure the entry in extensions.conf to use a certain codec when
necessary (I've found it necessary only when calling through the 800
gateway provided to both FWD and SIPphone):
; FWD
exten => _1800NXXXXXX,1,Macro(callerid-pstn)
exten => _1800NXXXXXX,2,SetVar(SIP_CODEC=g729)
exten => _1800NXXXXXX,3,Dial(SIP/*${EXTEN}@fwd)
; SIPphone
;exten => _1800NXXXXXX,1,Macro(callerid-pstn)
;exten => _1800NXXXXXX,2,SetVar(SIP_CODEC=g729)
;exten => _1800NXXXXXX,3,Dial(SIP/*${EXTEN}@sipphone)

I hope this helps,

Barton

On Tuesday 18 November 2003 14:15, Steven Sokol wrote:
> I seem to be having a problem with transcoding and/or agreeing on a
> valid codec.  I am running a new image pulled from CVS at 1:30 PM
> CST. The issue occurs when I try to make a call to a toll-free
> number over sipphone.com.
>
> Here's what I see in the console:
>
> NOTICE[1259545280]: File channel.c, Line 1478
> (ast_set_read_format): Unable to find a path from G729A to ULAW
> NOTICE[1259545280]: File channel.c, Line 1448
> (ast_set_write_format): Unable to find a path from ULAW to G729A
>
> Before somebody tells me "UTFG", I ALREADY HAVE.  Somebody else
had
> a similar issue last week and there was no real resolution posted. 
> So here it is again.  I have all of the codecs that I support
> enabled in my sip.conf.  Here is the relevant section:
You cannot use G.729 unless you have purchased licenses for it.  So
either purchase licenses or turn it off on the client.

-Tilghman

--- Steve Underwood <steveu@coppice.org> wrote:
> Arnold Ligtvoet wrote:
> 
> >Since I would like the user names to be auto-generated by the
> system, I
> >would guess that this could best be done using festival with a
> localized
> >voice. I think there is a Dutch voice for Mbrola with should
> integrate into
> >festival ( note to self : need bigger harddisk :-) )
> >  
> >
> Speech recognition accuracy is not great under ideal conditions.
> Doing 
> what you suggest seems unlikely to achieve any meaningful accuracy. 
> Speech recognition training systems require many occurances of a word
> or 
> phrase, clearly spoken, before their accuracy becomes useful. A one
> shot 
> utterance from Festival seems to fail on both counts :-)
> 
> Bottom line: the very best speech recognition still sucks. As a
> British 
> speaker I never get more than about 40% accuracy speaking into a US 
> trained recogniser. I have never had better than about 70-80%
> accuracy 
> on a British trained recogniser. Strangely, my terrible Cantonese
> gets 
> nearly 100% on SpeechWorks recogniser. :-\
An interresting question might be "How well to humans recognize
words in the same situation?"  I doubt they can score better then 80%.

Sounds low but "same situation" means the human does nt have access
to the grametric or semantic context and must recognize the words
one at a time in radom order over a telphone.

But if you design the application "correctly" and you look not just at
the firt pick but the whole probibility list you can do well.  Well
being maybe 80% or so.  So one in five time you have to ask the use
to press a key or something.

I agree 100%.  You will have to get some people together to train
the system.  

====Chris Albertson
  Home:   310-376-1029  chrisalbertson90278@yahoo.com
  Cell:   310-990-7550
  Office: 310-336-5189  Christopher.J.Albertson@aero.org
  KG6OMK

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree