SIP FoIP issue with Gamma, CUCM and RightFax

[leighharrison]

Hello all,

We're trying to configure a SIP trunk to a RightFax server and are having difficulty in getting it working. 

Setup wise, we have:-

Gamma (SIP provider) - sip trunk - Sonus SBC - sip trunk - CUCM - sip trunk - RightFax Server

From what we can see, the configuration looks fine, indeed, we have a GoldFax server too which runs more than happily.  We've set the SIP trunk down to the RightFax server to be identical to the working GoldFax server.

We've run a Wireshare trace on the RightFax Server and the issue seems to arise when the RightFax server wants to run T38.  The trace is here:-

 

It seems as though the call progresses nicely through normal trying and ringing, but then, when the server wants to talk FoIP using T38, the Call Manager says it's trying and then kicks back a 488 Not Acceptable Media.

I presume the Call Manager is checking with the gateway to see if they can take T38, but gets a "no" back?  As I've said, we have another fax server running quite nicely with no problems.  We've got the SIP Trunk Security profile set to UDP for outgoing (which is a RightFax requirement).  The SIP profile is reatively standard, except we have Outgoing T.38 INVITE include audio mline checked.

Has anyone had this sort of setup before?  Can you shed any light on our issue?

Best, Leigh

[R0g22]

Can you get a SDL trace from CUCM for a test fax ?

[leighharrison]

Hi Nipun,

Thanks for the response.  I've got the trace and gone through it.  The timings weren't an exact match, but I've found the conversation.

In the attached file, on line 170, the invite arrives asking for T38, on line 224, the Trying response goes back.  Then, I think I see the root cause of the issue, on line 248, there is a message saying there is no in band DTMF, so an MTP is invoked on line 249.

On line 309, the server gets a message from the MTP saying it doesn't support pass thru fax.

Do you agree?

What's the best course of action here?  Reconfigure the MTP to support pass thru?  Alter the order of the MTP servers so there's a CM in there offering the service, rather than the ISR  that's currently running the MTP?

Best, Leigh

[R0g22]

If you have viewed that much, I don't need to go through them. Any sort of media resources will fail faxes for sure. Is the MTP being allocated a CUCM software or IOS MTP ?

1. If CUCM 9.X and above with CUCM software MTP, you can go into the service parameters for IPVMS, there would be an option to "Enable Passthrough".
2. If IOS MTP, configure "codec pass-through" on the profile. You would need to shut the profile which would drop any calls utilising the resource so check with "show sccp connections" first.
3. Check why is their an MTP getting invoked due to DTMF mismatch. On both the SIP trunks, ensure you have dtmf set to "No preference" to minimise un-necessary resource allocation.

[leighharrison]

Hi Nipun,

Many thanks for your reply.  I've gone through the configuration of the setup and I've built the SIP trunk down to the RightFax server to have the CM server they're registered with as their primary MTP in the MRGL, the main inbound/outbound SIP trunk is set to have the hardware ISR's as their primary choice.

I've confirmed the CUCM has "Enable Passthrough" set (it was already set)  On the IOS MTP, I've got:-

voice service voip

 allow-connections sip to sip

 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

dpsfarm profile 10 mtp

 description DSP MTP Resources

 codec g711alaw

 codec pass-through

 maximum sessions hardware 100

 associate application SCCP

Again, this was as it's previously been configured - I've not altered anything.

The main inbound/outbound SIP trunk has it's DTMF Signalling set to OOB and RFC2833 (I believe it was to do with an issue getting DTMF to work correctly in Lync), os I've set the RightFax trunk to be the same.

However, I still get told the MTP resource doesn't support pass-thru in the trace.  Any thoughts on this?  Any idea where I look to see which resource is being asked to be MTP for the DTMF, so I can see why it's not offering the service?

Best, Leigh

[R0g22]

I can look at the trace if you can share the SDL file with me with the timestamp.
Can you set the trunks to "No Preference" ? With RFC-2833 and OOB set, the CUCM mandates that both parties should support both the methods. If either party does not support either of them, an MTP or a Xcoder will be invoked always.
Also as a test, can you remove the CUCM software MTP from the trunk MRG and only have the IOS MTP ? I am not really a fan of software resources, they always mess things up especially faxes.

[leighharrison]

Hi Nipun,

Ok, so I've set hardware MTP not both trunks and both ends are set to RFC-2833.  I can't alter it to no-preference as it's in there supporting a lot of other systems.

