1、什么是Outbound proxy（外出代理服务器）？应当设置Outbound proxy 吗？
From the SIP RFC:
Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols.
The outbound proxy is a normal SIP proxy. You configure your client, the phone or software, to use the proxy for all SIP sessions, just like when you configure your Web browser to use a Web proxy for all Web transactions. In some cases, the outbound proxy is placed alongside the firewall and is the only way to let SIP traffic pass from the internal network to the Internet.
The outbound proxy used by a UA can be automatically set with DHCP (this applies to SIP devices mostly, not SIP softphones). There are also autodiscovery solutions, but not frequently used.
Outbound proxy通常是在有防火墙/NAT时用，用于处理信号及帮助多媒体数据流通过防火墙。如果用户有Outbound proxy，并且没有使用STUN或者其它的穿过防火墙/NAT的机制，则应当使用Outbound proxy。但是已经使用了STUN或者其它的穿过防火墙/NAT的工具，则不同时使用Outbound proxy。
2、用户ID（User ID）和认证ID（Authentication ID）有什么区别？
用户ID是电话的SIP地址中用户部分，而且通常是作为呼叫者ID的信息，显示在SIP软件或者电话机的LCD上。典型的情况下，用户ID是一个电话号码或者是扩展了的数字，或者是一个用户的名字。而认证ID则是严格地用于认证目的之ID，是电话机联系SIP服务器时验证用户身份用的ID。认证ID可以与用户ID相同，也可以不一样。
3、应当选用哪种语音编码方法？
通常的情况下，所有的编码方法，都能够提供良好的语音。但是低比特速率的编码，对音乐来说质量可能有些差。DTMF（双音多频传输法）音调或者传真信号在音频通道上传输（带宽不够时），有可能在远端不能解码。所以，如果带宽允许，选用G.711编码方法，G.722甚至能够给出更好的音质。
带宽允许的情况下，使用PCMU(G711u)编码。PCMU and PCMA都能够达到CD音质，但是它们消耗的带宽也最多(64kbps)。如果网络带宽比较低，可以选用低比特速率的编码方法，如G.723或G.729，这两种编码的方法也能达到传统长途电话的音质，但是需要很少的带宽（G723需要5.3/6.3kbps，G729需要8kbps）。
如果带宽足够并且需要更好的语音质量，就使用PCMU 和 PCMA，甚至可以使用宽带的编码方法G722(64kbps)，这可以提供有高保真度的音质。
4、"Voice_Frames_Per_TX"是什么意思？它与以太网的流量有什么关系？
为了减少整个 以太网/IP/RTP 的开销（这些开销是由54字节的报文头引起的），多个语音帧可以包在单个以太网帧中发送。不过，这会引起语音延迟。在网络带宽比较紧的时候，增加这个数量，可以提高整个语音质量。
如果RTP数据包每2.5ms发送一个（G.728），则整个以太网/IP/RTP的开销是
0.432*400 = 172.8kbps
这在公共Internet上，将会不太好。但是，如果RTP数据包每10ms发送一个，则总的以太网/IP/RTP的开销是
0.432*100=43.2kbps
如果RTP数据包每20ms发送一个，则总的以太网/IP/RTP的开销是
0.432*50=21.6kbps
推荐对G.723/iLBC编码，每30ms发送一个数据包，所有其它的编码则每20ms发送一个包。所以，对G.723/iLBC编码，Voice_Frames_Per_TX的值设置为1，对G.728设为8，对所有其它的编码设为2。
5、Voice_Frames_Per_TX应当设置为什么值？
这取决于选用什么样的编码方法，及在带宽利用率与丢包影响之间的折衷。这个值越大，则带宽利用率越高，因为更多的语音帧放到一个UDP/RTP数据包中，这样数据报文头的开销减少了。但是丢失了一个数据包，对语音质量的影响比较大。
对PCMU/PCMA，默认值是2，最大值是10
对G.723，默认值是1，最大值是32
对G726-32，默认值是2，最大值是20
对G729，默认值是2，最大值是64
对G728，默认值是4，最大值是64
6、以太网加到RTP数据包上的开销是多少？
对于语音数据，在以太网的IP网上传输，一个RTP数据包包含54字节（或者432比特）的报文头。这54字节包含14字节的以太网头，20字节的IP头，8字节的UDP头，和12字节的RTP头。
7、各种编码方法的帧的速率及比特速率是多少？
G.711 是10ms的帧长度， 64kbps的比特速率
G.722 是10ms的帧长度， 64kbps的比特速率
G.726-32 (也叫 G.721)是10ms的帧长度，32kbps的比特速率
G.728 是2.5ms的帧长度， 16kbps的比特速率
G.729 是10ms的帧长度， 10kbps的比特速率
G.723 是30ms的帧长度， 5.3kbps或者6.4kbps的比特速率
iLBC 是20ms或者30ms的帧长度，15.2kbps 或者 13.3kbps 的比特速率
8、为什么G.723是低带宽的IP通信中最佳的选择？
对G.723，其帧速率是30ms发一个数据包，编码的速率是5.3kbps (20 bytes 每 30ms)或者6.4kbps (24 bytes 每 30ms)。其总的比特速率是
5.3 + 0.432*33.3 = 19.7kbps,
或者 6.4 +0.432*33.3 =20.8kbps。
如此低的比特速率，很适合于在28.8kbps拔号上网的时使用。再与其它的技术配合，如数据链路层压缩、静默抑制，及舒适的噪声产生，总的带宽可能更低。
9、什么是STUN服务，我是否需要使用STUN服务？
STUN代表UDP数据包简单地穿过NAT（Simple Traversal of UDP over NAT）。这是一个协议，当一个IP电话机在NAT后面时，IP电话机可以使用这个协议检测到NAT的存在，并判断NAT的类型。一个IP电话机如果支持STUN协议，它就可以发送一系列的STUN查询，到公共的因特网上的STUN服务器，这样就可以得到NAT上映射到话机的公网IP地址和端口。IP电话机就可以智能地修改SIP/SDP消息中的私有IP地址。这样SIP信令和RTP多媒体数据就可以成功地穿过NAT，而不需要修改NAT的任何配置。
STUN代表了对大多数NAT的解决方法，但是不适合于对称的NAT。也就是说，绝大多数的SOHO路由器都是非对称的NAT，在这种情况下，使用STUN是成功的。但是STUN协议不能穿过对称的NAT。如果你的路由器是对称的NAT，则不要使用STUN。
10、如果我的电话机使用了STUN服务，能够正常地工作，我还需要设置外出代理服务器（Outbound proxy）吗？
不需要设置Outbound proxy
11、SIP应用中有哪些DTMF类型？
DTMF在VOIP SIP的应用的分为两种，一种是用SIP信令的INFO方法携带DTMF信号，另一种是在RTP媒体传输中携带DTMF信号：
1) 用SIP信令的INFO方法携带DTMF信号。
该方法是用SIP信令的INFO方法来明文定义来代表DTMF信号。该种方法还在研究讨论当中，有专家认为其并不适用，主要缺陷是因为SIP控制信令和媒体传输（RTP）是分开传输，很容易造成DTMF信号和媒体包不同步。简单举个例子，在 Voice Mail应用中，用户根据提示音输入一个DTMF信号，随后开始留言。Server是在接受到该DTMF信号后开始保存用户的留言。然而由于DTMF信号是通过SIP信令来传输的，而媒体流是通过RTP来传输的，有可能用户留言的RTP包先到，而该DTMF信号的INFO消息延迟，导致Server不保存用户的语音留言直至接受到INFO消息。
2) 在RTP媒体传输中携带DTMF信号。
该方法是将DTMF信号和媒体流一样，用RTP包来传输，因而没有DTMF信号和媒体流不同步的问题，使用H323信令的VOIP就是采用该种方法，相对来说比较成熟。
而其中又分In band和Out of band（RFC2833）两种：
a) In Band DTMF
In Band DTMF是指直接将DTMF的音频数字信号不经任何处理直接打成RTP包在IP网中传输。其中可能和用户的语音媒体流混合（mix）在一起传输。程序要获知哪个包有DTMF信号，是什么DTMF信号，必须实时检查每个RTP包里面的媒体流数据，分析它的频域。
b) Out of Band DTMF(RFC 2833)
Out of Band DTMF是DTMF信号用专门的RTP包进行标识，在RTP包的头域中就可得知该包是DTMF包，并且知道是什么DTMF信号。RFC2833专门对此有定义。
当前对于DTMF事件的传送有三种途径：
1. In-band 带内
2. RFC2833
3. SIP INFO消息
一般来说，第一种和第二种方法都需要支持。
对于第二种方法，SDP使用audio/telephone-event或audio/tone媒体类型。详情查看RFC4733-RFC2833的升级。
对于第三种方法，在SDP中带有事件。此时可以使用的媒体类型为application/dtmf-relay或application/dtmf或application/kpml。
1. application/dtmf-relay为思科VOIP产品所用，但不能成为注册的MMIE.
2. application/dtmf也没成为注册的MMIE，详见seedraft-kaplan-sipping-dtmf-package-00.txt
3. application/kpml为注册的MMIE，是建议使用的类型。详见draf-sipping-sip-interaction-framework。
12.启用静音压缩，可以通过检测通话阶段中的静音，并对其进行一定的处理，来达到节省网络带宽，减少时延的作用。若不选择则即使检测到静音也仍产生正常的音频信号并传输。在本设备中有舒适噪音产生的技术，在选择静音压缩，并处静音期的情况下，设备会产生静音包，既节省带宽又能使通话双方感觉舒适。
启动回音消除技术，可以消除己方回音传输对对端的影响。
13. SIP offer 和answer 对应关系
在3261里有规定INVITE如果带offer, 那么200就要带answer; INVITE如果没带，200就要带offer.
但3262里也有规定如果INVITE带offer, 那么可靠的临时应答1xx要带answer. 在这种情况下, INVITE的200是否需要再带anwser呢?
200OK是可以不带SDP的。
offer/answer存在的情况：
1. Invite_________offer............Invite200______answer
2. Invite200______offer............Ack____________answer
3. Invite_________offer............1xx____________answer
4. 1xx____________offer............PRAck__________answer
5. PRAck__________offer............PRAck200_______answer
6. Update_________offer............Update200______answer
像上面，如Update的情况下200Ok是不用带SDP的。^_^
14. PRACK
PRACK是SIP消息中保证临时消息(101-199)可靠传输的机制。为达到该目的，UAC有两种选择，在inivite消息中加入Require:100rel或者Supported:100rel。UAS在接受到上述消息中，也存在选择的问题。
当Inivte中含有Supported:100rel，UAS在发送临时消息中，可以根据UAS中是否支持PRACK决定发送临时消息中的参数。如果支持则临时消息中加入Require:100rel和Rseq字段，接到该消息UAC发送PRACK；否则不加上述参数，UAC不发PRACK。
当Inivte中含有Require:100rel。UAS如果不支持PRACK需要使用420（不正确的扩展）来拒绝呼叫。否则临时消息中加入Require:100rel和Rseq字段，接到该消息UAC发送PRACK。
1)SIP中的最终响应被理解是会可靠传输的，例如对应INVITE的200OK响应，UAC会给一个ACK，告诉UAS已经收到了200OK。 200 与 ACK间的可靠性是end-to-end的。
2)PRACK就是仿照200OK的可靠性响应，对除100以外的1xx临时响应（100是hop-to-hop的），进行可靠性传输。
3)UAC与UAS对是否支持该扩展的协商，就是通过一个option tag -- 100rel。
例如：UAC发起的INVITE中含有Supported: 100 rel,而UAS也支持该扩展并且在183响应中有Require:100rel，说明接下来会话中，对所有100以外的1xx响应，均要有PRACK回应。
如果对话支持100rel,183后面一定要跟prack以支持可靠传输，如果对话不支持100rel，183后不会跟prack的，另如果支持update方法，那也一定会支持100rel的
也就是说,如果请求中有100rel标志,UAS必须用可靠传输的方式发送非100的临时响应(101-199),如果UAS不愿意这样做,它得利用420(Bad Extension)拒掉这个请求.
假设UAC接收到需要可靠传输的非100临时响应后,它必须用PRACK方法创建一新请求, 所以UAC收到180,183可靠响应后,它会创建一PRACK请求到UAS.
A SIP UA indicates support for this standard by including a "Supported: 100rel" or "Required: 100rel" as a SIP header.
15。关于我们这个软件中cancle的问题
sip应用中，协议栈对于有的request消息会自动回复相应的response。如对于200OK的ACK。有的消息是提供了一个接口，如sendCANCEL给应用层。应用层在逻辑代码中调用这个接口来进行SIP消息的处理.在check消息流的过程中，应正确区分是协议栈的问题还是应用层的问题。
如我们的软件中app层面会重复调用sendCANCEL，导致在已经对第一个cancle处理完后，仍发出第二个，属应用层逻辑问题。
16.Early-Media
dialog(对话)的建立是UAC收到UAS的100以外的1XX(带To tag)响应时建立的,这时叫做早期对话--->early dialog.
收到2XX的应答开始才是被证实的对话--->confirmed dialog建立。
"early-session"和正常的session(regular session)的唯一区别是early-session是在early dialog中建立的（可参考RFC 3959 ），同样是遵循offer/answer模型的
early media媒体通道在Invite消息得到最终响应之前已经建立，真正的会话时需要采用新的媒体通道
在发话方发送INVITE之后和受话方接听之前（200 OK之前），双方所交换的AUDIO或VIDEO被称为“Early Media”,而这些AUDIO和VIDEO所组成的RTP Stream被称为“Early Session”
RFC3259明确的讲：Application servers perform an offer/answer exchange with the User Agent Client (UAC) to exchange early media exclusively, while
UASs use the same offer/answer exchange, first to exchange early media, and once the regular dialog is established, to exchange regular media.
UAS 可以将early session的SDP放入可靠临时相应比如183的message body中，甚至同时也存放regular session的SDP ,以Content-Disposition注明是early session还是regular session的SDP，UAC收到以后将SDP分别取出，并可用PRACK做为early answer发给UAS，等到UAC收到回应PRACK的200OK后early session就建立完成了。当UAC收到初始INVIE的200 OK并发送ACK后，建立起通话用的regular session
或者UAS在给UAC的可靠临时响应中加Alert-Info头，UAC按Alert-Info中指定的地址去Media Server取得媒体档案来播放
INVITE F1 [offer]
-------------------------->
100trying F2
<--------------------------
183 Sessing Progress F3 [answer][early-offer]
<--------------------------
PRACK F4 [early-answer]
-------------------------->
<================媒体通道================>
200 OK(PRACK) F5
<--------------------------
UPDATE F6
-------------------------->
200 OK(UPDATE) F7
<--------------------------
180 Ringing F8
<--------------------------
PRACK F9
-------------------------->
200 OK(PRACK) F10
<--------------------------
200 OK F11
<--------------------------
ACK F12
-------------------------->
<================媒体通道================>
.....................
.....................
BYE F13
-------------------------->
200 OK F14
<--------------------------
F3 UAC收到非100的1XX(带To tag)响应时建立起early dialog
F3 F4 early session的offer/answer完成以后建立起早媒体的通道
F11 200 OK之后建立起regular dialog，early session结束
为了regular session 要建立新的媒体通道
F13 当BYE请求一发送到客户端事务,regular session就结束了（也就停止发送或者接收媒体流）
F14 当BYE请求收到200 OK应答后，regular dialog也结束
还要说明的是以下几种情况都可能带SDP：
INVITE-可靠18X(INVITE)
可靠18X(INVITE)-PRACK
INVITE-200(INVITE)
200(INVITE)-ACK
PRACK-200(PRACK)
UPDATE-200(UPDATE)