​前面的章節筆者重點討論了offer初始化流程的處理，包括基本的SDP協商模式的背景知識，針對發起方對offer消息中單播和多播環境處理。從本章節開始，我們繼續介紹SDP協商中的接收方或者應答方的單播和多播媒體的應答處理（answer消息）。除了針對移動方生成answer的討論以外，本章節還將繼續介紹關於SDP的媒體管理，指示能力的討論和一個交互模式的示例。

構建offer消息的answer消息

發起方提供了一個offer消息給應答方，同樣，應答方answerer也會根據offer的消息回覆一個answer信息。在answer的討論中，筆者首先需要提醒讀者需要注意幾個媒體描述的設置（"o="，"m="行數和“t=”行），並且"m="中包含接受的媒體格式和不接受的媒體格式指示。通常來說，已提供的offer消息和它的answer是相互對應的，否則雙方的交互沒有辦法完成。它們之間的綁定關係是通過"o="行來關聯在一起。具體來講，如果answer消息中的"o="行版本號和offer消息中的"o="行版本號不一致的話，那麼，說明這answer消息是由不同的實體生成。另外，在offer中的每個"m="行必須對應相應的answer中的"m="行，answer中的"m="行必須包含和offer消息中完全一樣的"m="行數。簡單來說，offer中包含2行"m="行，answer必須也同樣包含2行"m="行。當然，如果在offer消息中包含零行"m="行的話，answer中也是包含零行"m="行。一些情況下，這樣規定的目的是為了保證媒體流格式按照一定的順序來匹配。最後，會話時間是不能協商的，因此，在answer中的"t="行設置必須等於offer中的"t="設置。offer消息中提供的流可以因為各種原因被answer消息拒絕。進一步說明，如果offer的流媒體被拒絕的話，發起方和應答方雙方一定不能生成針對此流媒體生成媒體流數據（或者RTCP報表數據）。對已拒絕的offer的媒體流，answer消息中相應的"m=0"行表示。任何的媒體格式列表要被忽略，至少保留一個媒體格式以支持指定的SDP。針對單播和多播流媒體來說，offer的流媒體的answer消息生成也有各自的流程。另外提醒讀者，很多網關設備支持的默認媒體媒體格式的列表有自己的設置限制，有的網關可能至少支持一個媒體格式，最大支持4個媒體格式列表。有點的可能更多，如果列表支持的最大數百年滿足協商的列表的話，可能出現編碼匹配或者協商機制的不兼容性。下面，我們針對answer消息的單播媒體流和多播媒體流的構建進行討論。

在生成應答的消息環境中，單播媒體流需要注意一些設置，特別是指向特徵屬性

注意，規範中的定義相對比較嚴格，為了保證能夠完整準確的解釋其官方的內容，筆者也只能遵從其用法。這裡的流媒體是一個總稱，媒體流是指具體的音視頻，數據等具體媒體格式。現在，我們說明在answer消息中關於指向屬性的設置。這裡有很多“如果”，讀者一定要注意。如果發送的或者提供的流媒體使用的是一個單播地址，此媒體其應答的地址或answered的地址必須包含一個單播地址。如果提供的流媒體標記為sendonly狀態，在answer消息中其相應的流媒體必須標記為recvonly 或者 inactive狀態。如果在offer消息中，媒體流列為recvonly狀態，在answer消息中其媒體流必須標記為sendonly或者 inactive狀態。如果提供的媒體流標記為sendrecv（或如果在媒體級或會話級沒有指向屬性，這種情況下，媒體流默認的標記為sendrecv狀態），在answer消息中相應的媒體流可以標記為sendonly，recvonly，sendrecv，或inactive的狀態。如果提供的媒體流標記為inactive狀態，此媒體流在answer消息中必須標記為inactive狀態。指向屬性討論完以後，筆者再結合指向屬性介紹一些關於"m="行以及其他相關屬性設置。對於在answer消息中標記為

• 如果offer的消息是sendonly狀態，answer中構建的媒體格式列表好像answer中的recvonly狀態。
• 如果offer的消息中標記的媒體流是recvonly的狀態，answer中構建的媒體格式列表好像answer中的sendonly狀態。
• 如果offer的中的消息是sendrecv狀態，answer中構建的媒體格式列表好像answer中的sendrecv狀態。
• 如果offer的中的消息是inactive狀態，answer中構建的媒體格式列表好像這樣一種狀態，它們分別是，offer實際上是sendrecv狀態，answer實際上是sendrecv狀態。

在answer消息中的連接地址和端口表示一個應答方期望接收媒體的地址（RTP和RTCP的地址，RTCP端口是默認比RTP端口高一位數的端口，否則必須明確說明）。現在，筆者討論一下關於RTP的媒體格式使用以及其他參數設置。如果在offer消息中，一個特定的編碼格式支持了一種指定的payload類型碼的話，此指定的payload類型碼也應該使用在answer的payload類型中。雖然在answer中使用了同樣類型的payload類型號，answer也必須包含rtpmap屬性來定義payload類型的映射，使用此映射支持動態的payload類型，並且在answer消息中應該包含payload類型映射支持靜態的payload類型。在answer消息中，"m="行中的媒體格式列表應該按照偏好順序來排列，列表中的第一個媒體格式是實際推薦的媒體格式。在這種情況下，推薦的媒體格式表示對端offerer應該使用answer消息中推薦列表的最高排序的媒體格式。簡單來說，answerer通知offerer使用answer中的最高優先級編碼格式。雖然answerer應答方可以根據自己的推薦媒體格式在answer消息中列出一個媒體格式推薦順序列表，但是，除非有特別的原因，一般的推薦方式是，應答方應根據出現在offer中的列表的格式順序列出answer中的推薦列表。換句話說，如果出現在offer中的媒體流的語音編碼格式順序是8，22和48，answerer支持的語

商人擁有虛擬的象形圖

音編碼是8和48的話，根據一般的推薦方式，如果answerer沒有任何理由修改這個順序的話，在answer中的語音編碼的順序應該是8和48，而不是48和8的順序。這樣可以保持雙向編碼一致，降低了編碼協商的多餘處理步驟。answerer可以包括一個非零的ptime屬性來支持任何媒體格式，這表示應答方期望使用此打包時長來接收媒體。對於一個媒體流來說，針對每個方向的媒體流打包時長可以不同，不一定是一樣的。應答方也可以包括一個帶寬屬性支持任何媒體流，此帶寬表示answerer應答方希望發起方發送媒體時使用的帶寬。帶寬屬性可以為零，這表示無媒體發送，使用RTP的場景中，answerer同時也關閉了RTCP。針對一個某個由發起方的媒體流，如果answerer沒有對此媒體流提供任何媒體格式的話，answerer必須設置端口為零來拒絕此媒體。但是，如果answerer對所有的媒體沒有提供媒體格式的話，發起方提供的整個會話將會被answerer拒絕。

現在，我們繼續討論answerer發送answer後的處理流程。一旦answerer已經發送了answer消息，answerer必須準備好接收在answer消息中標識為recvonly

多播媒體流在answerer中關於answer和單播媒體流的處理有一定的差別，一些基礎的設置是相同的。我們這裡簡要介紹多播媒體流在answerer方的構建處理規範。

https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-14.html

閱讀更多 Asterisk 的文章

關鍵字: answerer 列表 發送