News:

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

Main Menu

Firmware 1.3.0 (Build: 2532) Problem

Started by RonR, September 04, 2011, 09:10:34 PM

Previous topic - Next topic

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

#4
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.

RonR

#5
Quote from: jimates on September 10, 2011, 02:40:02 PM
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.

You misunderstood.

From the release notes:

- Allow Caller-id spoofing for calls bridged via OBiTALK service. But use the obi number for circle-of-trust authentication.

The OBi number is NOT being used for circle-of-trust authentication in the case I cited.  The bridged call's CallerID is being used which, of course, does NOT match the circle-of-trust authentication.  It works correctly with the forks ordered one way but not the other -- one of them has to be working incorrectly.

(And I guess the reboots at the end of every call were simply thrown in for additional entertainment.   ;D)

earthtoobi

Ronr: i see that a lot of posts from users that seems  repetitive.it would be nice if someone can collate the issues/questions till now and reference the resolution threads for each.
it would be a nice FAQ that people can read before they post.

jimates

Many items are addressed in the stickies of each sub-forum, no one reads them before they post.

obi-support2

RonR:

1. Reboot problem as described in 2532 is reproducible. This has been addressed and
    the fix will be included in the next f/w update
2. Caller-ID and COT authentication in OBiTALK service should work as advertised.
    Please make sure your OBi100 is also updated to ver 1.3 in order for the
    COT authentication to work properly

Thank you.
OBIHAI Support Staff

RonR

Quote from: obi-support2 on September 15, 2011, 07:15:55 PM
2. Caller-ID and COT authentication in OBiTALK service should work as advertised.
    Please make sure your OBi100 is also updated to ver 1.3 in order for the
    COT authentication to work properly

The OBi100 has not been updated to v1.3.  Even so, why does the forking order of the calls in the OBi110, only one of which is directed to the OBi100, cause COT to behave differently?  I could understand if it didn't work at all, but it works correctly with certain forking orders and not with others.

Your comment also infers there is an interoperability problem between v1.3 and prior versions.

RonR

I updated the OBi100 to 1.3.0 (Build: 2532), but the problem is not resolved.

With the following call forking order in the OBi110 (200123456):

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

and a calling number into SP1 of 17607058888, the OBi100 appears to receive the call with a COT of 200123456 and the wrong CallerID.

With the following InboundCallRoute in the OBi100:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456:ph},{aa}

the PHONE Port rings with a CallerID of 200123456 and the Call History shows a Peer Number of 200123456.



With the following call forking order in the OBi110 (200123456):

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

and a calling number into SP1 of 17607058888, the OBi100 appears to receive the call with a COT of 200123456 and no CallerID.

With the following InboundCallRoute in the OBi100:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456:ph},{aa}

the PHONE Port rings with no CallerID and the Call History shows a Peer Number of 17607058888.