Re: [Linphone-developers] Possible bug in mediastreamer when switching between different video codecs

[Jean-Paul Iribarren]

Hi again, replying to my own message...

As far as I can say, nothing is wrong with Linphone, the bug is actually
in FreeSWITCH, I have been fooled by the fact that I used two different
interfaces. Linphone keeps on sending H.263 compressed video after both
legs have been bridged by FreeSWITCH, and it correctly sets H.263 type
in its RTP tx packets. But FreeSWITCH re-tags the RTP packets received
from Linphone as H.264 without changing the video data (FreeSWITCH has a
passthrough codec for H.26x) before sending them to the caller side...

Therefore, I am going to move the issue to FreeSWITCH lists.

Sorry for the false alarm !
-- 
JPI


Le 30/06/2014 16:50, Jean-Paul Iribarren a écrit :
> Hi Linphone wizards,
>
> First, thank you all for this great piece of software. And now, on for
> the bad news : I think I have found a nasty bug which triggers when
> Linphone switches between two different video modes. I noticed this
> issue with Linphone 3.6.1 (Win32), with msx264 plugin 1.4.3, used on a
> Windows XP Pro/SP3 workstation, but I think it could happen with Linux
> versions as well.
>
> The problem showed up during the following video call scenario: Linphone
> is registered on a FreeSWITCH server as extension 1000. This extension
> is a member of a call center, which can be called by dialing 7002. When
> FreeSWITCH receives an incoming call for (virtual) extension 7002, it
> rings all members of the call center (including 1000), and it plays
> music on hold to the call issuer. When Linphone goes off-hook,
> FreeSWITCH bridges the leg of the incoming call with the leg of
> extension 1000.
>
> Video support is configured as follow:
>
> - preferred video codecs on FreeSWITCH: H.263,H.264 (in this order)
> - caller's video codec: H.264
> - Linphone video codecs: H.264, H.263
>
> Therefore, everybody has H.264 in common.
>
> In this situation, at incoming call time, FreeSWITCH and Linphone
> initially negociate H.263 video. Linphone logs the following messages
> regarding its video filters stack:
>
>     message: ms_filter_link: MSDsCap:021AB0D8,0-->MSPixConv:021A4C90,0
>     message: ms_filter_link: MSPixConv:021A4C90,0-->MSSizeConv:0219BB38,0
>     message: ms_filter_link: MSSizeConv:0219BB38,0-->MSTee:021CE170,0
>     message: ms_filter_link: MSTee:021CE170,0-->MSH263Enc:021A13B0,0
>     message: ms_filter_link: MSH263Enc:021A13B0,0-->MSRtpSend:0184BD90,0
>
>     message: ms_filter_link: MSRtpRecv:02169FB0,0-->MSH263OldDec:02169FE8,0
>     message: ms_filter_link: MSH263OldDec:02169FE8,0-->MSTee:021EF310,0
>     message: ms_filter_link: MSTee:021EF310,1-->MSJpegWriter:021EF280,0
>     message: ms_filter_link: MSTee:021EF310,0-->MSDrawDibDisplay:021A86C8,0
>     message: ms_filter_link: MSTee:021CE170,1-->MSDrawDibDisplay:021A86C8,1
>
> Later, when connecting legs, Linphone notices that it must switch from
> H.263 to H.264 to exchange data with the remote end, and it logs the
> following messages (and nothing else) regarding stack reconfiguration:
>
>     message: ms_filter_unlink:
> MSRtpRecv:02169FB0,0-->MSH263OldDec:02169FE8,0
>     message: ms_filter_unlink: MSH263OldDec:02169FE8,0-->MSTee:021EF310,0
>     message: ms_filter_link: MSRtpRecv:02169FB0,0-->MSH264Dec:02B1FC00,0
>     message: ms_filter_link: MSH264Dec:02B1FC00,0-->MSTee:021EF310,0
>
> After these steps, Linphone receives and displays correctly the H.264
> video flow sent by the caller, but it keeps on sending H.263 video
> *while pretending it is H.264 at RTP level*. Therefore, the remote end
> is unable to decode and display the video flow sent by Linphone.
>
> I noticed this problem when using Linphone with FreeSWITCH, but I
> suppose it could happen in any situation where Linphone (actually,
> mediastreamer) must switch from one video mode to another at answer time
> (what about audio? Perhaps the same issue exists).
>
> Many thanks in advance for having a look.

--