專利名稱：一種媒體處理方法及相關設備的制作方法
技術領域：
本發(fā)明涉及通信領域，尤其涉及一種媒體處理方法及相關設備。
背景技術：
互聯(lián)網(wǎng)協(xié)議多媒體子系統(tǒng)(IMS，IP Multimedia Subsystem)是基于互聯(lián)網(wǎng)協(xié)議 (IP, Internet Protocol)的多媒體流業(yè)務通信網(wǎng)絡，它被認為是支持語音、視頻、數(shù)據(jù)等多種媒體流及其組合業(yè)務，實現(xiàn)多種網(wǎng)絡(例如移動與固定網(wǎng)絡，PS與CS網(wǎng)絡等)融合的下一代通信網(wǎng)絡的核心技術。在IMS網(wǎng)絡中，當本端用戶與對端用戶在進行通話時，本端用戶可以選擇不同的媒體流在不同的用戶設備(UE，User Equipment)上傳輸，例如語音媒體流在固定電話上傳輸，數(shù)據(jù)媒體流在電腦上傳輸；并且，本端用戶可以有多個UE同時對這些媒體流進行控制。本端用戶的每個UE與業(yè)務集中和會話連續(xù)性應用服務器(SCC AS, Service Centralization&Continuity Application Server)有一個會話，多個終端與 SCC AS 間的多個會話合在一起成為一個聯(lián)合會話。具有聯(lián)合會話的控制權的UE稱為控制端UE(C0ntr0ller UE)，控制端UE可以對聯(lián)合會話中的所有媒體流進行控制，這里的控制包括對聯(lián)合會話內的任何媒體流進行轉移， 刪除，增加，進行補充業(yè)務操作等。在現(xiàn)有技術中，當聯(lián)合會話內同時存在多個控制端UE時，各控制端UE在聯(lián)合會話內的地位是相同的，都可以控制聯(lián)合會話內的任何媒體。并且按照先到先處理的原則進行操作。現(xiàn)有技術中一種媒體處理方法具體如下假設UEl和UE2均為聯(lián)合會話中的控制端UE，當對端用戶通過re-Invite消息發(fā)起媒體增加的請求時，SCC AS通過re-Invite消息同時向UEl以及UE2發(fā)起媒體增加請求；如果UEl對該媒體增加的請求的處理消息先于UE2的處理消息到達SCCAS，例如， UEl發(fā)出將媒體轉移(transfer)到UE2的請求；由于UEl的處理消息先到達SCC ASJU SCC AS向UE2發(fā)出取消請求，可以為SCC AS向UE2發(fā)送Cancel消息。如果UE2已通過refer發(fā)出將媒體轉移給其他UE的請求，則 SCC AS需要通過4xx消息拒絕該refer消息。如果UE2已發(fā)出2000K確認消息，則SCC AS 首先向UE2回復ACK消息，再向UE2發(fā)送刪除媒體的請求消息。當SCC AS向UE2發(fā)出取消請求之后，SCC AS再次向UE2發(fā)送媒體增加請求，以請求UE2增加媒體，UE2則根據(jù)該媒體增加請求執(zhí)行后續(xù)操作。在上述現(xiàn)有技術的過程中，若UEl的處理消息首先到達SCC AS，且UEl請求將媒體轉移至UE2，則UE2至少會收到一個取消請求以及兩個內容完全相同的媒體增加請求，這樣會增加網(wǎng)絡數(shù)據(jù)傳輸?shù)呢摀?，影響系統(tǒng)性能；其次，對于UE2來說，UE2在第一次接收到SCC AS發(fā)送的媒體增加請求之后可能就已經(jīng)進行了處理操作，例如接受該媒體增加請求或拒絕該媒體增加，但是由于UE2的處理消息后到達SCC AS，因此UE2的本次操作會被認為無效，并且還需要再次進行一遍相同的處理，即對相同的操作處理兩次，增加了操作時長，從而影響了用戶體驗。

