本備忘錄的狀態(tài)

本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建
議以得到改進(jìn)。請參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)”(STD1)來獲得本協(xié)議的標(biāo)準(zhǔn)化
程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。
版權(quán)聲明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
摘要
本文提出了會話初始化協(xié)議（Sip）的一個擴展的建議。這一擴展為SIP增加了INFO
方法。
INFO方法的目的是答應(yīng)運送會議相關(guān)的控制信息，這些控制信息是在會議中生成的。這種
會議控制信息的一個例子是用于控制電話業(yè)務(wù)的ISUP和ISDN信令消息。
其他的關(guān)于INFO方法的例子在將來將被標(biāo)準(zhǔn)化。

目錄

1簡介...............................................2
1.1用法舉例................................................2
2INFO方法................................................3
2.1INFO方法的頭域支持....................................3
2.2INFO請求方法的響應(yīng)....................................4
2.3消息體的內(nèi)容......................................5
2.4SIP用戶代理的行為.................................6
2.5SIP代理和重定向服務(wù)器的的行為...................6
2.5.1代理服務(wù)器................................................6
2.5.2分支代理服務(wù)器........................................6
2.5.3重定向服務(wù)器.........................................6
3.INFO消息體.........................................6
4.利用INFO擴展的指導(dǎo)方針................7
5.安全性考慮.....................................7
6.參考資料..................................................8

7.致謝.............................................8
8.作者聯(lián)系方法...........................................8
版權(quán)說明....................................9

1.簡介

[1]中描述的SIP協(xié)議定義了用在SIP控制的會議的建立和拆除階段的會議控制信息。

另外，SIP重新INVITE（re-INVITE）能夠用于在一個會一種改變會議的特性。這通
常是與會議相關(guān)的媒體流量的屬性或者更新SIP會議地計時器。
然而，沒有通用的目標(biāo)機制來在會話過程中沿著SIP信令通路承載會話控制信息。

INFO消息的目的是沿著SIP信令通路攜帶應(yīng)用層消息。
INFO方法并不是用來改變SIP呼叫的狀態(tài)，或會議SIP的初始化狀態(tài)參數(shù)。它僅是用
于發(fā)送通常與會議有關(guān)的應(yīng)用層的可選信息。

會議中的信號信息穿過會議后的SIP信令通路建立是必要的。這個通路是SIP的
re-INVITEs,BYEs和其它與一個獨立會話聯(lián)系的SIP請求所采用的。他答應(yīng)SIP代理服務(wù)
器接收并潛在地對會議中的信號信息起作用。

此文檔通過定義新的INFO方法提供了SIP的一個擴展。INFO方法將被用于沿著會議信
號通路傳送呼叫中信號信息。

1.1用法舉例

以下是一些INFO消息地可能應(yīng)用:

-在PSTN網(wǎng)關(guān)之間傳送呼叫中PSTN信令消息

-傳送SIP會議中生成的DTMF數(shù)字。

-傳送無線信號強度信息以支持無線移動應(yīng)用。

-傳送計算平衡信息.

- 在會議的參加者之間傳送影像或其它的非流信息

這些只是可能的應(yīng)用；本文檔并不指定這些應(yīng)用，也不一定必須介紹它們。

也可以想象還有INFO方法的其它電話和非電話的應(yīng)用。


2.INFO方法

INFO方法被用于沿著呼叫的信令通路進(jìn)行會議中信令消息間的通訊。

INFO方法并不是用于改變SIP呼叫的狀態(tài)，也不是用于改變被SIP初始化地會議狀態(tài)。
然而，它提供增加的選項信息可以進(jìn)一步加強用SIP的應(yīng)用程序功能。


INFO方法的信令通路是呼叫建立之后建立的信令通路。這可以是呼叫方和被呼叫方用戶
代理之間的直接信令，也可以包括是牽涉到呼叫建立和自己增加到初始INVITE信息記錄路
由頭部的SIP代理服務(wù)器的信令通路。

