Quantcast
Channel: Dialogic PowerMedia HMP GlobalCall and R4 API - Recent Threads
Viewing all 1151 articles
Browse latest View live
↧

DV_TPT

June 14, 2017, 2:31 pm
$
0
0

I'm using the D4PCI with GlobalCall on an Analog application and have few questions:

1. DV_TPT Structure: tp_length is limited to a value of 60000. Is it 60000ms or 60000 cycles/counts of the selected timer (10ms or 100ms) ?

2. Is it possible to mark a terminator as not used in the I/O operation ? can it be done by setting tp_length to Zero (for time related terminators) and TF_USE (for non time related terminators) ?

3. gc_WaitCall: since Rings parameter in not used on analog applications, how do I set the numbers of ring to wait before answering the call ?

4. gc_DropCall: do I have t use gx_ReleaseCallEx after every gc_DropCall ?


Any assistance will be appreciated - Thank You.

↧
Search

RE: HMP 4.1 su213 ssp_x86Linux_boot: null_cfsp.c: losing data.

June 15, 2017, 8:03 am
$
0
0

I really don't understand what is going wrong.

I set CPU affinity on ESXi host, installed VMware tools on the guest VM, configured ntpd on the host and on the guest, but nothing changed.

The only strange thing is that time synchronization between guest and host using VMware Tools capability seem to not work, and for this reason I disabled it and installed ntpd.

Roberto

↧
↧

RE: HMP 4.1 su213 ssp_x86Linux_boot: null_cfsp.c: losing data.

June 16, 2017, 8:24 am
$
0
0

How much memory and CPUs do you have assigned to the VM in this case?

Jeff

↧

HMP3.0 SU372 defect processing "record-route"

June 28, 2017, 5:20 am
$
0
0

Hi everyone.

Upgraded to SU372 from SU361 (Windows  2012 R2, SIP IP) and now system not honoring 200OK Record-Route in ACK response.

Please see SDPs below.

SU361:

Session Initiation Protocol (200)
Message Header
    Via: SIP/2.0/UDP XX:5060;branch=z9hG4bK-8adda-21e71cf7-62b67a91-f2dfa70
    Record-Route: <sip:XX@XX:5060;lr;transport=udp>
    To: <sip:XX@XX>;tag=XX
    From: <sip:XX@XX>;tag=f354110-28bbe7ad-13c4-65014-8adda-424034db-8adda
    Call-ID: f6cddc0-28bbe7ad-13c4-65014-8adda-d8b7d6d-8adda
    CSeq: 1 INVITE
    Contact: <sip:XX@XX:5060>
    Content-Type: application/sdp
    Content-Length: 213

Session Initiation Protocol (ACK)
Message Header
    From: <sip:XX@XX>;tag=f354110-28bbe7ad-13c4-65014-8adda-424034db-8adda
    To: <sip:XX@XX>;tag=XX
    Call-ID: f6cddc0-28bbe7ad-13c4-65014-8adda-d8b7d6d-8adda
    CSeq: 1 ACK
    Via: SIP/2.0/UDP XX:5060;branch=z9hG4bK-8addf-21e732a7-11bb28c9-f2dfa70
    Max-Forwards: 70
    Route: <sip:XX@XX:5060;transport=udp;lr>
    Contact: <sip:XX@XX>
    Content-Length: 0

SU372:

Session Initiation Protocol (200)
Message Header
    Via: SIP/2.0/UDP XX:5060;branch=z9hG4bK-2de14-b338012-6f95e20b-f5e5cb8
    Record-Route: <sip:XX@XX:5060;lr;transport=udp>
    To: <sip:XX@173.245.33.5>;tag=XX
    From: <sip:XX@XX>;tag=f92ef50-8858066b-13c4-65014-2de14-262e104a-2de14
    Call-ID: fa4bfc0-8858066b-13c4-65014-2de14-379e58e4-2de14
    CSeq: 1 INVITE
    Contact: <sip:XX@XX:5060>
    Content-Type: application/sdp
    Content-Length: 213


Session Initiation Protocol (ACK)
Message Header
    From: <sip:XX@XX>;tag=f92ef50-8858066b-13c4-65014-2de14-262e104a-2de14
    To: <sip:XX@XX>;tag=XX
    Call-ID: fa4bfc0-8858066b-13c4-65014-2de14-379e58e4-2de14
    CSeq: 1 ACK
    Via: SIP/2.0/UDP XX:5060;branch=z9hG4bK-2de19-b33926e-6e15d801-f5e5cb8
    Max-Forwards: 70
    Contact: <sip:XX@XX>
    Content-Length: 0

