GNOME Bugzilla – Bug 328794
SIP incorrect payload type 112 (ilbc) with asterisk
Last modified: 2006-02-11 14:05:53 UTC
Please describe the problem: When asterisk initiate a call to ekiga with ilbc, asterisk send its first rtp with a payload type of x70 (112/ilbc) but ekiga send back in its first rtp packet a payload type of 0xf0 and then on subsequent packets 0x70. Ethereal list all packets from ekiga to asterisk as payload type=unknow (112). Asterisk give the same notice in its log and the audio work from asterisk to ekiga but not from ekiga to asterisk. I suspect the problem is related to ilbc not being a registered codec with the rtp protocol and has to be negotiated... Steps to reproduce: 1. initiate a call from asterisk to ekiga with ilbc as prefered codec from asterisk 2. 3. Actual results: no audio from ekiga to asterisk Expected results: Does this happen every time? a lot of times... Other information: I have a complete packet capture of the SIP call if you need it, please contact me.
The bug is probably in OPAL. Damien will certainly have a look at it when he'll have the time, as interoperating with asterisk is crucial.
Actually, I'm back for one day, and had a look at it. Have you tried calling 500@ekiga.net? It works perfectly with iLBC. I even made an ethereal dump, and I couldn't reproduce your bug. What you describe about the "112" payload is a normal behavior. However, this "ekiga send back in its first rtp packet a payload type of 0xf0 and then on subsequent packets 0x70" is not normal, but I can not reproduce it here with Asterisk 1.0 or 1.2. Can I contact your asterisk somehow?
Damien, I have just sent you the packet capture. The problem arises only when asterisk contact ekiga, not the oposite. I think the packet capture should have everything but if you need more get me on #ekiga and I will create an extension for you on my asterisk for you to register to and I will call you. Cheers
Damien, The diff you sent me has fixed the issue.
Beware : you shouldn't close the bug because Damien sent a diff! A patch only means a solution was found -- it may take some time to apply it! I'll leave it closed, but still : beware!
Yes, Craig doesn't want that patch to be applied AS IS. I will reopen the bug, and it will be marked as fixed when he can come with a better fix.
*** Bug 329180 has been marked as a duplicate of this bug. ***
*** Bug 329204 has been marked as a duplicate of this bug. ***
That's fixed in latest OPAL CVS HEAD.
*** Bug 330779 has been marked as a duplicate of this bug. ***
Marking as FIXED.