News:

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

Main Menu

SIPx rejecting AA calls

Started by somnius, November 01, 2012, 12:35:03 PM

Previous topic - Next topic

somnius

Hi all!

I've spent hours searching for an appropriate answer to my issue in the forum with no success so far. I hope somebody can help out.

I've got OBi110 with SP1 and SP2 set up for 2 different extensions of a single ITSP. I further have my PSTN line hooked up, and an analog phone on the Phone Port.
Everything is working smoothly when initiating calls from the Phone Port.
Calls initiating from the AA through the PSTN are OK.
However, calls initiating from the AA through SIP lines are not working. I keep getting the message "The number you dialed was rejected by the Service Provider. Reason is 488."

Call History at OBi shows the following:

Caller:
Terminal ID:   AA1
Peer Name:   (empty)   
Peer Number: **1131
Direction:   Outbound
16:17:18 New Call

Callee:
Terminal ID:   SP1
Peer Name: (empty)
Peer Number: 131
Direction: Outbound
16:17:18 End Call (488 Not acceptable here)


Given that the calls are only rejected if coming through AA, I pressume there would be some kind of problem with the CallerID, maybe. I have tried out several options without success.

If anybody can guide me into a proper solution, I'd be really grateful

Cheers

jimates

if the caller id was the problem your incoming call would not be presented to the AA. The problem must be the outgoing call.

You dialed **1131?

somnius

Hi jimates

Thanks for the reply.

I did dial **1131 on the AA, after selecting option 2.
I tried several ways, and none seems to get the call through. SP1 is also the Primary line, so I also dialed 131 all alone, with the same outcome. I even tried through SP2, whose set-up is the same as SP1, only another SIP user (on the same SIP server). Same outcome.

By the way, 131 is a shortcut setup by my SIP ITSP for another extension I own. Even if I replace 131 with another valid phone number, same thing happens.

Calls from the AA through li are OK. That means, if I dial **8(some number), it goes through.

Also, calling from ph is OK, both through PSTN and through SIP.

Incoming calls are all working fine.

So I thought if the service is only not working when starting the call from AA through SIP, it must be something the AA is doing that my ITSP doesn't like. Hence, I thought of the CallerID, which I understand can be configured to be OBi110's CallerID or calling party's (OBiON). I just don't know where to set this right. The Digit Maps are all the default ones, but for the one for AA, which has been modified by OBiTALK according to my Circle of Trust.

Any ideas?

jimates

the circle of trust should only change the Obitalk Service Inbound Call Route, nothing else.

I suspected the call is being rejected by a digit map, either the AA digit map or the SP digit map. But you said if you dial **11xxxxxxxxxx you get the same result.

this is a spread sheet for the Obi110 settings. the second sheet is the default settings. Compare your maps and routes to them and see what is different.
https://docs.google.com/a/thejmart.com/spreadsheet/ccc?key=0ApZetlc97n9-dFpqUDZ6Wnp1Zm9oRVlBbXc3bkVrTmc

jimates

#4
calling from the phone uses the phone port digit map and outboundcallroute
calling from the AA uses the AA digit map and outboundcallroute

there is a slight difference but I don't know what the rule difference means. IanObi knows digit maps and call routes. Maybe he will be along soon.

You might temporarily try replacing the AA digit map with that of the phone port and test.

AA defautl digit map
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|<00:$1>|0|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|(Mpli))

phone port default digit map
([1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|(Mpli))
the *** and **0 are for accessing the IVRs

AA default OCR
{([1-9]x?*(Mpli)):pp},{0:ph},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

phone default OCR
{([1-9]x?*(Mpli)):pp},{(<#:>|911):li},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}

somnius

#5
Hi again jimates, and thanks for your prompt reply

You're right about OBiTALK only modifying InboundCallRoute. I got confused there.

I checked both DigitMap and OutboundCallRoute on AA and ph, and they are indeed the default ones. Only difference with your Mph is the 411 you added on the spreadsheet.

Appart from this, the message I hear from AA when the call gets rejected is giving the error code 488 generated by the SIP server, so OBi110 is indeed outputting the call. It is the server rejecting it.

I have done some research elsewhere and have come accross a couple of posts implying that the 488 error might be related to codec mismatch between server and client. I don't currently have acces to the OBi110 (it got turned off). I'll recheck tomorrow with "Call status" and let you know.
(Ref: http://forums.whirlpool.net.au/archive/943431 and http://lists.kamailio.org/pipermail/users/2006-October/007035.html)

Any other ideas will be most welcome.

ianobi

This does not look like a DigitMap issue to me. 131 is seen to be going out on sp1. It is being processed by the xx. rule in Msp1, which adds ten seconds delay, but still sends the correct number out. This could be improved upon after the main problem is sorted.

As suspected above, the most probable causes are either Caller ID not being accepted by the service provider, or a codec problem.

Using Call Status while the call is in progress, try to spot a difference between a call from the phone port which works and a call from aa which does not work.

somnius

Hi all

Thanks jimates and ianobi for your support.

The problem was indeed a codec issue. Mi ITSP only supports G.729a and iLBC, which are both low bit rate codecs. The OBiON app supports codecs from 16kbps upwards. That is the problem.

Calling AA from the local phone port (**0) I manage to get the call routed correctly. From OBiON I cannot.

The only solution would be that OBiON app supported a low bit rate codec. I don't know if this is in the plans for development, but I would be very grateful to have such thing.

I can always bypass OBiON and call my OBi110 through a Softphone, via my ITSP, but I prefer to use OBiON.

Thanks for your support anyway.

Kind regards