CUCM to RightFax via SIP missing ANI

[chris.black42]

I have an interesting case where the RightFax server is not seeing any ANI/DNIS information coming from CUCM. The steup is pretty standard: PSTN ---> MGCP Controlled GW ----> CUCM ---> Route Pattern ----> SIP Trunk ----> RightFax Server.

RightFax does not support NSE, so I made sure it was a T38 passthrough setup in the MGCP code.

All the faxes are supposed to be routed to individuals within RightFax, however it's all just dumping to the default administrator account. RightFax support says that's because CUCM is not passing the digits over. However you can see the information in the debugs. Just not where RightFax wants them.

Any ideas?

[shane.orr]

PSTN Router Model, Router IOS Version, and PVDM-2 or PVDM-3?

[chris.black42]

Afternoon Shane,

I'm still banging my head on this, I'm looking at debug statements that show the DNIS/ANI leaving CUCM. When they get to RightFax, their debugs show no information. So of course the error falls back to my setup...somewhere.

PSTN Router Model: 3825

IOS: 12.4(20)T1

PVDM2 version with 23.6.2 firmware

Current MGCP Stat:

MGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONE

MGCP call-agent: CUCMPUB Initial protocol service is MGCP 0.1

MGCP validate call-agent source-ipaddr DISABLED

MGCP validate domain name DISABLED

MGCP block-newcalls DISABLED

MGCP send SGCP RSIP: forced/restart/graceful/disconnected DISABLED

MGCP quarantine mode discard/step

MGCP quarantine of persistent events is ENABLED

MGCP dtmf-relay voip codec all mode out-of-band

MGCP dtmf-relay for voAAL2 is SDP controlled

MGCP voip modem passthrough disabled

MGCP voaal2 modem passthrough disabled

MGCP voip modem relay: Disabled

MGCP T.38 Named Signalling Event (NSE) response timer: 200

MGCP Network (IP/AAL2) Continuity Test timer: 200

MGCP 'RTP stream loss' timer disabled

MGCP request timeout 500

MGCP maximum exponential request timeout 4000

MGCP gateway port: 2427, MGCP maximum waiting delay 3000

MGCP restart delay 0, MGCP vad DISABLED

MGCP rtrcac DISABLED

MGCP system resource check DISABLED

MGCP xpc-codec: DISABLED, MGCP persistent hookflash: DISABLED

MGCP persistent offhook: ENABLED, MGCP persistent onhook: DISABLED

MGCP piggyback msg ENABLED, MGCP endpoint offset DISABLED

MGCP simple-sdp DISABLED

MGCP undotted-notation DISABLED

MGCP codec type g711ulaw, MGCP packetization period 20

MGCP JB threshold lwm 30, MGCP JB threshold hwm 150

MGCP LAT threshold lwm 150, MGCP LAT threshold hwm 300

MGCP PL threshold lwm 1000, MGCP PL threshold hwm 10000

MGCP CL threshold lwm 1000, MGCP CL threshold hwm 10000

MGCP playout mode is adaptive 60, 40, 1000 in msec

MGCP Fax Playout Buffer is 300 in msec

MGCP media (RTP) dscp: ef, MGCP signaling dscp: cs3

MGCP default package: fxr-package

MGCP supported packages: gm-package dtmf-package trunk-package line-package

                         hs-package atm-package ms-package dt-package mo-package

                         res-package mt-package fxr-package md-package

MGCP Digit Map matching order: shortest match

SGCP Digit Map matching order: always left-to-right

MGCP VoAAL2 ignore-lco-codec DISABLED

MGCP T.38 Max Fax Rate is DEFAULT

MGCP T.38 Fax is ENABLED

MGCP T.38 Fax ECM is DISABLED

MGCP T.38 Fax NSF Override is ENABLED: 000000

MGCP T.38 Fax Low Speed Redundancy: 0

MGCP T.38 Fax High Speed Redundancy: 0

MGCP Fax relay SG3-to-G3: ENABLED

MGCP Fax relay ANSam suppression: DISABLED

MGCP control bound to interface GigabitEthernet0/0

MGCP media bound to interface GigabitEthernet0/0

MGCP Upspeed payload type for G711ulaw: 0,  G711alaw: 8

MGCP Dynamic payload type for Cisco fax indication: 96, Cisco fax ack: 97

MGCP Dynamic payload type for G.726-16K codec

MGCP Dynamic payload type for G.726-24K codec

MGCP Dynamic payload type for G.726-32K codec

MGCP Dynamic payload type for G.Clear codec