I think I've managed to grab a failed call on the IOS MTP router and there's a funny result in there (I think).  The call for the MTP (if it is indeed the call, there's 20,000 devices in the system and there was a lot of lines in the debug to wade through).

Here's the bit I think is the failed MTP attempt:-

Jun 19 10:34:04.867: SCCP:rcvd OpenReceiveChannel
Jun 19 10:34:04.867: OpenReceiveChannelMsg Info:
conference_id = 69263086, pass_through_party_id = 50769958
msec_pkt_size = 20, compression_type = 2
qualifier_in.ecvalue = 0, g723_bitrate = 0, call_ref = 58554818
stream_pass_through_id = 16777216, rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0, salt_len 0
requestedAddrType = 0, source_ip_addr.ipAddrType = 0, source_ip_addr = 10.156.102.36, source_port_number = 4000,
audio_level_adjustment = 0
Jun 19 10:34:04.867: sym_xapp_search_for_conn_cb: sess_cb 7FEA8EB1D2A0, sess_id 69263086, conn_id 50769958
Jun 19 10:34:04.867: sym_xapp_create_conn_if_ok: creating new conn_cb for sess_id 69263086, conn_id 50769958
Jun 19 10:34:04.867: sym_xapp_create_and_init_conn_cb: glob_ccm->version 9
Jun 19 10:34:04.867: sccp_extract_and_validate_srtp_context
Jun 19 10:34:04.867: sym_xapp_find_peer_conn_cb: find possible peer_conn_cb for
cur conn_cb 0x7FEA8F078238: sess_id 69263086 conn_id 50769958 conn_id_tx 0 stream_passthr_id 16777216 call_ref 58554818
peer_conn_cb 0x7FEA8EA1C9F0: sess_id 69263086 conn_id 50769948 conn_id_tx 0 stream_passthr_id 16777216 call_ref 58554818, conn_mode 1 rtp_clr 0x7FEA869C61B0
Jun 19 10:34:04.867: sym_xapp_find_peer_conn_cb: find possible peer_conn_cb for
cur conn_cb 0x7FEA8F078238: sess_id 69263086 conn_id 50769958 conn_id_tx 0 stream_passthr_id 16777216 call_ref 58554818
peer_conn_cb 0x7FEA8F077668: sess_id 69263086 conn_id 50769946 conn_id_tx 0 stream_passthr_id 16777216 call_ref 58554818, conn_mode 4 rtp_clr 0x7FEA8F79D9B0
Jun 19 10:34:04.867: sym_xapp_find_peer_conn_cb: found peer_conn_cb, rtp_clr state 4
Jun 19 10:34:04.868: sccp_get_local_address_by_idb: get_physical_ip:1, use IP addr 10.156.102.85
Jun 19 10:34:04.868: sym_xapp_open_receive_chnl agreed_sccp_ver=18, dtmf_method=10, rx_PT=0 conn_info->local_ipaddr=10.156.102.85 conn_info->remote_ipaddr=0.0.0.0
Jun 19 10:34:04.868: sym_xapp_open_receive_chnl: appl_type 2, sess_id 69263086, conn_id 50769958, codec 2, pkt_period 20, sess_type 2 mixed_mode 0, mm_codec 0, mm_pkt_period 0, stream_passthr_id 16777216, rcv_dtmf_payload_type 101, snd_dtmf_payload_type 101, codec_mode 0, rx_dynamic_pt 0, tx_dynamic_pt 0, amr_bitmap 0, call_ref 58554818, profile_id 1, from_dfr_list 0, need_to_deffer 1
Jun 19 10:34:04.868: Enterning sym_xapp_trigger_fsm_or_deffer_event: conn_cb 0x7FEA8F078238
Jun 19 10:34:04.868: sym_xapp_defer_conn_setup_req: setup conn req for sess_id 69263086, conn_id 50769958, conn_id_tx 0, stream_passthr 16777216, call_ref 58554818 is deferred
Jun 19 10:34:04.868: sym_xapp_trigger_fsm_or_deffer_event: conn setup req defered for sess_id 69263086, conn_id 50769958, conn_id_tx 0, stream_passthr 16777216, call_ref 58554818

10.156.102.36 is the CUCM server and 10.156.102.85 is the SBC.

Points of note that are different from the other calls is the line "need_to_deffer 1" and then the setup request look to progress through to saying that the "stream_passthr 16777216, call_ref 58554818 is deferred".

Is that the IOS gateway kicking back the request for a pass-through?  I can't find any information anywhere as to what "need_to_defer" means, but I presume it means it's going to defer/kick the request.

I did put the SDL trace in this thread earlier, if you need any more than that, I can pop some more info in too.

Many thanks in advance, 

Best, Leigh

[R0g22]

The deferred and passthrough in the sccp messages on IOS don't really relate to the pass-through for the MTP not kicking in AFAIK. We are not really sure if these events are even part of the MTP/fax failure we are troubleshooting.

Can you take a SDL trace for a failed fax ? I want to see now after the changes for hardware MTP only what is happening. Also, are these media resources hosted on a ISR-4k by any chance ?

[leighharrison]

Ok, I'll grab the SDL trace off the server now and upload it - thanks for looking at the call again.  And yeah - they're on 4k's.

Best, Leigh

[R0g22]

What is the XE code running ? And are there any other issues being reported for calls utilizing these resources ?

[leighharrison]

03.16.06b.S / 15.5(3)S6b
We've had some odd issues with the boxes to do with DTMF tones being sent through Lync, other than that, pretty well behaved we believe. Though, it is a big system with 20,000 users connected and many faults don't always get through to us

[R0g22]

Ahh ... not a good IOS to be on. Earlier XE codes had issues with media resources, especially 15.5(3). I will want you to be on a more recent IOS. Let's see the trace first since you are dealing with 20000 users or if you can squeeze in a maintenance window, upgrade the box to a 16.X release, 16.3.4 or above.

[leighharrison]

So, the VPN is down at the moment, I'll get the trace uploaded as soon as I can!

[leighharrison]

Hi Nipun,

Thanks for all of your help with this, I've managed to get it sorted now.  After lots of testing, I was at a point where the RightFax server was sending what seemed like fax transmission into CUCM, but it was never going out of the gateway.

Eventually, I built a new set of SIP trunks into the gateways going to Gamma on port 5066, changed all of the legs to "No Preference" and it worked first time!

Hope that helps someone else in the same situation.

Best, Leigh