Solved: Cisco VG202 (MGCP) Fax Problem with CUCM 8.0(2) and Sip Trunk

rafael_rung · ‎09-20-2010

Hello,

i have a big Problem with our VG202's.

We have CUCM 8.0(2) with a SIP Trunk to our Telephone Provider.

with the VG202 i tried IOS 12.4.22T5 and 15.0.1M3.

When i connect a Analog Phone to the FXS Port, everything works fine.i can phone out and in.

When i connect a Fax, i can send a fax out and the Sniffer says that it uses G.711 and T.38 is enabled for the transfer.

When i try to receive a fax it stops after a few seconds.

When i look at the trace, the cucm sends one Wrong Invite Packet:(Trace vom Voice Log Translator)

//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP UDP message to 82.z.z.z:[5060]:
INVITE sip:0049xxxxxxxx@82.z.z.z:5060 SIP/2.0
Via: SIP/2.0/UDP 10.x.x.x:5060;branch=z9hG4bK763748f093
From: <sip:0049xxxxxxxxxx@10.x.x.xx0:5060>;tag=ff7b2b03-9c7c-46e3-b0b7-24f31958f09a-20768851
To: <sip:0049xxxxxxxxxx@82.z.z.z:5060;cpc=ordinary>;tag=gK080b28cb
Date: Mon, 20 Sep 2010 14:48:20 GMT
Call-ID: 1057542822_10220@82.z.z.z
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
User-Agent: Cisco-CUCM8.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Contact: <sip:0049xxxxxxxxxx@10.x.x.x:5060>
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
P-Asserted-Identity: <sip:12@10.x.x.x>
Remote-Party-ID: <sip:12@x.x.x>;party=calling;screen=yes;privacy=off
Content-Type: application/sdp
Content-Length: 434

SDP Message
====================================================
v=0
-- The version is: 0
o=CiscoSystemsCCM-SIP 2000 3 IN IP4 10.x.x.x (cucm)
-- Owner/creator and session identifier:
-- User name: CiscoSystemsCCM-SIP
-- Session ID: 2000
-- Version: 3
-- Network type: Internet
-- Address type: IP4
-- Address: 10.x.x.x (cucm)
s=SIP Call
-- Session name: SIP Call
t=0 0
-- Start time: 0
-- Stop time: 0
m=audio 0 RTP/AVP 8
-- Media mode: audio service
-- Transport port: 0
-- Transport protocol: RTP with Audio/Video Profile
-- -------------------------------------------
-- Based on the following codec:
-- 8: The 8kHz PCMA codec
c=IN IP4 10.y.y.y
-- Network type: IP4 Internet\par   -- The connection address: 10.y.y.y
a=rtpmap:8 PCMA/8000
-- The encoding of dynamic audio formats: 8 kHz PCMA codec
a=ptime:20
-- The duration of the packet: 20
m=image 18288 udptl t38
-- Media mode is a network access service and the access control method is 'no authentication required'.
c=IN IP4 0.0.0.0   < our Provider says that this is Wrong..... Bug???
-- Network type: IP4 Internet\par   -- The connection address: 0.0.0.0
a=T38FaxVersion:0
-- other attribute's name
a=T38MaxBitRate:14400
-- other attribute's name
a=T38FaxFillBitRemoval:0
-- other attribute's name
a=T38FaxTranscodingMMR:0
-- other attribute's name
a=T38FaxTranscodingJBIG:0
-- other attribute's name
a=T38FaxRateManagement:transferredTCF
-- other attribute's name
a=T38FaxUdpEC:t38UDPRedundancy
-- other attribute's name
a=T38FaxMaxBuffer:200
-- other attribute's name
a=T38FaxMaxDatagram:72
-- other attribute's name

as explained above our Provider also created a sniffer file and they say that the cucm should provide the right IP Adress for the RDP Connection, 0.0.0.0 is wrong.

we tried this with a MGCP config, when i configure it with skinny, it cannot send and i cannot receive a fax.

any ideas?

Marcos Assakawa · ‎09-23-2010

Hi Rafael, The CUCM will always wait for the IP Address information from the MGCP GW in order to send to the SIP Trunk. If the CUCM doesn't have the information by the time that CUCM needs to send the re-invite to swtich over to T.38, the CUCM will send 0.0.0.0 first and as soon the CUCM receives the IP information from the MGCP GW the CUCM will send another re-invite with the correct IP. We need to make sure that the Service Provider doesn't disconnect the call when we first send the re-invite with 0.0.0.0, so the CUCM will send the correct information a little bit later in the call. Thanks, Marcos

View solution in original post

Marcos Assakawa · ‎09-23-2010

Hi Rafael, The CUCM will always wait for the IP Address information from the MGCP GW in order to send to the SIP Trunk. If the CUCM doesn't have the information by the time that CUCM needs to send the re-invite to swtich over to T.38, the CUCM will send 0.0.0.0 first and as soon the CUCM receives the IP information from the MGCP GW the CUCM will send another re-invite with the correct IP. We need to make sure that the Service Provider doesn't disconnect the call when we first send the re-invite with 0.0.0.0, so the CUCM will send the correct information a little bit later in the call. Thanks, Marcos

Steven Holl · ‎09-24-2010

If you put a CUBE between CUCM and the service provider, it will block the 0.0.0.0 out to the provider.

Well, it will if you run 12.4(24)T4. 15.1(2)T code doesn't behave this way. I'm currently talking to CUBE developers to find out if this change is intentional. There may be a regression for that behavior.

Techincally I think its okay according to spec to do what CUCM is doing, but your provider may not like that or operate properly when it receives it.

-Steve

Steven Holl · ‎09-24-2010

Oh Rafael:

Can you respond back to me with who your service provider is, and what type of SBC they are using to terminate the SIP traffic on their side? I want to collect this information for development since this change in CUBE behavior is causing interop issues with certain providers.

rafael_rung · ‎09-26-2010

Hello Marcos, Hello Steven,

thanks a lot for your answers.

i will do my best to get one or two cubes in, but its not so easy because we have redundent links for about everything and i have to get at least two cubes.

But maybe we can test that and then decide what to do.

As i look in the Sip Packets the Session Border Controller should be from Sonus.

Provider is "Telekom Deutschland GMBH", Part of "Deutsche Telekom AG" in Germany.

patcbr600 · ‎12-22-2010

Hi all,

Today i have faced the same problem with a service provider, i'm sending 0.0.0.0 in the reinvite to the service provider and then get a disconnected from the provider. The only way to get the T.38 working was to change the mgcp to sip on the VG202 to callmanager. I'm using a ISR 2921 on the CUBE.

Is there any IOS developed to workaround this issue for the ISR G2

Thanks

Christopher Graham · ‎12-22-2010

No, there isn't. With MGCP, CUCM does not have the ip address for the outgoing c-line re-invite, which is why it sends 0.0.0.0

This is, however, acceptable per the SIP rfc, so your provider needs to change their response to the re-invite.

Steven Holl · ‎12-23-2010

Maybe you are hitting this bug? CUBE used to supress the 0.0.0.0 t38 mid-call re-invite, but behavior changed, which is why this bug was filed to revert behavior:

CSCtj50993
CUBE sends Re-INVITE to ITSP for T.38 with m=image and c=IN IP4 0.0.0.0