MGCP Dynamic payload type for NSE is 100

MGCP Dynamic payload type for NTE is 99

MGCP rsip-range is enabled for TGCP only.

MGCP Comedia role is NONE

MGCP Comedia check media source is DISABLED

MGCP Comedia SDP force is DISABLED

MGCP Guaranteed scheduler time is DISABLED

MGCP DNS stale threshold is 30 seconds

Current SIP Profile config on SIP:

Early offer for G.Clear Calls: Disabled

Checkmark on Outgoing t.38 invite include audio mline

SIP Security Profile:

Incoming TCP+UDP

Outgoing UDP  --- This was set because RightFax only accepts UDP

Trunk config:

Port: 5060

DTMF: RFC 2833

Route Pattern:

4.9XX with discard predot.

Called Party selection has been: Cisco CM, Subscriber, National, and Unknown with no changes in DNIS/ANI presentation to RightFax.

[Ayodeji Okanlawon]

I dont know why rightfax does this, but this is the second time I am seeing this issue on the forum. You need to look at cucm traces and see what CUCM is sending to rightfax over the sip trunk. Can you enable detailed cucm traces and attach here? Please send the calling and called number

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[shane.orr]

Chris, are you opposed to trying H323 instead of SIP from CUCM to RFax?

[chris.black42]

Not opposed, would like to avoid that until I give up or this wall I'm banging my head on does. =)

I've attached a CUCM trace log. Fire up VLT and parse out for 980 or and IP ending in .19 That would be the RightFax Server.

Here is something odd though, looking at the output of the RightFax system, they seem to be parsing on Calling instead of Called....at least that's how I'm reading this output below:

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BfvCallWaitForSetup returns=1

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BoACALL:Call type=4  did_digits='980'

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BoACALL:CDPN:980, CDPSA:, CIPN:5034062124, CIPSA:, RN:, RR:0

(M-D-Y)07-09-2012 09:08:59[PID:113316332,TID:113316332]<->CH[0] Brooktrout: BoPANI:Parsing ANI/DNIS String "5034062124" using pattern "49XX"

(M-D-Y)07-09-2012 09:08:59[PID:113316332,TID:0]<->CH[0] Brooktrout: BoPANI:Returning (0), ANI="", DNIS=""

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BoACALL:dest_id='', rtenum=, len=0

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BoACALL(CallAccept): call_result.status = 0, call_result.line_status:0, Line_state=1

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BoACALL(WaitForAccept): call_result.status = 0, call_result.line_status:0, Line_state=2

(M-D-Y)07-09-2012 09:08:59[PID:118152460,TID:113316332]<->CH[0] Brooktrout: BfvCallWaitForAccept = AnswerSuccess

[Ayodeji Okanlawon · Accepted solution]

Chris,

Looking at the traces we can 1000% confirm that cucm is sending the rights digit and looking also at the trace from the brookout server, we see the did_digits=980 (called number) and the ANI=5034062124

+++CUCM sends an Invite to DN=980 @ip=192.9.201.19+++++++

07/12/2012 10:56:04.406 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.9.201.19:[5060]:

INVITE sip:980@192.9.201.19:5060 SIP/2.0

Date: Thu, 12 Jul 2012 17:56:04 GMT

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

From: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943

+++CUCM receives a ringing from the brookout server+++

07/12/2012 10:56:04.409 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 426 from 192.9.201.19:[5060]:

SIP/2.0 180 Ringing

From: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943

To: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134

Call-ID:

d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11

+++++CUCM receives a 200 ok from the dialogic server with SDP+++++++

incoming SIP UDP message size 709 from 192.9.201.19:[5060]:
SIP/2.0 200 OK
From: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943
To: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134
Call-ID: d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11
CSeq: 101 INVITE
Via: SIP/2.0/UDP 192.10.200.11:5060;branch=z9hG4bK42a6b3da3c3
Supported: timer
User-Agent: Brktsip/6.3.4B11 (Dialogic)
Contact: <192.9.201.19>
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 218

v=0
o=- 2209261406 0736283000 IN IP4 192.9.201.19
s=no_session_name
t=0 0
m=audio 56224 RTP/AVP 0
c=IN IP4 192.9.201.19
a=rtpmap:0 pcmu/8000
m=audio 56224 RTP/AVP 8
c=IN IP4 192.9.201.19
a=rtpmap:8 pcma/8000

+++++CUCM sends an ACK to the 200 ok with the codec to use for the call as g711ulaw+++++

