Problem with API methods in version 5.0.1

[maycol]

Some methods that were operating in version 4.6.1, fail in version 5.0.1

We have upgraded the system to version 5.0.1 and after updating some methods no longer work.
I'm correcting the requests, but the following does not work:

Request:

Code: Select all

<request method="switchvox.extensions.search">
  <parameters>
    <min_create_date>2011-01-01 01:01:01</min_create_date>
    <max_create_date>2011-04-01 01:01:01</max_create_date>
  </parameters>
</request>

Response:

Code: Select all

<response method="switchvox.extensions.search">
   <errors>
      <error code="10000" message="Can't call method &quot;translate&quot; on an undefined value" />
      <error code="10000" message="Can't call method &quot;translate&quot; on an undefined value" />
   </errors>
</response>

Where is the error?

Thanks. Best regards.

[dpodolsky]

I verified the issue and have added it to our bugtracker to fix. The issue is only when using the dates, if you call the same API with min_extension / max_extension or no parameters at all then this will work fine. To work around your current issue I would suggest calling it with no parameters and you will get all extensions back and then filter by date_created.

You mentioned "some methods" weren't working? If you have more please send them to me and I will investigate.

Also I suggest upgrading to 5.0.2 which was released earlier this week that has a couple bug fixes in it.

[maycol]

Thank you very much for responding.
We are testing some methods, if we find a issue will be posted.

Regards

[maycol]

According to my tests, the method "switchvox.users.currentCalls.getList" has a different behavior and sometimes fails, I might be using it wrong.
In version 4.6.1 works very fast and the parameter '<account_id>' could be any account number and could be different from '<requested_account_id>'.
Now in version 5.0.2 the method is slow and fails with some accounts. But it works perfectly if the parameters '<account_id>' and '<requested_account_id>' are equal.

Request:

Code: Select all

<request method="switchvox.users.currentCalls.getList">
    <parameters>
        <account_id>1122</account_id>
        <requested_account_id>1122</requested_account_id>
    </parameters>
</request>

Immediate response:

Code: Select all

<response method="switchvox.users.currentCalls.getList">
   <result>
      <current_calls channel="SIP/223">
      </current_calls>
   </result>
</response>

Another request:

Code: Select all

<request method="switchvox.users.currentCalls.getList">
    <parameters>
        <account_id>1121</account_id>
        <requested_account_id>1122</requested_account_id>
    </parameters>
</request>

Response after waiting 10 seconds:

Code: Select all

<response method="switchvox.users.currentCalls.getList">
   <errors>
      <error code="22400" message="Switchvox encountered a problem.  No changes were made." />
   </errors>
</response>

Why does this happen? In the version 4.6.1 did not happen.

Sorry for my English.
Regards

[maycol]

Hi.
I found another difference in the new version.
Before the 4.6.1 version, when we perform a call of extension to extension, the connection was immediate, now in version 5.0.2 it takes 12 seconds to connect to the other extension.
Is it normal to happen?

Regards.

[dpodolsky]

This is not normal. Are you using the API for these calls or just normal extension to extension via phones? I would contact technical support and they will be able to help you review your configuration and diagnose the issue.

[maycol]

in both ways there is delay

[maycol]

What happened to the method "Switchvox.call"?
We currently use the method 'switchvox.call' with 'switchvox.currentCalls.getList'. First we create the call and then retrieve the user's calls to obtain the information.
To create the call use the following request:

Code: Select all

<request method="switchvox.call">
   <parameters>
      <dial_first>222</dial_first>
      <dial_second>88708877</dial_second>
      <dial_as_account_id>1121</dial_as_account_id>
      <caller_id_name>test</caller_id_name>
   </parameters>
</request>

In response, the PBX calls to 222 and after answering, call 8870-8877. This works well.
But the problem happens with the method 'switchvox.currentCalls.getList'.
If I request the calls while the PBX is calling 222, this is the answer:

Code: Select all

<response method="switchvox.users.currentCalls.getList">
   <result>
      <current_calls channel="SIP/222">
          <line incoming_did="" caller_id_name="Michael Martinez" attached_text="" uid="e9b8538381" display_url="" status="ringing" recording="0" start_time="1309538381" src_chan="SIP/222-0a43e9b8" is_callback="0" dest_chan="Local/222~1121@pre_process_call_api-7710,2" context="" id="L|1" park_exten="" caller_id_num="222" />
      </current_calls>
   </result>
</response>

Then, if I request the calls answered after that 222 answered and while is ringing in 8870-8877, this is the answer:

Code: Select all

