[Freeswitch-dev] Freeswitch chooses the first codec and ignores the rest

[Sam Russell]

I've had a couple of calls recently that have been a little weird -
here's the scenario:

A (local freeswitch) sends invite with PCMU, PCMA as codecs

B (foreign) sends 200 OK with PCMA, PCMU as codecs

Freeswitch sees the response and sets audio codec to PCMA, but other
end sends us PCMU (as it was our first choice in this case - sometimes
they choose a random one that both of us support).

RTP is fine with this - each packet refers to the # of the codec
(either standard or a reference to an rtpmap from the SDP), but
freeswitch doesn't like it - it forwards the PCMA from my soft phone,
but the PCMU coming in from the foreign phone gets dropped by
freeswitch and doesn't get forwarded onto my soft phone (packet trace
shows freeswitch being the black hole).

Debug output shows freeswitch setting the audio codec, and I suspect
this means it then only accepts RTP with that codec, instead of
handling all codecs that it offered in its invite.

Is this expected behaviour? I went trawling through RFCs yesterday and
nothing jumped out at me, and I'm seeing this on a couple of call
managers - also sometimes the other end will send H263+ even though
both ends offered H264 as preferred, and freeswitch drops this in the
same manner. I think freeswitch should be handling all codecs that it
offers, especially for video when it only does pass through, so
spinning up instances of extra "codecs" shouldn't create much
overhead.

Sent from my iPhone