Allow T.38 with hard fax, no T.38 to IXM Fax

[Sean655]

I'm looking for a way to allow my onsite fax machines to continue to use T.38 on their outbound transmissions over our SIP trunk but not allow T.38 on inbound fax calls to DIDs that route to our IX Messaging server. The environment uses TLS so I'm not able to use T.38 to IXM.

The call flow is that inbound comes in on SBC to SM to CM on NR 1/codec set 1 which is T.38 with g.711 fallback. Then the call hits AAR to route to specific SIP fax trunk to IXM that uses codec set 5 that is set to passthrough for fax. The call initially negotiates to use g.711 but CM sends a re-invite for T.38.

Inbound calls originating on PRI work fine.

I have Avaya engaged but looking to see if there are any suggestions here.

 

[kyle555]

I don't see why TLS would impact anything in codec/media type selection if SRTP isn't involved.

First things first, check the media rules on the inside and outside of your SBC to make sure the incoming fax from the carrier's SDP passes from outside to inside with the same media parameters just to make sure the SBC isn't changing anything on the way in.

On site fax machines - presumably on analog ports on gateways belong to the network region of the gateway.
Let's just say...
Region 11 - Gateway
Region 1 - SIP trunks
Region 242 - IXM

Sig/trunk 1 - SIP trunks
Sig/trunk 242 - IXM

The far end network region of the SIP sig group defines the codec offer. So, let's say sig 1 and 242 have far-end network regions 1 and 242 respectively.
In ip-network-region 11, the codec set used to get to 1 could be codec-set 1.
In ip-network-region 1, the codec set used to get to destination 242 could be codec-set 5 like in your example.

The SBC has the A1 interface for incoming SIP calls which must exist in CM in the ip-network-map as pointing to ip-network-region 1.

When the inbound call flow happens, CM is going to use the IP address of the SBC interface to know it's from NR1 and your AAR thing makes it know it's going our sig group 242. Presumably you have codec set 5 for calls from NR1 to NR242.

Are the settings Initial IP-IP Direct Media and Direct IP-IP Audio Connections both set to yes in sig group 1 and sig group 242?

Is procr in NR1? Are gateways in NR1? If so, you have a design problem that makes it more complicated.

But, back to the inbound call flow for now. We know we're sending an invite out 242 with codec set 5. We know the IP representing A1 is in the map as NR1.
If the 2 settings are NO, then CMs invite will have a c= line for media to be be on a gateway and never change.
If direct IP = yes and Initial... = no, then CM will send the first invite with a c= line for media to be on a gateway and a reinvite with the c= line of A1 of the SBC to go direct.
If both are yes, then CM's initial invite will have the c= line be A1 of the SBC.

If there's a gateway in the first invite, then it depends whether that gateway's NR/codec supports t38 with 711fallback as a first choice. If so, it'll be in the original invite to IXM, if not, then it'll probably just be 711.

Then if you had direct ip YES and initial...NO, you'll try to shuffle based on what the IP of A1 (NR 1) can do and that where you see your reinvite. I would think fax stuff wouldn't like shuffling.

But, why do you care if you're using T38 or not on inbound? Only reason I can think of is speed. T38 is 9600baud and you can go up to 33.6 kbps on G711.
Couldn't you just work around the whole problem by turning off T38 on IXM and then T38 with 711 fallback is perfect everywhere? Outbound is T38 and inbound to IXM will always be 711?

If you know what the fax DIDs were, you could have fun in the BSC too by making that a URI group, and having another config for incoming calls only matching that URI group. It's topology hiding would, instead of changing the domain to customer.com change it to inc.fax.customer.com. You could have that domain in SM, point to CM, CM have a new sip SIG group with far-end domain inc.fax.customer.com and have no shuffling, hard coded settings, etc.

 

[Sean655]

Thanks for the detailed information. Here's some more info about the setup:

[ul]
[li]The SBC settings are pretty vanilla, Avaya pro svc set it up and I don't see anything being manipulated.[/li]
[li]Procr is in NR1 along with some gateways and an SM that we send outbound traffic over.[/li]
[li]Onsite fax machines are connected to analog ports on gateways in NR1.[/li]
[li]NR 2 has a couple gateways and an SM that handles inbound calls.[/li]
[li]The A1 IP of SBC was not defined in the map. I can create an NR for it and have the SBC mapped there or map it to NR1.[/li]
[li]IXM fax sig is set as NR 58.[/li]
[li]IXM voice sig is set as NR 59.[/li]
[/ul]

SRTP is being used in the codecs and according to Avaya/Brooktrout T.38 is unstable on TLS and not suggested.

SM sig allows direct IP but not initial, IXM Fax sig does not allow direct IP or initial.

