Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

From: <[email-masked]>
Date: Mon, 15 Oct 2012 14:16:31 +0000

Hi all,

We propose the following use case

Anne & Emile

Use case for Request routing « footprint & capabilities »

Figure 1 shows the context of CDN interconnection used to illustrate the use case "footprint & capabilities". An example of the CDNI interface Request Routing/footprint&capabilities exchanges between CDN A and CDN B will be detailed.

I)              Use case assumptions:

CP demand example:

·         A given CP1 wishes to delegate the delivery of its content to CDNA. Most of CP1 client are from "France" but wants that client all over the world be also delivered through a CDN. Its contents are two types :

o    content delivers in HTTP

o    and content delivers in RTMP
CP1 describes its content as per class of request, footprint and capabilities parameters.
Example of CP1's "service" demand for the use case:
"Class of request":
"URI_class":
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>?url_signing="bb"&*
"footprint" :
geo = world"
"quality/capabilities":
               maxDeliveryStartLatency = 500

CDN interconnection negotiations phase:

CDN A capabilities compared to CP1 demand are the following:
"Class of request ":
"URI_class":
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>?url_signing="bb"&*
"footprint" :
Geo= "france"
"quality/capabilities" :
               maxDeliveryStartLatency = 500

CDN A capabilities are not enough compared to CP1 demand (limited to "footprint/geo= france). CDN A already has an agreement with a global CDN (CDN D) to deliver any content to "world" with url_signing="bb" ("service_ad" compatible with CP1 demand) but the price is very high.
Beside, CDN A operator is also aware that another CDN, CDN B, has the possibility to deliver content to "Europe" with a lower price than CDN D.

                1) CDN A notes the CP1 demand
2) CDN A contacts CDN B operator and demand CDN B capabilities compared to CP1 demand.
3) CDN B notes the CDN A demand and verify if it can manage the CDNA demand.

CDN B capabilities compared to CDN A demand:
"Class of request ":
"URI_class":
http://cdn.cp1.com/video/*? url_signing="bb"&*
"footprint" :
Geo= "Europe"
"quality/capabilities" :
maxDeliveryStartLatency = 500

CDN B owns capabilities are not enough compared to CDN A demand (limited to footprint/geo="europe" and protocol=HTTP).
But CDN B operator already has an agreement with CDN C to deliver any content in RTMP to "Europe":
"service_bc":
"Class of request ":
"URI_class":
rtmp://cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing="bb"&*
"footprint" :
Geo= "Europe"
"quality/capabilities" :
maxDeliveryStartLatency = 500
CDN B is able to satisfy the CDN A demand for "footprint/geo=Europe" when it delegates content delivered in RTMP to CDN C.

4) CDN B announces its capabilities to CDN A limited to "Europe"  compared to CDN A demand

"Class of request":
"URI_class":
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>?url_signing="bb"&*
"footprint":
Geo= "Europe"
"quality/capabilities" :
                maxDeliveryStartLatency = 500

5) CDN A is ok and an agreement is concluded between CDNA and CAN B operators for the following service:
"service_ab":
"Class of request ":
"URI_class":
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing="bb"&*
"footprint" :
Geo= "Europe"
"quality/capabilities" :
maxDeliveryStartLatency = 500

[ed.note] This CDN interconnection negotiation phase is out of scope of IETF CDNI WG. In this example, potential dCDN capabilities are known by uCDN thanks to "relationship" or already concluded agreement. One can imagine another way for the uCDN to know potential dCDN capabilities: potential dCDN capabilities automatic advertisement directly to all potential uCDN or through a "CDN capability portal" accessible to all CDNs.

II)            Use case:

                II-1) CDN A- CDN B Interconnection initialization phase

CDN A - CDN B interconnection initialization

Parameters needed to initialize CDNI interfaces between CDN A and CDN B (request Routing, metadata and logging) for the agreed "service" are exchanged via the control interface. These parameters will be used to configure CDN A and CDN B.
Among those, the following parameters are needed to initialize the Request Routing interface accordingly to the agreed "service_ab":

Service_id : "service_ab"
                               {
"Class of request ":
               {
"URI_class":
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing="bb"&*
"footprint" :
Geo= "Europe"
}
"quality/capabilities" :
maxDeliveryStartLatency = 500
}

