Thread: [Opalvoip-devel] 3.12.6 bandwidth management change
Brought to you by:
csoutheren,
rjongbloed
From: Alexander S. <ale...@gm...> - 2013-09-17 11:35:49
|
I've found a regression in simpleopal from 3.12.6 as compared to 3.12.3. During attempt to establish a call both parties reject to receive video streams by the reason of excessive bandwidth (240Mbit) being request for those channels. I understand that simpleopal is kinda outdated, but still i am willing to report this issue. At the same time OpenPhone is working (with it's own problem but woring) so i suppose something changed in API and simpleopal just failed to initialize channel bandwidth properly for video streams. Also i was supprised to see 448Kbit available from 1Mbit. But main problem is still 240Mbit reported for incoming channel. Command lines i've used for this test: obj_linux_x86_64/simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e h323:<peer ip> -tttt obj_linux_x86_64/simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e Log for this problem (at least for outcome): 0:00.339 H225 Calle...c770d2c700 H245 Receiving PDU: request openLogicalChannel { forwardLogicalChannelNumber = 102 forwardLogicalChannelParameters = { dataType = videoData genericVideoCapability { capabilityIdentifier = standard 0.0.8.241.0.0.1 maxBitRate = 2400000 collapsing = 4 entries { [0]={ parameterIdentifier = standard 41 parameterValue = booleanArray 64 } [1]={ parameterIdentifier = standard 42 parameterValue = unsignedMin 85 } [2]={ parameterIdentifier = standard 4 parameterValue = unsignedMin 36 } [3]={ parameterIdentifier = standard 6 parameterValue = unsignedMin 9600 } } } multiplexParameters = h2250LogicalChannelParameters { sessionID = 2 mediaGuaranteedDelivery = false mediaControlChannel = unicastAddress iPAddress { network = 4 octets { c0 a8 00 0f .... } tsapIdentifier = 5003 } dynamicRTPPayloadType = 115 mediaPacketization = rtpPayloadType { payloadDescriptor = oid 0.0.8.241.0.0.0.0 payloadType = 115 } } } } 0:00.339 H225 Calle...c770d2c700 H245 Received open channel: R-102, state=Released 0:00.339 H225 Calle...c770d2c700 H323 CreateLogicalChannel - forward channel 0:00.339 H225 Calle...c770d2c700 OpalPlugin to_normalised_options: H.264-1 0:00.339 H225 Calle...c770d2c700 OpalPlugin to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" 0:00.340 H225 Calle...c770d2c700 OpalPlugin to_normalised_options: H.264-1 0:00.340 H225 Calle...c770d2c700 OpalPlugin to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" 0:00.340 H225 Calle...c770d2c700 H323 Found capability: H.264-1 <14> 0:00.340 H225 Calle...c770d2c700 RTPCon Found existing video session 2 0:00.340 H225 Calle...c770d2c700 H323RTP Receiver created using session 2 0:00.340 H225 Calle...c770d2c700 OpalCon Insufficient rx bandwidth request of 240Mb/s, available: 448kb/s 0:00.340 H225 Calle...c770d2c700 LogChan Failed bandwidth request=240Mb/s, used=0b/s 0:00.340 H225 Calle...c770d2c700 H323 OnReceivedPDU gave error 7 0:00.340 H225 Calle...c770d2c700 H245 OLC Release: chan=0 0:00.340 H225 Calle...c770d2c700 H245 Sending PDU: response openLogicalChannelReject { forwardLogicalChannelNumber = 102 cause = insufficientBandwidth <<null>> } |
From: Robert J. <ro...@vo...> - 2013-09-19 02:50:33
|
Am I correct in you are making a call between two simpleopal instances? As you have indicated, the sender has put in 240Mbps in the bandwidth field of the openLogicalChannel, so getting the log the the sender to see why it doing that would have been more useful, rather than the receiver. As a rule, partial logs are never enough to work out problems. I have just done a quick check of the current head SVN for the Eridani branch (using OpenPhone) and it seems to be doing the right thing. I seem 1024 in the TCS and OLC. I also did a uick check and nothing has changed in bandwith management since 3.12.6. I will need more info to figure out what is going on. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 17/09/2013 9:35 PM, Alexander Sbitnev wrote: > I've found a regression in simpleopal from 3.12.6 as compared to > 3.12.3. During attempt to establish a call both parties reject to > receive video streams by the reason of excessive bandwidth (240Mbit) > being request for those channels. > I understand that simpleopal is kinda outdated, but still i am willing > to report this issue. > At the same time OpenPhone is working (with it's own problem but woring) > so i suppose something changed in API and simpleopal just failed to > initialize channel bandwidth properly for video streams. > Also i was supprised to see 448Kbit available from 1Mbit. But main > problem is still 240Mbit reported for incoming channel. > > Command lines i've used for this test: > obj_linux_x86_64/simpleopal -alfIX --grabber > "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D > H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 > --video-bitrate 960000 -b 1024000 -e h323:<peer ip> -tttt > obj_linux_x86_64/simpleopal -alfIX --grabber > "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D > H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 > --video-bitrate 960000 -b 1024000 -e > > Log for this problem (at least for outcome): > 0:00.339 H225 Calle...c770d2c700 H245 Receiving PDU: > request openLogicalChannel { > forwardLogicalChannelNumber = 102 > forwardLogicalChannelParameters = { > dataType = videoData genericVideoCapability { > capabilityIdentifier = standard 0.0.8.241.0.0.1 > maxBitRate = 2400000 > collapsing = 4 entries { > [0]={ > parameterIdentifier = standard 41 > parameterValue = booleanArray 64 > } > [1]={ > parameterIdentifier = standard 42 > parameterValue = unsignedMin 85 > } > [2]={ > parameterIdentifier = standard 4 > parameterValue = unsignedMin 36 > } > [3]={ > parameterIdentifier = standard 6 > parameterValue = unsignedMin 9600 > } > } > } > multiplexParameters = h2250LogicalChannelParameters { > sessionID = 2 > mediaGuaranteedDelivery = false > mediaControlChannel = unicastAddress iPAddress { > network = 4 octets { > c0 a8 00 0f .... > } > tsapIdentifier = 5003 > } > dynamicRTPPayloadType = 115 > mediaPacketization = rtpPayloadType { > payloadDescriptor = oid 0.0.8.241.0.0.0.0 > payloadType = 115 > } > } > } > } > 0:00.339 H225 Calle...c770d2c700 H245 Received open channel: > R-102, state=Released > 0:00.339 H225 Calle...c770d2c700 H323 CreateLogicalChannel - > forward channel > 0:00.339 H225 Calle...c770d2c700 OpalPlugin > to_normalised_options: H.264-1 > 0:00.339 H225 Calle...c770d2c700 OpalPlugin > to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" > 0:00.340 H225 Calle...c770d2c700 OpalPlugin > to_normalised_options: H.264-1 > 0:00.340 H225 Calle...c770d2c700 OpalPlugin > to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" > 0:00.340 H225 Calle...c770d2c700 H323 Found capability: > H.264-1 <14> > 0:00.340 H225 Calle...c770d2c700 RTPCon Found existing video > session 2 > 0:00.340 H225 Calle...c770d2c700 H323RTP Receiver created using > session 2 > 0:00.340 H225 Calle...c770d2c700 OpalCon Insufficient rx > bandwidth request of 240Mb/s, available: 448kb/s > 0:00.340 H225 Calle...c770d2c700 LogChan Failed bandwidth > request=240Mb/s, used=0b/s > 0:00.340 H225 Calle...c770d2c700 H323 OnReceivedPDU gave error 7 > 0:00.340 H225 Calle...c770d2c700 H245 OLC Release: chan=0 > 0:00.340 H225 Calle...c770d2c700 H245 Sending PDU: > response openLogicalChannelReject { > forwardLogicalChannelNumber = 102 > cause = insufficientBandwidth <<null>> > } > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Opalvoip-devel mailing list > Opa...@li... > https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Alexander S. <ale...@gm...> - 2013-09-19 08:04:37
|
Yes, I am testing with two opal instances on linux, with command lines as given below. Since I was using "Fake" device i suppose there is no setup specific and result should be easy reproducible. So I put short log only as a head-start. I will send full logs as soon as possible during next week. I reproduce this problem with latest 3.12.7 beta from svn. So it not something 3.12.6 specific. I also confirm OpenPhone is immune to this problem. Can you try these command lines with simpleopal: simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e h323:<peer ip> simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e Probably it just simpleopal specific, or something "Fast start" related, or have something to do with me specifying separate video-bitrate option. On 09/19/2013 06:50 AM, Robert Jongbloed wrote: > Am I correct in you are making a call between two simpleopal instances? > > As you have indicated, the sender has put in 240Mbps in the bandwidth > field of the openLogicalChannel, so getting the log the the sender to > see why it doing that would have been more useful, rather than the > receiver. As a rule, partial logs are never enough to work out problems. > > I have just done a quick check of the current head SVN for the Eridani > branch (using OpenPhone) and it seems to be doing the right thing. I > seem 1024 in the TCS and OLC. I also did a uick check and nothing has > changed in bandwith management since 3.12.6. > > I will need more info to figure out what is going on. > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 17/09/2013 9:35 PM, Alexander Sbitnev wrote: >> I've found a regression in simpleopal from 3.12.6 as compared to >> 3.12.3. During attempt to establish a call both parties reject to >> receive video streams by the reason of excessive bandwidth (240Mbit) >> being request for those channels. >> I understand that simpleopal is kinda outdated, but still i am willing >> to report this issue. >> At the same time OpenPhone is working (with it's own problem but woring) >> so i suppose something changed in API and simpleopal just failed to >> initialize channel bandwidth properly for video streams. >> Also i was supprised to see 448Kbit available from 1Mbit. But main >> problem is still 240Mbit reported for incoming channel. >> >> Command lines i've used for this test: >> obj_linux_x86_64/simpleopal -alfIX --grabber >> "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D >> H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 >> --video-bitrate 960000 -b 1024000 -e h323:<peer ip> -tttt >> obj_linux_x86_64/simpleopal -alfIX --grabber >> "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D >> H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 >> --video-bitrate 960000 -b 1024000 -e >> >> Log for this problem (at least for outcome): >> 0:00.339 H225 Calle...c770d2c700 H245 Receiving PDU: >> request openLogicalChannel { >> forwardLogicalChannelNumber = 102 >> forwardLogicalChannelParameters = { >> dataType = videoData genericVideoCapability { >> capabilityIdentifier = standard 0.0.8.241.0.0.1 >> maxBitRate = 2400000 >> collapsing = 4 entries { >> [0]={ >> parameterIdentifier = standard 41 >> parameterValue = booleanArray 64 >> } >> [1]={ >> parameterIdentifier = standard 42 >> parameterValue = unsignedMin 85 >> } >> [2]={ >> parameterIdentifier = standard 4 >> parameterValue = unsignedMin 36 >> } >> [3]={ >> parameterIdentifier = standard 6 >> parameterValue = unsignedMin 9600 >> } >> } >> } >> multiplexParameters = h2250LogicalChannelParameters { >> sessionID = 2 >> mediaGuaranteedDelivery = false >> mediaControlChannel = unicastAddress iPAddress { >> network = 4 octets { >> c0 a8 00 0f .... >> } >> tsapIdentifier = 5003 >> } >> dynamicRTPPayloadType = 115 >> mediaPacketization = rtpPayloadType { >> payloadDescriptor = oid 0.0.8.241.0.0.0.0 >> payloadType = 115 >> } >> } >> } >> } >> 0:00.339 H225 Calle...c770d2c700 H245 Received open channel: >> R-102, state=Released >> 0:00.339 H225 Calle...c770d2c700 H323 CreateLogicalChannel - >> forward channel >> 0:00.339 H225 Calle...c770d2c700 OpalPlugin >> to_normalised_options: H.264-1 >> 0:00.339 H225 Calle...c770d2c700 OpalPlugin >> to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" >> 0:00.340 H225 Calle...c770d2c700 OpalPlugin >> to_normalised_options: H.264-1 >> 0:00.340 H225 Calle...c770d2c700 OpalPlugin >> to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" >> 0:00.340 H225 Calle...c770d2c700 H323 Found capability: >> H.264-1 <14> >> 0:00.340 H225 Calle...c770d2c700 RTPCon Found existing video >> session 2 >> 0:00.340 H225 Calle...c770d2c700 H323RTP Receiver created using >> session 2 >> 0:00.340 H225 Calle...c770d2c700 OpalCon Insufficient rx >> bandwidth request of 240Mb/s, available: 448kb/s >> 0:00.340 H225 Calle...c770d2c700 LogChan Failed bandwidth >> request=240Mb/s, used=0b/s >> 0:00.340 H225 Calle...c770d2c700 H323 OnReceivedPDU gave error 7 >> 0:00.340 H225 Calle...c770d2c700 H245 OLC Release: chan=0 >> 0:00.340 H225 Calle...c770d2c700 H245 Sending PDU: >> response openLogicalChannelReject { >> forwardLogicalChannelNumber = 102 >> cause = insufficientBandwidth <<null>> >> } >> >> >> >> ------------------------------------------------------------------------------ >> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint >> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes >> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Opalvoip-devel mailing list >> Opa...@li... >> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel > |
From: Robert J. <ro...@vo...> - 2013-09-24 06:13:14
|
I have checked in a possible fix. This both makes sure the bandwidth for each thing in TCS is limited to the max receive bandwidth, and that the outgoing OLC is set to the target transmit bandwidth. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 19/09/2013 6:04 PM, Alexander Sbitnev wrote: > Yes, I am testing with two opal instances on linux, with command lines > as given below. > Since I was using "Fake" device i suppose there is no setup specific > and result should be easy reproducible. > So I put short log only as a head-start. I will send full logs as soon > as possible during next week. > I reproduce this problem with latest 3.12.7 beta from svn. So it not > something 3.12.6 specific. > I also confirm OpenPhone is immune to this problem. > Can you try these command lines with simpleopal: > simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e h323:<peer ip> > simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e > Probably it just simpleopal specific, or something "Fast start" > related, or have something to do with me specifying separate > video-bitrate option. > > On 09/19/2013 06:50 AM, Robert Jongbloed wrote: >> Am I correct in you are making a call between two simpleopal instances? >> >> As you have indicated, the sender has put in 240Mbps in the bandwidth >> field of the openLogicalChannel, so getting the log the the sender to >> see why it doing that would have been more useful, rather than the >> receiver. As a rule, partial logs are never enough to work out problems. >> >> I have just done a quick check of the current head SVN for the >> Eridani branch (using OpenPhone) and it seems to be doing the right >> thing. I seem 1024 in the TCS and OLC. I also did a uick check and >> nothing has changed in bandwith management since 3.12.6. >> >> I will need more info to figure out what is going on. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ >> Commercial support at http://www.voxlucida.com.au >> >> On 17/09/2013 9:35 PM, Alexander Sbitnev wrote: >>> I've found a regression in simpleopal from 3.12.6 as compared to >>> 3.12.3. During attempt to establish a call both parties reject to >>> receive video streams by the reason of excessive bandwidth (240Mbit) >>> being request for those channels. >>> I understand that simpleopal is kinda outdated, but still i am willing >>> to report this issue. >>> At the same time OpenPhone is working (with it's own problem but woring) >>> so i suppose something changed in API and simpleopal just failed to >>> initialize channel bandwidth properly for video streams. >>> Also i was supprised to see 448Kbit available from 1Mbit. But main >>> problem is still 240Mbit reported for incoming channel. >>> >>> Command lines i've used for this test: >>> obj_linux_x86_64/simpleopal -alfIX --grabber >>> "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D >>> H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 >>> --video-bitrate 960000 -b 1024000 -e h323:<peer ip> -tttt >>> obj_linux_x86_64/simpleopal -alfIX --grabber >>> "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D >>> H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 >>> --video-bitrate 960000 -b 1024000 -e >>> >>> Log for this problem (at least for outcome): >>> 0:00.339 H225 Calle...c770d2c700 H245 Receiving PDU: >>> request openLogicalChannel { >>> forwardLogicalChannelNumber = 102 >>> forwardLogicalChannelParameters = { >>> dataType = videoData genericVideoCapability { >>> capabilityIdentifier = standard 0.0.8.241.0.0.1 >>> maxBitRate = 2400000 >>> collapsing = 4 entries { >>> [0]={ >>> parameterIdentifier = standard 41 >>> parameterValue = booleanArray 64 >>> } >>> [1]={ >>> parameterIdentifier = standard 42 >>> parameterValue = unsignedMin 85 >>> } >>> [2]={ >>> parameterIdentifier = standard 4 >>> parameterValue = unsignedMin 36 >>> } >>> [3]={ >>> parameterIdentifier = standard 6 >>> parameterValue = unsignedMin 9600 >>> } >>> } >>> } >>> multiplexParameters = h2250LogicalChannelParameters { >>> sessionID = 2 >>> mediaGuaranteedDelivery = false >>> mediaControlChannel = unicastAddress iPAddress { >>> network = 4 octets { >>> c0 a8 00 0f .... >>> } >>> tsapIdentifier = 5003 >>> } >>> dynamicRTPPayloadType = 115 >>> mediaPacketization = rtpPayloadType { >>> payloadDescriptor = oid 0.0.8.241.0.0.0.0 >>> payloadType = 115 >>> } >>> } >>> } >>> } >>> 0:00.339 H225 Calle...c770d2c700 H245 Received open channel: >>> R-102, state=Released >>> 0:00.339 H225 Calle...c770d2c700 H323 CreateLogicalChannel - >>> forward channel >>> 0:00.339 H225 Calle...c770d2c700 OpalPlugin >>> to_normalised_options: H.264-1 >>> 0:00.339 H225 Calle...c770d2c700 OpalPlugin >>> to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" >>> 0:00.340 H225 Calle...c770d2c700 OpalPlugin >>> to_normalised_options: H.264-1 >>> 0:00.340 H225 Calle...c770d2c700 OpalPlugin >>> to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" >>> 0:00.340 H225 Calle...c770d2c700 H323 Found capability: >>> H.264-1 <14> >>> 0:00.340 H225 Calle...c770d2c700 RTPCon Found existing video >>> session 2 >>> 0:00.340 H225 Calle...c770d2c700 H323RTP Receiver created using >>> session 2 >>> 0:00.340 H225 Calle...c770d2c700 OpalCon Insufficient rx >>> bandwidth request of 240Mb/s, available: 448kb/s >>> 0:00.340 H225 Calle...c770d2c700 LogChan Failed bandwidth >>> request=240Mb/s, used=0b/s >>> 0:00.340 H225 Calle...c770d2c700 H323 OnReceivedPDU gave error 7 >>> 0:00.340 H225 Calle...c770d2c700 H245 OLC Release: chan=0 >>> 0:00.340 H225 Calle...c770d2c700 H245 Sending PDU: >>> response openLogicalChannelReject { >>> forwardLogicalChannelNumber = 102 >>> cause = insufficientBandwidth <<null>> >>> } >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint >>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes >>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Opalvoip-devel mailing list >>> Opa...@li... >>> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel >> > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > > > _______________________________________________ > Opalvoip-devel mailing list > Opa...@li... > https://lists.sourceforge.net/lists/listinfo/opalvoip-devel |
From: Robert J. <ro...@vo...> - 2013-10-02 00:28:43
|
This time for sure! Fix checked in. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 2/10/2013 1:06 AM, Alexander Sbitnev wrote: > Sorry for this long delay. I've just checked latest source. > Still no luck in receiving video streams but this time bandwidth > values are different: > Insufficient rx bandwidth request of 512kb/s, available: 448kb/s > > I've enclose logs from both simpleopal's ends. > > 24.09.2013 10:13, Robert Jongbloed ?????: >> I have checked in a possible fix. >> >> This both makes sure the bandwidth for each thing in TCS is limited >> to the max receive bandwidth, and that the outgoing OLC is set to the >> target transmit bandwidth. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ >> Commercial support at http://www.voxlucida.com.au >> >> On 19/09/2013 6:04 PM, Alexander Sbitnev wrote: >>> Yes, I am testing with two opal instances on linux, with command >>> lines as given below. >>> Since I was using "Fake" device i suppose there is no setup specific >>> and result should be easy reproducible. >>> So I put short log only as a head-start. I will send full logs as >>> soon as possible during next week. >>> I reproduce this problem with latest 3.12.7 beta from svn. So it not >>> something 3.12.6 specific. >>> I also confirm OpenPhone is immune to this problem. >>> Can you try these command lines with simpleopal: >>> simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e h323:<peer ip> >>> simpleopal -alfIX --grabber "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 --video-bitrate 960000 -b 1024000 -e >>> Probably it just simpleopal specific, or something "Fast start" >>> related, or have something to do with me specifying separate >>> video-bitrate option. >>> >>> On 09/19/2013 06:50 AM, Robert Jongbloed wrote: >>>> Am I correct in you are making a call between two simpleopal instances? >>>> >>>> As you have indicated, the sender has put in 240Mbps in the >>>> bandwidth field of the openLogicalChannel, so getting the log the >>>> the sender to see why it doing that would have been more useful, >>>> rather than the receiver. As a rule, partial logs are never enough >>>> to work out problems. >>>> >>>> I have just done a quick check of the current head SVN for the >>>> Eridani branch (using OpenPhone) and it seems to be doing the right >>>> thing. I seem 1024 in the TCS and OLC. I also did a uick check and >>>> nothing has changed in bandwith management since 3.12.6. >>>> >>>> I will need more info to figure out what is going on. >>>> >>>> *Robert Jongbloed* >>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>> Commercial support at http://www.voxlucida.com.au >>>> >>>> On 17/09/2013 9:35 PM, Alexander Sbitnev wrote: >>>>> I've found a regression in simpleopal from 3.12.6 as compared to >>>>> 3.12.3. During attempt to establish a call both parties reject to >>>>> receive video streams by the reason of excessive bandwidth (240Mbit) >>>>> being request for those channels. >>>>> I understand that simpleopal is kinda outdated, but still i am willing >>>>> to report this issue. >>>>> At the same time OpenPhone is working (with it's own problem but woring) >>>>> so i suppose something changed in API and simpleopal just failed to >>>>> initialize channel bandwidth properly for video streams. >>>>> Also i was supprised to see 448Kbit available from 1Mbit. But main >>>>> problem is still 240Mbit reported for incoming channel. >>>>> >>>>> Command lines i've used for this test: >>>>> obj_linux_x86_64/simpleopal -alfIX --grabber >>>>> "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D >>>>> H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 >>>>> --video-bitrate 960000 -b 1024000 -e h323:<peer ip> -tttt >>>>> obj_linux_x86_64/simpleopal -alfIX --grabber >>>>> "Fake/OriginalMovingBlocks" -D H.263 -D H.263plus -D H.261 -D MPEG4 -D >>>>> H.264-High -P H.264-1 --video-size 1280x720 --video-rate 25 >>>>> --video-bitrate 960000 -b 1024000 -e >>>>> >>>>> Log for this problem (at least for outcome): >>>>> 0:00.339 H225 Calle...c770d2c700 H245 Receiving PDU: >>>>> request openLogicalChannel { >>>>> forwardLogicalChannelNumber = 102 >>>>> forwardLogicalChannelParameters = { >>>>> dataType = videoData genericVideoCapability { >>>>> capabilityIdentifier = standard 0.0.8.241.0.0.1 >>>>> maxBitRate = 2400000 >>>>> collapsing = 4 entries { >>>>> [0]={ >>>>> parameterIdentifier = standard 41 >>>>> parameterValue = booleanArray 64 >>>>> } >>>>> [1]={ >>>>> parameterIdentifier = standard 42 >>>>> parameterValue = unsignedMin 85 >>>>> } >>>>> [2]={ >>>>> parameterIdentifier = standard 4 >>>>> parameterValue = unsignedMin 36 >>>>> } >>>>> [3]={ >>>>> parameterIdentifier = standard 6 >>>>> parameterValue = unsignedMin 9600 >>>>> } >>>>> } >>>>> } >>>>> multiplexParameters = h2250LogicalChannelParameters { >>>>> sessionID = 2 >>>>> mediaGuaranteedDelivery = false >>>>> mediaControlChannel = unicastAddress iPAddress { >>>>> network = 4 octets { >>>>> c0 a8 00 0f .... >>>>> } >>>>> tsapIdentifier = 5003 >>>>> } >>>>> dynamicRTPPayloadType = 115 >>>>> mediaPacketization = rtpPayloadType { >>>>> payloadDescriptor = oid 0.0.8.241.0.0.0.0 >>>>> payloadType = 115 >>>>> } >>>>> } >>>>> } >>>>> } >>>>> 0:00.339 H225 Calle...c770d2c700 H245 Received open channel: >>>>> R-102, state=Released >>>>> 0:00.339 H225 Calle...c770d2c700 H323 CreateLogicalChannel - >>>>> forward channel >>>>> 0:00.339 H225 Calle...c770d2c700 OpalPlugin >>>>> to_normalised_options: H.264-1 >>>>> 0:00.339 H225 Calle...c770d2c700 OpalPlugin >>>>> to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" >>>>> 0:00.340 H225 Calle...c770d2c700 OpalPlugin >>>>> to_normalised_options: H.264-1 >>>>> 0:00.340 H225 Calle...c770d2c700 OpalPlugin >>>>> to_normalised_options changed option "SIP/SDP Max FS" from "9000" to "9216" >>>>> 0:00.340 H225 Calle...c770d2c700 H323 Found capability: >>>>> H.264-1 <14> >>>>> 0:00.340 H225 Calle...c770d2c700 RTPCon Found existing video >>>>> session 2 >>>>> 0:00.340 H225 Calle...c770d2c700 H323RTP Receiver created using >>>>> session 2 >>>>> 0:00.340 H225 Calle...c770d2c700 OpalCon Insufficient rx >>>>> bandwidth request of 240Mb/s, available: 448kb/s >>>>> 0:00.340 H225 Calle...c770d2c700 LogChan Failed bandwidth >>>>> request=240Mb/s, used=0b/s >>>>> 0:00.340 H225 Calle...c770d2c700 H323 OnReceivedPDU gave error 7 >>>>> 0:00.340 H225 Calle...c770d2c700 H245 OLC Release: chan=0 >>>>> 0:00.340 H225 Calle...c770d2c700 H245 Sending PDU: >>>>> response openLogicalChannelReject { >>>>> forwardLogicalChannelNumber = 102 >>>>> cause = insufficientBandwidth <<null>> >>>>> } >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >>>>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint >>>>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes >>>>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Opalvoip-devel mailing list >>>>> Opa...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >>> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint >>> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes >>> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >>> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Opalvoip-devel mailing list >>> Opa...@li... >>> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Opalvoip-devel mailing list >> Opa...@li... >> https://lists.sourceforge.net/lists/listinfo/opalvoip-devel > |