Firmware 1.3.0 (Build: 2532) Problem

(1/3) > >>

RonR:
Obihai support,

The following SP1 Service InboundCallRoute works perfectly:

Voice Services -> SP1 Service -> X_InboundCallRoute : {ph,vg5(pap2),pp(ob300123456),tg1(18708470000)}

Swapping the last two forks:

Voice Services -> SP1 Service -> X_InboundCallRoute : {ph,vg5(pap2),tg1(18708470000),pp(ob300123456)}

results in two problems:

1.  The Peer Number received by the OBi100 (300123456) is that of the incoming call and not the OBi110 forking the call, causing Circle of Trust to fail.

2. The OBi110 reboots at the completion of the call every time.

RonR:
Obihai support,

Are you able to reproduce this problem?

I hope that an OBi rebooting at the conclusion of EVERY call is a serious enough problem to warrant looking into.

Ostracus:
Quote from: RonR on September 09, 2011, 08:55:47 am

Obihai support,

Are you able to reproduce this problem?

I hope that an OBi rebooting at the conclusion of EVERY call is a serious enough problem to warrant looking into.



Sounds like a good enough reason for a recall. ;)

earthtoobi:
Ostracus: this has nothing to do with a recall.
i have Had obi reboot after a call issue and they were patched by OBiTeam (a separate unreleased patch).
they are typically software(firmware) bugs that needs to be addressed.

jimates:
Quote from: RonR on September 04, 2011, 09:10:34 pm


The Peer Number received by the OBi100 (300123456) is that of the incoming call and not the OBi110 forking the call, causing Circle of Trust to fail.


This is the main reason (feature) many have been waiting for release 1.3. We want the caller id to be for the original call.

I had previously disabled forking calls on my Obi because of the caller id issue. Yesterday I changed my call route to fork my SP1 calls to my other 2 Obi's and am very happy to see the correct caller id.

Navigation

[0] Message Index

[#] Next page