CDN A - CDN B Request Routing/footprint&capabilities Notification

Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertizes CDN A (uCDN) with request routing information via the Request Routing/footprint and capabilities interface.

CDN A (dCDN) sends a Request Routing information notification to CDN B (uCDN). This notification includes the following parameters:
Service :
      {
          Service_id = service_ab
           Status = operational
     }

After CDN A has received this Request routing information notification, an example of its selection algorithm could be as following (as an example and for information only)

If the End-user request of content matches the class of request "*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing="bb"&*"
And
{
If  the IP source address belongs to the footprint/geo="France"
      then, the delivery of the requested content is done by the CDN A itself
      else {
if the IP source address belongs to the footprint/geo="Europe" then, the delivery of the requested content is delegated to CDN B (which will delegate it to CDN C if protocol = "RTMP")
else {

if the IP source address belongs to the footprint/geo="World" then, the delivery of the requested content is delegated to CDN D

                               }
        }

                II-2) Request routing information modification

A problem occurs on CDN C so that it is not able to deliver anymore content using RTMP.
CDN A must now selects CDN D for the delivery of CP1's content in RTMP for client other than in France.

Request Routing/footprint&capabilities Notifications

CDN C - CDN B Request Routing/footprint&capabilities Notification

CDN C will then send a request routing information notification to CDN B
This notification includes the following parameters:
Service :
      {
          Service_id = service_bc
           Status = not_operational
     }

CDN A - CDN B Request Routing/footprint&capabilities Notification

CDN B will then send a request routing information notification to CDN A
This notification includes the following parameters:
Service :
      {
          Service_id = service_ab
           Status = partially_operational
          Modified_parameters :
                                      {
Class of request/URI_class:
http//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing="bb"&*
}
     }

After CDN A has received this Request routing information notification, an example of its modified selection algorithm is presented (as an example and for information only)

If the End-user request of content matches the class of request "*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing="bb"&*"
and
{
If  the IP source address belongs to the footprint/geo="France"
      then, the delivery of the requested content is done by the CDN A itself
      else {
if the IP source address belongs to the footprint/geo="Europe" and the End-user request of content matches the class of request "http//*<http://cdn.cp1.com/video/*>?*&*"
then, the delivery of the requested content is delegated to CDN B else {

if the IP source address belongs to the footprint/geo="World" then, the delivery of the requested content is delegated to CDN D

                               }
        }

Anne MARREC
FT<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%0F%04D%0A%07q%10-%1D%19%1C%0C%17%3FY%27%0AM%01%0B%06%3E%14-%07%05%09%0C%00%29Y%27%0AM%0E%17%13%22%16%26%1D%15%04%00%11%23%18o%0D%13U%03%00>/ OLNC<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%06%1C%06%06%5E%23%00%7E%0F%04D%0A%07q%10-%1D%19%1C%0C%17%3FY%27%0AM%01%0B%06%3E%14-%07%05%09%0C%00%29Y%27%0AM%0E%17%13%22%16%26%1D%15%04%00%11%23%18o%0D%13U%03%00>/ OLN<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%06%1C%06I%1D9H%2C%05%1E%0BI%1D9H%25%1D%5C%07%10O%29%1B7%00%04%01%00%01%60%11+T%19%06%11%00-%1B-%1C%11%01%17%17%60%11+T%16%1A%04%1C%2F%107%0C%1C%0D%06%1D%21Y%27%0AM%0E%17>/ CNC<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%0A%1E%0BI%1D9H%2C%05%1ED%0A%07q%1A%2F%07%13D%0A%07q%137E%1F%1DX%17%22%01*%1D%19%0D%16%5E%28%16%7E%00%1E%1C%17%13%22%1B6%08%19%1A%00%5E%28%16%7E%0F%02%09%0B%11%29%01%26%05%15%0B%0A%1F%60%11+T%16%1A>/ IDA<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%00%14%09I%1D9H+%07%13D%0A%07q%1A%2F%07%5C%07%10O%23%19-%0A%5C%07%10O*%01o%06%05U%00%1C8%1C7%00%15%1BI%16%2FH*%07%04%1A%04%1C%22%00%22%00%02%0DI%16%2FH%25%1B%11%06%06%178%10%2F%0C%13%07%08%5E%28%16%7E%0F%02>/ CDS<http://one-directory.sso.francetelecom.fr/annuaire/entite.do?action=View&uid=%23%00%7E%0A%14%1BI%1D9H*%0D%11D%0A%07q%16-%0A%5C%07%10O%23%19-E%1F%1DX%1D+%1B+E%1F%1DX%148Y%2C%1CM%0D%0B%06%25%01*%0C%03D%01%11q%1C-%1D%02%09%0B%1C9%14*%1B%15D%01%11q%131%08%1E%0B%00%06%29%19%26%0A%1F%05I%16%2FH%25%1B>
tél. +33 2 96 05 18 71
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jan Seedorf <[email-masked]>
Date: Tue, 16 Oct 2012 13:25:47 +0000

Hi Anne and Emile,

Thanks for sharing this use case and the detailed examples. It is all clear to me, and I think good input to our discussions.

Two quick comments (we can discuss more in the call today):

-          According to your example, "capabilities_updates" must not only include "operational" or "non-operational", but probably "partially-operational" plus some specification what partially means;

-          What about the case where capabilities updates may contain a referral to a given footprint, as we have discussed, e.g. the "partially-operational" update from B to A shall indicate that B can only serve RTMP in some parts of Europe? Do you agree to this scenario and that it should be supported?

-          Jan

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 15, 2012 4:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

Hi all,

Anne & Emile

I)                    Use case assumptions:

