Summary:	ASTERISK-09209: Queue uses minimum 4 channels, 2 calls, can not reinvite calls. possible g729 passthru violation.
Reporter:	Rudy K. (cyberglobe)	Labels:
Date Opened:	2007-04-06 02:21:22	Date Closed:	2011-06-07 14:03:14
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	After extensive testing, the queue system is currently using too many channels to bridge one call to an extension and because of this, could be a possible g729 passthru violation. The Passthru gets violated since Asterisk bridges 2 separate calls from different codes (eg: incoming TDM call is in G729 but Extensions are G711.) Therefore, * ends up transcoding in this instance. Also, Queues blocks any way of issuing reinvites to reduce the amount of channels and calls per actual call. Is there any way to ensure that: 1: the Queues when completed to an extension uses only 2 channels and 1 call path. 2: Ensure that there are no g729 passthru violations. 3: Ensure that reinvites function after an extension picks up the next queue caller. Could the queue code be recoded to support using the refer instead of invite via  a new call channel? Marked as major as many who are using g729 passthru might be in violation of the licensing agreement.
Comments:	By: Rudy K. (cyberglobe) 2007-04-06 02:35:38 After reading the RFC 3515 based on REFER, this seems like the best way to reissue the connection between Caller -> Queue Call 1 and Queue Call 2 -> Extension.  Just Refer Queue Call 1 to Queue Call 2 and therefore we would have 2 channels and 1 call instead of 4 channels and 2 calls per caller.   Would this be a possibility? By: Jason Parker (jparker) 2007-04-06 10:59:12 What is a "g729 passthrough violation"? You also don't really want to have the caller directly bridged to the queue member, because that would take the call out of the queue. By: Rudy K. (cyberglobe) 2007-04-06 11:48:10 passthru violation is if you need to transcode g729 to another codec. you only need to purchase a license if you are transcoding g729. for example, if you select your ATAs to use the g711 codec and your trunk is using g729, then there is transcoding done, in which case you need to purchase a license. however, if you select your ATAs to use the g729 codec and your trunk is using g729, then there is no transcoding done, hence no need for a license. Here is more information about it. http://www.voip-info.org/wiki/view/Asterisk+G.729+pass-thru By: Rudy K. (cyberglobe) 2007-04-06 11:54:30 Actually, If a caller makes it to my extensions, I actually do want them to get out of the queue.  Why leave them in the queue when their call is being answered? By: Jason Parker (jparker) 2007-04-06 11:54:40 It won't try to transcode if there are no licenses available.  If one channel *must* use g729 and the other *must* use something else, you will need a license regardless.  That issue is moot. As for bridging a call out of a queue, that is a very bad idea. By: Rudy K. (cyberglobe) 2007-04-06 12:31:02 [quote] It won't try to transcode if there are no licenses available. If one channel *must* use g729 and the other *must* use something else, you will need a license regardless. That issue is moot. As for bridging a call out of a queue, that is a very bad idea. [/quote] Unfortunately, it does as when you use the free implementation of the g729 codec available here: http://www.readytechnology.co.uk/open/ipp-codecs-g729-g723.1/  However I can understand your point. As for the bridging a call out of queue, why would anyone want to use 4 channels and 2 calls to handle 1 actual call?  It is a waste of cpu resources and if a caller has to go through 2-4 different queues, that means 8-16 channels and 8 calls just to handle 1 caller. Why would it be a bad idea to pull the call out of queue once the call has been answered by a rep?  Take a look at my example. Here is my scenario, We have a DSL connection and we have agents that are working from home and from their cellphones.  When a caller comes in, then goes out to one of those agents, it uses up 2 RTP channels in * present state.  If Queues could support reinvites, then those 2 RTP channels would not go over our connection, saving us on bandwidth to allow to handle more incoming calls. I don't see why a bridged call should stay within the queue after they have been answered in this type of scenario unless recording of the call is needed. What Bad thing would happen to the queue if after the call has been answered by a rep?  Constantly rering the rep?  It would show that they are busy since CW would be disabled. I do respect your valuable insight here. By: Jason Parker (jparker) 2007-04-06 12:37:56 There is no such thing as a free implementation of g723/g729 - we will not help you with the linked modules here. As far as I can tell, app_queue *will* bridge the audio, which will do the bandwidth savings you're talking about. If you reinvite a call out of a queue, you will completely lose all queue statistics. By: Rudy K. (cyberglobe) 2007-04-06 13:11:06 Ok Understand with g729.  that is now ignored. Interesting, cause I can not seem to make any calls bridge even though I have the extensions, and trunks setup with reinvite on for RTP.  I have tried numerous configurations.  Guess I will have to spend a little $ to call your support line to help me out in this instance? The RTP Data does not bridge in my instance.  Stays stuck in Asterisk.  tested g711, g729. Below is a snippet of my Queue code. extensions.conf exten => 110,1,Answer exten => 110,n,Set(__BLKVM_OVERRIDE=BLKVM/${EXTEN}/${CHANNEL}) exten => 110,n,Set(__BLKVM_BASE=${EXTEN}) exten => 110,n,Set(DB(${BLKVM_OVERRIDE})=TRUE) exten => 110,n,Set(_DIAL_OPTIONS=${DIAL_OPTIONS}M(auto-blkvm)) exten => 110,n,Set(__NODEST=${EXTEN}) exten => 110,n,GotoIf($["${CONTEXT}"="from-internal"]?USERCID:SETCID) exten => 110,n(USERCID),Macro(user-callerid,) exten => 110,n(SETCID),Set(CALLERID(name)=${CALLERIDNAME}) exten => 110,n,Queue(110|t||) exten => 110,n,dbDel(${BLKVM_OVERRIDE}) exten => 110,n,Set(__NODEST=) exten => 110,n,Goto(app-blackhole,congestion,1) exten => 110*,1,Macro(agent-add,110,) exten => 110**,1,Macro(agent-del,110,110) queues.conf [110] announce-frequency=0 queue-callswaiting= queue-thankyou=queue-thankyou queue-thereare= queue-youarenext= retry=5 rtone=0 strategy=ringall timeout=18 music=default monitor-join=yes announce-holdtime=no context= eventmemberstatus=no eventwhencalled=no joinempty=No leavewhenempty=yes maxlen=0 monitor-format= wrapuptime=0 sip.conf [1003] type=friend secret=secret record_out=Never record_in=Never qualify=yes port=5060 nat=no mailbox=1003@default host=dynamic dtmfmode=rfc2833 disallow=all dial=SIP/1003 context=from-internal canreinvite=yes callerid=device <1003> allow=g729,ulaw,alaw Using agentlogin to get into the queue. Anything else needed? By: Jason Parker (jparker) 2007-04-08 18:34:11 The problem is with your use of the 't' option to Queue() Closing.  Please contact a bug marshal on freenode IRC in the channel #asterisk-bugs if you need to reopen this report for any reason.