某金融客户SR6608 部署LNS 无法携带手机号码的问题

一     组网：

二     问题描述：

某金融客户SR6608部署LNS，下端3GVPN Clinet拨入，中间运营商LAC（诺西）设备。 要求LAC将3G手机号码上送到LNS，并传递至后台AAA服务器。

现场拨号过程，在LNS上debug l2tp all 报文能看到LNS收到ICRQ报文中“Parse AVP Dialing number: 8614524083062” ，正常解析了手机号码，但debug raidus packet报文中31 Caller-ID属性字段没有任何填充，导致AAA收不到手机号码。

三     过程分析：

拨号时，L2TP没有将calling number的值传给PPP，PPP发送给AAA服务器的callingnumber字段为空。

实际上，L2TP已经携带dialing number，但该值没有传给PPP的szCallingNumber 字段，详见下面的调试信息：

*Sep 10 13:38:19:978 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Checked ICRQ MSG TYPE = 10

*Sep 10 13:38:19:979 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Parse AVP remote call ID 256

*Sep 10 13:38:19:979 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Parse AVP Call serial number: 799089226

*Sep 10 13:38:19:979 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Parse AVP Dialing number: 8614524083062

*Sep 10 13:38:19:979 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Parse AVP Dialed number: lnccbank.ldyh.lnapn

*Sep 10 13:38:19:979 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Put AVP Message Type: INCOMING_CALL_REPLY

*Sep 10 13:38:19:979 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Put AVP Assigned call ID: 7760

*Sep 10 13:38:22:999 2014 LN_ECN_RT_3 PPP/7/debug2: -Slot=2;

  PPP Event:

      Virtual-Template1:0 : PPP send AAA Prim: ulPrimID = 00000001,ulUserID = 0xffffffff

      Detail: ausVlanTag[0] = 65535, ausVlanTag[1] = 65535,

              ulServiceType = 0x6005, ulUserType = 0x10,

              szCallingNumber =      

从代码来看，因为LAC回应的ICCN报文里面只有这两个AVP，导致usUseOptionalPara = 0（usUseOptionalPara 为程序内部调用字段，debug信息未出现）,  如果它为0的话，L2TP就不会调用L2TP_Phy_Ready把dialing-number传递给PPP了。

*Sep 10 13:38:19:986 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Call 7760 recv ICCN in state 5 from Remote Call 256

*Sep 10 13:38:19:986 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Tunnel 1 restarted the Hello timer (60 seconds)

*Sep 10 13:38:19:986 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Checked ICCN MSG TYPE = 12

*Sep 10 13:38:19:986 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Parse AVP Tx connect speed: 8640000

*Sep 10 13:38:19:986 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Parse AVP Framing type: 1

*Sep 10 13:38:19:987 2014 LN_ECN_RT_3 L2TP/7/L2TDBG:  L2TP_CONTROL: Call 7760 established. Sending call structure to IO slot 2

在COMWARE V5平台实现中，认为只有当ICCN中携带了下面的这几个AVP才需要将对端的 LINK信息、以及Proxy信息交给PPP。

Initial Received LCP CONFREQ（26）

Last Sent LCP CONFREQ（27）

Last Received LCP CONFREQ（28）

Proxy Authen Type（29）

Proxy Authen Name（30）

Proxy Authen Challenge（31）

Proxy Authen ID（32）

Proxy Authen Response（33）

上面的8个AVP均是Proxy的AVP，包括LCP的以及CHAP认证2种。

实际是：LINK信息（包括calling number等）都应该交给PPP的，不受ICCN报文是否携带Proxy属性的影响，也不受L2TP模块是否配置了LCP重协商、Chap重协商的影响。

四     解决方法：

R2604P02之后的版本已经解决，在COMWARE V7中也已经修改。