488 Not Acceptable Here Response

[iTime]

OK, I prepared the Wireshark log and attached here.

 

I can see "488 Not Acceptable Here" message, but please keep in mind that the connection to our VoIP provider was fine until I had applied the latest VG yesterday.

 

Thank you for your help again.

 

 

 

 

 

LogWithWireShark.zip

[SupportTeam]

WireShark trace shows that HMP answers incoming fine, but then the device sending the call to HMP (Sonus / Broadvox Fusion) the sends a re-INVITE, and HMP responds to that re-INVITE with a "488 Not Acceptable Here" message.

 

Sonus / Broadvox Fusion then sends a BYE message to HMP to end the call.

 

Not sure why HMP would respond to the second INVITE message (the re-INVITE message) with a 488. This needs to be taken up with Dialogic (usually done through the HMP license supplier).

 

Quickest resolution may be to speak to SIP service provider and ask them to stop sending the re-INVITE.

[iTime]

OK, I sent your comment to our service provider, Broadvox Fusion, asking if stopping re-invite is possible, but with the fact that their service has been working fine with the previous version of VG, wouldn't it be more appropriate if you can support the original functionality/behavior that used to be fine with the provider?

[SupportTeam]

Dialogic's RTF Log files may give more information as to why HMP responded to re-INVITE with a "488 Not Acceptable Here".

 

Increasing the HMP log level will show more information in those log files.

 

Below are instructions on increasing the RTF logging levels:

1. Stop the VoiceGuide service.
2. Stop the Dialogic service.

Please place the attached RtfConfigWin.xml file on your system - unzip first. (file link at very bottom of this post)


for Windows 7, Win2008, Win2012 :
3a. make the hidden directory C:\ProgramData visible
3b. go to C:\ProgramData\Dialogic\HMP\cfg


for Windows XP, Win2003 and Win2008-32bit :
3a. go to C:\Program Files\Dialogic\cfg


Then:

4. Backup existing RtfConfigWin.xml,
5. Replace it with attached RtfConfigWin.xml (unzip it first)
6. Shutdown and restart Windows.

7 Start WireShark to capture the SIP packets of the incoming call. (see: www.wireshark.org)
8. Start the Dialogic service.
9. Once Dialogic service has fully started then start the VoiceGuide service.

10. After VoiceGuide service has fully started place a call into system.

11. .ZIP up Dialogic logs (C:\Program Files (x86)\Dialogic\log directory) and VoiceGuide ktTel log and the WireShark .pcap log file that captures the SIP packets.
12. Please post all the above logs here.

RtfConfigWin.zip

[iTime]

Hi again,

 

I have prepared the log files along with RTF log as requested.

Thanks again for looking into this.

I haven't got anything from our VoIP provider either.

I will keep you posted.

 

Thanks.

LogWithRTFConf.zip

[SupportTeam]

One thing to try would be to see if using HMP SU360 makes any difference - SU361 is also available but has not been tested with VoiceGuide yet.

 

If you are getting similar situation with newest version of Dialogic HMP then you should probably contact the Dialogic HMP supplier and forward to them the captured RTF logs and see if they are able to to assist by raising issue with Dialogic.

 

VoiceGuide does not issue the 488 response. That is all done on HMP level.

[iTime]

OK, I will try that, but please know that the previous version of VG we are currently using for other customers is working fine with the exact same environment of the VoIP carrier and HMP driver.

That being said, wouldn't it be more appropriate if you could find the cause or solutions?

I will keep you posted.

Thanks.

[SupportTeam]

If you would be able to retrieve a similar set of RTF + VoiceGuide + WireShark logs from a working system then we can have a look at the traces from the two systems and see if there is anything obvious visible in them - but Dialogic are far better placed to comment on their drivers behavior.

 

(RTF logs would need to be captured with the debug RtfConfigWin.xml applied)

[iTime]

Here is the logs for the working version that passes [CheckTaskType] and beyond.

It is the server (restored with the previous image) with the exact same VoIP provider, HMP version and same everything but VG version.

I noticed from Wirshark log that it does request INVITE twice here as well, but no rejection.

Thanks for taking a look at this.

VG_WorkingVersion.zip

[iTime]

I have posted this issue to a Dialogic forum and am waiting for their reply.

In the meantime, I performed comparison of rtf logs between the previous and the current VG (those 2 rtfLog files I posted in this thread) and found a different, which might be something.

I noticed that the current VG shows "callModifyStateReInviteReceived(), OperationMode=2" while the previous version of VG shows "callModifyStateReInviteReceived(), OperationMode=4" then the logs take different paths until the current VG returns "about to send 488 response."