CP demand example:

"Class of request":
"URI_class":

II)                 Use case:

                               }
        }

                               }
        }

Anne MARREC

Thank you.

---

From: <[email-masked]>
Date: Tue, 16 Oct 2012 14:00:00 +0000

De : Jan Seedorf [mailto:[email-masked]]
Envoyé : mardi 16 octobre 2012 15:26
À : MARREC Anne OLNC/OLN; [email-masked]
Cc : [email-masked]
Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

Hi Anne and Emile,

-          According to your example, "capabilities_updates" must not only include "operational" or "non-operational", but probably "partially-operational" plus some specification what partially means;
[AM] "partially_operationnel" means thet the "service" is not anymore supported by the dCDN as it was originally specified

-          What about the case where capabilities updates may contain a referral to a given footprint, as we have discussed, e.g. the "partially-operational" update from B to A shall indicate that B can only serve RTMP in some parts of Europe? Do you agree to this scenario and that it should be supported?
[AM] Yes, this scenario should be supported... more thinks are necessary to describe how the modified parameter have to be specified

-          Jan

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, October 15, 2012 4:17 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

Hi all,

Anne & Emile

I)              Use case assumptions:

CP demand example:

"Class of request":
"URI_class":

II)            Use case:

                               }
        }

                               }
        }

Anne MARREC

Thank you.

---

From: Songhaibin <[email-masked]>
Date: Wed, 17 Oct 2012 06:24:43 +0000

Excellent use case and discussion! And I think the negotiation phase should be in scope, which should not be left as a hole for CDNI.

-Haibin

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 16, 2012 10:00 PM
To: Jan Seedorf; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

Hi Anne and Emile,

-          Jan

Hi all,

Anne & Emile

I)                    Use case assumptions:

CP demand example:

"Class of request":
"URI_class":

II)                 Use case:

                               }
        }

                               }
        }

Anne MARREC

Thank you.

Thank you.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Oct 2012 23:39:14 +0100

Anne, Jan

On 16 Oct 2012, at 15:00, <[email-masked]> wrote:

> -          According to your example, “capabilities_updates” must not only include “operational” or “non-operational”, but probably “partially-operational” plus some specification what partially means;
> [AM] “partially_operationnel” means thet the “service” is not anymore supported by the dCDN as it was originally specified

Partially operational smells like a rat hole full of interoperability issues to me. Why can't the dCDN just advertise what it is now capable of doing and the uCDN can decide whether it still wishes to use the dCDN. 

The capability to advertise "this advertisement is different to the last one i gave you" via a "partially operatiobal" state adds no value IMO. 

