Re: [asterisk-users] AgentCalbackLogin not loging in race condition ?
Previous mail did not go through. Following up... Carlos G Mendioroz @ 16/09/2007 13:27 -0300 dixit: Hi, I'm seeing a problem using AgentCallbackLogin (Asterisk 1.2.16) where a call in queue while an agent is logging in results in the agent getting the call without properly being logged in. This seems to be a race, although I've not (yet) pinpointed the code at fault. And I'm not able to reproduce it 100% of the time. The perceived anomaly is that teh agent is logged of w/o request, but it seems it never got logged in. This only happens when logging in with calls already in queue. Any hints ? I'm going to make AgentCallbackLogin set the initial state to wrap to see if that patches the problem by the time being. Any hints are welcome. I did not find a way to go wrap on login, cause the logic is distributed between Queue and Agent, but I did find this comment at chan_agent.c: /* Ensure we can't be gotten until we're done */ gettimeofday(p-lastdisc, NULL); p-lastdisc.tv_sec++; It seems that the time it takes for the login ok message is more than one second, and is creating the trouble window. I changed that to allow 10 seconds of unavailability and the problem seems to be gone. -Carlos -- Carlos G Mendioroz [EMAIL PROTECTED] ___ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --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] AgentCalbackLogin not loging in race condition ?
Atis Lezdins @ 19/09/2007 06:05 -0300 dixit: On Wednesday 19 September 2007 11:43:39 Carlos G Mendioroz wrote: Previous mail did not go through. Following up... Carlos G Mendioroz @ 16/09/2007 13:27 -0300 dixit: Hi, I'm seeing a problem using AgentCallbackLogin (Asterisk 1.2.16) where a call in queue while an agent is logging in results in the agent getting the call without properly being logged in. This seems to be a race, although I've not (yet) pinpointed the code at fault. And I'm not able to reproduce it 100% of the time. The perceived anomaly is that teh agent is logged of w/o request, but it seems it never got logged in. This only happens when logging in with calls already in queue. Any hints ? I'm going to make AgentCallbackLogin set the initial state to wrap to see if that patches the problem by the time being. Any hints are welcome. I did not find a way to go wrap on login, cause the logic is distributed between Queue and Agent, but I did find this comment at chan_agent.c: /* Ensure we can't be gotten until we're done */ gettimeofday(p-lastdisc, NULL); p-lastdisc.tv_sec++; It seems that the time it takes for the login ok message is more than one second, and is creating the trouble window. I changed that to allow 10 seconds of unavailability and the problem seems to be gone. -Carlos Shouldn't wrapuptime be used in this case? Regards, Atis This is happening at login time. wrapuptime gets used after the agent handles a call. I do have wrapuptime set BTW. wrapuptime uses lastcall as reference, which is a Queue var. Login is an Agent process. I still do not understand the whole thing though... -- Carlos G Mendioroz [EMAIL PROTECTED] ___ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --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] AgentCalbackLogin not loging in race condition ?
Atis Lezdins @ 19/09/2007 06:53 -0300 dixit: On Wednesday 19 September 2007 12:11:19 Carlos G Mendioroz wrote: Atis Lezdins @ 19/09/2007 06:05 -0300 dixit: On Wednesday 19 September 2007 11:43:39 Carlos G Mendioroz wrote: Previous mail did not go through. Following up... Carlos G Mendioroz @ 16/09/2007 13:27 -0300 dixit: Hi, I'm seeing a problem using AgentCallbackLogin (Asterisk 1.2.16) where a call in queue while an agent is logging in results in the agent getting the call without properly being logged in. This seems to be a race, although I've not (yet) pinpointed the code at fault. And I'm not able to reproduce it 100% of the time. The perceived anomaly is that teh agent is logged of w/o request, but it seems it never got logged in. This only happens when logging in with calls already in queue. Any hints ? I'm going to make AgentCallbackLogin set the initial state to wrap to see if that patches the problem by the time being. Any hints are welcome. I did not find a way to go wrap on login, cause the logic is distributed between Queue and Agent, but I did find this comment at chan_agent.c: /* Ensure we can't be gotten until we're done */ gettimeofday(p-lastdisc, NULL); p-lastdisc.tv_sec++; It seems that the time it takes for the login ok message is more than one second, and is creating the trouble window. I changed that to allow 10 seconds of unavailability and the problem seems to be gone. -Carlos Shouldn't wrapuptime be used in this case? Regards, Atis This is happening at login time. wrapuptime gets used after the agent handles a call. I do have wrapuptime set BTW. wrapuptime uses lastcall as reference, which is a Queue var. Login is an Agent process. I still do not understand the whole thing though... Ok, my mistake. AgentCallbackLoging really doesn't add to queue. So, your agent is already in queue, when you do AgentCallbackLogin? Or how otherwise would you get call from queue? I'm not sure for static members, i'm using QueueAdd after AgentCallbacklogin. Regards, Atis Yup, agents are statically assigned to queues. So on login, they go from unavailable to not in use. And when this happens while calls are in queue... somehow sometimes the login gets aborted, so to say. -- Carlos G Mendioroz [EMAIL PROTECTED] ___ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --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] Queue serializes call delivery ?
This might be obvious, and well known, but... If I have 5 ready members and 5 calls in queue at once, Queue seems to deliver them one by one, blocking while waiting for each member to answer in turn. Is there anyway to speed this up (other than setting auto answer ?) I.e., I would like to have paralel calls to 5 members if I have 5 calls in queue... -- Carlos G Mendioroz [EMAIL PROTECTED] ___ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --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] PRI problem, pri_fixup_principle: Call specified, but not found? [SOLVED]
Issue was that zapata.conf was specifying trunkgroup for the spans. This was adding a DS1 Identifier to the setup channel ID, which the CO does not recognize and so it assigns its own pick of channel. This was causing a move which asterisk does not cope with. (Actually, initial channel id being exclusive explicitly forbids B channel being moved). As Matt said, configuration error. -Carlos Carlos G Mendioroz @ 24/05/2007 10:33 -0300 dixit: Here... Please advise if any special flags/options are needed. [ 02 01 01 27 ] Supervisory frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 019 P/F: 1 0 bytes of data -- ACKing all packets from 18 to (but not including) 19 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Unsolicited RR with P/F bit, responding Sending Receiver Ready (51) [ 02 01 01 67 ] Supervisory frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 051 P/F: 1 0 bytes of data -- Restarting T203 counter -- Restarting T203 counter T203 counter expired, sending RR and scheduling T203 again Sending Receiver Ready (51) [ 00 01 01 67 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 051 P/F: 1 0 bytes of data -- Restarting T203 counter [ 00 01 01 27 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 019 P/F: 1 0 bytes of data -- ACKing all packets from 18 to (but not including) 19 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter [ 02 01 01 b1 ] Supervisory frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 088 P/F: 1 0 bytes of data -- ACKing all packets from 87 to (but not including) 88 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Unsolicited RR with P/F bit, responding Sending Receiver Ready (6) [ 02 01 01 0d ] Supervisory frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 006 P/F: 1 0 bytes of data -- Restarting T203 counter -- Restarting T203 counter T203 counter expired, sending RR and scheduling T203 again Sending Receiver Ready (6) [ 00 01 01 0d ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 006 P/F: 1 0 bytes of data -- Restarting T203 counter [ 00 01 01 b1 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 088 P/F: 1 0 bytes of data -- ACKing all packets from 87 to (but not including) 88 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter -- Accepting AUTHENTICATED call from 10.8.0.6: requested format = alaw, requested prefs = (), actual format = alaw, host prefs = (), priority = mine -- Executing Dial(IAX2/10.8.0.6:4569-3, Zap/g2/113) in new stack -- Requested transfer capability: 0x00 - SPEECH [ 00 01 26 66 08 02 0e 89 05 04 03 80 90 a3 18 04 e9 82 83 81 28 08 43 61 72 6c 6f 73 20 4d 6c 06 41 81 31 31 30 30 70 04 c1 31 31 33 a1 ] Informational frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 N(S): 019 0: 0 N(R): 051 P: 0 41 bytes of data -- Restarting T203 counter Stopping T_203 timer Starting T_200 timer Protocol Discriminator: Q.931 (8) len=41 Call Ref: len= 2 (reference 3721/0xE89) (Originator) Message type: SETUP (5) [04 03 80 90 a3] Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Speech (0) Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16) Ext: 1 User information layer 1: A-Law (35) [18 04 e9 82 83 81] Channel ID (len= 6) [ Ext: 1 IntID: Explicit, PRI Spare: 0, Exclusive Dchan:0 ChanSel: Reserved Ext: 1 DS1 Identifier: 2 Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 1 ] [28 08 43 61 72 6c 6f 73 20 4d] Display (len= 8) [ Carlos M ] [6c 06 41 81 31 31 30 30] Calling Number (len= 8) [ Ext: 0 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) Presentation: Presentation permitted, user number passed network screening
[asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?
Hi, in a PRI setup, the receiving side is changing the B channel at proceeding. It seems this sometimes breaks some logic (pri_fixup_principle) and then the hangup kind of breaks, release is not answered and a restart cycle is triggered (by remote side). Anyone can help me debug this ? I've seen many posts with simmilar issues but no answer/solution. This is happening on Asterisk 1.2.16 + libpri 1.2.4 on a sangoma A104D. On a general side, where can I find a document (other than sources :) to start digging where the Zap-pri mapping is done and how, or at leaset what pri_fixup_principle is supposed to do... TIA, -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI problem, pri_fixup_principle: Call specified, but not found?
-- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter [ 02 01 72 2c 08 02 00 00 46 18 03 a1 83 88 79 01 80 ] Informational frame: SAPI: 00 C/R: 1 EA: 0 TEI: 000EA: 1 N(S): 057 0: 0 N(R): 022 P: 0 13 bytes of data -- ACKing all packets from 21 to (but not including) 22 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 0/0x0) (Originator) Message type: RESTART (70) [18 03 a1 83 88] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 8 ] [79 01 80] Restart Indentifier (len= 3) [ Ext: 1 Spare: 0 Resetting Indicated Channel ( 0) ] [ 00 01 2c 74 08 02 80 00 4e 18 03 a1 83 88 79 01 80 ] Informational frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 N(S): 022 0: 0 N(R): 058 P: 0 13 bytes of data -- Restarting T203 counter Stopping T_203 timer Starting T_200 timer Protocol Discriminator: Q.931 (8) len=13 Call Ref: len= 2 (reference 0/0x0) (Terminator) Message type: RESTART ACKNOWLEDGE (78) [18 03 a1 83 88] Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0 ChanSel: Reserved Ext: 1 Coding: 0 Number Specified Channel Type: 3 Ext: 1 Channel: 8 ] [79 01 80] Restart Indentifier (len= 3) [ Ext: 1 Spare: 0 Resetting Indicated Channel ( 0) ] -- B-channel 0/8 restarted on span 2 [ 00 01 01 2e ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 023 P/F: 0 0 bytes of data -- ACKing all packets from 21 to (but not including) 23 -- ACKing packet 22, new txqueue is -1 (-1 means empty) -- Since there was nothing left, stopping T200 counter -- Nothing left, starting T203 counter -- Restarting T203 counter T203 counter expired, sending RR and scheduling T203 again Sending Receiver Ready (58) [ 00 01 01 75 ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 058 P/F: 1 0 bytes of data -- Restarting T203 counter [ 00 01 01 2f ] Supervisory frame: SAPI: 00 C/R: 0 EA: 0 TEI: 000EA: 1 Zero: 0 S: 0 01: 1 [ RR (receive ready) ] N(R): 023 P/F: 1 0 bytes of data -- ACKing all packets from 22 to (but not including) 23 -- Since there was nothing left, stopping T200 counter -- Stopping T203 counter since we got an ACK -- Nothing left, starting T203 counter -- Got RR response to our frame -- Restarting T203 counter John Treble @ 24/05/2007 09:35 -0300 dixit: in a PRI setup, the receiving side is changing the B channel at proceeding. Please post the layer 3 trace for this call scenario so that members of this forum can help you debug your problem. John Treble Ottawa, Canada -Original Message- From: [EMAIL PROTECTED] [mailto:asterisk-users- [EMAIL PROTECTED] On Behalf Of Carlos G Mendioroz Sent: May 24, 2007 7:53 AM To: asterisk-users@lists.digium.com Subject: [asterisk-users] PRI problem, pri_fixup_principle: Call specified,but not found? Hi, in a PRI setup, the receiving side is changing the B channel at proceeding. It seems this sometimes breaks some logic (pri_fixup_principle) and then the hangup kind of breaks, release is not answered and a restart cycle is triggered (by remote side). Anyone can help me debug this ? I've seen many posts with simmilar issues but no answer/solution. This is happening on Asterisk 1.2.16 + libpri 1.2.4 on a sangoma A104D. On a general side, where can I find a document (other than sources :) to start digging where the Zap-pri mapping is done and how, or at leaset what pri_fixup_principle is supposed to do... TIA, -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Linux IAX client to zaptel voice quality issue
Hi, I've had a hard time understanding what was going on in a new * setup. The deployment has a * box running on dual xeon RH9 stock 2.4.20-8 and some different versions of asterisk (1.2.10/1.2.16) + libpri + zaptel + wanpipe. Short version: audio from iaxclient clients is fine from windows but poor from linux when going to zaptel. E.g. Iaxcomm running on windows works fine, but the same version of it running on linux has poor quality when going IAX-Zap-PRI (sounds like samples are being dropped ~4 times/second). Return audio is clear. This happens no matter what version of linux we tried. Finally a way of dealing with it was setting jitterbuffers in zapata.conf up to 10 from default 4. All audio is fine if zaptel is not used (i.e. iax to iax or iax to sip calls sound great). I don't really understand what the issue is, but one possibility is that somehow iaxclient is not being able to set correct timestamps in linux, and that in turn triggers some kind of correction in zaptel. FTR, clients are using DSP-400 headsets (although problem can be reproduced with other sound devices) and the problem also happens with analog TDM zaptel interfaces. Keywords: linux client iax zaptel voice audio quality -- Carlos G Mendioroz [EMAIL PROTECTED] ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
