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

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

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

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

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

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

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

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

　　后續(xù)還將繼續(xù)介紹關(guān)于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