SDP通信协议开发和组件移植

       通信终端要面对各种服务器流程，这些流程大多数都符合RFC标准，但是标准并不是业务流程规范，它给出了积木，而积木的形状则各式各样。

      对于Calling组件而言，它最重要的除了流程控制之外（这个还是挺容易实现的），还有很大程度上取决于SDP的灵活。SDP最重要的部分是获取准确的媒体参数，因为它的名字叫着会话描述协议。媒体参数就代表了上下文。再者SDP的作用就是业务判断：业务判断说容易也容易，说难也难。因为RFC3264定义了SDP如何表示基本的业务。但问题是这些业务有时会同时出现，这是RFC上未做说明的。比 如会话在Hold状态时却收到了add-media的SDP（想象hold电话时又收到了对方的视频请求）。Hold时收到了session-timer时下发的re-invite携带的SDP（标准上推荐re-invite应该带SDP，UPDATE就不要带了）。这些业务并行发生时，并不好由SDP来判断，可以由应用层做控制。在保持时，如果收到了不可以判断成恢复的SDP请求，则一律忽略该操作，当成是session-timer。

    有些终端提供的业务流很是恶心的，虽然它按照SDP标准增加m行，但是该方向属性却为inactive。又或者是增加m行，但是端口号却为0。足以说明后端服务器人员对标准理解的不透彻。因为，方向属性会影响终端对保持或恢复操作的判断，而m行会影响终端对增删媒体的判断。

    另外，关于媒体ON/OFF的场景。
    其实说白了，媒体就是根据媒体参数的变化来变化。需要注意的是保持情况，即sendrecv->sendonly时是保持操作，而此时应该暂停媒体，而不应该只是只发不收。若是采用3GPP中的sendrecv->inactive的策略，则媒体开关控制就不存在保持情况的特殊处理，但是没办法，终端要兼容这种情况。

   关于SDP协议栈/业务组件等移植到各终端平台

   代码需要写的规范标准，才能很好很迅速的移植。比如在Symbian平台下，.mmp文件是用来进行工程设置的，这个如果不正确，会影响release版本的生成。比如如下情况都会造成链接器失败：

1，代码中含有全局变量或静态变量
2，包含多余的头文件。
3，嵌套包含头文件。
4，出现了如下格式的语句

  ...
goto err:
   ...

 case xx:
 {
     int i;
 }

err:

5,  函数指针要先声明，再定义。（函数或变量也应该先声明，再使用，这个好处很大的）。
如不要写 int fun(int (*p)());
应该 typedef int (*p)();
     int fun(p p1);

   移植对于Brew平台而言会相对容易些。因为Brew平台只支持单线程，静态应用程序支持全局和静态变量，而动态应用程序不支持。另外，在BREW下面，应该使用它的平台C库，而不允许使用标准C库。

   在BREW静态应用程序下面使用全局变量有个需要注意的地方，因为BREW在加载程序时，会初始化所有的全局变量，此时如果全局变量的构造函数中使用到了库函数是有问题的，因为库函数地址总是在程序加载后才知道。所以全局变量最好是指针。（程序使用单件模式就可以避免全局变量了）

   对于不支持多线程的平台，都使用定时器来模拟多线程。

   而在WINCE平台下，移植基本上是一些头文件的替换，不过有个恶心的地方就是，WINCE对时间函数支持不好，有些函数如time(),gmtime()都是只声明没定义。需要自己来实现相应功能。windows mobile不支持GOTO语句