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

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

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

　　現在，我們繼續討論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ā)送媒體流的時(shí)候，如果offer消息中出現了ptime打包時(shí)長(cháng)的話(huà)，應答方應該使用和offer消息中設定的ptime相等的打包時(shí)長(cháng)來(lái)處理發(fā)送的媒體流。當應答方answerer發(fā)送媒體流的時(shí)候，如果收到的offer消息中出現了帶寬設置的話(huà)，應答方應該使用不高于offer消息中設定的帶寬來(lái)處理發(fā)送媒體流。answerer必須使用offer消息中列出的媒體格式，同時(shí)也是在answer消息中列出的媒體格式發(fā)送媒體流，并且應該使用offer消息中推薦優(yōu)先級最高的編碼格式，同時(shí)也是在answer列表中的編碼格式。這里提醒讀者，通常，在生產(chǎn)環(huán)境中，我們可能使用所謂的使用本地推薦編碼或者遠端推薦編碼的方式來(lái)進(jìn)行編碼協(xié)商處理設置，每個(gè)廠(chǎng)家所支持的設置方式不同，讀者可以查閱一些廠(chǎng)家語(yǔ)音產(chǎn)品的設置。筆者在后續章節的延伸討論中會(huì )做進(jìn)一步的介紹。在RTP使用場(chǎng)景中，雖然有時(shí)answer消息中的payload類(lèi)型號和offer的payload類(lèi)型號有所區別，answerer必須使用offer消息中的payload類(lèi)型號。以上是關(guān)于單播媒體流在answerer中的answer消息構建的核心討論。接下來(lái)，筆者繼續討論多播媒體流在answerer中關(guān)于answer消息構建的規范。

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

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

　　資源來(lái)源：https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-02

　　offerer應該基于answer消息中的ptime和bandwidth帶寬發(fā)送媒體。有一種媒體格式發(fā)起方可能會(huì )馬上終止監聽(tīng)。具體來(lái)說(shuō)，offerer可以馬上終止偵聽(tīng)媒體格式，這種媒體格式是在初始化offer中列出的，但是沒(méi)有出現在收到的answer消息中的媒體格式。

　　后續還將繼續介紹關(guān)于SDP的媒體管理（修改會(huì )話(huà)描述參數），指示能力的討論和一個(gè)交互模式的示例。

　　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