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

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

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

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

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

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

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

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

　　后續(xù)還將繼續(xù)介紹關(guān)于SDP的媒體管理（修改會(huì)話描述參數(shù)），指示能力的討論和一個(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