Would this mean something to changes on your application?

 

Thanks for continuously taking care of my issues.

[iTime]

Hi,

I finally got an answer from Dialogic. Please see below.

The only part that mentions "G729" in the rtf log is listed below (I did not attached the rft log file in this post because the file has already been posted above).

So, what do I have to do next?

 

Thanks.

 

 

 

• The second Invite comes with G729 codec, which is probably not licensed on your system. Also, both offers come with 20 ms frame size, while the app sets 30 ms; I'd fix this first.

10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    - <-- INVITE sip:1234567890@192.168.100.130 SIP/2.0
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Via: SIP/2.0/UDP 208.93.227.216;rport;branch=z9hG4bKFtNtUBrUSDKFQ
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Route: <sip:1234567890@192.168.100.130>
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Max-Forwards: 69
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     From: "Company Systems Cor" <sip:7144443020@208.93.227.216>;tag=93Kta0Bv0j83p
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     To: <sip:1234567890@192.168.100.130>
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Call-ID: 670cbeb2-f3be-1233-83a9-f04da23d7069
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     CSeq: 82443685 INVITE
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Contact: <sip:7144443020@208.93.227.216:5060>
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     User-Agent: Broadvox Fusion
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Supported: timer, path, replaces
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Allow-Events: talk, hold, conference, refer
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Privacy: none
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Content-Type: application/sdp
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Content-Disposition: session
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     Content-Length: 279
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     P-Asserted-Identity: "Company Systems Cor" <sip:7144443020@208.93.227.216>
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    - 
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     v=0
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     o=Sonus_UAC 1980001994 1568278165 IN IP4 216.86.41.7
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     s=SIP Media Capabilities
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     c=IN IP4 216.86.41.4
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     t=0 0
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     m=audio 18498 RTP/AVP 0 18 101
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     a=rtpmap:0 PCMU/8000
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     a=rtpmap:18 G729/8000
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     a=fmtp:18 annexb=no
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     a=rtpmap:101 telephone-event/8000
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     a=fmtp:101 0-15
10/22/2015 17:18:18.632   1680        4744 sip_stack               Debug        INFO   - TRANSPORT    -     a=maxptime:20

[SupportTeam]

The second Invite comes with G729 codec

 

The second INVITE does not specify the G729 codec. WireShark traces and RTF logs show that second INVITE only specifies the PCMU codec. Only the first INVITE lists the G.729 codec.

 

Please note that Dialogic Support is not accessible through their public online board. Dialogic Support can be reached directly through the authorized suppliers who supplied the Dialogic product.

 

 

Reviewing the previously posted traces it looks like HMP SU347 is installed on this system, and one trace was done with a two year old VoiceGuide v7.4 which you originally had installed on this system, and the other trace was done with a more recent release, but still a v7.4.

 

This free support forum is used for systems that run the latest current releases of drives and VoiceGuide - for VoIP deployments that currently means v7.5 and HMP SU360. Please provide traces from system that uses those versions of drivers and software and we can then look at those traces.

 

Continuing support for older versions of VoiceGuide is available under a support plan (please contact sales@voiceguide.com for details).

[iTime]

I have installed Dialogic HMP SU360 along with VG 7.5 as suggested on the same server, then tried.

The same result of "488 error" occurred. This time VG crashed (service stopped), leaving error log on Windows event viewer.

Please see attached VG log, Wireshark, RTF log along with Windows event log.

 

Thanks.

 

VG75_488Err.zip

[SupportTeam]

Could you please update system with this version of VoiceGuide:

 

[old link removed]

 

 

and post traces as before if you still encounter any problems.

[iTime]

The new update works. It has fixed the problem. Thanks for the update.

 

But one issue is that vbs files created in "Temp" folders (for debugging purposes, we utilize this option) fail with the following error if run separately (as WScript):

"ActiveX component can't create object: 'vgServices.CommandLink"

We found that the component (vgServices) does not seem to have been registered properly (RegEdit shows "vgServices.CommandLink" in the list but no associated CLSID), yet the VBScript modules run fine as parts of our VoiceGuide scripts.

Without debugging functionality, we will not be able to provide upgrade to our customers production environments.

 

Did I install/configure something wrong? The environment is Windows Server 2008 R2.

 

Thanks.

[SupportTeam]

Thanks for letting us know that RE-INVITEs now work on your system.

 

A new thread has been started for this problem:

vbs files created in "Temp" folders (for debugging purposes, we utilize this option) fail with the following error if run separately (as WScript):

"ActiveX component can't create object: 'vgServices.CommandLink"

 

Please see: http://voiceguide.com/forums/index.php?showtopic=12146