无Cause Code---Gi口后的应用服务器无响应

爱卫生

   本例将介绍一个实例。在激活流程中，都是正常的。因此并没有任何的Cause Code。但用户却不能访问它所期望的服务。在终端的屏幕上可以看到总是处于连接服务的状态，经过10多秒的等待，连接建立失败。手机浏览器弹出一个建立失败的窗口提示，然后浏览器自动退出。这是在手机终端上用户看到的现象。那到底背后是什么原因导致的呢？其实如果有这种故障，当然有可能是CC38-network_failure，由于SGSN发给GGSN的激活请求，而GGSN却没有响应，（可能是这个GGSN宕机了，或者是处理GPRS的业务板卡失效了等等。）没有给SGSN回Response消息，这样SGSN要重试N3次乘以T3秒之后，才会给终端回拒绝激活消息，同样要等待较长的时间。
   但本例中，你会发现，其实激活是正常的。因此就可以排除CC38的问题。仔细观察，你会发现，在#3中，MS要访问的是一个RSTP流媒体视频服务（端口号为554可看出），视频服务器地址是10.64.8.254，而RSTP的会话是基于TCP的，因此首先要建立TCP的三次握手。我们在#3看到MS发出了TCP的Syn建立连接请求，但对方Server没有回应。因此，它的网关节点10.64.9.2在#4给MS回了一个ICMP消息告知源端目的网络不可达。同样的步骤重复了三遍（#3到#8)。整个过程经历了10多秒。这就是用户的体验，在终端上等待了10多秒，然后手机浏览器弹出建立连接失败的消息后，退出。

   

hendouse

居然还有目标服务器无响应且无任何原因值回复的情况，按理说GGSN是不是应该代理下，比如在这种情况下下发一个原因值给用户，表示对端不可及之类的原因值呢~ 或者是说#4、#6、#8就是起着这样的作用呢

爱卫生

回复 hendouse 的帖子

  目前来说还没有哦。因为站在GGSN的角度，它只负责监管PDP上下文的创建、修改、删除。而不负责监管MS的上层应用。如果是这样的话，GGSN将为所有的MS的所有应用都要设置Timer来监控，将极大的加重GGSN的负荷，类似的工作应该是防火墙来完成的。类似的功能也可以由ICMP协议来提供。
  

zhengyufu

访问的SP地址(10.64.8.254)是私网地址，在Gi后的Internet没法路由。肯定没法响应。也不关SGSN和GGSN什么事！！！

三方-数据-三郎

我的iPhone终端经常进行媒体流视屏时发生，突然游览器自动退出