[Freeswitch-users] Incorrect reply to T.38 re-INVITE

[Tomasz Ostrowski]

Hello,
while testing FreeSWITCH 1.4.26 I stumbled upon old and seemingly ignored  
problem when FreeSWITCH replies with SDP containing:

m=image 0 udptl t38
m=image 0 udptl t38

when receiving re-INVITE with disabled audio media and enabled image media  
(switching from audio to image). As far as I know this is correct way to  
change media, from RFC 3264:

8.1 Adding a Media Stream

    New media streams are created by new additional media descriptions
    below the existing ones, or by reusing the "slot" used by an old
    media stream which had been disabled by setting its port to zero.

    Reusing its slot means that the new media description replaces the
    old one, but retains its positioning relative to other media
    descriptions in  the SDP.  New media descriptions MUST appear below
    any existing media sections.  The rules for formatting these media
    descriptions are identical to those described in Section 5.

    When the answerer receives an SDP with more media descriptions than
    the previous SDP from the offerer, or it receives an SDP with a media
    stream in a slot where the port was previously zero, the answerer
    knows that new media streams are being added.  These can be rejected
    or accepted by placing an appropriately structured media description
    in the answer.  The procedures for constructing the new media
    description in the answer are described in Section 6.

This problem is mentioned in:
https://freeswitch.org/jira/browse/FS-7037
https://freeswitch.org/jira/browse/FS-6212

With reversed transmission direction (when FreeSWITCH receives FAX and  
re-INVITES) re-INVITE contains only image media, but this is easier to  
accept (https://freeswitch.org/jira/browse/FS-6954 -  correcting it caused  
interoperability problems between FS versions), while not accepting  
correct SDP by FreeSWITCH is really painful as it requires implementing  
RFC non-compliant negotiation and probably adding special switch in  
configuration to be interoperable.

Is this issue fixed in FreeSWITCH 1.6 (I cannot find any further  
references in jira)?
Could you give me any suggestions where to look in FreeSWITCH source code  
(10k LOC sofia.c seems pretty complex)?

-- 
TMSZ