Please advise.

↧

RE: HMP3.0 SU372 defect processing "record-route"

July 6, 2017, 7:30 am
$
0
0

Anyone experiencing same issues or am I the only one here?

↧
↧

RE: HMP 4.1 - outbound INVITE Timeout

July 6, 2017, 7:39 am
$
0
0

Ok, the 64 seconds is a result of the retransmission timers set at the SIP stack level which can also be modified by the application when passing a SIP_STACK_CFG structure into the IP_VIRTBOARD pointer. Refer to chapter 10 sip stack cfg section in the GC IP TUG here:

www.dialogic.com/.../globalcall_for_ip_hmp_v12.pdf

Jeff

↧

RE: HMP 4.1 - outbound INVITE Timeout

July 6, 2017, 11:32 am
↧

HMP 4.1 - outbound INVITE Timeout

July 6, 2017, 4:28 am
$
0
0

Hi, 

I'm currently working with the RHEL version of HMP 4.1 and I'm currently trying to figure out how to set the outbound INVITE timeout.

I've created an application which makes outbound calls against a SIP gateway and that works as expected. However there may be times where the SIP gateway does not respond to the outbound INVITE and the application is left waiting for around 64 seconds before HMP generates IPEC_SIPReasonStatus408RequestTimeout.

Essentially, I'm trying to find the setting which controls the timeout so that I can be notified of any issues sooner rather than having to wait the 64 seconds. If anyone can advise or know what this value is then it would be greatly appreciated.

Thanks & Regards, 

Mike

↧
Search

make call - No Reply

July 6, 2017, 11:43 am
$
0
0

Hi,

I'm currently working with the RHEL version of HMP 4.1 and have created an application which makes outbound calls against a SIp gateway and when it is up the gc_MakeCall function makes and proceed with the call as expected.

However, I noticed that when the gateway is not available and the specific call disconnects with a SIP code such as IPEC_SIPReasonStatus503ServiceUnavailable then when I try to make another outbound call I get the following err-

GC ERROR: Function is not supported in this state
CC Name: GC_H3R_LIB
CC ERROR: IPERR_INVALID_STATE

I've tried to explicitly release the call using gc_ReleaseCallEx but this gives an error. Can anyone advise on how I should handle such as scenario?

Many thanks, 

Mike

↧
↧

RE: make call - No Reply

July 7, 2017, 12:39 am
$
0
0

Hi,

I have some more feedback on this - when I do the 1st makecall against the invalid gateway then I get the following error reported in the logs (this generates IPEC_SIPReasonStatus503ServiceUnavailable back to the application):-

07/07/2017 09:28:08.537   1391    83635056 sip_stack               Error        0x4fc2b70  ERROR  - TRANSACTION  - TransactionTransportTrxStateChangeEv - pTransc=0x0xf717afe0: Message failed to be sent (rv=0:OK)

07/07/2017 09:28:08.537   1391    83635056 sip_stack               Error        0x4fc2b70  ERROR  - TRANSMITTER  - SipTransmitterGetCurrentLocalAddress - Transmitter 0x0xf7167330 - Current local address was not set

07/07/2017 09:28:08.537   1391    83635056 sip_stack               Error        0x4fc2b70  ERROR  - TRANSMITTER  - RvSipTransmitterGetCurrentLocalAddress - Transmitter 0x0xf7167330 failed to get current local address (rv=-13)

When I try to make a second call - I get the following:-

07/07/2017 09:28:32.064   1391  4026329968 gc_h3r                  ERR1         sm_callcontrol.:525   !     3 ! << SharonMgr::MakeCall:  makeCall issued while processing a call. [9]

07/07/2017 09:28:32.064   1391  4026329968 gc                      ERR1         gclib                 iptB1T3   ::::> gc_MakeCall(linedev:5, phone_num:(null), timeout:25, mode:async) - ccfp_MakeCall(cclibcrn:0xffc40040) returns:-1

The above seems to suggest that HMP believes that there is stil a call being processed on the specific line device - can any one advise on how I can recover the line device and make it available again?

Thanks,

Mike

↧

RE: make call - No Reply

July 7, 2017, 4:58 am
$
0
0

Just an update on this - I've managed to free up the line device by using gc_ResetLineDev. This reset the line device ready for the next call.

↧

RE: make call - No Reply

July 7, 2017, 6:51 am
$
0
0

Hi,

Even if the call were not connected after initial makecall you need to gc_dropcall first and then call gc_releasecall in this case. Not just call releasecall alone.

