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