SCENARIO:
This is a common scenario that I have noticed when fax is involved with the following call flow:
PSTN -- siptrunk -- CUCM (MTP Invoked) -- mgcp -- VG224 -- FAX machine
or
Lexmark fax (3rd party SIP) -- sip -- CUCM (MTP Invoked) -- mgcp - GATEWAY - e1/t1 (isdn) -- PSTN
or
FAX machine -- ATA187-- sip -- CUCM (MTP Invoked) -- mgcp - GATEWAY - e1/t1 (isdn) -- PSTN
All inbound and outbound fax calls fail from and to this UCM cluster due to either a timer expiry, or the caller disconnecting the call as he/she doesn't hear/see any progress on the call.
WHAT TO CHECK?
- Is an MTP, either CUCM Software or Hardware invoked in the call?
- What is the CUCM version? If CUCM version is 8.5(1) or below, a CUCM software MTP could be the issue as it does not support T38 pass-through.
This is supported in CUCM version 8.6(1) and above.
- If a Hardware MTP is invoked, check the dspfarm configuration for 'codec pass-through' that will make sure that the T38 signals are passed.
- If all configuration is correct and if MGCP is involved, 'fxr (start)' is being passed when gateway detects fax tone.
WHAT IS SEEN OFTEN?
The configuration is right a lot of the time and still we see the fax calls failing.
Often, we see that
UCM sends an INVITE/200 OK for the voice-to-fax escalation with c=IN IP4 0.0.0.0.
It sends this in the INVITE when the scenario is an inbound fax call, and 200 OK when it is an outbound fax call. (Terminating end starts the escalation to fax)
The problem is that certain 3rd Party vendors and Service Providers think that the 0.0.0.0 is to ask them to only have one-way audio, or to disconnect the call completely. They think that the UCM is sending this because it wants to disconnect the call or only hear from their side.
So, in response to this, the Provider may reject the call.
Here is an example of a reply from the Provider for the INVITE that call manager sent.
11:19:26.813 |//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 1220 from 10.24.255.137:[5060]:
[355182,NET]
SIP/2.0 200 OK
Call-ID: SDssdra01-62d85b98adf041da4ec437f4af1d7fc0-a0608l1
//sdp
v=0
o=BroadWorks 3934 2 IN IP4 10.24.255.137
s=-
c=IN IP4 10.24.255.137
t=0 0
a=recvonly
m=image 0 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
The Provider has rejected the escalation to fax sent by the UCM by changing the m-line to port 0. In SIP, this is an indication of rejecting or disconnecting the call.
The INVITE message sent by the call manager was as below.
We see that the UCM has sent a valid port number, but UCM has sent 0.0.0.0 as the IP address. This is a valid move as per the RFC.
However, if the Provider/3rd party vendor doesn't understand this, they are not following RFC. The section of RFC containing the validity of this move is further below.
11:19:26.745 |//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 10.24.255.137:[5060]:
[355180,NET]
INVITE sip:+38516314026@10.24.255.137:5060;transport=udp SIP/2.0
Call-ID: SDssdra01-62d85b98adf041da4ec437f4af1d7fc0-a0608l1
//sdp
v=0
o=CiscoSystemsCCM-SIP 166300 2 IN IP4 10.24.255.104
s=SIP Call
c=IN IP4 0.0.0.0
b=TIAS:64000
b=AS:64
t=0 0
m=image 18632 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
Why does this affect the call? It's because when the Provider/3rd Party fax device sends in the port=0, it causes the SIPInterface() to send (numT38Fax=0) to the Media layer, and the Media Layer then thinks that there is no fax involved, and therefore, does nothing.
003147882 |2013/04/11 11:19:26.814 |100 |SdlSig |SDPAnswerInd |sessionEstablished |SIPInterface(1,100,68,236) |SIPCdpc(1,100,74,234) |1,100,230,1.166886^10.24.255.137^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] nAudio=0 nVideo=0 nApp=0 numT38Fax=0 nBFCPApp=0 MTPAllocated=0 keepAudiomLineForT38=F transID=0 DTMFMethod=2 DTMFConfig=1 RFC2833PT=98 wantDTMF=1 provideOOB=T FCOffer=0 SipCallState=2 SIPAccessDevice=T RSVPLastCollab=F cfgAddrMode=0 ReqInactiveSDPMidCall=F BFCPAllowed=F
The above part where I have marked ‘numT38Fax=0’ should be 1, not 0. The reason it is 0 is because the m=image line shows port information of 0. This signal is passed from SIPCdpc() to SIPInterface() and ultimately to the Media Layer.
WHAT SHOULD BE DONE TO SOLVE THIS? (RESOLUTION)
The Provider/3rd Party vendor has to first conform to RFC standards.
As per the RFC the mechanism of the port being 0 is for rejecting calls and Removing a media stream, as stated by the heading 8.2.
Here is the section of RFC that talks about the 0.0.0.0 IP address being used in an SDP and the usefulness of this.
http://www.ietf.org/rfc/rfc3264.txt
Under section 8.4 Putting a Unicast Media Stream on Hold
“RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP should be sent to the peer.”
Therefore, from the above, we note that the usage of 0.0.0.0 to put a call On Hold is no longer recommended.
CUCM no longer uses the 0.0.0.0 to put the call on Hold. It uses the SDP with a=inactive/sendonly/recvonly to establish break of audio or transmission of audio only in one direction today.
This is the recommended way of putting SIP calls on hold.
The UCM Media Layer process doesn’t know the address at the time it sends the offer, and therefore, sends 0.0.0.0 in the IP address field, but the port number is valid!
We need the other end (Provider/3rd Party Vendor) to be able to receive this because this kind of method is supported in SIP as you can note above. So, instead of rejecting the call thinking this is a termination, and send port 0, the Provider can send us 0.0.0.0 and a valid port.
