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

　　在生成應答的消息環(huán)境中，單播媒體流需要注意一些設置，特別是指向特征屬性。注意，規(guī)范中的定義相對比較嚴格，為了保證能夠完整準確的解釋其官方的內容，筆者也只能遵從其用法，盡量不使用口語化的用詞。這里的流媒體是一個總稱，媒體流是指具體的音視頻，數(shù)據(jù)等具體媒體格式�，F(xiàn)在，我們說明在answer消息中關于指向屬性的設置。讀者一定要注意，這里有很多“如果”。如果發(fā)送的或者提供的流媒體使用的是一個單播地址，此媒體其應答的地址或answered的地址必須包含一個單播地址。如果提供的流媒體標記為sendonly狀態(tài)，在answer消息中其相應的流媒體必須標記為recvonly 或者 inactive狀態(tài)。如果在offer消息中，媒體流列為recvonly狀態(tài)，在answer消息中其媒體流必須標記為sendonly或者 inactive狀態(tài)。如果提供的媒體流標記為sendrecv（或如果在媒體級或會話級沒有指向屬性，這種情況下，媒體流默認的標記為sendrecv狀態(tài)），在answer消息中相應的媒體流可以標記為sendonly，recvonly，sendrecv，或inactive的狀態(tài)。如果提供的媒體流標記為inactive狀態(tài)，此媒體流在answer消息中必須標記為inactive狀態(tài)。指向屬性討論完以后，筆者再結合指向屬性介紹一些關于"m="行以及其他相關屬性設置。對于在answer消息中標記為recvonly狀態(tài)的流媒體來說，其"m="行必須包含至少一個媒體格式，此媒體格式是應答方期望使用的媒體格式（在offer消息中包含的媒體格式列表中挑選），使用此媒體格式接收媒體。另外，此流媒體也可以指示另外其他的媒體格式，指示的媒體格式也不在offer消息中包含的媒體格式，應答方期望使用此媒體格式來接收媒體流。對于在anwer消息中標記為sendonly狀態(tài)的流媒體，其"m="行必須包含至少一種媒體格式（此媒體格式在offer消息列表中的），應答方（answerer）使用此媒體格式發(fā)送媒體流。對于在answer中標記為sendrecv的流媒體，在"m="行必須至少包含一個媒體格式，其媒體格式表示應答方期望使用其媒體格式來發(fā)送和接收媒體流（在offer消息中包含的媒體格式列表中挑選）。流媒體也可以指示一個其他的媒體格式（此格式不在offer消息中的媒體列表中），應答方期望使用此媒體格式發(fā)送或接收媒體流。當然，此時，因為此媒體格式不在offer消息的媒體列表格式中，應答方還不能使用此媒體格式發(fā)送媒體流。對于answer中的媒體流標識為inactive的狀態(tài)，實際使用場景比較復雜。對于在answer消息中標識為inactive的媒體流，其媒體格式的構建是基于offer消息中的媒體格式。具體來說：

　　在answer消息中的連接地址和端口表示一個應答方期望接收媒體的地址（RTP和RTCP的地址，RTCP端口是默認比RTP端口高一位數(shù)的端口，否則必須明確說明）�，F(xiàn)在，筆者討論一下關于RTP的媒體格式使用以及其他參數(shù)設置。如果在offer消息中，一個特定的編碼格式支持了一種指定的payload類型碼的話，此指定的payload類型碼也應該使用在answer的payload類型中。雖然在answer中使用了同樣類型的payload類型號，answer也必須包含rtpmap屬性來定義payload類型的映射，使用此映射支持動態(tài)的payload類型，并且在answer消息中應該包含payload類型映射支持靜態(tài)的payload類型。在answer消息中，"m="行中的媒體格式列表應該按照偏好順序來排列，列表中的第一個媒體格式是實際推薦的媒體格式。在這種情況下，推薦的媒體格式表示對端offerer應該使用answer消息中推薦列表的最高排序的媒體格式。簡單來說，answerer通知offerer使用answer中的最高優(yōu)先級編碼格式。雖然answerer應答方可以根據(jù)自己的推薦媒體格式在answer消息中列出一個媒體格式推薦順序列表，但是，除非有特別的原因，一般的推薦方式是，應答方應根據(jù)出現(xiàn)在offer中的列表的格式順序列出answer中的推薦列表。換句話說，如果出現(xiàn)在offer中的媒體流的語音編碼格式順序是8，22和48，answerer支持的語音編碼是8和48的話，根據(jù)一般的推薦方式，如果answerer沒有任何理由修改這個順序的話，在answer中的語音編碼的順序應該是8和48，而不是48和8的順序。這樣可以保持雙向編碼一致，降低了編碼協(xié)商的多余處理步驟。answerer可以包括一個非零的ptime屬性來支持任何媒體格式，這表示應答方期望使用此打包時長來接收媒體。對于一個媒體流來說，針對每個方向的媒體流打包時長可以不同，不一定是一樣的。應答方也可以包括一個帶寬屬性支持任何媒體流，此帶寬表示answerer應答方希望發(fā)起方發(fā)送媒體時使用的帶寬。帶寬屬性可以為零，這表示無媒體發(fā)送，使用RTP的場景中，answerer同時也關閉了RTCP。針對一個某個由發(fā)起方的媒體流，如果answerer沒有對此媒體流提供任何媒體格式的話，answerer必須設置端口為零來拒絕此媒體。但是，如果answerer對所有的媒體沒有提供媒體格式的話，發(fā)起方提供的整個會話將會被answerer拒絕。

　　現(xiàn)在，我們繼續(xù)討論answerer發(fā)送answer后的處理流程。一旦answerer已經(jīng)發(fā)送了answer消息，answerer必須準備好接收在answer消息中標識為recvonly的媒體。answerer必須準備好發(fā)送和接收在answer消息中標識為sendrecv的媒體流，并且它也可能馬上發(fā)送媒體流。answerer必須準備好接收媒體流，此媒體流是在answer消息中發(fā)送的，并且標記為recvonly或者sendrecv的任何媒體流格式，并且answerer也可能馬上發(fā)送媒體流。當應答方answerer發(fā)送媒體流的時候，如果offer消息中出現(xiàn)了ptime打包時長的話，應答方應該使用和offer消息中設定的ptime相等的打包時長來處理發(fā)送的媒體流。當應答方answerer發(fā)送媒體流的時候，如果收到的offer消息中出現(xiàn)了帶寬設置的話，應答方應該使用不高于offer消息中設定的帶寬來處理發(fā)送媒體流。answerer必須使用offer消息中列出的媒體格式，同時也是在answer消息中列出的媒體格式發(fā)送媒體流，并且應該使用offer消息中推薦優(yōu)先級最高的編碼格式，同時也是在answer列表中的編碼格式。這里提醒讀者，通常，在生產環(huán)境中，我們可能使用所謂的使用本地推薦編碼或者遠端推薦編碼的方式來進行編碼協(xié)商處理設置，每個廠家所支持的設置方式不同，讀者可以查閱一些廠家語音產品的設置。筆者在后續(xù)章節(jié)的延伸討論中會做進一步的介紹。在RTP使用場景中，雖然有時answer消息中的payload類型號和offer的payload類型號有所區(qū)別，answerer必須使用offer消息中的payload類型號。以上是關于單播媒體流在answerer中的answer消息構建的核心討論。接下來，筆者繼續(xù)討論多播媒體流在answerer中關于answer消息構建的規(guī)范。

　　多播媒體流在answerer中關于answer和單播媒體流的處理有一定的差別，一些基礎的設置是相同的。我們這里簡要介紹多播媒體流在answerer方的構建處理規(guī)范。和單播媒體流的offer/answer交互模式不同，從單播媒體流的角度可以看到雙向的媒體流流程，但是多播媒體流的交互模式下，我們僅能看到一個媒體流。如果嚴格地講，對一個多個offer流媒體生成一個answer消息通常會涉及到修改流媒體的一些限定選項參數(shù)。如果接受了一個多媒體流的話，在answer消息中的地址和端口消息必須匹配offer消息中的地址和端口信息。同樣，在answer中的指向消息（sendonly，recvonly，或者sendrecv）必須和offer消息中的指向消息相同。因為，RFC 2327針對多參與方的一種前提假設，在一個多會話中，所有的參與方需要會話參數(shù)的等同理解。在answer消息中，一個媒體格式集必須等于offer中的媒體集或媒體集的子集。answerer應答方通過移除一個媒體格式來對offerer發(fā)起方表示應答方不支持此媒體格式。如果在answer中出現(xiàn)了ptime的話，在answer中的ptime和bandwidth帶寬必須等于offer消息中的ptime和bandwidth帶寬。如果在answer中沒有出現(xiàn)ptime，在answer中可以增加一個非零的ptime值。

　　前面，我們討論了answerer應答方如何生成answer消息�，F(xiàn)在，筆者討論發(fā)起方是如何接收answer消息的。當發(fā)起方收到answer的消息以后，offerer發(fā)起方可以通過流數(shù)據(jù)來發(fā)送媒體內容（假設在answer消息中標識的指向是sendrecv 或者recvonly）。這時，作為offerer發(fā)起方，它發(fā)送媒體流時必須使用answer中的媒體格式列表中的媒體格式，并且應該使用answer媒體格式列表中的第一個媒體格式。讀者注意，這里筆者強調的是應該使用，而不是必須使用，因為在answerer端規(guī)定的也是“應該使用”，不是必須使用，通常情況下，雙方的編碼常常需要及時修改保證協(xié)商的及時性。例如，在雙方通話的無聲時段，一個終端可能想切換到一個舒適噪音的編碼（參考RFC3389），另外，有時終端可能通過終端面板摁DTMF按鍵發(fā)送DTMF按鍵音。除了一些必要的應用場景需要推薦“應該使用”，很多時候，擁塞控制也根據(jù)對端的響應強迫用戶不得不使用相對低速率的編碼。在擁塞控制的草案中涉及了一個控制模型，讀者有興趣的話可以進一步學習：

　　資源來源：https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-02

　　offerer應該基于answer消息中的ptime和bandwidth帶寬發(fā)送媒體。有一種媒體格式發(fā)起方可能會馬上終止監(jiān)聽。具體來說，offerer可以馬上終止偵聽媒體格式，這種媒體格式是在初始化offer中列出的，但是沒有出現(xiàn)在收到的answer消息中的媒體格式。

　　后續(xù)還將繼續(xù)介紹關于SDP的媒體管理（修改會話描述參數(shù)），指示能力的討論和一個交互模式的示例。

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

　　https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-00