會議中信息能夠在INFO信息頭部或作為一個消息體的一部分來進(jìn)行通訊。消息體和/或
消息頭部的定義被用來傳送會議中信息在本文檔討論范圍之外。

沒有與INFO相關(guān)的非凡語法語義。語義是從定義給INFO用的頭部或協(xié)議體那里繼續(xù)來
的。

2.1INFO方法的頭域支持

表1和表2給【1】中的表3和表4增加了一列。請參考【1】中的第6節(jié)對表中內(nèi)容
的描述。請注重在附錄里定義的規(guī)則和【1】中表3和表4的e－e列同樣應(yīng)用了在INFO
請求和回應(yīng)INFO請求中的頭部的應(yīng)用。

2.2INFO請求方法的響應(yīng)

假如服務(wù)器收到一個INFO請求，他必須發(fā)出一個最后的回應(yīng)。

假如INFO請求被現(xiàn)有的呼叫成功的接收到，UAS必須發(fā)送一個200OK沒有消息體的
回應(yīng)給一個INFO請求。在此之外，不需要其他的操作。

頭部Header地方Where信息INFO
---------------
接收AcceptRo
接收－編碼Accept-EncodingRo
接收－語言Accept-LanguageRo
答應(yīng)Allow200-
答應(yīng)Allow405o
認(rèn)可AuthorizationRo
呼叫號Call-IDgcm
連接ContactRo
連接Contact1xx-
連接Contact2xx-
連接Contact3xx-
連接Contact485-
連接－編碼Content-Encodingeo
內(nèi)容－長度Content-Lengtheo
內(nèi)容－類型Content-Typee*
CSeqgcm
數(shù)據(jù)Datego
加密Encryptiongo
期滿EXPiresgo
Fromgcm
隱藏HideRo
最大－向前流Max-ForwardsRo
組織Organizationgo

表1頭域的概括,A-0

包括消息體的INFO消息是在本文檔的討論范圍之內(nèi)。本文檔消息體的定義將同樣需
要SIP中的那些消息體中的定義。

假如INFO請求與任何現(xiàn)存的呼叫l(wèi)eg不匹配，那么一個481呼叫Leg/Transaction
不存在消息必須在一個UAS中被發(fā)送。

假如一個服務(wù)器收到一個他能理解消息體的INFO請求，但是它又對與INFO過程有關(guān)
的消息體規(guī)則沒有一點了解，那么這個消息體可能被翻譯并顯示給用戶。這個INFO被一個
200OK說回應(yīng)了。

假如INFO請求包括一個服務(wù)器那時不能理解的消息體，在INFO相關(guān)的消息體的進(jìn)
程規(guī)則缺乏時，服務(wù)器必須回應(yīng)一個415不支持的媒體類型消息。

頭部地方INFO信息
---------------
優(yōu)先權(quán)Ro
PRoxy驗證407o
Proxy驗證Ro
Proxy-需求Ro
請求Ro
重試-之后R-
重試-之后404,480,486o
重試-之后503o
重試-之后600,603o
回應(yīng)-要害字Ro
記錄-路由Ro
記錄-路由2xxo
路由Ro
服務(wù)器ro
主體Ro
時間戳go
To到gc(1)m
不支持的420o
用戶代理go
Viagc(2)m
告警ro
WWW-驗證401o

表2頭域的概括P-Z

那些在SIP呼叫狀態(tài)中或被SIP初始化后的會議中完成一個改變的消息體不能被放在
一個INFO消息中發(fā)送。

其它請求失敗(4xx),服務(wù)器失敗(5xx)和全局失敗(6xx)回應(yīng)將被送給INFO請求。

2.3消息體的內(nèi)容

INFO請求將包含一個消息體。.

2.4SIP用戶代理的行為

除非被申明，INFO請求的協(xié)議規(guī)則控制了標(biāo)記（tags）的用法。路由和記錄－路由
重傳和可靠性，CSeq自增和消息格式遵從【1】中定義給BYE請求。

