BCM 450 RLS 6 trouble with Allstream IPT services.

[dgmf]

Hi All,

This is my first post to this forum. I'm at my wits end here. I have a BCM 450 Rel 6 with all the latest patches installed.

Sysytem software version is: 10.0.1.02.120

I am trying to configure the system to use our new Allstream IP Trunking service... and have hit a snag. I followed a document from Avavya's support website detailing the recomended configureation(attached). Here's where is gets odd. I am able to receive all calls but am only able to dial out to my local area code(905) I cannot even dial out to the other local Toronto area codes(416 or 647). The techs at Allstream say they cannot even see calls hitting their SBC(other than 905)and are saying it's a configuration issue with my PBX. I have reviewed all programming with my current interconnect company(who are Avaya partners) and have been told that it should work. I only have this one route and this one service configured in my system. Here is some data from my BCM monitor showing a sucessful call (905 Number)and a failed call. I can see that the IP information is diferent in the RTP section. Not sure if this matters.

JOY! (905 Number)

[RTP Session Details]
[{Set 255 10.0.22.42:51004}<->{ SIP Trunk (Allstream) 8 }{10.0.21.5:16598} G.729, 2 fpp, 101 RFC2833, SMALL jb]

[Line: 8 - Line008 Direction: Outgoing Start Time: Thu Mar 10 15:46:37 2011 User: 255 - testst2 State: Connected Duration: 00:00:01 Number and Name: 905XXXXXXX ]

NO JOY (416 Number)

[RTP Session Details]
[{Set 255 10.0.22.42:51004}<=>{10.0.22.30:28000} G.729, 2 fpp, SMALL jb, ECan+NLP]

[Line: 8 - Line008 Direction: Outgoing Start Time: Thu Mar 10 15:55:35 2011 User: 255 - testst2 State: Idle Number and Name: 416XXXXXXX ]

Both Calls made from same IP set (Set 255 10.0.22.42) and 10.0.22.30 is the local IP of my BCM.

Any insight would be greatly appreciated. Is there anything in the configuration of the BCM 450 that would treat area codes diferently other than seperate routes?

Thanks for your time.

 

[telcodog]

If you're using Allstream IP trunking and IP sets, there's one little item that manual doesn't tell you. You have to set the payload size for the 711 and 729 codecs to 20ms and don't use the 723. What it doesn't tell you is that if you're using IP sets, you have to change their codecs too or else your calls will fail every time. If you leave them at the default of 30ms, the system will use the set codec setting instead of the trunk setting. Drove me around the bend the first time I had to deal with them on this. You'd think they would know by now and tell you that.

Try that first and let us know if that fixes it.

And BTW, you're also going to have outbound CLID issues with these Allstream trunks too. When you get the calls going through, make sure you check it out thoroughly.

 

[dgmf]

Thanks for the reply telcodog

I did find that payload setting specifically for the ip sets and did change it. I will double check everything in that IP set section in the morning. It does appear in the logs that both the successful calls and failed calls are using G.729 codec.

I hear ya with being driven around the bend... they sure make you work for the info you need.

What's really driving me nuts is that I can receive any call and consistently make calls to one of my local area codes. Also my logs are showing that all calls are choosing the same VOIP Line(8)and sending only the dialled digits and no additional or unique codes.


{Set 255 10.0.22.42:51004}<=>{10.0.22.30:28000(BCM450 IP)}

So when I get the above on failed calls... I'm wondering is the BCM treating all calls but 905 with this random setting and sending them out differently, causing them them to fail... or is it just more likely they are being rejected on Allstreams end.

At this point I'm just dying to know clearly one way or the other.

Sorry for barfing that all out... I'm been on this on and off for the greater part of the month and 10 hrs today.

Any little bit helps... thanks

D

 

[telcodog]

If you can make one successful call, then your SIP trunking is set up correctly. Whatever is going on at their end, they should at least be giving you the failure code that they're seeing when they monitor your trunks. That should provide you with some direction on where to look.

My guess is it's somewhere in your routing tables, either the ip routing table or the regular one. Both are pretty simple to set up in this kind of scenario.

And, make sure that you don't have anything configured in the H.323 routing table either. Your logs look like those failed calls are trying to use H.323 settings.

At this point, it has to be something simple.