Voice communication terminal, intermediate node, processing device, connection method, and program
Abstract
It is a connection method between voice communication terminals, and is the 1st voice communication terminal (100), The 1st category containing a plurality of modes of voice codec is indicated to a SDP offer, and it transmits to the 2nd voice communication terminal (200), and is the 2nd voice communication terminal, A plurality of modes are chosen from the 1st category indicated to the SDP offer, and as the 2nd category, it indicates to a SDP answer and transmits to the 1st voice communication terminal. To at least one of a SDP offer and the SDP answers, the demand of the greatest bandwidth or the bandwidth in the mode in which a priority is the highest is indicated among the modes of the voice codec contained in the 2nd category.

Term
No projected expiry on record.
- Priority and filed
- Published
- Today
11 claims: 9 independent, 2 dependent
- 1音声通信端末間の接続方法であって、 第1の音声通信端末で、音声コーデックの複数のモードを含む第1のカテゴリをSDP(Session Description Protocol)オファーに記載して、第2の音声通信端末に送信し、 前記第2の音声通信端末で、前記SDPオファーに記載された前記第1のカテゴリの中から複数のモードを選択して第2のカテゴリとしてSDPアンサーに記載して、前記第1の音声通信端末に送信し、 単一のベアラで前記第1の音声通信端末および前記第2の音声通信端末を接続し、 前記SDPオファーまたは前記SDPアンサーの少なくとも1つに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載される、 接続方法。
- 2音声通信端末間の接続方法であって、 第1の音声通信端末で、音声コーデックの複数のモードを含む第1のカテゴリをSDP(Session Description Protocol)オファーに記載して、第2の音声通信端末に送信し、 前記第2の音声通信端末で、前記SDPオファーに記載された前記第1のカテゴリの中から複数のモードを選択して第2のカテゴリとしてSDPアンサーに記載して、前記第1の音声通信端末に送信し、 単一のベアラで前記第1の音声通信端末および前記第2の音声通信端末を接続し、 前記第1の音声通信端末および前記第2の音声通信端末の間に位置する中間ノードにおいて、受信した前記SDPオファーまたは前記SDPアンサーを参照して、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を行う、 接続方法。
- 3SIP(Session Initiation Protocol)メッセージに付加されるSDPオファーおよびSDPアンサーを交換して着呼側音声通信端末との間で接続を行う発呼側の音声通信端末であって、 前記音声コーデックの複数のモードを含む第1のカテゴリを記載した前記SDPオファーを生成するSDPメッセージ生成部と、 前記SDPオファーを前記着呼側音声通信端末に送信する送信部と、 前記着呼側音声通信端末から、前記SDPオファーに対応する前記SDPアンサーであって、前記SDPオファーに記載した前記第1のカテゴリの中から複数のモードが選択されて第2のカテゴリとして記載されるとともに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載された前記SDPアンサーを受信する受信部と、を有し 単一のベアラで前記着呼側音声通信端末と接続を行う、 音声通信端末。
- 4SIP(Session Initiation Protocol)メッセージに付加されるSDPオファーおよびSDPアンサーを交換して発呼側音声通信端末との間で接続を行う着呼側の音声通信端末であって、 前記発呼側音声通信端末から、前記音声コーデックの複数のモードを含む第1のカテゴリが記載された前記SDPオファーを受信する受信部と、 前記SDPオファーに対応する前記SDPアンサーであって、前記SDPオファーに記載された前記第1のカテゴリの中から複数のモードを選択して第2のカテゴリとして記載するとともに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を記載した前記SDPアンサーを生成するSDPメッセージ生成部と、 前記SDPアンサーを前記発呼側音声通信端末に送信する送信部と、を有し、 単一のベアラで前記着呼側音声通信端末と接続を行う、 音声通信端末。
- 5SIP(Session Initiation Protocol)メッセージに付加されるSDPオファーおよびSDPアンサーを交換して着呼側音声通信端末との間で接続を行う発呼側音声通信端末で用いられる発呼側の処理装置であって、 前記音声コーデックの複数のモードを含む第1のカテゴリを記載した前記SDPオファーを生成し、前記発呼側音声通信端末の送信部へ供給するSDPメッセージ生成部と、 前記SDPオファーに記載した前記第1のカテゴリの中から複数のモードが選択されて第2のカテゴリとして記載されるとともに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載された前記SDPアンサーの受信処理を行なう制御部と、を有し 単一のベアラで前記着呼側音声通信端末と接続を行う、 発呼側処理装置。
- 6SIPメッセージに付加されるSDPオファーおよびSDPアンサーを交換して発呼側音声通信端末との間で接続を行う着呼側音声通信端末で用いられる着呼側処理装置であって、 前記発呼側音声通信端末から送信された、前記音声コーデックの複数のモードを含む第1のカテゴリが記載された前記SDPオファーの受信処理を行なう制御部と、 前記SDPオファーに記載された前記第1のカテゴリの中から複数のモードを選択して第2のカテゴリとして記載するとともに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を記載した前記SDPアンサーを生成するSDPメッセージ生成部と、を有し、 単一のベアラで前記着呼側音声通信端末と接続を行う、 着呼側処理装置。
- 7SIPメッセージに付加されるSDPオファーおよびSDPアンサーを交換して第1の音声通信端末および第2の音声通信端末との間で接続サービスを行う中間ノードであって、 前記第1の音声通信端末で生成され、音声コーデックの複数のモードを含む第1のカテゴリが記載されたSDPオファーと、前記第2の音声通信端末で生成され、前記SDPオファーに記載された前記第1のカテゴリの中から複数のモードが選択され第2のカテゴリとして記載された前記SDPアンサーとを受信する受信部と、 受信した前記SDPオファーまたは前記SDPアンサーを参照して、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅を判断する判断部と、 前記判断部の判断結果を生成する情報生成部と、 前記判断結果をネットワークノードに送信する送信部と、 を有する中間ノード。
- 8着呼側音声通信端末との間で接続を行う発呼側音声通信端末の接続方法であって、 音声コーデックの複数のモードを含む第1のカテゴリを記載したSDPオファーを生成し、 前記SDPオファーを前記着呼側音声通信端末に送信し、 前記着呼側音声通信端末から、前記SDPオファーに記載した前記第1のカテゴリの中から複数のモードが選択されて第2のカテゴリとして記載されるとともに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で、最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求が記載されたSDPアンサーを受信し、 単一のベアラで前記着呼側音声通信端末と接続を行う、 接続方法。
- 9発呼側音声通信端末との間で接続を行う着呼側音声通信端末の接続方法であって、 前記発呼側音声通信端末から、音声コーデックの複数のモードを含む第1のカテゴリが記載された前記SDPオファーを受信し、 前記SDPオファーに記載された前記第1のカテゴリの中から複数のモードを選択して第2のカテゴリとして記載するとともに、前記第2のカテゴリに含まれる前記音声コーデックの前記モードの中で最大の帯域幅もしくは最も優先度の高いモードの帯域幅の要求を記載したSDPアンサーを生成し、 前記SDPアンサーを前記発呼側音声通信端末に送信し、 単一のベアラで前記着呼側音声通信端末と接続を行う、 接続方法。
- 10請求項8記載の接続方法をプロセッサで実行するためのプログラム。
- 11請求項9記載の接続方法をプロセッサで実行するためのプログラム。
Independent claims11
78 paragraphs, as filed
A voice communication terminal, a middle node, a processing unit, a connection method, and a program
0001This indication is related with the art which changes the mode of voice codec about a voice communication terminal used by VoIP (Voice*Over*IP) etc., and a connection method for the same.
0002On communications systems, such as 3GPP, when a communication terminal (following UE:*User*Equipment) communicates IP (Internet*Protocol) base, 呼制御 is performed. In 呼制御, exchange with the communication partner point of an IP address or a port number used by communication, the agreement (negotiation (negotiation)) of the voice codec used by communication, reservation of the course along which data passes, etc. are performed. 呼制御 in 3GPP is performed by IMS (IP*Multimedia*Subsystem). An IMS network is a net for performing routing of the information management for 呼制御, and the signaling message (SIP:Session*Initiation*Protocol) of 呼制御, and interconnection with the legacy network of 3GPP, or nets other than 3GPP.
0003Drawing 8 shows the flow which shows an example of a procedure until the telephone call of VoIP using IMS of 3GPP is performed. Drawing 8 shows the example of a flow in the case of telephoning UE102 from UE100. As shown in Drawing 8, a SIP*INVITE message is transmitted to UE102 from UE100 via an IMS network (ST11), and a SIP*183*Session*Progress message is transmitted to UE100 from UE102 via an IMS network (ST12). Thus, a SIP*INVITE message and a SIP*183*Session*Progress message are exchanged between UE (s), and the negotiation about communication is performed.
0004The SDP (Session*Description*Protocol) offer is added to the SIP*INVITE message, and it is in a SDP offer, The candidate about information required in order to perform VoIP communication, for example, the voice codec currently supported, its payload format, etc., etc. are described. If a SIP*INVITE message is received by ST11, UE102 will choose media information, including suitable voice codec etc., from a plurality of candidates described by the SDP offer, and will describe it to a SDP answer. UE102 adds a SDP answer to a SIP*183*Session*Progress message in ST12, and transmits to UE100.
0005The media information selected by UE102 is analyzed with an IMS network, and the directions which assign the resource according to an analysis result at this telephone call session are outputted to IP core network. In the case of the communication pathway (GPRS* (General*Packet*Radio*Service) *) according to a demand resource, in the case of a PDP context and EPS (Evolved*Packet*System), an EPS bearer is established. According to the directions from an IMS network, resource quota processing with IP core network and a radio access network is performed (ST13). If resource quota processing is completed, a user's call will be performed in UE102 (ST14), if a user answers, a 200 OK message will be transmitted to UE100 (ST15), and a telephone call will be started between UE100 and UE102 (ST16).
0006An example of a SDP offer (SDP*offer) and a SDP answer (SDP*answer) is shown in Drawing 9. In Drawing 9, it is AMR-WB (Adaptive*Multi*Rate*-*Wide*Band) bandwidth-efficiency mode (payload format) by SDP offer, AMR-WB*octet-align mode (payload format), The 4 of AMR*bandwidth-efficiency mode and AMR*octet-align mode modes are offered in UE100, and AMR-WB*bandwidth-efficiency mode is chosen in UE102.
0007And to change voice codec and the mode in the middle of a telephone call, it is necessary to exchange an IMS signaling message, i. e., a SDP offer, and a SDP answer again, and to perform re-negotiation.
0008Here, a thing with a plurality of modes exists in voice codec. The EVS* (Enhanced*Voice*Service) codec to which standardization is performed by 3GPP is the example. According to nonpatent literature (S4-130778:*EVS-4*Design*Constraint) EVS is as AMR-WB non-compatibility mode (non- [the following and] compatibility mode or native mode) besides AMR-WB compatibility mode (following compatibility mode), NB (Narrowband) mode, WB (Wideband) mode, SWB (Super*Wideband) mode, FB (Full*band) mode, etc. exist.
0009A change in the middle of a session may be [these modes] needed. For example, it is a case where the voice codec of one of the two of UE under communication changes to nonpatent literature 1 by SRVCC (Single*Radio*Voice*Communication*Continuity) of a statement, SRVCC*with*ATCF*enhancement*, etc. The case of SRVCC is explained using Drawing 10.
0010For example, as two terminals, UE100 and UE102, are communicating using the SWB mode of EVS, suppose that UE100 separated from the cover area (PS) of LTE, and carried out SRVCC hand-over to the line switching network (CS). In a line switching network, since EVS is not supported, it is that it is changed into the thing (for example, AMR and AMR-WB) of a line switching network support by the voice codec which UE100 uses. It is necessary to perform session re-negotiation of IMS at this time, to also change the voice codec by the side of UE102 into AMR or AMR-WB, to perform session re-negotiation, but to perform transcoding by a middle gateway (patent documents 1 and 2). When performing transcoding, it is desirable on quality for the bandwidth of both terminals to have gathered. Therefore, when [of for example UE100] voice codec changes to AMR, When the voice codec of UE100 changes UE102 side to AMR-WB at NB mode of EVS, it is desirable to change UE102 side without session re-negotiation to WB mode or AMR-WB compatibility mode of EVS.
0011Next, a mode switching method is explained. One methods for changing these modes without the re-negotiation by an IMS signaling message during a session include the method of including all the information about the mode in a RTP payload.
0012Drawing 11 is a figure showing the composition of a RTP packet. A RTP packet consists of IP header, an UDP header, a RTP header, and a RTP payload. A RTP payload is a data part (payload) which a RTP packet carries. That is, according to the described method, the information on the mode can be acquired by checking the contents of the RTP payload.
0013However, in nonpatent literature 2, the method of giving information to a RTP header is proposed instead of giving information to a RTP payload. That is, as shown in Drawing 11, a respectively separate payload type (PT) number (97, 98, 99, 100) is first assigned to NB of AMR-WB non-compatibility mode, WB, SWB, and AMR-WB compatibility mode, and it describes to a SDP offer. Next, all the modes are chosen as a group by a SDP answer. And when it is necessary to change the mode, the mode is changed by describing the payload type number corresponding to the mode of a change place in the payload type (PT) field of a RTP header. This method is made to call it a payload type change (PT*switching).
<p num="0014"><patcit num="1"><text>JP, 2013-12855, A</text></patcit><patcit num="2"><text>JP, 2013-12856, A</text></patcit></p>
<p num="0015"><nplcit num="1"><text>3 GPP*TS*23.216*V12.0. 0"Single*Radio*Voice*Call*Continuity* (SRVCC) "</text></nplcit><nplcit num="2"><text>AHEVS-272 3GPPSA4-EVS*SWG*Conference*Call*#29 (August*29*2013)</text></nplcit><nplcit num="3"><text>RFC*3388 Grouping*of*Media*Lines*in*SDP* (December*2002)</text></nplcit><nplcit num="4"><text>3 GPP*TS*23.237*V12.5. 0"IP*Multimedia*Subsystem* (IMS) *Service*Continuity"</text></nplcit></p>
0016However, when a sampling rate changes with modes in a payload type change, how whose time stamp of a RTP header increases will become scattering by the mode. As a result, there is a problem of being unable to perform reproduction control using RTCP (Real*Time*Control*Protocol) etc. well.
0017In this indication, by performing the mode change of voice codec smoothly, there is no discontinuation of a telephone call and it provides a voice communication terminal with high telephone speech quality, etc. Even if it is a codec which specifically contains several modes in which a sampling rate differs from demand bandwidth, a mode switching method, a voice communication terminal, etc. of the voice codec which can use the conventional reproduction control and the zone secured (zone request to print out files) technique are provided.
0018In the connection method between the voice communication terminals of this indication, the 1st voice communication terminal indicates the 1st category containing a plurality of modes of voice codec to a SDP offer, and transmits to the 2nd voice communication terminal, A plurality of modes are chosen from the 1st category indicated to the SDP offer, and as the 2nd category, the 2nd voice communication terminal indicates to a SDP answer, and transmits to the 1st voice communication terminal. To at least one of a SDP offer and the SDP answers, the demand of the greatest bandwidth in the mode of the voice codec contained in the 2nd category or the bandwidth in the mode in which a priority is the highest is indicated.
0019In the voice communication terminal of this indication, since the mode change of voice codec can be performed smoothly, there is no discontinuation of a telephone call and it can make telephone speech quality high. According to a mode switching method, a voice communication terminal, etc. of voice codec of this indication, even if it is a codec containing several modes in which a sampling rate differs from demand bandwidth, specifically, the conventional reproduction control and the zone secured (zone request to print out files) technique can be used.
0020<figref num="1">The lineblock diagram of the voice communication terminal in Embodiment 1 of this indication</figref><figref num="2A">The explanatory view showing the SDP offer in Embodiment 1 of this indication</figref><figref num="2B">The explanatory view showing the SDP offer in Embodiment 1 of this indication</figref><figref num="2C">The explanatory view showing the SDP offer in Embodiment 1 of this indication</figref><figref num="3">The explanatory view showing a SDP offer of others in Embodiment 1 of this indication</figref><figref num="4A">The explanatory view showing the SDP answer in Embodiment 1 of this indication</figref><figref num="4B">The explanatory view showing the SDP answer in Embodiment 1 of this indication</figref><figref num="4C">The explanatory view showing the SDP answer in Embodiment 1 of this indication</figref><figref num="5">The explanatory view showing operation of the voice communication terminal in Embodiment 1 of this indication</figref><figref num="6A">The SDP offer 示す explanatory view in Embodiment 2 of this indication</figref><figref num="6B">The SDP offer 示す explanatory view in Embodiment 2 of this indication</figref><figref num="7">The lineblock diagram of the middle node in Embodiment 3 of this indication</figref><figref num="8">The explanatory view showing the call control method of conventional technology</figref><figref num="9">The explanatory view showing a SDP offer / answer of conventional technology</figref><figref num="10">The explanatory view explaining the hand-over of conventional technology</figref><figref num="11">The explanatory view showing the composition of the RTP packet of conventional technology</figref>
0021Hereinafter, the composition and operation of the embodiment of this indication are explained with reference to drawings.
0022In this specification, "the 1st category" is the set containing a plurality of modes of voice codec, and also when enumerating and indicating the mode of the voice codec which is an element of a set besides in the case of indicating the name representing a set, or voice codec, it is contained.
0023"The 2nd category" is the set containing a plurality of modes of voice codec, and it is contained also when enumerating and indicating the mode of the voice codec which is an element of a set besides in the case of indicating the name representing a set, or voice codec. the number of voice codec with which the number of the modes of the voice codec contained in the 2nd category is contained in the 1st category -- the same -- or it is less than it.
0024It contains, also when the method of determining a clock rate besides in case the clock rate with beforehand specific it "having been set beforehand" being defined uniquely is defined uniquely.
0025Also when receiving via one or more [besides in the case of receiving from the direct receipt side voice communication terminal] middle nodes, it "contains from the receipt side voice communication terminal. "When it goes via a middle node and the SDP answer has received change by the middle node, naturally the SDP answer after change is received in a receiving part.
0026"shot -- from the 呼 side voice communication terminal -- " -- also when receiving via one or more [besides in the case of receiving from the 呼 side voice communication terminal from direct] middle nodes, it contains. When it goes via a middle node and the SDP offer has received change by the middle node, naturally the SDP offer after change is received in a receiving part.
0027(Circumstances where it resulted in this indication) Some subjects exist in the conventional payload type change.
0028First, when a sampling rate changes with modes, how whose time stamp of a RTP header increases becomes scattering by the mode (subject 1). As a result, there is a problem of being unable to perform reproduction control using RTCP (Real*Time*Control*Protocol) etc. well.
0029Next, when a demand zone (bit rate) changes with modes (subject 2), there is a problem that the zone demanded by the network side is not suitably securable.
0030As a method of solving these subjects, a separate EPS bearer is assigned to each mode, and how to handle separately can be considered. For example, a plurality of voice codec to which the separate EPS bearer was assigned is group-ized, and the method of dealing with it as a flow of one ETP is indicated by nonpatent literature 3. By assigning a separate port number to each voice codec, this method is the method of specifying the group relation of such voice codec and dealing with it as one RTP session. However, in nonpatent literature 3, it is assumed that the sampling rate of the voice codec group-ized is the same, and above-mentioned (subject 1) is not solved. The method of stretching a plurality of bearers requires the management load of the bearer in a middle node, and also when the mode changes, it also has the demerit that it is necessary to run signaling for activating the bearer for the modes which was not used till then.
0031In this indication, by performing the mode change of voice codec smoothly, there is no discontinuation of a telephone call and it provides a voice communication terminal with high telephone speech quality, etc. Even if it is a codec which specifically contains several modes in which a sampling rate differs from demand bandwidth, a mode switching method, a voice communication terminal, etc. of the voice codec which can use the conventional reproduction control and the zone secured (zone request to print out files) technique are provided.
0032(Embodiment 1) Drawing 1 is a block diagram showing the composition of the voice communication terminal concerning Embodiment 1. The left-hand side of Drawing 1 is 発呼 side voice communication terminal 100, and the right-hand side of Drawing 1 is receipt side voice communication terminal 200. 発呼 side voice communication terminal 100 is mainly constituted by SDP message creating section 101, packet generation part 102, storage part 103, control part 104, transmission section 105, receiving part 106, and judgment part 107. Receipt side voice communication terminal 200 is mainly constituted by SDP message creating section 201, packet generation part 202, storage part 203, control part 204, transmission section 205, receiving part 206, and judgment part 207.
0033SDP message creating section 101 by the side of 発呼 generates the SDP offer in a SIP*INVITE message. In that case, judgment part 107 judges the demand zone at the time of SDP message creating section 101 generating SDP オファージ. Drawing 2A and Drawing 2B show the example of the SDP offer generated by SDP message creating section 101. In the media column of the SDP offer, the mode of the voice codec which 発呼 side voice communication terminal 100 is supporting thru/or voice codec is written. In the case of Drawing 2A and Drawing 2B, 発呼 side voice communication terminal 100 is, The four modes, the AMR-WB non-compatibility mode (SWB) of EVS, the AMR-WB non-compatibility mode (WB) of EVS, the AMR-WB non-compatibility mode (NB) of EVS, and the AMR-WB compatibility mode (WB) of EVS, are supported. The 1st category is constituted in these four modes. The AMR-WB compatibility mode (WB) of EVS is contained, When receipt side voice communication terminal 200 which received the SDP offer does not support EVS but is supporting only AMR-WB of legacy, it is for choosing only the line (payload type 100) of AMR-WB, and enabling it to answer.
0034As shown in Drawing 2C, the AMR-WB non-compatibility mode (SWB) of EVS, the AMR-WB non-compatibility mode (WB) of EVS, and the AMR-WB non-compatibility mode (NB) of EVS may be summarized, for example, it may indicate in one line as EVS/32000. Thus, the 1st category is good also as a name representing the set which may contain the name representing the set which summarized a plurality of modes of voice codec, and summarized a plurality of modes for the 1st category itself.
0035Similarly, in the media column of the SDP offer, based on judgment of the demand zone in judgment part 107, as shown in Drawing 2A, the demand of the greatest bandwidth that the mode contained in the 1st category, i. e., the mode which 発呼 side voice communication terminal 100 supports, uses is written. For example, SWB and WB mode set to 80k bps bandwidth indicated to a SDP offer, when a maximum of 80k bps, NB mode, and AMR-WB compatibility mode (WB) require a maximum of 30k bps.
0036Or in the media column of a SDP offer, based on judgment of the demand zone in judgment part 107, as shown in Drawing 2B, the demand of the bandwidth in the mode in which a priority is the highest is written among the modes contained in the 1st category, i. e., the mode which 発呼 side voice communication terminal 100 supports. For example, when NB mode is the mode in which a priority is the highest, the bandwidth indicated to a SDP offer is set to 30k bps. A priority can be judged in the order etc. which were beforehand defined at the voice communication terminal. It may write in the media column of a SDP offer in this order of a priority.
0037When indicating bandwidth and making a bandwidth demand, it may indicate to the below-mentioned SDP answer, without indicating to a SDP offer. Or it does not indicate to SDP, but the contents of SDP are checked, the middle node which stretches a bearer instead is based on the contents of SDP, and judges and determines demand bandwidth, and it may make it assign demand bandwidth in the terminal side.
0038As shown in Drawing 3, the group relation in the mode of voice codec may be described explicitly. It becomes clear to make into one the number of the bearer stretched at the time of a telephone call start by indicating in this way.
0039SDP message creating section 201 by the side of receipt generates the SDP answer in a SIP*183*Session*Progress message corresponding to the SDP offer by the side of 発呼. Drawing 4A, Drawing 4B, and Drawing 4C show the example of the SDP answer generated by SDP message creating section 201. In the media column of the SDP answer, the mode of the voice codec which receipt side voice communication terminal 200 is supporting thru/or voice codec is written out of the candidate in the mode of a plurality of voice codec described by the SDP offer thru/or voice codec. For example, in the case of Drawing 4A, receipt side voice communication terminal 200 is supporting all the four modes. The 2nd category is constituted in these four modes. When receipt side voice communication terminal 200 does not support EVS but is supporting only AMR-WB of legacy, as shown in Drawing 4B, only the line (payload type 100) of AMR-WB which is the AMR-WB compatibility mode (WB) of EVS is chosen, and it is indicated.
0040What [indicated a plurality of modes of voice codec like / the 2nd category / the 1st category / not only] It is good also as a name representing the set which may contain the name representing the set which summarized a plurality of modes of voice codec, and summarized a plurality of modes for the 2nd category itself.
0041Similarly in the media column of the SDP answer, the demand of bandwidth is written. The demand of this bandwidth may be copied from a SDP offer, when bandwidth is indicated to the SDP offer, and it may be indicated based on judgment of the demand zone in judgment part 207. Drawing 4A shows the example the demand of the greatest bandwidth that the mode contained in the 2nd category, i. e., the mode which receipt side voice communication terminal 200 supports, uses is indicated to be. 80k bps which is the bandwidth which SWB and WB mode require is indicated by this example. Drawing 4C shows the example the demand of the bandwidth in the mode in which a priority is the highest is indicated to be among the modes contained in the 1st category, i. e., the mode which receipt side voice communication terminal 200 supports. 30k bps in case NB mode is the mode in which a priority is the highest is indicated by this example. A priority can be judged to the media column of a SDP offer from an order of a statement, the order beforehand defined at the voice communication terminal, etc.
0042According to a SDP offer and a SDP answer, resource assignment is performed by the network side, and packet generation part 102 generates the RTP packet which is a packet for transmitting the coded voice data, after a telephone call is started through a user call. The composition of a RTP packet is as in Drawing 11. Packet generation part 102 reads a clock rate from storage part 103, using the read clock rate, gives a time stamp into a RTP packet, and generates a RTP packet. Or it may replace with reading a clock rate and may give a time stamp using the clock rate which read the method of determining a clock rate, and determined and determined the clock rate in accordance with the method of starting. Judgment part 107 makes a decision of a clock rate. The method of determining the clock rate thru/or clock rate memorized by storage part 103 is mentioned below.
0043When packet generation part 102 needs to change the mode of voice codec thru/or voice codec by hand-over etc., The payload type (PT) number which did not perform re-negotiation by a SDP offer / answer, but was assigned to the mode of the voice codec of a change place thru/or voice codec in the payload type field of the RTP header is specified, The mode of voice codec thru/or voice codec is changed (payload type change). The payload type change is the same as that of the conventional technology explained in Drawing 11. In this case, a clock rate is not changed with a change. Also when it is a change method in case mode information is included in the payload instead of a payload type change method, re-negotiation by a SDP offer / answer is not performed, but the mode information included in the payload is used for a mode change. Also in this case, a clock rate is not changed with a change.
0044Packet generation part 202 has the same composition as packet generation part 102.
0045Storage part 103 has memorized the deciding method of a clock rate common to the mode of the voice codec contained in the 2nd category thru/or voice codec, or a clock rate. For example, when the voice codec contained in the 2nd category is EVS, 48000 Hz which is a sampling rate of AMR-WB non-compatibility mode (FB) can be appointed at using as a clock rate. The deciding method of the clock rate instead of the clock rate of such unique fixation may be defined. For example, when the deciding method made into the greatest thing among the modes of the voice codec contained in the 2nd category is defined, in the case of Drawing 4A, it becomes with 32000 Hz. The clock rate as which important one is determined here should just be a clock rate common to the mode of the voice codec contained in the 2nd category thru/or voice codec, and there is. That is, it is although it becomes a change within the mode contained in the 2nd category in changing the mode without re-negotiation, It is because a clock rate does not change in the range of such a change, i. e., a time stamp does not change before and after a change, i. e., the value of a time stamp may be given continuously.
0046Storage part 203 has the same composition as storage part 103.
0047Control part 104 realizes the function of SDP message creating section 101 and packet generation part 102, and also performs the input and output to storage part 103, and control of transmission section 105 and receiving part 106. Control part 104 realizes the function of judgment part 107. Judgment part 107 determines a clock rate with reference to storage part 103, and, specifically, supplies it to packet generation part 102. Judgment part 107 determines the bandwidth to demand and supplies it to SDP message creating section 101. Control part 204 also has the same composition as control part 104.
0048Transmission section 105 turns to receiving part 206 of receipt side voice communication terminal 200 the SDP offer generated by SDP message creating section 101, and the RTP packet generated by packet generation part 102, and transmits, and receiving part 206 receives this.
0049Transmission section 205 turns to receiving part 106 of 発呼 side voice communication terminal 100 the SDP answer generated by SDP message creating section 201, and the RTP packet generated by packet generation part 202, and transmits, and receiving part 106 receives this.
0050The 発呼 side processing unit consists of control part 104 containing SDP message creating section 101, packet generation part 102, and judgment part 107 and storage part 103. The receipt side processing unit consists of control part 204 containing SDP message creating section 201, packet generation part 202, and judgment part 207 and storage part 203. The 発呼 side processing unit and the receipt side processing unit correspond to the composition of semifinished product levels, such as part levels, such as a semiconductor device, or a system board.
0051Next, operation of 発呼 side voice communication terminal 100 and receipt side voice communication terminal 200 is explained using Drawing 5. Drawing 5 is an explanatory view showing operation (method) of 発呼 side voice communication terminal 100 of this indication, and receipt side voice communication terminal 200 of operation.
0052First, 発呼 side voice communication terminal 100 generates a SDP offer, and transmits towards receipt side voice communication terminal 200 (S1). In requiring bandwidth at 発呼 side voice communication terminal 100, it indicates this demand to a SDP offer.
0053Receipt side voice communication terminal 200 receives the SDP offer transmitted from 発呼 side voice communication terminal 100 (S2). And a SDP answer is generated corresponding to a SDP offer, and it transmits towards 発呼 side voice communication terminal 100 (S3). In requiring bandwidth at receipt side voice communication terminal 200, it indicates this demand to a SDP answer.
0054発呼 side voice communication terminal 100 receives the SDP answer transmitted from receipt side voice communication terminal 200 (S4).
0055if a telephone call is started, in order to transmit the coded voice data -- 発呼 side voice communication terminal 100 and receipt side voice communication terminal 200 -- it comes out, respectively and a RTP packet is generated (S8). Under the present circumstances, a clock rate is read from storage parts 103 and 203, a clock rate is determined by judgment part 107 in control part 104, and judgment part 207 in control part 204, and a time stamp is given at this clock rate.
0056When the necessity for a mode change arises for the reasons of hand-over etc., the mode of voice codec thru/or voice codec is changed from 発呼 side voice communication terminal 100 or receipt side voice communication terminal 200 by specifying a payload type (PT) number (S9). When mode information is included in the payload instead of a payload type change method, the mode is changed using this information.
0057after a change -- again -- 発呼 side voice communication terminal 100 and receipt side voice communication terminal 200 -- it comes out, respectively and a RTP packet is generated (S10). Under the present circumstances, a time stamp is given at the same clock rate as change before. That is, the cycle of a time stamp is changed, is order and does not change. A clock rate may be again read from storage parts 103 and 203 by S10, and it may be made to use the clock rate before a change without operation of read-out from storage part 103, 203 succeedingly.
0058As mentioned above, it is since according to this embodiment the cycle of a time stamp does not change before and after a mode change as a result of a clock rate's not changing before and after the mode change of voice codec, Reproduction control using RTCP (Real*Time*Control*Protocol) etc. can be performed satisfactorily.
0059According to this embodiment, it becomes possible to secure suitably the zone demanded by the network side.
0060(Embodiment 2) This embodiment explains other examples of the SDP offer which 発呼 side voice communication terminal 100 transmits.
0061The case where it negotiates by transmitting the SDP offer of Embodiment 1 shown in Drawing 2A to receipt side voice communication terminal 200 (negotiation) is considered. When receipt side voice communication terminal 200 which received the SDP offer does not support EVS but is supporting only AMR-WB, as shown in Drawing 4B, only the line (payload type 100) of AMR-WB is chosen, and a SDP answer is transmitted.
0062However, in the case of Drawing 2A, bandwidth is set to 80k bps, but when coding by the AMR-WB non-compatibility mode of EVS is not performed, such wide bandwidth is not needed in many cases. Since receipt side voice communication terminal 200 does not correspond to the transcription method of SDP which performed group-ization as shown in Drawing 3 when group-ization is indicated explicitly, as shown in Drawing 3, it may be unable to choose only the line (payload type 100) of AMR-WB.
0063So, by this embodiment, as shown in Drawing 6A, while indicating all the four modes to support in the 1st media line, only the AMR-WB non-compatibility mode of EVS is taken out independently in the 2nd media line, and is indicated in it. As shown in Drawing 6B, group relations may be displayed on the 1st media line. Even if it performs a statement as shown in Drawing 6A or Drawing 6B, when EVS is chosen in receipt side voice communication terminal 200, the 2nd media line is deleted by a SDP answer, Since the 1st media line is deleted by a SDP answer when AMR-WB is chosen in receipt side voice communication terminal 200, the bearer used for a telephone call becomes single.
0064Thus, bandwidth required for the AMR-WB non-compatibility mode of EVS and suitable can be uniquely set up by taking out only the AMR-WB non-compatibility mode of EVS, and indicating in another media line.
0065As another embodiment of this embodiment, 発呼 side voice communication terminal 100 may transmit the SDP offer of the same Drawing 2A as Embodiment 1, and may change and indicate the value of a demand zone by the middle receipt side voice communication terminal [which answers this] 200, or network node side.
0066The function of voice communication terminals 100 and 200 of these Embodiments 1 and 2, It may be mounted in the node which carries out the anchor of SDP messages and voice data, such as MGM (media*gateway), ATCF of SRVCC*with*ATCF*enhancement, and ATGW.
0067(Embodiment 3) This embodiment explains middle node 300 located by Embodiments 1 and 2 between 呼 side voice communication terminal 100 from 記載した, or receipt side voice communication terminal 200.
0068Drawing 7 is a block diagram which checks the contents of a SDP offer or the SDP answer and in which showing the composition of middle nodes, such as P-CSCF. Middle node 300 comprises receiving part 301, judgment part 302, information generating part 303, and transmission section 304.
0069Middle node 300 can also realize the node which transmits other SDP messages, although P-CSCF (Proxy*Call*Session*Control*Function) corresponds typically.
0070Receiving part 301 receives a SDP message, i. e., a SDP offer and a SDP answer, from 発呼 side voice communication terminal 100 or receipt side voice communication terminal 200.
0071Judgment part 302 judges the bandwidth required of the network node which performs a QoS (Quality*of*Service) setup. This zone may be beforehand appointed by the operator and may be based on the contents of the SDP offer received from receiving part 301, or the SDP answer. For example, this bandwidth is followed when bandwidth is explicitly indicated to the SDP offer or the SDP answer. When bandwidth is explicitly indicated to neither a SDP offer nor a SDP answer, demand bandwidth is judged from other information, including a media column etc. For example, when it is the codec by which two or more modes are supported, the greatest bandwidth in the mode currently supported may be sufficient and it may be the bandwidth in the mode in which a priority is the highest.
0072Information generating part 303 generates the information for notifying the demand zone judged by judgment part 302 to the network node which performs a QoS (Quality*of*Service) setup.
0073Transmission section 304 transmits the information generated by information generating part 302 to a network node. The received SDP message is transmitted to 発呼 side voice communication terminal 100 or receipt side voice communication terminal 200.
0074Not only a demand zone but other policies, fee collection information, etc. may be included in the judgment made by judgment part 302, or the information created by information generating part 303. The network node which performs a QoS (Quality*of*Service) setup refers to PCRF (Policy*and*Charging*Rules*Function) on 3GPP network, etc., for example. Neither the judgment by judgment part 302 nor the information generation by information generating part 303 is completed by a single network node, but may be performed by cooperation with other nodes.
0075(Generalization) In the above, Embodiments 1 and 2 explained the voice communication terminal of this indication, and Embodiment 3 explained the middle node of this indication. The voice communication terminal of this indication and the middle node of this indication are included also when realizing by installing in general-purpose hardware the program which performs operation (method) of this indication not only as hardware designed for exclusive use, and performing by a processor. As a general-purpose hardware barrel electronic computer, various Personal Digital Assistants, such as a personal computer and a smart phone, etc. are mentioned, for example.
0076The voice communication terminal concerning this indication is contained also when treating a music signal besides in the case of treating an audio signal. And it is applicable to the apparatus related to record of an audio signal or a music signal, transmission, and playback.
0077100 発呼 Side Voice Communication Terminal 200 Receipt Side Voice Communication Terminal 101, 201 SDP message creating section 102, 202 Packet generation part 103, 203 Storage part 104, 204 Control part 105, 205 Transmission section 106, 206 Receiving part 107, 207 Judgment part 300 Middle Node
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
Every citation, both ways
| Document | Relation | Office | Category | Cited during | Relevant claims |
|---|---|---|---|---|---|
| US11799922B2 | Cited by | United States of America | – | Applicant | – |
| JP2021061630A | Cited by | Japan | – | Search report | – |
| US10701109B2 | Cited by | United States of America | – | Applicant | – |
| US11444984B2 | Cited by | United States of America | – | Applicant | – |
| US12155698B2 | Cited by | United States of America | – | Applicant | – |
| US11736983B2 | Cited by | United States of America | – | Applicant | – |
| US10771509B2 | Cited by | United States of America | – | Applicant | – |
| WO2018064488A1 | Cited by | World Intellectual Property Organization (WIPO) | – | Applicant | – |
| CN109479113A | Cited by | China | – | Search report | – |
| US11252612B2 | Cited by | United States of America | – | Applicant | – |
| US10965719B2 | Cited by | United States of America | – | Applicant | – |
| JP2022068304A | Cited by | Japan | – | Search report | – |
| US11290509B2 | Cited by | United States of America | – | Applicant | – |
| US12160776B2 | Cited by | United States of America | – | Applicant | – |
| US11171999B2 | Cited by | United States of America | – | Applicant | – |
| JP2020521374A | Cited by | Japan | – | Search report | – |
| EP3497949A4 | Cited by | European Patent Office (EPO) | – | Search report | – |
| JP2005318534A | Cites | Japan | Y | International search | 2, 7 |
| JP2008530921A | Cites | Japan | Y | International search | 1-11 |
| JP2010533419A | Cites | Japan | Y | International search | 1-11 |
| WO2013080471A1 | Cites | World Intellectual Property Organization (WIPO) | Y | International search | 1-11 |
| TAKUYA SAWADA ET AL., JISSEN NYUMON NETWORK JISSEN SIP SHOKAI TEXT, 11 November 2005 (2005-11-11), pages 248 - 253, XP008183214 | Non-patent | – | – | International search | – |
| See also references of EP 3113468A4 | Non-patent | – | – | International search | – |
8 members in 4 offices
Members8
| Document | Office | Kind | |
|---|---|---|---|
| WO2015129181A1This record | World Intellectual Property Organization (WIPO) | A1 | |
| US2016308919A1 | United States of America | A1 | |
| EP3113468A1 | European Patent Office (EPO) | A1 | |
| EP3113468A4 | European Patent Office (EPO) | A4 | |
| JPWO2015129181A1 | Japan | A1 | |
| JP6454683B2 | Japan | B2 | |
| US10594744B2 | United States of America | B2 | |
| EP3113468B1 | European Patent Office (EPO) | B1 |
Numbers
- Publication
- 2015/129181
- Application
- 619
Titles5
- English
- A voice communication terminal, a middle node, a processing unit, a connection method, and a program
- French
- TERMINAL DE COMMUNICATION VOCALE, NŒUD INTERMÉDIAIRE, DISPOSITIF DE TRAITEMENT, PROCÉDÉ DE CONNEXION ET PROGRAMME
- Japanese
- 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
- Unlabeled
- 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
- Japanese
- A voice communication terminal, a middle node, a processing unit, a connection method, and a program
Classification
- CPC, 9
- H04L65/1069
- H04L65/1016
- H04L65/80
- H04L47/2416
- H04L65/1104
- H04L65/65
- H04W36/00226
- H04L65/1033
- H04L65/403
- IPC, 4
- H04M11 00
- H04L47 2416
- H04W36 14
- H04W80 10
Designated states147
- Regional, 80
- Botswana
- Ghana
- Gambia
- Kenya
- Liberia
- Lesotho
- Malawi
- Mozambique
- Namibia
- Rwanda
- Sudan
- Sierra Leone
- Eswatini
- United Republic of Tanzania
- Uganda
- Zambia
- Zimbabwe
- Armenia
- Azerbaijan
- Belarus
- Kyrgyzstan
- Kazakhstan
- Russian Federation
- Tajikistan
and 56 moreShow fewer
- Turkmenistan
- Albania
- Austria
- Belgium
- Bulgaria
- Switzerland
- Cyprus
- Czechia
- Germany
- Denmark
- Estonia
- Spain
- Finland
- France
- United Kingdom
- Greece
- Croatia
- Hungary
- Ireland
- Iceland
- Italy
- Lithuania
- Luxembourg
- Latvia
- Monaco
- North Macedonia
- Malta
- Netherlands (Kingdom of the)
- Norway
- Poland
- Portugal
- Romania
- Serbia
- Sweden
- Slovenia
- Slovakia
- San Marino
- Türkiye
- Burkina Faso
- Benin
- Central African Republic
- Congo
- Côte d’Ivoire
- Cameroon
- Gabon
- Guinea
- Equatorial Guinea
- Guinea-Bissau
- Comoros
- Mali
- Mauritania
- Niger
- Senegal
- Chad
- Togo
- Sao Tome and Principe
- National, 67
- United Arab Emirates
- Antigua and Barbuda
- Angola
- Australia
- Bosnia and Herzegovina
- Barbados
- Bahrain
- Brunei Darussalam
- Brazil
- Belize
- Canada
- Chile
- China
- Colombia
- Costa Rica
- Cuba
- Dominica
- Dominican Republic
- Algeria
- Ecuador
- Egypt
- Grenada
- Georgia
- Guatemala
and 43 moreShow fewer
- Honduras
- Indonesia
- Israel
- India
- Iran (Islamic Republic of)
- Japan
- Saint Kitts and Nevis
- Democratic People’s Republic of Korea
- Republic of Korea
- Lao People’s Democratic Republic
- Saint Lucia
- Sri Lanka
- Libya
- Morocco
- Republic of Moldova
- Montenegro
- Madagascar
- Mongolia
- Mexico
- Malaysia
- Nigeria
- Nicaragua
- New Zealand
- Oman
- Panama
- Peru
- Papua New Guinea
- Philippines
- Qatar
- Saudi Arabia
- Seychelles
- Singapore
- El Salvador
- Syrian Arab Republic
- Thailand
- Tunisia
- Trinidad and Tobago
- Ukraine
- United States of America
- Uzbekistan
- Saint Vincent and the Grenadines
- Viet Nam
- South Africa