Results 1 to 4 of 4

Thread: GP 2.x VOIP issues with Cisco CallManager 7

  1. #1
    devguy Guest

    Default GP 2.x VOIP issues with Cisco CallManager 7

    Hi,

    I wonder if anybody has tried to use Pika VOIP/SIP (GP 2.8/AoH 2.8) with Cisco CallManager v7.

    I've run into what looks like issues with the SDK itself. Using latest 2.8.13 for both GP and AoH.
    Issues i'm seeing:


    1. Issuing a PKX_Call_Reject in response to PKX_EVENT_GROUP_INCOMING_CALL results in a crash in libpikagpgwy.dll (actual fault in dll that kills the app). I canít test it with gptest since gptest auto-answers the incoming call. However in my own app i'm seeing the windows crash as well as an accompanying message in the windows event log.

    App works fine with Asterisk hence i don't believe it to be app problem but rather Pika SDK inability to deal with something that CallManager does or data it returns.





    2. Attempting a bridgetransfer results in a crash in the pikahmpapi.dll. This one is easily reproducible using gptest by dialing 2 lines and then attempting bridgetransfer on them. Again it crashes gptest and there is an accompanying message in the windows event log. This one again works fine on Asterisk and also works on CallManager v6 also - issue is with v7 only.


    It thus appears to me like a bug in SDK - at the very least i'd expect SDK to handle the error and possibly propagate it up to my app code but it actually faults and crashes out.

    Any ideas or suggestions?


    I do have additional info available in terms of error screenshots and logs and they are available from here for anyone inerested :

    http://downloadtemp.s3.amazonaws.com...dll_errors.zip


    I don't have Pika support plan at the time to send it to them and hard time justifying the fairly high cost for basic plan for something that does not seem to be our issue (since we can reproduce the 2nd issue using using just SDK + GPTEST app; and that it only fails with one specific pbx) but rather a defect in their side.
    Regards,
    Raul

  2. #2
    awayte Guest

    Default

    Hi Raul,

    Thank you for your forum contribution.

    I have gone over the logs you provided and I can see the specific behavior in each case that's casing problems in the GrandPrix SDK.

    In the first scenario you encounter an exception after a call to PKX_CALL_Reject when a PKX_EVENT_GROUP_INCOMING_CALL event is raised. The root cause of the problem is that the Cisco Call Manager V7 is sending in an INVITE request without an SDP payload. When the PKX_CALL_Reject function is called a 603 Decline is sent, when the ACK is received from Cisco there is some unexpected handling in GrandPrix caused by the missing SDP payload in the original INVITE. I have raised the issue with design.

    In the second scenario the Cisco Call Manager V7 sends a NOTIFY request to GrandPrix with 'sipfrag' content indicating the progress of the requested transfer. Before GrandPrix can respond to the NOTIFY a re-INVITE (Hold) request is received. Receiving the 'Hold' request at this time is causing issues in GrandPrix's response handling. I have also raised this issue with design.

    Thanks Again!

    Adam

  3. #3
    devguy Guest

    Default

    Thanks Adam for checking out the logs and forwarding it to the design!

    I have worked around the 1st issue by doing PKX_CALL_Answer, wait for that to complete and then just issuing a PKX_CALL_Drop.

    For the 2nd issue i'll have to wait for new version of GP/AOH i guess.

    Thanks again
    Raul

  4. #4
    awayte Guest

    Default

    Hi Raul,

    On a side note, I thought you might to know how to change the channel behavior in GPtest for future testing.

    The command goes as follows:

    channel <id> set config behavior=<type>

    <id> = channel number and can be a range like 0-29.

    <type> = The desire behavioral setting when GPtest receives a call. Valid values are 'autoanswer', 'autoreject', 'autoaccept' and 'none'.

    'autoanswer' is set on by default.

    In your case for SIP if you do not want GPtest to respond with anything but '100 Trying' then use type 'none'.

    So if you want to set this behavior for channels 0-9 you would enter this:

    channel 0-9 set config behavior=none

    Hope this helps!

    /Adam

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •