Re: [asterisk-users] CDR when replaces
You should read this. http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CDR Rewrite -- Questions to the users
On Sat, Jan 17, 2009 at 10:39 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Only if the dial plan actually gets enough information to set the accountcode, which at least historically wasn't the case for Asterisk. In 1.2.x, you couldn't in the dialplan tell if a call went A-B or A-C(SIP redirect)-B. BLINDXFER didn't get set correctly in all cases. The alternative is to use the built-in accountcode from sip.conf; I haven't verified how well that actually works. It won't work if you need to distinguish two different phones behind a SIP trunk, but I don't think anything can, so we can forget about that case. I've always set the accountcode directly in the dialplan using SetAccountCode and now the newer CDR function. I to encountered occassional problems relying on Asterisk picking up the accountcode from configuration files or a realtime database. We changed our approach to doing a FastAGI call to get the accountcode, the FastAGI call provides the channel name from which the authenticated username and then accountcode can be looked up. As for blind transfers I've always seen the accountcode on the transferred call leg set to that of the call that initiated it. If you wanted it the other way around you do have the option of breaking back into the dialplan when a blind transfer occurs by using the TRANSFER_CONTEXT. At the moment depending on which Asterisk version you are using that won't completely solve the problem since the CDRs produced when transfers occur are all wrong and differently wrong in the different Asterisk versions. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR problems -- two call legs create only one CDR. Using ForkCDR() not even working.
On Fri, Jan 16, 2009 at 6:12 PM, Örn Arnarson o...@arnarson.net wrote: Am I missing something? Any ideas appreciated. No you are not missing anything. The Asterisk CDR implementation has a number of issues and one CDR per bridge is one of them. There is currently a re-design discussion going on on the list at the moment. If you're really interested you can read the new design document at http://svn.digium.com/svn/asterisk/team/murf/RFCs/CDRfix2.rfc.txt. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Rewrite -- Questions to the users
On Sat, Jan 17, 2009 at 3:08 AM, Steve Murphy m...@digium.com wrote: Greyman-- I've been thinking of Benny Amorsen's comments on Simple CDRs... This is tricky... I need to create these CDR's for the billing system: src: A start: e1 ans: e2 end: e6 dst: B disp: ANSW src: A start: e4 ans: e5 end: e6 dst: B disp: ANSW If I do the same substitution again, I get this: A-B start: e1 ans: e2 end: e4. Whoops, end time is wrong. A-C start: e1 ans: e5 end: e4. Whoops, both start and end times are wrong. CDR2 needs to find e1 so it can replace start, while CDR3 shouldn't have anything replaced. I can't think of a query which will do this correctly. Do you have any ideas that might make this work for him? I guess simple CDR's won't work for everyone, but... if they could work in this case From what I can gather the problem Benny has is getting the src field correct for a transfer. In the traditional Telco World the src (or A Number) field tends to be both the callerid of the customer and an identifier that ties the CDR to the customer for billing purposes. With Asterisk and a lot of other modern day softswitches there's usually a field called accountcode or similar which can be used to tie a CDR to a customer. The src field is then only fulfilling one role which is to hold the callerid that was set or recieved for the call. The trick with transfers is to forget about the src field for billing purposes and make sure the accountcode for the call is set in accordance with the business rules. For example if two customers A and B are talking to each other and A blind transfers B to a billable destination Z then who pays for the call from B to Z? There is no right answer but as far as the CDRs are concerned it's irrelvant as long as each call is recorded and the accountcode can be set within the dialplan both choices can be accomodated. With the simple CDR approach it could end up that there are multiple CDRs for a customer for the one call since they could be charged for both ends of a transfer. I don't see that as an issue. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] call transfer in CDR
On Thu, Jan 15, 2009 at 4:09 AM, Rilawich Ango maillist...@gmail.com wrote: Hi, I wonder how I can relate the CDR records for the case of call transfer. I can't find their relationship in CDR. Any can advice? ango You may want to read this thread. http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dropping this SIP message, it's incomplete
On Thu, Jan 15, 2009 at 12:18 AM, David @ULC ucoms2...@gmail.com wrote: I am getting this Error on my Asterisk. How to solve it ? ERROR[2654]: chan_sip.c:11355 handle_request: Missing Cseq. Dropping this SIP message, it's incomplete. If the error message being reported by Asterisk is correct and there is no CSeq header then Asterisk should and is correct to drop the request. The CSeq header is mandatory in all SIP messages and it's not something that a SIP server should try and accomodate. The fix is to determine which device or server is sending the faulty requests and ask the manufacturer to fix it. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Fri, Jan 9, 2009 at 3:08 PM, Steve Murphy m...@digium.com wrote: By appending another string, you can guarantee it is unique across systems. So, if you use a system name, or Asterisk server name, that you yourself guarantee to be unique among all the asterisk servers that would contribute CDRs to a database, you achieve complete, guaranteed uniqueness. How many characters from the server/system name are you intending to use? How are you going to ensure users are aware they need to make their server names unique. asterisk-gateway-europe-ireland-dublin.datacenter-numberone.server1 asterisk-gateway-europe-ireland-dublin.datacenter-numberone.server2 What happens when the server name is left as a default of linux or localhost. I could go on. If I'm missing something, educate me. I need to understand this sort of stuff to be able to write a useful CDR system. Consider this case again. A billing engine using a database backend runs as a separate process to Asterisk. For whatever reason it is terminated unexpectedly and left in an unknown state. Its method of operation is to take CDRs produced by Asterisk, bill them and then write a billed call record to a billedcalls table. When the billing engine is restarted it needs to determine which outstanding CDRs have been billed and which haven't. The consequence of getting it wrong is that a customer will be double billed or not billed. If the billing engine can depend on a unique id field for all Asterisk CDRs its very easy for the billing engine to know what's been billed and what hasn't. Without it extra measures have to be taken such as using both the uniqueid and calldate, not that there isn't a chance of a collision there as well. I'll give up on this. I know programmers can be pedantic but 20 posts discussing whether a Universally Unique Identifier (UUID) is unique has been a bit frustrating. At the end of the day all I'd hope to get from any new system is correct CDRs for blind and attended transfers. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Wed, Jan 7, 2009 at 6:01 PM, Steve Murphy m...@digium.com wrote: On Wed, 2009-01-07 at 02:56 +, Grey Man wrote: On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy m...@digium.com wrote: That sounds a bit dangerous to me. If you go down the path of setting the answer time based on dial plan applications or events you'll need to understand and modify every dial plan application that can answer a call. To me it would seem a lot simpler to do the override/modification in each channel or even better even lower in ast_channel. A channel has to have a very clearly defined definition of answer and hangup whereas dial plan applications don't. Hadn't thought along that line before: classifying the *kinds* of Answer. But we may not have to bother In this mode, a single CDR could cover several dial attempts and their corresponding answers incoming caller A could, during his lifetime in Asterisk, dial several users, say via assisted xfers, and have the targets hang up first, leaving his channel intact. It doesn't make sense to store an outgoing dial result in the originating channel CDR A single CDR should not be able to cover several Dial attempts or even multiple destinations within the same Dial attempts. If you think of Dial as just another application and of CDRs being designed to reflect the lifetime of a channel then things are simplified. If a Dial or any other dial plan application causes three channels to be created then that's 3 CDRs that will be generated. If the first Dial call fails and another one is made with another 3 destinations than that's another 3 CDRs that will be generated. What if, instead, we record the disposition of the dial in the created channel CDR? A channel comes into existence only once. For external incoming calls into the PBX, the disposition is pretty uninteresting, because we'd not create the channel if the disposition wasn't ANSWERED... (well, at least in the DAHDI world, maybe not so much in the voip world)... but, once asterisk dials B in A's behalf, we could record all the dialing action in the CDR for B; It's src/dest related fields could record the dial from A to B; the disposition would be FAIL/BUSY/NOANSWER/etc... That's not quite true. An incoming call to Asterisk could FAIL due to some dialplan condition, it could go UNANSWERED if the dialplan forwards the call to a destination that does not pick up, it could get CANCELLED by the external party before Asterisk finishes processing etc. Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override an ANSWER on exten s, BTW... And, would it be proper to include all dial attempts? My guess is that you would *NOT* want to see any dial attempts in this mode. Well, at least, in this particular case, if A *tries* to dial B, but B doesn't answer, then since A is a live channel, we would record it's life in the system. When A hangs up, we would see the NO ANSWER disposition, and the destination of B, right? If A tried to dial a group, and nobody answered, the destination would be a random member of that group, the args to the Dial command would record the other members, usually. If A tried to dial a group that consisted of 10 members then that's 10 CDRs that should be generated. For those people that don't want unanswered CDRs they can be easily turned off with the configuration option. For those of us that want a CDR for every call which includes successful and unsuccessful call attempts we ge them. Let's say you do your examp, but we add exten dev SIP/w to the list for variety; suppose: W just plain doesn't ANSWER X is offline, so it's FAIL; Y gets answered; Z is busy If you have unanswered = yes, then you'd expect to see: 1. A to Asterisk which is answered (by the dialplan) 2. Asterisk to X which is FAIL 3. Asterisk to Y which is answered, 4. Asterisk to Z which is BUSY 5. Asterisk to W which is cancelled But if you have unanswered = no, then I guess you'd just see: 1. A to Asterisk which is answered (by the dialplan), 2. Asterisk to X which is FAIL 3. Asterisk to Y which is answered, 4. Asterisk to Z which is BUSY or would unanswered = no also suppress #2 and #4? I think with unanswered=no the desire would be to exclude any call with billsec=0. The disposition field is a descriptive field and not something that I think should be relied upon too heavily. Different channels may set the disposition field differently for eaxmple the SIP channel could get clever and set it to FAILED - 403 Forbidden to reflect the SIP response code that caused the failure. That description would obviously not make sense for DAHDI. I don't think it should be the case but if it looks like disposition is increasing the complexity of the design or implementation it could probably be dropped as it's not a critical CDR field and CEL will provide more information in that area anyway. OK, gotcha. Now, let's talk about the fields in current/future
Re: [asterisk-users] Simple CDRs
On Thu, Jan 8, 2009 at 7:34 PM, Leif Madsen leif.mad...@asteriskdocs.org wrote: My apologies. I had installed a tool for posting Asterisk releases, and forgot to turn off all the automatic stuff. This was a reply that reflects my personal opinions on the matter, not all of the Asterisk Development Team. Pity, I thought Asterisk had become sentinent ;-). It would have made bug fixing a lot easier. The new Rule The World feature might have been an issue though... Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Thu, Jan 8, 2009 at 7:22 PM, Asterisk Development Team asteriskt...@digium.com wrote: Actually I could see appending a 'servername' to the UUID as useful in a clustered environment. Every time I don't think I need to do that, I end up having to do it. And since this would be a configurable appendage, it shouldn't hurt anything. I would argue against that. If the server name is useful in the CDR then add another field for it. I for one load CDRs to and from a database using a typed langauge and would be utilising the UUID field as a specific UUID type. If the server name has been tacked on I'll need to do some string parsing to take it off. That aside I don't quite understand the reluctance to rely on the uniqueness of a UUID. I like the wikipedia description (http://en.wikipedia.org/wiki/UUID) where a clash in randomly generated UUID has a probability greater than 10^36 whereas the probability of Earth being hit by a meteor is estimated as one in 17 billion. Where I and I'm sure others want to use the current uniqueid CDR field is as the primary key in a database. Being able to rely on at least one field in the CDR being unique solves a lot of probelms for billing engines such as if the billing engine stops and starts has a particular call been billed or not. At the moment the uniqueid is next to useless for those of us putting CDRs into a database. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Thu, Jan 8, 2009 at 6:22 PM, Steve Murphy m...@digium.com wrote: In general, stuff like FXO's activating, would signal an incoming call, but gee, I could wire up some odd circuit to make it a local extension... Some external rule to the pbx determines which devices and peers you'll want to pay (billable) attention to. Don't you think? That's the classic one alright. Should a CDR be generated whenever someone picks up an analogue phone connected to a DAHDI port on Asterisk? I would argue yes. It may seem like something that could generate an overwhelming number of CDRs but when you think about it a person dedicating themselves to tkaing a phone on and off hook as quickly as possible may be able to generate 3 or 4 CDRs per second. A misbehaving SIP gateway could generate 100's of spuirous call requests and CDRs per second. In both cases as the Asterisk administrator I'd be quite happy to get the CDRs so as to be alerted to the situation so I can take remedial action. - channel: The data that was passed to the channel driver for a call. you probably mean the lastapp/lastdata fields here. I think we may need to look at these fields a little closer. There are several places in the code where a dial-type-operation is performed, but the Dial() app is not called to do it... followme, queues, call files, ami originate, places like that. It might be good to have the method of making the call recorded in the CDR in the lastapp field; like queue#Dial park#Dial, CallFile#Dial, etc. Also, you left out the party field... If A calls in, and dials B, (well, asterisk dials B in A's behalf), and B xfers A to C, then, wouldn't you be at all interested in the fact, that even tho B called C, it was A that spent all the time on the line? Eh, I guess it wouldn't really matter, would it? If C was in Namibia, would B always be billed for the call, or would anyone ever be tempted to bill A's dept for that call? (Assuming, I guess, that A B are both internal)... I was thinking more of the piece of data passed to the channel driver and not the data provided to any particular dialplan application. It gets back again to CDRs reflecting channel activity and not dialplan application activity. The current Asterisk CDR situation illustrates the problem of moving the CDRs up to the dialplan application layer, the solution is to sink them back down to the channel layer. At the end of the day a Call Detail Record by definition should be recording call activity. In Asterisk it's the channels that end up making and ending the calls and not the dial plan or it's applications hence it's the channels that are the best place to generate the CDRs. I take that as a heck no, I'm not interested in the slightest about that! ;) I would be interested in additional information in the CDRs as I'm sure others would. My worry is it's not a critical peice of CDR information and because it sounds like information being generated at the dialplan level it could end up being complicated to implement or confusing to desgin and become a distraction from getting the core CDR fields sorted out. As to the current CDR situation, it is where it is, because of several factors; like a large number of users with vastly different desires and demands; The cdr is stored on channels; several of the CDR fields are copies of channel fields, and no spec to define where/when the proper updates are supposed to be done; CDR fields are updated and set at various places and times with no development documentation as to why; CDRs depend on channel/peer roles that channels take on, but that some operations swap around; and on and on... I have never seen a mechanism so intertangled and interdependent... It's screaming rewrite me!. I've seen a lot worse. Asterisk isn't even 10 years old and in the last couple has started to get some quite rigid coding guidelines. Try 30 years, no guidelines and every programmer and his dog poking around! Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Fri, Jan 9, 2009 at 3:48 AM, Steve Murphy m...@digium.com wrote: But, since it is timestamp based, and unique in that the final part was incremented per request in the same sec, it made a great item to sort on, and allowed me to implement linkedID's. Again that's mixing fields that shouldn't be. The calldate or starttime can be used to sort the CDRs on creation time. If you're going to call a field uniqueid surely a good effort should be made to make it live up to its name. If it's intended to be a sequenceid then that's what it should be called. I guess I could simply have used a simple integer for a linkedID, and had a routine somewhat like the one that coughs up the uniqueID's, just use a lock to provide a number that is incremented safely, (atomic_fetchadd_whatever) and hand it out. Then I could have used a numeric comparison. Might be faster. Maybe Someday... But, it is NOT a number. It's got a period in it but uuids usually have dashes. It's a string. Why you would rip off a system name, I cannot guess, unless you really want or need to deal with it as a number. My advise is not to. I have no prob with uuids, except that they are 36 bytes, and overkill for uniqueness. linkedID + system name would be totally sufficient; One glance at the linkedID will tell you immediately what sys it came from, if you did that. But it's quite legitimate to want to use UUID's. I have no idea how much processing power they take to be generated, probably not much. There's pros and cons... I don't deal with UUIDs as a number or string I deal with them as a UUID (a UUID is a type in OO langauages). That's the point I'm trying to get across. Every modern high level language already has constructs to deal with UUIDs AND it's such a dead easy way to generate a unique id, it's one line of code. By making it a string or integer or something else you're making it harder for people to deal with in their billing engines and it's not actually making the field any more unique than it would be as just a UUID. I don't understand why you want to combine server name and/or a timestamp with the unique id? If a user wants to know or sort on server name then why not provide a dedicated field in the CDR for that? I'm not being anal here. I'm not the only one that has raised this and time and time again it's cropped up on the mailing list where users have been burnt because they relied on uniqueid being unique. Perhaps it would be worth soliciting views from the user list on what people's preference would be for the uniqueid field? Maybe there is a super efficient unique id generation approach that uses less than 36 bytes but what's going to cost the most: people's time in accommodating the super cleverness in their many and varied systems (instead of a UUID that's well understood with existing constructs) or storing 36 bytes per CDR? Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Simple CDRs
On Fri, Jan 9, 2009 at 6:37 AM, Tilghman Lesher tilgh...@mail.jeffandtilghman.com wrote: I think Steve is as interested as anybody else in achieving a solution, but you're hand-waving when it comes to the establishment of a UUID. There is no such construct that we can use, but there are very deterministic methods (which Steve has enumerated) for producing the required uniqueness. And at the end of the day, what you need is the assurance that the algorithm used is indeed unique enough to produce no possible collisions. I've been hand-waving for over a year about the CDRs so you're right in that respect. There are no contructs in C for threads either but they are an abstraction heavily used by Asterisk, likewise linked lists etc etc. At the end of the day whoever writes the code will implement it how best they see fit. I'm merely pointing out that there is already a very straight forward, standard way of generating unique ids that is used extensively and has a probability lower than 1 in 10^36 of generating a collision. In my opinion the methods discussed of incorporating a server name or timestamp into some kind of sequence to create a unique id are pretty fragile. If the new CDRs are accurate with regards the remaining core fields that would be great. Those of us that are using the Asterisk CDRs are already dealing with the non-uniqueid so can continue to do so. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk CLI got freezed!!
Make sure the DNS servers Asterisk is using are not becoming unresponsive or unreachable. Asterisk blocks on DNS requests so if it doesn't get a response it will appear frozen. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Fwd: Simple CDRs
On Tue, Jan 6, 2009 at 3:53 PM, Steve Murphy m...@digium.com wrote: Can't do this; it would be inaccurate; start time is when A either picks up the phone (if dahdi exten), or when A submits an invite (if sip exten), or when an incoming call (via sip invite, or dahdi fxo i/f) arrives at the pbx. I understand what you are saying about start time and I think your approach is correct. I was a bit loose in the use of start and answer time but I agree with you. The answer time is absolutely critical but start time is also required as it can be used for things like identifying how long a user waited for a call to answer. As to Answers, we have to start getting pedantic; if A is an exten, then the first answer will be when B answers. But if A is an incoming call via, say a dahdi fxo interface, or an incoming sip invite, then an s exten is going to get run, and usually the PBX runs the answer() app, and this will usually be the first answer. Now, I can use heuristics to override this first answer if a dial occurs, but... if multiple dials occur, this heuristic would tend to record the last answer; if we override only Answer() in the 's' exten, then we would only record the first answer... is this more like it? That sounds a bit dangerous to me. If you go down the path of setting the answer time based on dial plan applications or events you'll need to understand and modify every dial plan application that can answer a call. To me it would seem a lot simpler to do the override/modification in each channel or even better even lower in ast_channel. A channel has to have a very clearly defined definition of answer and hangup whereas dial plan applications don't. Oh, and BUSY/NO ANSWER/FAIL for a non-s exten, would also override an ANSWER on exten s, BTW... And, would it be proper to include all dial attempts? My guess is that you would *NOT* want to see any dial attempts in this mode. Well, at least, in this particular case, if A *tries* to dial B, but B doesn't answer, then since A is a live channel, we would record it's life in the system. When A hangs up, we would see the NO ANSWER disposition, and the destination of B, right? If A tried to dial a group, and nobody answered, the destination would be a random member of that group, the args to the Dial command would record the other members, usually. I liked you previous approach where all call attempts were recorded and there was a config option to opt out of CDRs for non-answered calls for people that didn't want them. When the Dial command specifies multiple destinations then there should be one CDR for each destination that is dialled irrespective of whether it is answered or not. A disposition of something like CANCELLED could be set for the dial legs that Asterisk cancels after the first one is answered. As an example consider the standard call scenario where a user calls into Asterisk and the dialplan forwards the call to 3 destinations: User A -- Asterisk: Dial(SIP/xSIP/ySIP/z) -- SIP/y answers That should generate 4 CDRs: 1. A to Asterisk which is answered, 2. Asterisk to X which is cancelled, 3. Asterisk to Y which is answered, 4. Asterisk ti Z which is cancelled. For people setting the no unanswered call CDRs the 2 and 4th CDRs would not be generated. I notice that you group the two B CDRs I described into a single entity, but in doing so, you violate your own rule; when B parked A, B was hung up. (He could easily dialed party D, eg, and had a conversation and hung up while A was parked!) According to the rules, there should be two CDR's for B, right? I think this was just me not being that familiar with parking. If the example had been a transfer I would have been on the ball :-). OK, gotcha. Now, let's talk about the fields in current/future CDRs, and see which you consider relevant? The core fields I would put into the Asterisk CDRs are: - uniqueid: A GUID/UUID that cannot be changed and is critical for billing, - calldirection: 0 for a call Asterisk receives and 1 for a call Asterisk initiates, - accountcode (user modifiable) - clid: The channel identifier of the call originator equivalent to the A number on a traditional telco CDR, - dst: The destination of the call equivalent to the B number on a traditional telco CDR, - starttime: The time Asterisk first receives or initiates a call, - progresstime: The time Asterisk first receives or generates a progress indication, - answertime: The time a call is answered, - endtime: The time a call is hungup or cancelled, - duration: endtime - starttime, - billsec: endtime - answertime, - disposition: ANSWERED, TIMEOUT, CANCELLED, HUNGUP and maybe others, - userfield (user modifiable): General purpose field for any custom CDR info needed by Asterisk users. Some extra fields that I think would also be very (if not very very) useful to people: - remoteip: The remote IP address of the call where relevant. For an incoming call the originator's IP address, for an
Re: [asterisk-users] Asterisk CLI got freezed!!
Doesn't matter if you have set it up or not Asterisk needs DNS. I haven't checked the code but I think it even does reverse lookups on IP addresses. If you haven't got a reliable DNS server available for Asterisk I suspect you're always going to get issues. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] 1.6, CDR and h extension
On Mon, Dec 29, 2008 at 10:19 PM, Benny Amorsen benny+use...@amorsen.dk wrote: You are onto something, even if I don't actually use ForkCDR. With 1.6.1beta4 the behaviour is consistent at least, for a particular call scenario CDR(hangupcause) is either recorded correctly or not recorded. Still, some call scenarios work and some don't. In particular, some of the call scenarios create weird extra empty CDR's like: ,,s,from-ipvision,SIP/ipvision-0871eaa02008-12-29 23:04:14,,2008-12-29 23:04:16,2,0,NO ANSWER,DOCUMENTATION,,lpbx02-1230588254.29,, Hi Benny, There was some tweaking done to the CDRs in Asterisk recently by murf that I believe did influence the behaviour of the hangup extension so that may be the cause of your first issue. The CDR you have posted above is not that abnormal, it looks like an outgoing call that did not end up getting sent anywhere meaningful and therefore its end destination was the s extension in your dialplan. Or it could be something else entirely. There is a currently a year long conversation going on about Asterisk CDRs to try and design out numerous glitches you can search the list archives if interested. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk quits responding
On Fri, Dec 26, 2008 at 12:36 AM, Todd Reese trees...@gmail.com wrote: I think that it was 167. I usually keep a it very high. New update: After the console being frozen for about 15 minutes, it just responded to the last reload comand Sounds like a DNS problem to me. If Asterisk can't get responses from DNS it handles it very inelegantly by just sitting there blocking. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk and Dabatase
On Sun, Dec 21, 2008 at 9:52 AM, bilal ghayyad bilmar...@yahoo.com wrote: Anyone knows if there is an Asterisk version that setup can be stored in Database instead of the configuration files (.conf)? Yes all current versions can. Take a look at Asterisk Realtime http://www.voip-info.org/wiki-Asterisk+RealTime Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk and Dabatase
On Sun, Dec 21, 2008 at 11:57 AM, bilal ghayyad bilmar...@yahoo.com wrote: Where this link? Did not see or receive any? In case of using database, how can I determine that my configuration be taken from DB or from .conf files? Where this can be setted? And is it possible to take confiruation from both? If any recorded added for DB, then I need to do a reload to become effected? Getting Asterisk up and running with a database configuration (realtime) is not something that you will be able to do quickly or easily. If you are new to Asterisk I'd highly recommend getting a grip on running Asterisk with the configuration files before moving onto realtime. If you're not too interested in the inner workings and do just want to get something up and running pronto take a look at the AsteriskNow or TrixBox products. They tend to provide a higher level abstraction to running Asterisk and have a web page based configuration approach. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, Dec 5, 2008 at 8:26 AM, Andrew Thomas [EMAIL PROTECTED] wrote: In summary: Leave CDR exactly as it is and create a new CEL (Call Event Logging) module (optional in modules.conf) that puts out (and does not accept) call event information (ie. a one-way fire-and-forget output from Asterisk). Hi Andrew and Others, This thread is actually part of a discussion that has been going on for over a year. The links below provide the background to the whole thing. http://www.asterisk.org/node/48358 http://bugs.digium.com/view.php?id=11849 http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html Up until recently the approach was to try and fix the specific bugs with transfer CDRs as a typical bug. There is now a realisation that that is a lot trickier than inially thought so it's been decided to try and come up with a good design for the Asterisk CDR sub-system. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
Another thing to be aware of as the wish list for the Asterisk CDR continues to grow is that right now Asterisk does not lend itself to accurately creating the most fundamental requirement of a CDR which is to accurately record at the very least the originator, destination, time and duration for EVERY call Asterisk processes. It's already proven to be a very hard requirement to meet for Asterisk given the original CDR design and implementation and to my mind there is no point trying to add more sohisticated behaviour - call flows, events, linked ids etc. - until it has been. The more convoluted any new design gets the less chance it has of ever getting implemented in the near future. Getting a basic accurate CDR system in place does not preclude future enhancements but without it they'll just add another few layers to the house of cards. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Fri, Dec 5, 2008 at 8:11 PM, Steve Murphy [EMAIL PROTECTED] wrote: Hmmm. See your point. I can suppress these HOLD events, and any others I end up covering with a config file. Whether it's by default on or off, we can arrange as the majority, whatever that is, requests. In my current line of thinking, the HOLD period was output to help describe what was done with the channel. Whether folks on hold are charged the same as folks not on hold, that's a business decision. I personally cannot predict with any certainty what folks will be interested in billing or not billing. You seem pretty certain that HOLD information is useless to billing, but can you guarantee me that this info is useless in all possible billing situations? No I can't but it would be the first I'd ever heard of anybody being differently when they were on hold compared to a normal call. Putting a call hold does not change the original call ends and the time on those calls keeps ticking so I can guarantee you there a people like me that want to bill the call besed on endpoints and whether the call is on hold, listening to streaming radio, being sent a festival tts message etc. is irrelevant. Well, if I take a UUID type field and tack it onto the end of the current LinkedID, will that do? I get something I can sort timewise and make a quick decision on; you get something that but once every billion-trillion-gazillion times, will be unique. And you can also tack a system id onto the end, or the begin for that matter, on the way to the database In my perfect World I'd change uniqueid to a UUID since that's what it claims to falsely be. But as you say there are other ways a unique id can be added and if needs be we could do it that way. I've being trying to avoid a bunch of comma separated data in the UserField but that's no big deal either way. maybe. But, you can do one-touch stuff via dtmf to asterisk, and do transfers that way. How this might reflect back into the sip protocal, I'm not certain right now. A sip device might not be able to tell what happened, but this is conjecture on my part. No it doesn't. A SIP transfer is a striaght forward operation and the only way to do one is with a REFER request. How you generate the REFER request can be different such as DTMF or transfer button but the effect is identical. When Asterisk processes the REFER request it is going to end up initiaiting a call and for a blind transfer hanging one up. That's it. I'll have to think on this. Perhaps an option to reduce everything to single per-chan cdrs. It'll be a ton easier to implement something like this by NOT storing the CDR on a channel. In my life as a software engineer simple solutions tend to be the right ones. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Wed, Dec 3, 2008 at 10:47 PM, JD [EMAIL PROTECTED] wrote: Grey man: you are right. The direction of a call leg is easy to determine from the point of view of asterisk. I suspect other folks however, think of it differently. Some would think of a call coming from a customer CPE to asterisk as an outbound call. Inbound to asterisk, yes. But outbound for billing purposes. But if you are using Asterisk for xyz, then the pattern of logic may differ yet again. So, while AMA CDRs may look at it in a specific way, Steve's flexible system should probably leave it up to each programmer writing their unique billing analysis software. I knew I shouldn't have mentioned inbound and outbound calls :-). I don't have any issues distinguishing between outbound and inbound calls in the current system all I was attempting to do was point out it's not very difficult to manage. However it's not that relevant an argument for the CDR design so should be disregarded. To sum up, personally I still think the current AMA-style CDRs should remain in place. Perhaps touched up a bit. Or not. Steve's system should be in addition to the AMA-style CDRs and called something other than CDRs. (CDRplus?) Well if you are in a situation where you have to bill users and those users are able to make transfers you'd be just as keen for the system to get the system changes as a lot of the rest of us. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Design
On Mon, Dec 1, 2008 at 3:26 PM, Steve Murphy [EMAIL PROTECTED] wrote: Everyone-- I've just made some major changes to the CDRfix2.rfc.txt file in http://svn.digium.com/svn/asterisk/team/murf/RFCs to accommodate the Leg approach instead of a channel-based approach. Hi murf, I've got a couple of points (as always) from the new design. First one would be the generation of CDRs when putting a call on hold. I don't think that should occur. When a call is put on hold Asterisk never changes the endpoints of a call all it does is possibly change the media to one or both of the call ends. CDRs are about call endpoints not about media transitions. In SIP terms putting a call on hold is no different to changing codecs both operations are re-INVITES and are irrelevant as far as CDRs and billing go. As far as internal calls vs external calls go I would argue that Asterisk can distinguish between them. Any call initiated with the Dial (or equivalent) app is an outgoing call. Anything call request arriving at Asterisk from the outside World is an internal call. For a standard call from a SIP user there are two call legs; the incoming call leg to Asterisk and the outgoing call from the dialplan. For a DAHDI user there is only a single call leg being the outgoing call from the dialplan since providing dialtone when they pick up the phone is not a call leg. I guess it's not really relevant for the CDR design but it's actually not a difficult thing to cope with when writing a billing engine for Asterisk, I know as I've done it. I like the new CDR fields. My number one concern would be to get the CDRs accurate but additional useful information can only help as long as it used the right way, i.e. not treated as definitive for billing purposes. For the linkedid and ideally the uniqueid I reaally think it would be vastly more useful to use a GUID or UUID rather than a incrementing sort of unique id. A lot of use are dealing with CDRs by writing them to databases and it would greatly simplify and improve the robustness of billing if Asterisk CDRs could be categorically be indentified as unique. If we need to know which CDR came first we can use the calldate ther is no need for the linkedid or uniqueid to double up for that. I'm not to sure about: In a leg-based sort of system, CDRs would follow bridging. Does that mean whenever the end of a bridge changes a CDR is generated? And does it mean there are two CDRs per bridge or one? From your examples there only seems to be one CDR per bridge which straight away I can think of a scenario that would cause a problem. If I supply toll free numbers that need to be billed for incoming calls and that can be forwarded out to billable destinations then I want a CDR for both ends of the bridge. In your first blind transfer example what if the initial incoming call to A is billable? I can't see any easy way to get the duration of that call leg. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Desgin
On Mon, Dec 1, 2008 at 7:57 PM, Philipp Kempgen [EMAIL PROTECTED] wrote: JD schrieb: As to the idea of piping to a deamon via socket or dbus: how would asterisk behave if the daemon froze or worse, it lagged? I have implemented something similar with the Dial command. We had a customer that required real-time call control where every 60s a new request had to be made to reserve quota to allow the call to continue. Part of that involved sending a Curl request from app_dial.c as soon as the call answered and as soon as the call hungup. It works well and is loosely coupled with Asterisk so that in the worst case the Curl request times out after 2s and Asterisk could take alternative action if necessary. A nice side effect of this approach is that it's possible to get a realtime display of calls in progress from the database rather than having to use MAPI. Ultimatley I think CEL is going to be the approach for tracking call flow. Hopefully the CEL hooks will be two way so I don't have to keep updating my real-time call control patch for each version of Asterisk :-(. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Channel variable to identify the calling SIP peer
On Wed, Nov 26, 2008 at 11:47 AM, Richard Brady [EMAIL PROTECTED] wrote: Hi folks I'm not sure what I am missing but I cannot find a predefined channel variable to identify the SIP peer/user which has initiated a call and established the channel. The one option is to extract it from the CHANNEL variable, but that is fraught with difficulties. Is there another variable I don't know about or another way to do this? In 1.2 and 1.4 I don't believe there is any other way. Parsing the username from the channel name is what we ended up having to do! Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR Desgin
On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy [EMAIL PROTECTED] wrote: For the moment, let's not worry about the implementation. Let's get consensus on the spec first. In the scenario, where A calls B, B xfers A to C, C xfers A to D, or some such similar scenario, half the world wants a single CDR for A, from the time it started, to the time it hung up with D. The other half wants A-B's dial and bridge, a cdr for A C's bridge, a CDR for A D's bridge, and mayhaps some CDRs to describe the xfers, where B xfers A to C and C xfers A to D. My document is pointing in the former direction, and either we need to spec both, or pick one. To me the obvious answer is to provide a CDR for every call leg so for A calling B via Asterisk there would be two CDRs produced. It's far far easier to disregard the unwanted CDRs than it is to try and generate the missing ones and in some cases it's virtually impossible. If it's weighed up I think people would vote to have accurate CDRs ahead of anything else and if single legs are the best way to do that then it's the way it should be done. In addition with single leg CDRs it will solve the dilemna about acommodating every possible call scenario that I know has caused you a lot of consternation over the last 18 months. Sure it's a change from the current situation so maybe needs to use the standard apporach of a configuration setting to opt in initially before becoming the default in the subsequent major release. Regards, Greyman. P.S. Sorry about the duplicate post. I actually sent the email to the list 4 times with around 8 hour spacings and I'm not sure why there was a problem getting it through. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CDR Design
I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal (link ommitted to see if email gets accepted). After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; channel calls but not peer calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields be removed from the current implementation (although for pity's sake one change that should be made it to use a GUID/UUID for the CDR's uniqueid and save endless confusion). People that really do need verbose or enhanced CDRs to do things like tracking a call's flow as it travels in and out of queues, parking lots etc. would be better off using AMI or the new CEL and not CDRs. At the very least if problems arise with their call flow tracking they will still be able to rely on the accuracy of the CDRs to piece it altogether to work out what's going wrong. My proposal of creating a 1-to-1 relationship between CDRs and Asterisk channels already exsits but somewhere along the line it's going awry. As an experiment, and to actually do something instead of continually moaning about it, I started commenting out the blocks of code in res_featrures.c and sip_channel.c that muck around with the channel CDRs when a transfer occurs. The results of that were that the CDRs for blind and attended transfers actually got better! They're still not quite right but are pretty close with only one CDR on each having a wrong destination. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CDR Design
I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; channel calls but not peer calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields be removed from the current implementation (although for pity's sake one change that should be made it to use a GUID/UUID for the CDR's uniqueid and save endless confusion). People that really do need verbose or enhanced CDRs to do things like tracking a call's flow as it travels in and out of queues, parking lots etc. would be better off using AMI or the new CEL and not CDRs. At the very least if problems arise with their call flow tracking they will still be able to rely on the accuracy of the CDRs to piece it altogether to work out what's going wrong. My proposal of creating a 1-to-1 relationship between CDRs and Asterisk channels already exsits but somewhere along the line it's going awry. As an experiment, and to actually do something instead of continually moaning about it, I started commenting out the blocks of code in res_featrures.c and sip_channel.c that muck around with the channel CDRs when a transfer occurs. The results of that were that the CDRs for blind and attended transfers actually got better! They're still not quite right but are pretty close with only one CDR on each having a wrong detstination. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CDR Desgin
I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; channel calls but not peer calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields be removed from the current implementation (although for pity's sake one change that should be made it to use a GUID/UUID for the CDR's uniqueid and save endless confusion). People that really do need verbose or enhanced CDRs to do things like tracking a call's flow as it travels in and out of queues, parking lots etc. would be better off using AMI or the new CEL and not CDRs. At the very least if problems arise with their call flow tracking they will still be able to rely on the accuracy of the CDRs to piece it altogether to work out what's going wrong. My proposal of creating a 1-to-1 relationship between CDRs and Asterisk channels already exsits but somewhere along the line it's going awry. As an experiment, and to actually do something instead of continually moaning about it, I started commenting out the blocks of code in res_featrures.c and sip_channel.c that muck around with the channel CDRs when a transfer occurs. The results of that were that the CDRs for blind and attended transfers actually got better! They're still not quite right but are pretty close with only one CDR on each having a wrong detstination. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] CDR Desgin
I've taken the liberty of starting a new thread to discuss the design of the Asterisk CDR mechanism. The discussion has been kindly initiated by murf putting together a proposal: http://svn.digium.com/svn/asterisk/team/murf/RFCs. After reading the proposal I still don't think it's the right way to go. To my mind adding more channel variables increases the complexity in a situation that is already overly so. I think it's a mistake to try and think about all the different call scenarios and come up with little tricks for the more complicated ones. There will always be something missed; app_shotgun initiates calls to 100 random numbers and as soon as three or more calls are answered it will start randonly transferring them amongst each other at 2 second intervals. I think it's important to clarify at the outset what a CDR should be. The most fundamental requirement for CDRs is that they accurately record the following pieces of information for EVERY call entering or leaving the system (note every means every and not; channel calls but not peer calls). 1. Destination (aka as A Number) 2. AccountCode (aka as B Number) 3. Call Start Time (answer time), 4. Duration. Of course adding extra information can be very useful and I'm not proposing any fields be removed from the current implementation (although for pity's sake one change that should be made it to use a GUID/UUID for the CDR's uniqueid and save endless confusion). People that really do need verbose or enhanced CDRs to do things like tracking a call's flow as it travels in and out of queues, parking lots etc. would be better off using AMI or the new CEL and not CDRs. At the very least if problems arise with their call flow tracking they will still be able to rely on the accuracy of the CDRs to piece it altogether to work out what's going wrong. My proposal of creating a 1-to-1 relationship between CDRs and Asterisk channels already exsits but somewhere along the line it's going awry. As an experiment, and to actually do something instead of continually moaning about it, I started commenting out the blocks of code in res_featrures.c and sip_channel.c that muck around with the channel CDRs when a transfer occurs. The results of that were that the CDRs for blind and attended transfers actually got better! They're still not quite right but are pretty close with only one CDR on each having a wrong detstination. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Load balancing Asterisk.
This baby talks about being able to do hardware SIP load balancing. http://www.f5.com/news-press-events/press/2007/20070212.html I've never used an f5 product so I can't provide any comments from experience. I did look at an f5 load balancer product once and the price was over 6 figures that was a few years ago though. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Load balancing Asterisk.
3. Incoming calls - I admit complete ignorance. I don't know how OpenSIPS handles incoming calls, but for those to arrive at the user reliably they must arrive from the same IP address the user is registered to. Otherwise their broadband router's NAT firewall will just block the connection. How does OpenSIPS handle this? (does it handle this??) That's the big question! My company uses a custom SIP Proxy and SIP Registrar so I can't speak for the details of SER derivatives but the theory is most likely the same. Our SIP Registrar records the proxy the REGISTER request arrived on and updates the Asterisk realtime database outboundproxy field with that value. When Asterisk needs to send an incoming call to the user it looks up the SIP username in the realtime database and sends the call thorugh the correct Proxy which solves the NAT issue you mention. One trick for young players here is that the outboundproxyport setting is broken in Asterisk so your Proxy will have to run on port 5060. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Outgoing SIP calls dropped after 30 seconds.
To get to the bottom of it I'd recommend determining why the ACKs are not getting through to Asterisk rather than trying to work around it. I'm actually suprised Asterisk terminates the call by default when it doesn't get the ACK to it's 200 Ok response that must be new for 1.4.22 as I haven't seen that behaviour in earlier versions. In my opinion it's unwarranted behaviour, if Asterisk is getting RTP then it should leave the call up irrespective of whether it gets an ACK or not. From the original SIP trace the ACK does not appear to be arriving at your Asterisk server at all. Try doing a packet trace on the network segment where the calling SIP agent is and see where it's trying to send the ACK to. My guess would be your firewall is incorrectly handling the SIP messages. Generally it's very bad news to use an ALG or firewall to mangle SIP packets as they almost always get it wrong. In your case there is a Record-Route header in the response so the ACK request should be being sent to that address. Perhaps your firewall is not correctly mangling that to allow the request to find its way back to your Asterisk server. Record-Route: sip:216.82.224.202;lr;ftag=as3ed791f3 Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Providing Ringback
Hi Igor,
We had an interconnect with a carrier that generated early media for
progress indications but the carrier's switch, in this case a Cerpack,
would only start sending the RTP for the early media AFTER it received
an RTP packet from the Asterisk end. Completely stupid behaviour since
early media is generally only one way but that's what it did.
We worked around it by recording 200ms of silence and playing that
back to the carrier's Cerpack with the Background command whenever we
received an incoming call. This got two way RTP set up and allowed the
progress tones to be correctly passed through to the user.
[noringback]
exten = _X.,1,Background(/var/lib/asterisk/custom-sounds/silence_200,n)
exten = _X.,2,Goto(incoming, ${EXTEN}, 1)
Regards,
Greyman.
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SER + Asterisk
As far as I'm aware SER (and it's derivatives) cannot initiate outbound registraitions. They can do the opposite and act as a SIP Registrar. For outbound registrations you should be able to use Asterisk. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] RTP sent before the INVITE ACK (for voicemail app)
On Wed, Oct 1, 2008 at 5:37 PM, tic tac [EMAIL PROTECTED] wrote: Thanks, in my case though it looks like the originating party (polycom softphone) is hearing a clipped voicemail prompt because of that; should I look into having that fixed into their firmware? As a workaround, I was thinking to just add a few seconds delay in app_voicemail, or wait through AGI before calling voicemail, makes sense? Yes. It's fairly standard practice to add a Wait(2) or Wait(3) at the start of a call Asterisk is generating direct audio on. This gives the RTP stream a chance to get sorted out. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] RTP sent before the INVITE ACK (for voicemail app)
CLI output does not show any error that I see. Is there any reason other than a SIP 183 that would trigger this and isn't asterisk supposed to ACK/answer the channel before playing any prompt? Asterisk wil start the audio as soon as it sends back the 200 Ok response it doesn't wait for the ACK. Most SIP servers will work like that. The matching of ACK requests to a SIP transaction is not a particulalrly robust mechanism (for instance if a user agent puts its IP address in the Call-ID and a SIP ALG fiddles with the SIP packet for INVITEs but ignores ACKs then there will be a mismatch. This happens more frequently then you would think) so sending RTP after an OK response is the correct thing to do. I think Asterisk will actually cut off the call after 32s if it doesn't get an ACK which is not such a great idea but that may have been changed in later versions. The arrival of an RTP packet from the remote end should be used as the definitive indication of an answered call not the ACK. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] test call generator
I've used both the Hammer Call Analyzer software and als to the Hammer XMS system which is a server that they install in your rack to do the packet captures and provide you with all sorts of statistics. I suspect the Empirix Hammer products would be able to take care of any load, monitoring or analysis scenarios you have including signalling and media. The price is going to be the issue. When we looked at the solution the Call Analyzer software was 5 figures and the XMS solution was 6. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
Shotgunning the use of IP addresses is foolish at best and lazy programming at worst. Imagine if the poeple writing browsers did that! The internet could end up with double or triple the traffic for no extra benefit not to mention the additinoal load on web servers etc. It's not particularly difficult to determine the best IP address for a piece of client software to use. Check the local machines default gateway, apply the subnet mask and then compare it against all the local IP's. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip forking needed for ekiga 3.0
On Fri, Sep 26, 2008 at 2:36 PM, Brian J. Murrell [EMAIL PROTECTED] wrote: Check the local machines default gateway, apply the subnet mask and then compare it against all the local IP's. Yeah? And if more than one matches? Then what? Use one of them! And if the network set up is too complex that that still causes problems do what the Ekiga guy told you and set the IP address you want to use in the config file. It's not a difficult situation. I have servers with 15 public IP addresses on them and manage to run SIP services no problems. I've read enough of the thread to know the Asterisk issue you are trying to describe is loop detection and not forking. Asterisk does support forking: Dial(SIP/user1SIP/user2) is forking. Not being able to handle duplicate requests from different IPs is loop handling and you'll already find bugs open about that. Oh? I like to make sure I've done my homework before ascending to sarcasm especially when I'm the one that requested Thots in the first place... Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] DNS Query Overload
Most distros come with a caching daemon. Still that's not really the point... If Asterisk has all of a sudden developed a habit of sending high volumes of nonsense DNS requests then it's a serious issue. Besides if the requests are different for each call the caching server is not going to help much and the downstream ISP is going to notice sooner or later. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Sip Info events
Hi Robb, Have a look in your features.conf file and see what keys you have enabled for transfers. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] dialplan reload and dropped calls
On Sat, Aug 16, 2008 at 2:57 PM, Todd Fulton [EMAIL PROTECTED] wrote: Hi All, This is just a basic question . . . but if I'm doing a CLI dialplan reload while in operation, do I risk dropping calls or affecting calls in progress? Nope. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] 2000+ user Asterisk PBX
On Sun, Aug 3, 2008 at 6:19 PM, Steve Totaro [EMAIL PROTECTED] wrote: Curious why you stay with postgres then, and not go with MySQL if you know in advance it is a problem and will bite you sometime? The other IT truism, it's not easy to change a production system. In our case we have a lot of business logic that hits the database for call credit checks, user account management, provisioning etc. etc. Have we used any SQL in that code that would break if switched from Postgresql to MySQL... probably not but we'd have to check and validate... You way want to look at extconig.conf and ODBC or whatever database driver and even hook up to a MSSQL cluster. While not inexpensive, it is is mission critical. If you can monetize one hour of downtime and then figure the MTBF (including all the pieces) and how long ot trouble shoot and get it back up, maybe that is worth quite a bit of money. If you can just say sorry, we were upgrading and the cost is only time, then that certainly dictates your direction. We use ODBC and extconfig.conf already and you're correct that from our Asterisk servers point of view we could switch to another database backend easily. There's no big reason that would stop us switching from Postgresql to MySQL or MSSQL to gain better fault tolerance but there are lots of little ones: - We have 4 years of effort and expertise invested in configuring and optimising the nuts and bolts of Postgresql and our underlying hardware which would be a lot to throw away. - Our database load is high enough that we wouldn't be able to just throw up a stock standard server and get away with it anymore. We use a dedicated fiber channel storage array hanging off a SunFire 4200 and I get nervous enough whenever change is mentioned in its vicinity so switching database products would be a big deal. - Most of our Asterisk servers are still 1.2 (the transfer CDR bugs prevent us from upgrading at this point) and if a 1.2 Asterisk server loses it's realtime ODBC connection you have to restart it anyway so even if your database fails over automatically you still lose the in progress calls when you restart Asterisk (maybe this could be overcome with some form of MySQL load balancer but then that's another thing that could fail). Asterisk 1.4 has fixed that problem and will automatically try and re-connect if it loses its ODBC connection taking advantage of automatic database failover, - An automatic fail over solution for Postgresql has always seemed just around the corner (SLONY has been around for ages but just never quite got there), - Our current failover situation is not that bad and our DBA can fail over to our secondary Postgresql databse at the flick of a switch i.e. 30 seconds post alert notification (we use the Postgresql archive log shipping to keep our secondary db in sync with our primary so that it's only ever a second or so behind). When coupled with the fact that we'd have to restart our Asterisk 1.2 servers anyway we wouldn't gain a tremendous amount by reducing those 30 seconds to say 1 second with a MySQL master/salve mechanism. Don't get me wrong I'd much prefer to have a situation where the database and Asterisk servers could failover automatically and would highly recommend anyone designing a system from scratch put that at the top of their list! Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] 2000+ user Asterisk PBX
On Sat, Aug 2, 2008 at 2:53 PM, Femi [EMAIL PROTECTED] wrote: Any 2000+ user Asterisk PBX installs out there? Please hit me off-list, I need some support on a 2000+ user Asterisk PBX with high availability and over 10E1s to PTOs If you're talking about 2000+ SIP users then I have some experience. When we got to 1000 users we replaced the Digium E1 cards with a Cisco AS5400 to make our echo and static problems go away (that was 3 years ago so the cards may have improved since then). Now we've largely replaced the Cisco AS5400 with an SS7 switch but that was more a business call related to supplier interconnect considerations than a technical one. Those Cisco AS5400's are fantastic pieces of kit, it's the only thing in our set up that we have never had even the smallest problem with in over 3 years! An AS5400 will be more expensive than a commodity server with 2 or 3 four port E1 cards which is the main drawback. At the time it was more expensive for us to be continuously troubleshooting static and echo issues and as mentioned above that situation may have improved. If you are talking SIP users the other thing you'll have to do is to move as much of the non-call related SIP traffic off Asterisk. That means a separate SIP Proxy and/or Registrar. We have split those two functions off onto separate boxes so that Asterisk only has to deal with SIP for call signalling and of course media which is what its big strength is. Finally you will need a nice big database box, realtime is the only practical way to run Asterisk for anything over a few hundred users. The SIP Registrar and Asterisk will both generate large loads on your database and it is the critical link in the chain. If your database has problems you can't get any calls out and if that's not bad enough all your user's ATAs registrations will drop off meaning you get a deluge of support calls. We use Postgresql which does a good job but the big problem with it is redundancy. Postgresql does not really have an industrial strength replication solution which means the time it takes to switch over from the primary to secondary database is a problem. MySQL seems to have a much better replication solution and Asterisk doesn't really need a lot of the advantages Postgresql has over MySQL such as better stored procedure support etc. So in summary the critical factors in my opinion are: 1. Good database, 2. Good quality solution ofr E1's, 3. Split off non-media related signalling from Asterisk. If you're not talking about 2000+ SIP users then you can pretty much disregard everything I've said :-). Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Realtime + SIP + MySQL: md5secret BROKEN
On Thu, Jul 24, 2008 at 11:04 AM, Walter Stanish [EMAIL PROTECTED] wrote: If someone could sort out this bug (or let me know if I'm missing something 'obvious' - a hard call with realtime documentation this sparse...) I'd be most grateful, since we require md5secret support to integrate with our existing users database. Welcome to Asterisk! It's highly unlikely you'll find anyone to find the bug for you unless someone is experiencing the same thing. There's no guarantee the bug is actually with Asterisk it could be with your database or somewhere in between. That's not to say it's not with Asterisk but there are a lot of people using realtime with MySQL so if it was a galring bug it would have been seen and logged already. If you do manage to track down the bug it will generally at lest get a response in a short amount of time once it's on the bug tracker. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Problems w/Asterisk Realtime + MySQL + SIP
On Mon, Jul 21, 2008 at 6:40 PM, Walter Stanish
[EMAIL PROTECTED] wrote:
[Jul 21 15:28:21] DEBUG[2028] chan_sip.c: Received REGISTER (2) -
Command in SIP REGISTER
[Jul 21 15:28:21] DEBUG[2028] chan_sip.c: SIP message could not be
handled, bad request: ZjFhZjZlNmZmZjM3OWFlYzE0MGYzZDYwYzJmODAwNDg.
It looks like Asterisk is unhappy with the SIP REGISTER request coming
from your softphone for some reason. It's very strange that it's
occurring for two different softphones though.
Trun on SIP debugging by typing sip debug on your Asterisk console
and then post up the 4 SIP messages invloved in the register
transaction so we can take a look and spot why it could be getting
rejected.
Sure.
Here's what happens when kphone starts up:
==
--- SIP read from 192.168.0.25:5060 ---
REGISTER sip:192.168.0.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.25;branch=z9hG4bK5760BF8C
CSeq: 35 REGISTER
To: Walter sip:[EMAIL PROTECTED]
Expires: 900
From: Walter sip:[EMAIL PROTECTED]
Call-ID: [EMAIL PROTECTED]
Content-Length: 0
User-Agent: kphone/4.2
Event: registration
Allow-Events: presence
Contact: Walter
sip:[EMAIL PROTECTED];transport=udp;methods=INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER
black*CLI
-
--- (12 headers 0 lines) ---
Using latest REGISTER request as basis request
Sending to 192.168.0.25 : 5060 (no NAT)
--- Transmitting (no NAT) to 192.168.0.25:5060 ---
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.25;branch=z9hG4bK5760BF8C;received=192.168.0.25
From: Walter sip:[EMAIL PROTECTED]
To: Walter sip:[EMAIL PROTECTED]
Call-ID: [EMAIL PROTECTED]
CSeq: 35 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: sip:[EMAIL PROTECTED]
Content-Length: 0
--- Transmitting (no NAT) to 192.168.0.25:5060 ---
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.25;branch=z9hG4bK5760BF8C;received=192.168.0.25
From: Walter sip:[EMAIL PROTECTED]
To: Walter sip:[EMAIL PROTECTED];tag=as59de1023
Call-ID: [EMAIL PROTECTED]
CSeq: 35 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm=asterisk, nonce=7864265a
Content-Length: 0
Scheduling destruction of SIP dialog '[EMAIL PROTECTED]' in
32000 ms (Method: REGISTER)
==
Kphone prompts for a password, then the following occurs.
==
--- SIP read from 192.168.0.25:5060 ---
REGISTER sip:192.168.0.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.25;branch=z9hG4bK36B0646C
CSeq: 36 REGISTER
To: Walter sip:[EMAIL PROTECTED]
Authorization: Digest username=walter, realm=asterisk,
nonce=7864265a, uri=sip:192.168.0.2, cnonce=abcdefghi,
nc=0001, response=10a7024959390c04b4d09c708fac6130, opaque=,
algorithm=MD5
Expires: 900
From: Walter sip:[EMAIL PROTECTED]
Call-ID: [EMAIL PROTECTED]
Content-Length: 0
User-Agent: kphone/4.2
Event: registration
Allow-Events: presence
Contact: Walter
sip:[EMAIL PROTECTED];transport=udp;methods=INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER
-
--- (13 headers 0 lines) ---
Using latest REGISTER request as basis request
Sending to 192.168.0.25 : 5060 (no NAT)
--- Transmitting (no NAT) to 192.168.0.25:5060 ---
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.25;branch=z9hG4bK36B0646C;received=192.168.0.25
From: Walter sip:[EMAIL PROTECTED]
To: Walter sip:[EMAIL PROTECTED]
Call-ID: [EMAIL PROTECTED]
CSeq: 36 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: sip:[EMAIL PROTECTED]
Content-Length: 0
--- Transmitting (no NAT) to 192.168.0.25:5060 ---
SIP/2.0 403 Forbidden (Bad auth)
Via: SIP/2.0/UDP 192.168.0.25;branch=z9hG4bK36B0646C;received=192.168.0.25
From: Walter sip:[EMAIL PROTECTED]
To: Walter sip:[EMAIL PROTECTED];tag=as59de1023
Call-ID: [EMAIL PROTECTED]
CSeq: 36 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0
[Jul 22 00:59:38] NOTICE[2414]: chan_sip.c:15049
handle_request_register: Registration from 'Walter
sip:[EMAIL PROTECTED]' failed for '192.168.0.25' - Wrong password
Scheduling destruction of SIP dialog '[EMAIL PROTECTED]' in
32000 ms (Method: REGISTER)
Really destroying SIP dialog '[EMAIL PROTECTED]' Method: REGISTER
==
Just to confirm, the password supplied was 'aaa'.
In MySQL md5secret = md5('aaa') and secret = 'aaa'.
Here's what happens with zoiper (one registration click only)...
==
--- SIP read from
Re: [asterisk-users] Problems w/Asterisk Realtime + MySQL + SIP
On Tue, Jul 22, 2008 at 10:32 AM, Walter Stanish [EMAIL PROTECTED] wrote: Any further ideas? Other than trying a different asterisk version, I'm feeling pretty stuck. Is there an equivalent of the Asterisk console odbc show command for MySQL? That would show you whether Asterisk has a connection yo your db. Can you post up the contents of your extconfig.conf for us to have a look at? Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Problems w/Asterisk Realtime + MySQL + SIP
On Mon, Jul 21, 2008 at 9:11 AM, Walter Stanish [EMAIL PROTECTED] wrote: [Jul 21 15:28:21] DEBUG[2028] chan_sip.c: Received REGISTER (2) - Command in SIP REGISTER [Jul 21 15:28:21] DEBUG[2028] chan_sip.c: SIP message could not be handled, bad request: ZjFhZjZlNmZmZjM3OWFlYzE0MGYzZDYwYzJmODAwNDg. Hi Walter. It looks like Asterisk is unhappy with the SIP REGISTER request coming from your softphone for some reason. It's very strange that it's occurring for two different softphones though. Trun on SIP debugging by typing sip debug on your Asterisk console and then post up the 4 SIP messages invloved in the register transaction so we can take a look and spot why it could be getting rejected. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Dialplan Action on Authentication
On Sun, Jul 20, 2008 at 11:31 AM, David Ashwood [EMAIL PROTECTED] wrote: Ok - thanks for the prompt answer Alex. I thought something might be available under the associated context connected with the IAX registration. So the only approach dealing with registrations would be a script running listening to manager events? If you configured Asterisk to use realtime you could set up a database trigger such that when Asterisk updated the FullContact field, i.e. registered, you could process some logic. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Not a valid SIP contact - Asterisk 1.4.21.1 Mitel SIP phones
2008/7/19 Mark Wiater [EMAIL PROTECTED]: Your problem is the Contact header coming back in the Mitel's Ok response. Contact:p:[EMAIL PROTECTED];tag=4881ea36-2ca-6747d965 Asterisk is not going to be able to parse that! It should be: Contact: sip:[EMAIL PROTECTED];tag=4881ea36-2ca-6747d965 I'd get your Mitel vendor to log a fault about that. It's a big problem as the Contact field is critical for further in-dialogue SIP requests such as transfer related requests and BYEs. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk + web services
On Wed, Jul 16, 2008 at 3:08 AM, Paul Belanger [EMAIL PROTECTED] wrote: List, We're working on an upcoming job that may require us to access a web service (WS). I'm curious to hear peoples thoughts on the best way to do this with asterisk. We'll be submitting a single number to the WS and it will return a success or error. One solution would be to write a simple perl script to interface into to the WS, and use SYSTEM() from asterisk to call it. Another may be to use the func_curl to do it too. If anybody have suggestions / ideas please post them. If you need to use a web service and return a SOAP payload then I'd strongly suggest using the FastAGI. I've always found the FastAGI interface simple and reliable and it allows you to put all your web service processing code into whatever development environment you are comfortable with. I am a heavier user of web services with Asterisk and FastAGI is the way I do it. By using FastAGI you'll also have a nice process separation boundary between you new logic and Asterisk. It's pretty likely you'll need to do a lot of changes to your logic at least in the short term and it's a lot easier to restart the FastAGI process then it is to re-start Asterisk when it has a bunch of live calls. And then of course you'll need to add security to your web serivces or the API will change etc. etc. Incidentally I do use Curl calls from Asterisk as well but not for web service end points. I use Curl to call a very basic HTTP server that returns a single integer value. That's a whole different kettle of fish compared to a web services API. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Tracking Call Time While in Dial()
On Sun, Jul 13, 2008 at 12:05 AM, Steve Edwards [EMAIL PROTECTED] wrote: On Sat, 12 Jul 2008, Douglas Garstang wrote: The person I am working is building a calling card. They want to allow the user to recharge their account when their time runs out (without hanging up the current call). I got no idea how to implement that. In addition, they don't want to charge the user for the time they spend recharging their account. So, they need to track multiple timers for the call. Would this work? Hack up meetme to add an option to time out after x seconds, set MEETME_STATUS to TIMEOUT and return to the dialplan. You can follow the w option to figure out how to pass the seconds. Then in meetme's main loop (in conf_run()), just check for when its time to leave. Use dial()'s G option to put both the caller (with the timeout) and the callee into a meetme. When the caller times out, the callee will hear the music on hold (please wait until the other party returns). The caller can top up and then return to the meetme. You can accumulate the time the caller is in the meetme. What happens if the caller can't top up and hangs up. Who pays for the callee leg? Would you need a second timer to abort the callee? Take a look at http://bugs.digium.com/view.php?id=6335. Myself and KNK both implemented two different real-time call control mechanisms for Asterisk but unfortunately the feature was not deemed useful enough to make it into Asterisk :-(. The patches are available though and can be applied if you really need the functionality. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk PBX How-to Guide for Amazon EC2
On Fri, Jul 11, 2008 at 7:50 PM, Ronald Lewis [EMAIL PROTECTED] wrote: I've just added a PREVIEW release of my upcoming how-to guide for Asterisk PBX on EC2. It is based on months of testing and evaluating Asterisk on EC2. It addresses all kinks and showstoppers that many people have experienced over the past year or so. Because this is a preview, it is not the final version of this guide. It is subject to change (format, copy, layout, etc.) To view and download this guide, please visit http://ronaldlewis.com/2008/07/08/asterisk-pbx-on-amazon-ec2-how-to-guide-almost-complete/ Please take this opportunity to test the guide and provide any feedback. The official release is set for Wednesday, July 16 and will be available on CloudCrunch. There's already 4 public images on ec2 mentioning Asterisk in their names so wouldn't it be easier to try out one of those rather than install all the bits and pieces on a base Linux image? An interesting paper on ec2 and Asterisk would be one that discusses what the call quality is like from both inside and outside the US. When I briefy ran up an instance at this time last year it actually seemed ok. From a provider's point of view running Asterisk on the ec2 cloud does pose some interesting questions. As a quick and dirty estimate if you assume one of the standard small ec2 instances could cope with 100 simultaneous g711 calls (I don't know if that is the case just guessing) then you'll chew up approx. 2MB/s (you pay for bandwidth both ways). Assuming that you'd then have 1MB/s average to account for quite and busy call times then it would be 3.6GB/hour or 86.4GB/day. At the Amazon price of $0.10/GB that's $8.64/day or $260/month. The server instance will cost you $72/month so total cost for 100/calls per month is $332. A typical dedicated server for $300/month is roughly equivalent to an ec2 small instance and comes with 500GB of bandwidth/month which is only a fifth of what's required but you could probably get the extra 2TB/month thrown in for $32/month making the dedicated server and ec2 prices the same. There are serious pros and cons between these approaches. With the ec2 you don't get a permanent static IP, with a dedicated server you do. With ec2 you could scale up and down between 1 server and 4 servers at the drop of a hat to save costs and cope with peak and quite times, with dedicated servers you're stuff with 12 or 24 month contracts for the number of servers you'd need under maximum load. And then of course the major factor for both is what the call quality will be like. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk PBX How-to Guide for Amazon EC2
On Sat, Jul 12, 2008 at 2:16 AM, Grygoriy Dobrovolskyy [EMAIL PROTECTED] wrote: Strange prices, look at ovh, 233€/m~~350$ And ovh provide a REAL unlimited. And I'm sure there will be someone somewhere who has a better deal as well. Whenever hosting gets mentioned in tech forums you always end up with lots of opinions (or pitches depending on how well they are disguised). My post was more in the vein of ballpark figures to compare the technincal merits of a grid approach, in this case manifested by Amazon's ec2, to a dedicated server approach for running a VoIP provider service using Asterisk. It's probably already gone off the OP's original topic enough now that they'll be people jumping up and down that this should be on the Biz list... Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] [asterisk-dev] Locking, coding guidelines addition
On Sat, Jul 5, 2008 at 7:47 PM, Russell Bryant [EMAIL PROTECTED] wrote: If you want to talk about locking improvements, then I'm more than happy to talk about them. Naming an application is useless. Let's talk about the technical details that make one approach better than the other. You have yet to bring any useful discussion to the table. From what I can gather the suggestion from the FS approach is that each Asterisk channel should be handled after by it's own unique thread and save the need for any locking on the channel data structures in the first place. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] [asterisk-dev] Locking, coding guidelines addition
On Sun, Jul 6, 2008 at 4:11 AM, Russell Bryant [EMAIL PROTECTED] wrote: On Jul 5, 2008, at 7:59 PM, Grey Man wrote: Having a thread per channel _absolutely does NOT_ remove the need for locking to synchronize access to channel data structures. It does if only one thread needs to access the channel data structures. Perhaps I should have been clearer about the use of channel. Rather than being the overall SIP channel or IAX channel driver I was referring to creating a new thread at the point a channel driver creates a new ast_channel structure. After the structure and new thread have been initialised by the channel driver the only thread allowed to access it the structure is its associated thread. At the end of the day we'd all like to see the locking issue eliminated from Asterisk. My worry would be that putting in place stringent guidelines dealing with the way channel data must be locked and unlocked will mean the problem will continue to occur every time a new developer adds an new module and is not aware, doesn't understand or forgets the guidelines. A more idealistic fix would be to provide a safe, simple way to access the channel data in the first place hence the suggestion of one channel struct pre thread suggestion which appears to be how FS have solved the problem. One of the very reasons this thread came up (again) is that one of the experienced Asterisk developers seemingly put some locks in wrong order pointing to the fact that the problem may possibly be with the locking mechanism rather than the developer. I don't pretend to have anywhere near the expertise you or others have in the architecture of the Asterisk core and am merely attempting to contribute. I do have my fair share of experience writing multi-threaded applications and the best locking mechanism crosses both problem domain and language. If such ideas have already been considered and aren't suitable fair enough I'm not trying to tell you how to do your job, i.e. it's not presonal :-). Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On Thu, Jun 26, 2008 at 8:21 PM, Steve Murphy [EMAIL PROTECTED] wrote: On Wed, 2008-06-25 at 22:50 +0100, Grey Man wrote: Hi murf, CDR start answer end 112 4 245 6 Well, time 3 does get lost, but I thought it might be nice to be able to link 1 2 by the coincident times and say, hey, that looks like a blind transfer! One point of dissatisfaction I have with these is the fact that SIP/snom dialed the second CDR, not DAHDI/1. But, if I change it, you won't know that DAHDI/1 was the guy that murf-eyebeam was talking to... tough choices. So, I take it from your above words, that you'd like the 1,2,3; 4,5,6; times on the two CDR's? If i've understood your call flow correctly the CDR's required are 1,2,6 and 4,5,6. The key point being that the first call made is up until both call legs are hungup (which is 6) whereas the CDR is reporting its duration as the time up until the blind transfer was initiated (which is 3). As far as using the CDRs to identify that a blind transfer has taken place my opinion would be that that is a secondary concern compared to getting the call records accurate. There seem to be a lot of cases where people are experiencing pain because of the incorrect CDRs for their billing but I'm yet to see a post where someone is kicking up a fuss because they can't easily identify whether a particular CDR was involved in a transfer. It's would be a nice to have whereas incorrect durations on the CDRs cost money. Can anyone lab this up for 1.2; I don't have enough phones, and I'm not eager to reconfigure the ones I've got for just one test ! Do you mean compare the differences between the CRDfix4 branch and 1.2? At the moment the blind transfer CDRs are the same for 1.2, 1.4 and CDRfix4 with all being incorrect in the same spot which is the duration on the first call leg. In case it's of any help if you have a Windows box available I have a tool that can initiate SIP calls and carry out blind and attended transfers with Asterisk. It does make testing a lot easier, I got tired of playing hopscoth on my phones as well, now I just click a button. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Warning: CDRfix branches about to be merged into 1.4, 1.6.0, trunk!
On Tue, Jun 24, 2008 at 4:28 PM, Steve Murphy [EMAIL PROTECTED] wrote: This is just a note that the fixes in the CDRfix4 and CDRfix6 branches are getting closer to being merged into 1.4, trunk, and 1.6.x. If CDR's are important to you, and you ignore this notice, then you deserve what you get! Hi murf, From some preliminary testing on the CDRfix4 branch it looks like the CDRs for attended transfers are now correct which is fantastic. For blind transfers the CDR for the first call leg is still incorrect with the duration only being recorded up until the point the transfer occurs. For people on the list following this bug my company got stung by this in the last week so there now appear to be some people out there actively looking for Asterisk systems to exploit. The incident for us was a user using attended transfers to place free calls through a 1.2 system. In the past we have had normal users stumble across the problem but in this case it was a directed attempt. So if like us you are a provider and use Asterisk and are required to support transfers it would be highly advisable to keep a close eye on things! Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] TRANSFER_CONTEXT ignored?
The TRANSFER_CONTEXT has only ever worked for blind transfers for me and gets ignored for attended transfers. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] trying directrtpsetup
On Sun, May 25, 2008 at 10:45 AM, ronald ramos [EMAIL PROTECTED] wrote: Hi, I recently installed asterisk, i used sterisk-1.4.20.1, i i set directrtpsetup to yes, no whow would i know if the rtp/media is not passing to asterisk. any tool or can u just sniff? You could type rtp debug on your console and if your call is in progress and you don't get a stack of rtp debug messages flying past then you will know the rtp is not going through your Asterisk server. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk semi-hangs
The main thing I have noticed over the years that causes temporary asterisk hangs is the DNS server asterisk is trying to use becoming inaccessible. If a network issue causes Asterisk to be unable to connect to the DNS server you will get the classic freeze on the console and then when the DNS server is accessible again a flood of messages. This could be your problem although if the console never comes back perhaps not. Hopefully 1.6 will be able to cope better with an unresponsive DNS and at the very least be able to continue running and carry out any tasks that aren't related to DNS lookups. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Incoming calls not being answered by asterisk
The first thing to do is type sip debug on the console and place the call from the Sipura. If you get a bunch of SIP messages flashing down your console you know the call is reaching Asterisk and it's most likely going to be an issue authenticating the call or a problem in your dial plan. If no SIP messages flash up then the call is not reaching your Asterisk server. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Call only for registered sip users...
On Tue, May 13, 2008 at 7:31 PM, equis software [EMAIL PROTECTED] wrote: What I need to configure in my * to permit make calls only registered sip users?? Nothing. You can't call unregistered SIP users since you don't have any contact information for them so therefore all your calls will only ever be to registered ones. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] New Asterisk Deployment - Need some tips
On Tue, May 13, 2008 at 12:17 PM, Matthew Ratliff [EMAIL PROTECTED] wrote: I'll be doing a new Asterisk deployment soon, and would like to gather your thoughts. Here are some items that need to be kept in mind: Support 800 phones (400 of which are analog) Concurrent calls ... ? but need to guess high so that the server can handle this. Voicemail will be required along with sending voice mail attachments to email server. Flash panel for switchboard operator. Needs to be a distributed server design for redundancy and fail-over. Will need to be integrated into an existing PBX until each building is switched over to use the Asterisk servers. If calling 911 from a building among multiple buildings, how can EMS find that person based upon the call? What type of data line should be used in this setup? T1? The physical network will support QOS and the like, so that is not an issue. What type of design/setup do you recommend for this? How about server resources...ie...CPU, RAM, Disk space. How about backups? Does imaging work best if a server were to fail? Any thing else you can think of? If this is a project for your work and it's your first Asterisk deployment then definitely don't go the big bang approach in the way you've outlined. If you do you could well be out of that job in 6 months! The first thing I'd recommend you do is find 10 or 20 people who are suitable as early adopters. The set up a single Asterisk server and give the early adopters a SIP phone each thats in addition to their normal desk phone and ask them to see how they go using the SIP phones for calls to each other, external calls and whatever else would make sense. Then 6 months and a lot of learning/experience/frustration later you'll know whether to get answers to your original questions or not. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is there a way to have Manager Bridge Channel without being connected
On Mon, May 12, 2008 at 9:44 PM, Sanjay Rajdev [EMAIL PROTECTED] wrote: Hello All, Is there a way to have Manager Bridge Channel to the specified extension without the channel being connected. In the current scenario the channel only bridges once the call get connected, it does not bridge when any service provider (telco) message is played. I want to record all call originated by manager even if a telco message is played. I think the only way you'll be able to do that is by capturing the RTP packets with a wireshark or tcpdump. The message from your telco sounds like it's early media (in the SIP World it's called Call Progress media) and as you point out it's generated without answering the call. Most of the time the early media is going to be a ring tone and hence very uninsteresting to record so I suspect no one has bothered to write an application for it. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AGI asterisk high balance
On Fri, May 9, 2008 at 5:19 AM, Al Baker [EMAIL PROTECTED] wrote: I think his connect/disconnect is going to take far longer than his 3 queries. The fact that Asterisk doesn't support sustained MySQL connection from the DialPlan is in fact quite a big deal that Digium seems to have its head in the sand about. And one of those things that SHOULD come up in those Is * Ready For Prime Time Threads I would not agree with that. Asterisk's primary purpose as a PBX is moving the media around and doing lots of clever things with it. Asterisk has lots of ways to do inter-process communication (AGI, FastAGI, MAPI, Dialplan Apps) so the fact that it may not be optimised for a purpose to what most of us use it for when there are good options available to do the same thing does not hold water. Now if you were to get me started on Asterisk and its CDR's I would throw in a moan or two ;-). In relation to timing how long the rates lookups take it's as simple as taking a timestamp at the start of your application and suntracting it from the timestamp when you're finished and spitting it out to a log file. As far as the lookup taking too long the application logic I use manages to lookup the rate using a combination of regular expressions and longet matches as well as interogate the customers call plans of which they can have multiple with differnet combinations of destinations in plans and pay as you go balances and return the time for the call in well under 100ms. The logic is in C# but even so I wouldn't expect Perl to be slow. I'd suggest timing how long your database calls are. At one point the credit checks I was doing started to go up over 1 second and it was purely down to the load on the database (Postgresql). Getting a bigger server fixed it. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk for larg
Can you some reasons for this? Would interest me a lot why SIP is better in a large Enviroment. than IAX. Because with IAX you cannot separate the signalling and media resulting in a complex scalability problem. With SIP you can deploy a SIP Proxy and level load calls across as many Asterisk servers as you like. For fault tolerance you can add another SIP Proxy or an IP load balancer in front of your SIP Proxy. With IAX you can't do any either of those (at least not easily, there is no equivalnet of a stateless SIP Proxy with IAX) since every call's signalling and media path is tied to each IAX server it passes through. The only way to scale IAX is to get a bigger server. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AGI asterisk high balance
If you've got anything but trivial AGI loads you should switch to FastAGI and put your business logic on a separate server to your Asterisk server. I use a deployment where a call could make up to 3 AGI requests per call before being put through (for things such as looking up accountcode, checking account credit, setting PSTN callerid). We monitor the time thw whole process takes and on average it's less than 100ms on an Asteisk server that peaks at 200 simultaneous calls (400 bridged) and 3 to 5 call set ups per second. The business logic processing the FastAGI calls is C# and .net which means Java would be able to handle it easily as well. The most likely bottleneck under high load will be your database. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Disable transfer on all calls
Thanks to your answers, but i found more beautiful way to do this - there is some system variable __TRANSFER_CONTEXT, which defines context to handle the transfered number, so you can create a new context and there you can do anything with transfered call - i just hang it up. It's only relevant for blind transfers. For attended transfers that mechanism won't work. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Graphing Jitter Packet loss and Latency for SIP Calls
On Fri, Apr 25, 2008 at 10:55 PM, Vikas [EMAIL PROTECTED] wrote: Requirement: Monitor the QOS for the SIP phones connecting to the voip server. Ideal solution: Browder based reporting software that I can install on the asterisk server (I use freepbx) and when I connect to this reporting engine it gives me the Jitter loss, packet loss and latency for each of the calls that the extensions connecting to this asterisk server make and receive. Network design: A. The sip endpoints: 6 polycom 650 phones in India connecting to an VOIP server. B. Network between the SIP endpoints and VOIP server: The Indian office has 5 different ISPs giving the internet connection. Each ISP has a different packet loss latnecy and Jitter and these change over time. So I want a way to be able to select the best ISP on a given day. C. VOIP server: hosted at he.net datacenter and acts as the gateway between the sip endpoints and the PSTN gateway. D. PSTN gateway: Broadvoice for outgoing calls and exgn.net for incoming calls on the 800 number Things I have looked at: 1. Wireshark - I did not find a good reporting engine which I can automate to collect data and then graph it. 2. Endian 2.2 3. IPCop I would really appreciate any insights on how to monitor the QOS. Thanks for your time, I doubt you'll find a good solution for free (if you do I for one would love to hear about it). My company looked at monitoring QoS about 18 months ago. We ended up evaluating on of the Hammer products from Empirix. At the time of the eval the product couldn't do much in real-time with QoS stats such as jitter and you could only collate general statistical information at the end of the call. Subsequent to our eval the product was enhanced to provide better real-time reporting and in the end I don't think there was too much it couldn't do. The drawback then came down to price which is hefty. I suspect the Empirix range of products won't suit your needs due to price but they could be worth checking out to give you a guide as to how QoS monitoring could be done. As an aside I beleive Digium are using the Empirix load tools in some kind of partnership arrangement to stress test Asterisk these days. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Disable transfer on all calls
Hi Danila, You can't turn them transfers off with Asterisk. The best option is to put a SIP Proxy in front of your Asterisk sever and block REFER requests. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] OT: Linksys devices send incorrect REGISTER
I would suspect it's an Asterisk issue and not a Linksys issue. We use a non-Asterisk registrar with 1000's of Linksys devices and don't have that problem. If you are starting to get a lot of registration traffic it would be a good time to look at a way at moving it off Asterisk. Asterisk is great for the media and feature side of the PBX but there are better solutions for signalling and registrations such as OpenSER. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] WARNING: Remote host can't match request NOTIFY to call on Audiocodes MP-124 FXS
For blind transfers Asterisk will send the call back to the dial plan
and into the TRANSFER (I think, could be a different name) context if
it exists. Within that context you can access the channel that was
answered on the original call using ${DIALEDPEERNUMBER}.
Note that this mechanism cannot be use for attended transfers as they
are not sent back to the dial plan for processing.
Regards,
Greyman.
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] func_curl.so Error on load
Oh, my; yes. Nothing drives me further up the wall than googling up a 17-posting thread on an obscure question I have, and having the last post be got it, thanks. The *price you pay* for other people helping you in the open source community is posting the final message saying what it was and how you fixed it. It's not optional, even just a little bit. Come to think of it, there is one thing: finding 17 different people asking variations of the same question in threads with no replies at all. Over 5 years. Yep, at least half a dozen times. I can think of one thing that would drive me further up the wall. Finding a post where someone claimed they had the solution but instead of posting it for all to benefit from instead carried on with inane comments! Or maybe you are trying to get to the 17 posts to prove your theory! Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP outboundproxy for asterisk
If you search the Asterisk bug tracker with outboundproxy you'll get a few hits. This is the latest one: http://bugs.digium.com/view.php?id=12006 The way I use outboundproxy is via realtime and apply it to each sipaccount. If you set the outboundproxy for each of your SIP accounts in sip.conf then when you dial that SIP account it should be sent via the outboundporxy address specified in sip.conf. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP outboundproxy for asterisk
This approach works well if one has a limited set of target endpoints, but becomes a show-stopper, if we have to generically allow any remote domain user to be called via our local outbound. Right? That's correct as far as I am aware, I have the same problem. To call arbitrary endpoints I go direct from the Asterisk server as I've never been able to find a way to get the calls to go through a SIP Proxy. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] call forking feature
Asterisk only allows a single contact per SIP account so to do forking you'll need to use two SIP accounts and put them both in the Dial command. Or you could use OpenSER. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP outboundproxy for asterisk
There are lots of different ways to configure Asterisk and SER to get them working together depending on what you want to do. The link below is not a bad starting point. http://www.voip-info.org/wiki-Asterisk+at+large Asterisk has outboundproxy and outboundproxyport settings that can be used in sip.conf but while they work to an extent there are bugs with using them that have been around for at least two years and in fact as fas as I can tell the outboundproxyport setting is ignored even though it gets parsed. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] CDR and transfers! :(
Hi Raul, CDR's for transfers are beyond the ability of Asterisk. http://lists.digium.com/pipermail/asterisk-users/2008-January/204856.html http://bugs.digium.com/view.php?id=11093 It's not something the powers that be want to think about a design for and the solution that's been suggested is to date it to use a different type of server software, such as a SIP Proxy, to generate the CDR's (something easy to suggest and complicated to do). You're not the only one affected by this and there is no fix. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] QOS for outgoing SIP calls
On Wed, Apr 16, 2008 at 11:49 PM, Simon [EMAIL PROTECTED] wrote: Hi There, We have our Asterisk box using a external SIP provider for outgoing calls over our DSL line. This seems to be going well... But i do have the ability to set some QOS ports in our linksystem DSL router... Its faily basic, so im wondering if it will help at all... We can specify High, Med, Low settings for: FTP, HTTP, Telnet, SMTP and POP3. Plus we have the ability to specify up to 3 ports for the same settings. Is this worth doing? If so, what ports should i specifiy? Hi Simon, You won't be able to get much use of your router's QoS if it can only set it via port number. By default Asterisk will select a UDP port somewhere in the range of 10,000 to 20,000 to carry the RTP. The port selected for the RTP will be different at your end and at your providers end which means you would need two QoS port rules per call. You can change the port range your Asterisk server uses for RTP in rtp.conf but there's probably not a lot of point given you can't prioritise a big enough range with only 3 rules available. To be of any practical use for SIP calls you really need to be able to set QoS by IP address. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PSTN to SIP
The Cisco's also support T.38 gateway functions whereas Asterisk can only do pass thru. Either way you'll still need another server, typically hylafax, to receive the faxes to get them somewhere useful. In my experience the Cisco switches are definitely the way to go for the ISDN/SIP gateway and then back it on to Asterisk for any PBX bells and whistles needed. If you've got more time and patience than money then a card in Asterisk for the ISDN gateway is an ok solution. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] C# SIP API to Comiunicate with Asterisk
On Thu, Apr 3, 2008 at 11:35 PM, [EMAIL PROTECTED] wrote: Do anyone has an idea about an open source SIP API written in C# that can communicate with Asterisk, to call out? There are a few C# SIP stacks around that will let you do that. Creating a call from such a stack to Asterisk will be the same as to any other SIP server. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] C# SIP API to Comiunicate with Asterisk
On Fri, Apr 4, 2008 at 12:11 AM, [EMAIL PROTECTED] wrote: Can you Please refer me to any, the one that I found are all either in Java/C. Or if they are in C# they are not opensource. I know www.mysipswitch is written in C# and can place SIP calls to Asterisk servers. The code is open sourced at http://www.codeplex.com/mysipswitch. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Howto connect to Cirpack softswitch with Asterisk ?
On Wed, Apr 2, 2008 at 9:11 AM, Robert Rozman [EMAIL PROTECTED] wrote: Hi, has anyone connected Asterisk to Cirpack softswitch sucessfully ? Any howto or more info about needed Asterisk SW and setup ? Thanks in advance, regards, Rob. We have a trunk supplier that uses a Cirpack switch. There weren't any real problems with the SIP side of things, I thin we used the P-Assert headers for callerid. There was an issue early on with getting progress tones as the Cirpack wouldn't sned the progress audio without first getting an RTP packet and Asterisk wouldn't send an RTP packet until the call was established (rightly so in Asterisk's case). That issue seemed to get fixed in an upgrade on the Cirpack firmware at some point since our interconnect was put in. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How many maximum SIP Registrations can Asterisk Handle
On Sun, Mar 30, 2008 at 8:31 AM, Abid Saleem Choudhary [EMAIL PROTECTED] wrote: Hi All, I am new to this community and just subscribed. We have Asterisk running in production but I could not find out in documentation as well as web that how many maximum number of registrations an Asterisk Server can support. We have it on a 1.4 GHz Processor, 2 GB RAM and 40 GB HDD IBM Server. Please suggest urgently. Depends a lot on a few factors the ones I can think of off the top of my head are: 1. The registration interval you use, the smaller the interval the greater the load but the better at keeping NAT connections open, 2. Whether you use the qualify setting to help with keeping NAT connections open, 3. Whether you are using realtime or a configuration file. 4. The load from calls, With a best case scenario the answers to the above questions would be: 1. 3600, 2. No, 3. Configuration file, 4. Minimal With that set up I'd guess that somewhere between 5,000 and 10,000 registrations would be something your hardware could handle. However it would be normal that once the number of SIP accounts gets to a certain point it becomes to painful to configure them via a config file which means realtime with it's database option comes into play. At that point you are better off taking the load from registrations away from Asterisk. Asterisk is not a particularly good SIP Registrar anyway so putting in something like OpenSER is a superior option. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] e164.org
Does anyone know if the e164.org ENUM service is still active? If anyone who has anything to do with the e164.org ENUM site monitors this list could you check your signup page as the Captcha's (the test to see if you are human) fails for both the text and audio tests every time. I'd post a message on the e164.org forums but the signup page there has the test missing altogether. Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP carrier billing technicalities
SIP Carriers will determine who you are by the username/password in the INVITE request or by using IP address authentication not by the B Number. Changing the B Number will not make any difference to the way you are billed. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Sip exten matching based on contact: sip header?
On Tue, Mar 25, 2008 at 4:04 AM, Mike Fedyk [EMAIL PROTECTED] wrote: It seems that the sip channel matching is based only on source IP address instead of also checking the contact: header as mentioned in the O'Reilly book. According to Asterisk 2nd edition it says about insecure ... If you set insecure=invite, you'll determine which peer to match on by comparing the IP address or hostname and port number to those provided in the contact field of the SIP header with the host and port options in sip.conf. If a match is found, authentication will not be required on the initial INVITE, and the call will be allowed. Hi Mike, I've never heard of Asterisk authenticating based on the Contact header. The Contact header set by client side user agents will often contain a private IP address and it's also possible it could contain a hostname so authenticating based on it would be a tricky proposition. My understanding of using insecure=invite was that ONLY the host and port would be used for matching the INVITE requests to an Asterisk SIP account entry rather than the username and secret. You could also use insecure=port to specify that the port, username and secret would all be ignored and only the host used when matching. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] when we try to add CURL code to file channel.c we get an error - undefined reference to curl_easy_init
On Mon, Mar 3, 2008 at 6:27 AM, Prashant Sharma [EMAIL PROTECTED] wrote: Hi Tilghman, Thanks for taking interest in my problem. I just want to send a http post request to my website without changing the dial plan. So I have added slightly modified http post code and some other code to channel.c got from curl/curl.h. After adding the code I compiled the asterisk code and got the error: channel.o(.text+0x): channel.c:: undefined reference to 'curl_global_init' Try adding the following above the first include in channel.c. It's what I've done in app_dial.c to get the Curl library to link properly. /*** MODULEINFO dependCurl/depend ***/ Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] load balancing
On Fri, Feb 29, 2008 at 2:01 AM, Ron [EMAIL PROTECTED] wrote: Hi All, If i have this kind of setup, what do i need to make it's load balance. [ asterisk 1 ] -- [ asterisk 2 ] -- [ asterisk 3 ] -- [ asterisk 4 ] | | | | - | mysql cluster | - I plan on doing it via DNS SRV only, but if a user register on asterisk 1 how can users at asterisk 4 reach that user. Thank You Regards, Ron Hi Ron, If you're using realtime each Asterisk server will know where every user is irrespective of which Asterisk server they registered on. The problem is NAT, if a client is behind NAT and registers on server 1 then server's 2,3 4 are unlikely to be able to get through to it. Last time I lookedthe Asterisk realtime engine doesn't record which server an account registered on in the database so the only option I can think of would be to forward an incoming call for a user to all 4 of your Asterisk servers that way the call will get through but if they are not behind NAT they'll get 4 incoming calls. Bascially it's messy using the set up you've got. What you really need is a SIP Proxy (assuming you're using SIP, if not it's even trickier). The SIP Proxy could load balance requests across your Asterisk servers. For calls destined for your users you can use the outboundproxy field in the sippeers table, by setting it to the IP address of your SIP Proxy server you can get Asterisk to forward all requests for a SIP account through the proxy (there is also an outboundproxyport setting but avoid it as it's been broken forever). There are a few gotchas with a SIP Proxy the main one being transfers. But if you can get away with not allowing transfers then you are best to do so as the CDR's Asterisk produces are wrong anyway. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] load balancing
On Fri, Feb 29, 2008 at 4:03 AM, Ron [EMAIL PROTECTED] wrote: Hi Greyman, Should it look like this now? Can i use 2 SIP Proxies just to make sure i have a backup? will that cause any problem again with regards to calling extension to extension? Extensions will register on the asterisk still? How about outbound calls to other SIP provider or a telcobridge, SIP proxy will handle that also? Basically asterisk will ask SIP proxy of everything? Will RTP stream still go thru asterisk? Also, i plan on setting these up as a Virtual PBX for multiple offices, which means company A can only use Trunks for A, B is for Trunk B etc etc. Does outbound to trunks have any issues? or problem is just basically calling extension to extension? [other voip provider][telcobridge] -- [pstn] || [ SIP Proxy ] | | | | [ asterisk 1 ] -- [ asterisk 2 ] -- [ asterisk 3 ] -- [ asterisk 4 ] | | | | | mysql cluster| Thanks Regards, Ron Hi Ron, Yep it starts to get tricky :). There will be slight difference depending exactly on what you need to accomplish. I work for a VoIP Proivder that provides services to users in internet land so our set up is designed for that. If you've got VPNs or are on a LAN things will be different. Two SIP Proxy's are definitely a good idea, you can load balance your users across them using DNS SRV records, DNS Round Robin, IP Load Balancer (although then you prob should have two load balancers). If you're just starting your build network build or only have 1000 users the extra SIP Proxy should go to the bottom of the list. SIP Proxy's such as OpenSER are pretty stable and don't do anywhere near as much work as the media server. It's the fault tolerance on your Asterisk servers that is the most critical thing. They do a lot more work and in my experience with them (4+ years) they are a lot more likely to crash than your SIP Proxy. With two SIP Proxy's you have an additional problem in that now you need to set the outboundproxy field in the Asterisk realtime database to the value of the proxy the user agent came through. Asterisk can't do that for you (as far as I know) so you could possibly use the SIP Proxy to do registrations or use a custom SIP Registrar. Both are a good idea as they take registration load away from Asterisk and this can be VERY significant as your user base grows. We use a custom SIP Registrar. For outbound trunking we go directly from Asterisk to the terminating gateway no SIP Proxy involved. For inbound trunking we do go through the SIP Proxy for the same reason you get users to. Incoming calls are going to be more reliable if they are not tied to a single Asterisk server (I guess you could use SRV records for your Asterisk servers for inbound trunking as well but then you're kind of duplicating the role of the SIP proxy). The RTP stream will always be between the users and Asterisk the SIP Proxy is never invovled. If you send an RTP packet to a SIP Proxy and it will just shake its head in an irritated manner and ignore you. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] load balancing
On Fri, 29 Feb 2008 6:21 +0200, Yehavi Bourvine +972-8-9489444 [EMAIL PROTECTED] wrote: See the discussion a few days ago. The Asterisk server saves the value of SYSNAME (defined in asterisk.conf) in the field REGSERVER inside MySQL. Regards, __Yehavi: Ahh that's handy. That would allow a half way solution between multiple Asterisk servers and a SIP Proxy by utilising an AGI script or database lookup in each Asterisk server's dialplan. When the incoming calls arrive you'll be able to know which Asterisk server to forward them to. You still have the problems about failing over the Asterisk servers and putting two Asterisk servers in the media path is always best avoided if possible although probably not a huge deal. Actually from memory there is something in sip.conf regarding autoregexten or something where when a SIP account registers with Asterisk it automatically adds an entry to the dialplan. If this were employed you could forward a call to all 4 Asterisk servers and only the one that had the registered user would forward the call. There are lots of ways to skin the cat but the SIP Proxy is the best way to utilise mutliple Asterisk servers when being used for SIP calls. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk Manager and Visual Basic
- Original Message From: Bill Andersen [EMAIL PROTECTED] To: asterisk-users@lists.digium.com Sent: Wednesday, 13 February, 2008 8:31:01 PM Subject: [asterisk-users] Asterisk Manager and Visual Basic Has anyone tried to used VB6 to communicate with the Asterisk Manager? If so, would you be willing to share some basic code showing your approach to getting connected and parsing results? I've got a Telnet control that is allowing me to connect, authenticate and see the flow of status, etc., but I'm sure there is a better way to do this without using Telnet (maybe not?). Any suggestions? Hi Bill, I don't know if it would be of any use to you but we have some C# code that handles the basics of communicating the the Asterisk Manager Interface. It doesn't do anything fancy just sends single commands and checks the responses. We don't use it for monitoring. Regards, Greyman. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] External MWI question for Asterisk
- Original Message From: Olivier [EMAIL PROTECTED] To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Saturday, 9 February, 2008 6:55:15 AM Subject: Re: [asterisk-users] External MWI question for Asterisk Do you mean your script does send a NOTIFY messages to hardphones ? Then, how did you write such SIP-aware script (language, ...) ? If not, how external script and Asterisk do communicate ? Our MWI program is written in C# but to send SIP NOTIFY requests is very straight forward and could be done in anything. Our program is 250 lines of code and that includes polling the database to decide when to send the NOTIFY requests. In the NOTIFY request the body consists of: Messages-Waiting: yes|no That's all you need to turn on and off the MWI indicators on every device we've come across. There's nothing tricky to MWI at all. Regards, Greyman. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] External MWI question for Asterisk
- Original Message From: Olivier [EMAIL PROTECTED] To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Wednesday, 6 February, 2008 7:35:10 AM Subject: Re: [asterisk-users] External MWI question for Asterisk Do you send those notifications to SIP hardphones ? Then, how do you proceed ? Is there a standard way to make (or stop) a SIP hardphone Message Waiting Indicator blinking ? Hi Olivier, Yes we send MWI notifications to all user agents on our service which include IP Phones and ATAs. We use the externnotify option in voicemail.conf to pipe out to an external script everytime a voicemail is checked. That script does a few things that allows our MWI service to know that there are no longer any new voicemails for a specific and a NOTIFY request is sent to the user agent to turn the MWI off. Regards, Greyman. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Goto in Realtime extensions
I would have been happy ... but it's not that. This query gives me the right row (I double checked). Make sure you don't have any labels on the prioritys. When loading extensions from realtime labels aren't supported. Replace: exten = _X.,1(mylabel),... with exten = _X.,1,... You'll have to make your Goto's use the prioritty instead of the label afterward. Regards, Greyman. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] External MWI question for Asterisk
- Original Message From: Jason Crum [EMAIL PROTECTED] To: Asterisk Users Mailing List - Non-Commercial Discussion asterisk-users@lists.digium.com Sent: Tuesday, 5 February, 2008 7:13:12 PM Subject: Re: [asterisk-users] External MWI question for Asterisk Gah. So currently in 1.4, there is no method of having Asterisk accept SIP NOTIFY from another server, and pass it on to endpoints if it matches? I can't imagine this being that complex, but then again I'm not familiar with the Asterisk internals. It just seems Asterisk would compare the SIP NOTIFY to what it has currently registered (sip show peers) and forward it on to the endpoint. I'm pretty sure sipXecs can do this. Hi Jason, We use Asterisk with realtime so that all the SIP peer's contact URI's are recorded in a database. Our separate MWI service then is able to lookup where to send the MWI notifications to and doesn't need to involve Asterisk in their sending. Regards, Greyman. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
