VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
tomasz.o.ostrowski at ... Guest
|
Posted: Fri Feb 19, 2016 2:35 pm Post subject: [Freeswitch-users] Incorrect reply to T.38 re-INVITE |
|
|
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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.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 |
|
Back to top |
|
|
mike at jerris.com Guest
|
Posted: Fri Feb 19, 2016 3:02 pm Post subject: [Freeswitch-users] Incorrect reply to T.38 re-INVITE |
|
|
I think we fixed this in 1.6 already. Give it a try to confirm but i recall this one getting fixed.
Quote: | On Feb 19, 2016, at 2:24 PM, Tomasz Ostrowski <tomasz.o.ostrowski@gmail.com> 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)?
--
TMSZ
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.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
|
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.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 |
|
Back to top |
|
|
victor.chukalovskiy at... Guest
|
Posted: Tue Feb 23, 2016 1:53 pm Post subject: [Freeswitch-users] Incorrect reply to T.38 re-INVITE |
|
|
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:
Quote: | 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)?
|
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.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 |
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|