All Proposals - Table View

Proposal It is proposed to agree the following changes to 3GPP TR 26.836 v0.1.1.

Proposal It is proposed to agree the following changes to 3GPP TR 26.836 v0.1.1.

• • • First Change (all new) * * * *

A.3.3 Media delivery to multiple subscribers using Relay

This clause describes the delivery model where multiple subscribers subscribe to track(s) provided by an endpoint acting as an Original Publisher, using an endpoint acting as Relay. The Relay can cache objects of tracks.

Figure A.3.3-1 shows the model for media delivery to multiple subscribers using Relay.

Figure A.3.3-1. The model for media delivery to multiple subscribers using Relay

Figure A.3.32-2 shows the call flow for media delivery to multiple subscribers using Relay.

Figure A.3.3-2. The call flow for media delivery to multiple subscribers using Relay

NOTE: The gray boxes with dotted outlines indicate that the procedure is optional.

1. MOQT session is established between the endpoints as follows

2. Subscriber_1 and Relay

3. Subscriber_2 and Relay

4. Relay and Publisher

5. Publisher publishes namespace(s) provided by itself. Subscriber_1 and Subscrber_2 discovers publishers for a namespace using one of the methods described in step 1 of the call flow in clause A.3.2 subscribe to namespace(s) to receive the information of namespace(s).

6. To learn about the tracks being produced by the (MSF) publisher, Subscriber_1 sends a SUBSCRIBE message to Relay to request the catalog track of Publisher, if necessary.

7. The Relay sends a SUBSCRIBE message to establish the upstream subscription corresponding to the received SUBSCRIBE request, if Subscriber_1 is authorized to access the content.

8. The Publisher sends a SUBSCRIBE_OK message to the Relay, if the subscription request is accepted.

9. The Relay sends a SUBSCRIBE_OK message to Subscriber_1.

10. The Relay receives the catalog track from the Publisher. The Relay can be configured to caches the received objects data of catalog track.

11. Subscriber_1 receives the catalog track from the Relay.

8 – 13. Subscriber_1 selects a media track from the received catalog, and subscribes to the media track as same as the step 2-7 for catalog track. The Relay can be configured to also caches the received objects data of media track.

1. To subscribe to the catalog track of the Publisher, Subscriber_2 sends a SUBSCRIBE message to the Relay, if necessary.

2. The Relay sends a SUBSCRIBE_OK message to Subscriber_2, if Subscriber_21 is authorized to access the content. The Relay does not need to send SUBSCRIBE to the Publisher since there is the established upstream subscription corresponding to the received SUBSCRIBE message.

3. Subscriber_2 receives the catalog track from the Relay.

17-19. Subscriber_2 selects a media track from the received catalog (in this case, the media track is the same track of Subscriber_1) and subscribes to the media track as same as the step 14-16 for catalog track.

1. Subscriber_1 sends a STOP_SENDING frame on the related stream(s) to the Relay to terminate the subscription to the media track as soon as possible.

2. Subscriber_1 sends a STOP_SENDING frame on the related stream(s) to the Relay to terminate the subscription to the catalog track as soon as possible, if there are valid subscription on catalog track.

3. Subscriber_1 closes the bidirectional stream for SUBSCRIBE_NAMESPACE which is established at step 1 by sending FIN or RESET_STREAM frame, if Subscriber_1 is no longer interested in.

23-24. Subscriber_2 sends STOP_SENDING frames to the Relay as same as step 20-21 for Subscriber_1 to terminate the subscriptions (i.e., media and catalog).

1. Subscriber_2 closes the bidirectional stream for SUBSCRIBE_NAMESPACE which is established at step 1 by sending FIN or RESET_STREAM frame, if Subscriber_2 is no longer interested in.

26-27. Relay sends STOP_SENDING frames to the Publisher as same as step 20-21 for Subscriber_1 to terminate the subscriptions (i.e., media and catalog) since there is no subscriber which subscribes to these tracks.