search for: 001338

...MA/8000* > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=ptime:20 > a=maxptime:150 > a=sendrecv > > <------------> > > And when I look at the RTP debugging I see the data from the remote is: > > Got RTP packet from xx.xx.xx.xx:50644 (type 18, seq 001338, ts 610458, len 000020) > > AAArgh! Type 18 is g729. Why on earth is the remote sending me g729 when > I clearly said the only thing I could do was alaw. > > Is this legal? > > Is the other side broken? > It shouldn't be sending it, but as well we should be ignoring i...

...t; *a=rtpmap:8 PCMA/8000* > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=ptime:20 > a=maxptime:150 > a=sendrecv > > <------------> And when I look at the RTP debugging I see the data from the remote is: > Got RTP packet from xx.xx.xx.xx:50644 (type 18, seq 001338, ts 610458, > len 000020) AAArgh!  Type 18 is g729.  Why on earth is the remote sending me g729 when I clearly said the only thing I could do was alaw. Is this legal? Is the other side broken? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

I am having a problem with one of my callers who is using either g729 or alaw.  I can do alaw but not g729 so asterisk should negotiate alaw right?  In fact from the sip debug it looks like it does, but then I get the dreaded "channel.c:5630 set_format: Unable to find a codec translation path: (g729) -> (alaw)" and the call hangs up.  Why? Last minute thought: Is it possible that