List Info

Thread: Re: RESEND : CR: OVIL-7DPT56 : Helix fails toreconnectto WLAN AP




Re: RESEND : CR: OVIL-7DPT56 : Helix fails toreconnectto WLAN AP
country flaguser name
United States
2008-05-01 12:38:13
No, with RDTv2/3 there is no means of identifying packets
belonging
to different sessions.

rajesh.rathinasamynokia.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-bounceshelixcommunity.org 
>> [mailto:protocol-dev-bounceshelixcommunity.org] On
Behalf Of 
>> ext Eric Hyche
>> Sent: Thursday, May 01, 2008 8:51 AM
>> To: Nadagoudar Ashwinkrishna.1
(EXT-InfoVision-MSW/Dallas); 
>> protocol-devhelixcommunity.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 (ehychereal.com)
>> Technical Lead
>> RealNetworks, Inc.  
>>
>>> -----Original Message-----
>>> From: protocol-dev-bounceshelixcommunity.org
>>> [mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of 
>>> ext-ashwinkrishna.1.nadagoudarnokia.com
>>> Sent: Thursday, May 01, 2008 9:00 AM
>>> To: protocol-devhelixcommunity.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-devhelixcommunity.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.Nadagoudarnokia.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-devhelixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
>>
> 
> _______________________________________________
> Protocol-dev mailing list
> Protocol-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

RE: RESEND : CR: OVIL-7DPT56 : Helix fails toreconnectto WLAN AP
user name
2008-05-01 12:48:45
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:jgordonreal.com]

>Sent: Thursday, May 01, 2008 12:38 PM
>To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas)
>Cc: ehychereal.com; Nadagoudar Ashwinkrishna.1 
>(EXT-InfoVision-MSW/Dallas); protocol-devhelixcommunity.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.rathinasamynokia.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-bounceshelixcommunity.org
>>> [mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of ext 
>>> Eric Hyche
>>> Sent: Thursday, May 01, 2008 8:51 AM
>>> To: Nadagoudar Ashwinkrishna.1
(EXT-InfoVision-MSW/Dallas); 
>>> protocol-devhelixcommunity.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 (ehychereal.com)
>>> Technical Lead
>>> RealNetworks, Inc.  
>>>
>>>> -----Original Message-----
>>>> From: protocol-dev-bounceshelixcommunity.org
>>>> [mailto:protocol-dev-bounceshelixcommunity.org] On Behalf Of 
>>>> ext-ashwinkrishna.1.nadagoudarnokia.com
>>>> Sent: Thursday, May 01, 2008 9:00 AM
>>>> To: protocol-devhelixcommunity.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-devhelixcommunity.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.Nadagoudarnokia.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-devhelixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
>>>
>> 
>> _______________________________________________
>> Protocol-dev mailing list
>> Protocol-devhelixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev
>

_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )