No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

H.323 trunk to SBC intercom with CiscoCallManager (CCM). Outgoing call failure

Publication Date:  2012-08-09 Views:  37 Downloads:  0
Issue Description
SX is connected to CiscoCallManager(CCM) via H.323 trunk. 
The networking: 
IAD101-SIP(11.0.59.10) directly accesses to SX(11.0.72.10). SX connected via H.323 trunk to server interface of SBC (11.1.72.1). Client interface of SBC(89.185.92.4) sends H.323 messages to CiscoPIX (89.185.64.144), which sends them to CCM (10.60.17.1). Intercom function is enabled on SBC. 
The problem:
The incoming call from CCM is Ok. But outgoing call fails: SX sends Q.931 SETUP -> CCM answers with CallProcceding -> CCM answers with ALERTING -> SX sends RELEASE COMPLETE to H.323 trunk and sends 480 to SIP Caller. 
      
Alarm Information
None.
Handling Process
According to traces and H.323- and TCP- debugs from SBC:
- SBC receives Q.931 ALERTING messages, processes it successfully, then sends it to SX successfully
- Then SBC receives some Q.931 message, which it can't process.
*0.2557407733 FW-1.Tumen-1.72.NMN H.323/8/HQ.931X:
Erro: **** Process call message.decode Q.931 message failed[-1],length[36]
*0.2557407733 FW-1.Tumen-1.72.NMN H.323/8/HQ.931X:
Erro: **** Receive.proc call message failed! protocol[Q.931]
- Then SBC closes TCP connections sending TCP RST to both parties:
*0.2579509966 FW-1.Tumen-1.72.NMN SOCKET/8/TCP PACKET:
1178902391: Output: task = H.323(58), socketid = 2, state = Closed,
src = 11.1.72.1:1720, dst = 11.0.72.10:9371,
seq = 1762918639, ack = 3783270484, flag = ACK RST,
window = 8192
*0.2579509966 FW-1.Tumen-1.72.NMN SOCKET/8/TCP PACKET:
1178902391: Output: task = H.323(58), socketid = 3, state = Closed,
src = 89.185.92.4:14001, dst = 89.185.64.144:1720,
seq = 1762983041, ack = 2313719087, flag = ACK RST,
window = 8192
According to TCP-dump from CCM:
- the last Q.931 message sent from CCM just before receive TCP reset, is NOTIFY message. Obviously, that is the message, which SBC can not process:
No.     Time        Source                Destination           Protocol Info
    8 0.217352    10.60.17.1            89.185.92.4           Q.931    NOTIFY
Frame 8 (76 bytes on wire, 76 bytes captured)
Ethernet II, Src: CompaqHp_ee:df:3b (00:0b:cd:ee:df:3b), Dst: Cisco_ec:32:11 (00:0f:f7:ec:32:11)
Internet Protocol, Src: 10.60.17.1 (10.60.17.1), Dst: 89.185.92.4 (89.185.92.4)
Transmission Control Protocol, Src Port: 1720 (1720), Dst Port: 13369 (13369), Seq: 125, Ack: 529, Len: 22
    Source port: 1720 (1720)
    Destination port: 13369 (13369)
    Sequence number: 125    (relative sequence number)
    [Next sequence number: 147    (relative sequence number)]
    Acknowledgement number: 529    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 65535
    Checksum: 0xd12a [incorrect, should be 0xc3fd (maybe caused by "TCP checksum offload"?)]
TPKT, Version: 3, Length: 22
Q.931
    Protocol discriminator: Q.931
    Call reference value length: 2
    Call reference flag: Message sent to originating side
    Call reference value: 3336
    Message type: NOTIFY (0x6e)
    Notification indicator
        Information element: Notification indicator
        Length: 1
        Notification description: Unknown (0x71)
    Connected number: '2505116'
        Information element: Connected number
        Length: 8
        .... 0000 = Numbering plan: Unknown (0x00)
        .000 .... = Number type: Unknown (0x00)
        1... .... = Extension indicator: last octet
        Connected party number digits: 2505116
What is suspicious?
1. We can see the 'Incorrect TCP checksum' error in the dump. Actually it's caused by 'TCP checksum offload' function of CCM. Actually, it's correct TCP datagram.
2. As we can see from TCP-dump, NOTIFY from CCM contains IE_CONNECTED_NUMBER, 
which is not allowed by Q.931 standard. That's why SBC can't process it. That's legal behavior of SBC.
Root Cause
Possible reasons:
1.Wrong SoftX3000 configuration.
2.According to Operation Guide, the usage of intercom and proxy functions of SBC at the same time is not recommended. 
Probably, not supported well enough and have some bug?
3.Wrong CMM configuration.
4.Wrong SBC configuration.
Suggestions
Advised to CCM admin to adjust CCM's settings to remove IE_CONNECTED_NUMBER from NOTIFY, or do not send NOTIFY at this call phase.

END