> -          What about the case where capabilities updates may contain a referral to a given footprint, as we have discussed, e.g. the “partially-operational” update from B to A shall indicate that B can only serve RTMP in some parts of Europe? Do you agree to this scenario and that it should be supported?
> [AM] Yes, this scenario should be supported… more thinks are necessary to describe how the modified parameter have to be specified

Why not have the dCDN advertise the specific part of europe it can still support delivery to?

Ben
> Figure 1 shows the context of CDN interconnection used to illustrate the use case “footprint & capabilities”. An example of the CDNI interface Request Routing/footprint&capabilities exchanges between CDN A and CDN B will be detailed.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> I)              Use case assumptions:
>  
> CP demand example:
> ·         A given CP1 wishes to delegate the delivery of its content to CDNA. Most of CP1 client are from “France” but wants that client all over the world be also delivered through a CDN. Its contents are two types :
> Example of CP1’s “service” demand for the use case:
> “Class of request”:
> “URI_class”:
> *//cdn.cp1.com/video/*?url_signing=”bb”&*
> "footprint" :
> geo = world”
> “quality/capabilities”:
> “Class of request “:
> “URI_class”:
> *//cdn.cp1.com/video/*?url_signing=”bb”&*
> “footprint” :
> Geo= “france”
> “quality/capabilities” :
> CDN A capabilities are not enough compared to CP1 demand (limited to “footprint/geo= france). CDN A already has an agreement with a global CDN (CDN D) to deliver any content to “world” with url_signing=”bb” (“service_ad” compatible with CP1 demand) but the price is very high.
> Beside, CDN A operator is also aware that another CDN, CDN B, has the possibility to deliver content to “Europe” with a lower price than CDN D.
>  
> “Class of request “:
> “URI_class”:
> http://cdn.cp1.com/video/*? url_signing=”bb”&*
> “footprint” :
> Geo= “Europe”
> “quality/capabilities” :
> CDN B owns capabilities are not enough compared to CDN A demand (limited to footprint/geo=”europe” and protocol=HTTP).
> But CDN B operator already has an agreement with CDN C to deliver any content in RTMP to “Europe”:
> “service_bc”:
> “Class of request “:
> “URI_class”:
> rtmp://cdn.cp1.com/video/*? url_signing=”bb”&*
> “footprint” :
> Geo= “Europe”
> “quality/capabilities” : 
> CDN B is able to satisfy the CDN A demand for “footprint/geo=Europe” when it delegates content delivered in RTMP to CDN C.
>  
> 4) CDN B announces its capabilities to CDN A limited to “Europe”  compared to CDN A demand
>  
> “Class of request“:
> “URI_class”:
> *//cdn.cp1.com/video/*?url_signing=”bb”&*
> “footprint”:
> Geo= “Europe”
> “quality/capabilities” :
> “service_ab”:
> “Class of request “:
> “URI_class”:
> *//cdn.cp1.com/video/*? url_signing=”bb”&*
> “footprint” :
> Geo= “Europe”
> “quality/capabilities” : 
> [ed.note] This CDN interconnection negotiation phase is out of scope of IETF CDNI WG. In this example, potential dCDN capabilities are known by uCDN thanks to “relationship” or already concluded  agreement. One can imagine another way for the uCDN to know potential dCDN capabilities: potential dCDN capabilities automatic advertisement directly to all potential uCDN or through a “CDN capability portal” accessible to all CDNs.
>  
>  
> II)            Use case:
>  
> Parameters needed to initialize CDNI interfaces between CDN A and CDN B (request Routing, metadata and logging) for the agreed “service” are exchanged via the control interface. These parameters will be used to configure CDN A and CDN B.
> Among those, the following parameters are needed to initialize the Request Routing interface accordingly to the agreed “service_ab”:
>  
> Service_id : “service_ab”
>                                {
> “Class of request “:
>                {
> “URI_class”:
> *//cdn.cp1.com/video/*? url_signing=”bb”&*
> “footprint” :
> Geo= “Europe”
> }
> “quality/capabilities” : 
> If the End-user request of content matches the class of request “*//cdn.cp1.com/video/*? url_signing=”bb”&*”
> And
> {
> If  the IP source address belongs to the footprint/geo=”France”
> if the IP source address belongs to the footprint/geo=”Europe” then, the delivery of the requested content is delegated to CDN B (which will delegate it to CDN C if protocol = “RTMP”)
> else {
>  
> if the IP source address belongs to the footprint/geo=”World” then, the delivery of the requested content is delegated to CDN D
>  
>                                }
>         }
>  
> CDN A must now selects CDN D for the delivery of CP1’s content in RTMP for client other than in France.
>  
> _______________________________________________
> cdni-footprint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni-footprint

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 17 Oct 2012 23:44:51 +0100

Haibin

> Excellent use case and discussion! And I think the negotiation phase should be in scope, which should not be left as a hole for CDNI.

I disagree. I don't think there is any need for negotiation or in fact any negotiation occurring at all. 

The dCDN advertises what it is capable/willing to do on the behalf of the uCDN and the uCDN decides whether it wants to use the dCDN or not. 

A negotiation implies the dCDN advertises something the uCDN doesn't like and the uCDN can reply "that doesn't work for me please try a different offer" where the dCDN can then advertise a different footprint/capabilities to the uCDN. I don't see such negotiations occurring at the protocol layer in practice and so CDNI doesn't require a footprint/capabilities negotiation state machine. 

Ben
>      &nbs

---

From: Songhaibin <[email-masked]>
Date: Thu, 18 Oct 2012 01:14:48 +0000

Hi Ben,

Actually in the example described by Anne, the negotiation phase is about the footprint/capability advertisement. That is what I mean. I agree with your point. The note below in the example is not necessary and should be removed.

BR,
-Haibin

From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, October 18, 2012 6:45 AM
To: Songhaibin
Cc: [email-masked]; Jan Seedorf; [email-masked]; [email-masked]
Subject: Re: [cdni-footprint] [CDNi] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

Haibin

On 17 Oct 2012, at 07:24, Songhaibin <[email-masked]<mailto:[email-masked]>> wrote:
Excellent use case and discussion! And I think the negotiation phase should be in scope, which should not be left as a hole for CDNI.

Ben

-Haibin

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 16, 2012 10:00 PM
To: Jan Seedorf; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

De : Jan Seedorf [mailto:[email-masked]]
Envoyé : mardi 16 octobre 2012 15:26
À : MARREC Anne OLNC/OLN; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'

Hi Anne and Emile,

-          Jan

Hi all,

Anne & Emile

CDN A
CP1
CDN B
CDN D
CDN C

I)                    Use case assumptions:

