Quote from: azrobert on July 29, 2015, 02:17:28 PM
The message you are receiving doesn't sound like it's coming from the OBi. It sounds like a Callcentric message. I called a Callcentric extension that that wasn't signed in and the first part of the message I received was exactly like what you posted. Mine went to VM, so the 2nd half of the message was different. What is defined on OBi2 SP1?
You're right, that is a callcentric msg - on Obi1, SP2 is setup for callcentric. On Obi2, SP1 is setup for sip2sip, but it's ObiTALK inbound directs anything from Obi1 (without the *0) to it's AA, so SP1 never comes into play for this.
When I change the SP2 inbound on Obi1 to just
pp(200222222*0), in addition to the callcentric msg 1004, the Obi call log shows End Call (404 Not Found) - when the inbound is just
pp(200222222), the call is directed to Obi2 as expected. When
pp(200222222*0) is included as part of a fork, the fork is shown in the call log, but silently fails for that portion (other fork recipients
do get the call directed to them). It looks like Obi1 cannot properly parse that Obi number when *0 is present.
QuoteTry forking the call without *0 and look at the call history on OBi2. The Peer Number should be 500111111. What is the Peer Number? If it is 500111111 it should be routed to the AA, but it's routed to the phone port. This is strange.
The Peer Number on these calls always reflects the caller-ID number of the originating caller (ie: if I initiate an inbound call from my callcentric extension 101, then that is what is shown as Peer Number on Obi2 after the fork from Obi1). Since you really
do want the originating caller-ID number to be shown, I assumed this to be correct behavior. 500111111 is only shown as Peer Number when the call to Obi2 is directly initiated from Obi1 via ObiTALK.