News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

New 1032 Firmware Issue

Started by Boykin, April 20, 2015, 06:25:20 AM

Previous topic - Next topic

Boykin

After having no connectivity issues for 24 hours, I was ready to update my last 1032.  I wanted to set up programmable keys to work with parking a call first though.  I made a call with my cell to my 1032s, and when I answer on the phones that had been upgraded, I could hear nothing on the 1032 and only hear static on the cell.  If I answer the call on the phone that was not upgraded, the call was fine.  To confirm that the firmware was the problem, I upgraded the last phone and now it does the same as the other 2.  Silence on the 1032 and static on the cell.  This is happening on wired and wireless internet connected 1032s.  I will revert back to the March firmware since now I cannot get incoming calls. 

Boykin

Reverted back to 2486 and now incoming calls are working again. 
If your 1032 firmware is current, you better call it from your cell to see if you can hear the caller and see if the caller gets static. 

WelshPaul

#42
Not getting this issue on my OBi1032. Mine has been running the latest version since I last posted and I just called it from my cell phone without issue.

However... I reported the very same behaviour back in February, only difference then was it only happened when bridging a call. No audio in either direction and static on my cell phone.

QuoteI just attempted to set a divert for a pesky number that keeps ringing. I setup the following rule against sp1:

InboundCallRoute: {(12345):sp1(54321)},{ph}

If I get a call from caller ID 12345 it should divert it over sp1 to telephone number 54321 and although it does do that there is no audio?

I cannot hear anything either side of the call. Both phones are silent?

I tested it on my mobile, Call my obi1032 from my home phone > obi1032 using the above rule forwards the call to mobile without ringing on the Obi1032 > Mobile phone rings and I answer it and no audio on mobile or house phone.

I do believe this was fixed, looks like it may now be happening on inbound calls on the latest version when using a certain codec?

EDIT: The thread is located in the beta forum: http://www.obitalk.com/forum/index.php?topic=9393.0

EDIT 2: I just tested this again and OBIHAI still have not fixed the issue, while the OBi1032 does indeed forward the call the result is that once answered there is no audio in either direction only some minor white noise. I'm sure they are both related.

Syslog results are identical to those I posted back in Febuary

<7> RTP:DtmfTxMtd:1(1),0
192.168.1.5 30/04 09:23:37.509
<7> RTP:Start->c0a8010a:13456(1 0);0;(nil);(nil):0:0;0(59)
192.168.1.5 30/04 09:23:37.510
<6> +++ rtp_alloc_encoder: rtp 0xafddd060 tx_ptime_ts set to 160
192.168.1.5 30/04 09:23:37.510
<7> RTP:DtmfTxMtd:1(1),0
192.168.1.5 30/04 09:23:41.520
<7> RTP:Start->c0a8010a:13456(1 0);0;(nil);(nil):0:0;0(59)
192.168.1.5 30/04 09:23:41.522
<6> +++ rtp_alloc_encoder: rtp 0xafddd060 tx_ptime_ts set to 160
192.168.1.5 30/04 09:23:41.522
<7> RTP:Start->c0a8010a:10384(80 0);0;(nil);(nil):0:0;0(55)
192.168.1.5 30/04 09:23:41.530
<6> +++ rtp_alloc_encoder: rtp 0xafd63378 tx_ptime_ts set to 160
192.168.1.5 30/04 09:23:41.530
<3> RTP_process_audio_frame_ex 4066: Huhh??? 0 vs 80.
192.168.1.5 30/04 09:23:41.531
<3> RTP_process_audio_frame_ex 4066: Huhh??? 0 vs 80.
192.168.1.5 30/04 09:23:41.532
<3> RTP_process_audio_frame_ex 4066: Huhh??? 0 vs 80.
192.168.1.5 30/04 09:23:41.533
<3> RTP_process_audio_frame_ex 4066: Huhh??? 0 vs 80.
192.168.1.5 30/04 09:23:41.533
<7> RTCP:RxPkt[44]=201<--c0a8010a:10385
192.168.1.5 30/04 09:23:46.700
<7> RTCP:RxPkt[44]=201<--c0a8010a:10385
192.168.1.5 30/04 09:23:51.540
<7> RTCP:RxPkt[44]=201<--c0a8010a:10385
192.168.1.5 30/04 09:23:56.539
<7> RTP:Del Channel
192.168.1.5 30/04 09:23:57.961
<7> CCTL:DelChisItem
192.168.1.5 30/04 09:23:57.974
<7> CCTL:AddChisItem
192.168.1.5 30/04 09:23:57.975
<7> RTP:Del Channel
192.168.1.5 30/04 09:23:57.975
For everything VoIP
www.ukvoipforums.com

Boykin

I am using OBiPlus Premium with all of my SPs on the OBi202.  I wonder if I set up one of my lines on a 1032 directly if I would still have the same problem.  I will have to experiment tonight when I get home. 

I had to turn off the auto attendant in OBiPlus due to a similar issue.  The auto attendant had 2 options, 1 to leave a voice mail and 2 to continue.  When the caller pressed 2, I could hear everything they were saying but they could not hear me.  I confirmed this with my cell. 

I found something that might have caused an issue.  In OBiPlus I was using codec B, but the SP was using codec A in the 202.  I changed OBiPlus to codec profile A.  I will test this when I get home. 

ianobi

QuoteI found something that might have caused an issue.  In OBiPlus I was using codec B, but the SP was using codec A in the 202.  I changed OBiPlus to codec profile A.  I will test this when I get home.

I believe that there is a bug with the way OBi devices negotiate codecs when setting up a bridged call. In your case I don't think it's a problem with which codec profiles are used, it's a problem with which codecs are actually enabled and their priority within the profiles. I managed to get around the bug by only enabling codec G711U in both devices. You may wish to try this as a test.

My setup does not include OBiPLUS, so I cannot comment on how that might affect codec negotiation when bridging calls. However, my problem did include an OBi1032 and an OBi110 and a bridged call between them.

Boykin

Quote from: ianobi on April 30, 2015, 07:37:14 AM
QuoteI found something that might have caused an issue.  In OBiPlus I was using codec B, but the SP was using codec A in the 202.  I changed OBiPlus to codec profile A.  I will test this when I get home.

I believe that there is a bug with the way OBi devices negotiate codecs when setting up a bridged call. In your case I don't think it's a problem with which codec profiles are used, it's a problem with which codecs are actually enabled and their priority within the profiles. I managed to get around the bug by only enabling codec G711U in both devices. You may wish to try this as a test.

My setup does not include OBiPLUS, so I cannot comment on how that might affect codec negotiation when bridging calls. However, my problem did include an OBi1032 and an OBi110 and a bridged call between them.

You are correct.  I turned off all codecs except G711U and now the latest firmware works.  I can hear the caller and they can hear me. 

When I bypassed the 202 and put a GV line on 1032, it works correctly too. 

Even using only G711U, the auto attendant still does not work correctly.  I can hear caller, but they still cannot hear me. 

WelshPaul

Quote from: Boykin on April 30, 2015, 11:43:06 AM
the auto attendant still does not work correctly.


I reported the auto attendant issues a while back also. They should be working on a fix.
For everything VoIP
www.ukvoipforums.com

Boykin

The offending codec is G726R32.  I enabled the ones I had disabled one by one until I reproduced the problem.  I had to disable this codec on the 1032s.  The 202 has this codec and all the other default codecs enabled.  I tried to disable this codec on the 202 and leave it enabled on the 1032s but that did not fix the problem.