U.S. patent application number 14/678649 was filed with the patent office on 2015-07-30 for method and apparatus for providing video on demand.
The applicant listed for this patent is Cisco Technology, Inc.. Invention is credited to John Ellis, Michel Khouderchah, Chandrasekar Krishnamurthy, Jan Medved.
Application Number | 20150215680 14/678649 |
Document ID | / |
Family ID | 37983406 |
Filed Date | 2015-07-30 |
United States Patent
Application |
20150215680 |
Kind Code |
A1 |
Khouderchah; Michel ; et
al. |
July 30, 2015 |
METHOD AND APPARATUS FOR PROVIDING VIDEO ON DEMAND
Abstract
A session border controller for delivering content includes a
first port to communicate with a user using a first signaling
protocol, a second port to communicate with a content provider
using a second signaling protocol, and a processor coupled to the
first and second ports. The session border controller sends a
message to the content provider to begin delivery of a content
destined for the user. The session border controller receives a
first media stream including the content and content provider
information from the content provider. The session border
controller creates a second media stream that includes the content
without the content provider information, and delivers the second
media stream to the user.
Inventors: |
Khouderchah; Michel;
(Cupertino, CA) ; Krishnamurthy; Chandrasekar;
(Sunnyvale, CA) ; Ellis; John; (Pleasanton,
CA) ; Medved; Jan; (Pleasanton, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cisco Technology, Inc. |
San Jose |
CA |
US |
|
|
Family ID: |
37983406 |
Appl. No.: |
14/678649 |
Filed: |
April 3, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11378993 |
Mar 17, 2006 |
9026677 |
|
|
14678649 |
|
|
|
|
Current U.S.
Class: |
725/98 |
Current CPC
Class: |
H04N 21/47202 20130101;
H04N 21/64707 20130101; H04N 21/23109 20130101; H04N 7/167
20130101; H04N 21/6587 20130101; H04N 21/6581 20130101; H04N
21/6543 20130101; H04N 21/6377 20130101; H04N 7/17336 20130101;
H04N 21/234309 20130101; H04N 21/64715 20130101; H04N 21/2543
20130101; H04N 21/2347 20130101; H04N 21/2393 20130101; H04N
21/2387 20130101; H04N 21/2221 20130101; H04N 21/64784 20130101;
H04N 21/25891 20130101; H04N 21/6437 20130101; H04N 21/6582
20130101 |
International
Class: |
H04N 21/647 20060101
H04N021/647; H04N 21/6587 20060101 H04N021/6587; H04N 21/6437
20060101 H04N021/6437 |
Claims
1. A session border controller comprising: a first port to
communicate with a user; a second port to communicate with a
content provider; a processor coupled to the first port and to the
second port, the processor configured to: receive an authentication
message identifying the user; send a PLAY message to the content
provider to begin delivery of a content destined for the user,
receive a first media stream including the content and content
provider information from the content provider, create a second
media stream that includes the content without the content provider
information, and deliver the second media stream to the user.
2. The session border controller of claim 1, further comprising a
third port to communicate with a database server, wherein the
processor is further coupled to the third port and configured to:
receive a first selection message for the content from the user,
obtain a location for the content selected by the user from a
database server; send a second selection message for the content to
the content provider, receive a reply message from the content
provider in response to the second selection message indicating
that the content is ready, send an OK message to the user after
receiving the reply message, and receive an ACK message from the
user before sending the PLAY message to the content provider.
3. The session border controller of claim 1, wherein communications
over the first port use a session initiation protocol (SIP) and
communications over the second port use a real-time stream protocol
(RTSP).
4. The session border controller of claim 1, wherein the processor
is further configured to receive an encryption key from the content
provider and wherein creating the second media stream encrypts the
first media stream with the encryption key if the first port is
connected to an untrusted access network.
5. The session border controller of claim 1, wherein the processor
is further configured to maintain a state for the first port, the
state being used with messages from the user to create messages to
be sent to the content provider.
6. The session border controller of claim 1, wherein the processor
is further configured to select the content provider from a
plurality of content providers, each of which has the content, such
that the first media stream has a first format that is easiest to
transcode to a second format of the second media stream.
7. The session border controller of claim 1, wherein the processor
is further to create a detailed billing record including an
identifier of the content provider, a content type indicator, and
associated statistics.
8. The session border controller of claim 1, further comprising a
third port to communicate with a second user, wherein the processor
is further coupled to the third port and configured to: receive a
selection message for the content from the second user, and deliver
a second media stream to the second user.
9. The session border controller of claim 1, wherein the processor
is further configured to: obtain a location for the content from a
database server; send a selection message for the content to a
content provider; send an INVITE message to the user when the
content is ready to be delivered, and receive an OK message from
the user before sending the PLAY message to the content
provider.
10. A method for delivering content from a session border
controller to a user; the method comprising: sending a PLAY message
to the content provider to begin delivery of a content destined for
the user; receiving a first media stream including the content and
content provider information from the content provider; creating a
second media stream that includes the content without the content
provider information; and delivering the second media stream to the
user without content provider information.
11. The method of claim 10, further comprising: receiving a first
selection message for the content from the user; obtaining a
location for the content selected by the user from a database
server; sending a second selection message for the content to a
content provider; receiving a reply message from the content
provider in response to the second selection message indicating
that the content is ready; sending an OK message to the user after
receiving the reply message; and receiving an ACK message from the
user before sending the PLAY message to the content provider.
12. The method of claim 11, wherein messages are exchanged with the
user using real-time transport protocol (SIP) as a first signaling
protocol and messages are exchanged with the content provider using
real time stream protocol (RTSP) as a second signaling
protocol.
13. The method of claim 10, further comprising receiving an
encryption key from the content provider and wherein creating the
second media stream includes encrypting the first media stream with
the encryption key if the first port is connected to an untrusted
access network.
14. The method of claim 10, further comprising maintaining a state
for the first port, the state being used with messages from the
user for creating messages to be sent to the content provider.
15. The method of claim 10, further comprising selecting the
content provider from a plurality of content providers; each of
which has the content, such that the first media stream has a first
format that is easiest to transcode to a second format of the
second media stream.
16. The method of claim 10, further comprising creating a detailed
billing record including an identifier of the content provider, a
content type indicator, and associated statistics.
17. The method of claim 10, further comprising: receiving a third
selection message for the content from a second user; and
delivering the second media stream to the second user.
18. The method of claim 10, further comprising: obtaining a
location for the content from a database server; sending a
selection message for the content to a content provider; sending an
INVITE message to the user when the content is ready to be
delivered; and receiving an OK message from the user before sending
the PLAY message to the content provider.
19. A session border controller comprising: means for sending a
PLAY message to the content provider to begin delivery of a content
destined for the user; means for receiving a first media stream
including the content and content provider information from the
content provider; means for creating a second media stream that
includes the content without the content provider information; and
means for delivering the second media stream to the user.
20. The session border controller of claim 19, further comprising:
means for receiving a first selection message for the content from
the user; means for obtaining a location for the content selected
by the user from a database server; means for sending a second
selection message for the content to a content provider; means for
receiving reply message from the content provider in response to
the second selection message indicating that the content is ready;
means for sending an OK message to the user after receiving the
reply message; and means for receiving an ACK message from the user
before sending the PLAY message to the content provider.
Description
RELATED APPLICATION
[0001] This application is a continuation application of U.S.
patent application Ser. No. 11/378,993, filed Mar. 17, 2006, which
is hereby incorporated by reference in its entirety.
FIELD
[0002] The present invention relates to systems and methods for
providing content to users over networks, and in particular to a
method and system for using a session border controller to
facilitate providing the content.
BACKGROUND
[0003] A session border controller (SBC) is a piece of network
equipment or a collection of functions that control real-time
session traffic at the signaling, call-control, and packet layers
as they cross a notional packet-to-packet network border between
networks or between network segments.
An SBC may consolidate interconnect points, provide and enforce QoS
metrics, interwork between protocols, and provide a more secure
connection for intersite calling. SBCs may address the inability of
real-time session traffic to cross network address translation
(NAT) device or firewall boundaries.
[0004] Multimedia content, such as video on demand (VOD) may be
requested and controlled using real-time stream protocol (RTSP) as
a signaling protocol. The content may be delivered using real-time
transport protocol (RTP), a protocol for the transport of real-time
data, such as audio and video. Some user may wish to use session
initiation protocol (SIP) as a signaling protocol to request and
control multimedia content that may be available from content
providers that use RTSP.
SUMMARY
[0005] A session border controller includes a first port to
communicate with a user using a first signaling protocol, a second
port to communicate with a content provider using a second
signaling protocol, and a controller. The controller may send a
PLAY message to the content provider to begin delivery of a content
destined for the user. The controller may further receive a first
media stream including the content arid content provider
information from the content provider. The controller may further
create a second media stream that includes the content without the
content provider information, and deliver the second media stream
to the user.
[0006] Other features and advantages of the present invention will
be apparent from the accompanying drawings and from the detailed
description that follows below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The present invention is illustrated by way of example and
not limitation in the figures of the accompanying drawings, in
which like references indicate similar elements and in which:
[0008] FIG. 1 is a diagram of a system that includes an embodiment
of the invention.
[0009] FIG. 2 is a block diagram of an embodiment of the
invention.
[0010] FIG. 3 is a diagram that illustrates a set of operations by
an embodiment of the invention.
[0011] FIG. 4 is a diagram that illustrates another set of
operations by an embodiment of the invention.
[0012] FIG. 5 is a flowchart for a method that embodies of the
invention.
[0013] FIG. 6 is a flowchart for another method that embodies of
the invention.
[0014] FIGS. 7 and 8 are flowcharts for other methods that embodies
of the invention.
DETAILED DESCRIPTION
[0015] FIG. 1 shows a multi-network system with a session border
controller (SBC) 100 to interconnect the networks 102-110. The
interconnected networks may be of any of a variety types as known
in the art.
[0016] Users may access the interconnected networks using various
types of terminal devices such as wired telephones 120-122,
wireless telephones and personal digital assistants 123, 124, and
personal computers 125. The terminal devices may include audio only
devices, video only devices, and audio/video devices of a variety
types as known in the art. Terminal devices may be connected by any
of a variety of means such as the Public Switched Telephone Network
(PSTN) 130, digital subscriber line (DSL), broadband cable,
Ethernet 132, cellular networks, general packet radio service
(GPRS), IP (internet protocol) Multimedia Subsystem (IMS) 134, and
WIMAX networks 136 using IEEE 802.16 wireless standards. An analog
telephone adapter (ATA) 138 may be used to interconnect an analog
terminal device to a digital connection. A voice over internet
protocol (VOIP) gateway 137 may be used to convert time division
multiplexed (TDM) traffic to VOIP. A wireless local area network
(LAN) access point 139 may be used to connect wireless terminal
devices. An aggregation router 140 may connect a number of the
networks 130-136 for the terminal devices 120-125 to a high speed
network 102 that is connected to the SBC 100.
[0017] The SBC 100 may be part of a service network 150 maintained
by a service provider. The SBC 100 may interconnect a variety of
servers that cooperate to provide service to users via their
terminal devices 120-125. The service network 150 may include
session initiation protocol (SIP) servers 152 that provide proxy,
registrar, redirect, and location database services. The service
network 150 may further include bandwidth manager servers 154 to
select and control the network resources to manage the traffic on
the network. The service network 150 may further include database
servers 156 that provide user service profiles and content
directories. The service network 150 may further include billing
servers 158 to collect billing records used to bill users for the
services provided by the service network.
[0018] One of the services provided by the service network 150 may
be providing multimedia content such as streaming audio and video,
audio and video on demand. The service network 150 may include
local content servers 160 that provide multimedia content
maintained by the service provider. The content servers may by
controlled using real-time stream protocol (RTSP) and multimedia
content may be delivered using real-time transport protocol
(RTP).
[0019] The service network 150 may provide access to additional
multimedia content acquired from content networks 170, 180, 190
that are maintained by content providers not under the control of
the service provider. These content networks may include
authentication, authorization, and accounting (AAA) servers 172,
182, 192 to control access to the content and accumulate charges
for the use of the content. These content networks may further
include content servers 174, 184, 194 that provide multimedia
content maintained by the content providers. Theses content
servers, like the local content server 160, may by controlled using
real-time stream protocol (RTSP) and multimedia content may be
delivered using real-time transport protocol (RTP).
[0020] The SBC 100 provides the interconnect between the content
servers 174, 184, 194 maintained by content providers and the
service network
150. Thus the SBC 100 is in a position to orchestrate delivery of
multimedia content from a content server 160, 174, 184, 194 to a
user terminal device 120-125.
[0021] As shown in FIG. 2, an SBC 100 may include two or more ports
204-207 that may be connected to two or more networks (102-110 as
shown in FIG. 1) and a processor 200 to transfer messages received
on one port to another port. A first port 204 may communicate with
a user
using a first signaling protocol. A second port 206 may communicate
with a content provider using a second signaling protocol. The
processor 200 may carry out various operations to modify the
messages received from a sender on one port as required by the
intended recipient before sending the message on another port to
the recipient. The SBC 100 may include a memory 202 coupled to the
processor 200. The memory 202 may be used by the processor to store
or buffer messages or portions thereof, state information derived
from processing activities, program instructions that control the
operation of the processor, and other data used to carry out the
operations of the processor.
[0022] As illustrated in FIG. 3, the SBC 100 may receive a first
selection message 300 for a content from the user 124. The first
selection message may be an instant-message that uses the session
initiation protocol (SIP). The SBC 100 may send a message to a
database server 156 with the user's content selection 302. The
database server 156 may provide the SBC 100 with a location for the
content selected by the user 304.
[0023] The SBC 100 may interact with the server of the content
provider 174 that has the content selected by the user 304. The SBC
100 may send a DESCRIBE request that includes the media filename to
the content provider 174 and receive an associated response. The
SBC 100 may send a second selection message for the content 306,
such as a SETUP request, to the content provider 174. The messages
between the SBC 100 and the content provider may be transmitted
using real-time stream protocol (RTSP). The SBC 100 may transcode
the first selection message and combine it with other information
such as the location for the content as provided by the database
server to generate the second selection message. The SBC 100 may
send a MESSAGE asking the user to wait 308 to indicate that the
content request has been received and is being processed.
[0024] The SBC 100 may maintain a state for the first port 204,
which is connected to the user. The state may be maintained in the
memory 202 of the SBC 100. The state may be used with the received
messages to generate the messages to be sent. Thus the SBC 100
provides stateful internetworking in which the transcoding may
depend both on the message received and a state determined by
preceding messages received or sent that relate to the first
port.
[0025] The SBC 100 may receive a reply message 310 from the content
provider 174 in response to the second selection message when the
requested content is ready to be transmitted. The SBC 100 may
transcode
this message and send an OK message to the user 312 after receiving
the ready indication in the reply message 310. The reply message
may include information that identifies the content provider or the
location of the content. Messages generated by the SBC 100 to be
sent to the user may hide information that would identify the
content provider, the location of the content, and/or that
interworking of signaling protocols is occurring. Hiding
information may make certain attacks on the content provider more
difficult to initiate. The state maintained by the-SBC 100 may
preserve information hidden from the users so that it may be used
to generate and send messages to the content provider on behalf of
the user.
[0026] The SBC 100 may receive an ACK message 314 from the user
when the user is prepared to receive the requested content. The SBC
100 may send a PLAY request 316 to the content provider 174 after
receiving the ACK message, to begin the delivery of the content.
The SBC 100 may further send a billing record 318 to a billing
server 158 to provide a record of the start of a request for
content. The content provider 174 may send a reply message for the
PLAY request 320 to the SBC 100 when the content is ready to be
delivered.
[0027] The SBC 100 may receive a first media stream 322 from the
content provider 174. The first media stream 322 may include the
content and content provider information. The SBC 100 may create a
second media stream 324 that includes the content without the
content provider information and deliver the second media stream to
the user 124.
[0028] The second media stream 324 may or may not use the same
format as the first media stream 322. If the second media stream
324 uses a different format than the first media stream 322, the
SBC 100 may transcode the first media stream from a first format to
a second format for the second media stream. The SBC 100 may select
the content provider from a plurality of content providers, each of
which has the requested content. The content provider may be chosen
by the SBC 100 according to a local policy such that the first
media stream provided by the content provider has a first format
that is easiest to transcode to the second format. Easiest to
transcode may mean that the transcoding take the least time to
transcode of the available formats or it may be judged as easiest
by another metric such as processing resources required. Selection
of content provider may also include selecting from a plurality of
content locations having different formats where the content
locations are controlled by the same content provider.
[0029] The SBC 100 may receive an encryption key for the requested
content from the content provider 174 and/or from a database server
156 that may provide local policy information on content
distribution. The SBC 100 may encrypt the first media stream 322
with the encryption key to create the second media stream 324 if
the first port 204 is connected to an untrusted access network 102.
If the first port is connected to a trusted access network, the SBC
100 may transmit the second media stream 324 in the clear and avoid
the overhead of using encrypted content when not required.
[0030] Some content may be provided by the content provider 174 in
an encrypted format. The SBC 100 may use the encryption key from
the content provider 174 to decrypt the content before transcoding
the first media stream 322 to create the second media stream 324.
The SBC may re-encrypt the second media stream 324 prior to
delivery to the user using either an encryption key provided by the
content provider 174 or an encryption key maintained by the network
service provider. Encryption keys maintained by the network service
provider may be provided to the SBC by a local server 156.
[0031] The user 124 may send one or more messages with playback
control requests 326 to the SBC 100. The SBC may transcode the
playback control requests 328 and send the request to the content
provider 174.
Playback control messages may provide for actions such as pause,
rewind, and fast forward. The content provider may provide an
acknowledgment of the playback control 330 to the SBC 100. The SBC
may or may not provide a transcoded acknowledgment to the user
124.
[0032] The user 124 may send a Bye message 332 or otherwise signal
a termination of the request for the content to the SBC 100. The
SBC 100 may then send a teardown message 334 to the content
provider 174. The SBC 100 may further send a billing record 336 to
a billing server 158 to provide a record of the end of the request
for content.
[0033] The SBC 100 may create one or more detail billing records
318, 336 in response to the transactions between the user 124 and
the content provider 174. A detail billing record may include an
identifier of the content provider, a content type indicator,
and/or associated statistics. The associated statistics may include
number of packets sent/received, jitter, and/or latency. The
associated statistics may be as measured by the SBC 100 and/or
captured from RTCP statistics generated by the endpoints. The SBC
may send detail billing records to a billing server 158. The detail
billing records created by the SBC 100 may be compared to reported
statistics provided by endpoints. The SBC 100 may include the
comparison information in the detail billing records sent to the
billing server 158.
[0034] Prior to accepting a selection message 300 for a content
from the user 124, the user may need to complete authentication,
authorization, and accounting (AAA) transactions before accessing
content through the service provider network 150. The user 124 may
initially send an INVITE message 338 to the SBC 100 signaling a
desire to access content. The SBC 100 may send a message 340 to a
database server 156 with the user's identifying information. The
SBC 100 may send a trying message 342 to indicate that the access
request has been received and is being processed.
[0035] The database server 156 may provide the SBC 100 with a menu
for content based on the user's profile 344. This may allow the SBC
100 to determine what format to use for messages to be delivered to
the user 124. For example, the user may have a profile that
indicates that the user's terminal device is audio only; the SBC
100 would then transcode messages to deliver than in a format
suitable for audio only presentation. The user 124 may send a
selection for content from the menu 300 to the SBC 100 which the
SBC obtains and delivers to the user as previously described.
[0036] As shown in FIG. 4, the SBC 100 may push content to a user
124 as an alternative to providing content in response to a user
request. The SBC 100 may push content that is unsolicited by the
user, such as content delivered at the request of the service
provider, a content provider, or a third party, or content that is
delivered in response to some user action other than an explicit
request for content.
[0037] To push content, the SBC 100 may begin by exchanging
messages 400, 402 with the database server 156 to locate the
content to be delivered to the user. The SBC 100 may send a SETUP
request 404 to the content server 160 acting as the content
provider requesting the content to be delivered to the user. The
content server 160 may send a reply message 406 for the SETUP
request to the SBC 100 indicating that the content is
available.
[0038] The SBC 100 may send an INVITE request 408 to the user 124
seeking permission to deliver the content. The user 124 may send a
trying message 410 to indicate that the INVITE request has been
received and is being processed.
[0039] If the user sends an OK message 412, the SBC 100 will
generate a PLAY request 416 and send it to the content server 160.
This will cause the content server 160 to begin the delivery of the
content. The content server 160 may send a reply message for the
PLAY request 418 to the SBC 100 when the content is ready to be
delivered. The SBC 100 may receive a first media stream 420 from
the content server. The first media stream may include the content
and content server information. The SBC 100 may create a second
media stream that includes the content without the content server
information and deliver the second media stream to the user.
Playback control and termination may be handled as previously
described for user selected content. Pushed content may use the
multicasting or broadcasting techniques described above.
[0040] FIG. 4 illustrates push content that is provided by the
network service provider 150 and delivered at no charge to the user
124. Therefore no detail billing records are generated. Push
content may make use of content from a content provider and detail
billing record may be generated by the SBC 100 for the purpose of
accounting for payments to the content provider. Push content may
be delivered with a charge to the user 124 or to a third party that
contracts with the network service provider to deliver the push
content. Detail billing records may be generated for the purpose of
accounting for payments to the network service provider for
delivery of the push content.
[0041] FIG. 5 illustrates a form of multicast broadcasting. A first
user 522 may select 500 broadcast content that is being delivered
in real-time. The first user 522 may complete authentication,
authorization, and accounting (AAA) transactions and make a
selection as previously described in connection with FIG. 3. The
SBC 100 may obtain and deliver the selected content to the first
user 522 using similar transactions as previously described in
connection with FIG. 3.
[0042] If a second user 524 selects 510 the same broadcast content
that is being delivered to the first user 522, the SBC 100 may
recognize the content selection 512 as one for content that is
already being received. The SBC 100 may bypass the steps of
obtaining the content location 506 and the first media stream with
the content 508 that were previously done to respond to the
selection 500 by the first user 522. The SBC 100 may respond
directly to the second user's select message 510 with an OK invite
message 514.
[0043] Upon receipt of the second user's ACK message 515 the SBC
100 may begin delivering the first media stream 508 as obtained for
the first user 522 as a third media stream 518 directed to the
second user 524. The SBC 100 may transcode the first media stream
508 to create the third media stream 518 in the format needed for
the second user 524. If the first and second users 522, 524 require
the same format for the media stream, the controller may send the
same media stream to both users without the need to transcode the
content for the second user. Multicasting can accommodate an
arbitrary number of users 526 who all receive the same broadcast
content 508. The third and subsequent users 526 are each handled in
the same way as the second user 524.
[0044] The SBC 100 may support playback control features such as
pause or rewind for content that is being delivered as a multicast
broadcast.
Support of playback control features may be only for selected
broadcast content. If a user is receiving content as a member of a
group of users receiving a multicast broadcast and then invokes a
playback control, the SBC 100 will remove that user from the
multicast group and request a separate content stream for that user
to allow the use of the playback controls. If the user later
returns to the real-time delivery of the broadcast content, the SBC
100 may rejoin the user with the multicast group. The SBC 100 may
generate additional billing records for the use of playback control
features. The multicast group will be maintained as long as any
user, not necessarily the first user, continues to receive the
broadcast content.
[0045] FIG. 6 is a flowchart of a method for delivering content
from a session border controller to a user. A PLAY message is sent
to a content provider to begin delivery of a content destined for
the user 602. A first media stream including the content and
content provider information is received from the content provider
604. A second media stream that includes the content without the
content provider information is created 606. An encryption key may
be received from the content provider and/or the local database
server 156. The encryption key may be used to encrypt the first
media stream to create the second media stream if the first port is
connected to an untrusted access network. The second media stream
is delivered to the user 608. Messages may be exchanged with the
user using real-time transport protocol (SIP) as a first signaling
protocol and with the content provider using real-time stream
protocol (RTSP) as a second signaling protocol. A state may be
maintained for the connection to the user, the state being used
with messages from the user for creating messages to be sent to the
content provider.
[0046] FIG. 7 is a flowchart of a method for initiating the
delivery of content from a session border controller to a user
based on a content selection by the user. A first selection message
for the content is received from the user 700. A message is sent to
a database server to obtain a location for the content selected by
the user 702. The location may be selected from a plurality of
locations such that the first media stream has a first format that
is easiest to transcode to a second format of the second media
stream.
[0047] A second selection message including a request for the
content is sent to a content provider 704. A reply to the content
request indicating "ready" is received from the content provider
706. An OK message is sent to the user after receiving the ready
message 708. An ACK message is received from the user 710
indicating that the user is ready to receive the selected content.
The content thus selected may be sent to the user using the method
shown in FIG. 6. The same content may be sent to a second user in
response to a third selection message for the content received from
the second user.
[0048] FIG. 8 is a flowchart of another method for initiating the
delivery of content from a session border controller to a user in
which the user does not initiate the delivery. A location for the
content is obtained from a database server 800. A selection message
for the content is sent to a content provider 802. An INVITE
message is sent to the user when the content is ready to be
delivered 804. An OK message is received from the user before
sending the PLAY message to the content provider 806. The content
thus selected may be sent to the user using the method shown in
FIG. 6. The same content may be sent to more than one user.
[0049] While certain exemplary embodiments have been described and
shown in the accompanying drawings, it is to be understood that
such embodiments are merely illustrative of and not restrictive on
the broad invention, and that this invention not be limited to the
specific constructions and arrangements shown and described, since
various other modifications may occur to those ordinarily skilled
in the art.
* * * * *