Codec 5 does not allow T.38 and IXM Fax is set to g711

 

[kyle555]

OK, so the reinvite from CM for T38 is probably based on an attempted shuffle because the SIP trunk can go direct after initial setup.
In network region 1, in the later pages, is it really set to use codec set 5 to get to 58?

I can't see why the media offer in the initial invite would be different than in the reinvite. It should still offer t38 and g711. IXM on the reinvite should just send back a 200OK supporting G711 and life goes on.

Are the inbound faxes working?

 

[Sean655]

NR 1 is set to use codec 5 to get to 58.
Inbound faxes from PRI work but inbound from SIP carrier fail. Most fax numbers are still on PRI and I'm glad I decided not to port them over.

List trace shows the call coming in and using a resource from a gateway in region 1. I assigned the SBC to region 3. The call comes in to the SBC, gets handled by the SM in region 2 and routed to IXM fax but somehow a media resource from region 1 gets picked.

16:51:46 SIP<SIP/2.0 100 Trying
16:51:46 Call-ID: ec3
16:51:46 Proceed trunk-group 198 member 34 cid 0x18
16:51:46 SIP<SIP/2.0 180 Ringing
16:51:46 Call-ID: ec3
16:51:46 Alert trunk-group 198 member 34 cid 0x18
16:51:46 G711MU ssff ps:20
rgn:3 [10.12.sbc.y]:39490
rgn:1 [10.12.x.x]:4192
16:51:46 xoip options: fax:T38 modemff tty:US uid:0x50053e
xoip ip: [10.12.x.x]:4192

 

[kyle555]

The far end network region of a sig group does NOT define what region incoming calls are assigned.

CM uses the oldest VIA header in the SIP message, which would be the IP address of your SBC. If the the SBC IP didn't have a IP in the map assigning it to a region, it would default to the region of thenear end signaling node of the group, so, procr, so, 1

It's never seeing it as part of region 2.

Again, as long as you've got direct at yes and initial at no, you'll always get a shuffle. What problem are you really having?

 

[Sean655]

Inbound fax calls coming through the SBC try to use T.38 and IXM does not support that. Those fax calls fail.

If I don't allow T.38 at all, then outbound faxes fail. This prevents me from setting NR1 to NR3 to use codec 5(pass through) since the physical fax machines are located in NR 1.

 

[kyle555]

The far end network region of the signaling group is used exclusively for codec selection on media offers to that sig group from the network region that is originating the call.

You mentioned the fax and voice sig groups to IXM were 58 and 59. Presume those are also far-end NR 58 and 59.
Use a different codec set from 1 --> sig 58 that only does G711 and not t38

Assume:
-inbound faxes support g711
-no outbound faxing from IXM
-inbound faxes only terminate on IXM and not real fax machines that also send faxes

If you want t38 in and out of real fax machines on your sip trunka and inbound fax to IXM on your SIP trunks via g711, you need better planned network regions.
*edit: What I'm suggesting would allow t38 in and out of real fax machines in NR1 and only offer 711 on inbound to IXM

 

[Sean655]

Thank you for your time and suggestions.

As far as I can tell, the NRs are set up the way you've described but the behavior does not correlate.
NR 1 to NR 58 was already set to G711.
NR 3 (SBC) to 58 was set to G711.

I'm not sure that the NRs were poorly planned but Avaya pro svcs had a hand in them during CM6 to CM8 migration and this isn't my expertise. I'm educating myself on best practices now.

I could possibly move procr to a separate region instead of it being in NR 1, and also separate GWs and SMs in the same geographic area to different regions.

 

[kyle555]

OK, I presume every NR is directly connected to every other NR, right?

What codec set DOES support T38? Obviously that's sneaking its way into the reinvite.
Is the reinvite T38 only or t38+g711?
You'd need a traceSM to be sure, but is the reinvite from SBC--SM--CM--SM--IXM? Or does it originate at CM--SM--IXM? Maybe it's the provider side trying to negotiate to T38

What is IXM's response to that? 488 not acceptable here?
From a traceSM, is the original invite to IXM containing T38?

Now, I'm not going to expect IXM to adhere strictly to the law of the RFCs, but there's nothing inherently wrong with a request and a 400 response once a session is established. If you happened to get a reinvite refused with a 488, that doesn't end the call. You still need a BYE from one side to the other. Is that what you're seeing?

It's trying to thread a needle a bit without rejigging things to support and configure being able to get out from a gateway/NR1 to a SIP trunk with T38 and have the reverse call flow not do T38...

An easy fix might be to disable direct IP in the sig group to IXM for fax. That should remove the reinvite to try and rejig the media.