Details of the issue:
The situation is H600 can establish H.460 calls with most of the GKs around the world, but failed to a Polycom GK.
Allow me to explain the details of this issue:
1. Caller: Group500, callee: H600, GK/MCU: Polycom RMX 2000
2. Group500 sent a call to GK with callModel set to gatekeeperRouted, calling target: H600
3. GK sent H.460 SCI to H600
4. H600 replied SCR to GK
5. H600 established a H.225 TCP connection to the Polycom GK successfully
6. H600 sent facility to GK.
7. Polycom GK shutdown the H.225 TCP connection from H600 actively, and call terminated.Trouble shooting:
Tried to make one another Polycom MT(VSX7000) as the callee, the call was established successfully.
So we captured the protocol commands of both calls to pcap files, and compared the two calls for differences, found out that there were two major differences:
1. Facility reason in step 6
2. CRV(Call reference value) in Q.931
VSX7000’s facility reason was undefinedReason, and CRV in Q.931 was a random non-zero value while,
H600’s facility reason was forwardedElements, and CRV in Q.931 was zero.
Let’s bring out the standard documents about this, we can see that:
1. Rules in H460-18(10 Incoming call procedure):
EPA shall initiate a TCP connection for ITU-T H.225.0 to the transport address specified in the callSignalAddress field of the IncomingCallIndication. EPA shall then send an ITU-T H.225.0 FACILITY message with the callIdentifier field set to the value of the callIdentifier sub-field of the IncomingCallIndication of the previously received SCI message. The reason field shall be set to undefinedReason and the conferenceId field shall be omitted. The call reference value shall be set to 0, the global call reference.
2. Rules in H460-19(7.1.1 Capabilities signalling):
a) For outgoing calls the feature identifier shall be included in the SETUP message.
b) For incoming calls the feature identifier shall be included in CALL PROCEEDING,ALERTING and CONNECT messages, and in FACILITY messages with facilityReason set to forwardedElements.
Solution:
The direct action after was change the facilityReason from forwardedElements to undefinedReason for H600, then the call was actually established.
Seems:
1. The CRV value was not relevant to Polycom RMX2000.
2. Polycom RMX2000 does not support H.460.19??? Weird. It was newly purchased by the customer, supposed to be a new model.
Vendor info:
Here are the vendor infos in the tests, with Polycom MCU RMX2000, Polycom MT Group 500 and VSX7000 involved.
Vendor info of Polycom Group500:
t35CountryCode: United States(181)
t35Extension: 0
manufacturerCode: 9009
H.221 Manufacturer: ViaVideo(0xb5002331)
productId: RealPresence Group 500
versionId: Release – 4.3.0-230161
Vendor info of Polycom VSX7000:
t35CountryCode: United States(181)
t35Extension: 0
manufacturerCode: 9009
H.221 Manufacturer: ViaVideo(0xb5002331)
productId: VSX 7000
versionId: Release 8.0 – 14Jun2005 16:08
Vendor info of Polycom MCU:
t35CountryCoe: Israel(88)
t35Extension: 0
manufacturerCode: 172
H.221 Manufacturer: Unknown(0x580000ac)
productId: Polycom RMX 2000
versionId: 8.3.0