Jamie,
Thanks for clarifying.
So how can we protect ourselves from old session data and
malicious
packets. If a malicious RDT packet is pushed in, it could
mess up the
protocol handling.
Thanks,
Rajesh.
>-----Original Message-----
>From: ext Jamie Gordon [mailto:jgordon real.com]
>Sent: Thursday, May 01, 2008 12:38 PM
>To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas)
>Cc: ehyche real.com; Nadagoudar Ashwinkrishna.1
>(EXT-InfoVision-MSW/Dallas); protocol-dev helixcommunity.org
>Subject: Re: [Protocol-dev] RESEND : CR: OVIL-7DPT56 :
Helix
>fails toreconnectto WLAN AP
>
>No, with RDTv2/3 there is no means of identifying
packets
>belonging to different sessions.
>
>rajesh.rathinasamy nokia.com wrote:
>> Hi Eric,
>> You are right. We need to add this for future
work. The
>current fix
>> will also avoid packets coming in thus not
increasing the
>load on the
>> sockets for the current streaming session.
>>
>> By the way, Does RDT packets have SSRC or any other
means of session
>> identifier ?
>>
>> Thanks,
>> Rajesh.
>>
>>
>>> -----Original Message-----
>>> From: protocol-dev-bounces helixcommunity.org
>>> [mailto:protocol-dev-bounces helixcommunity.org] On Behalf Of ext
>>> Eric Hyche
>>> Sent: Thursday, May 01, 2008 8:51 AM
>>> To: Nadagoudar Ashwinkrishna.1
(EXT-InfoVision-MSW/Dallas);
>>> protocol-dev helixcommunity.org
>>> Subject: RE: [Protocol-dev] RESEND : CR:
OVIL-7DPT56 : Helix fails
>>> toreconnectto WLAN AP
>>>
>>>
>>> This change looks good.
>>>
>>> However, I see this change as more of a
workaround rather than a
>>>real solution. We should have a way of detecting
datagrams from old
>>>sessions and throwing them away at the transport
layer. However, we
>>>can put that down as a to-do item for future
work.
>>>
>>> Eric
>>>
>>> =============================================
>>> Eric Hyche (ehyche real.com)
>>> Technical Lead
>>> RealNetworks, Inc.
>>>
>>>> -----Original Message-----
>>>> From: protocol-dev-bounces helixcommunity.org
>>>> [mailto:protocol-dev-bounces helixcommunity.org] On Behalf Of
>>>> ext-ashwinkrishna.1.nadagoudar nokia.com
>>>> Sent: Thursday, May 01, 2008 9:00 AM
>>>> To: protocol-dev helixcommunity.org
>>>> Subject: [Protocol-dev] RESEND : CR:
OVIL-7DPT56 : Helix fails to
>>>> reconnectto WLAN AP
>>>>
>>>>
>>>>
>>>>
_____________________________________________
>>>> From: Nadagoudar Ashwinkrishna.1
(EXT-InfoVision-MSW/Dallas)
>>>> Sent: Tuesday, April 29, 2008 4:52 PM
>>>> To: 'protocol-dev helixcommunity.org'
>>>> Subject: CR : OVIL-7DPT56 : Helix
fails to
>>>> reconnect to WLAN AP
>>>>
>>>>
>>>> " Nokia submits this
>>>> code under the terms of a commercial
contribution agreement with
>>>> RealNetworks, and I am authorized to
contribute this code
>under said
>>>> agreement."
>>>>
>>>>
>>>> Modified by:
>>>> ext-Ashwinkrishna.1.Nadagoudar nokia.com
>>>>
>>>> Reviewed by:
>>>>
>>>> Date: 04/28/2008
>>>>
>>>> Project: SymbianMmf
>>>>
>>>> ErrorId: OVIL-7DPT56
>>>>
>>>> Synopsis: Helix fails
>>>> to reconnect to WLAN AP
>>>>
>>>> Scenario:
>>>> Walk out of WLAN
>>>> coverage while streaming, wait for the
reconnection query.
>>> Go back to
>>>> WLAN coverage area. Select reconnection.
Audio and Video are not
>>>> regained but Media player still shows
playback progress.
>>>>
>>>> Root Cause of the problem:
>>>> New Helix client is
>>>> initialized after reconnecting to the WLAN.
But there are network
>>>> buffered packets still coming from the old
session along
>>> with the new
>>>> packets to the same ip address( of the
>>>> client) and to the same UDP port.
>>>>
>>>> So both new and old
>>>> packets are getting mixed. This is causing
the problem
>>>>
>>>> Solution:
>>>>
>>>> Choose the UDP port
>>>> dynamically between the specified range so
that after
>>> reconnecting to
>>>> the WLAN , server sends all the new packets
to the new port.
>>>>
>>>> Files Modified:
>>>>
>>>> protocolrtsprtspclnt.cpp
>>>>
>>>> Files Added: None
>>>>
>>>> Image Size and Heap Use
>>>> impact: None
>>>>
>>>> Module Release testing
>>>> (STIF) : Done.
>>>>
>>>> Test case(s) Added : N/A
>>>>
>>>> Memory leak check
>>>> performed : yes. No leak.
>>>>
>>>> Platforms and Profiles
>>>> Build Verified:
helix-client-s60-50-mmf-mdf-arm
>>>>
>>>> Platforms and Profiles
>>>> Functionality verified: armv5, winscw
>>>>
>>>> Branch: Head & 210CayS
>>>>
>>>>
>>>> Index: rtspclnt.cpp
>>>>
>>>>
>========================================================
===========
>>>> RCS file:
/cvsroot/protocol/rtsp/rtspclnt.cpp,v
>>>> retrieving revision 1.182.2.26
>>>> diff -w -u -b -r1.182.2.26 rtspclnt.cpp
>>>> --- rtspclnt.cpp 7 Mar 2008
20:23:17
>>>> -0000 1.182.2.26
>>>> +++ rtspclnt.cpp 29 Apr 2008
18:57:37 -0000
>>>>  -5629,18 +5629,24 
>>>> continue;
>>>> }
>>>>
>>>> - for (datagramPort =
>>>> pUDPPort->uFrom; datagramPort <=
pUDPPort->uTo; datagramPort += 2)
>>>> - {
>>>> +
>>>> datagramPort = (( UINT16
)HX_GET_TICKCOUNT() %
>>>> (pUDPPort->uTo - pUDPPort->uFrom)) +
pUDPPort->uFrom ;
>>>>
>>>>
>>>> if (datagramPort %
2)
>>>> {
>>>> - datagramPort =
>>>> (UINT16)(datagramPort + 1);
>>>> + datagramPort =
(datagramPort + 1);
>>>> }
>>>>
>>>> + for (UINT16 temp = 0;
temp <
>>>> (pUDPPort->uTo - pUDPPort->uFrom) ;
temp += 2, datagramPort += 2)
>>>> + {
>>>> if
((pUDPPort->uTo -
>>> datagramPort + 1) < 2)
>>>> {
>>>> - break;
>>>> +
datagramPort =
>>>> pUDPPort->uFrom ;
>>>> + if
(datagramPort % 2)
>>>> + {
>>>> +
>>>> datagramPort = (datagramPort + 1);
>>>> + }
>>>> }
>>>> +
>>>> HXLOGL3(HXLOG_RTSP,
>>>>
"RTSPClientProtocol[%p]::InitSockets(): trying
%lu...", this,
>>>> datagramPort);
>>>> if (HXR_OK ==
>>>>
CreateUDPSockets(pStreamInfo->m_streamNumber,
>>>> pStreamInfo->m_ulAvgBitRate,
datagramPort))
>>>>
>>>> {
>>>>
>>>> -Ashwin
>>>>
>>>>
>>>
>>>
_______________________________________________
>>> Protocol-dev mailing list
>>> Protocol-dev helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
>>>
>>
>> _______________________________________________
>> Protocol-dev mailing list
>> Protocol-dev helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
>
_______________________________________________
Protocol-dev mailing list
Protocol-dev helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
|