發(fā)明內容
本發(fā)明實施例提供了一種媒體處理方法及相關設備，能夠提高系統(tǒng)性能并提高用戶體驗。本發(fā)明實施例提供的媒體處理方法，包括接收第一媒體處理請求；向各控制端用戶設備UE發(fā)送所述第一媒體處理請求，所述各控制端UE至少包括第一控制端UE以及第二控制端UE ；接收第一控制端UE針對所述第一媒體處理請求反饋的第二媒體處理請求，所述第二媒體處理請求指示媒體在第二控制端UE中進行傳輸；若接收第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，當所述第二控制端UE同意在自身傳輸所述媒體時，向所述第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，當所述第二控制端UE 不同意在自身傳輸所述媒體時，向所述第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。本發(fā)明實施例提供的應用服務器，包括請求接收單元，用于接收第一媒體處理請求；請求發(fā)送單元，用于向各控制端用戶設備UE發(fā)送所述第一媒體處理請求，所述各控制端UE至少包括第一控制端UE以及第二控制端UE ；應答接收單元，用于接收第一控制端UE 針對所述第一媒體處理請求反饋的第二媒體處理請求，所述第二媒體處理請求指示媒體在第二控制端UE中進行傳輸；通知單元，用于在應答接收單元接收第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求時，若所述第二控制端UE同意在自身傳輸所述媒體， 則向所述第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若所述第二控制端UE不同意在自身傳輸所述媒體，則向所述第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。從以上技術方案可以看出，本發(fā)明實施例具有以下優(yōu)點本實施例中，AS向各控制端UE發(fā)送第一媒體處理請求之后，若第一控制端UE的針對第一媒體處理請求反饋的第二媒體處理請求先到達AS，且要求媒體在第二控制端UE進行傳輸時，則AS會等待第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，并判斷第二控制端UE是否接受該媒體在其自身傳輸，若第二控制端UE接受了媒體在其自身傳輸，則AS會直接向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若第二控制端 UE不接受在其自身傳輸，則AS直接向第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗，因此，AS無需向第二控制端UE重復發(fā)送相同內容的媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于AS不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長， 增加了用戶體驗。