<response method="switchvox.users.currentCalls.getList">
   <result>
      <current_calls channel="SIP/222">
          <line incoming_did="" caller_id_name="" attached_text="" uid="" display_url="" status="" recording="" start_time="" src_chan="" is_callback="" dest_chan="" context="" id="" park_exten="" caller_id_num="" />
      </current_calls>
   </result>
</response>

Where is the call information?
In the version 4.6.1 worked fine!

[ptashka-berkut]

Where is the call information?

I second that question.

I'm using trial Switchvox SMB Edition
Version 5.0.2 (35592)

I get the same empty respose to switchvox.users.currentCalls.getList API call after I press Conference button on the phone. Once the phone is on the second call (before or after the conference is established) I get this responce:

Code: Select all

<response method="switchvox.users.currentCalls.getList">
   <result>
      <current_calls channel="SIP/392">
          <line incoming_did="" caller_id_name="" attached_text="" uid="" display_url="" status="" recording="" start_time="" src_chan="" is_callback="" dest_chan="" context="" id="" park_exten="" caller_id_num="" />
      </current_calls>
   </result>
</response>

So where is the call information?!

I also have another question: Is there a way to figure out that the 2 current calls are conferenced together other than going through the list of all calls in the system and matching my phone extension? I guess there isn't?

PS. Once the conference is established switchvox.currentCalls.getList returns the following:

Code: Select all

<response method="switchvox.currentCalls.getList">
   <result>
      <current_calls total_items="2">
         <current_call id="SIP/392-b541e640" from_caller_id_name="Sleeping Beauty" from_caller_id_number="392" to_caller_id_name="Unknown" to_caller_id_number="96135919002"  start_time="2011-09-21 13:25:34" duration="139" state="talking" provider="Unlimitel" format="g722-&gt;ulaw" />
         <current_call id="SIP/392-b5407e40" from_caller_id_name="Sleeping Beauty" from_caller_id_number="392" to_caller_id_name="The Beast" to_caller_id_number="391"  start_time="2011-09-21 13:26:24" duration="89" state="talking" provider="Internal" format="g722-&gt;ulaw" />
      </current_calls>
   </result>
</response>

[dpodolsky]

Looking into the empty response.

I also have another question: Is there a way to figure out that the 2 current calls are conferenced together other than going through the list of all calls in the system and matching my phone extension? I guess there isn't?

When you conference calls on the phone, the phone is taking both those calls and then merging the audio on the phone. The PBX doesn't know the phone has conferenced two calls it just thinks that the phone is talking to two people at the same time. The only way you could assume that the calls are conferenced is that the state if both the calls is "talking". The only way to "talk" to two people at the same time on most phones is to use the three way conference feature.

[ptashka-berkut]

Looking into the empty response.

Thanks for your prompt reply!

When you conference calls on the phone, the phone is taking both those calls and then merging the audio on the phone.

Understood.

The PBX doesn't know the phone has conferenced two calls it just thinks that the phone is talking to two people at the same time.

So if PBX sees that the phone is on 2 active calls, and it knows that the state of both calls is "talking", why couldn't it return some meaningful state instead of emptiness? E.g. Switchvox could return 2 <line> nodes - one per call, in which case it could also give me something for calls on hold (with status "waiting"). This would allow me to figure out what's going on without using switchvox.currentCalls.getList method, which requires admin credentials.

Another thing that could be very helpful: "call held" and "call retrieved/resumed" event notifications. Right now there is no way to figure out that the call was put on hold.

A little background:
I have a physical SIP phone connected to Switchvox box.
I am writing a desktop application which would allow me to do the following:
1. Login to switchvox (in other words, check user credentials)
2. Initiate an outgoing call.
3. Hang up current call.
4. Update my app state based on Switchvox event notifications (most basic: am I on call, ringing or idle?).

1. and 2. are not a problem.
3. and 4. I was able to implement easily for simple scenarios. Once on a conference (or on hold, or transfering, or anything else that involves complex telephony) both requirements become a pain to implement. Partially due to the problem reported in this thread, and partially because there is no clear mapping between JOB_ID and current call ID (aka src_chan). The later issue with ID inconsistencies was reported on this forum twice with no resolution so far:
http://forums.digium.com/viewtopic.php? ... dc#p130547
http://forums.digium.com/viewtopic.php? ... dc#p130526

Thanks again for your reply.

[danalmsa]

Hello,

Did you ever get to the bottom of this? It is still ocurring.

Thanks

[dpodolsky]

We did, and the fix made it into 5.5 which was released yesterday. Can you try upgrading to 5.5 and verify that this fixes your missing data problem. If it does, then I will update this thread as resolved.

The bug we found only affected these two APIs you were using. This wasn't a problem with any other APIs for the system and thus why it was not caught earlier. Thanks for the feedback to help us track this issue down.