CA 02774429 2014-08-29
1
METHOD FOR CONTROLLING SESSION AND
SERVER USING THE SAME
Technical Field
[1] This disclosure relates to an Inter-UE Transfer (IUT).
Background
[2] In general, a session between a first terminal and a service provider,
or between the first
terminal and a second terminal in a network based upon an Internet Protocol
(IP) Multimedia
Subsystem (MS) (IMS) is performed under control of an application server.
[3] Recently, as users use various types of plural terminals (for example,
portable terminals,
TVs, computers, smart phones, etc.), a research has been devoted to the
technique for
transferring/copying part or all of media flows composing a session, which was
established by a
first terminal, to a second terminal.
[4] The transfer, move or copy of part or all of media flows in a session
between terminals is
referred to as Inter-UE Transfer (IUT).
[5] The IUT may also be performed between terminals belonging to different
users, as well as
being performed between terminals belonging to same user, which has recently
been researched
in 3GPP Release 10. Consequently, information share, collaboration and
entertainment between
family members, business members and social network members are allowed by
virtue of the
IUT. The IUT will be described with reference to FIG. 1.
[6] FIG. 1 is an overview showing an Inter-UE Transfer (IUT) according to
the related art.
[7] As shown in the left side of FIG. 1(a), a first user possesses a
plurality of terminals, e.g.,
User Equipment (UE)-1, UE-2 and UE-3. The UE-1 owned by the first user has a
session
containing audio and video media with a remote end, for example, a service
provider. FIG. 1
shows a Service Centralization and Continuity Application Server (SCC AS),
which controls
such session.
[8] Under the environments, the first user desires to use the UE-2 and UE-
3, respectively to
perform the session with the remote end . For example, if it is assumed that
the UE-1 is a
cellular phone, the UE-2 is an earset or headset having a communication
function, and the UE-3
is a Head Up Display (HUD) having a communication function, the first user
desires to perform
the audio media session with the remote end via the earset or headset, and
perform the video
media session with the remote end via the HUD.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
2
[91 Accordingly, as shown in the right side of FIG. 1(a), the audio media
flow which was
terminated to the UE-1, is transferred to the UE-2 and the video media flow
thereof is
transferred to the UE-3. Here, even after the audio and video media flows are
transferred from the UE-1 to the UE-2 and UE-3, respectively, the UE-1 can
still
control the transferred audio and video media flows.
[10] Here, the UE-1 is called as a controller UE and the UE-2 and the UE-3
are called as
controllee UEs. Also, the session, which contains the audio and video media
and in
which the UE-1, UE-2 and UE-3 take part, is referred to as a collaborative
session.
[11] Meanwhile, as shown in the left side of FIG. 1(b), the first user is
performing a
session containing audio media flow using the UE-2 and is performing a session
containing video media flow using the UE-3, and these media flows are under
control
of the UE-1. Here, the first user transfers the control (control-ownership)
taken by the
UE-1 to the UE-2.
[12] Accordingly, as shown in the right side of FIG. 1(b), the UE-2 is
performing the
session containing the audio media flow, and has the control for the
collaborative
session in which the UE-2 and UE-3 are involved. The UE-3 keeps performing the
session containing the video media flow. After the transfer of the control, UE-
2
becomes a controller UE, and UE-3 is a controllee UE as the same as before, UE-
1 no
more belongs to the collaborative session.
[13] On the other hand, as shown in the left side of FIG. 1(c), the first
user is performing a
session containing audio and video media flows with the remote end via the UE-
1.
Here, the first user transfers both the audio and video media flows and the
control to
the UE-3.
[14] As shown in the right side of FIG. 1(c), the UE-3 accordingly performs
the session
containing the audio and video media flows. In this inter-UE transfer, no
collaborative
session is established.
[15] FIG. 2 shows an IUT process according to the related art.
[16] It is assumed in FIG. 2 that UE-1 11 and UE-2 12 belong to a user A,
and UE-3 13
belongs to a user B.
[17] FIG. 2 also shows a home network in which the users have subscribed.
The home
network includes IP Multimedia Subsystem (IMS) nodes 51, SCC AS-1 52a and SCC
AS-2 52b.
[18] As shown in FIG. 2, in a state where the user A is performing a
session containing
text, audio and video media with the remote end 30 via the UE-1 11, the user A
transfers the audio and video media flows to the UE-3 13 belonging to the user
B while
maintaining the session continuity. Here, even after the audio and video media
flows
are transferred to the UE-3 13, the UE-1 11 still has the control for the
transferred
media flows, which will be described in detail with reference to FIG. 2.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
3
[19] 1) The UE-1 11 decides to transfer the audio and video media flows to
the UE-3 13.
[20] 2a-2b) The UE-1 11 sends a transfer request message, for example,
Media Transfer
Request message, to the SCC AS-1 52a to transfer the audio and video media
flows to
the UE-3 13.
[21] 3) The SCC AS-1 52a then authorizes or verifies the transfer request
message sent by
the UE-1 11. The authorization and verification may be performed based upon
subscriber information. The authorization and verification may be performed to
determine whether the UE-1 11 is a terminal for which the IUT operation is
supported
(allowed). Alternatively, the authorization or verification may be performed
to
determine whether the media flows in the UE-1 11 can be transferred to the UE-
3 13.
[22] 4) The SCC AS-1 52a transfers the transfer request message to the SCC
AS-2 52b via
the IMS nodes 51.
[23] 5) The SCC AS-2 52b authorizes or verifies the transfer request
message. The autho-
rization or verification may be performed based upon subscriber information,
which is
similar to the foregoing description, so it will be understood by the
foregoing de-
scription without detailed description.
[24] 6a-6b) The SCC AS-2 52b sends a session initiation request message
(for example,
SIP-based INVITE message), which includes information related to the audio and
video media flows requested to be transferred, to the UE-3 13 via the IMS
nodes, in
response to the transfer request message.
[25] 7a-7b) The UE-3 13 then sends a session initiation accept message to
the SCC AS-2
52b via the IMS nodes 51, in response to the session initiation request
message.
[26] 8) The SCC AS-2 52b then forwards the session initiation accept
message to the SCC
AS-1 52a via the IMS nodes 51.
[27] 9) The SCC AS-1 52a completes the transfer of the audio and video
media flows
from the UE-1 11 to the UE-3 13 based upon the session initiation accept
message.
[28] The UE-1 11 has the control for a collaborative session containing the
text media, the
audio media and the video media, after transferring the audio and video media
flows to
the UE-3 13. That is, the UE-1 11 then serves as a controller UE, and the UE-3
13
serves as a controllee UE.
[29] FIG. 3 is an exemplary view showing problems of the related art.
[30] As shown in FIG. 3, UE-1 11 and UE-2 12 belong to a user A, and UE-3
13 belongs
to a user B.
[31] Also, FIG. 3 shows a home network in which the users A and B have
subscribed. The
home network includes IMS nodes 51, SCC AS-1 52a and SCC AS-2 52b.
[32] 1-2) The UE-1 11 sends a registration request to the IMS nodes 51 to
register in its
home network, and receives an acknowledgement message. Here, the registration
informs the home network of the UE-1 11's current location.
CA 02774429 2015-03-30
4
[33] 3-4) The IMS nodes 51 then perform a third-party registration for the
UE-1 11 to SCC AS-
1 52a, which serves the UE-1 11, and receives an acknowledgement message
therefrom.
[34] 5a-5d) When the UE-1 11 sends a session initiation request message to
establish a session
containing audio and video media with a remote end 30, the IMS nodes 51 then
forward the
session initiation request message to the SCC AS-1 52a serving the UE-1 11
based upon
subscriber information of the user A. The SCC AS-1 52a then transfers the
session initiation
request message to the remote end 30 via the IMS nodes 51.
[35] 6a-6d) The remote end 30 sends a session initiation accept message to
the IMS nodes 51,
and the IMS nodes 51 forward it to the SCC AS-1 52a. The SCC As-1 52a then
transfers the
session initiation accept message to the UE-1 11 via the IMS nodes 51.
Accordingly, the
session containing the audio and video media is established between the UE-1
11 and the
remote end 30.
[36] 7-8) Meanwhile, the user A desires to transfer some media of the
session or control for the
session from the UE-1 11 to the UE-2 12, and thus manipulates the UE-2 12.
However, the UE-
2 12 has no information related to the session being performed by the UE-1 11
(for example,
the UE-2 12 cannot know which media flows are ongoing on the UE-1), and thus
it may not
decide which media flows can be taken from the UE-1 11. Hence, the UE-2 12
cannot generate
and send a transfer request message.
[37] 9-10) Also, the user B desires to transfer some media of the session
or the control for the
session from the UE-1 11 to the UE-3 13, and thus manipulates the UE-3 13.
However, the UE-
3 13 has no information related to the session being performed by the UE-1 11
(for example,
the UE-3 13 cannot know which media flows are ongoing on the UE-1), and thus
it may not
decide which media flows can be taken from the UE-1 11. Hence, the UE-3 13
cannot generate
and send a transfer request message.
Summary
[38] Consequently, according to the related art, other terminals, for
example, UE-2 and UE-3,
which do not have the control for the session being performed by a specific
terminal (e.g., UE-1
in FIG. 3), cannot acquire information related to the session, so they cannot
request a transfer of
part or all of media flows in the session and/or the control of the session
therefore. One example
of such problems will be described as follows. If it is assumed that the UE-1
11 is a device such
as PC and the UE-2 12 is a cellular phone, the user having UE-1 11 and UE-2 12
may be more
CA 02774429 2015-03-30
convenient to manipulate the UE-2 12 to transfer part or all of media flows in
the session being
performed by the UE-1 11 and/or the control for the session. However, the
related art does not
provide any mechanism that the UE-2 12 can acquire the information related to
the session
being performed by the UE-1 11 and accordingly the UE-2 12 cannot send a
transfer request
message.
[39] Therefore, an aspect of the detailed description is to address those
problems.
[40] In other words, an aspect of the detailed description is for other
terminals to request and
acquire information related to a session(s), which is being performed by a
specific terminal, for
example, specific media flows in the session, information related to whether
or not the session
is a collaborative session and the like.
[41] Another aspect of the detailed description is that the specific
terminal is allowed not to
provide information related to the ongoing session(s) to other terminals, for
reasons of, for
example, privacy and the like.
[42] The disclosure describes a method for controlling a session in a
Service Centralization and
Continuity Application Server (SCC AS) which controls the session being
performed between
at least one first terminal and a remote end. The method involves receiving a
session discovery
request message for acquiring information related to the session being
performed between the at
least one first terminal and the remote end from a second terminal, filtering
information of one
or more media flows of the session based on information related to at least
one of user related
information or operator policy and transmitting a session discovery response
message including
information related to the media flows except for the filtered information of
the one or more
media flows to the second terminal. The method also involves receiving a media
transfer
request for at least one media flow which is selected by the second terminal
from among the
media flows except for the filtered information of the one or more media flows
and performing
media transfer of the at least one media flow.
[43] The information related to at least one of user related information or
operator policy may be
included in a registration request message from the first terminal.
[44] The information related to at least one of user related information or
operator policy may be
included in a session initiation request message from the first terminal.
[45] The information related to at least one of user related information or
operator policy may be
included in a session initiation response message from the first terminal.
CA 02774429 2015-03-30
6
[46] The information related to at least one of user related information or
operator policy may be
included in a message sent from the first terminal to the SCC AS serving the
first terminal.
[47] The information related to at least one of user related information or
operator policy may be
included in a subscriber information server in a network.
[48] The information related to at least one of user related information or
operator policy may
include information indicating that all media types in the session being
performed by every
terminal belonging to a specific user should be filtered, information
indicating that a specific
media type in the session being performed by each of all terminals belonging
to the specific
user should be filtered, information indicating that all media types in the
session being
performed by a specific terminal belonging to the specific user should be
filtered or information
indicating that only a specific media type in the session being performed by
the specific
terminal belonging to the specific user should be filtered.
[49] The information related to at least one of user related information or
operator policy may
include a parameter indicating whether specific information included in the
session discovery
response message should be filtered.
[50] The method may further involve receiving a media transfer request
including information
whether to keep the control of collaborative session.
[50a] The method may further involve receiving a media transfer request for
a media transferring.
The first terminal may keep control of a collaborative session after the media
transferring.
[50b] The first terminal may be a controller UE and the second terminal may
be controllee UE.
[50c] The disclosure describes Service Centralization and Continuity
Application Server (SCC
AS)for controlling a session being performed between at least one first
terminal and a remote
end. The SCC AS includes a transceiver and a processor configured to control
the transceiver.
The processor performs receiving a session discovery request message for
acquiring
information related to the session being performed between the at least one
first terminal and
the remote end from a second terminal and filtering information of one or more
a media flows
of the session based on information related to at least one of user related
information or
operator policy. The processor also performs transmitting a session discovery
response message
including information related to the media flows except for the filtered
information of the one
or more media flows to the second terminal, receiving a media transfer request
for at least one
media flow which is selected by the second terminal from among the media flows
except for the
filtered information of the one or more media flows and performing media
transfer of the at
least one media flow.
CA 02774429 2015-03-30
6a
[50d] The information related to at least one of user related information
or operator policy may be
included in a registration request message from the first terminal.
[50e] The information related to at least one of user related information
or operator policy may be
included in a session initiation request message from the first terminal.
[50f] The information related to at least one of user related information
or operator policy may be
included in a session initiation response message from the first terminal.
[50g] The information related to at least one of user related information
or operator policy may be
included in a message sent from the first terminal to the SCC AS serving the
first terminal.
[50h] The information related to at least one of user related information
or operator policy may be
included in a subscriber information server in a network.
[50i] The information related to at least one of user related information
or operator policy may
include information indicating that all media types in the session being
performed by every
terminal belonging to a specific user should be filtered, information
indicating that a specific
media type within the session being performed by each of all terminals
belonging to the specific
user should be filtered, information indicating that all media types in the
session being
performed by a specific terminal belonging to the specific user should be
filtered or information
indicating that only a specific media type in the session being performed by
the specific
terminal belonging to the specific user should be filtered.
[51] The foregoing and other objects, features, aspects and advantages will
become more
apparent from the following detailed description when taken in conjunction
with the
accompanying drawings.
Brief Description of Drawings
[52] The accompanying drawings, which are included to provide a further
understanding of the
invention and are incorporated in and constitute a part of this specification,
illustrate
embodiments of the invention and together with the description serve to
explain the principles
of the invention.
[53] In the drawings:
[54] FIG. 1 is an overview showing an Inter-UE Transfer (IUT) according to
the related art;
[55] FIG. 2 is a view showing an IUT process according to the related art;
[56] FIG. 3 is an exemplary view showing problems of the related art;
[57] FIG. 4 is an exemplary view showing a process of acquiring information
on a session being
performed by a specific terminal;
CA 02774429 2015-03-30
7
[58] FIG. 5 is an exemplary flowchart showing a method for masking
(filtering) information
related to specific media flows in a session being performed by a specific
terminal from being
discovered (retrieved, found) by another terminal;
[59] FIG. 6 is an exemplary flowchart showing a process that in a state
where the information
related to the specific media flows are masked (filtered) from discovery
(retrieval) by another
terminal according to FIG. 5, the another terminal requests for transfer of
media flows except
for the specific media flows;
CA 02774429 2014-08-29
7a
[60] FIG. 7 is an exemplary flowchart showing another method for masking
(filtering)
information related to specific media flows in a session being performed by a
specific terminal
from being discovered by another terminal;
[61] FIG. 8 is an exemplary flowchart showing a process that in a state
where the information
related to the specific media flows are masked (filtered) from discovery
(retrieval) by another
terminal according to FIG. 7, the another terminal requests for transfer of
media flows except
for the specific media flows;
[62] FIG. 9 is a flowchart briefly showing the method according to the
present disclosure; and
[63] FIG. 10 is a block diagram of UE 100 and SCC AS 520.
[64] Technical terms used in this specification are used to merely
illustrate specific
embodiments, and should be understood that they are not intended to limit the
present
disclosure. As far as not being defined differently, all terms used herein
including technical or
scientific terms may have the same meaning as those generally understood by an
ordinary
person skilled in the art to which the present disclosure belongs to, and
should not be construed
in an excessively comprehensive meaning or an excessively restricted meaning.
In addition, if a
technical term used in the description of the present disclosure is an
erroneous term that fails to
clearly express the idea of the present disclosure, it should be replaced by a
technical term that
can be properly understood by the skilled person in the art. In addition,
general terms used in
the description of the present disclosure should be construed according to
definitions in
dictionaries or according to its front or rear context, and should not be
construed to have an
excessively restrained meaning.
[65] A singular representation may include a plural representation as far
as it represents a definitely
different meaning from the context. Terms 'include' or 'has' used herein
should be understood that
they are intended to indicate an existence of several components or several
steps, disclosed in the
specification, and it may also be un-
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
8
derstood that part of the components or steps may not be included or
additional
components or steps may further be included.
[66] It will be understood that, although the terms first, second, etc. may
be used herein to
describe various elements, these elements should not be limited by these
terms. These
terms are only used to distinguish one element from another. For example, a
first
element could be termed a second element, and, similarly, a second element
could be
termed a first element, without departing from the scope of the present
disclosure.
[67] It will be understood that when an element is referred to as being
"connected with"
another element, the element can be directly connected with the other element
or in-
tervening elements may also be present. In contrast, when an element is
referred to as
being "directly connected with" another element, there are no intervening
elements
present.
[68] Embodiments of the present invention will be described below in detail
with
reference to the accompanying drawings, where those components are rendered
the
same reference number that are the same or are in correspondence, regardless
of the
figure number, and redundant explanations are omitted. In describing the
present
invention, if a detailed explanation for a related known function or
construction is
considered to unnecessarily divert the gist of the present invention, such
explanation
has been omitted but would be understood by those skilled in the art. The ac-
companying drawings are used to help easily understood the technical idea of
the
present invention and it should be understood that the idea of the present
invention is
not limited by the accompanying drawings. The idea of the present invention
should be
construed to extend to any alterations, equivalents and substitutes besides
the ac-
companying drawings.
[69] The accompanying drawings exemplarily show User Equipment (UE), but
the UE
may be replaced with other terms, such as terminal, Mobile Equipment (ME) and
the
like. Also, the UE may be a type of portable equipment, such as a notebook, a
cellular
phone, PDA, a smart phone, a multimedia player and the like, or a type of
fixed
equipment, such as PC, vehicle-mounted device and the like.
[70] Term Definition
[71] Hereinafter, prior to description of main characteristics of the
present disclosure,
brief description will be given of definitions of terms used in this
specification, for
better understanding.
[72] 1) IP Multimedia Subsystem (IMS) is a network technology which allows
packet
switching for wireless terminals as well as wired terminals based upon
Internet
Protocol (IP), and has been proposed for connection of both wired and wireless
terminals via IP (All-IP).
[73] A network based upon the IMS includes a Home Subscriber Server (HSS)
having a
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
9
database for storing subscriber information on users (i.e., subscribers), and
other
entities. Also, the IMS-based network includes a Call Session Control Function
(CSCF) for processing control signaling, registration, and procedures for
sessions. The
CSCF may include Proxy-CSCF (P-CSCF), Serving-CSCF (S-CSCF) and Inter-
rogating-CSCF (I-CSCF). The P-CSCF serves as a first access point for a user
Equipment (UE) within the IMS-based network, and the S-CSCF processes and
controls a session within the IMS network. That is, the S-CSCF is an entity
for routing
of a signaling, which routes a session in the IMS network. The I-CSCF serves
as an
access point to other entities within the IMS network.
[74] 2) An IP-based session under the IMS is controlled by a Session
Initiation Protocol
(SIP). The SIP is a protocol for control of a session, namely, a signaling
protocol,
which specifies procedures that terminals, which desire to communicate with
each
other, identify each other to find locations, generate a multimedia session
therebetween, or delete or modify the generated session. The SIP may use a SIP
Uniform Resource Identifier (URI), similar to an e-mail address, for
discrimination of
each user, so as to provide services irrespective of the IP addresses.
[75] 3) Registration indicates a process that UE notifies information
related to its current
location to the home network, namely, a process that the UE sends its current
location
and other information to access the home network.
[76] 4) Application Server (AS) is a server for providing various
multimedia services.
[77] 5) Multimedia Session Continuity indicates supporting UE mobility or
mobility
between UEs while maintaining the continuity of an ongoing session.
[78] 6) Service Centralization and Continuity Application Server (SCC AS)
is an ap-
plication server which supports a multimedia session continuity. [Refer to
3GPP TS
23.237 V10.3.01
[79] 7) Collaborative Session is a set of two or more access legs and
related media on two
or more UEs having IMS subscriptions under the same operator that are
presented as
one remote leg by the SCC AS. [Refer to 3GPP TS 23.237 V10.3.01
[80] 8) Controller UE is a UE that controls a Collaborative Session and
whose service
profile determines the services on the remote leg. The Controller UE may also
support
media flows for a Collaborative Session and may request IUT Media Control
Related
Procedures. [Refer to 3GPP TS 23.237 V10.3.01
[81] 9) Controllee UE is a UE that supports media flows for a Collaborative
Session and
may request IUT Media Control Related Procedures but is subordinate to the
Controller UE for authorization of these procedures. A plurality of Controllee
UEs
may be involved in a Collaborative Session. [Refer to 3GPP TS 23.237 V10.3.01
[82] 10) Remote End is a counter UE or a counter application server
communicating with
the UE.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
[83] 11) Inter-UE Transfer (IUT) indicates transfer at the IMS-level of
some or all of the
media flows and/or service control across a set of having IMS subscriptions
under the
same operator.
[84] 12) IUT Media Control Related Procedures indicate the control
operations on the
media flows of the Collaborative Session which involve multiple UEs or need
Controller UE's authorization within the Collaborative Session, e.g. ability
to transfer/
add/replicate media flows, to remove/modify media flows on a different UE.
[Refer to
3GPP TS 23.237 V10.3.01
[85] 13) Collaborative Session Control is the control operation on the
Collaborative
Session which can only be performed by the Controller UE, e.g. ability to
release the
Collaborative Session, to invoke supplementary services, and to authorize
requests for
IUT Media Control Related Procedures from other UEs. [Refer to 3GPP TS 23.237
V10.3.01
[86] Those terms used in this specification have been defined.
[87] Hereinafter, detailed description will be given with reference to the
accompanying
drawings. However, the description will be mainly given of methods proposed in
this
specification, and other comments will not be described but should be
construed as
being included in this specification without being excluded therefrom.
[88] FIG. 4 is an exemplary view showing a process of acquiring information
on a session
being performed by a specific terminal.
[89] As shown in FIG. 4, a user A possesses User Equipment (UE)-1 110 and a
user B
possesses a UE-2 120. However, this is merely illustrative, and the following
de-
scription will be similarly understood even if it is assumed that the user A
has both
UE-1 and UE-2. The term, 'user' used in this specification may be replaced
with other
terms, such as subscriber, IMS subscription and the like.
[90] FIG. 4 also shows a home network in which the users A and B have
subscribed. The
home network may include IP Multimedia Subsystem (IMS) nodes 510 including S-
CSCF, an SCC AS-1 520a serving the UE-1 110, and an SCC AS-2 520b serving the
UE-2 120. For the IMS nodes 510 including the S-CSCF, although not shown in
detail
in FIG. 4, the same S-CSCF may serve both the UE-1 110 and the UE-2 120, or
different S-CSCFs may serve the UE-1 110 and the UE-2 (for example, S-CSCF-1
may
serve the UE-1 belonging to the user A and S-CSCF-2 may serve the UE-2
belonging
to the user B).
[91] Referring to FIG. 4, the UE-1 110 of the user A performs a
registration process to the
home network and establishes a session containing audio and video media with
the
remote end 300. Here, the UE-2 120 of the user B discovers the session, which
is being
performed by the UE-1 110 and then desires to request for transferring the
video media
in the ongoing session on the UE-1 110 to itself. Hereinafter, a detailed
description
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
11
thereof will be given with reference to FIG. 4. Also, it is assumed in FIG. 4
that the
UE-2 120 has already registered in its home network.
[92] 1-2) The UE-1 110 sends a registration request message, for example,
SIP-based
REGISTER message, to register in its home network, and receives an acknowl-
edgement message, for example, a SIP-based 200 OK message. Here, the
registration
informs the home network of UE-1's current location.
[93] 3-4) The IMS nodes 510 perform a third-party registration for the UE-1
110 to the
SCC AS-1 520a based upon subscriber information related to the user A, and
receives
an acknowledgement message.
[94] 5a-5b) The user A then desires to establish a session containing audio
and video
media with the remote end 300 via the UE-1 110. Accordingly, the UE-1 110
sends a
session initiation request message (e.g., SIP-based INVITE message) to the IMS
nodes
510. The IMS nodes 510 then forward the session initiation request message to
the
SCC AS-1 520a based upon subscriber information related to the user A. The
session
initiation request message includes information related to the audio and video
media.
[95] 6a-6b) The SCC AS-1 520a forwards the session initiation request
message to the
remote end 300 via the IMS nodes 510.
[96] 7a-8b) The remote end 300 sends a session initiation accept message
(e.g., SIP-based
200 OK) to the SCC AS-1 520a via the IMS nodes 510, in response to the session
initiation request message. The SCC AS-1 520a then forwards the message to the
UE-1
110 via the IMS nodes 510. Consequently, a session containing audio and video
media
flows is established between the UE-1 110 and the remote end 300.
[97] 9a-9b) In order to perform an IUT operation using the UE-2 120, the UE-
2 120 of
the user B sends a session discovery request message (e.g., SIP-based
SUBSCRIBE
message) to the SCC AS-2 520b serving the user B so as to discover the ongoing
session on the UE-1 110. The session discovery request message includes a
parameter(s) indicating information related to the UE-1 110. For example, the
parameter may be a target UE.
[98] 10a-10b) Upon receipt of the session discovery request message, the
SCC AS-2
520b forwards the session discovery request message to the SCC AS-1 520a,
which
serves the UE-1 110.
[99] 1la-11b) Upon receipt of the session discovery request message, the
SCC AS-1 520a
sends a session discovery response message (e.g., SIP-based NOTIFY message) to
the
SCC AS-2 520b via the IMS nodes 510. The session discovery response message
includes information related to media flows, e.g., audio and video media flows
in the
session which is being performed by the UE-1 110.
[100] 12a-12b) The SCC AS-2 520b forwards the session discovery response
message sent
by the SCC AS-1 520a to the UE-2 120 via the IMS nodes 510.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
12
[101] 13) The UE-2 120 checks the information included in the session
discovery response
message, and decides to take video media flow from the UE-1 110 based upon the
discovery result.
[102] 14a-14b) The UE-2 120 sends a transfer request message, e.g., Media
Transfer
Request message (e.g., SIP-based REFER message), to the SCC-AS-2 520b to take
the
video media flow from the UE-1 110. The transfer request message includes a
parameter indicating information related to the UE-1 110, e.g., Source UE
parameter,
and a parameter indicating information related to the UE-2 120, e.g., Target
UE
parameter. The transfer request message also includes a media parameter
indicating in-
formation related to media to be transferred.
[103] 15) The SCC AS-2 520b authorizes or verifies the transfer request
message. The au-
thorization or verification may be performed based upon subscriber
information. The
authorization or verification may be performed to check whether the UE-2 120
is
allowed for the IUT operation or is capable of the IUT operation. Also, the
autho-
rization or verification may be performed to check whether the media flows in
the
session which is being performed by the UE-1 110 can be transferred to the UE-
2 120.
If the subscriber information does not include information related to the
authorization
or verification for the IUT operation, the authorization or verification may
not be
performed. Also, it may not be performed when the SCC AS-2 520b does not need
the
authorization or verification.
[104] 16a-16b) The SCC AS-2 520b forwards the transfer request message to
the SCC AS-
1 520a via the IMS nodes 510.
[105] 17a-17b) the SCC AS-1 520a then forwards the transfer request message
to the UE-1
110 via the IMS nodes 510.
[106] 18) The UE-1 110 then authorizes or verifies the transfer request
message sent by the
UE-2 120. The authorization or verification may be performed through
interaction with
the user, or performed based upon information pre-configured in the UE-1 110
without
interaction with the user.
[107] 19a-19b) The UE-1 110 sends a deny message indicating that the
transfer request
message forwarded by the SCC AS-1 520a is not accepted if the transfer is
impossible
or the UE-1 110 does not want to transfer video media flow to another terminal
due to
a current condition of the terminal or a network to which the terminal is
connected.
[108] 20a-20b) The SCC AS-1 520a sends a message indicating failure of the
transfer
request to the SCC AS-2 520b via the IMS nodes 510.
[109] 21a-21b) The SCC AS-2 520b forwards the message indicating the
failure of the
transfer request to the UE-2 120 via the IMS nodes 510.
[110] As described above, the information related to the session being
performed by the
specific terminal, e.g., the UE-1 110, can be freely acquired by another
terminal, e.g.,
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
13
the UE-2 120. However, if the specific terminal does not want to transfer part
or all of
the media flows in its ongoing session, to provide information related to such
media
flows to the another terminal may be unnecessary.
[111] Also, if the another terminal sends the transfer request message even
when the
specific terminal does not want to transfer part or all of the media flows in
its ongoing
session, it may result in a waste of network resources. Especially, there may
be a case
that the specific terminal, e.g., the UE-1 110, does not want to provide the
information
related to its ongoing session to other terminals in terms of privacy.
Conceiving the
foregoing description, the UE-2 120 may freely acquire the information related
to the
ongoing session on UE-1 110, which may be a problem.
[112] In particular, a random terminal may perform a discovery request for
several
terminals, collect information on ongoing sessions and use such information.
[113] As another example, it is assumed that while performing a session
containing audio
and video media using its own terminal, the user A has temporarily transferred
audio
media in the ongoing session which is a Collaborative Session and the control
for the
Collaborative Session to a terminal of a user B. In this state, a user C may
discover in-
formation related to the session which is being performed by the terminal of
the user B
and know the existence of the audio media in the session. Accordingly the user
C may
request to transfer the audio media from the terminal of the user B to its own
terminal.
However, the initiation of the session is done by the user A, and the user A
may not
want the audio media to be transferred to another user other than the user B.
[114] As such, due to the unrestricted discovery of the session, a
controllee terminal may
discover an ongoing session and send a transfer request message for media
flows
which are terminated to the other controllee terminal in the discovered
session to a
controller terminal, which may result in allowing the controllee terminal to
take the
ongoing media flows from the other controllee terminal.
[115] Therefore, a method for preventing (avoiding) discovery of session-
related in-
formation, namely, a method for masking or filtering session-related
information will
be described hereinafter.
[116] In order to mask or filter information related to specific media
flow(s) in a session,
which is being performed by the specific terminal (i.e., on the specific
terminal), from
being discovered by other terminals, several solutions are proposed in this
specification
as follows.
[117] 1) First method in which a terminal sets (adds, configures, places) a
masking flag(s)
with respect to IUT discovery (i.e., mask from IUT discovery) in a
registration
message (e.g., SIP-based REGISTER message) when a terminal registers (or re-
registers) in a home network
[118] A specific terminal may set, in a registration message, a masking
flag(s) with respect
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
14
to IUT discovery for all media types in every session (or all sessions) to be
established
for the terminal. In this case, masking is applied to all media flows
composing every
(originating and terminating) session (or all sessions), which is established
by the
specific terminal for the term of validity of the registration. Accordingly,
when another
terminal sends a session discovery request message for information related to
the
session which is being performed by the specific terminal, SCC AS serving the
specific
terminal does not provide the another terminal with information related to the
masked
media flows (i.e., all of the media flows) in the session on the specific
terminal.
[119] Alternatively, a specific terminal may set a masking flag(s) with
respect to IUT
discovery for a specific media type(s) in a registration message. In this
case, masking
is applied only to the media flows whose masking flag is set among all the
media flows
composing every (originating and terminating) session (or all sessions), which
is es-
tablished by the specific terminal for the term of validity of the
registration. Ac-
cordingly, when another terminal sends a session discovery request message for
in-
formation related to the session being performed by the specific terminal, SCC
AS
serving the specific terminal does not provide the another terminal with
information
related to the masked media flows in the session on the specific terminal.
[120] The masking flag with respect to IUT discovery may be pre-configured
in a terminal
based on a user preference and/or an operator policy. The masking flag
configured in
the terminal may be modified by the user, or configured or modified by
interaction re-
flecting the user preference.
[121] If a terminal wants to set a masking flag(s) with respect to IUT
discovery in a reg-
istration message, the masking flag(s) may be set by using one or more of a
header
field of a SIP message, or one or more of a parameter included in the header
field.
[122] 2) Second method in which a terminal sets (adds, configures, places)
a masking
flag(s) with respect to IUT discovery (i.e., mask from IUT discovery) in a
session
initiation request message (e.g., SIP-based INVITE message) when sending the
session
initiation request message in order to initiate (originate) a session, or sets
a masking
flag(s) with respect to IUT discovery (i.e., mask from IUT discovery) in a
session
initiation accept message (e.g., SIP-based 200 OK) when sending the session
initiation
accept message in order to accept a session (terminating session) initiated by
a remote
end.
[123] A specific terminal may set a masking flag(s) with respect to IUT
discovery for a
specific media type(s) in a session initiation request message or session
initiation
accept message. In this case, masking is applied only to the media flows whose
masking flag is set among all the media flows composing the session
established by the
specific terminal. Accordingly, when another terminal sends a discovery
request
message for information related to the session which is being performed by the
specific
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
terminal, SCC AS serving the specific terminal does not provide the another
terminal
with information related to the masked media flows in the session on the
specific
terminal.
[124] Alternatively, the specific terminal may set a masking flag(s) to the
very session es-
tablished (originated or terminated) in a session initiation request message
or session
initiation accept message. In this case, masking is applied to all media flows
composing the session established by the specific terminal. Accordingly, when
another
terminal sends a session discovery request message for information related to
the
session which is being performed by the specific terminal, SCC AS serving the
specific
terminal does not provide another terminal with information related to the
masked
media flows (i.e., all of the media flows) in the session of the specific
terminal.
[125] The masking flag with respect to the IUT discovery, as aforesaid, may
be pre-
configured in a terminal based on a user preference and/or an operator policy.
The
masking flag configured in the terminal may be modified by the user or
configured or
modified by interaction reflecting the user preference.
[126] When a terminal wants to set a masking flag(s) with respect to IUT
discovery in the
session initiation request message or session initiation accept message, the
masking
flag(s) may be set by using one or more of a header field of a SIP message,
one or
more of a parameter included in the header field or one or more of a field in
a SDP
body.
[127] 3) A third method in which a terminal sets (configures) a masking
flag(s) with
respect to IUT discovery (i.e., mask from IUT discovery) to SCC AS serving
itself by
using a network interface (e.g., Ut)
[128] A specific terminal may use an interface, such as Ut, to request its
serving SCC AS
to set a masking flag(s) with respect to IUT discovery, to release (unset) the
setting, or
to set a validity (e.g., a setting residual time, setting end time, setting
expiration time,
etc.) of the setting for the masking flag(s) with respect to IUT discovery.
[129] A specific terminal may set a masking flag(s) with respect to IUT
discovery for a
specific media type(s) to its serving SCC AS. In this case, masking is applied
only to
the media flows whose masking flag is set among all the media flows composing
every
(originating and terminating) session, which is established by the specific
terminal for
the term of validity of the setting. Accordingly, when another terminal sends
a session
discovery request message for information related to the session being
performed by
the specific terminal, SCC AS serving the specific terminal does not provide
the
another terminal with information related to the masked media flows in the
session on
the specific terminal.
[130] Alternatively, a specific terminal may set a masking flag(s) with
respect to IUT
discovery for all media types composing the session (or the whole session) to
be es-
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
16
tablished for the terminal, to its serving SCC AS. In this case, masking is
applied to all
media flows composing every (originating and terminating) session (or all
sessions),
which is established by the specific terminal for the term of validity of the
setting. Ac-
cordingly, when another terminal sends a session discovery request message for
in-
formation related to the session which is being performed by the specific
terminal,
SCC AS serving the specific terminal does not provide the another terminal
with in-
formation related to the masked media flows (i.e., all of the media flows)
contained in
the session on the specific terminal.
[131] For use of the network interface (e.g., Ut), the masking flag(s) may
be transferred by
use of a message via a protocol such as XCAP, HTTP or the like.
[132] The masking flag with respect to the IUT discovery, as aforesaid, may
be pre-
configured in a terminal based on a user preference and/or an operator policy.
The
masking flag configured in the terminal may be modified by the user or
configured or
modified by interaction reflecting the user preference.
[133] 4) Fourth method is to set (configure) a masking flag(s) with respect
to IUT
discovery (i.e., mask from IUT discovery) for one or more of a specific
terminal and
one or more of a specific media type in subscriber or user information
(database,
profile).
[134] The subscriber information may also be defined as other terms, such
as a subscriber
configuration, a subscriber service configuration, a subscriber service
profile,
subscriber database and the like.
[135] The method of setting a masking flag(s) with respect to IUT discovery
in the
subscriber information may be categorized into i) setting it (them) for a
subscriber, ii)
setting it (them) for a specific terminal(s), iii) setting it (them) for a
specific media
type(s), and iv) setting it (them) for both a specific terminal(s) and a
specific media
type(s).
[136] First, if a masking flag(s) is(are) set for a subscriber, masking is
applied to all media
flows composing every (originating and terminating) session (or all sessions),
which is
established by the terminal belonging to the subscriber. Accordingly, when
another
terminal sends a session discovery request message for information related to
the
session on the terminal belonging to the subscriber, SCC AS serving the
terminal does
not provide another terminal with information related to all of media flows in
the
session on the terminal belonging to the subscriber.
[137] Second, if a masking flag(s) is(are) set for a specific terminal(s),
masking is applied
to all media flows composing every (originating and terminating) session (or
all
sessions), which is established by the specific terminal(s). Accordingly, when
another
terminal sends a session discovery request message for information related to
the
session being performed by the specific terminal, SCC AS serving the specific
terminal
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
17
does not provide another terminal with information related to all of media
flows in the
session being performed by the specific terminal.
[138] Thirdly, if a masking flag(s) is(are) set for a specific media
type(s), masking is
applied only to the media flows whose masking flag is set among all the media
flows
composing every (originating and terminating) session (or all sessions), which
is es-
tablished by every terminal belonging to the subscriber who has the masking
flag(s) in
subscriber information. Accordingly, when another terminal sends a session
discovery
request message for information related to the session being performed by the
terminal
belonging to the subscriber, SCC AS serving the terminal does not provide
information
related to the masked media flows in the session on the terminal.
[139] Lastly, if a masking flag(s) is(are) set for both a specific
terminal(s) and a specific
media type(s), masking is applied only to the media flows whose masking flag
is set
among all the media flows composing every (originating and terminating)
session (or
all sessions), which is established by the specific terminal(s). Accordingly,
when
another terminal sends a session discovery request message for information
related to
the session being performed by the specific terminal, SCC AS serving the
specific
terminal does not provide another terminal with information related to the
masked
media flows in the session on the specific terminal.
[140] In the description of the fourth method, it has been described that
the masking flag
with respect to IUT discovery is set to the subscriber information maintained
in a
subscriber information storage node such as a Home Subscriber Server (HSS);
however, it may alternatively be stored in the SCC AS other than in the
subscriber in-
formation storage node, or stored in another node (e.g., a dedicated database
for IUT)
within the home network so as to be acquired by the SCC AS.
[141] The masking flag(s) with respect to IUT discovery may be configured,
modified or
released in the subscriber information based on a user preference and/or an
operator
policy. However, the operator policy may be run (operated, maintained,
managed) in-
dependent of the subscriber information without being applied to the
subscriber in-
formation. In this case, the masking flag(s) with respect to IUT discovery may
be
managed in the subscriber information and in the operator policy, separately.
Ac-
cordingly, the SCC AS may perform masking based upon one or more of the two
separate settings (configurations) (i.e., setting in the subscriber
information and setting
in the operator policy). If the masking flag(s) with respect to IUT discovery
should be
applied based on both the subscriber information setting and the operator
policy
setting, several application (adaptation) rules, e.g., which setting of the
two has the
higher priority, how to combine and apply the two, may exist. For example,
when the
information related to the masking flag(s) with respect to IUT discovery is
not present
in the subscriber information but the masking flag(s) with respect to IUT
discover is
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
18
set for a specific media type in the operator policy, upon requesting for
information
related to sessions being performed by any terminal belonging to any
subscriber of the
operator, the SCC AS serving the terminal may not provide information related
to the
media flow(s) having the masking flag set, among all the media flows in the
sessions
being performed by the terminal.
[142] Also, setting (configuration), modification and release within the
subscriber in-
formation may be performed in an online or offline manner.
[143] For the operator policy, the masking flag(s) with respect to IUT
discovery may be set
for each subscriber, for a group of subscribers (e.g., for each charging plan
or for each
age), or for all subscribers same.
[144] The masking flag on IUT discovery having described so far may be
indicated with
ENABLE, SET, ON, 1 or the like.
[145] Hereinafter, description will be given of a case where when another
terminal requests
for discovering information related to a session being performed by a specific
terminal,
SCC AS, which serves the specific terminal (i.e., target terminal of
discovery) to be
discovered, performs masking to thereafter provide session information.
However,
unlike to this, SCC AS, which serves another terminal having requested for the
discovery, may receive un-masked session information and information related
to
masking flag(s) with respect to IUT discovery from the SCC AS serving the
specific
terminal to be discovered, perform masking by using the received information,
and
thereafter provide the requested information.
[146] For reference, even if a terminal sets a masking flag with respect to
IUT discovery
upon registration or session establishment, it does not mean that the terminal
cannot or
does not participate in the IUT operation.
[147] The media type described in the methods 1), 2), 3) and 4) presents
voice media,
video media, text media and etc. However, the media type is not limited to
voice, video
and the like. For example, the media type described in the methods 1), 2), 3)
and 4)
may be replaced with the media status such as active media, held media and
etc.
[148] Also, it has been described that the masking is performed for media
flows which
should not be discovered. However, on the contrary, unmasking may be performed
for
media flows to be discoverable. In this case, an unmasking flag(s) with
respect to IUT
discovery other than the masking flag(s) may be set, modified or released. For
example, for employing the method 4), if the unmasking flag(s) with respect to
IUT
discovery (i.e., unmask from IUT discovery) has been set in subscriber
information for
a specific terminal, only session information related to the terminal whose
unmasking
flag is set may be provided.
[149] Meanwhile, when masking information related to the session being
performed by the
specific terminal or a part of media flows in the ongoing session and
thereafter
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
19
providing the masked information, other supplementary information may also be
provided, and such information may also be masked or unmasked. Types of in-
formation to be masked or unmasked are listed but not to limited to as
follows.
[150] - session identifier
[151] - source UE identifier (e.g., GRUU or IMPU)
[152] - remote end identifier
[153] - identity of the controller UE for the related collaborative session
[154] - media type (voice, video, etc.)
[155] - media status (held, active, etc.)
[156] - media flow identifier
[157] - service identifier for the service the session is related to
[158] The masking or unmasking for such information (or called as field,
parameter, etc.),
which is included when providing information to a terminal performing a
session
discovery, may be performed separately from the masking or unmasking
information
related to the ongoing session or part of media flows composing the session
from
discovery by another terminal. Here, one or more of the aforesaid four methods
can be
used to mask or unmask for such supplementary information.
[159] The masking flag (i.e., mask from IUT discovery) mentioned above may
be referred
to as a filtering flag (i.e., filter from IUT discovery). The term 'masking'
and
'unmasking' may be replaced with 'filtering' and 'unfiltering', respectively.
[160] Hereinafter, detailed description thereof will be given with
reference to the ac-
companying drawings.
[161] FIG. 5 is an exemplary flowchart showing a method for masking
(filtering) in-
formation related to specific media flows in a session being performed by a
specific
terminal from being discovered (retrieved, found) by another terminal. FIG. 6
is an
exemplary flowchart showing a process that in a state where the information
related to
the specific media flows are masked (filtered) from discovery (retrieval) by
another
terminal according to FIG. 5, the another terminal requests for transfer of
media flows
except for the specific media flows.
[162] As shown in FIGS. 5 and 6, a user A has UE-1 110 and a user B has UE-
2 120.
However, this is merely illustrative, and the following description will not
be changed
even if it is assumed that the user A has both UE-1 and UE-2.
[163] Referring to FIGS. 5 and 6, a home network to which the users A and B
have
subscribed is shown. The home network may include IP Multimedia Subsystem
(IMS)
nodes 510 including S-CSCF, an SCC-AS-1 520a serving the UE-1 110, and an SCC
AS-2 520b serving the UE-2 120. Although not shown in detail in FIGS. 5 and 6,
the
same S-CSCF may serve both the UE-1 110 and the UE-2 120, or different S-CSCFs
may serve the UE-1 110 and the UE-2 (for example, S-CSCF-1 may serve the UE-1
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
belonging to the user A and S-CSCF-2 may serve the UE-2 belonging to the user
B).
[164] Although not shown in FIG. 5, it is assumed that the UE-1 110 of the
user A registers
in the home network, and the UE-2 120 also registers in the home network.
[165] Here, FIG. 5 exemplarily shows the method of setting a masking flag
with respect to
IUT discovery (i.e., mask from IUT discovery) through a session initiation
request
message, among the aforesaid methods. That is, when the UE-1 110 of the user A
sends a session initiation request message in order to establish a session
including
audio and video media with the remote end 300, the UE-1 110 enables the
masking
flag with respect to IUT discovery (i.e., mask from IUT discovery) for audio
media for
the SCC AS-1 520a not to provide information related to the audio media flow.
[166] Detailed description will be made with reference to FIG. 5.
[167] la¨lb) The user A desires to perform a session containing audio and
video media
with the remote end 300 via the UE-1 110. Hence, the UE-1 110 sends a session
initiation request message (e.g., SIP-based INVITE message) to the IMS nodes
510,
and the IMS nodes 510 then forward the session initiation request message to
the SCC
AS-1 520a based upon subscriber information on the user A. The session
initiation
request message may include information related to media composing the
session,
namely, information related to audio and video. The information related to the
media
may be included in a SDP body.
[168] Explaining an exemplary format included in the SDP body with
reference to
document RFC 4566, it will be described as follows.
[169] m=<media><port>knumber of ports><proto><fmt>
[170] For example, it may be written in a format of m=video 49170/2 RTP/AVP
31.
[171] As another example, the SDP format may be described as follows.
[172]
v=0
o=jdoe 2890844526 2890842807 IN 1P4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
[173] Also, in order to prevent the audio media flow among audio and video
media flows
composing the session to be established from being discovered by another
terminal, a
masking flag with respect to IUT discovery (i.e., mask from IUT discovery) for
the
audio media may be set (enabled) in the session initiation request message.
[174] 2) Upon receipt of the session initiation request message sent from
the UE-1 110, the
SCC AS-1 520a stores information related to the media, namely, information
related to
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
21
audio and video media, included in the session initiation request message, and
checks
whether there exists any masking flag with respect to IUT discovery which has
been
set. As such, the SCC AS-1 520a stores the masking flag with respect to IUT
discovery
enabled for the audio media.
[175] 3a-3b) The SCC AS-1 520a forwards the session initiation request
message to the
remote end 300 via the IMS nodes 510. Here, the masking information with
respect to
IUT discovery is needed only in the SCC AS-1 520a, so the masking flag is not
included in the session initiation request message forwarded to the remote end
300.
[176] 4a-4b) Upon receipt of the session initiation request message, the
remote end 300
sends a session initiation accept message (e.g., SIP-based 200 OK) to the SCC
AS-1
520a via the IMS nodes 510.
[177] 5a-5b) The SCC AS-1 520a then forwards the session initiation accept
message sent
by the remote end 300 to the UE-1 110 via the IMS nodes 510. Here, the SCC AS-
1
520a may include in the session initiation accept message a flag for
indicating whether
it is capable of supporting a masking flag with respect to IUT discovery for
the audio
media included in the session initiation request message sent by the UE-1 110,
for
example, a masking flag with respect to IUT discovery. Alternatively, the SCC
AS-1
520a may send the session initiation accept message by disabling the masking
flag
with respect to IUT discovery only when it is not capable of supporting the
masking
flag with respect to IUT discovery in the session initiation request message.
In this
case, if the SCC AS-1 520a can support the masking flag with respect to IUT
discovery, the session initiation accept message may be sent without any flag
related to
masking information.
[178] In the meantime, upon receiving the session initiation accept
message, a session
containing audio and video media is established between the UE-1 110 and the
remote
end 300. Here, the SCC AS-1 520a serving the UE-1 110 maintains information
related
to the session established between the UE-1 110 and the remote end 300. The
maintained information may include one or more of session identifier, source
UE
identifier (e.g., GRUU or IMPU), remote end identifier, media type (voice,
video, etc.),
media status (held, active, etc.), media flow identifier, service identifier
for the service
the session is related to. Other various information as well as those
information may
also be maintained by the SCC AS-1 520a.
[179] 6a-6b) In order to perform the IUT operation according to the
instruction of the user
B, the UE-2 120 sends a session discovery request message, (e.g., SIP-based
SUBSCRIBE message) for discovering the session being performed by the UE-1
110,
to the SCC AS-2 520b via the IMS nodes 510. The session discovery request
message
may include information related to the UE-1 to be discovered.
[180] 7a-7b) The SCC AS-2 520b forwards the session discovery request
message to the
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
22
SCC AS-1 520a serving the UE-1 110 via the IMS nodes 510.
[181] 8) The SCC AS-1 520a checks whether the UE-2 120 has a right to (is
allowed to, is
permitted to) discover information related to the session being performed by
the UE-1
110. The checking may be performed based upon subscriber information. The SCC
AS-1 520a checks which kind of media flows are contained in the ongoing
session on
the UE-1 110 based upon the previously stored session information. The SCC AS-
1
520a decides media flows, which should not be discovered (i.e., should be
masked),
among all of the media flows in the ongoing session on the UE-1 110, based
upon the
previously stored information related to the masking from IUT discovery. The
SCC
AS-1 520a then generates a session discovery response message (e.g., SIP-based
NOTIFY message) based upon the decision for masking. Here, the SCC AS-1 520a
masks or filters the information related to the decided media flows among all
the media
flows contained in the session on UE-1 110 and does not include the masked or
filtered
information in the session discovery response message. In other words, the SCC
AS-1
520a includes information related only to the rest of media flow(s) except for
the
masked or filtered media flow(s) among all the media flows in the session on
UE-1
110, in the session discovery response message. In FIG. 5, the discovery
response
message includes, for example, information related only to video media flow
among
the media flows in the ongoing session on the UE-1 110, without information
related to
audio media flow.
[182] 9a-9b) The SCC AS-1 520a then sends the session discovery response
message to
the SCC AS-2 520b via the IMS nodes 510.
[183] 10a-10b) The SCC AS-2 520b forwards the session discovery response
message to
the UE-2 120 via the IMS nodes 510.
[184] 11) Meanwhile, referring to FIG. 6, after receipt of the session
discovery response
message, the UE-2 120 decides to take the video media flow from the UE-1 110
based
upon the discovery result, namely, the information related to the video media
flow,
included in the session discovery response message.
[185] 12a-12b) In order to take the video media flow from the UE-1 110, the
UE-2 120
sends a transfer request message, e.g., Media Transfer Request message (e.g.,
SIP-
based REFER message) to the SCC AS-2 520b via the IMS nodes 510. Also, the
transfer request message includes a parameter indicating a source terminal,
e.g., Source
UE parameter. Also, the transfer request message includes a parameter
indicating a
target terminal, e.g., Target UE parameter. The transfer request message also
includes
a parameter indicating media to be transferred, e.g., Media parameter.
Besides, the
transfer request message may further include various parameters needed for the
media
transfer. The transfer request message may further include a parameter
indicating that
the control for a Collaborative Session which the UE-1 110 and the UE-2 120
will par-
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
23
ticipate in, is kept in the UE-1 110 (i.e., a parameter indicating that the UE-
2 120 does
not want to take the control for the Collaborative Session), e.g.,
Collaborative Session
Control parameter. If the transfer request message does not include the
parameter for
the control, e.g., Collaborative Session Control parameter, it may be
conceived that the
UE-2 120 does not want to take the Collaborative Session Control. This
embodiment
illustrates that the UE-2 does not take the control for the Collaborative
Session to be
established. However, if the UE-2 120 wants to take the Collaborative Session
Control,
a parameter for indicating the transfer of the control may be included in the
transfer
request message. Also, the transfer of the Collaborative Session Control may
be
performed separately from the transfer of the media flows, as shown in FIG.
1(b).
[186] 13) Upon receipt of the transfer request message, the SCC AS-2 520b
authorizes or
verifies the transfer request message. The authorization or verification may
be
performed based upon subscriber information. The authorization or verification
may be
performed to check whether the UE-2 120 is allowed for the IUT operation or is
capable of the IUT operation. In addition, the authorization or verification
may be
performed to check whether the media flows in the session on the UE-1 110 can
be
transferred to the UE-2 120. If information related to the authorization for
the IUT
operation is not present in the subscriber information or SCC AS serving a
target UE
of the IUT operation does not need the authorization or verification, the step
13 may
not be performed.
[187] 14a-14b) After the authorization or verification, the SCC AS-2 520b
checks the in-
formation included in the transfer request message, and then forwards the
transfer
request message via the IMS nodes 510 to the SCC AS-1 520a serving the UE-1
110 as
a source UE of the session, to which the video media requested to be
transferred
belongs.
[188] 15a-15b) Upon receipt of the transfer request message, the SCC AS-1
520a checks
the information included in the transfer request message. If it is checked
that the
session, to which the video media requested to be transferred belong, is the
session on
the UE-1 110, the SCC AS-1 520a forwards the transfer request message to the
UE-1
110 via the IMS nodes 510.
[189] 16) The UE-1 110 then authorizes or verifies the transfer request
message sent by the
UE-2 120. The authorization or verification may be performed through
interaction with
the user, or based upon information pre-configured in the UE-1 110 without
interaction
with the user. The authorization or verification may be performed additionally
or alter-
natively by the SCC AS-1 520a based upon subscriber information. In other
words, the
UE-1 110 may perform the authorization or verification, or the SCC AS-1 520a
may
perform it based upon setting in subscriber information. Alternatively, both
the UE-1
110 and the SCC AS-1 520a may perform it.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
24
[190] 17a-17b) Upon accepting the transfer request for the video media
flow, the UE-1
110 sends a transfer request accept message to the SCC AS-1 520a via the IMS
nodes
510.
[191] 18) As the UE-1 110 accepts the transfer of the video media flow to
the UE-2 120,
the SCC AS-1 520a completes the transfer of the video media flow from the UE-1
110
to the UE-2 120.
[192] Thusly, as the video media flow is transferred from the UE-1 110 to
the UE-2 120, a
Collaborative Session in which both the UE-1 110 and the UE-2 120 take part,
is es-
tablished. Even after transferring the video media flow to the UE-2 120, the
UE-1 110
has the control for the Collaborative Session containing the audio media on
itself and
the video media on the UE-2 120. That is, the UE-1 110 becomes a Controller
UE, and
the UE-2 120 becomes a Controllee UE.
[193] FIG. 7 is an exemplary flowchart showing another method for masking
(filtering) in-
formation related to specific media flows in a session being performed by a
specific
terminal from being discovered by another terminal;
[194] FIG. 8 is an exemplary flowchart showing a process that in a state
where the in-
formation related to the specific media flows are masked (filtered) from
discovery
(retrieval) by another terminal according to FIG. 7, the another terminal
requests for
transfer of media flows except for the specific media flows.
[195] Referring to FIGS. 7 and 8, UE-1 110 belongs to a user A, UE-2 120
belongs to a
user B, and UE-3 130 belongs to a user C. FIGS. 7 and 8 also show a home
network to
which the users A, B and C have subscribed. The home network may include IP
Multimedia Subsystem (IMS) nodes 510 including S-CSCF, an SCC-AS-1 520a
serving the UE-1 110, and an SCC AS-2 520b serving the UE-2 120 and the UE-3
130.
For the S-CSCF, although not shown in detail in FIGS. 7 and 8, the same S-CSCF
may
serve UE-1, UE-2 and UE-3, or different S-CSCFs may serve UE-1, UE-2 and UE-3
(for example, S-CSCF-1 may serve the UE-1 110 belonging to the user A, S-CSCF-
2
may serve the UE-2 120 belonging to the user B, and S-CSCF-3 serves the UE-3
130
belonging to the user C. As another example, S-CSCF-1 serves the UE-1 110
belonging to the user A and S-CSCF-2 serves the UE-2 120 belonging to the user
B
and the UE-3 130 belonging to the user C).
[196] FIG. 7 exemplarily shows the method of setting a masking flag with
respect to IUT
discovery (i.e., mask from IUT discovery) upon registration in the home
network,
among the aforesaid methods.
[197] Detailed description will be given as follows.
[198] 1) First, it is assumed that the UE-1 110 and the UE-3 130 have
already registered in
the home network, and the UE-1 110 is performing a session containing audio
and vide
media flows with the remote end 300.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
[199] Under this state, the UE-2 120 sends a registration request message,
e.g., REGISTER
message to the IMS nodes 510 to register in its home network. Here, the
registration
request message has a masking flag with respect to IUT discovery (i.e., mask
from IUT
discovery) enabled (set) for audio media.
[200] 2-3) The IMS nodes 510 then send an acknowledgement message in
response to the
registration message sent by the UE-2 120. The IMS nodes 510 then perform a
third-
party registration to the SCC AS-2 520b based upon subscriber information on
the user
B. Here, the registration message includes the masking flag with respect to
IUT
discovery (i.e., mask from IUT discovery) enabled for the audio media.
[201] 4) The SCC AS-2 520b then checks the registration message to find the
existence of
any masking flag with respect to IUT discovery enabled, and accordingly
decides that
the audio media contained in all the sessions established by the UE-2 120 for
the term
of validity of the registration should not be discovered by another terminals.
Then, the
SCC AS-2 520b maintains the masking-related information for the UE-2 120.
[202] 5) The SCC AS-2 520b sends an acknowledgement message to the IMS
nodes 510 in
response to the registration message. Here, the SCC AS-2 520b may include in
the ac-
knowledgement message a flag for indicating whether it is capable of
supporting a
masking flag with respect to IUT discovery (i.e., mask from IUT discovery) for
the
audio media. On the contrary, the SCC AS-2 520b may send the acknowledgement
message by disabling the masking flag with respect to IUT discovery only when
it
cannot support the masking flag with respect to IUT discovery included in the
reg-
istration message. In this case, if the SCC AS-2 520b can support the masking
flag
with respect to IUT discovery included in the registration message, the SCC AS-
2
520b may send the acknowledgement message without any flag related to masking
in-
formation. Upon receipt of the acknowledgement message, if it is checked
through the
acknowledgement message that the masking with respect to IUT discovery is not
supported, the IMS nodes 510 may notify it to the UE-2 120 immediately or
later (e.g.,
when the UE-2 initiates (originates) a session). Those operations are similar
to those in
the foregoing description, so a detailed description thereof will be omitted.
[203] 6) Meanwhile, the UE-1 110 decides to transfer audio and video media
flows to the
UE-2 120.
[204] 7a-7b) In order to transfer the audio and video media flows to the UE-
2 120, the UE-
1 110 then sends a transfer request message, e.g., Media Transfer Request
message
(e.g., SIP-based REFER message) to the SCC AS-1 520a via the IMS nodes 510.
Here,
the transfer request message includes a parameter indicating a source
terminal, e.g.,
Source UE parameter. Also, the transfer request message include a parameter in-
dicating a target terminal, e.g., Target UE parameter. The transfer request
message
includes a parameter indicating media to be transferred, e.g., Media
parameter.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
26
Besides, the transfer request message may further include various parameters
needed
for the media transfer. The transfer request message may further include a
parameter
indicating that the control for a Collaborative Session which the UE-1 110 and
the UE-
2 120 will participate in, is kept in the UE-1 110 (i.e., a parameter
indicating that the
UE-2 120 does not want to take the control for the Collaborative Session),
e.g., Col-
laborative Session Control parameter. If the transfer request message does not
include
the parameter for the control, e.g., Collaborative Session Control parameter,
it is
assumed that the Collaborative Session Control is not transferred to the UE-2
120.
[205] 8) The SCC AS-1 520a then authorizes or verifies the transfer request
message sent
by the UE-1 110. The authorization or verification may be performed based upon
subscriber information. The authorization or verification may be performed to
check
whether the UE-1 110 is allowed to perform the IUT operation or is capable of
the IUT
operation. In addition, the authorization or verification may be performed to
check
whether the media flows in the session on the UE-1 110 can be transferred to
the UE-2
120.
[206] 9a-9b) The SCC AS-1 520a then forwards the transfer request message
to the SCC
AS-2 520b via the IMS nodes 510.
[207] 10) The SCC AS-2 520b authorizes or verifies the transfer request
message. The au-
thorization or verification may be performed based upon subscriber
information, which
is similar to the aforesaid description, so a detailed description thereof
will be omitted.
[208] 1la-11b) The SCC AS-2 520b sends a session initiation request message
(e.g., SIP-
based INVITE message) including information related to audio and video media
flows
requested to be transferred to the UE-2 120 via the IMS nodes 510, based upon
the
transfer request message. The session initiation request message may include
contents
as shown in Table 1.
[209] 12a-12b) The UE-2 120 sends an accept message in response to the
session initiation
request message to the SCC AS-2 520b via the IMS nodes 510.
[210] 13a-13b) The SCC AS-2 520b forwards the session initiation accept
message to the
SCC AS-1 520a via the IMS nodes 510.
[211] 14) Accordingly, the SCC AS-1 520a completes the transfer of the
audio and video
media flows from the UE-1 110 to the UE-2 120 based upon the session
initiation
accept message. Here, even after transferring the audio and video media flows
to the
UE-2 120, the control for the media flows still belongs to the UE-1 110. That
is, a Col-
laborative Session is established in which the UE-1 110 and the UE-2 120 are
involved, and the UE-1 becomes a Controller UE while the UE-2 becomes a
Controllee
UE.
[212] Meanwhile, the SCC AS-1 520a serving the UE-1 110 maintains
information related
to the Collaborative Session in which the UE-1 110 and the UE-2 120 take part.
Here,
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
27
the maintained information may include one or more of session identifier,
source UE
identifier (e.g., GRUU or IMPU), remote end identifier, Controller UE
identifier of the
Collaborative Session, media type (e.g., voice, video, etc.), media status
(e.g., held,
active, etc.), media flow identifier, source UE identifier for media on a
local end, and
service identifier for the service the session is related to. Further, other
various in-
formation as well as those information may also be maintained by the SCC AS-1
520a.
[213] Similarly, the SCC AS-2 520b serving the UE-2 120 also maintains
information
related to the Collaborative Session in which the UE-1 110 and the UE-2 120
take part,
which will be understood as the same as being described above.
[214] The detailed description will be continued as follows with reference
to FIG. 8.
[215] 15a-15b) In order to perform the IUT operation, the UE-3 130 first
sends a session
discovery request message, e.g., Session Discovery Request message (e.g., SIP-
based
SUBSCRIBE message), to the SCC AS-2 520b via the IMS nodes 510 to discover in-
formation related to the ongoing session of the terminal belonging to the user
B.
[216] 16) The SCC AS-2 checks whether the UE-3 130 has a right to (is
allowed to, is
permitted to) discover information related to the session being performed by
the UE-2
120. The checking may be performed based upon subscriber information. The SCC
AS-2 520b then checks which kind of media flows are contained in the ongoing
session on the UE-2 120 based upon the previously stored session information.
The
SCC AS-2 520b then decides media flows, which should not be discovered (i.e.,
should be masked), among all of the media flows in the ongoing session on the
UE-2
120, based upon the previously stored information related to the masking from
IUT
discovery. The SCC AS-2 520b generates a session discovery response message
(e.g.,
SIP-based NOTIFY message), based upon the decision for masking. Here, the SCC
AS-2 520b masks or filters the information related to the decided media flows
among
all the media flows contained in the session on UE-2 120 and does not include
the
masked or filtered information in the session discovery response message. In
other
words, the SCC AS-2 520b includes in the session discovery response message in-
formation related only to the rest of media flows except for the masked or
filtered
media flows among the media flows in the session on UE-2 120. That is, since
the
audio media flow in the session being performed by the UE-2 120 should not be
discovered by other terminals, the audio media flow is masked or filtered. Ac-
cordingly, only information related to the video media flow is included in the
session
discovery response message, without information related to the audio media
flow.
[217] 17a-17b) Afterwards, the SCC AS-2 520b sends the session discovery
response
message to the UE-3 130 via the IMS nodes 510.
[218] 18) The UE-3 130 checks the session discovery response message and
decides to
take the video media flow from the UE-2 120 based upon the discovery result.
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
28
[219] 19a-19b) In order to take the video media flow from the UE-2 120, the
UE-3 130
sends a transfer request message, e.g., Media Transfer Request message (e.g.,
SIP-
based REFER message) to the SCC AS-2 520b via the IMS nodes 510. Here, the
transfer request message may include the aforesaid parameters needed for the
media
transfer.
[220] 20) Upon receipt of the transfer request message from the UE-3 130,
the SCC AS-2
520b authorizes or verifies the transfer request message, which will similarly
be un-
derstood by the foregoing description, so a detailed description thereof will
not be
repeated.
[221] 21a-21b) The SCC AS-2 520b forwards the transfer request message to
the SCC AS-
1 520a, which serves the UE-1 110 as a Controller UE of the Collaborative
Session to
which the transfer-requested video media flow belongs. To this end, upon
receipt of
the transfer request message, the SCC AS-2 520b checks whether the session to
which
the transfer-requested video media flow belongs is a Collaborative Session.
Here,
whether the session to which the transfer-requested video media flow belongs
is a Col-
laborative Session may be determined based upon a parameter which is included
in the
received transfer request message to explicitly indicate a Collaborative
Session or non-
Collaborative Session (i.e., an indicator indicating that the session is a
Collaborative
Session, or information related to the Controller UE for the session, etc.).
Alter-
natively, it may be determined based upon information related to the
corresponding
session maintained by the SCC AS-2 520b, by using another parameter (e.g.,
session
identifier) included in the transfer request message. Also, the information
related to the
Controller UE may be included in the transfer request message or obtained
based upon
information related to the corresponding session maintained by the SCC AS-2
520b ,
by using another parameter (e.g., session identifier) included in the transfer
request
message.
[222] 22a-22b) Upon receipt of the transfer request message, the SCC AS-1
520a checks
whether the session, to which the transfer-requested video media flow belongs,
is a
Collaborative Session. If the session is a Collaborative Session, the SCC AS-1
520a
forwards the transfer request message to the UE-1 110 as the Controller UE of
the Col-
laborative Session. Here, whether the session to which the transfer-requested
video
media flow belongs is a Collaborative Session may be determined based upon a
parameter which is included in the received transfer request message to
explicitly
indicate a Collaborative Session or non-Collaborative Session (i.e., an
indicator in-
dicating that the session is a Collaborative Session, or information related
to the
Controller UE for the session, etc.). Alternatively, it may be determined
based upon in-
formation related to the corresponding session maintained by the SCC AS-1
520a, by
using another parameter (e.g., session identifier) included in the transfer
request
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
29
message. Also, the information related to the Controller UE may be included in
the
transfer request message or obtained based upon information related to the
corre-
sponding session maintained by the SCC AS-1 520a, by using another parameter
(e.g.,
session identifier) included in the transfer request message.
[223] 23) The UE-1 110 then authorizes or verifies the transfer request
message sent by the
UE-3 130. The authorization or verification may be performed through
interaction with
the user, or based upon information pre-configured in the UE-1 110 without
interaction
with the user, which will similarly be understood by the foregoing
description, so a
detailed description will be omitted.
[224] 24a-24b) The UE-1 110 then sends a request accept message to the SCC
AS-1 520a
via the IMS nodes 510 in response to the transfer request message.
[225] 25) As the UE-1 110 accepts the transfer of the video media flow from
the UE-2 120
to the UE-3 130, the SCC AS-1 520a completes the transfer of the video media
flow
from the UE-2 120 to the UE-3 130.
[226] 26a-26b) The SCC AS-1 520a then sends a transfer complete message,
e.g., Media
Transfer Complete message to the UE-1 110 as the Controller UE via the IMS
nodes
510.
[227] Through those processes, as the video media flow is transferred from
the UE-2 120
to the UE-3 130, the UE-3 130 joins the Collaborative Session in which the UE-
1 110
and the UE-2 120 have been involved. Even after the transfer of the video
media flow
to the UE-3 130, the UE-1 110 has the control for the Collaborative Session
containing
the audio media flow on the UE-2 120 and the video media flow on the UE-3 130.
That
is, the UE-1 110 keeps acting as a Controller UE and the UE-3 130 becomes a
Controllee UE. The UE-2 120 keeps acting as a Controllee UE.
[228] FIG. 9 is a flowchart briefly showing the method according to the
present disclosure.
[229] As show in FIG. 9, upon receiving from a second terminal a session
discovery
request message for information related to the session(s), which is being
performed
between at least one first terminal and a remote end (S101), it is checked
whether the
second terminal is permitted (allowed) to discover information related to the
session(s)
on the first terminal (S103). If permitted, based up the stored information
related to the
session(s) on the first terminal it is checked which kind of media flows are
contained in
the session on the first terminal (S105). It is then decided which media
flow(s) among
all the media flows in the session on the first terminal should be masked or
filtered,
based upon the stored information related to the masking from IUT discovery,
configured for the first terminal (S107). If there exists the media flow(s)
which should
be masked or filtered, a session discovery response message including
information
related only to the rest of one or more media flow(s) except for the masked or
filtered
media flow(s) among all the media flows in the session on the first terminal
is
CA 02774429 2012-03-16
WO 2011/056034 PCT/KR2010/007849
generated and sent to the second terminal (S109).
[230] Afterwards, a transfer request message for a specific media flow(s)
among the rest of
one or more media flows is received from the second terminal (S111). Whether
or not
the session containing the media flow(s) requested to be transferred is a
Collaborative
Session is checked (S113), and if so, the transfer request message is
forwarded to a
controller terminal having a Collaborative Session Control (S115). However, if
not, the
transfer request message is forwarded to the first terminal (S117).
[231] In regard of those processes of FIGS. 4, 5 and 8, namely, the
transmission of the
session discovery request message (steps 9a-10b of FIG. 4, steps 6a-7b of FIG.
5 and
steps 15a-15b of FIG. 8), and the transmission of the session discovery
response
message (steps 1 1 a-12b of FIG. 4, steps 9a-10b of FIG. 5, and steps 17a-17b
of FIG.
8), instead of the aforesaid method that the terminal sends the session
discovery
request message to the SCC AS and in response the SCC AS sends the session
discovery response message containing session information to the terminal, a
method
may be employed such that when the terminal sends the session discovery
request
message to the SCC AS, the SCC AS first sends an acknowledgement message
(e.g.,
SIP-based 200 OK) to the terminal to notify the successful reception of the
session
discovery request message and then sends the session discovery response
message
containing the session information to the terminal, accordingly, the terminal
sends an
acknowledgement message (e.g., SIP-based 200 OK) to the SCC AS to notify the
successful reception of the session discovery response message.
[232] For a plurality of sessions being performed by one terminal, SCC AS
performs
masking from IUT discovery for all the sessions being performed by the
terminal.
[233] Also, as a result of masking from IUT discovery performed by SCC AS,
it may
happen that all the media flows contained in the session being performed by
the
terminal, which is a target for session information discovery, are masked. In
this case,
the SCC AS may not include information related to the session in the session
discovery
response message (i.e., masking the session itself), or include only
information related
to the existence of the session without information related to the masked
media flows.
[234] In FIGS. 5, 8 and 9, as described above, masking from IUT discovery
is performed
by SCC AS prior to generating the session discovery response message in
response to
the session discovery request message sent by another terminal. However,
unlike to
this manner, as a certain terminal subscribes to a session information
announcement
service, masking from IUT discovery may be performed by SCC AS when sending a
session information announcement (notification) message to the subscribed
terminal.
For example, in case where the first terminal has subscribed to an
announcement
service for receiving session information related to the second terminal (or
every
terminal of the user having the second terminal) from a network periodically
or when
CA 02774429 2014-08-29
31
there is any change in information related to the session(s) being performed
by the second
terminal (or every terminal of the user having the second terminal) (e.g., in
case of the first
terminal subscribing to a dialog event packet through SIP-based SUBSCRIBE
message), the SCC
AS may perform masking for the session(s) on the second terminal (or on every
terminal of the
user having the second terminal) prior to sending a session information
announcement
(notification) message (e.g., SIP-based NOTIFY message) to the first terminal.
Here, as a result of
making from IUT discovery performed by SCC AS, it may happen that all the
media flows
contained in the session being performed by the terminal, whose session
information is to be
discovered, are masked. In this case, the SCC AS may not send a session
information
announcement (notification) message to the first terminal at all, or may send
a session information
announcement (notification) message including only information related to the
existence of the
session without information related to the masked media flows.
[235] In the exemplary flowcharts showed in FIGS. 5, 6, 7 and 8, other IUT
operations such as
media replication than media transfer may be applied.
[236] Meanwhile, the method according to this specification, as described
so far, can be
implemented by hardware or software, or any combination thereof. For example,
the method
according to the present invention may be stored in a storage medium (e.g., an
internal memory of
a mobile terminal, a flash memory, a hard disc, etc.). Alternatively, the
method according to the
present invention can be implemented as codes or command words within a
software program
capable of being executed by a processor (e.g., a microprocessor in a mobile
terminal).
[237] FIG. 10 is a block diagram of UE 100 and SCC AS 520.
[238] As shown in FIG. 10, the UE 100 may include a storage unit 101, a
controller 102 and a
transceiver 103. The SCC AS 520 may include a storage unit 521, a controller
522 and a
transceiver 523.
[239] The storage units 101, 521 may store those methods shown in FIGS. 4
to 9.
[240] The controllers 102, 522 may control the storage units 101, 521 and
the transceiver 103, 523.
Especially, the controller 102, 522 may execute the methods stored in the
storage units 101, 521,
respectively. The controllers 102, 522 may send those aforesaid signals via
the transceivers 103,
523, respectively.
[241] The present invention has been explained with reference to the
embodiments which are merely
exemplary. It will be apparent to those skilled in the art that various
modifications and equivalent
other embodiments can be made. Also, it will be understood that the present
invention can be
CA 02774429 2014-08-29
32
implemented by selectively combining the aforementioned embodiment(s) entirely
or partially.
Thus, it is intended that the present invention cover modifications and
variations of this invention
provided they come within the scope of the appended claims and their
equivalents.
