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

Sharing the internet IP address cause the eSpace client register failed

Publication Date:  2012-08-09 Views:  38 Downloads:  0
Issue Description
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
clientaddr  220.248.193.90
serveraddr  10.14.161.22
softxaddr  10.14.160.4 10.14.160.20
iadmsaddr  10.14.160.5
media-clientaddr  220.248.193.90
media-serveraddr  10.59.136.22
enable
sbc mapgroup proxy 20                     
clientaddr  220.248.193.90
serveraddr  134.224.25.41
softxaddr  134.224.25.26
media-clientaddr  220.248.193.90
media-serveraddr  134.224.25.133
enable
#
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.
Alarm Information
Null
Handling Process
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.
Root Cause
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.
Suggestions
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
<Quidway>terminal debugging
<Quidway>terminal monitor
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

END