Jeff

↧

RE: HMP3.0 SU372 defect processing "record-route"

July 7, 2017, 6:53 am
$
0
0

Is it the fact that the ACK is getting sent to the incorrect destination in this case. I can really comment further without seeing the actual Header content and IP addresses in order to see where the network path went wrong.

jeff

↧
↧

RE: HMP3.0 SU372 defect processing "record-route"

July 7, 2017, 8:14 am
$
0
0

Not really. Issue easy to see from provided SDP.

Basically after SU upgrade "Route:" completely ignored in ACK...

SU361:

Max-Forwards: 70

   Route: <sip:XX@XX:5060;transport=udp;lr>

   Contact: <sip:XX@XX>

SU372:

Max-Forwards: 70

   Contact: <sip:XX@XX>

Since that is not RFC compliant I assume that is another bug in SDP presented in latest updates or is it locally to me?

↧

RE: HMP3.0 SU372 defect processing "record-route"

July 7, 2017, 10:26 am
$
0
0

So just to be on the same page about this one. There is "Record-Route:" in 200 OK reply... with 1 record

According to RFC any content should be copied to outgound ACK. In our case should be "Route:" with same 1 record in response.

In updated SU that behaviour have changed...

Thank you in advance.

↧
Search

RE: Incoming G722 call "not acceptable here"(488) despite license

July 14, 2017, 4:08 am
$
0
0

Sorry for the typos, I always meant 722, not 772 :)

↧

RE: Incoming G722 call "not acceptable here"(488) despite license

July 14, 2017, 4:23 am
$
0
0

More info: rhe GCEV_REQ_MODIFY_CALL has nothing to do with it though, I was misreading my own log. My only actions are gc_AcceptCall and gc_AnswerCall and handling the corresponding events.

↧
↧

Incoming G722 call "not acceptable here"(488) despite license

July 14, 2017, 4:06 am
$
0
0

Hello,

having trouble with the G722 codec in a software only SIP solution. We have a six channel license which includes G772. Yet I cannot answer a call that offers the G722 codec but no G711 codecs. After answering the call with gc_AnswerCall I get a Disconnected event, looking at the result info yields: Lib GC_H3R_LIB: IPEC_SIPReasonStatus488NotAcceptableHere (5488). If I add G711 codecs to the offered codes, HMP picks G711 aLaw and continues with the call.

I am also handling the GCEV_REQ_MODIFY_CALL event and add all quiried codecs (G772 among them) to the parmblock for gc_AcceptModifyCall. This happens right after opening the board and registering the user.

A zipped Wireshark Capture is attached.

Looking forward to any help anyone can provide.

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/7/4743.G722_5F00_Test.zip:550:0]

↧

Busy signal

July 17, 2017, 6:41 am
$
0
0

First please forgive that I know nothing about the Dialogic boards I am working with.  We have an old (runs on Windows XP...) application that no longer dials out like it should. Nobody is quite sure what happened to it.  From what I can trace, test calls seem to get a busy signal instead of an open line.

Environment:  Windows XP PC, D/240/JCT-T1, D/480-2T1, DMV600TEP.  Avaya (CM) switch.

So far, I managed to find the Dialogic diagnostics, and the boards passed all checks.  

We actually have two dialers, not quite identical, and the phone lines we use checked out when we moved them to the other dialer - the other dialer seemed to function fine with them, so I have ruled out the phone lines.  

I have found the Dialogic Voice Demo to test if the boards can dial out, but I'm not sure what to do with it.  When I open a channel (dxxxB1C1), I get a message "This channel appears to have a digital network frontend. Do you wish to associate a network timeslot with the voice channel?" - and I have no idea whether that is the thing to do or not, so I tell it no (not knowing how to undo it if its the wrong thing, or what parameter it might ask for next), and proceed with a test, that results in an error "Error: Invalid Swithing Handler Bus Mode".  I'm not sure if that is because I didn't give it a network timeslot like it asked, or from something else.

Again, forgive my ignorance on this topic.  Can anybody help me figure out what is wrong with this machine?  Thanks so much...

↧

RE: Incoming G722 call "not acceptable here"(488) despite license

July 17, 2017, 7:34 am
$
0
0

Is this for windows or Linux?

Also note support for HD codecs (AMR / GSM / G722 ) are only available when running the application is 3PCC mode in this case. Is you application running in 3PCC mode?

Since you can only specify the codec in IPML level via ipm_startmedia,

Jeff

↧
Viewing all 1151 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>