The IMS version is 8.0, SBC version is V200R005C03SPC220. IMS core network is disposed inside the private network but eSpace clients were disposed at the internet, and a SBC was used for the public IP and private IP nat. And the SBC
was the existing device in the network which already used for NGN service. For saving IP address the new built IMS network used the same public IP address, the SBC configuration is like this:
sbc mapgroup proxy 10
softxaddr 10.14.160.4 10.14.160.20
sbc mapgroup proxy 20
The sbc mapgroup proxy 10 is used for NGN and proxy 20 is used for IMS.
But after configured like this, the eSpace client can not registered on IMS.
1. Using Wireshark tool to trace the signaling message on eSpace client PC and found the IP packet were already sent to SBC and received the answer from SBC.
2. Open a SIP message tracing task on PCSCF, then Register the eSpace client, but there is no message been traced. That means SBC have not transferred the message to IMS.
3. Open the debug function in SBC according to R&D's advice, and found when SBC received message from public IP it transferred the message to NGN network, not the IMS network. Checking the configuration we can see that NGN
mapgroup proxy is 10 and IMS' is 20. Consider the NGN and IMS use the same public IP address, how SBC known which private IP address should transferred to when it received the message from the public IP address? Actually SBC
don't known, so it always transfer the message to the first maggroup proxy's private IP address. In this case, it always transfers to NGN network.
5. If we change the IMS mapgroup proxy ID to 1 or other values which smaller than 10, then SBC will transfer the message to IMS, but this affect the NGN service.
6. Add a new public IP in SBC and renew the mapgroup proxy 20's clientaddr and media- clientaddr with the new IP, the problem solved.
The possible issues are:
1. The Register message have not reached SBC.
2. The Register message reached IMS, but IMS refused register because some error occurs.
3. The Register message reached SBC but SBC have not transferred to IMS.
The SBC debugging method is like this (be noticed: this operation will affect the SBC’s performance, if the traffic is high is better not to do this):
1. Open the debug switch, reproduce the problem, collect the debug information
<Quidway>debugging sbc sip user name xxxx // xxxx means the client number or client name which used for Register
<Quidway>debugging sbc sip packet all
<Quidway>debugging sbc sip register all
2. Reregister the client, reproduce the problem and collecting the debug information.
3. Close the debug switch
<Quidway>undo terminal debugging
<Quidway>undo debugging all