07/12/2012 10:56:04.458 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 192.9.201.19:[5060]:
ACK sip:192.9.201.19:5060 SIP/2.0
Date: Thu, 12 Jul 2012 17:56:04 GMT
From: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943
Allow-Events: presence
Content-Length: 178
To: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134
Content-Type: application/sdp
Call-ID: d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11
Via: SIP/2.0/UDP 192.10.200.11:5060;branch=z9hG4bK42b7ac2dab8
CSeq: 101 ACK
Max-Forwards: 70

v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 192.10.200.11
s=SIP Call
c=IN IP4 192.10.200.2
t=0 0
m=audio 17522 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
m=audio 0 RTP/AVP 8

++++After the call was established, cucm gets an invite from the brook rout server to swicth to fax using t.38+++++++++

NB: The calling and called number is correct or present.

07/12/2012 10:56:07.462 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 815 from 192.9.201.19:[5060]:
INVITE sip:5034062124@192.10.200.11:5060 SIP/2.0
From: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134
To: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943
Call-ID: d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.9.201.19:5060;branch=z9hG4bK-41137-fe34258-4246a3f0
Supported: timer
Max-Forwards: 70
User-Agent: Brktsip/6.3.4B11 (Dialogic)
Contact: <192.9.201.19>
Min-SE: 1800
Content-Type: application/sdp
Content-Length: 286

v=0
o=- 2209261406 0789715000 IN IP4 192.9.201.19
s=no_session_name
t=0 0
m=image 56224 udptl t38
c=IN IP4 192.9.201.19
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy

++++after cucm sent a trying to this invite, cucm sends a 200 ok with t.38 capabilites++++++++

Outgoing SIP UDP message to 192.9.201.19:[5060]:
SIP/2.0 200 OK
Date: Thu, 12 Jul 2012 17:56:07 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134
Allow-Events: presence
P-Asserted-Identity: "TRUECOMM COM" <5034062124>
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Remote-Party-ID: "TRUECOMM COM" <5034062124>;party=called;screen=yes;privacy=off
Content-Length: 144
To: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943
Contact: <5034062124>
Content-Type: application/sdp
Call-ID: d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11
Via: SIP/2.0/UDP 192.9.201.19:5060;branch=z9hG4bK-41137-fe34258-4246a3f0
CSeq: 1 INVITE

v=0
o=CiscoSystemsCCM-SIP 2000 2 IN IP4 192.10.200.11
s=SIP Call
c=IN IP4 192.10.200.2
t=0 0
m=image 17522 udptl t38
m=audio 0 RTP/AVP 8

++++++next we see the dialogic sending an ACK to the 200 ok+++++++

Incoming SIP UDP message size 458 from 192.9.201.19:[5060]:

ACK sip:5034062124@192.10.200.11:5060 SIP/2.0

From: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134

To: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943

Call-ID:

d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11

CSeq: 1 ACK

Via: SIP/2.0/UDP 192.9.201.19:5060;branch=z9hG4bK-41137-fe34262-1a8a2c82

Contact: <192.9.201.19>

Max-Forwards: 70

User-Agent: Brktsip/6.3.4B11 (Dialogic)

Content-Length: 0 Incoming SIP UDP message size 458 from 192.9.201.19:[5060]:
ACK sip:5034062124@192.10.200.11:5060 SIP/2.0
From: <980>;tag=8bd3590-0-13c4-55013-41134-5e021916-41134
To: <5034062124>;tag=889d6a73-ead2-4dbe-880d-1e50bab4ebeb-20702943
Call-ID: d7e49780-fff10fb4-dc-bc80ac0@192.10.200.11
CSeq: 1 ACK
Via: SIP/2.0/UDP 192.9.201.19:5060;branch=z9hG4bK-41137-fe34262-1a8a2c82
Contact: <192.9.201.19>
Max-Forwards: 70
User-Agent: Brktsip/6.3.4B11 (Dialogic)
Content-Length: 0

So at this point I believe we can safely conclude that this is not a case of cucm not sending the called number.

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[chris.black42]

@aokanlawon

Thank you very much for the step through. That helps with disecting the SIP information.

The RightFax vendor is still questioning why on his debug the ANI/DNIS values output are blank. My only response was, "That sounds like a Layer 7 issue." It was a joke, but as you pointed out in the CUCM debugs, we have passed along the ball to the next player and it's up to them to get it in the goal.

To rule out bugs on the RightFax side, the vendor is requesting an upgrade of the RightFax server to their latest SR3 version.

Thanks again for your help and I'll keep you posted.