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

[Victor Chukalovskiy]

Hi Tomasz,

Hi, I was the guy who reported and followed-up on 
https://freeswitch.org/jira/browse/FS-6954

What I recall that it needed to be fixed for a variety of possible 
config call flow scenarios, that can be represented as 3 independent 
factors:

Factor 1 - whether FS is in proxy_media, bypass_media, or default full 
media mode. (3 options)
Factor 2 - direction in which t.38 reINVITE flows (A --> B or B --> A). 
(2 options)
Factor 3 - whether A leg of the call and B leg of the call is the same 
SIP profile or two different SIP profiles. (2 options)

So, you have a matrix representing possible scenarios based on these 3 
independent factors...So, you have at least 3 x 2 x 2 = 12 distinct 
cases to test. Bugfixes were done for some of them, but there were some 
cases left where bug fix was never complete, at least not until I 
gave-up on that JIRA. I'd imagine cases that were fixed made it's way to 
1.6, while cases that were not fixed can still be in the same state.

If you want to be confident about current state, I'd recommend getting 
1.6 and setting test environment where you can verify each possible 
configuration + call flow scenario.

Cheers,
-Victor

On 16-02-19 02:24 PM, Tomasz Ostrowski wrote:
> 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)?
>