引：
sip命令與音視頻rtp通話完整流程分析-sxcong-ChinaUnix博客
http://blog.chinaunix.net/uid-15063109-id-132137.html
根據asterisk的代碼，推測出sip server的工作流程如下：
1 客戶端A通過sip發INVITE時，帶的是內網IP和端口。
2 服務器收到后，轉發給客戶端B時，先創建兩個音視頻端口port1,port2，加到客戶端A sdp中，然后發給B。
3 B收到后，肯定是同意了.如果拒絕，以下就不走了。
4 B本地也創建兩個端口，連接port1,port2,帶stun協議，返回自己的公網IP和端口。(這一步可選)
5 B向服務器回復同時，sdp上帶本地的IP和端口。(這一步必須)
6 服務器收到B同意的回復后，再創建兩個端口port3,port4，同時加到sdp中，返回給客戶端A。
7 客戶端A收到sdp后，得到其中的兩個端口，然后本地也創建兩個端口，分別向服務器的兩個端口發數據，(也可以直接向對方的IP和端口發，但對方是內網的，可能收到，也可能收不到,稍后再討論怎么P2P)。
8 客戶端B應該也要創建兩個端口，向服務器的端口發數據。(如果執行過4，這一步直接發數據就行了)。
9 因為端口是一一對應關系，服務器端根據端口號可以知道是哪個用戶發來的，並發往表現哪里的。
10 用戶發bye，或掉線，服務器通知對方結束會話，同時close掉這4個端口。
以上，服務器創建rtp端口的同時，還要創建rtcp端口。
上面的流程是服務器直接在兩點間中轉，不包括經過多服務器間流轉。
如果要做到兩客戶端之間直接點對點，AB雙方的音視頻端口，應該先連stun，取到自己的外網IP和端口后，再發INVITE,這時SDP中帶的是自己的外網IP和端口，雙方直接傳很大可能是收的到的。
大致流程應該是這樣的，可能還有些出入，畢竟是看代碼得出的結論，不是看RFC協議。
只能說發明SIP和RTP的人，大腦復雜度遠超普通人。當初以為HTTP已經夠麻煩的了，不過人家也不過只用了一個端口就可以傳所有數據。rtp的創始人應該是電信背景，可能認為每個端口號相當於電信中的每一路通話了。
1 客戶端A通過sip發INVITE時，帶的是內網IP和端口。
2 服務器收到后，轉發給客戶端B時，先創建兩個音視頻端口port1,port2，加到客戶端A sdp中，然后發給B。
3 B收到后，肯定是同意了.如果拒絕，以下就不走了。
4 B本地也創建兩個端口，連接port1,port2,帶stun協議，返回自己的公網IP和端口。(這一步可選)
5 B向服務器回復同時，sdp上帶本地的IP和端口。(這一步必須)
6 服務器收到B同意的回復后，再創建兩個端口port3,port4，同時加到sdp中，返回給客戶端A。
7 客戶端A收到sdp后，得到其中的兩個端口，然后本地也創建兩個端口，分別向服務器的兩個端口發數據，(也可以直接向對方的IP和端口發，但對方是內網的，可能收到，也可能收不到,稍后再討論怎么P2P)。
8 客戶端B應該也要創建兩個端口，向服務器的端口發數據。(如果執行過4，這一步直接發數據就行了)。
9 因為端口是一一對應關系，服務器端根據端口號可以知道是哪個用戶發來的，並發往表現哪里的。
10 用戶發bye，或掉線，服務器通知對方結束會話，同時close掉這4個端口。
以上，服務器創建rtp端口的同時，還要創建rtcp端口。
上面的流程是服務器直接在兩點間中轉，不包括經過多服務器間流轉。
如果要做到兩客戶端之間直接點對點，AB雙方的音視頻端口，應該先連stun，取到自己的外網IP和端口后，再發INVITE,這時SDP中帶的是自己的外網IP和端口，雙方直接傳很大可能是收的到的。
大致流程應該是這樣的，可能還有些出入，畢竟是看代碼得出的結論，不是看RFC協議。
只能說發明SIP和RTP的人，大腦復雜度遠超普通人。當初以為HTTP已經夠麻煩的了，不過人家也不過只用了一個端口就可以傳所有數據。rtp的創始人應該是電信背景，可能認為每個端口號相當於電信中的每一路通話了。