Re: [asterisk-dev] libpri: reverse charging
On Sunday, November 11, 2007, 09:13:54, Vinícius Fontes wrote: > Sorry, I didn't express myself right. I would like to allow some > COLLECT calls based on their caller id (for example employees on > field, but not customers). The caller id part is easy, nothing that a > GotoIf won't handle... the collect call part is the difficult -- or > impossible -- here. Here in the States when a collect call comes in they announce who the call is from and you're asked if you want to accept it. Is it different in Brazil? -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Application timeouts, Periodic and Scheduled Announcements
On Wednesday, August 29, 2007, 15:00:40, Russell Bryant wrote:
>...
> ; Cancel announcements in case the call ended early
> exten => s,n,NoOp(Cancel beep after ${STOP_ANNOUNCE(${ANNOUNCE_ID1})} seconds)
> exten => s,n,NoOp(Cancel timeup after ${STOP_ANNOUNCE(${ANNOUNCE_ID2})}
> seconds)
> ; Turn off application timeout
> exten => s,n,Set(TIMEOUT(application)=0)
What would be the behaviour if the STOP_ANNOUNCE's and the TIMEOUT
weren't done?
--
[EMAIL PROTECTED] "The avalanche has already started, it is too
Rod Dorman late for the pebbles to vote." - Ambassador Kosh
___
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] The New CDR system
On Monday, April 2, 2007, 06:09:41, Tim Panton wrote: > On 1 Apr 2007, at 18:07, Rod Dorman wrote: >> On Sunday, April 1, 2007, 04:15:16, Tim Panton wrote: >>> On 31 Mar 2007, at 17:17, Rod Dorman wrote: >>>> On Saturday, March 31, 2007, 09:43:53, critch wrote: >>>>> On Sat, 2007-03-31 at 10:59 +0300, Tzafrir Cohen wrote: >>>>>>... >>>>>> What you do is re-implement TCP (or TCP/with a bit of SSL). >>>>>> While it might work, ,it is not as good as the original. >>>> ... >>>> I can understand Tzafrir's point of view. The IAX2 protocol draft >>>> states >>>> "Full frames are sent reliably, so all full frames require an >>>> immediate acknowledgment upon receipt" >>>> whereas TCP utilizes a sliding window protocol that doesn't >>>> require an ACK for every individual transmission. >>> >>> Actually if you cared to it would be legitmate for an IAX >>> implementation to ACK a number of fullframes by just acking the >>> _last_ one, this implicitly acks all the earlier full-frames in that >>> call. >> >> I'm having difficulty finding where in the IAX2 draft that is >> specified. Its not stated in "6.11.1. ACK acknowledgement Message" >> where I would expect to find it. >> >> The closest thing I can find is in "7. Message Transport" where it >> says: >>" ... And if the message is a reliable message, the incoming >> message counter MUST be used to acknowledge all the messages >> up to that sequence number which have been sent." >> >> But the way I interpret that it requires that each reliable message >> MUST be individually acknowledged. > > Not the way I read it, here's the section on ACKs > > When the following messages are received, an ACK MUST be sent in > return: NEW, HANGUP, REJECT, ACCEPT, PONG, AUTHREP, REGREL, REGACK, > REGREJ, TXREL. ACKs SHOULD not be expected by any peer and their > purpose is purely to force the transport layer to be up to date. > > Implicitly for any other FullFrame the ACK is optional, so the the CDR > frame type would be able to make it's own rules. > > In implementation terms you have to be able to treat ACKs as optional > because for some messages they are - NEW for example may be 'acked' > with either an ACK, an ACCEPT a REJECT, AUTHREQ depending on the > situation. > > (I admit, I'm cheating - I got the clue from a helpful comment from > Mark a couple of years back...) I'm not picky about where enlightenment is obtained :-) It does point out that some wordsmithing would be helpful. If any of the authors are reading this could you take this as a request for clarification on when ACKs are required? -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] The New CDR system
On Saturday, March 31, 2007, 09:43:53, critch wrote: > On Sat, 2007-03-31 at 10:59 +0300, Tzafrir Cohen wrote: >>... >> But CDR data really needs what TCP has to offer. >> >> What you do is re-implement TCP (or TCP/with a bit of SSL). While it >> might work, ,it is not as good as the original. > > The only thing needed is guarenteed delivery. IAX full frames in UDP > already do that. Seems to work fine for most people. I can understand Tzafrir's point of view. The IAX2 protocol draft states "Full frames are sent reliably, so all full frames require an immediate acknowledgment upon receipt" whereas TCP utilizes a sliding window protocol that doesn't require an ACK for every individual transmission. -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] Clearing pick-up groups on Zap/ channels
On Monday, November 6, 2006, 15:17:18, Nic Bellamy wrote: > ... > I've been trying to think of an easy, minimal-change way out of the > zapata.conf inheritence problem (since it's not just pickupgroups that > have this behaviour, it's just worse with that since you can't reset it > at present). > > What about something simple like a "resetdefaults" item that will > restore all zapata.conf settings to hardcoded defaults, and clear out > the pickupgroup/callgroup stuff? > Ie. > pickupgroup=1 > callgroup=1 > channel => 1-3 > resetdefaults=yes ; likely need the =yes since it's key=value based > otherconfig=123 > channel => 4 What about just setting it to an empty value? e.g. pickupgroup = -or- pickupgroup = "" (or some other empty value designation) That way you could reset just the ones you want to. -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] E&M + Dial Tone?
On Sunday, June 18, 2006, 12:54:44, Bart Fisher wrote: > I ask on the user's newsgroup and got "dead air" - So trying here: > ... > Any clues for me? http://www.asterisk.org/support Asterisk-users & Asterisk-dev ... asterisk-dev@lists.digium.com provides a forum for the discussion of C code developement pertaining to the Asterisk project. The asterisk-dev list is NOT a 2nd level support -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] Writing a SIP client
On Thursday, May 25, 2006, 08:59:43, Vij wrote: > I'm planning to write a sip client for windows using the sip code > available in asterisk, so that when new features like JB are introduced to > sip, they can be added seamlessly to the softphone too and would work with > asterisk seamlessly. I plan to create a dll, so it would be easy for anyone > to create a custom looking softphone with the all features of * sip code. An informational RFC that just came out may be of interest to you RFC 4504 Title: SIP Telephony Device Requirements and Configuration Author: H. Sinnreich, Ed., S. Lass, C. Stredicke Status: Informational Date: May 2006 URL:http://www.rfc-editor.org/rfc/rfc4504.txt This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones. We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community. If nothing else you should browse section 3 "Glossary and Usage for the Configuration Settings" for ideas on what to name your settings. -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] Variable Inheritance, Setting Channel Variables outside of current context
On Thursday, May 18, 2006, 11:24:41, Johansson Olle E wrote: > 18 maj 2006 kl. 16.41 skrev Peter Beckman: >> ... >> I understand inheritance better now; there are child and parent >> CHANNELS, and variables set in Channel A (parent) with a leading one >> or two underscores will be inherited by Channel B (child) when >> Channel A creates Channel B. > > Please don't use the phrase "parent" or "child" because there's no such > relationship. When one channel creates another channel, we copy some > data to the new channel. After that, it's two channels that may > become bridged. But clearly there *is* a relationship at that point in time when the creation is taking place. I would agree that parent/child is a misleading nomenclature since other uses of it traditionally mean some lasting association beyond the instant of creation. If labels are needed it would be good to be consistent. What would be good labels to use? Some that come to mind are: creator/createe spawner/spawnee forker/forkee -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] IAX internet draft (draft-guy-iax-00)
On Monday, March 6, 2006, 16:51:31, Steve Kann wrote: > ... > I don't know if the spec should include this as a requirement or not: > It was really a workaround for a broken implementation IMHO a broken implementation is equivalent to a different protocol. A spec should describe how to do it right, not enumerate several ways to do it wrong. At least not in a normative section, a non-normative appendix would be the appropriate way to incorporate it in the spec if its really needed. > -- but it would still be needed for asterisk < 1.2, or very old > iaxclient implementations (the new jitterbuffer was in iaxclient > before asterisk). I'm not familiar enough with IAX history. Were the older implementations IAX Version 2? -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] IAX internet draft (draft-guy-iax-00)
On Monday, March 6, 2006, 14:26:59, Steve Kann wrote: > Adrian Sietsma wrote: >> ... >> This would imply that _all_ frames received subsequently would be >> ignored, until frame #4 re-arrives, and resets the sequence ? > > That's correct. That's how it works presently, and the way it would > have to work, unless the receiver stored out-of-order frames (which > would be a worthwhile optimization to make for the lossy link case, as > you note below). I think that such an "out-of-order" reciever store > could be done without changing the specs, though -- as long as it > doesn't _act_ on frames out-of-order, it could probably defer processing > them until it got the missing frame. Is it worth stating that explicitly by saying something along the lines of: "The receiver MAY store out-of-order frames but MUST NOT process them until it receives the missing frame." -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." - Ambassador Kosh ___ --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] Zaptel 1.0 to latest version update
On Tuesday, February 7, 2006, 14:16:19, Kevin P. Fleming wrote: > Rod Dorman wrote: >> I read the intent of the new Development and Release Cycle to be that >> every x.y release will be "consumer ready". > > We are leaving the option open to make releases from the developer > branch as we get closer to making a real release. So, as opposed to > releasing 1.4.0-beta1, -beta2, -beta3, etc. we may release 1.3.90, > 1.3.91, 1.3.92, etc. Ah, the first concrete answer, thanks. This is all I was asking about, I didn't mean for this thread to wander off into a philosophical discussion of release numbering :-) -- [EMAIL PROTECTED] In a world without borders, who needs Windows Rod Dorman and Gates? ___ --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] Zaptel 1.0 to latest version update
On Tuesday, February 7, 2006, 14:26:03, Tzafrir Cohen wrote: > On Tue, Feb 07, 2006 at 01:57:32PM -0500, Rod Dorman wrote: >> ... >> I read the intent of the new Development and Release Cycle to be that >> every x.y release will be "consumer ready". > > You can think of the current development branch as version 1.3.x . e.g: > 1.3.0. . If you really need the version formatted as a version > number. I don't think that the current development branch really needs a version number, its simply the current development branch aka trunk aka head. Its the "release" version numbering I was asking about. -- [EMAIL PROTECTED] "Subtlety is the art of saying what you think Rod Dorman and getting out of range before it's understood." ___ --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 TCP
On Sunday, February 5, 2006, 06:18:01, asterisk_dev wrote: > "Olle E Johansson" wrote: >> ... >> The TCP implementation requires quite a lot of work to be done >> properly and that patch implements some, but very little of what is >> required. SIP over TCP needs the new socket interface that Kevin has >> on hist to-do list and a serious change of chan_sip internals, which >> is on my to-do list under the project name "chan_sip3". > > Great, so, how can I start? I think a good start would be looking at your > chan_sip3. I've never been in an open-source project, so I'm a little lost > with that, it would be nice if someone can help me with that. You can view the code at http://svn.digium.com/view/asterisk/team/oej/chan_sip3/ -- [EMAIL PROTECTED] Bug /n./ Rod DormanAn elusive creature living in a program that makes it incorrect. The activity of "debugging," or removing bugs from a program, ends when people get tired of doing it, not when the bugs are removed. ___ --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] Re: cvs revision tags
On Monday, November 21, 2005, 03:59:49, Olle E. Johansson wrote: > Tony Mountifield wrote: >> ... >> Yes, that's v1-2. It will only have bug fixes, and not experimental or new >> features. The latter will continue to go into HEAD. > > HEAD that is now version 1.3dev, open for a lot of new crazy stuff and > still not recommended for production use. The amount of crazyness will > increase during the coming months so be prepared for the worst and stay > on the v1-2 track for production servers. I was tracking HEAD whilst initially playing with Asterisk and will probably do so again when I can scrape up the pieces to put together a test box. I'm definitely NOT tempted to track HEAD now that we've cut over to Asterisk :-) > Also remember that the v1-2 cvs branch is *not* the release. The release > that we consider stable is the actual tarballs or the tagged CVS, like > v1-2-0. The CVS will change while we are testing bug fixes and you may > check out something we haven't tested out fully yet, which may cripple > your stable server. CVS branches are always changing and committers may > make mistakes. Yes, I understand now that the v1-2-0 tag is the equivalent of burning a CD, its a point in time and is not going to change. However, bugs will be discovered and changes made to HEAD to fix them along with changes for the "new crazy stuff". I'm trying to figure out what the best approach to getting those 1.2.0 'fixes' applied to a production system is. -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." Ambassador Kosh ___ 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] Asterisk or Polycom Bug? - Message waiting
On Monday, November 7, 2005, 18:25:08, Will McCown wrote: > ... > The bad news it that the light remains lit even if there are no > new messages (as I pretty much expected). So, it appears that if > the polycom gets a message-summary with "Messages-Waiting: no" > then it ignores the rest of the message and sets all of the counts > to zero. Reading the RFC I can see how this might be considered > the correct behavior. My take on RFC 3842 is that Messages-Waiting: is a 'new' messages flag only and the presence of 'old' messages are only communicated via the xxx-Message: lines. In particular "3.11. Rate of Notifications" where it has the phrase " ...which do not affect the overall message waiting state (e.g., there are still new messages)." -- [EMAIL PROTECTED] "The avalanche has already started, it is too Rod Dorman late for the pebbles to vote." Ambassador Kosh ___ 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
