search for: ast_format_ilbc

...(*): May 5 10:48:15 NOTICE[139648000]: rtp.c:418 ast_rtp_read: Unknown RTP codec 96 received May 5 10:48:15 NOTICE[139648000]: rtp.c:418 ast_rtp_read: Unknown RTP codec 96 received We had this static_RTP_PT[xx] structure in rtp.c :(asterisk source): [...] [34] = {1, AST_FORMAT_H263}, [97] = {1, AST_FORMAT_ILBC}, [101] = {0, AST_RTP_DTMF}, [110] = {1, AST_FORMAT_SPEEX}, [121] = {0, AST_RTP_CISCO_DTMF}, // Must be type 121 [...] as there is no 96 entry and function ast_rtp_read() is returning 'Unknown RTP.....". We added entry, recompiled Asterisk and yeah it works!!!!!! See debug below: [...]...

...w ast 1.8 server and see > if the SRCC is changing between my scenarios described above.? Am I on the > right track or is there something else I should be looking at? > I added [96] in */main/rtp.c of the ast 1.4 servers then recompiled. [96] = {0, AST_RTP_DTMF}, [97] = {1, AST_FORMAT_ILBC}, [99] = {1, AST_FORMAT_H264}, [101] = {0, AST_RTP_DTMF}, This seemed to allow flow through of the DTMF up to the new 1.8 call servers and on to the carrier. I don't know why this seemed to fix the issue, I'm not 100% convinced it really did. I reverted the change and coul...

...samples=0; switch(f->subclass) { case AST_FORMAT_SPEEX: samples = 160; /* XXX Not necessarily true XXX */ break; case AST_FORMAT_G723_1: samples = 240 /* XXX Not necessarily true XXX */; break; case AST_FORMAT_ILBC: samples = 240 * (f->datalen / 50); break; case AST_FORMAT_GSM: samples = 160 * (f->datalen / 33); break; case AST_FORMAT_G729A: samples = 160 * (f->datalen / 20); break; [...] }...

Jean-Marc Valin wrote: >>Heh. I guess after playing with different jitter buffers long enough, >>I've realized that there's always situations that you haven't properly >>accounted for when designing one. >> >> > >For example? :-) > > I have a bunch of examples listed on the wiki page where I had written initial specifications: