From rajesh.rathinasamy at nokia.com Wed Apr 2 11:04:32 2008
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Wed Apr 2 10:04:27 2008
Subject: [Protocol-dev] Rate adaptation & Helix 11 server
Message-ID: <78988A0C817D8B4F9734DE8EFCEA6F6701560DC6@daebe104.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: RateAdaptation.zip
Type: application/x-zip-compressed
Size: 495140 bytes
Desc: RateAdaptation.zip
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080402/678bf4ae/RateAdaptation-0001.bin
From jojo786 at gmail.com Fri Apr 4 08:27:21 2008
From: jojo786 at gmail.com (Yusuf Mayet)
Date: Fri Apr 4 07:26:19 2008
Subject: [Protocol-dev] OT: Does youtube mobile app use RTSP
Message-ID: <6710801c0804040827u6049f10bk80c016fbd5c8cd8c@mail.gmail.com>
Hi guys,
this might be very Off-Topic, but I dont know where else to turn.
The youtube mobile application on my N95 is not working, just times
out when trying to play, says cannot connect to Streaming Server.
To debug it, I have set my laptop wifi point in ad-hoc mode, connected
the phone to it, then got a 3g card in the laptop, and running
wireshark
However, in the debug, I dont see any RTSP, or any UDP of any kind.
Does anybody know better than I do?
--
thanks,
Yusuf
From Ashish.As.Gupta at nokia.com Fri Apr 4 10:29:05 2008
From: Ashish.As.Gupta at nokia.com (Ashish.As.Gupta@nokia.com)
Date: Fri Apr 4 09:28:25 2008
Subject: [Protocol-dev] OT: Does youtube mobile app use RTSP
In-Reply-To: <6710801c0804040827u6049f10bk80c016fbd5c8cd8c@mail.gmail.com>
Message-ID: <60A427E0B02CC34B98D22BDCAA2536120567EE05@daebe101.NOE.Nokia.com>
Hi,
I would point the browser to m.youtube.com to see if video can be
streamed from here. It will use RTSP in this case. This will make sure
that streaming is working fine first.
Ashish
-----Original Message-----
From: protocol-dev-bounces@helixcommunity.org
[mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of ext Yusuf
Mayet
Sent: Friday, April 04, 2008 10:27 AM
To: protocol-dev@helixcommunity.org
Subject: [Protocol-dev] OT: Does youtube mobile app use RTSP
Hi guys,
this might be very Off-Topic, but I dont know where else to turn.
The youtube mobile application on my N95 is not working, just times out
when trying to play, says cannot connect to Streaming Server.
To debug it, I have set my laptop wifi point in ad-hoc mode, connected
the phone to it, then got a 3g card in the laptop, and running wireshark
However, in the debug, I dont see any RTSP, or any UDP of any kind.
Does anybody know better than I do?
--
thanks,
Yusuf
_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
From jojo786 at gmail.com Mon Apr 7 07:58:49 2008
From: jojo786 at gmail.com (Yusuf Mayet)
Date: Mon Apr 7 06:57:02 2008
Subject: [Protocol-dev] OT: Does youtube mobile app use RTSP
In-Reply-To: <60A427E0B02CC34B98D22BDCAA2536120567EE05@daebe101.NOE.Nokia.com>
References: <6710801c0804040827u6049f10bk80c016fbd5c8cd8c@mail.gmail.com>
<60A427E0B02CC34B98D22BDCAA2536120567EE05@daebe101.NOE.Nokia.com>
Message-ID: <6710801c0804070758y31e4c38amfb8636ebf3dbd941@mail.gmail.com>
Hi,
I know m.youtube uses RTSP, I have confirmed it via the wireshark dumps.
I want to know whether anybody has done a protocol anaylsis of the
youtube mobile application.
On Fri, Apr 4, 2008 at 7:29 PM, wrote:
> Hi,
> I would point the browser to m.youtube.com to see if video can be
> streamed from here. It will use RTSP in this case. This will make sure
> that streaming is working fine first.
>
> Ashish
>
>
> -----Original Message-----
> From: protocol-dev-bounces@helixcommunity.org
> [mailto:protocol-dev-bounces@helixcommunity.org] On Behalf Of ext Yusuf
> Mayet
> Sent: Friday, April 04, 2008 10:27 AM
> To: protocol-dev@helixcommunity.org
> Subject: [Protocol-dev] OT: Does youtube mobile app use RTSP
>
> Hi guys,
>
> this might be very Off-Topic, but I dont know where else to turn.
> The youtube mobile application on my N95 is not working, just times out
> when trying to play, says cannot connect to Streaming Server.
> To debug it, I have set my laptop wifi point in ad-hoc mode, connected
> the phone to it, then got a 3g card in the laptop, and running wireshark
> However, in the debug, I dont see any RTSP, or any UDP of any kind.
> Does anybody know better than I do?
>
> --
>
> thanks,
> Yusuf
>
> _______________________________________________
> Protocol-dev mailing list
> Protocol-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
>
--
thanks,
Yusuf
From Shy.Ward at nokia.com Wed Apr 16 07:42:24 2008
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Wed Apr 16 06:42:05 2008
Subject: [Protocol-dev] CR: Fix Crash for Streaming via YouTube application
when HTTP/1.0 302 Redirect is Received
Message-ID: <0265888D9A65AC4E87B50F72993F81360166428C@daebe104.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: protocol.diff
Type: application/octet-stream
Size: 2321 bytes
Desc: protocol.diff
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080416/e63c2ed4/protocol.obj
From ehyche at real.com Wed Apr 16 08:06:54 2008
From: ehyche at real.com (Eric Hyche)
Date: Wed Apr 16 07:02:47 2008
Subject: [Protocol-dev] CR: Fix Crash for Streaming via YouTube
applicationwhen HTTP/1.0 302 Redirect is Received
In-Reply-To: <0265888D9A65AC4E87B50F72993F81360166428C@daebe104.NOE.Nokia.com>
References: <0265888D9A65AC4E87B50F72993F81360166428C@daebe104.NOE.Nokia.com>
Message-ID: <009201c89fd3$82ceb5c0$db68a8c0@EHYCHED620>
This change looks good to me.
=============================================
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
> Shy.Ward@nokia.com
> Sent: Wednesday, April 16, 2008 10:42 AM
> To: protocol-dev@helixcommunity.org
> Cc: I-Chin.Yu@nokia.com
> Subject: [Protocol-dev] CR: Fix Crash for Streaming via
> YouTube applicationwhen HTTP/1.0 302 Redirect is Received
>
> "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: shy.ward@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
> Date: 15-April-2008
>
> Project: SymbianMmf_Rel
> TSW: MFAE-7DDB8X
>
> Synopsis: Fix Crash for Streaming via YouTube application
> when HTTP/1.0 302 Redirect is Received
> Overview: When no UDP data is received from the Google server
> we switch transport and we get an HTTP redirect and this
> introduces a memory corruption when we are deleted. Basically
> a buffer is being deleted twice. The fix is already in the
> HEAD branch. Also made all buffer creation to be from CCF.
>
> Files Modified:
>
> /cvsroot/protocol/common/util/hxcloakedsocket.cpp
> Image Size and Heap Use impact: None
>
> Module Release testing (STIF) : Pass, Streaming Cases only
>
> Test case(s) Added : No
> Memory leak check performed : No new leaks introduced.
> Platforms and Profiles Build Verified:
> Profile -> helix-client-s60-32-mmf-mdf-arm
> BIF branch -> helix_restricted
> SYSTEM_ID -> symbian-91-armv5
> Target -> symbianMmf_rel
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Cays_2_1_0, Cays_2_2_1
> <>
>
>
From Shy.Ward at nokia.com Wed Apr 16 08:28:37 2008
From: Shy.Ward at nokia.com (Shy.Ward@nokia.com)
Date: Wed Apr 16 07:25:18 2008
Subject: [Protocol-dev] CN: Fix Crash for Streaming via YouTube
applicationwhen HTTP/1.0 302 Redirect is Received
In-Reply-To: <009201c89fd3$82ceb5c0$db68a8c0@EHYCHED620>
References: <0265888D9A65AC4E87B50F72993F81360166428C@daebe104.NOE.Nokia.com>
<009201c89fd3$82ceb5c0$db68a8c0@EHYCHED620>
Message-ID: <0265888D9A65AC4E87B50F72993F81360166432C@daebe104.NOE.Nokia.com>
Check into Cays_2_1_0 & Cays_2_2_1
Thanks,
Shy;
-----Original Message-----
From: ext Eric Hyche [mailto:ehyche@real.com]
Sent: Wednesday, April 16, 2008 10:07 AM
To: Ward Shy (Nokia-D-MSW/Dallas); protocol-dev@helixcommunity.org
Cc: Yu I-Chin (Nokia-D-MSW/Dallas)
Subject: RE: [Protocol-dev] CR: Fix Crash for Streaming via YouTube
applicationwhen HTTP/1.0 302 Redirect is Received
This change looks good to me.
=============================================
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
> Shy.Ward@nokia.com
> Sent: Wednesday, April 16, 2008 10:42 AM
> To: protocol-dev@helixcommunity.org
> Cc: I-Chin.Yu@nokia.com
> Subject: [Protocol-dev] CR: Fix Crash for Streaming via YouTube
> applicationwhen HTTP/1.0 302 Redirect is Received
>
> "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: shy.ward@nokia.com
>
> Reviewed by: rajesh.rathinasamy@nokia.com
> Date: 15-April-2008
>
> Project: SymbianMmf_Rel
> TSW: MFAE-7DDB8X
>
> Synopsis: Fix Crash for Streaming via YouTube application when
> HTTP/1.0 302 Redirect is Received
> Overview: When no UDP data is received from the Google server we
> switch transport and we get an HTTP redirect and this introduces a
> memory corruption when we are deleted. Basically a buffer is being
> deleted twice. The fix is already in the HEAD branch. Also made all
> buffer creation to be from CCF.
>
> Files Modified:
>
> /cvsroot/protocol/common/util/hxcloakedsocket.cpp
> Image Size and Heap Use impact: None
>
> Module Release testing (STIF) : Pass, Streaming Cases only
>
> Test case(s) Added : No
> Memory leak check performed : No new leaks introduced.
> Platforms and Profiles Build Verified:
> Profile -> helix-client-s60-32-mmf-mdf-arm BIF branch ->
> helix_restricted SYSTEM_ID -> symbian-91-armv5 Target ->
> symbianMmf_rel
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: Cays_2_1_0, Cays_2_2_1
> <>
>
>
From rajesh.rathinasamy at nokia.com Sun Apr 20 08:56:19 2008
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Sun Apr 20 07:51:22 2008
Subject: [Protocol-dev] CR: Fix for packet drops if src address is different
from RTSP server address.
Message-ID: <78988A0C817D8B4F9734DE8EFCEA6F67016AEB28@daebe104.NOE.Nokia.com>
> "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: rajesh.rathinasamy@nokia.com
>
> Reviewed by:
>
> Date: 20-Apr-2008
>
> Project: SymbianMmf_rel
>
> ErrorId: AMAI-7DR6D5
>
> Synopsis: CR: Fix for packet drops if src address is different from
> RTSP server address.
>
> Some server setup could result in Media data transmitted from
> different ip than the connected RTSP server.
> RTSP Client session drops the packets if it is from source other than
> RTSP server.
>
> The source address is informed to the client via "Source" header on
> setup response. Added additional check to see if source address is
> sent.
> If source address is sent on setup response, client will use that else
> it will use the rtsp server address.
>
> Limitation:
> If streams are coming from different ip address (like strm 1 from ip1
> and strm 2 from ip2), some stream's packets could be dropped as the
> peer address check is done from rtspclient session.
> Ideal solution would be to query peer address from each transport and
> make the validation.
> This is a rare server setup case and considering the schedule, this is
> not handled now.
>
> Root Cause of the problem: Implementation
>
> Files Modified:
> ===========
> protocol\rtsp\rtspclnt.cpp
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Passed. (Streaming only, no impact on
> local)
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes, No new leaks introduced
>
> Platforms and Profiles Build Verified: helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 221Cays, 210CayS, Head
>
>
> Index: rtspclnt.cpp
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
> retrieving revision 1.182.2.25.2.1
> diff -w -u -b -r1.182.2.25.2.1 rtspclnt.cpp
> --- rtspclnt.cpp 7 Mar 2008 20:03:49 -0000 1.182.2.25.2.1
> +++ rtspclnt.cpp 20 Apr 2008 15:21:53 -0000
> @@ -6276,9 +6276,19 @@
>
> if (pTrans)
> {
> - // make sure the unicast packets received are coming from
> the same server
> - // we are connecting to
> - if ((pSource->IsEqualAddr(m_pConnectAddr)) || bMCastPort)
> + // make sure the unicast packets received are coming from
> the server
> + // sent in source field of setup response. If source
> field is not mentioned,
> + // from addr shall be validated against connected addr
> + //
> + // Please note that if source ip is different for diff
> streams, then
> + // the packets could be dropped for some streams.
> + //
> + // TODO: Move the check for peer address inside the
> transport ( OR )
> + // Obtain the peer address from the respective
> transport here.
> + //
> + if ( ( (m_pPeerAddr != NULL) &&
> pSource->IsEqualAddr(m_pPeerAddr) ) ||
> + ( (m_pConnectAddr != NULL) &&
> pSource->IsEqualAddr(m_pConnectAddr) ) ||
> + (bMCastPort) )
> {
> ReportSuccessfulTransport();
>
> @@ -6296,6 +6306,10 @@
> }
> }
> }
> + else
> + {
> + HXLOGL2(HXLOG_RTSP,
> "RTSPClientProtocol[%p]::handleSetupResponseExt(): Src address
> mismatch", this );
> + }
> }
> else
> {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080420/d66475c4/attachment-0001.html
From ehyche at real.com Mon Apr 21 06:21:57 2008
From: ehyche at real.com (Eric Hyche)
Date: Mon Apr 21 05:16:39 2008
Subject: [Protocol-dev] CR: Fix for packet drops if src address is
differentfrom RTSP server address.
In-Reply-To: <78988A0C817D8B4F9734DE8EFCEA6F67016AEB28@daebe104.NOE.Nokia.com>
References: <78988A0C817D8B4F9734DE8EFCEA6F67016AEB28@daebe104.NOE.Nokia.com>
Message-ID: <004701c8a3b2$ad80ba60$db68a8c0@EHYCHED620>
Looks good.
=============================================
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
> rajesh.rathinasamy@nokia.com
> Sent: Sunday, April 20, 2008 11:56 AM
> To: protocol-dev@helixcommunity.org
> Subject: [Protocol-dev] CR: Fix for packet drops if src
> address is differentfrom RTSP server address.
>
>
>
> "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: rajesh.rathinasamy@nokia.com
>
> Reviewed by:
>
> Date: 20-Apr-2008
>
> Project: SymbianMmf_rel
>
> ErrorId: AMAI-7DR6D5
>
> Synopsis: CR: Fix for packet drops if src address is
> different from RTSP server address.
>
> Some server setup could result in Media data
> transmitted from different ip than the connected RTSP server.
> RTSP Client session drops the packets if it is from
> source other than RTSP server.
>
> The source address is informed to the client via
> "Source" header on setup response. Added additional check to
> see if source address is sent.
>
> If source address is sent on setup response, client
> will use that else it will use the rtsp server address.
>
> Limitation:
> If streams are coming from different ip address (like
> strm 1 from ip1 and strm 2 from ip2), some stream's packets
> could be dropped as the peer address check is done from
> rtspclient session.
>
> Ideal solution would be to query peer address from each
> transport and make the validation.
> This is a rare server setup case and considering the
> schedule, this is not handled now.
>
> Root Cause of the problem: Implementation
>
> Files Modified:
> ===========
> protocol\rtsp\rtspclnt.cpp
>
> Image Size and Heap Use impact: no major impact
>
> Module Release testing (STIF) : Passed. (Streaming
> only, no impact on local)
>
> Test case(s) Added : No.
>
> Memory leak check performed : Yes, No new leaks introduced
>
> Platforms and Profiles Build Verified:
> helix-client-s60-32-mmf-mdf-arm
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 221Cays, 210CayS, Head
>
>
> Index: rtspclnt.cpp
>
> ===================================================================
> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
> retrieving revision 1.182.2.25.2.1
> diff -w -u -b -r1.182.2.25.2.1 rtspclnt.cpp
> --- rtspclnt.cpp 7 Mar 2008 20:03:49 -0000
> 1.182.2.25.2.1
> +++ rtspclnt.cpp 20 Apr 2008 15:21:53 -0000
> @@ -6276,9 +6276,19 @@
>
> if (pTrans)
> {
> - // make sure the unicast packets received
> are coming from the same server
> - // we are connecting to
> - if ((pSource->IsEqualAddr(m_pConnectAddr))
> || bMCastPort)
> + // make sure the unicast packets received
> are coming from the server
> + // sent in source field of setup response.
> If source field is not mentioned,
> + // from addr shall be validated against
> connected addr
> + //
> + // Please note that if source ip is
> different for diff streams, then
> + // the packets could be dropped for some streams.
> + //
> + // TODO: Move the check for peer address
> inside the transport ( OR )
> + // Obtain the peer address from the
> respective transport here.
> + //
> + if ( ( (m_pPeerAddr != NULL) &&
> pSource->IsEqualAddr(m_pPeerAddr) ) ||
> + ( (m_pConnectAddr != NULL) &&
> pSource->IsEqualAddr(m_pConnectAddr) ) ||
> + (bMCastPort) )
> {
> ReportSuccessfulTransport();
>
> @@ -6296,6 +6306,10 @@
> }
> }
> }
> + else
> + {
> + HXLOGL2(HXLOG_RTSP,
> "RTSPClientProtocol[%p]::handleSetupResponseExt(): Src
> address mismatch", this );
> + }
> }
> else
> {
>
>
From rajesh.rathinasamy at nokia.com Mon Apr 21 11:54:03 2008
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Apr 21 10:49:19 2008
Subject: [Protocol-dev] CR: Fix for packet drops if src address is
differentfrom RTSP server address.
In-Reply-To: <004701c8a3b2$ad80ba60$db68a8c0@EHYCHED620>
References: <78988A0C817D8B4F9734DE8EFCEA6F67016AEB28@daebe104.NOE.Nokia.com>
<004701c8a3b2$ad80ba60$db68a8c0@EHYCHED620>
Message-ID: <78988A0C817D8B4F9734DE8EFCEA6F67016AF003@daebe104.NOE.Nokia.com>
Thanks Eric !
The changes have been checked into Head, 210CayS, 221CayS.
- Rajesh.
>-----Original Message-----
>From: ext Eric Hyche [mailto:ehyche@real.com]
>Sent: Monday, April 21, 2008 8:22 AM
>To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas);
>protocol-dev@helixcommunity.org
>Subject: RE: [Protocol-dev] CR: Fix for packet drops if src
>address is differentfrom RTSP server address.
>
>
>Looks good.
>
>=============================================
>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
>> rajesh.rathinasamy@nokia.com
>> Sent: Sunday, April 20, 2008 11:56 AM
>> To: protocol-dev@helixcommunity.org
>> Subject: [Protocol-dev] CR: Fix for packet drops if src address is
>> differentfrom RTSP server address.
>>
>>
>>
>> "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: rajesh.rathinasamy@nokia.com
>>
>> Reviewed by:
>>
>> Date: 20-Apr-2008
>>
>> Project: SymbianMmf_rel
>>
>> ErrorId: AMAI-7DR6D5
>>
>> Synopsis: CR: Fix for packet drops if src address is
>different from
>> RTSP server address.
>>
>> Some server setup could result in Media data transmitted from
>> different ip than the connected RTSP server.
>> RTSP Client session drops the packets if it is from
>source other than
>> RTSP server.
>>
>> The source address is informed to the client via
>"Source" header on
>> setup response. Added additional check to see if source address is
>> sent.
>>
>> If source address is sent on setup response, client
>will use that
>> else it will use the rtsp server address.
>>
>> Limitation:
>> If streams are coming from different ip address (like
>strm 1 from ip1
>> and strm 2 from ip2), some stream's packets could be dropped as the
>> peer address check is done from rtspclient session.
>>
>> Ideal solution would be to query peer address from each
>transport and
>> make the validation.
>> This is a rare server setup case and considering the
>schedule, this
>> is not handled now.
>>
>> Root Cause of the problem: Implementation
>>
>> Files Modified:
>> ===========
>> protocol\rtsp\rtspclnt.cpp
>>
>> Image Size and Heap Use impact: no major impact
>>
>> Module Release testing (STIF) : Passed. (Streaming
>only, no impact
>> on local)
>>
>> Test case(s) Added : No.
>>
>> Memory leak check performed : Yes, No new leaks introduced
>>
>> Platforms and Profiles Build Verified:
>> helix-client-s60-32-mmf-mdf-arm
>>
>> Platforms and Profiles Functionality verified: armv5, winscw
>>
>> Branch: 221Cays, 210CayS, Head
>>
>>
>> Index: rtspclnt.cpp
>>
>> ===================================================================
>> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>> retrieving revision 1.182.2.25.2.1
>> diff -w -u -b -r1.182.2.25.2.1 rtspclnt.cpp
>> --- rtspclnt.cpp 7 Mar 2008 20:03:49 -0000
>> 1.182.2.25.2.1
>> +++ rtspclnt.cpp 20 Apr 2008 15:21:53 -0000
>> @@ -6276,9 +6276,19 @@
>>
>> if (pTrans)
>> {
>> - // make sure the unicast packets received
>> are coming from the same server
>> - // we are connecting to
>> - if ((pSource->IsEqualAddr(m_pConnectAddr))
>> || bMCastPort)
>> + // make sure the unicast packets received
>> are coming from the server
>> + // sent in source field of setup response.
>> If source field is not mentioned,
>> + // from addr shall be validated against
>> connected addr
>> + //
>> + // Please note that if source ip is
>> different for diff streams, then
>> + // the packets could be dropped for some streams.
>> + //
>> + // TODO: Move the check for peer address
>> inside the transport ( OR )
>> + // Obtain the peer address from the
>> respective transport here.
>> + //
>> + if ( ( (m_pPeerAddr != NULL) &&
>> pSource->IsEqualAddr(m_pPeerAddr) ) ||
>> + ( (m_pConnectAddr != NULL) &&
>> pSource->IsEqualAddr(m_pConnectAddr) ) ||
>> + (bMCastPort) )
>> {
>> ReportSuccessfulTransport();
>>
>> @@ -6296,6 +6306,10 @@
>> }
>> }
>> }
>> + else
>> + {
>> + HXLOGL2(HXLOG_RTSP,
>> "RTSPClientProtocol[%p]::handleSetupResponseExt(): Src address
>> mismatch", this );
>> + }
>> }
>> else
>> {
>>
>>
>
>
From rmathew at real.com Mon Apr 21 12:24:05 2008
From: rmathew at real.com (Rishi Mathew)
Date: Mon Apr 21 11:18:50 2008
Subject: [Protocol-dev] CR: Fix for packet drops if src address is
differentfrom RTSP server address.
In-Reply-To: <78988A0C817D8B4F9734DE8EFCEA6F67016AF003@daebe104.NOE.Noki a.com>
References: <78988A0C817D8B4F9734DE8EFCEA6F67016AEB28@daebe104.NOE.Nokia.com>
<004701c8a3b2$ad80ba60$db68a8c0@EHYCHED620>
<78988A0C817D8B4F9734DE8EFCEA6F67016AF003@daebe104.NOE.Nokia.com>
Message-ID: <6.2.1.2.2.20080421122322.03e4ea30@mailone.real.com>
Please also commit to 310_atlas for all cross-platform code moving forward.
Cheers,
Rishi.
At 11:54 AM 4/21/2008, rajesh.rathinasamy@nokia.com wrote:
>Thanks Eric !
>
>The changes have been checked into Head, 210CayS, 221CayS.
>
>- Rajesh.
>
>
> >-----Original Message-----
> >From: ext Eric Hyche [mailto:ehyche@real.com]
> >Sent: Monday, April 21, 2008 8:22 AM
> >To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas);
> >protocol-dev@helixcommunity.org
> >Subject: RE: [Protocol-dev] CR: Fix for packet drops if src
> >address is differentfrom RTSP server address.
> >
> >
> >Looks good.
> >
> >=============================================
> >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
> >> rajesh.rathinasamy@nokia.com
> >> Sent: Sunday, April 20, 2008 11:56 AM
> >> To: protocol-dev@helixcommunity.org
> >> Subject: [Protocol-dev] CR: Fix for packet drops if src address is
> >> differentfrom RTSP server address.
> >>
> >>
> >>
> >> "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: rajesh.rathinasamy@nokia.com
> >>
> >> Reviewed by:
> >>
> >> Date: 20-Apr-2008
> >>
> >> Project: SymbianMmf_rel
> >>
> >> ErrorId: AMAI-7DR6D5
> >>
> >> Synopsis: CR: Fix for packet drops if src address is
> >different from
> >> RTSP server address.
> >>
> >> Some server setup could result in Media data transmitted from
> >> different ip than the connected RTSP server.
> >> RTSP Client session drops the packets if it is from
> >source other than
> >> RTSP server.
> >>
> >> The source address is informed to the client via
> >"Source" header on
> >> setup response. Added additional check to see if source address is
> >> sent.
> >>
> >> If source address is sent on setup response, client
> >will use that
> >> else it will use the rtsp server address.
> >>
> >> Limitation:
> >> If streams are coming from different ip address (like
> >strm 1 from ip1
> >> and strm 2 from ip2), some stream's packets could be dropped as the
> >> peer address check is done from rtspclient session.
> >>
> >> Ideal solution would be to query peer address from each
> >transport and
> >> make the validation.
> >> This is a rare server setup case and considering the
> >schedule, this
> >> is not handled now.
> >>
> >> Root Cause of the problem: Implementation
> >>
> >> Files Modified:
> >> ===========
> >> protocol\rtsp\rtspclnt.cpp
> >>
> >> Image Size and Heap Use impact: no major impact
> >>
> >> Module Release testing (STIF) : Passed. (Streaming
> >only, no impact
> >> on local)
> >>
> >> Test case(s) Added : No.
> >>
> >> Memory leak check performed : Yes, No new leaks introduced
> >>
> >> Platforms and Profiles Build Verified:
> >> helix-client-s60-32-mmf-mdf-arm
> >>
> >> Platforms and Profiles Functionality verified: armv5, winscw
> >>
> >> Branch: 221Cays, 210CayS, Head
> >>
> >>
> >> Index: rtspclnt.cpp
> >>
> >> ===================================================================
> >> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
> >> retrieving revision 1.182.2.25.2.1
> >> diff -w -u -b -r1.182.2.25.2.1 rtspclnt.cpp
> >> --- rtspclnt.cpp 7 Mar 2008 20:03:49 -0000
> >> 1.182.2.25.2.1
> >> +++ rtspclnt.cpp 20 Apr 2008 15:21:53 -0000
> >> @@ -6276,9 +6276,19 @@
> >>
> >> if (pTrans)
> >> {
> >> - // make sure the unicast packets received
> >> are coming from the same server
> >> - // we are connecting to
> >> - if ((pSource->IsEqualAddr(m_pConnectAddr))
> >> || bMCastPort)
> >> + // make sure the unicast packets received
> >> are coming from the server
> >> + // sent in source field of setup response.
> >> If source field is not mentioned,
> >> + // from addr shall be validated against
> >> connected addr
> >> + //
> >> + // Please note that if source ip is
> >> different for diff streams, then
> >> + // the packets could be dropped for some streams.
> >> + //
> >> + // TODO: Move the check for peer address
> >> inside the transport ( OR )
> >> + // Obtain the peer address from the
> >> respective transport here.
> >> + //
> >> + if ( ( (m_pPeerAddr != NULL) &&
> >> pSource->IsEqualAddr(m_pPeerAddr) ) ||
> >> + ( (m_pConnectAddr != NULL) &&
> >> pSource->IsEqualAddr(m_pConnectAddr) ) ||
> >> + (bMCastPort) )
> >> {
> >> ReportSuccessfulTransport();
> >>
> >> @@ -6296,6 +6306,10 @@
> >> }
> >> }
> >> }
> >> + else
> >> + {
> >> + HXLOGL2(HXLOG_RTSP,
> >> "RTSPClientProtocol[%p]::handleSetupResponseExt(): Src address
> >> mismatch", this );
> >> + }
> >> }
> >> else
> >> {
> >>
> >>
> >
> >
>
>_______________________________________________
>Protocol-dev mailing list
>Protocol-dev@helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Helix Community
RealNetworks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080421/576c510c/attachment-0001.html
From rajesh.rathinasamy at nokia.com Mon Apr 21 13:01:36 2008
From: rajesh.rathinasamy at nokia.com (rajesh.rathinasamy@nokia.com)
Date: Mon Apr 21 11:56:33 2008
Subject: [Protocol-dev] CR: Fix for packet drops if src address is
differentfrom RTSP server address.
In-Reply-To: <6.2.1.2.2.20080421122322.03e4ea30@mailone.real.com>
References: <78988A0C817D8B4F9734DE8EFCEA6F67016AEB28@daebe104.NOE.Nokia.com>
<004701c8a3b2$ad80ba60$db68a8c0@EHYCHED620>
<78988A0C817D8B4F9734DE8EFCEA6F67016AF003@daebe104.NOE.Nokia.com>
<6.2.1.2.2.20080421122322.03e4ea30@mailone.real.com>
Message-ID: <78988A0C817D8B4F9734DE8EFCEA6F67016AF0C7@daebe104.NOE.Nokia.com>
Rishi,
Changes have been checked into 310_Atlas.
- Rajesh.
________________________________
From: ext Rishi Mathew [mailto:rmathew@real.com]
Sent: Monday, April 21, 2008 2:24 PM
To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas); ehyche@real.com;
protocol-dev@helixcommunity.org
Subject: RE: [Protocol-dev] CR: Fix for packet drops if src
address is differentfrom RTSP server address.
Please also commit to 310_atlas for all cross-platform code
moving forward.
Cheers,
Rishi.
At 11:54 AM 4/21/2008, rajesh.rathinasamy@nokia.com wrote:
Thanks Eric !
The changes have been checked into Head, 210CayS,
221CayS.
- Rajesh.
>-----Original Message-----
>From: ext Eric Hyche [ mailto:ehyche@real.com
]
>Sent: Monday, April 21, 2008 8:22 AM
>To: Rathinasamy Rajesh (Nokia-D-MSW/Dallas);
>protocol-dev@helixcommunity.org
>Subject: RE: [Protocol-dev] CR: Fix for packet drops if
src
>address is differentfrom RTSP server address.
>
>
>Looks good.
>
>=============================================
>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
>> rajesh.rathinasamy@nokia.com
>> Sent: Sunday, April 20, 2008 11:56 AM
>> To: protocol-dev@helixcommunity.org
>> Subject: [Protocol-dev] CR: Fix for packet drops if
src address is
>> differentfrom RTSP server address.
>>
>>
>>
>> "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: rajesh.rathinasamy@nokia.com
>>
>> Reviewed by:
>>
>> Date: 20-Apr-2008
>>
>> Project: SymbianMmf_rel
>>
>> ErrorId: AMAI-7DR6D5
>>
>> Synopsis: CR: Fix for packet drops if src
address is
>different from
>> RTSP server address.
>>
>> Some server setup could result in Media data
transmitted from
>> different ip than the connected RTSP server.
>> RTSP Client session drops the packets if it is
from
>source other than
>> RTSP server.
>>
>> The source address is informed to the client via
>"Source" header on
>> setup response. Added additional check to see if
source address is
>> sent.
>>
>> If source address is sent on setup response,
client
>will use that
>> else it will use the rtsp server address.
>>
>> Limitation:
>> If streams are coming from different ip address
(like
>strm 1 from ip1
>> and strm 2 from ip2), some stream's packets could be
dropped as the
>> peer address check is done from rtspclient session.
>>
>> Ideal solution would be to query peer address
from each
>transport and
>> make the validation.
>> This is a rare server setup case and considering
the
>schedule, this
>> is not handled now.
>>
>> Root Cause of the problem: Implementation
>>
>> Files Modified:
>> ===========
>> protocol\rtsp\rtspclnt.cpp
>>
>> Image Size and Heap Use impact: no major impact
>>
>> Module Release testing (STIF) : Passed.
(Streaming
>only, no impact
>> on local)
>>
>> Test case(s) Added : No.
>>
>> Memory leak check performed : Yes, No new leaks
introduced
>>
>> Platforms and Profiles Build Verified:
>> helix-client-s60-32-mmf-mdf-arm
>>
>> Platforms and Profiles Functionality verified:
armv5, winscw
>>
>> Branch: 221Cays, 210CayS, Head
>>
>>
>> Index: rtspclnt.cpp
>>
>>
===================================================================
>> RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
>> retrieving revision 1.182.2.25.2.1
>> diff -w -u -b -r1.182.2.25.2.1 rtspclnt.cpp
>> --- rtspclnt.cpp 7 Mar 2008 20:03:49
-0000
>> 1.182.2.25.2.1
>> +++ rtspclnt.cpp 20 Apr 2008 15:21:53
-0000
>> @@ -6276,9 +6276,19 @@
>>
>> if (pTrans)
>> {
>> - // make sure the unicast packets
received
>> are coming from the same server
>> - // we are connecting to
>> - if
((pSource->IsEqualAddr(m_pConnectAddr))
>> || bMCastPort)
>> + // make sure the unicast packets
received
>> are coming from the server
>> + // sent in source field of setup
response.
>> If source field is not mentioned,
>> + // from addr shall be validated
against
>> connected addr
>> + //
>> + // Please note that if source ip
is
>> different for diff streams, then
>> + // the packets could be dropped
for some streams.
>> + //
>> + // TODO: Move the check for peer
address
>> inside the transport ( OR )
>> + // Obtain the peer address
from the
>> respective transport here.
>> + //
>> + if ( ( (m_pPeerAddr != NULL) &&
>> pSource->IsEqualAddr(m_pPeerAddr) ) ||
>> + ( (m_pConnectAddr != NULL) &&
>> pSource->IsEqualAddr(m_pConnectAddr) ) ||
>> + (bMCastPort) )
>> {
>> ReportSuccessfulTransport();
>>
>> @@ -6296,6 +6306,10 @@
>> }
>> }
>> }
>> + else
>> + {
>> + HXLOGL2(HXLOG_RTSP,
>> "RTSPClientProtocol[%p]::handleSetupResponseExt():
Src address
>> mismatch", this );
>> + }
>> }
>> else
>> {
>>
>>
>
>
_______________________________________________
Protocol-dev mailing list
Protocol-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Helix Community
Real Networks, Inc.
rmathew@real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080421/485a7872/attachment.html
From ext-anuj.dhamija at nokia.com Tue Apr 22 10:01:28 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Tue Apr 22 08:56:54 2008
Subject: [Protocol-dev] Real Proxy server reacting with RESET when
AutoBandWidthDetection turned ON
Message-ID: <2198383E1141814486F0B881B3260CF502372988@daebe103.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case1.pcap
Type: application/octet-stream
Size: 7538 bytes
Desc: Case1.pcap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080422/e15fe541/Case1-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case2.pcap
Type: application/octet-stream
Size: 13926 bytes
Desc: Case2.pcap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080422/e15fe541/Case2-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Case3.pcap
Type: application/octet-stream
Size: 9608 bytes
Desc: Case3.pcap
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080422/e15fe541/Case3-0001.obj
From ext-anuj.dhamija at nokia.com Tue Apr 22 13:10:50 2008
From: ext-anuj.dhamija at nokia.com (ext-anuj.dhamija@nokia.com)
Date: Tue Apr 22 12:06:30 2008
Subject: [Protocol-dev] Real Proxy server reacting with RESET when
AutoBandWidthDetection turned ON
Message-ID: <2198383E1141814486F0B881B3260CF50237298A@daebe103.NOE.Nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.zip
Type: application/x-zip-compressed
Size: 12551 bytes
Desc: Capture.zip
Url : http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080422/9253a069/Capture.bin
From daudrain at roundbox.com Wed Apr 23 08:28:20 2008
From: daudrain at roundbox.com (David Audrain)
Date: Wed Apr 23 07:22:37 2008
Subject: [Protocol-dev] RTP padding octets
In-Reply-To: <5162542.59531208964124876.JavaMail.root@mailman.roundbox.com>
Message-ID: <2563193.60531208964500731.JavaMail.root@mailman.roundbox.com>
Hi All,
rtptran.cpp analyzes RTP packets but I can not see how the padding bit (RTPPacketBase::padding_flag) is handled.
I would expect rtptran.cpp to check RTPPacketBase::padding_flag, and compute pkt.data.len accordingly.
Could you please tell me if I am missing something regarding those padding octets? Especially when a RTP packet only contains an Access Unit fragement.
Thank you,
David Audrain
Software Engineer
Roundbox International Inc
9 rue de conde
33064 Bordeaux, France
www.roundbox.com
T: +33 556.001.250
F: +33 556.442.351
E: daudrain@roundbox.com
Yahoo: daudrain33
Skype: daudrain33
From ltani at real.com Wed Apr 23 09:42:07 2008
From: ltani at real.com (Leina Tani)
Date: Wed Apr 23 08:36:16 2008
Subject: [Protocol-dev] RE: [Nokia-private-dev] Real Proxy server reacting
with RESET whenAutoBandWidthDetection turned ON
In-Reply-To: <2198383E1141814486F0B881B3260CF50237298A@daebe103.NOE.Nokia.com>
Message-ID: <0f3c01c8a560$f7ea4cb0$c140a8c0@corp.real.com>
Hi,
Anshuman is looking into this and will respond shortly.
Thank you,
-leina
_____
From: nokia-private-dev-bounces@helixcommunity.org
[mailto:nokia-private-dev-bounces@helixcommunity.org] On Behalf Of
ext-anuj.dhamija@nokia.com
Sent: Tuesday, April 22, 2008 1:11 PM
To: protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: [Nokia-private-dev] Real Proxy server reacting with RESET
whenAutoBandWidthDetection turned ON
Hi,
We are finding this problem on one of the sites where streaming sever would
not connect when connected via Real Proxy. It is able to connect and stream
fine when connected directly. IP dump shows that this is due to Proxy
sending a reset back to client that causes connection to fail.
Compared it with a dump where server was able to connect via proxy.
Comparison showed that in the latter case AutoBWDetection is turned off on
server side (turned ON on client by default) whereas in former case (not
working scenario) AutoBWDetection is turned ON on both client and server. So
we tried the first scenario with AutoBWDetection disabled on client and this
worked. So Proxy seems to be sending reset due to one of AutoBWDetection
related message (GET_PARAMETER).
I understand that this is some problem on the Proxy side and it must not
send a TCP RESET in any case.
Still I was wondering if it is correct for Helix to keep AutoBWDetection
enabled by default? Does this parameter have any significance in Wireless
networks? Isnt it relevant only in LAN/WLAN networks?
IPDumps are enclosed.
Case1: Auto BW Detection Cleint:Enable; Server:Enable ==> Not Working
Case2: Auto BW Detection Client:Enable; Sever: Disable ==> Working
Case3: Auto BW Detection Client: Disable; Sever: Enable ==> Working
Comments and suggestions are appreciated.
Thnx & regds
AD
<>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080423/eb204cc4/attachment-0001.html
From asingh at real.com Wed Apr 23 23:56:36 2008
From: asingh at real.com (Anshuman Singh)
Date: Wed Apr 23 22:50:45 2008
Subject: [Protocol-dev] CR: Changes to handle RTP Timestamps after PAUSE
Message-ID: <00b001c8a5d8$58a90510$0b01a8c0@anshuman1>
Skipped content of type multipart/alternative-------------- next part --------------
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.221.2.7
diff -u -r1.221.2.7 rtspclnt.cpp
--- rtspclnt.cpp 21 Apr 2008 20:00:45 -0000 1.221.2.7
+++ rtspclnt.cpp 23 Apr 2008 12:10:08 -0000
@@ -4414,7 +4414,26 @@
m_pMutex->Lock();
- SendMsgToTransport(RESUME_BUFFER);
+ if (!m_transportRequestList.IsEmpty())
+ {
+ RTSPTransportRequest* pRequest =
+ (RTSPTransportRequest*)m_transportRequestList.GetHead();
+ RTSPTransportInfo* pTransInfo = pRequest->getFirstTransportInfo();
+ HXBOOL bUsesWallClockTS = ServerProducesWallClockTS();
+
+ while(pTransInfo)
+ {
+ if (bUsesWallClockTS)
+ {
+ // If we use wall-clock TS, we signal transport to defer processing of incomming packets until timing information
+ // is communicated.
+ pTransInfo->m_pTransport->setPlayRange( RTSP_PLAY_RANGE_BLANK , RTSP_PLAY_RANGE_BLANK , TRUE);
+ }
+ pTransInfo->m_pTransport->resumeBuffers();
+ pTransInfo = pRequest->getNextTransportInfo();
+ }
+ }
+
/*
* Man, iptv, teracast, and darwin server don't like this even though
@@ -6117,7 +6136,48 @@
HXBOOL
RTSPClientProtocol::IsRealServer(void)
{
- return FALSE;
+
+ HXBOOL bRealServer = FALSE;
+ IHXBuffer* pAgent = NULL;
+ IHXKeyValueListIter* pIter= NULL;
+
+ if (m_pResponseHeaders &&
+ SUCCEEDED(m_pResponseHeaders->KeyExists("Server")) &&
+ SUCCEEDED(m_pResponseHeaders->GetIter(pIter)))
+ {
+ char* pp = "Server";
+ while (pIter->GetNextPair(pp , pAgent) == HXR_OK)
+ {
+ if (strstr((const char *)pAgent->GetBuffer(), "RealServer") || strstr((const char *)pAgent->GetBuffer(), "RealMedia"))
+ {
+ bRealServer = TRUE;
+ break;
+ }
+ HX_RELEASE(pAgent);
+ }
+ HX_RELEASE(pAgent);
+ }
+ return bRealServer;
+
+}
+
+HXBOOL
+RTSPClientProtocol::ServerProducesWallClockTS(void)
+{
+ HXBOOL bRetVal = FALSE;
+
+ UINT32 major = HX_GET_MAJOR_VERSION(m_ulServerVersion);
+ UINT32 minor = HX_GET_MINOR_VERSION(m_ulServerVersion);
+ UINT32 release = HX_GET_RELEASE_NUMBER(m_ulServerVersion);
+
+ if (IsRealServer())
+ {
+ if(major >= 11 || ( major == 10 && minor == 0 && (release == 5 || release == 6)))
+ {
+ bRetVal = TRUE;
+ }
+ }
+ return bRetVal;
}
//
@@ -6187,7 +6247,7 @@
{
pTrans->setFirstSeqNum(uStreamNumber, uSeqNum, bOnPauseResume);
}
- else if (RTPINFO_RTPTIME == info)
+ else if ((RTPINFO_RTPTIME == info) && (!bOnPauseResume || !IsRealServer()))
{
pTrans->setFirstTimeStamp(uStreamNumber, ulRTPTime, FALSE, bOnPauseResume);
}
@@ -6979,7 +7039,7 @@
return NONE_SDP;
}
- if (strstr((const char*)pAgent->GetBuffer(), "RealMedia"))
+ if (IsRealServer())
{
sdpType = BACKWARD_COMP_SDP;
}
@@ -7710,7 +7770,7 @@
{
pSeqValue = pRange->getFirstHeaderValue();
- INT32 nFrom = 0, nTo = 0;
+ INT32 nFrom = RTSP_PLAY_RANGE_BLANK, nTo = RTSP_PLAY_RANGE_BLANK;
if (pSeqValue)
{
@@ -7746,10 +7806,10 @@
RTSPTransportInfo* pTransInfo = pRequest->getFirstTransportInfo();
- while(pTransInfo && nTo)
+ while(pTransInfo && (nFrom != RTSP_PLAY_RANGE_BLANK))
{
// set the range in transport...only for RTP
- pTransInfo->m_pTransport->RTSPTransport::setPlayRange((UINT32)nFrom, (UINT32)nTo);
+ pTransInfo->m_pTransport->RTSPTransport::setPlayRange((UINT32)nFrom, (UINT32)nTo,bIsResumeResponse);
pTransInfo = pRequest->getNextTransportInfo();
}
}
-------------- next part --------------
Index: rtptran.h
===================================================================
RCS file: /cvsroot/protocol/transport/rtp/pub/rtptran.h,v
retrieving revision 1.55
diff -u -r1.55 rtptran.h
--- rtptran.h 6 Jul 2007 20:51:42 -0000 1.55
+++ rtptran.h 23 Apr 2008 09:42:28 -0000
@@ -185,7 +185,7 @@
void SetFirstTSLive (RTSPStreamData* pStreamData, UINT32 ulTS, HXBOOL bIsRaw);
void SetFirstTSStatic (RTSPStreamData* pStreamData, UINT32 ulTS, HXBOOL bIsRaw);
- void setPlayRange (UINT32 ulFrom, UINT32 ulTo);
+ virtual void setPlayRange (UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume = FALSE);
HX_RESULT setFirstPlayTime (Timeval* pTv);
void OnPause (Timeval* pTV);
@@ -269,6 +269,7 @@
UINT32 m_ulWaitQueueBytes;
HXBOOL m_bWaitForStartInfo;
HXBOOL m_bAbortWaitForStartInfo;
+ HXBOOL m_bFirstSeqNumLocked;
HXBOOL m_bSSRCDetermined;
UINT32 m_ulSSRCDetermined;
-------------- next part --------------
Index: rtsptran.h
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/pub/rtsptran.h,v
retrieving revision 1.45
diff -u -r1.45 rtsptran.h
--- rtsptran.h 6 Jul 2007 20:51:40 -0000 1.45
+++ rtsptran.h 23 Apr 2008 09:46:29 -0000
@@ -295,7 +295,7 @@
// only in RTPTransport...
virtual void notifyRTPInfoProcessed (HXBOOL bOnPauseResume = FALSE) {}
- virtual void setPlayRange (UINT32 ulFrom, UINT32 ulTo);
+ virtual void setPlayRange (UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume = FALSE);
virtual HX_RESULT setFirstPlayTime (Timeval* pTv) {return HXR_OK;};
virtual void OnPause (Timeval* pTv) { };
virtual void setLegacyRTPLive(void){};
-------------- next part --------------
Index: rtptran.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/rtp/rtptran.cpp,v
retrieving revision 1.111.2.2
diff -u -r1.111.2.2 rtptran.cpp
--- rtptran.cpp 24 Jan 2008 06:49:24 -0000 1.111.2.2
+++ rtptran.cpp 23 Apr 2008 09:40:50 -0000
@@ -474,7 +474,6 @@
// On client we allow setting of sequence number only once not to cause
// havoc in transport buffer
- if (m_bIsSource || (!m_bSeqNoSet))
{
theErr = RTSPTransport::setFirstSeqNum(uStreamNumber, uSeqNum, bOnPauseResume);
@@ -485,11 +484,17 @@
// In the client, we set for start of stream only if there are no more
// pipelined seeks outstanding an this is not a resume request.
- if (m_bIsSource || ((!bOnPauseResume) && (m_ulSeekCount <= 1)))
+ if (m_bIsSource || (m_ulSeekCount <= 1))
{
if (SUCCEEDED(theErr))
{
m_bSeqNoSet = TRUE;
+ m_bAbortWaitForStartInfo = TRUE;
+ if (bOnPauseResume)
+ {
+ m_uFirstSeqNum = uSeqNum;
+ m_bFirstSeqNumLocked = TRUE;
+ }
}
if (m_pReflectorInfo)
@@ -599,13 +604,13 @@
SetFirstTSLive(pStreamData, ulTS, bIsRaw);
}
}
- else if (!m_bRTPTimeSet)
+ else if (bOnPauseResume || !m_bRTPTimeSet)
{
- // If there are outstanding pipelined seeks or this is just a
- // resumption action, we do not set
- // the start time as we wait for the information provided by
+ // If there are outstanding pipelined seeks
+ // we do not set the start time as we wait
+ // for the information provided by
// the last pipelined seek.
- if (bOnPauseResume || (m_ulSeekCount > 1))
+ if (m_ulSeekCount > 1)
{
return;
}
@@ -690,16 +695,21 @@
}
void
-RTPBaseTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo)
+RTPBaseTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume)
{
// this is the Range values in PLAY request in RMA time (ms) called on PLAY
// request
- RTSPTransport::setPlayRange(ulFrom, ulTo);
+ RTSPTransport::setPlayRange(ulFrom, ulTo, bOnPauseResume);
+ m_bWaitForStartInfo = TRUE;
+ m_bAbortWaitForStartInfo = FALSE;
+ m_bFirstSeqNumLocked = FALSE;
+
+
+ if (bOnPauseResume)
+ {
m_bSeqNoSet = FALSE;
m_bRTPTimeSet = FALSE;
- m_bWaitForStartInfo = TRUE;
- m_bAbortWaitForStartInfo = FALSE;
m_uFirstSeqNum = 0;
m_ulFirstRTPTS = 0;
m_bFirstSet = FALSE;
@@ -723,7 +733,7 @@
// re-start information (RTP-Info) arriving for the last
// pipelined seek.
m_ulSeekCount++;
-
+}
HXLOGL3(HXLOG_RTSP, "RTPBaseTransport[%p]::setPlayRange(From=%lu To=%lu) SeekStarted: Strm=%u SeekCount=%lu",
this,
ulFrom,
@@ -1570,7 +1580,10 @@
if (m_StartInfoWaitQueue.GetCount() == 0)
{
// First packet received
- m_uFirstSeqNum = pkt.seq_no;
+ if (!m_bFirstSeqNumLocked)
+ {
+ m_uFirstSeqNum = pkt.seq_no;
+ }
m_ulFirstRTPTS = pkt.timestamp;
// For Live stream, postpone identification of first packet until we get
// a contiguous sequence (some servers have discontinuity on start
@@ -1590,7 +1603,10 @@
// time is not wrapped before 0
if (lSeqNumDelta < 0)
{
- m_uFirstSeqNum = pkt.seq_no;
+ if (!m_bFirstSeqNumLocked)
+ {
+ m_uFirstSeqNum = pkt.seq_no;
+ }
}
else if (!m_bFirstSet)
{
@@ -1598,7 +1614,10 @@
if (lSeqNumDelta > MAX_NUM_PACKETS_GAPPED_FOR_LIVE_START)
{
resetStartInfoWaitQueue();
+ if (!m_bFirstSeqNumLocked)
+ {
m_uFirstSeqNum = pkt.seq_no;
+ }
m_ulFirstRTPTS = pkt.timestamp;
}
else
@@ -1639,17 +1658,8 @@
}
}
- /* If start Info has been at least partially set or the wait has been
- aborted for some reason (usually when we know it will not be set
- through out-of band methods <-> RTP Info did not contain start Info
- we need).
- Also if starting seq. number is not explicitly communicated,
- scan through few starting packets until we have a good starting
- sequence number (contiguous) since some servers send lossy streams
- in the beginning. */
- if (m_bSeqNoSet ||
- (m_bAbortWaitForStartInfo &&
- ((!m_bIsLive) || (m_StartInfoWaitQueue.GetCount() >= MIN_NUM_PACKETS_SCANNED_FOR_LIVE_START))))
+ if (m_bAbortWaitForStartInfo &&
+ ((!m_bIsLive) || (m_StartInfoWaitQueue.GetCount() >= MIN_NUM_PACKETS_SCANNED_FOR_LIVE_START)))
{
IHXBuffer* pStoredBuffer;
if (m_ulPlayRangeFrom == RTSP_PLAY_RANGE_BLANK)
@@ -1668,10 +1678,27 @@
if (pStoredBuffer)
{
- _handlePacket(pStoredBuffer, FALSE);
- pStoredBuffer->Release();
+ if (m_bFirstSeqNumLocked)
+ {
+ // If sequence number is locked, we drop any packet that precedes the locked in sequence number
+ RTPPacket pkt;
+ if (pkt.unpack(pBuffer->GetBuffer(), pBuffer->GetSize()) == 0)
+ {
+ LONG32 lSeqNumDelta = ((LONG32) (((UINT16) pkt.seq_no) - m_uFirstSeqNum));
+ if (lSeqNumDelta < 0)
+ {
+ HX_RELEASE(pStoredBuffer);
+ }
+ }
+ }
+
+ if (pStoredBuffer)
+ {
+ _handlePacket(pStoredBuffer, FALSE);
+ pStoredBuffer->Release();
}
}
+ }
m_ulWaitQueueBytes = 0;
}
-------------- next part --------------
Index: rtsptran.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/rtsptran.cpp,v
retrieving revision 1.54
diff -u -r1.54 rtsptran.cpp
--- rtsptran.cpp 6 Jul 2007 20:51:39 -0000 1.54
+++ rtsptran.cpp 23 Apr 2008 09:45:39 -0000
@@ -606,10 +606,16 @@
}
void
-RTSPTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo)
+RTSPTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume)
{
// this is the Range values in PLAY request in RMA time (ms) called on PLAY
// request
+ if ((!bOnPauseResume) || (ulFrom != RTSP_PLAY_RANGE_BLANK))
+ {
+ m_ulPlayRangeFrom = ulFrom;
+ m_ulPlayRangeTo = ulTo;
+ }
+
m_ulPlayRangeFrom = ulFrom;
m_ulPlayRangeTo = ulTo;
@@ -1925,14 +1931,19 @@
HX_RESULT
RTSPTransport::setFirstSeqNum(UINT16 uStreamNumber, UINT16 uSeqNum, HXBOOL bOnPauseResume)
{
- RTSPStreamData* pStreamData;
+ RTSPStreamData* pStreamData = NULL;
- HXLOGL3(HXLOG_RTSP, "RTSPTransport[%p]::setFirstSeqNum(uStreamNumber=%hu, uSeqNum=%hu)",
+ HXLOGL3(HXLOG_RTSP, "RTSPTransport[%p]::setFirstSeqNum(uStreamNumber=%hu, uSeqNum=%hu, OnPauseResume=%c)",
this,
uStreamNumber,
- uSeqNum);
+ uSeqNum,
+ bOnPauseResume ? 'T' : 'F');
+
+ if (!bOnPauseResume)
+ {
+ pStreamData = m_pStreamHandler->getStreamData(uStreamNumber);
+ }
- pStreamData = m_pStreamHandler->getStreamData(uStreamNumber);
if(pStreamData)
{
-------------- next part --------------
Index: rtspclnt.h
===================================================================
RCS file: /cvsroot/protocol/rtsp/pub/rtspclnt.h,v
retrieving revision 1.96.2.3
diff -u -r1.96.2.3 rtspclnt.h
--- rtspclnt.h 24 Jan 2008 20:39:42 -0000 1.96.2.3
+++ rtspclnt.h 23 Apr 2008 08:49:03 -0000
@@ -1174,6 +1174,7 @@
const char* pMimeType, UINT32 seqNo);
HXBOOL PipelineRTSP();
+ HXBOOL ServerProducesWallClockTS(void);
HXBOOL m_bPipelineRTSP; //defaults to TRUE.
HX_RESULT ReportSuccessfulTransport(void);
-------------- next part --------------
Index: rnrtspclnt.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/protocol/rtsp/rnrtspclnt.cpp,v
retrieving revision 1.44
diff -u -r1.44 rnrtspclnt.cpp
--- rnrtspclnt.cpp 1 May 2006 17:39:11 -0000 1.44
+++ rnrtspclnt.cpp 23 Apr 2008 09:50:30 -0000
@@ -1161,7 +1161,7 @@
// so use rtp to inter-operate.
if (!m_pSession->m_bChallengeDone && !((HXRTSPClientSession*)m_pSession)->m_pRealChallenge)
{
- return FALSE;
+ return RTSPClientProtocol::IsRealServer();
}
return TRUE;
}
From asingh at real.com Thu Apr 24 02:38:22 2008
From: asingh at real.com (Anshuman Singh)
Date: Thu Apr 24 01:32:30 2008
Subject: [Protocol-dev] Re: [Nokia-private-dev] Real Proxy server reacting
with RESETwhenAutoBandWidthDetection turned ON
References: <0f3c01c8a560$f7ea4cb0$c140a8c0@corp.real.com>
Message-ID: <018001c8a5ee$f2adb910$0b01a8c0@anshuman1>
Real Proxy server reacting with RESET when AutoBandWidthDetection turned ONHi Anuj,
At first glance the problem seems in Proxy. Since Auto Bandwidth Detection fetaure is more relevant for LAN/WAN,
you can turn off this feature by removing feature HELIX_FEATURE_AUTO_BANDWIDTH_DETECTION in your profile file.
You can also disbale it by setting preference AutoBWDetection to 0.
Thanks,
Anshuman
----- Original Message -----
From: Leina Tani
To: ext-anuj.dhamija@nokia.com ; protocol-dev@helixcommunity.org ; nokia-private-dev@helixcommunity.org
Sent: Wednesday, April 23, 2008 10:12 PM
Subject: RE: [Nokia-private-dev] Real Proxy server reacting with RESETwhenAutoBandWidthDetection turned ON
Hi,
Anshuman is looking into this and will respond shortly.
Thank you,
-leina
------------------------------------------------------------------------------
From: nokia-private-dev-bounces@helixcommunity.org [mailto:nokia-private-dev-bounces@helixcommunity.org] On Behalf Of ext-anuj.dhamija@nokia.com
Sent: Tuesday, April 22, 2008 1:11 PM
To: protocol-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: [Nokia-private-dev] Real Proxy server reacting with RESET whenAutoBandWidthDetection turned ON
Hi,
We are finding this problem on one of the sites where streaming sever would not connect when connected via Real Proxy. It is able to connect and stream fine when connected directly. IP dump shows that this is due to Proxy sending a reset back to client that causes connection to fail.
Compared it with a dump where server was able to connect via proxy. Comparison showed that in the latter case AutoBWDetection is turned off on server side (turned ON on client by default) whereas in former case (not working scenario) AutoBWDetection is turned ON on both client and server. So we tried the first scenario with AutoBWDetection disabled on client and this worked. So Proxy seems to be sending reset due to one of AutoBWDetection related message (GET_PARAMETER).
I understand that this is some problem on the Proxy side and it must not send a TCP RESET in any case.
Still I was wondering if it is correct for Helix to keep AutoBWDetection enabled by default? Does this parameter have any significance in Wireless networks? Isnt it relevant only in LAN/WLAN networks?
IPDumps are enclosed.
Case1: Auto BW Detection Cleint:Enable; Server:Enable ==> Not Working
Case2: Auto BW Detection Client:Enable; Sever: Disable ==> Working
Case3: Auto BW Detection Client: Disable; Sever: Enable ==> Working
Comments and suggestions are appreciated.
Thnx & regds
AD
<>
------------------------------------------------------------------------------
_______________________________________________
Nokia-private-dev mailing list
Nokia-private-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080424/112dd99e/attachment-0001.html
From ext-ashwinkumar.1.nadagoudar at nokia.com Tue Apr 29 14:52:01 2008
From: ext-ashwinkumar.1.nadagoudar at nokia.com (ext-ashwinkumar.1.nadagoudar@nokia.com)
Date: Tue Apr 29 13:46:41 2008
Subject: [Protocol-dev] CR : OVIL-7DPT56 : Helix fails to reconnect to WLAN
AP
Message-ID:
" 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-Ashwinkumar.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:
> \protocol\rtsp\rtspclnt.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080429/5b43c753/attachment.html
From asingh at real.com Wed Apr 30 06:03:24 2008
From: asingh at real.com (Anshuman Singh)
Date: Wed Apr 30 04:57:02 2008
Subject: RESEND: [Protocol-dev] CR: Changes to handle RTP Timestamps after
PAUSE
Message-ID: <023501c8aac2$95331770$0b01a8c0@anshuman1>
Skipped content of type multipart/alternative-------------- next part --------------
Index: rtspclnt.cpp
===================================================================
RCS file: /cvsroot/protocol/rtsp/rtspclnt.cpp,v
retrieving revision 1.221.2.7
diff -u -r1.221.2.7 rtspclnt.cpp
--- rtspclnt.cpp 21 Apr 2008 20:00:45 -0000 1.221.2.7
+++ rtspclnt.cpp 23 Apr 2008 12:10:08 -0000
@@ -4414,7 +4414,26 @@
m_pMutex->Lock();
- SendMsgToTransport(RESUME_BUFFER);
+ if (!m_transportRequestList.IsEmpty())
+ {
+ RTSPTransportRequest* pRequest =
+ (RTSPTransportRequest*)m_transportRequestList.GetHead();
+ RTSPTransportInfo* pTransInfo = pRequest->getFirstTransportInfo();
+ HXBOOL bUsesWallClockTS = ServerProducesWallClockTS();
+
+ while(pTransInfo)
+ {
+ if (bUsesWallClockTS)
+ {
+ // If we use wall-clock TS, we signal transport to defer processing of incomming packets until timing information
+ // is communicated.
+ pTransInfo->m_pTransport->setPlayRange( RTSP_PLAY_RANGE_BLANK , RTSP_PLAY_RANGE_BLANK , TRUE);
+ }
+ pTransInfo->m_pTransport->resumeBuffers();
+ pTransInfo = pRequest->getNextTransportInfo();
+ }
+ }
+
/*
* Man, iptv, teracast, and darwin server don't like this even though
@@ -6117,7 +6136,48 @@
HXBOOL
RTSPClientProtocol::IsRealServer(void)
{
- return FALSE;
+
+ HXBOOL bRealServer = FALSE;
+ IHXBuffer* pAgent = NULL;
+ IHXKeyValueListIter* pIter= NULL;
+
+ if (m_pResponseHeaders &&
+ SUCCEEDED(m_pResponseHeaders->KeyExists("Server")) &&
+ SUCCEEDED(m_pResponseHeaders->GetIter(pIter)))
+ {
+ char* pp = "Server";
+ while (pIter->GetNextPair(pp , pAgent) == HXR_OK)
+ {
+ if (strstr((const char *)pAgent->GetBuffer(), "RealServer") || strstr((const char *)pAgent->GetBuffer(), "RealMedia"))
+ {
+ bRealServer = TRUE;
+ break;
+ }
+ HX_RELEASE(pAgent);
+ }
+ HX_RELEASE(pAgent);
+ }
+ return bRealServer;
+
+}
+
+HXBOOL
+RTSPClientProtocol::ServerProducesWallClockTS(void)
+{
+ HXBOOL bRetVal = FALSE;
+
+ UINT32 major = HX_GET_MAJOR_VERSION(m_ulServerVersion);
+ UINT32 minor = HX_GET_MINOR_VERSION(m_ulServerVersion);
+ UINT32 release = HX_GET_RELEASE_NUMBER(m_ulServerVersion);
+
+ if (IsRealServer())
+ {
+ if(major >= 11 || ( major == 10 && minor == 0 && (release == 5 || release == 6)))
+ {
+ bRetVal = TRUE;
+ }
+ }
+ return bRetVal;
}
//
@@ -6187,7 +6247,7 @@
{
pTrans->setFirstSeqNum(uStreamNumber, uSeqNum, bOnPauseResume);
}
- else if (RTPINFO_RTPTIME == info)
+ else if ((RTPINFO_RTPTIME == info) && (!bOnPauseResume || !IsRealServer()))
{
pTrans->setFirstTimeStamp(uStreamNumber, ulRTPTime, FALSE, bOnPauseResume);
}
@@ -6979,7 +7039,7 @@
return NONE_SDP;
}
- if (strstr((const char*)pAgent->GetBuffer(), "RealMedia"))
+ if (IsRealServer())
{
sdpType = BACKWARD_COMP_SDP;
}
@@ -7710,7 +7770,7 @@
{
pSeqValue = pRange->getFirstHeaderValue();
- INT32 nFrom = 0, nTo = 0;
+ INT32 nFrom = RTSP_PLAY_RANGE_BLANK, nTo = RTSP_PLAY_RANGE_BLANK;
if (pSeqValue)
{
@@ -7746,10 +7806,10 @@
RTSPTransportInfo* pTransInfo = pRequest->getFirstTransportInfo();
- while(pTransInfo && nTo)
+ while(pTransInfo && (nFrom != RTSP_PLAY_RANGE_BLANK))
{
// set the range in transport...only for RTP
- pTransInfo->m_pTransport->RTSPTransport::setPlayRange((UINT32)nFrom, (UINT32)nTo);
+ pTransInfo->m_pTransport->RTSPTransport::setPlayRange((UINT32)nFrom, (UINT32)nTo,bIsResumeResponse);
pTransInfo = pRequest->getNextTransportInfo();
}
}
-------------- next part --------------
Index: rtptran.h
===================================================================
RCS file: /cvsroot/protocol/transport/rtp/pub/rtptran.h,v
retrieving revision 1.55
diff -u -r1.55 rtptran.h
--- rtptran.h 6 Jul 2007 20:51:42 -0000 1.55
+++ rtptran.h 23 Apr 2008 09:42:28 -0000
@@ -185,7 +185,7 @@
void SetFirstTSLive (RTSPStreamData* pStreamData, UINT32 ulTS, HXBOOL bIsRaw);
void SetFirstTSStatic (RTSPStreamData* pStreamData, UINT32 ulTS, HXBOOL bIsRaw);
- void setPlayRange (UINT32 ulFrom, UINT32 ulTo);
+ virtual void setPlayRange (UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume = FALSE);
HX_RESULT setFirstPlayTime (Timeval* pTv);
void OnPause (Timeval* pTV);
@@ -269,6 +269,7 @@
UINT32 m_ulWaitQueueBytes;
HXBOOL m_bWaitForStartInfo;
HXBOOL m_bAbortWaitForStartInfo;
+ HXBOOL m_bFirstSeqNumLocked;
HXBOOL m_bSSRCDetermined;
UINT32 m_ulSSRCDetermined;
-------------- next part --------------
Index: rtsptran.h
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/pub/rtsptran.h,v
retrieving revision 1.45
diff -u -r1.45 rtsptran.h
--- rtsptran.h 6 Jul 2007 20:51:40 -0000 1.45
+++ rtsptran.h 23 Apr 2008 09:46:29 -0000
@@ -295,7 +295,7 @@
// only in RTPTransport...
virtual void notifyRTPInfoProcessed (HXBOOL bOnPauseResume = FALSE) {}
- virtual void setPlayRange (UINT32 ulFrom, UINT32 ulTo);
+ virtual void setPlayRange (UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume = FALSE);
virtual HX_RESULT setFirstPlayTime (Timeval* pTv) {return HXR_OK;};
virtual void OnPause (Timeval* pTv) { };
virtual void setLegacyRTPLive(void){};
-------------- next part --------------
Index: rtptran.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/rtp/rtptran.cpp,v
retrieving revision 1.111.2.2
diff -u -r1.111.2.2 rtptran.cpp
--- rtptran.cpp 24 Jan 2008 06:49:24 -0000 1.111.2.2
+++ rtptran.cpp 23 Apr 2008 09:40:50 -0000
@@ -474,7 +474,6 @@
// On client we allow setting of sequence number only once not to cause
// havoc in transport buffer
- if (m_bIsSource || (!m_bSeqNoSet))
{
theErr = RTSPTransport::setFirstSeqNum(uStreamNumber, uSeqNum, bOnPauseResume);
@@ -485,11 +484,17 @@
// In the client, we set for start of stream only if there are no more
// pipelined seeks outstanding an this is not a resume request.
- if (m_bIsSource || ((!bOnPauseResume) && (m_ulSeekCount <= 1)))
+ if (m_bIsSource || (m_ulSeekCount <= 1))
{
if (SUCCEEDED(theErr))
{
m_bSeqNoSet = TRUE;
+ m_bAbortWaitForStartInfo = TRUE;
+ if (bOnPauseResume)
+ {
+ m_uFirstSeqNum = uSeqNum;
+ m_bFirstSeqNumLocked = TRUE;
+ }
}
if (m_pReflectorInfo)
@@ -599,13 +604,13 @@
SetFirstTSLive(pStreamData, ulTS, bIsRaw);
}
}
- else if (!m_bRTPTimeSet)
+ else if (bOnPauseResume || !m_bRTPTimeSet)
{
- // If there are outstanding pipelined seeks or this is just a
- // resumption action, we do not set
- // the start time as we wait for the information provided by
+ // If there are outstanding pipelined seeks
+ // we do not set the start time as we wait
+ // for the information provided by
// the last pipelined seek.
- if (bOnPauseResume || (m_ulSeekCount > 1))
+ if (m_ulSeekCount > 1)
{
return;
}
@@ -690,16 +695,21 @@
}
void
-RTPBaseTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo)
+RTPBaseTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume)
{
// this is the Range values in PLAY request in RMA time (ms) called on PLAY
// request
- RTSPTransport::setPlayRange(ulFrom, ulTo);
+ RTSPTransport::setPlayRange(ulFrom, ulTo, bOnPauseResume);
+ m_bWaitForStartInfo = TRUE;
+ m_bAbortWaitForStartInfo = FALSE;
+ m_bFirstSeqNumLocked = FALSE;
+
+
+ if (bOnPauseResume)
+ {
m_bSeqNoSet = FALSE;
m_bRTPTimeSet = FALSE;
- m_bWaitForStartInfo = TRUE;
- m_bAbortWaitForStartInfo = FALSE;
m_uFirstSeqNum = 0;
m_ulFirstRTPTS = 0;
m_bFirstSet = FALSE;
@@ -723,7 +733,7 @@
// re-start information (RTP-Info) arriving for the last
// pipelined seek.
m_ulSeekCount++;
-
+}
HXLOGL3(HXLOG_RTSP, "RTPBaseTransport[%p]::setPlayRange(From=%lu To=%lu) SeekStarted: Strm=%u SeekCount=%lu",
this,
ulFrom,
@@ -1570,7 +1580,10 @@
if (m_StartInfoWaitQueue.GetCount() == 0)
{
// First packet received
- m_uFirstSeqNum = pkt.seq_no;
+ if (!m_bFirstSeqNumLocked)
+ {
+ m_uFirstSeqNum = pkt.seq_no;
+ }
m_ulFirstRTPTS = pkt.timestamp;
// For Live stream, postpone identification of first packet until we get
// a contiguous sequence (some servers have discontinuity on start
@@ -1590,7 +1603,10 @@
// time is not wrapped before 0
if (lSeqNumDelta < 0)
{
- m_uFirstSeqNum = pkt.seq_no;
+ if (!m_bFirstSeqNumLocked)
+ {
+ m_uFirstSeqNum = pkt.seq_no;
+ }
}
else if (!m_bFirstSet)
{
@@ -1598,7 +1614,10 @@
if (lSeqNumDelta > MAX_NUM_PACKETS_GAPPED_FOR_LIVE_START)
{
resetStartInfoWaitQueue();
+ if (!m_bFirstSeqNumLocked)
+ {
m_uFirstSeqNum = pkt.seq_no;
+ }
m_ulFirstRTPTS = pkt.timestamp;
}
else
@@ -1639,17 +1658,8 @@
}
}
- /* If start Info has been at least partially set or the wait has been
- aborted for some reason (usually when we know it will not be set
- through out-of band methods <-> RTP Info did not contain start Info
- we need).
- Also if starting seq. number is not explicitly communicated,
- scan through few starting packets until we have a good starting
- sequence number (contiguous) since some servers send lossy streams
- in the beginning. */
- if (m_bSeqNoSet ||
- (m_bAbortWaitForStartInfo &&
- ((!m_bIsLive) || (m_StartInfoWaitQueue.GetCount() >= MIN_NUM_PACKETS_SCANNED_FOR_LIVE_START))))
+ if (m_bAbortWaitForStartInfo &&
+ ((!m_bIsLive) || (m_StartInfoWaitQueue.GetCount() >= MIN_NUM_PACKETS_SCANNED_FOR_LIVE_START)))
{
IHXBuffer* pStoredBuffer;
if (m_ulPlayRangeFrom == RTSP_PLAY_RANGE_BLANK)
@@ -1668,10 +1678,27 @@
if (pStoredBuffer)
{
- _handlePacket(pStoredBuffer, FALSE);
- pStoredBuffer->Release();
+ if (m_bFirstSeqNumLocked)
+ {
+ // If sequence number is locked, we drop any packet that precedes the locked in sequence number
+ RTPPacket pkt;
+ if (pkt.unpack(pBuffer->GetBuffer(), pBuffer->GetSize()) == 0)
+ {
+ LONG32 lSeqNumDelta = ((LONG32) (((UINT16) pkt.seq_no) - m_uFirstSeqNum));
+ if (lSeqNumDelta < 0)
+ {
+ HX_RELEASE(pStoredBuffer);
+ }
+ }
+ }
+
+ if (pStoredBuffer)
+ {
+ _handlePacket(pStoredBuffer, FALSE);
+ pStoredBuffer->Release();
}
}
+ }
m_ulWaitQueueBytes = 0;
}
-------------- next part --------------
Index: rtsptran.cpp
===================================================================
RCS file: /cvsroot/protocol/transport/common/system/rtsptran.cpp,v
retrieving revision 1.54
diff -u -r1.54 rtsptran.cpp
--- rtsptran.cpp 6 Jul 2007 20:51:39 -0000 1.54
+++ rtsptran.cpp 23 Apr 2008 09:45:39 -0000
@@ -606,10 +606,16 @@
}
void
-RTSPTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo)
+RTSPTransport::setPlayRange(UINT32 ulFrom, UINT32 ulTo, HXBOOL bOnPauseResume)
{
// this is the Range values in PLAY request in RMA time (ms) called on PLAY
// request
+ if ((!bOnPauseResume) || (ulFrom != RTSP_PLAY_RANGE_BLANK))
+ {
+ m_ulPlayRangeFrom = ulFrom;
+ m_ulPlayRangeTo = ulTo;
+ }
+
m_ulPlayRangeFrom = ulFrom;
m_ulPlayRangeTo = ulTo;
@@ -1925,14 +1931,19 @@
HX_RESULT
RTSPTransport::setFirstSeqNum(UINT16 uStreamNumber, UINT16 uSeqNum, HXBOOL bOnPauseResume)
{
- RTSPStreamData* pStreamData;
+ RTSPStreamData* pStreamData = NULL;
- HXLOGL3(HXLOG_RTSP, "RTSPTransport[%p]::setFirstSeqNum(uStreamNumber=%hu, uSeqNum=%hu)",
+ HXLOGL3(HXLOG_RTSP, "RTSPTransport[%p]::setFirstSeqNum(uStreamNumber=%hu, uSeqNum=%hu, OnPauseResume=%c)",
this,
uStreamNumber,
- uSeqNum);
+ uSeqNum,
+ bOnPauseResume ? 'T' : 'F');
+
+ if (!bOnPauseResume)
+ {
+ pStreamData = m_pStreamHandler->getStreamData(uStreamNumber);
+ }
- pStreamData = m_pStreamHandler->getStreamData(uStreamNumber);
if(pStreamData)
{
-------------- next part --------------
Index: rtspclnt.h
===================================================================
RCS file: /cvsroot/protocol/rtsp/pub/rtspclnt.h,v
retrieving revision 1.96.2.3
diff -u -r1.96.2.3 rtspclnt.h
--- rtspclnt.h 24 Jan 2008 20:39:42 -0000 1.96.2.3
+++ rtspclnt.h 23 Apr 2008 08:49:03 -0000
@@ -1174,6 +1174,7 @@
const char* pMimeType, UINT32 seqNo);
HXBOOL PipelineRTSP();
+ HXBOOL ServerProducesWallClockTS(void);
HXBOOL m_bPipelineRTSP; //defaults to TRUE.
HX_RESULT ReportSuccessfulTransport(void);
-------------- next part --------------
Index: rnrtspclnt.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/protocol/rtsp/rnrtspclnt.cpp,v
retrieving revision 1.44
diff -u -r1.44 rnrtspclnt.cpp
--- rnrtspclnt.cpp 1 May 2006 17:39:11 -0000 1.44
+++ rnrtspclnt.cpp 23 Apr 2008 09:50:30 -0000
@@ -1161,7 +1161,7 @@
// so use rtp to inter-operate.
if (!m_pSession->m_bChallengeDone && !((HXRTSPClientSession*)m_pSession)->m_pRealChallenge)
{
- return FALSE;
+ return RTSPClientProtocol::IsRealServer();
}
return TRUE;
}
From ext-ashwinkumar.1.nadagoudar at nokia.com Tue Apr 29 14:38:05 2008
From: ext-ashwinkumar.1.nadagoudar at nokia.com (ext-ashwinkumar.1.nadagoudar@nokia.com)
Date: Wed Apr 30 08:42:15 2008
Subject: [Protocol-dev] CR : OVIL-7DPT56 : Helix fails to reconnect to WLAN
AP
Message-ID:
> "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-Ashwinkumar.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:
> \protocol\rtsp\rtspclnt.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/protocol-dev/attachments/20080429/dd7f8f94/attachment.html
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.