一個INFO請求將被取消。假如，一個最終的回應(yīng)沒有被送給INFO并且行為如同該請
求從未被接收，那么，一個UAS接收一個給INFO請求的取消（CANCEL）將用一個“487
請求已取消”回應(yīng)給INFO。
然而，INFO消息決不許改變SIP呼叫的狀態(tài)，或SIP初始化的會議。

2.5SIP代理和重定向服務(wù)器的的行

2.5.1代理服務(wù)器

除非被申明,在一個服務(wù)器上的INFO的協(xié)議規(guī)定與那些在【1】中說明的BYE請求
的協(xié)議規(guī)定相一致。

2.5.2分支代理服務(wù)器

除非被申明,在一個服務(wù)器上的INFO的協(xié)議規(guī)定與那些在【1】中說明的BYE請求
的協(xié)議規(guī)定相一致。

2.5.3重定向服務(wù)器

除非被申明,在一個服務(wù)器上的INFO的協(xié)議規(guī)定與那些在【1】中說明的BYE請求
的協(xié)議規(guī)定相一致。

3.INFO消息體

INFO消息的目的是在SIP用戶代理間傳送會議中的信息。這一信息盡管能夠在INFO信
息頭中傳送，它一般地將被放在消息體中傳送。

對于消息體的定義或其它任何為INFO方法產(chǎn)生的新頭部在本文檔討論范圍之外。期望能
夠產(chǎn)生以定義這些實體為目標(biāo)的獨立文檔。

另外，INFO方法并不定義確保按順序傳送的附加機制。當(dāng)CSeq頭部將在傳送新的
INFO消息消息時自增，這就不能被用來決定INFO信息的順序，這是由于一個事實，即在
用戶代理發(fā)送有re-INVITES或其它SIP消息時在INFO消息CSeq的計數(shù)中將會引起鴻溝。

4.利用INFO擴展的指導(dǎo)方針

以下是在定義利用INFO方法的SIP擴展時必須考慮的方面。

-被INFO消息傳送的消息體的大小必須要考慮。由于消息將可能在UDP上傳送并且可能
重組一個大的消息，消息體應(yīng)該保持較小。

-有一種可能是INFO消息能被一個SIP代理服務(wù)器創(chuàng)建。完成這一INFO消息中的信息
的創(chuàng)建過程需要被考慮。

-當(dāng)定義被INFO消息傳送的消息體時，多部分消息體的應(yīng)用將會很有用。

-用INFO消息的擴展不答應(yīng)依靠INFO消息做那些影響SIP 呼叫的狀態(tài)或相關(guān)會
議的狀態(tài)的事。

-本文檔定義的INFO擴展不依靠于請求或代理請求頭部的應(yīng)用。用INFO消息的擴展名
可能需要應(yīng)用這些機制。然而，假如有可能請求或代理請求的應(yīng)用最好能避免，以便在SIP
實體間可以互操作。

5.安全性考慮

假如，消息體的內(nèi)容是私有的，那么端到端的消息體的加密能夠阻止未授權(quán)的進(jìn)入去訪
問它的內(nèi)容。

沒有其它的安全方法說明給INFO方法.在SIP說明中所說明的安全需要同樣用于INFO
方法。


6.參考資料

[1]Handley,M.,Schulzrinne,H.,Schooler,E.andJ.Rosenberg,
"SIP:sessionInitiationProtocol",RFC2543,March1999.

7.致謝

作者需要感謝MatthewCannon對這一文檔作出的貢獻(xiàn)。另外，作者想感謝
MMUSIC和SIP工作組的成員,非凡是JonathanRosenberg,他評論和建議如何提高本
文檔的質(zhì)量。

8.作者聯(lián)系方法

SteveDonovan
dynamicsoft
5100TennysonParkway,Suite200
Plano,Texas75024

Email:sdonovan@dynamicsoft.com

9.版權(quán)說明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

本文檔和他的譯本將被拷貝和附給其他人，Thisdocumentandtranslationsofitmay
becopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

Acknowledgement

FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.