Digitmap Help
Thunnderman:
Here is the OBiTALK inboundCallRoute, it seems correct as you stated.
{(Mcot)>(Mli):li},{(Mcot)>(<*1:>(Msp1)):sp1},{(Mcot)>(<*2:>(Msp2)):sp2},{(Mcot)>(<*8:>(Mli)):li}, {(Mcot)>(<*9:>(Mpp)):pp},{(Mcot)>(<**1:>(Msp1)):sp1},{(Mcot)>(<**2:>(Msp2)):sp2}, {(Mcot)>(<**8:>(Mli)):li},{(Mcot)>(<**9:>(Mpp)):pp},{(Mcot):aa},{ph}
RonR:
One of your Call History's didn't post.
In the case I can see (OBi #2), everything looks correct : 18503 was sent to SP2 in both cases. Why one case gets a 500 error and the other doesn't isn't clear because the correct number is being sent to SP2 in both cases.
Thunnderman:
RonR,
Reattached another call history to the original post.
It really strange to me too, it seems that no matter what number after the 2**2XXXXX from other obi unit, error will be prompted immediately.
Anyway, thanks a lot your patients and help me solve a lot of issues already.
RonR:
I can't think of anything else to try. It appears the provider on SP2 is unhappy with something when the OBi iniitates the call from the OBiTALK InboundCallRoute but is perfectly content when the OBi initiates the very same call from the PHONE Port. This shouldn't be and would seem to indicate a firmware problem in the OBi.
It's probably going to take Obihai to figure this one out.
Stewart:
Quote from: Thunnderman on November 12, 2011, 09:28:02 pm
It really strange to me too, it seems that no matter what number after the 2**2XXXXX from other obi unit, error will be prompted immediately.
Do you have X_SpoofCallerID set? If so, try turning it off.
If the above is inapplicable or doesn't help, set up syslog and turn on X_SipDebugOption for SP2. Use Wireshark or a syslog server to view the INVITES and report what's different between the two cases.
Navigation
[0] Message Index
[#] Next page
[*] Previous page