Showing results for 
Search instead for 
Did you mean: 

The significance of c=IN IP4 and media (m-line) ports in a T38 fax call



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


Lexmark fax (3rd party SIP) -- sip -- CUCM (MTP Invoked) -- mgcp - GATEWAY - e1/t1 (isdn) -- PSTN


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.


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


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

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 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[5060]:


SIP/2.0 200 OK

Call-ID: SDssdra01-62d85b98adf041da4ec437f4af1d7fc0-a0608l1



o=BroadWorks 3934 2 IN IP4


c=IN IP4

t=0 0


m=image 0 udptl t38










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  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[5060]:


INVITE sip:+38516314026@;transport=udp SIP/2.0

Call-ID: SDssdra01-62d85b98adf041da4ec437f4af1d7fc0-a0608l1



o=CiscoSystemsCCM-SIP 166300 2 IN IP4

s=SIP Call

c=IN IP4



t=0 0

m=image 18632 udptl t38










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^^*       |[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.


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 IP address being used in an SDP and the usefulness of this.

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  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, 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 to put a call On Hold is no longer recommended.

CUCM  no longer uses the 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 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 and a valid port.

paolo bevilacqua
Hall of Fame Master

Post questions in discussions, not in documents.

Sreekanth Narayanan
Cisco Employee

Hi Paolo. This was a leaarning on a couple of cases that I had. It is not a question. I have only posted the document in a Q&A format.

Recognize Your Peers
Content for Community-Ad