Thanks for the quick reply Anthony.

Do you think this is a hard/easy thing to implement? I'm keen to contribute a bit to freeswitch, and this is functionality that I'd like to write some code for, and I can do what I like with our office PBX so I can test it here too.


On Fri, Sep 20, 2013 at 8:56 AM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
We currently only support one codec in 200OK  The workaround for this is to only offer it PCMU so it has no choice.



On Thu, Sep 19, 2013 at 2:52 PM, Sam Russell <sam.h.russell@gmail.com> wrote:
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

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org



--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org