RE: [asterisk-dev] H.263 Buffer size
> -Original Message- > From: [EMAIL PROTECTED] [mailto:asterisk-dev- > [EMAIL PROTECTED] On Behalf Of John Lange > Sent: 18 July 2006 16:57 > To: Asterisk Developers Mailing List > Subject: RE: [asterisk-dev] H.263 Buffer size > > On Tue, 2006-07-18 at 08:29 +0200, Sergio García Murillo wrote: > > John Martin wrote: > > > Hi Devs, > > > I was just watching the SVN commits going by and I was wondering > > > why the H.263 buffer size in format_h263.c had to be increased to > > > 32kB? > > > > I really don't see the point if it either (perhaps someone can enlighten > us). > > I don't know if there is any special case in which it's needed, but if > you > > work with rtp you shouldn't exceed the MTU to avoid problems. > > Since MTU is a network layer 2 feature, and since you may traverse any > number of different networks on your way from point A to point B, I > don't see how anything at the application layer could possibly know what > the MTU is. > > When developing at the application layer you are supposed to be able to > safely ignore the layer 2 stuff and let the network(s) do its job. If > that involves fragmenting and reassembling packets then so be it; it > should be 100% transparent to the application layer. > > Now I suppose your point is that in the real world you do have to pay > attention to MTU when coding RTP because it impacts performance. I will > grant you that. Its a shame to have to "corrupt" an application with > issues it shouldn't be concerned with. For one thing if you subsequently > put it on a properly optimized network (larger MTU) it will not perform > optimally. > Brief response as I leave the office... (I said I wouldn't do that the other day :-) ) It often does worse than impact performance, many paths through the Internet (at least that I've come across in the last 5 years) don't let fragmented packets through at all, there always seems to be a device somewhere that'll block fragmented UDP packets - 100% packet loss is a bit of a problem :-) Local networks are a different matter, and so perhaps the RTP packet sizes should be configurable. This is all a fairly moot point because every endpoint I've tested with uses a max packet size of around 1500 bytes and will do so until everywhere on the internet can do more or there's a reliable way of deciding on an MTU before a call starts. I'm not sure what all the fuss is about, people seem quite happy to send G.729 20ms audio packets around with huge overhead, adding a few percent to a video stream to make it work doesn't seem to much of a problem :-) So you have to take account of RTP packet size, even though it might break some application layer models. :-( > By the way, which phones are you guys using to test video? > We use a combination of SIP and H.323 with Huawei, Grandstream, Polycom, Tandberg, Xten, D-Link, TelePhoSee and of course our own :-) For infrastructure we mainly use RadVision and Cisco. > John > > > ___ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] call-limit and problem with freezy phones. also freezy zap channels with x101p card.
call-limit and problem with freezy phones. also freezy zap channels with x101p card. Hello all. I have installed asterisk 1.2.9.1 and zaptel 1.2.6. I have such configuration: I have some phones with planet vip-156 with configuration in sip.conf: [036] ; planet 222 type=friend host=dynamic canreinvite=yes username=036 secret=036 nat=no qualify=10 dtfmode=rfc2833 musiconhold=default context=office callerid=<036> disallow=all allow=ulaw callgroup=1 pickupgroup=1 call-limit=1 . everything work good, but sometimes i have situation in which the asterisk thinks that phone is borrowed at present, and appear message like that: cannot create a sip channel due to usage limit... but when in this situation i check channels with comand "show channels", i see that phone, on which can not call, in this moment absolutly free. That situation appear when i started using call-limit=1. When i do asterisk -rx reload, then that fixes. How that can be fixed without reloads? Also I have problem with zap channels only with x101p cards. Sometimes channel stay up even when line hangup. Also I have tdm400 cards, they work perfect. section in zappata.conf for x101p channel: context=generic-inc signalling=fxs_ks rxwink=300 ; Atlas seems to use long (250ms) winks usedistinctiveringdetection=yes hidecallerid=no callwaiting=no usecallingpres=no callwaitingcallerid=no threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes echocancel=no echocancelwhenbridged=no echotraining=no rxgain=-4 txgain=-4 ;group=2 callgroup=3 pickupgroup=3 immediate=yes busydetect=yes busycount=8 callprogress=no pulsedial=no musiconhold=default switchtype = national group = 3 channel => 6 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] H.263 Buffer size
On Tue, 2006-07-18 at 08:29 +0200, Sergio García Murillo wrote: > John Martin wrote: > > Hi Devs, > > I was just watching the SVN commits going by and I was wondering > > why the H.263 buffer size in format_h263.c had to be increased to > > 32kB? > > I really don't see the point if it either (perhaps someone can enlighten us). > I don't know if there is any special case in which it's needed, but if you > work with rtp you shouldn't exceed the MTU to avoid problems. Since MTU is a network layer 2 feature, and since you may traverse any number of different networks on your way from point A to point B, I don't see how anything at the application layer could possibly know what the MTU is. When developing at the application layer you are supposed to be able to safely ignore the layer 2 stuff and let the network(s) do its job. If that involves fragmenting and reassembling packets then so be it; it should be 100% transparent to the application layer. Now I suppose your point is that in the real world you do have to pay attention to MTU when coding RTP because it impacts performance. I will grant you that. Its a shame to have to "corrupt" an application with issues it shouldn't be concerned with. For one thing if you subsequently put it on a properly optimized network (larger MTU) it will not perform optimally. By the way, which phones are you guys using to test video? John ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Implementing Paging on the Linksys SPA9XX phones
A while back I posted to this list regarding implementing multi-cast paging in Asterisk. I have now been able to get some additional information on how this is implemented and so I'll pass it on to the list in case anyone wants to take up the challenge. Personally I'm hoping to do some additional work on this in the near future when time permits. I'd also like to add this to the bug: http://bugs.digium.com/view.php?id=7172 but its closed. Can someone do that for me or open it? -- This is the format of a multi-cast UDP packet that triggers the phones to listen for a page: The server sends a command to all phones in the page group via multicast. The format of the command is: - First four bytes: command to start listening to a group page message - Second four bytes:multicast IP address to listen on - Ninth byte: group number; 0 for all phones (only zero is support in current firmware) - Tenth byte: reserved, must be 0 - 11th and 12th bytes: multicast port number When the caller hangs up, the server sends another multicast message alerting the listeners that the call has ended. --- Regards, John Lange ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] call-limit and problem with freezy phones.
i've the same issue with 1.2.9.1 Vitaly Oborsky wrote: Hello all. I have such configuration: I have some phones with planet vip-156 with configuration in sip.conf: [036] ; planet 222 type=friend host=dynamic canreinvite=yes username=036 secret=036 nat=no qualify=10 dtfmode=rfc2833 musiconhold=default context=office callerid=<036> disallow=all allow=ulaw callgroup=1 pickupgroup=1 call-limit=1 . everything work good, but sometimes i have situation in which the asterisk thinks that phone is borrowed at present, and appear message like that: cannot create a sip channel due to usage limit... but when in this situation i check channels with comand "show channels", i see that phone, on which can not call, in this moment absolutly free. That situation appear when i started using call-limit=1. When i do asterisk -rx reload, than that fixes. How that can be fixed without reloads? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] call-limit and problem with freezy phones.
Hello all. I have such configuration: I have some phones with planet vip-156 with configuration in sip.conf: [036] ; planet 222 type=friend host=dynamic canreinvite=yes username=036 secret=036 nat=no qualify=10 dtfmode=rfc2833 musiconhold=default context=office callerid=<036> disallow=all allow=ulaw callgroup=1 pickupgroup=1 call-limit=1 . everything work good, but sometimes i have situation in which the asterisk thinks that phone is borrowed at present, and appear message like that: cannot create a sip channel due to usage limit... but when in this situation i check channels with comand "show channels", i see that phone, on which can not call, in this moment absolutly free. That situation appear when i started using call-limit=1. When i do asterisk -rx reload, than that fixes. How that can be fixed without reloads? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: Re: [asterisk-dev] Channel problems
> you may want to post this to mantis at bugs.digium.com so if it is a bug > it can be documented , tagged, and looked into Thanks for this information. But it was not a good idea. "1. First of all, you are using an AGI script to dial. If you dial directly with Dial(), I bet this problem won't happen. 2. if the device looses network connectivity, there is a setting in sip.conf to specifically address this - 'rtptimeout' You have posted a bug report marked 'major' that has to do with a custom component, rather than Asterisk proper, which could also be addressed with a configuration option. This is the second time you do this. In the future, if you think you have identified an Asterisk bug, please consult somebody else either on #asterisk channel on IRC or asterisk-users mailing list. Thank you." But this isn't the solution. Because I set an AbsoluteTimeout that had been ignored by asterisk... Also AGI is a part of Asterisk and if I send a Dial-Command via AGI. Since it had been executed its up to asterisk to finish the call. So this really is a stupid answer to a major bug. -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] yacc error when compiling newest Asterisk 1.2 on FC3
I previously needed to update FC3's version of flex so Asterisk would make; do I have to do the same with byacc? make[1]: Entering directory `/usr/src/instantvoice/asterisk/utils' yacc ../ast_expr2.y yacc: e - line 133 of "../ast_expr2.y", syntax error %pure-parser ^ make[1]: *** [../ast_expr2.c] Error 1 make[1]: Leaving directory `/usr/src/instantvoice/asterisk/utils' make: *** [subdirs] Error 1 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] MeetMe without Zaptel or ztdummy
Anthony LaMantia wrote: > Hi, > > Has anyone ever tired to design a conferencing application or tweeking a > existing one, such as app_meetme to not require to use zap for > trunking/bridge operations? > > using /dev/zap/pseudo seems to be fine for most causes with ztdummy and > all, im just wondering.. Have a look for app_conference. Hint: iaxclient.sf.net -- Cheers, Matt Riddell ___ http://www.sineapps.com/news.php (Daily Asterisk News - html) http://freevoip.gedameurope.com (Free Asterisk Voip Community) http://www.sineapps.com/rssfeed.php (Daily Asterisk News - rss) ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Queries regarding Echo Cancellation in Zaptel-1.2.6
Hello, Chan Kwang Mien wrote: > IP Phone A <--> Asterisk IP PBX <---> Analog Phone B > > In my tests, echos were generated by IP Phone A when I turned on the > speaker. As was pointed out, zaptel could not cancel these echos because > the echo was not received at the zaptel interface, rather on the SIP > interface. Correct. > I have a question : > > Does it mean that the SIP interface has to cancel the echo from IP Phone > A ? No. VoIP part always uses different receive and transmit pathes, so there (theoretically) is no way to mix receive and transmit signals to produce echo. > This should be a real problem since it is possible that echo could be > generated by IP Phones when they are in the handsfree mode (Speaker > mode) or echo could be generated from an old IP Phone. A phone (analog or VoIP) implementing speakerphone mode should care about strong acoustic echo cancellation in this mode. Regular handset operation for best results also requires some sort of acoustic echo cancellation (to resolve signal "connections" between speaker and microphone embedded into single handset), but with correct handset design it's not so important (residual echo through accurate designed handset less than -20 dB). WBR, Paul. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] H.263 Buffer size
Hi Tilghman, Firstly, I think you're absolutely right that video corruption should be protected against. I have spent a lot of the last 6 months trying to get Asterisk to behave nicely with video :-) However, I guess the current fix doesn't actually protect against it, it just makes it more unlikely. H263_write() can still write packets bigger than 32k and h263_read() will still not read in the big packets after checking the packet size and will therefore corrupt the filestream through not keeping track of the file pointer correctly. Shouldn't big packets be dropped before being written in h263_write()? I guess it would also be a good idea to set an AST_MAX_FRAME_SIZE in frame.h and police it in rtp.c and elsewhere. The issue of what AST_MAX_FRAME_SIZE should be is a different matter... And on that note, I think for many reasons allowing large packets is a bad thing (e.g. fragmentation leading to packetloss, latency, jitter, sub-frame error concealment issues, etc). I think this will lead to problems in the future. I guess you didn't set out to fix these problems but it's something we think about on the video dev list. Oh, don't you need to reflect any changes in format_h264.c as well :-( John > -Original Message- > From: [EMAIL PROTECTED] [mailto:asterisk-dev- > [EMAIL PROTECTED] On Behalf Of Tilghman Lesher > Sent: 18 July 2006 08:16 > To: Asterisk Developers Mailing List > Subject: Re: [asterisk-dev] H.263 Buffer size > > On Tuesday 18 July 2006 01:29, Sergio García Murillo wrote: > > John Martin wrote: > > > Hi Devs, > > > I was just watching the SVN commits going by and I was > > > wondering why the H.263 buffer size in format_h263.c had to be > > > increased to 32kB? > > > > I really don't see the point if it either (perhaps someone can > > enlighten us). I don't know if there is any special case in which > > it's needed, but if you work with rtp you shouldn't exceed the MTU > > to avoid problems. > > That's all well and good, but the fact is we COULD receive frames that > are larger than the MTU, and we SHOULD NOT corrupt those frames if we > store them and read them back at a later time. Short of downsampling > those frames to keep them below the MTU, there is pretty much nothing > reasonable to do, except to pass out frames identical to the frames > we received. Hence, bigger buffer. > > I'm not so sure that downgrading the quality of the frame is even > within the purview of a format_ module. If Asterisk is acting as a > temporary storage location for an image that the user has decided that > it needs to be a particular sample size, then a decision on frame size > has already been made by the operator, and Asterisk SHOULD NOT > override that decision. > > > Avoiding memory corruption could be the only explanation I see to > > it, but I don't think it's a very good idea in the long term. > > Avoiding memory corruption is not a very good idea in the long term? > > -- > Tilghman > ___ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] H.263 Buffer size
Tilghman Lesher wrote: > On Tuesday 18 July 2006 01:29, Sergio García Murillo wrote: >> John Martin wrote: >>> Hi Devs, > I'm not so sure that downgrading the quality of the frame is even > within the purview of a format_ module. If Asterisk is acting as a > temporary storage location for an image that the user has decided > that it needs to be a particular sample size, then a decision on > frame size has already been made by the operator, and Asterisk SHOULD > NOT override that decision. IMHO it's not that easy. Working with h263 and rtp means that you have to follow some rules for rtp packetization (rfc 2190 or 2490). They must containt full gobs/slices in each packet and you must add some payload information (motion vectors, gob number, picture type) in it. So there is BIG problem if you plan to send an h263 stream from a non rtp source (H324M or H320 as it has been discussed in the video list) to a rtp one, because you at least would need to parse the h263 to find the gob boundaries and calculate the rest of the parameters for the header. And if you'r bridging two rtp streams I still haven't seen any that uses packets over 1500 bytes. -- This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. No confidentiality or privilege is waived or lost by any wrong transmission. If you have received this message in error, please immediately destroy it and kindly notify the sender by reply email. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Opinions, conclusions and other information in this message that do not relate to the official business of Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given nor endorsed by it. -- ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] H.263 Buffer size
On Tuesday 18 July 2006 01:29, Sergio García Murillo wrote: > John Martin wrote: > > Hi Devs, > > I was just watching the SVN commits going by and I was > > wondering why the H.263 buffer size in format_h263.c had to be > > increased to 32kB? > > I really don't see the point if it either (perhaps someone can > enlighten us). I don't know if there is any special case in which > it's needed, but if you work with rtp you shouldn't exceed the MTU > to avoid problems. That's all well and good, but the fact is we COULD receive frames that are larger than the MTU, and we SHOULD NOT corrupt those frames if we store them and read them back at a later time. Short of downsampling those frames to keep them below the MTU, there is pretty much nothing reasonable to do, except to pass out frames identical to the frames we received. Hence, bigger buffer. I'm not so sure that downgrading the quality of the frame is even within the purview of a format_ module. If Asterisk is acting as a temporary storage location for an image that the user has decided that it needs to be a particular sample size, then a decision on frame size has already been made by the operator, and Asterisk SHOULD NOT override that decision. > Avoiding memory corruption could be the only explanation I see to > it, but I don't think it's a very good idea in the long term. Avoiding memory corruption is not a very good idea in the long term? -- Tilghman ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] asterisk sending connects when it shouldn't (pre-answer OT)
Paul Cadach ha scritto: Could you provide full trace of such call with options: pri debug span set verbose 3 iax2 debug is a span number where you run ISDN PRI. OK I'll arrange with the customer, only practical problem is I'll probably couldn't stop the 150 concurrent calls are actually flowing, is there a way other than logging all to file and searching for the needle in the straw ? (I guess there isn't since 'grep in the cli' is an unanswered faq in users mailing list, but at least a best practice ?) ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Queries regarding Echo Cancellation in Zaptel-1.2.6
IP Phone A <--> Asterisk IP PBX <---> Analog Phone B In my tests, echos were generated by IP Phone A when I turned on the speaker. As was pointed out, zaptel could not cancel these echos because the echo was not received at the zaptel interface, rather on the SIP interface. I have a question : Does it mean that the SIP interface has to cancel the echo from IP Phone A ? This should be a real problem since it is possible that echo could be generated by IP Phones when they are in the handsfree mode (Speaker mode) or echo could be generated from an old IP Phone. > On Mon, 2006-07-17 at 17:04 +0800, Chan Kwang Mien wrote: > > Hi Paul, > > > > Thanks for your reply. > > > > The purpose of my tests is to verify that Echo Cancellation is up and > > running in the zaptel-1.2.6 that I have installed. > > > > In my test-bed, > > > > IP Phone A <--> Asterisk IP PBX <---> Analog Phone B > > Hopefully to put one more explination out here to make sure it is well > known why your problem isn't one that is solveable in Asterisk. > > Take your example above and break it down the way asterisk will see it. > > IP phone <-> Asterisk > > IP phones are 4 wire equivalent so no echo should be introduced here. No > echo cancellation is needed > > Analog Phone < Asterisk > > Asterisk monitors this to gather data for echo cancel. > > Asterisk > Analog Phone > > Now asterisk knows what it sent and can try to remove it from the > returning audio stream. > ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
