Migrated from PRI to SIP and have a few issues - please help

[Mark G]

Hi, we migrated from PRI to SIP trunks for incoming/outbound calls but we have some issues with faxes not coming in or going out(from many vendors but not all). Also, Ec500 will not work via the new SIP trunk so I routed them out a PRI for now but I really need this to work. Is there ANY way to have a call come in and force it to route out a certain trunk vis the SBC's or Session Manager? If I can figure that out I would have certain faxes use a different trunk when coming in as opposed to our new SIP trunk that they seem to be coming into by default. I really need this help. I appreciate any responses.

 

[kyle555]

Who's the carrier?
They should have a DevConnect note. Some carriers require a P-Asserted-Identity that is a DID that lives on your service. Considering a EC500 call has PAI of the outside caller, it's common to see a sigma script like this in a DevConnect note to make sure that the original called party - which would be in the diversion header - is used as PAI instead of the caller's number.

Fax is a crapshoot. T38 may or may not be supported from your carrier to you, but that doesn't mean it's supported on the other end. If someone sends a fax on SIP from Cox to you on Verizon and Cox and Verizon are SIP to each other, there's no guarantee that your supporting T38 gets from Verizon to Cox to their customer's fax machine.

// For Call forward all call and EC500
within session "INVITE"
{
act on request where %DIRECTION="OUTBOUND" and
%ENTRY_POINT="POST_ROUTING"
{
if (exists(%HEADERS["Diversion"][1])) then
 {
 %var1 = %HEADERS["Diversion"][1].URI.USER;
 //%var2 = %HEADERS["Diversion"][1].DISPLAY_NAME;

 %HEADERS["P-Asserted-Identity"][1].URI.USER = %var1;
 //%HEADERS["P-Asserted-Identity"][1].DISPLAY_NAME = %var2;

 remove(%HEADERS["Diversion"][1]);
 }
 }
 }

 

[7deedtz]

Do you have SBC?

 

[Mark G]

Good morning,

kyle555: That would make sense. How can I confirm that? Where exactly does a script like that belong?

7deedta: Yes, we have 2 SBC's

Thanks so much everyone. I am really stressed trying to get this to work. So anything helps and is greatly appreciated.

 

[kyle555]

Do you have a HA pair of SBCs? If so, you'll have a 3rd server, the EMS, that manages the configuration. If that's the case, the pair share their config - so, whichever is live would assume the IP addresses your SM and your carrier are sending to - much like CM duplex.

Otherwise you might have 2 single boxes in 2 different places for georedundancy in which case each box would have the management part built in.

you'd want to get in as root by CLI and traceSBC. There, you'd see the INVITE coming from SM to the SBC and from the SBC out to the carrier.

Based on your description, you'd expect that Sally's Desk calling Sally's Cell would work, but outsider Bob's cell calling Sally's Desk to EC500 to Sally's Cell would fail.

You'd want to compare the INVITE to the carrier for both cases.

In the case of Sally's desk calling her cell, you would see a TO header to the cell and a FROM and P-Asserted-Identity of Sally's desk, or DID in the public unknown table.
In the case of Bob calling thru Sally's Desk to EC500, you'd see TO - Sally's Cell, FROM and P-Asserted-Identity of Bob and Diversion of Sally's Desk.

Presumably the carrier would provide back some error message.

The sigma script is made in the SBC, and in the server configuration for your carrier, in the advanced tab, you can set that script active. You can do just about anything with them - force override number display to a main number, or whatever you might want. In your case, this script would look for a diversion header, which would indicate some ind of forwarding or ec500, and if present, make P-Asserted-Identity be the same as that diversion header so that it looks like the call is from Sally's desk.

 

[Mark G]

Our new SIP carrier is Windstream and they are stating that no diversion header is needed in the SBC for them. So, in the SBC, they have "None" under the advanced tab of Server Configuration.

 

[_n3rdlinger_]

I'll preface this with the fact that I'm coming from an IP office background, so this may or may not be relevant.

One thing that we ran into a lot when doing customer Twinning features was that it would be blocked by the provider when it tried to pass originating caller ID since that number wasn't actually owned by the company. We usually had to work with the provider to ensure they allowed us to pass originating CID.

If it was me, I'd probably sniff on the external interface of the sip trunk of the pbx and see how that call is leaving the system, then I would try to sniff from the SBC and see if it's making it in/out. If it is, then it might be a carrier issue blocking the call for some reason or another.

 

[Wanebo]

I've also had Windstream tell me in the past that no diversion header was needed. But things "magically" started working so much better when I put the sigma script in the Sipera SBC to provide it. I'd suggest giving it a try.

 

[kyle555]

everything looks like its running clean on our side. have you checked your pbx?

 

[Mark G]

I am now understanding this and do think this is what is needed. Being new to SIP and SBC's etc I have a follow up question.

Where exactly do I get the script and the diversion header info? From Windstream? From Avaya?

 

[kyle555]

No, what I pasted in there is a sigma script you can add. What it says is "if a Diversion Header is present, then use that data and overwrite the P-Asserted-Identity with it

 

[Mark G]

ok, awesome! I will add that NOW!

You are all VERY much appreciated!

THANK YOU!!!!

 

[Mark G]

Question:

Doesn't this last line remove HEADERS? A bit confused but still getting it. Thanks.

 

[kyle555]

Yeah, the script says "if there's a diversion header, put it in PAI. And then, on the way out, remove the diversion header.

That way, it looks the same as the user having dialed the outside number from their deskphone