ISSUE:
In my application I place a call from a CTI port to an extension. When that extension answers I try to conference that call into another existing call using the lineDevSpecific callJoin functionality. I keep getting a LINEERR_INVALCALLHANDLE response when I call lineDevSpecific() even though I'm confidant I'm using the correct call handle. My code looks like this:
| CCiscoLineDevSpecificJoin callJoin; |
callJoin.m_CallIDsToJoinCount = 1;
callJoin.m_CallIDsToJoin[0].CallID = tapiCall->GetCallID();
ret = lineDevSpecific(lineHandle, 0, callHandle, callJoin.lpParams(), callJoin.dwSize());
Where the lineHandle is the handle of the CTI port and the callHandle is the call handle of the CTI port's call. The call ID to join is the call ID of the call I'm trying to conference with. Am I missing something here?
SOLUTION:
I would request you to try using lineSetupConference() function
JOIN:
In Cisco Unified Communications Manager, the Join softkey joins all the parties of established calls (at least two) into one conference call. The Join feature does not initiate a consultation call and does not put the active call on hold. It also can include more than two calls, which results in a call with more than three parties.
Cisco Unified TSPexposesthe Join feature as a new device-specific function that is known as lineDevSpecific()– Join. Applications can apply this function to two or more calls that are already in the established state. This also means that the two calls do not need to be set up initially by using the lineSetupConference() or linePrepareAddToConference() functions. Cisco Unified TSP also supports the lineCompleteTransfer() function with dwTransferMode = Conference. This function allows a TAPI application to join all the parties of two, and only two, established calls into one
conference call. Cisco Unified TSP also supports the lineAddToConference() function to join a call to an existing conference call that is in the ONHOLD state. A feature interaction issue involves Join, Shared Lines, and the Maximum Number of Calls. The issue occurs when you have two shared lines and the maximum number of calls on one line is less than the maximum number of calls on the other line. For example, in a scenario where one shared line, A, has a maximum number of calls set to 5 and another shared line, A’, has a maximum number of calls set to 2, the scenario involves the following steps:
A calls B. B answers. A puts the call on hold.
C calls A. A answers. C puts the call on hold.
At this point, line A has two calls in the ONHOLD state, and line A’ has two calls in the
CONNECTED_INACTIVE state.
D calls A. A answers.
At this point, the system presents the call to A, but not to A’. This happens because the maximum calls for A' specifies 2.
A performs a Join operation either through the phone or by using the lineDevSpecific – Join API to join all the parties in the conference. It uses the call between A and D as the primary call of the Join operation. Because the call between A and D was used as the primary call of the Join, the system does not present the ensuing conference call to A’. Both calls on A’ will go to the IDLE state. As the end result, A’ will not see the conference call that exists on A.
JOIN ACROSS LINES(SCCP):
This feature allows two or more calls on different lines of the same device to be joined through the join operation. Applications can use the existing join API to perform the task. When the join across line happens, the consultation call on the different line on which the survival call does not reside will get cleared, and a CONFERENCED call that represents the consultation call will be created on the primary line where conference parent is created. This feature should have no impact when multiple calls are joined on the same line. This feature is supported on SCCP devices that can be controlled by CTI. In addition, this feature also supports chaining of conference calls on different lines on the same device. Also, a join across line can be performed on a non-controller line; that is, the original conference controller was on a different device then where the join is being performed.
N.B: This feature returns an error if one of the lines that are involved in the Join Across Lines is an intercom line.
JOIN ACROSS LINES(SIP):
This feature allows two or more calls on different lines of the same device to be joined by using the join operation. Applications can use the existing join API to perform the task. When the join across line happens, the consultation call on the different line on which the survival call does not reside will get cleared, and a CONFERENCED call that represents the consultation call will get created on the primary line where conference parent is created. This feature should have no impact when multiple calls are joined on the same line. This feature is supported both on SCCP and SIP devices that can be controlled by CTI. In addition, this feature also supports chaining of conference calls on different lines on the same device. Also, a join across line can be performed on a non-controller (the original conference controller was on a different device then where the
join is being performed) line.
This feature returns an error if one of the lines involved in the Join Across Lines is an intercom line.
Comments
0 comments
Please sign in to leave a comment.