Jump to content


< Back to Forum


 

Not Registering On Grandstream Ucm6102


  • Please log in to reply

#1 yona 04 January 2017 - 09:18 AM

Using VG 7.5.5 

windows 7 SP1 64 bit 

 

Voip Call comes in to grandstrim UCM6102 and then transfer to VG 

Works for 1 hr  and then stops working 

 

VG and UCM are on the same LAN VG=192.168.0.120 and UCM=192.168.0.240

 

I have tried with and without adding an <Expire>3600</Expire>  tag in config.xml

Im also including the 2 wireshark files with the other logs

 

Please delete file after downloading  

the files are 7z not zip but I had a problem uploading so I renamed it 

Yona 



#2 SupportTeam 06 January 2017 - 09:04 AM

The No_expoir WireShark trace covers about 2 hours. It shows one INVITE from 192.168.0.240 - around 30 seconds after the REGISTER. It was answered by the system.

The with_expir WireShark trace covers about 3 hours. It shows two INVITEs from 192.168.0.240 - one around 30 seconds after the REGISTER and one about an hour afterwards. Both calls were answered by the system.
Were there other calls after these 2 that were not forwarded by 192.168.0.240 to 192.168.0.120 ?

NB. In both traces only one REGISTER is made from 192.168.0.120 to 192.168.0.240

Would recommend looking at Dialogic RTF logs next to see if they contain any entries that would relate to HMP's subsequent REGISTER messages that are expected.
 



#3 yona 07 January 2017 - 03:03 AM

I did made a call after 1 hr in both cases, but you don't see the invite because it never Registered again, and never made it to VG server.  

how would i get the RTF logs?



#4 SupportTeam 07 January 2017 - 03:45 AM

The Dialogic's RTF logs are in Dialogic driver's /log/ subdirectory.



#5 yona 07 January 2017 - 05:14 AM

got them. 

works till the hr mark 

The RTF log is a bit more then a hr

 



#6 yona 07 January 2017 - 05:15 AM

this is the file

  • Attached File  log.zip   2.39MB   20 downloads


#7 SupportTeam 07 January 2017 - 05:52 AM

There seems to be some entries indicating errors around the 13:00:00 timestamp in the attached RTF log.

 

Dialogic support would need to be involved to advise why HMP does not seem to be able to currently re-REGISTER itself with this device.

 

You will need to contact the supplier of the HMP license regarding raising this issue with Dialogic support.



#8 yona 09 January 2017 - 04:11 AM

Is it possible that HMP has the errors because VG has an issue?

The fact of the mater is in order to make it work I don't need to restart the HMP  service by just restarting VG it starts to work.  



#9 SupportTeam 09 January 2017 - 05:37 AM

Restarting VoiceGuide resets HMP's internal states. The initial registration is carried out OK, but seems like HMP has trouble re-sending the registrations afterwards.

 

There are no registration related interactions between HMP and VoiceGuide after VoiceGuide advises registration particulars to HMP. The sending of registrations and re-registrations is handled by HMP.



#10 yona 11 January 2017 - 09:48 AM

Is there anyway I can get voice guide support or this issue?



#11 SupportTeam 12 January 2017 - 02:44 AM

If the HMP license was purchased through us and has a current valid Dialogic maintenance plan for it then we would be able to raise this issue with Dialogic.

We cannot make any support requests to Dialogic for HMP licenses that were not purchased through us.

Potential support related issues like this are the reason why we recommend purchasing Dialogic HMP through us.

 

For systems that use HMP purchased from other sources any support relating to HMP must be raised through that HMP supplier.



#12 yona 12 January 2017 - 04:29 AM

Can we buy Dialogic maintenance plan via Voicegude to our  existing HMP licences? 



#13 SupportTeam 12 January 2017 - 06:48 PM

Your current Config.XML has these VoIP_Registrations and VoIP_Authentications entries:

 

<VoIP_Registrations>
<VoIP_Registration>
  <Protocol>SIP</Protocol>
  <RegServer>192.168.0.240</RegServer>
  <RegClient>1000@192.168.0.240</RegClient>
  <LocalAlias>1000@192.168.0.240</LocalAlias>
</VoIP_Registration>
</VoIP_Registrations>
<VoIP_Authentications>
<VoIP_Authentication>
  <Realm>grandstream</Realm>
  <Identity></Identity>
  <AuthUsername>1000</AuthUsername>
  <AuthPassword>YOUR_PASSWORD</AuthPassword>
  <CallerID>1000@192.168.0.240</CallerID>
</VoIP_Authentication>
</VoIP_Authentications>

 

 

Please make the LocalAlias entry either blank or set it to be:

 

<LocalAlias>1000@192.168.0.120</LocalAlias>

 

 

More information on the VoIP_Registrations and VoIP_Authentications entries can be found here:

 

http://www.voiceguid...ip_register.htm

 

if you continue to encounter problems please post the RTF and ktTel and WireShark logs as before - for both cases: LocalAlias entry blank, and LocalAlias entry holding the 1000@192.168.0.120  value.



#14 yona 13 January 2017 - 09:41 AM

OK tried empty and with this settings 

 

<VoIP_Lines>
 
<VoIP_Registrations>
<VoIP_Registration>
  <Protocol>SIP</Protocol>
  <RegServer>192.168.0.240</RegServer>
  <RegClient>1000@192.168.0.240</RegClient>
  <LocalAlias>1000@192.168.0.120</LocalAlias>
  <Expires>3600</Expires>
</VoIP_Registration>
</VoIP_Registrations> 
<VoIP_Authentications>
<VoIP_Authentication>
  <Realm>grandstream</Realm>
  <Identity></Identity>
  <AuthUsername>1000</AuthUsername>
  <AuthPassword>pppppp</AuthPassword>
  <CallerID>1000@192.168.0.240</CallerID>
</VoIP_Authentication>
</VoIP_Authentications>
 
</VoIP_Lines>
 
Works just for one hour.  


#15 SupportTeam 13 January 2017 - 01:06 PM

Please make the LocalAlias entry:

 

<LocalAlias>1000@192.168.0.120:5060</LocalAlias>

 

and post the RTF and ktTel and WireShark logs as before.



#16 yona 14 January 2017 - 03:16 AM

Thanks,  it is now over an hour and works :D