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 ... View more

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 ... View more

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

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 ... View more

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 ... View more

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 ... View more

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 ... View more

Hi Flavio,   We eventually diagnosed that the ACL being put on the wireless clients was blocking access to the clients downloading the Intermediate Certificate from Digicert.  We added in the IP's that the url resolved to and got full access right away.   Best, Leigh ... View more