CP demand example:

*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>?url_signing=”bb”&*

CDN A capabilities compared to CP1 demand are the following:
“Class of request “:
“URI_class”:
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>?url_signing=”bb”&*
“footprint” :
Geo= “france”
“quality/capabilities” :
               maxDeliveryStartLatency = 500

rtmp://cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing=”bb”&*

“Class of request“:
“URI_class”:
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>?url_signing=”bb”&*
“footprint”:
Geo= “Europe”
“quality/capabilities” :
                maxDeliveryStartLatency = 500

5) CDN A is ok and an agreement is concluded between CDNA and CAN B operators for the following service:
“service_ab”:
“Class of request “:
“URI_class”:
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing=”bb”&*
“footprint” :
Geo= “Europe”
“quality/capabilities” :
maxDeliveryStartLatency = 500

II)                 Use case:

Service_id : “service_ab”
                               {
“Class of request “:
               {
“URI_class”:
*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing=”bb”&*
“footprint” :
Geo= “Europe”
}
“quality/capabilities” :
maxDeliveryStartLatency = 500
}

If the End-user request of content matches the class of request “*//cdn.cp1.com/video/*<http://cdn.cp1.com/video/*>? url_signing=”bb”&*”
And
{
If  the IP source address belongs to the footprint/geo=”France”
      then, the delivery of the requested content is done by the CDN A itself
      else {
if the IP source address belongs to the footprint/geo=”Europe” then, the delivery of the requested content is delegated to CDN B (which will delegate it to CDN C if protocol = “RTMP”)
else {

                               }
        }

[email-masked]<mailto:[email-masked]>