圖1為本發(fā)明實施例中媒體處理方法一個實施例示意圖；圖2為本發(fā)明實施例中媒體處理方法另一實施例示意圖3為本發(fā)明實施例中媒體處理方法另一實施例示意圖；圖4為本發(fā)明實施例中媒體處理方法另一實施例示意圖；圖5為本發(fā)明實施例中媒體處理方法另一實施例示意圖；圖6為本發(fā)明實施例中應用服務器一個實施例示意圖；圖7為本發(fā)明實施例中應用服務器另一實施例示意圖；圖8為本發(fā)明實施例中控制端用戶設備一個實施例示意圖；圖9為本發(fā)明實施例中媒體處理系統(tǒng)實施例示意圖。
具體實施例方式本發(fā)明實施例提供了一種媒體處理方法及媒體處理系統(tǒng)以及相關設備，能夠提高系統(tǒng)性能并提高用戶體驗。請參閱圖1，本發(fā)明實施例中媒體處理方法一個實施例包括101、接收第一媒體處理請求；本實施例中，AS可以從對端用戶接收第一媒體處理請求，例如對端用戶請求增加媒體的請求；或從本端受控端用戶設備(Controllee UE)接收第一媒體處理請求，例如本端受控端用戶設備請求刪除自身媒體的請求，該第一媒體處理請求中包含有對應的媒體。需要說明的是，本實施例中的AS在實際應用中可以為SCC AS，也可以為其他類型的AS，具體類型此處不作限定。102、向各控制端用戶設備UE發(fā)送第一媒體處理請求；AS在接收到第一媒體處理請求之后，會向與對端用戶正在進行會話的本端用戶的各控制端UE發(fā)送媒體第一處理請求。本端用戶的控制端UE至少包括第一控制端UE以及第二控制端UE，還可以進一步包括更多的控制端UE。103、接收第一控制端UE針對第一媒體處理請求反饋的第二媒體處理請求；各控制端UE在接收到媒體處理請求之后，會向AS反饋媒體處理請求，由于傳輸路徑和網(wǎng)絡狀況的不同，各控制端UE反饋的媒體處理請求可能會先后到達AS。本實施例中，假設AS會最先收到第一控制端UE反饋的第二媒體處理請求，例如， 將該媒體轉移到第二控制端UE中傳輸。如果2個以上控制端UE發(fā)出的媒體處理請求同時到達ASJU AS可以根據(jù)用戶的偏好和運營商策略僅選擇一個控制端UE的處理請求進行處理。104、判斷是否接收到第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，若是，則執(zhí)行步驟105，若否，則執(zhí)行步驟107 ；本實施例中，AS在接收到第一控制端UE反饋的第二媒體處理請求之后，等待第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求。105、判斷第二控制端UE是否同意在自身傳輸媒體，若同意，則執(zhí)行步驟106，若不同意，則執(zhí)行步驟107;當收到第二控制端UE的第三媒體處理請求后，可以根據(jù)第三媒體處理請求判斷第二控制端UE是否同意在自身傳輸媒體，例如，當?shù)诙刂贫薝E接受了媒體在其自身傳輸，則認為同意，當?shù)诙刂贫薝E拒絕媒體在其自身傳輸或將發(fā)起媒體轉移到其他UE的請求時，則認為不同意。106、向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功；若第二控制端UE的第三媒體處理請求是同意在自身傳輸媒體，則AS可以向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，不再進行后續(xù)的媒體轉移處理過程，之后第一控制端UE向AS返回確認消息，AS再向對端用戶發(fā)送確認消息，則媒體處理過程完成。如果存在第一、第二控制端UE外的其他控制端UE, AS在收到第二媒體處理請求后，需要向其他控制端UE發(fā)送取消消息。107、向第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。若第二控制端UE的第三媒體處理請求是不同意在自身傳輸該媒體，則AS向第一控制端UE發(fā)送第二通知消息以指示第一控制端UE第二媒體處理請求失敗。此時第一控制端UE可以選擇將媒體在自身傳輸、轉移到其他UE或拒絕該媒體等操作。需要說明的是，若在預置時間內未收到第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，則認為第二控制端UE不同意媒體在自身進行傳輸，則同樣執(zhí)行步驟 107。如果存在第一、第二控制端UE外的其他控制端UE，AS在收到第二媒體處理請求后，需要向其他控制端UE發(fā)送取消消息。如果AS未收到第三媒體處理請求，則AS也需要向第二控制端UE發(fā)送取消消息。本實施例中，AS向各控制端UE發(fā)送第一媒體處理請求之后，若第一控制端UE的針對第一媒體處理請求反饋的第二媒體處理請求先到達AS，且要求媒體在第二控制端UE進行傳輸時，則AS會等待第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，并判斷第二控制端UE是否接受該媒體在其自身傳輸，若第二控制端UE接受了媒體在其自身傳輸，則AS會直接向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若第二控制端 UE不接受在其自身傳輸，則AS直接向第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗，因此，AS無需向第二控制端UE重復發(fā)送相同內容的媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于AS不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長， 增加了用戶體驗。為便于理解，下面以兩個具體實例對本實施例中的媒體處理方法進行說明一、第二控制端UE同意在自身傳輸媒體具體請參閱圖2，本發(fā)明實施例中媒體處理方法另一實施例包括201、第一控制端UE與對端用戶傳輸媒體A ；202、第二控制端UE與對端用戶傳輸媒體B ；203 204、第一控制端UE向第二控制端UE共享控制權；205、對端用戶通過re-Invite消息向SCC ASl發(fā)送第一媒體處理請求；本實施例中，以媒體增加請求作為媒體處理請求的例子進行說明，在實際應用中， 該媒體處理請求還可以是其他的請求，例如媒體修改請求等，具體此處不作限定。206、SCC ASl采用re-hvite消息向第一控制端UE發(fā)送第一媒體處理請求；
207 208、SCC ASl通過SCC AS2采用rednvite消息向第二控制端UE發(fā)送第一媒體處理請求；需要說明的是，本實施例中，步驟206與207為同時執(zhí)行的步驟，沒有先后順序。209、SCC ASl接收第一控制端UE的第二媒體處理請求；本實施例中，假設第一控制端UE針對該第一媒體處理請求的第二媒體處理請求消息比第二控制端UE的第三媒體處理請求消息先到達SCC AS1。第一控制端UE的第二媒體處理請求消息可以指示媒體在第二控制端UE中進行傳輸。210、SCC ASl等待第二控制端UE的第三媒體處理請求消息；SCC ASl在接收到第一控制端UE發(fā)送的第二媒體處理請求消息之后，獲知第一控制端UE指示第二控制端UE傳輸媒體，則SCC ASl等待第二控制端UE的第三媒體處理請求消息。211 212、第二控制端UE通過SCC AS2向SCC ASl發(fā)送2000K消息；當?shù)诙刂贫薝E在步驟208中接收到SCC ASl發(fā)送的第一媒體處理請求之后，若第二控制端UE確定由自身來傳輸該媒體，則會通過SCC AS2向SCC ASl發(fā)送2000K消息。213、SCC ASl向第一控制端UE發(fā)送第一通知消息；當SCC ASl接收到第二控制端UE反饋的第三媒體處理請求消息為2000K消息時， 則確定第二控制端UE同意自身傳輸媒體，而第一控制端UE發(fā)送的應答消息正是要求第二控制端UE傳輸媒體，則SCC ASl直接向第一控制端UE發(fā)送第一通知消息，以告知操作成功， 不需要再進行后續(xù)的媒體轉移處理過程。214 215、第一控制端UE通過SCC ASl向對端用戶發(fā)送2000K消息。需要說明的是，若本端用戶有三個或以上的控制端UE，即除了第一控制端UE以及第二控制端UE之外，還有其他的控制端UE，則SCC ASl還會在步驟206或207的同時向其他的控制端UE發(fā)送第一媒體處理請求，并且SCCASl在步驟209之后會向除第一控制端UE 以及第二控制端UE之外的其他控制端UE發(fā)送取消消息以取消發(fā)送至這些控制端UE的媒體處理請求。本實施例中描述的SCC ASl與SCC AS2在實際應用中可以為同一個物理實體，則 SCC ASl與SCC AS2之間的交互為網(wǎng)元內部交互，可以理解的是，SCC ASl與SCC AS2也可以為不同的物理實體，則SCC ASl與SCC AS2之間的交互為網(wǎng)元間交互。本實施例中，步驟209時，SCC ASl會先接收到第一控制端UE反饋的第二媒體處理請求消息，在實際應用中，SCC ASl若同時接收到兩個控制端UE反饋的媒體處理請求消息，則SCC ASl可以根據(jù)用戶的偏好或運營商策略選擇其中的一個媒體處理請求消息作為最先收到的媒體處理請求消息，則后續(xù)處理與上述處理過程相同。二、第二控制端UE不同意在自身傳輸媒體具體請參閱圖3，本發(fā)明實施例中媒體處理方法另一實施例包括301 310、與前述圖2所示實施例中的步驟201至210相同，此處不再贅述；311 312、第二控制端UE通過SCC AS2向SCC ASl發(fā)送第三媒體處理請求；當?shù)诙刂贫薝E在步驟308中接收到SCC ASl發(fā)送的第一媒體處理請求之后，可以通過SCC AS2向SCC ASl發(fā)送第三媒體處理請求。
這里的第三媒體處理請求可以是媒體轉移消息或拒絕傳輸消息(例如4xx消息)。 若第二控制端UE發(fā)送的第三媒體處理請求是媒體轉移請求，則SCCASl還需要進一步向第二控制端UE發(fā)送拒絕消息，該拒絕消息的call-info消息頭中指明拒絕的原因，例如可以為“禁止轉移”等。需要說明的是，在實際應用中，第二控制端UE也可能不反饋任何應答消息，即不執(zhí)行步驟311 312，則在這種情況下，SCC ASl向第二控制端UE發(fā)送了第一媒體處理請求之后，即啟動定時器，當該定時器超過預置的時長仍未收到第二控制端UE反饋的應答消息時，則默認認為第二控制端UE不同意在自身傳輸媒體，則SCC ASl需要向第二控制端UE發(fā)送取消消息。313、SCC ASl向第一控制端UE發(fā)送第二通知消息；當SCC ASl確定第二控制端UE不同意在自身傳輸媒體時，則SCC ASl向第一控制端UE發(fā)送第二通知消息以指示第一控制端UE拒絕媒體處理請求。
314、第一控制端UE進行相應處理；第一控制端UE接收到SCC ASl發(fā)送的第二通知消息之后，則進行相應的處理，可以拒絕媒體處理請求，或安排其他控制端UE傳輸媒體，具體處理過程此處不作限定。315、SCC ASl向第二控制端UE提供當前聯(lián)合會話的狀態(tài)信息。本實施例中，SCC ASl具體可以通過通知(Notify)消息或re-Invite消息向第二控制端UE提供當前聯(lián)合會話的狀態(tài)，具體的消息體可以為< ？ xml version =" 1.0〃 ？ ><col laborat ive-sessionxmlns ="urn:ietf:params:xml:ns:collaborative-session" >〈media-description media_type = " Media-A"port = " 6787〃aor=〃 sip:UE-liexample. com"media_state =" sendrecv"/>〈media-description media_type = " Media-B"port = " 6788〃aor=〃 sip:UE-2iexample. com"media_state =" sendrecv"/></collaborative-session>該聯(lián)合會話的狀態(tài)用以表明當前傳輸?shù)拿襟w有哪些媒體類型，各媒體所在的UE，
所使用的端口，以及媒體狀態(tài)等信息。 需要說明的是，若本端用戶有三個或以上的控制端UE，即除了第一控制端UE以及第二控制端UE之外，還有其他的控制端UE，則SCC ASl還會在步驟306或307的同時向其他的控制端UE發(fā)送第一媒體處理請求，并且SCCASl在步驟309之后會向除第一控制端UE 以及第二控制端UE之外的其他控制端UE發(fā)送取消消息以取消發(fā)送至這些控制端UE的媒體處理請求。本實施例中描述的SCC ASl與SCC AS2在實際應用中可以為同一個物理實體，則 SCC ASl與SCC AS2之間的交互為網(wǎng)元內部交互，可以理解的是，SCC ASl與SCC AS2也可以為不同的物理實體，則SCC ASl與SCC AS2之間的交互為網(wǎng)元間交互。本實施例中，步驟309時，SCC ASl會先接收到第一控制端UE發(fā)送的第二媒體處理請求，在實際應用中，SCC ASl若同時接收到兩個控制端UE反饋的媒體處理請求，則SCC ASl可以根據(jù)用戶的偏好或運營商策略選擇其中的一個媒體處理請求作為最先收到的應答消息，則后續(xù)處理與上述處理過程相同。本實施例中，AS向各控制端UE發(fā)送第一媒體處理請求之后，若第一控制端UE的針對第一媒體處理請求反饋的第二媒體處理請求先到達AS，且要求媒體在第二控制端UE進行傳輸時，則AS會等待第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，并判斷第二控制端UE是否接受該媒體在其自身傳輸，若第二控制端UE接受了媒體處理在其自身傳輸，則AS會直接向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若第二控制端UE不接受在其自身傳輸，則AS直接發(fā)送向第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗，因此，AS無需向第二控制端UE重復發(fā)送相同內容的媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于AS不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長， 增加了用戶體驗。下面介紹本發(fā)明實施例中另一種媒體處理方法，請參閱圖4，本發(fā)明實施例中媒體處理方法另一實施例包括401、接收第一控制端UE發(fā)送的控制權共享請求；本實施例中，在執(zhí)行聯(lián)合會話的控制權共享過程中，AS會接收到第一控制端UE發(fā)送的控制權共享請求，該控制權共享請求指示將控制權共享給第二控制端UE,該控制權共享請求中包含第一控制端UE以及第二控制端UE的優(yōu)先級信息。402、當接收到媒體處理請求時，僅向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求。AS接收到第一控制端UE發(fā)送的控制權共享請求之后，會記錄第一控制端UE的優(yōu)先級以及第二控制端UE的優(yōu)先級。當從對端用戶接收到媒體處理請求時，AS僅會向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求。本實施例中，由于第一控制端UE發(fā)送的控制權共享請求中指示將控制權共享給第二控制端UE，該控制權共享請求中包含第一控制端UE以及第二控制端UE的優(yōu)先級信息， 因此AS在接收到媒體處理請求時，會按照該優(yōu)先級，僅向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求，由于只會有一個控制端UE接收到媒體處理請求，則可以避免多個控制端UE同時接收到媒體處理請求時所導致的操作沖突，因此可以避免第二控制端UE多次接收到媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于AS不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長， 增加了用戶體驗。
上面是從AS的角度進行描述，下面從第一控制端UE的角度進行描述，大致流程為(1)第一控制端UE確定需要共享控制權的第二控制端UE ；第一控制端UE可以根據(jù)本端用戶的指令將控制權共享給第二控制端UE,具體的確定過程此處不作限定。(2)第一控制端UE生成第一控制端UE以及第二控制端UE的優(yōu)先級；在確定了第二控制端UE之后，第一控制端UE即可生成優(yōu)先級。(3)第一控制端UE向應用服務器發(fā)送控制權共享請求。本實施例中，該控制權共享請求指示將控制權共享給第二控制端UE，該控制權共享請求中包含第一控制端UE以及第二控制端UE的優(yōu)先級信息，之后AS即可根據(jù)該優(yōu)先級發(fā)送媒體處理請求。為便于理解，下面以一具體實例進行說明，請參閱圖5，本發(fā)明實施例中媒體處理方法另一實施例包括501、第一控制端UE與對端用戶傳輸媒體A ；502、第二控制端UE與對端用戶傳輸媒體B ；503 504、第一控制端UE向第二控制端UE共享控制權；第一控制端UE發(fā)起將聯(lián)合會話控制權共享給第二控制端UE的請求，在請求中可以包括如下信息共享聯(lián)合會話控制權的指示；控制權共享的發(fā)起方為第一控制端UE的指示；控制權共享的目標方為第二控制端UE的指示；第一控制端UE和/或第二控制端UE在聯(lián)合會話中控制權的優(yōu)先級的指示；可以是第一控制端UE為主控制端(master)、第一控制端UE為輔控制端(slave)的指示，或第一控制端UE的優(yōu)先級為高，第一控制端UE的優(yōu)先級為低的指示。505、SCC ASl執(zhí)行校驗過程；SCC ASl在接收到第一控制端UE發(fā)送的控制權共享請求之后，會判斷第一控制端 UE是否可以將控制權共享給第二控制端UE，具體的校驗過程此處不作限定。506、SCC AS1建立聯(lián)合會話控制路徑；若SCC ASl確定第一控制端UE可以將控制端共享給第二控制端UE JlJSCC ASl通過SCC AS2與第二控制端UE建立會話控制路徑，即用于控制聯(lián)合會話的接入分支，并向第二控制端UE告知其優(yōu)先級。507、對端用戶通過re-Invite消息向SCC ASl發(fā)送媒體增加請求；本實施例中，以媒體增加請求作為媒體處理請求的例子進行說明，在實際應用中， 該媒體處理請求還可以是其他的請求，例如媒體修改請求等，具體此處不作限定。508、SCC ASl采用re-hvite消息向第一控制端UE發(fā)送媒體增加請求；當SCC ASl接收到媒體增加請求時，會根據(jù)優(yōu)先級確定第一控制端UE的優(yōu)先級高于第二控制端UE的優(yōu)先級，則向第一控制端UE發(fā)送媒體增加請求。需要說明的是，若第一控制端UE向多個控制端UE共享了控制權，則這些控制端UE 的優(yōu)先級也均低于第一控制端UE JlJSCC ASl會向優(yōu)先級最高的第一控制端UE發(fā)送媒體增力口請求。509、第一控制端UE執(zhí)行后續(xù)的處理過程。需要說明的是，若SCC ASl在步驟508之后的預置時長之內未能收到第一控制端 UE反饋的應答消息，則SCC ASl可以認為第一控制端UE失效，則此時SCC ASl可以按照優(yōu)先級順序向優(yōu)先級次高的控制端UE發(fā)送媒體增加請求，以此類推，每次只發(fā)送一個媒體增力口請求。本實施例中，由于第一控制端UE發(fā)送的控制權共享請求中指示將控制權共享給第二控制端UE，該控制權共享請求中包含第一控制端UE以及第二控制端UE的優(yōu)先級信息， 因此AS在接收到媒體處理請求時，會按照該優(yōu)先級，僅向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求，由于只會有一個控制端UE接收到媒體處理請求，則可以避免多個控制端UE同時接收到媒體處理請求時所導致的操作沖突，因此可以避免第二控制端UE多次接收到媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于AS不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長， 增加了用戶體驗。下面對本發(fā)明實施例中的應用服務器進行說明，請參閱圖6，本發(fā)明實施例中應用服務器一個實施例包括請求接收單元601，用于接收第一媒體處理請求；請求發(fā)送單元602，用于向各控制端用戶設備UE發(fā)送第一媒體處理請求，各控制端UE至少包括第一控制端UE以及第二控制端UE ；應答接收單元603，用于接收第一控制端UE針對第一媒體處理請求反饋的第二媒體處理請求，第二媒體處理請求指示媒體在第二控制端UE中進行傳輸；通知單元604，用于在應答接收單元接收第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求時，若第二控制端UE同意在自身傳輸媒體，則向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若第二控制端UE不同意在自身傳輸媒體，則向第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。需要說明的是，若本實施例中除了第一控制端UE以及第二控制端UE之外，還包括有其他的控制端UE，則本實施例中的應用服務器還可以進一步包括取消單元605，用于向除第一控制端UE以及第二控制端UE之外的其他控制端UE 發(fā)送取消消息以取消發(fā)送給其他控制端UE的媒體處理請求。本實施例中的應用服務器還可以進一步包括確定單元606，用于當?shù)谌襟w處理請求為2000K消息時確定第二控制端UE同意在自身傳輸媒體，當?shù)谌襟w處理請求為媒體轉移消息或拒絕傳輸消息時確定第二控制端UE不同意在自身傳輸媒體，當應答接收單元在預置的時長內未接收到第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求時確定第二控制端UE不同意在自身傳輸媒體。需要說明的是，本實施例中的確定單元606具體確定第二控制端UE是否同意在自身傳輸媒體的過程與前述圖2以及圖3所示的實施例中描述的過程類似，此處不再贅述。本實施例中，請求發(fā)送單元602向各控制端UE發(fā)送第一媒體處理請求之后，若第一控制端UE的針對第一媒體處理請求反饋的第二媒體處理請求先到達AS，且要求媒體在第二控制端UE進行傳輸時，則AS會等待第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，并判斷第二控制端UE是否接受該媒體在其自身傳輸，若第二控制端UE接受了媒體在其自身傳輸，則通知單元604會直接向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若第二控制端UE不接受在其自身傳輸，則通知單元604直接向第一控制端UE 發(fā)送第二通知消息以指示媒體處理失敗，因此，AS無需向第二控制端UE重復發(fā)送相同內容的媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于AS不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長， 增加了用戶體驗。請參閱圖7，本發(fā)明實施例中應用服務器另一實施例包括共享請求接收單元701，用于接收第一控制端UE發(fā)送的控制權共享請求，控制權共享請求指示將控制權共享給第二控制端UE，控制權共享請求包含第一控制端UE以及第二控制端UE的優(yōu)先級信息；處理請求接收單元702，用于接收媒體處理請求；第一發(fā)送單元703，用于僅向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求。本實施例中的應用服務器還可以進一步包括控制建立單元704，用于判斷是否允許將控制權共享給第二控制端UE，若允許，則為第二控制端UE建立用于控制聯(lián)合會話的接入分支，并向第二控制端UE告知其優(yōu)先級。本實施例中的應用服務器還可以進一步包括第二發(fā)送單元705，用于向下一優(yōu)先級較低的控制端UE發(fā)送媒體處理請求；控制單元706，用于判斷在預置時長內是否收到優(yōu)先級最高的控制端UE反饋的應答消息，若未收到，則觸發(fā)第二發(fā)送單元執(zhí)行相應操作。本實施例中，由于第一控制端UE發(fā)送的控制權共享請求中指示將控制權共享給第二控制端UE,控制權共享請求包含第一控制端UE以及第二控制端UE的優(yōu)先級信息，因此處理請求接收單元702在接收到媒體處理請求時，第一發(fā)送單元703會按照該優(yōu)先級，僅向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求，由于只會有一個控制端UE接收到媒體處理請求，則可以避免多個控制端UE同時接收到媒體處理請求時所導致的操作沖突，因此可以避免第二控制端UE多次接收到媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能；其次，由于第一發(fā)送單元703不會向第二控制端UE發(fā)送兩次相同內容的媒體處理請求，因此，第二控制端UE所執(zhí)行的操作為有效操作，不會重復執(zhí)行相同的處理，因此減少了操作時長，增加了用戶體驗。下面介紹本發(fā)明實施例中的控制端用戶設備實施例，請參閱圖8，本發(fā)明實施例中的控制端用戶設備包括控制權確定單元801，用于確定需要共享控制權的第二控制端UE ；生成單元802，用于生成自身以及第二控制端UE的優(yōu)先級；共享請求發(fā)送單元803，用于向應用服務器發(fā)送控制權共享請求，控制權共享請求指示將控制權共享給第二控制端UE，該控制權共享請求包含第一控制端UE以及第二控制端UE的優(yōu)先級信息。本實施例中，由于共享請求發(fā)送單元803發(fā)送的控制權共享請求中指示將控制權共享給第二控制端UE,該控制權共享請求包含第一控制端UE以及第二控制端UE的優(yōu)先級信息，因此AS在接收到媒體處理請求時，會按照該優(yōu)先級，僅向優(yōu)先級最高的控制端UE發(fā)送媒體處理請求，由于只會有一個控制端UE接收到媒體處理請求，則可以避免多個控制端 UE同時接收到媒體處理請求時所導致的操作沖突，因此可以避免第二控制端UE多次接收到媒體處理請求，從而可以減少網(wǎng)絡數(shù)據(jù)傳輸量，提高系統(tǒng)性能。下面介紹本發(fā)明實施例中的媒體處理系統(tǒng)實施例，請參閱圖9，本發(fā)明實施例中的媒體處理系統(tǒng)包括第一控制端用戶設備901，第二控制端用戶設備902以及應用服務器903 ；需要說明的是，本實施例中的媒體處理系統(tǒng)可以分為兩種情況在一種情況中，該第一控制端用戶設備901與第二控制端用戶設備902可以為本領域技術人員的公知常識，而應用服務器903可以為如圖6所示實施例中的應用服務器，具體的單元功能以及單元間的聯(lián)系均與圖6所示實施例中描述的內容相同，此處不再贅述。在另一種情況中，該第二控制端用戶設備902可以為本領域技術人員的公知常識，而應用服務器903可以為如圖7所示實施例中的應用服務器，具體的單元功能以及單元間的聯(lián)系均與圖7所示實施例中描述的內容相同，第一控制端用戶設備901可以為如圖8 所示實施例中的控制端用戶設備，具體的單元功能以及單元間的聯(lián)系均與圖8所示實施例中描述的內容相同，此處不再贅述。本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分步驟是可以通過程序來指令相關的硬件完成，該程序可以存儲于一種計算機可讀存儲介質中，上述提到的存儲介質可以是只讀存儲器，磁盤或光盤等。以上對本發(fā)明所提供的一種媒體處理方法及媒體處理系統(tǒng)以及相關設備進行了詳細介紹，對于本領域的一般技術人員，依據(jù)本發(fā)明實施例的思想，在具體實施方式
及應用范圍上均會有改變之處，因此，本說明書內容不應理解為對本發(fā)明的限制。
權利要求
1.一種媒體處理方法，其特征在于，包括接收第一媒體處理請求；向各控制端用戶設備UE發(fā)送所述第一媒體處理請求，所述各控制端UE至少包括第一控制端UE以及第二控制端UE ；接收第一控制端UE針對所述第一媒體處理請求反饋的第二媒體處理請求，所述第二媒體處理請求指示媒體在第二控制端UE中進行傳輸；若接收第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求，當所述第二控制端UE同意在自身傳輸所述媒體時，向所述第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，當所述第二控制端UE不同意在自身傳輸所述媒體時，向所述第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。
2.根據(jù)權利要求1所述的方法，其特征在于，若所述第三媒體處理請求為2000K消息，則確定第二控制端UE同意在自身傳輸所述媒體。
3.根據(jù)權利要求1所述的方法，其特征在于，若所述第三媒體處理請求為媒體轉移消息或拒絕傳輸消息，則確定第二控制端UE不同意在自身傳輸所述媒體。
4.根據(jù)權利要求1所述的方法，其特征在于，若所述第三媒體處理請求為媒體轉移消息，則收到所述媒體轉移消息后，向所述第二控制端UE發(fā)送拒絕消息，在所述拒絕消息的call-info消息頭中指明拒絕的原因。
5.根據(jù)權利要求1所述的方法，其特征在于，若未接收第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求的，則確定第二控制端UE不同意在自身傳輸所述媒體。
6.根據(jù)權利要求3或5所述的方法，其特征在于，若所述第二控制端UE不同意在自身傳輸所述媒體信息，所述方法還包括向所述第二控制端UE提供當前聯(lián)合會話的狀態(tài)信息，所述當前聯(lián)合會話的狀態(tài)信息包括以下參數(shù)中的至少一種聯(lián)合會話內每個媒體的媒體類型、聯(lián)合會話內每個媒體當前所在的UE標識、聯(lián)合會話內每個媒體所使用的端口、聯(lián)合會話內每個媒體的媒體狀態(tài)。
7.根據(jù)權利要求1至4中任一項所述的方法，其特征在于，所述接收第一控制端UE針對所述第一媒體處理請求反饋的第二媒體處理請求之后包括向除第一控制端UE以及第二控制端UE之外的其他控制端UE發(fā)送取消消息以取消發(fā)送給所述其他控制端UE的媒體處理請求。
8.一種應用服務器，其特征在于，包括請求接收單元，用于接收第一媒體處理請求；請求發(fā)送單元，用于向各控制端用戶設備UE發(fā)送所述第一媒體處理請求，所述各控制端UE至少包括第一控制端UE以及第二控制端UE ；應答接收單元，用于接收第一控制端UE針對所述第一媒體處理請求反饋的第二媒體處理請求，所述第二媒體處理請求指示媒體在第二控制端UE中進行傳輸；通知單元，用于在應答接收單元接收第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求時，若所述第二控制端UE同意在自身傳輸所述媒體，則向所述第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，若所述第二控制端UE不同意在自身傳輸所述媒體，則向所述第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。
9.根據(jù)權利要求8所述的應用服務器，其特征在于，所述應用服務器還包括確定單元，用于當所述第三媒體處理請求為2000K消息時確定第二控制端UE同意在自身傳輸所述媒體，當所述第三媒體處理請求為媒體轉移消息或拒絕傳輸消息時確定第二控制端UE不同意在自身傳輸所述媒體，當應答接收單元在預置的時長內未接收到第二控制端UE針對第一媒體處理請求反饋的第三媒體處理請求時確定第二控制端UE不同意在自身傳輸所述媒體。
10.根據(jù)權利要求8或9所述的應用服務器，其特征在于，所述應用服務器還包括 取消單元，用于向除第一控制端UE以及第二控制端UE之外的其他控制端UE發(fā)送取消消息以取消發(fā)送給所述其他控制端UE的媒體處理請求。
全文摘要
本發(fā)明實施例公開了一種媒體處理方法及相關設備，本發(fā)明實施例方法包括接收第一媒體處理請求；向各控制端UE發(fā)送第一媒體處理請求；接收第一控制端UE針對第一媒體處理請求反饋的第二媒體處理請求，第二媒體處理請求指示媒體在第二控制端UE中進行傳輸；當?shù)诙刂贫薝E同意在自身傳輸媒體時，向第一控制端UE發(fā)送第一通知消息以指示媒體處理成功，當?shù)诙刂贫薝E不同意在自身傳輸媒體時，向第一控制端UE發(fā)送第二通知消息以指示媒體處理失敗。本發(fā)明實施例還提供一種應用服務器。本發(fā)明實施例可以有效提高系統(tǒng)性能以及用戶體驗。
文檔編號H04L29/06GK102195926SQ20101011657
公開日2011年9月21日 申請日期2010年3月1日 優(yōu)先權日2010年3月1日
發(fā)明者金輝 申請人:華為終端有限公司