There is both a bug in the RFC itself and in the device in question. We might be able to wedge in tolerance but it may be a disservice because if you take the other option and fix the device then it will work correctly with every other compliant device. It may take a lot of code to make several exceptions in many places to tolerate this. It was painful enough wedging in the change to say 8000 everywhere. If the device is popular I would expect they would be eager to fix this. Germans are known for their attention to detail and quality after all. =]
Plus we don't even have one to test with.
What is your codec selection set to in FreeSWITCH and what rev of FreeSWITCH are you running?On Jan 20, 2012, at 4:09 PM, Roland Hänel wrote:OK you're right, I read the RfC and in fact a zero port means that the
stream is rejected. However the whole "negotiation" is still broken. If FS
rejects the incorrect G.722, OK, but what about all the other (perfectly
valid) codecs in the request (PCMA, PCMU)?
Because FS only rejects G.722, the call is doomed to fail, even though it
could work nicely if FS just selected one of the acceptable offers.
Roland
_________________________________________________________________________
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-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org