i tried asterisk ilbc codec against kphone. when the call got connected, i started to immediately get these kind of message to the console: WARNING[14350]: File codec_ilbc.c, Line 141 (ilbctolin_framein): Huh? An ilbc frame that isn't a multiple of 52 bytes long from RTP (50)? WARNING[14350]: File codec_ilbc.c, Line 141 (ilbctolin_framein): Huh? An ilbc frame that isn't a multiple of 52 bytes long from RTP (50)? WARNING[14350]: File codec_ilbc.c, Line 141 (ilbctolin_framein): Huh? An ilbc frame that isn't a multiple of 52 bytes long from RTP (50)? W... kphone ilbc has worked against two other ilbc implementations. kphone doesn't implement the very latest internet-draft that included a shorted sample size, but gips folks told me that the new version is backwards compatible with the one that kphone implements. -- juha
Alan Duric writes: > the problem seems to be the following: > - Kphone is using iLBC implementation based on draft draft-andersen-ilbc-01 > and it worked well with implementations based on > draft-ietf-avt-ilbc-codec-00, which followed it (that was the actual one at > the time of SIPiT interop event). However, it seems that there's problem > with backwards compatibility of current draft draft-ietf-avt-ilbc-codec-01 > (which is used by Asterisk implementation and will go for the WG last call) > against draft-andersen-ilbc-01 implementations. We have tested it very > carefully against draft-ietf-avt-ilbc-codec-00, and it worked well. alan, we changed kphone so that now it is compatible with draft-ietf-avt-ilbc-codec-01, but i don't think that that is really the issue. according to raft-ietf-avt-ilbc-codec-01, rtp payload is either 38 or 50 bytes, right? kphone is sending 50 byte payloads, but * seems to expect 52 byte payload: WARNING[14350]: File codec_ilbc.c, Line 141 (ilbctolin_framein): Huh? An ilbc frame that isn't a multiple of 52 bytes long from RTP (50)? if our interpretation of 50 byte payload size is correct, then it is * that is screwing this up if it is expecting to receive 52 byte payloads. -- juha
Mark writes: However, draft-ietf-avt-ilbc-codec-01 says, as you point out, that it should be 50. I've gone ahead and modified Asterisk to expect the 50 byte frames, but I suppose somewhere we need to be able to handle both types. i gave the latest (a hour ago) cvs a try and now * didn't complain about received 50 byte rtp payload, but was still sending 52 byte payloads. since 50 bytes is what it should be, could you please also change the sending side. i cannot tell if ilbc works the other way, because asterisk still doesn't play anything that kphone sends to it (nor the ringing tone), when invite comes into it. also, i cannot call anymore out from *, because now again * has started to use ip addresses in stead of names in from/to headers. this used to work like yesterday, but apparently something has got broken or i need to use some new sip configuration parameter that i don't know anything about. -- juha
after mark changed ilbc payload size to 50 bytes, */kphone started to
understand each other, but if i call from * to kphone, there is huge
delay. if i call from kphone to *, voice quality is good from * to
kphone, but i can't hear anything from kphone (not even a ringing sounds
that may point to problems with oss, not ilbc).
if we forget the oss problems, then it remains to replace host address
in ruri/to/from headers with name. an example from
draft-ietf-sipping-basic-call-flows-02.txt:
F1 INVITE Alice -> Bob
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 151
...
and some quotes from rfc 3261 (8.1.1 generating a request):
Request-URI The initial Request-URI of the message SHOULD be set to the
value of the URI in the To field.
To The To header field first and foremost specifies the desired logical
recipient of the request, or the address-of-record of the user or
resource that is the target of this request.
Does anyone have the fixed point implementation of the iLBC codec ? I am an undergraduate student that's trying to implement a faster way for this CODEC in a PC architeture using MMX/SSE (fixed point). -- Guilherme Loch G?es www.ufsc.br