Just set this 508 up and I have 8 lines registered with a Metaswitch however when dialing a 10 digit number the Obi inserts a "1" in front and I receive an announcement from the Metaswitch stating that I do not need to dial a 1. Happens on all ports.
Any ideas how to stop the 1 insertion?
You need to use OBi Expert to make the following change on all the ITSP definitions for Metaswitch.
Service Providers -> ITSP Profile x General -> DigitMap
The DigitMap has this rule: <1>[2-9]xxxxxxxxx
Change it to: [2-9]xxxxxxxxx
That did the trick! Thanks a bunch!
Hmmm now when I am testing the call rings three times and goes busy. If I answer before the three rings the call completes?
The 508 firmware had/has several bugs, but I don't know if this is a fw bug. It should ring for 60 seconds before the call fails.
OBi's have 2 ring profiles, A and B found here:
Ring Settings -> Ring Profile A/B
Each Profile has 10 Ring Patterns.
The default for SP1 should be Ring Profile A and Ring Pattern 1
Ring Pattern 1 is defined as: 60;(2+4)
This will ring for 2 seconds then silence for 4 seconds. The pattern will repeat for 60 seconds. After 60 seconds the call will fail and I think the caller will get a busy.
The Ring Profile is determined by:
Voice Services -> Spx Service -> X_RingProfile
The Ring Pattern is determined by:
Voice Services -> Spx Service -> X_DefaultRing
Try changing the Ring Pattern to 99;(2+4) or 120;(2+4) to see what happens.
I hate being a pain. But this thing is killin me!
Set it to 120 and tried dialing out again. No go rang three times and then fast busy.
Dialed three different test lines and the same thing RNAx3 than Fast Busy.
Thanks
Try routing the call to the Auto Attendant, then select the option to ring the phone. If you have the same problem, it would indicate a firmware bug. It won't be 100%, but it would point to a Provider problem if the phone continues to ring.
Voice Services -> SPx Service -> X_InboundCallRoute: aa
Call the 508. When you hear the AA prompt, enter 1 for continue the call.
I open a TT w Meta and they came back w this:
The PRACK is being rejected by the Perimeta because the request-line in the PRACK message doesn't contain a Request-URI. The endpoint needs to send a valid PRACK in order for us to process this. The PRACK sent in the SAS trace contains this request-line:
PRACK SIP/2.0
which is not valid.