Re: [Asterisk-Dev] Adding another dependability
On Mon, May 16, 2005 at 10:00:09AM +0200, Olle E. Johansson wrote: > The vercomp.sh depends on "/bin/bash" - which of course is installed > somewhere else on a FreeBSD server and in a lot of my systems is not > installed at all. [/home/edwin/asterisk/asterisk] [EMAIL PROTECTED]>cat /etc/redhat-release Fedora Core release 2 (Tettnang) [/home/edwin/asterisk/asterisk] [EMAIL PROTECTED]>uname -a Linux tardis.barnet.com.au 2.6.5-1.358smp #1 SMP Sat May 8 09:25:36 EDT 2004 i686 i686 i386 GNU/Linux [/home/edwin/asterisk/asterisk] [EMAIL PROTECTED]>./vercomp.sh flex = 2.5.31 ./vercomp.sh: line 27: conditional binary operator expected ./vercomp.sh: line 27: syntax error near `=~' ./vercomp.sh: line 27: `[[ $progver1 =~ '([^ ]+$)' ]]' Somebody actually managed to get it running? > Is it possible for a good shell hacker to rewrite this to standard > boring bourne shell so that we do not have to add another dependability > to outside software in Asterisk? I'll give it a try, but don't expect it to give the same results as it does do now :-) Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Need help to get into the code
Brian Capouch wrote: > Preston Garrison wrote: > >> Source code is your documentation :) >> > > All 200K+ lines of it!! > > Good luck. . . there aren't many comments either. This approach keeps > the "academics" away, with all the attendant slowdown in development > that entails. > And all calls for help with adding more comments and devdocs are generating close to null... chan_sip is pretty well documented by now ;-) /O ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Re: [patch] Possible fix for subscribe bug.
On 5/13/05, Steve Davies <[EMAIL PROTECTED]> wrote: > [snip] > > The failure was due to an inability to authenticate the SUBSCRIBE, and > this was happening when the phone was trying to SUBSCRIBE using > credentials from "SIP/line1", and find_peer(...) was returning > credentials for the correct phone, but for "SIP/line2". > > I have provided 2 versions of a simple patch, one against 1.0.7 and > once against CVS-HEAD, and would appreciate comments. I have given the > 1.0.7 version some basic testing, and have found no obvious problems. > An additional patch is attached, against 1.0.7, which allows the "sip show subscriptions" command to display the subscribed URI. The URI string was not previously being stored. I would appreciate feedback on these patches as I definitely qualify an an amateur :) Regards, Steve asterisk.chan_sip.107.patch2 Description: Binary data ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] does NOT rtptimout work configrued localy for a peer ???
Greetings, Did anybody get working with rtptimout option set localy. (I tried with no results). I mean not in [general] but with specific peer definition like this: [myfax] type=friend Secret=avantage username=xxx host=xxx fromuser=xxx insecure=very mailbox=xxx rtptimeout=9000 nat=no language=pl disallow=all allow=gsm allow=alaw Generally I need this to handle fax with spandsp. I have UA -> PSTN Gateway -> Asterisk1 (general rtp timeout = 60) -> Asterisk2 (spandsp-rxfax) Asterisk1 needs to have global rtptimout=60 in [general] set for handling voice calls. But when call is made to a specific peer that handles fax (sip.conf: [myfax]) faxing is interrupted by Asterisk1 becouse rxfax seems not transmiting any rtp during reception of fax. So I want rtptimeout in [myfax] to overtide global setting can anybody advise me how to solve this issue. Mateusz ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: [patch] Possible fix for subscribe bug.
Steve Davies wrote: > On 5/13/05, Steve Davies <[EMAIL PROTECTED]> wrote: > > [snip] > >>The failure was due to an inability to authenticate the SUBSCRIBE, and >>this was happening when the phone was trying to SUBSCRIBE using >>credentials from "SIP/line1", and find_peer(...) was returning >>credentials for the correct phone, but for "SIP/line2". >> >>I have provided 2 versions of a simple patch, one against 1.0.7 and >>once against CVS-HEAD, and would appreciate comments. I have given the >>1.0.7 version some basic testing, and have found no obvious problems. >> > > An additional patch is attached, against 1.0.7, which allows the "sip > show subscriptions" command to display the subscribed URI. The URI > string was not previously being stored. I had it there. Guess that's part of my large SIP Subscribe patch that is in the bug tracker. > I would appreciate feedback on these patches as I definitely qualify > an an amateur :) > Will look into it and give you feedback. /O ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] [patch] Possible fix for subscribe bug.
Steve Davies wrote: > Hi, > > A couple of days ago I posted regarding SIP 'SUBSCRIBE's failing from > our snom190 phones here: > http://lists.digium.com/pipermail/asterisk-users/2005-May/106545.html > > I did some more analysis, and it seems that the problem is caused > because each of our phones REGISTERs as two or more users on the same > server (So that the user can choose an identity for outgoing calls) > > This means that when a subscribe comes in, it calls to > check_user_full(...), which then calls find_peer(NULL,ip_address) - > the find_peer call was of course only returning ONE of the > registrations for that IP address. > > The failure was due to an inability to authenticate the SUBSCRIBE, and > this was happening when the phone was trying to SUBSCRIBE using > credentials from "SIP/line1", and find_peer(...) was returning > credentials for the correct phone, but for "SIP/line2". > > I have provided 2 versions of a simple patch, one against 1.0.7 and > once against CVS-HEAD, and would appreciate comments. I have given the > 1.0.7 version some basic testing, and have found no obvious problems. > This patch is already in the bug tracker, without many comments or feedback from other people. The basic problem is that we are trying to authenticate with the From: user name instead of the digest auth username, but that's a much larger fix. /O ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Need help to get into the code
On Monday 16 May 2005 10:11, Olle E. Johansson wrote: > Brian Capouch wrote: > > Preston Garrison wrote: > >> Source code is your documentation :) > > > > All 200K+ lines of it!! > > > > Good luck. . . there aren't many comments either. This approach keeps > > the "academics" away, with all the attendant slowdown in development > > that entails. > > And all calls for help with adding more comments and devdocs are > generating close to null... chan_sip is pretty well documented by now ;-) Then no patches should be accepted without comments, especially where new functions are added. Take a look at func_callerid.c, a new file that has been added without a single comment. B ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] ztdummy accuracy improvements on kernel 2.6
I've been using MeetMe via IAX with no problems on a FC1 box with the 2.4 kernel and zaprtc for timing. Recently I've set up a FC3 box with the 2.6 kernel, and have been using ztdummy for timing. Using the same IAX sources to a MeetMe conference, I found that there was an increasing delay between a participant speaking and the others hearing him. Over 10-20 minutes this crept up to several seconds! The only difference between the two boxes were the kernel and the timing, so I looked at ztdummy. I think the use of add_timer() and the jiffy counter doesn't give enough accuracy for MeetMe use (nor probably for IAX trunking, although I'm not using trunking). This got me thinking and looking again at zaprtc. In 2.4, in order to use zaprtc it was necessary to recompile the kernel to make the rtc a module or not included (CONFIG_RTC=m or CONFIG_RTC=n). In the 2.6 version of drivers/char/rtc.c I found a new feature to hook a function into the rtc interrupt, using the functions rtc_register(), rtc_unregister() and rtc_control(). There is an example of their use in sound/code/rtctimer.c. This would enable an rtc-based zap timer to be implemented without any kernel changes. So I rewrote the 2.6-specific parts of ztdummy.c to use these rtc funcs instead of add_timer(), adopting the same technique as in zaprtc, which is to set the rtc irq to 1024Hz (it must be a power of 2), and then skip 3 out of every 128 irqs (evenly spaced) to give 1000 zaptel interrupts each second. Repeating my tests, I found that the increasing delay was no longer present. This confirmed to me that the jiffy-based ztdummy is not accurate enough, and than an rtc-based one would be a big improvement. I intend to submit this to mantis, but could approach it in two ways: 1. Make it a completely new module called ztrtc, and only for 2.6. 2. Make it an update to ztdummy.c, replacing the add_timer code with the rtc_request() code. Any recommendations which of the two I should do? Cheers Tony -- Tony Mountifield Work: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] chan_sip development
Hi all, There have been various comments over the last few months that people are doing wonderful things to make chan_sip much cleaner and more generalised. I have been using some very crude changes to chan_sip in testing T.38, waiting for a wonderful new chan_sip to which I can make elegant changes. So far, what is in CVS still looks nasty. Can anyone tell me what is really happening? Regards, Steve ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] ztdummy accuracy improvements on kernel 2.6
On Mon, May 16, 2005 at 11:06:16AM +, Tony Mountifield wrote: > I've been using MeetMe via IAX with no problems on a FC1 box with the > 2.4 kernel and zaprtc for timing. > > Recently I've set up a FC3 box with the 2.6 kernel, and have been using > ztdummy for timing. Using the same IAX sources to a MeetMe conference, > I found that there was an increasing delay between a participant speaking > and the others hearing him. Over 10-20 minutes this crept up to several > seconds! i am unclear on one thing -- if there is such a delay, a queue somewhere must grow very long, and i wonder if this couldn't be used as a hint that there is clearly a timing mismatch that should be compensated. cheers luigi ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Re: ztdummy accuracy improvements on kernel 2.6
In article <[EMAIL PROTECTED]>, Luigi Rizzo <[EMAIL PROTECTED]> wrote: > On Mon, May 16, 2005 at 11:06:16AM +, Tony Mountifield wrote: > > I've been using MeetMe via IAX with no problems on a FC1 box with the > > 2.4 kernel and zaprtc for timing. > > > > Recently I've set up a FC3 box with the 2.6 kernel, and have been using > > ztdummy for timing. Using the same IAX sources to a MeetMe conference, > > I found that there was an increasing delay between a participant speaking > > and the others hearing him. Over 10-20 minutes this crept up to several > > seconds! > > i am unclear on one thing -- if there is such a delay, a queue > somewhere must grow very long, and i wonder if this couldn't be > used as a hint that there is clearly a timing mismatch that > should be compensated. I think what is happening is that the zaptel processing invoked by ztdummy is not happening quite often enough due to missed jiffies. Consequently I suspect the incoming IAX channels are not being serviced often enough, and are building up a backlog. Certainly, changing ztdummy to use the hardware timer in the RTC seems to fix the problem nicely. Cheers Tony -- Tony Mountifield Work: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] SIP REINVITE
Although the attached does not specifically address the problem below, it is a summary of a protocol exchange which has a number of questionable (re)INVITE's The exchange originates from a VoicePulse call to an Asterisk system acting as a SIP proxy to an IVR. For some reason, Voicepulse always sends two calls, then accepts the first one answered and cancels the other one. But the issue in the trace is the reINVITE's at lines 14, 18, 23, and 25. The first question is why are they there, but if one looks at the SDP, the INVITE's appear to be eiher sent in the wrong direction or contain the wrong c= elements. I have the full raw trace that I can send off-list if someone is interested. Dan Olle E. Johansson wrote: BJ Weschke wrote: Server A (IP 192.168.1.1) Server B (IP(s) 192.168.1.2 [actual] 192.168.1.3 [vip]) Server C (IP(s) 192.168.1.4) All servers are Asterisk installs. All servers have SIP canreinvite=yes. Server A calls Server B on his VIP. The call sets up fine, but the 3rd of 4th step in the dial plan is to then transfer that call on to Server C. Server B dials server C and then begins to attempt a native bridge between Server A and C. Server A responds back with "SIP/2.0 482 Loop Detected" assumably because the man in the middle has different terminating/originating IP addresses and has sent an improper invite back to A to start the briding process. Can you send me a packet trace of this? Does ANTHM's patch from a few weeks back to chan_sip fix this problem, or is this still a "live" issue? If it is patched, who needs the patch in the scenario above? Just server B? or Servers A and C too? I haven't seen the loop detected issue, but understand where it's coming from. Anthm's patch is more to be seen as a proof-of-concept than something you want to use. I'm trying to continue the work based on his patch, but it will require a lot of changes to chan_sip. I'm glad to see another person wanting to transfer calls from Asterisk to another SIP domain - I just had a question from a core developer on the theme "why would anyone want to do that?"... So I needed your mail to prove that's it is not only me and my customers that need that function. Digging into how chan_sip handles transfers I'm amazed that it work with anything... ;-) /Olle ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev VoicePulse AsteriskIVR 1 ---INVITE 266fc3ef -->| | | 2 |<--100 TRYING 266fc3ef ---| | 3 |---INVITE 124eb4d1 -->| | 4 ---INVITE 47e70fca -->| | | 5 |<--100 TRYING 47e70fca ---| | 6 |---INVITE 2de13285 -->| | 7 | |<--180 RINGING 124eb4d1 --| 8 |<--180 RINGING 266fc3ef --| | 9 | |<--180 RINGING 2de13285 --| 10 |<--180 RINGING 47e70fca --| | 11 | |<--200 OK 124eb4d1 ---| 12 |---ACK124eb4d1 -->| | 13 |<--200 OK 266fc3ef --| | 14 |---INVITE 124eb4d1 -->| | 15 | |<--200 OK 2de13285 ---| 16 |---ACK2de13285 -->| | 17 |<--200 OK 47e70fca --| | 18 |---INVITE 2de13285 -->| | 19 ---CANCEL 47e70fca -->| | | 20 |<--487 Req Term 4e70fca --| | 21 |<--200 OK (cancel) 47e70fca --| | 22 ---ACK266fc3ef -->| | | 23 |<--INVITE 266fc3ef --| | 24 ---ACK47e70fca -->| | | 25
Re: [Asterisk-Dev] Re: ztdummy accuracy improvements on kernel 2.6
On May 16, 2005 08:59 am, Tony Mountifield wrote: > I think what is happening is that the zaptel processing invoked by ztdummy > is not happening quite often enough due to missed jiffies. Consequently > I suspect the incoming IAX channels are not being serviced often enough, > and are building up a backlog. If ztdummy's hitting it 1024 times a second instead of 1000 wouldn't that indicate that it was servicing it too often? -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [Asterisk-Dev] Re: ztdummy accuracy improvements on kernel 2.6
> On May 16, 2005 08:59 am, Tony Mountifield wrote: > > I think what is happening is that the zaptel processing invoked by > > ztdummy is not happening quite often enough due to missed jiffies. > > Consequently I suspect the incoming IAX channels are not being > > serviced often enough, and are building up a backlog. > > If ztdummy's hitting it 1024 times a second instead of 1000 > wouldn't that indicate that it was servicing it too often? > > -A. >From the original email: which is to set the rtc irq to 1024Hz (it must be a power of 2), and then skip 3 out of every 128 irqs (evenly spaced) to give 1000 zaptel interrupts each second. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] chan_bluetooth
chan_bluetooth looks very interesting. When complete, will it be possible to use more than 1 handset per bluetooth dongle? The bluetooth specs specifiy up to three simultaneous synchronous voice channels... ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Re: ztdummy accuracy improvements on kernel 2.6
In article <[EMAIL PROTECTED]>, Andrew Kohlsmith <[EMAIL PROTECTED]> wrote: > On May 16, 2005 08:59 am, Tony Mountifield wrote: > > I think what is happening is that the zaptel processing invoked by ztdummy > > is not happening quite often enough due to missed jiffies. Consequently > > I suspect the incoming IAX channels are not being serviced often enough, > > and are building up a backlog. > > If ztdummy's hitting it 1024 times a second instead of 1000 wouldn't that > indicate that it was servicing it too often? My paragraph above was referring to the current ztdummy method in 2.6 which is to hook into the kernel's tick processing or every jiffy. It is that which I think is missing slots. The 1024Hz is the completely separate RTC interrupt used by zaprtc and now by my modified ztdummy. By skipping 3 every 128 (1 every 42 or 43), it evens out at 1000/sec. Cheers Tony -- Tony Mountifield Work: [EMAIL PROTECTED] - http://www.softins.co.uk Play: [EMAIL PROTECTED] - http://tony.mountifield.org ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] SIP REINVITE
On 5/16/05, Olle E. Johansson <[EMAIL PROTECTED]> wrote: > BJ Weschke wrote: > > Server A (IP 192.168.1.1) > > Server B (IP(s) 192.168.1.2 [actual] 192.168.1.3 [vip]) > > Server C (IP(s) 192.168.1.4) > > > > All servers are Asterisk installs. All servers have SIP canreinvite=yes. > > > > Server A calls Server B on his VIP. The call sets up fine, but the > > 3rd of 4th step in the dial plan is to then transfer that call on to > > Server C. Server B dials server C and then begins to attempt a native > > bridge between Server A and C. Server A responds back with "SIP/2.0 > > 482 Loop Detected" assumably because the man in the middle has > > different terminating/originating IP addresses and has sent an > > improper invite back to A to start the briding process. > Can you send me a packet trace of this? Sure. You want a raw packet trace, or just a "sip debug" trace from *? I won't be able to get packet traces from server A right off the bat, as that one is my carrier's and not my own, but my guess is the problem originates with server B. > > > Does ANTHM's patch from a few weeks back to chan_sip fix this > > problem, or is this still a "live" issue? If it is patched, who needs > > the patch in the scenario above? Just server B? or Servers A and C > > too? > I haven't seen the loop detected issue, but understand where it's coming > from. Anthm's patch is more to be seen as a proof-of-concept than > something you want to use. I'm trying to continue the work based on his > patch, but it will require a lot of changes to chan_sip. > > I'm glad to see another person wanting to transfer calls from Asterisk > to another SIP domain - I just had a question from a core developer on > the theme "why would anyone want to do that?"... So I needed your mail > to prove that's it is not only me and my customers that need that function. > > Digging into how chan_sip handles transfers I'm amazed that it work with > anything... ;-) > > /Olle > Well, looking at the code, it looks that it was designed to work under very simple circumstances. If we present any kind of complex setup, the logic there is going to fall down. My guess is that if server B used it's VIP as the originating IP as oppsed to it's native IP when it makes that initial dial to server C, the logic in place now would work when server B was told to bridge the two calls from Server A to B and B to C together natively. That's a "quick and dirty" for just my scenario, but I'd by interested in contributing time and resources towards "doing it right" if that effort is underway already. BJ ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
