Subject: Re: [MBONED] [blink-dev] Intent to Prototype: Multicast Receive API

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Feb 2022 23:14:50 -0500

Dear Jake, Toerless and MBONED

Does anyone know the status of this project to allow Chrome browser to play
multicast natively.

The issue was that NPAPI plug-in is not supported and so multicast cannot
play natively.

So some dev work was needed to get this fixed and working for MBONE
community at large.

https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs?pli=1

Copy/paste from link above.

Moving blink-dev@ to BCC and forwarding this to the net-dev@ mailing list.

This work proposes adding support for new network protocols to Chromium,
which has security and privacy consequences. net-dev@ is the mailing list
where this conversation should start. From private communications with the
proposers of this new API their primary goal at this stage of development
is to land an experimental implementation within Chromium in order to
facilitate iteration and evaluation of the technology.
Reilly Grant | Software Engineer | [email-masked] | Google Chrome
<https://www.google.com/chrome>

On Thu, Feb 4, 2021 at 1:31 PM 'Holland, Jake' via blink-dev <
[email-masked]> wrote:

> Contact emails
>
> [email-masked], [email-masked]
>
>
> Explainer
>
>
>
> https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md
>
>
> Specification
>
>
>
> TBD: API spec and design document (currently just entering Intent to
> Prototype).
>
> IETF standards-track docs (all presently works in progress):
>
> - draft-ietf-mboned-ambi
> - draft-ietf-mboned-dorms
>
> - draft-ietf-mboned-mnat
> - draft-ietf-mboned-cbacc
>
> (There will be integrated components prototyped in the browser feature
> based an appropriate subset of the above specs before origin trials begin.)
>
>
>
>
> Summary
>
> Subscribe to source-specific multicast IP channels and receive UDP
> payloads in web applications.
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 23 Feb 2022 16:04:18 +0000

Hi Gyan,

it’s not currently expected to make it into the upstream, as Google said they’re not interested.  However, an implementation is available for experimenting with.

I’ve been maintaining a fork that implements the proposed api (but does not have the authentication functionality implemented):
https://github.com/GrumpyOldTroll/chromium_fork

I’ve been keeping it approximately up to date with chromium releases.  There’s .deb binaries linked from the repo that you can experiment with, and there’s an example page that uses the api at https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html.

I’m looking into alternatives that might have a better chance at moving forward and getting adoption based on the feedback we got so far, and as soon as one of those is operational I’ll probably stop maintaining that fork and put up a note to the new thing, but for now that’s what I’ve got.

The primary discussion venue for this is the W3C multicast community group.  You can get a rough idea of what we’ve been thinking from the meeting logs and videos:
https://github.com/w3c/multicast-cg/tree/main/meetings

HTH,
Jake

From: Gyan Mishra <[email-masked]>
Date: Tue,2022-02-22 at 8:15 PM
To: "Holland, Jake" <[email-masked]>, MBONED WG <[email-masked]>, Toerless Eckert <[email-masked]>
Subject: Re: [blink-dev] Intent to Prototype: Multicast Receive API

Does anyone know the status of this project to allow Chrome browser to play multicast natively.

The issue was that NPAPI plug-in is not supported and so multicast cannot play natively.

So some dev work was needed to get this fixed and working for MBONE community at large.

https://groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs?pli=1<https://urldefense.com/v3/__https:/groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs?pli=1__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFRnRSVq8$>

This work proposes adding support for new network protocols to Chromium, which has security and privacy consequences. net-dev@ is the mailing list where this conversation should start. From private communications with the proposers of this new API their primary goal at this stage of development is to land an experimental implementation within Chromium in order to facilitate iteration and evaluation of the technology.
Reilly Grant | Software Engineer | [email-masked] | Google Chrome<https://urldefense.com/v3/__https:/www.google.com/chrome__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFJ2r6e6c$>

On Thu, Feb 4, 2021 at 1:31 PM 'Holland, Jake' via blink-dev <[email-masked]> wrote:
Contact emails
[email-masked], [email-masked]

Explainer

https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md<https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFmW_6mkM$>

Specification

TBD: API spec and design document (currently just entering Intent to Prototype).

IETF standards-track docs (all presently works in progress):
- draft-ietf-mboned-ambi<https://urldefense.com/v3/__http:/draft-ietf-mboned-ambi/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFhiTQ8xc$>
- draft-ietf-mboned-dorms<https://urldefense.com/v3/__http:/draft-ietf-mboned-dorms/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFpBPIpck$>
- draft-ietf-mboned-mnat<https://urldefense.com/v3/__http:/draft-ietf-mboned-mnat/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEzNi_XI$>
- draft-ietf-mboned-cbacc<https://urldefense.com/v3/__http:/draft-ietf-mboned-cbacc/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNF9SrvDFo$>
(There will be integrated components prototyped in the browser feature based an appropriate subset of the above specs before origin trials begin.)

Summary

Subscribe to source-specific multicast IP channels and receive UDP payloads in web applications.
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEOI0wLY$>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Feb 2022 11:46:13 -0500

Excellent!

Questions in-line

Thanks

Gyan

On Wed, Feb 23, 2022 at 11:04 AM Holland, Jake <[email-masked]> wrote:

> Hi Gyan,
>
>
>
> it’s not currently expected to make it into the upstream, as Google said
> they’re not interested.  However, an implementation is available for
> experimenting with.
>
>  Gyan>  Did google say why they are not interested?
>
> I’ve been maintaining a fork that implements the proposed api (but does
> not have the authentication functionality implemented):
>
>  Gyan>  That’s great.   I will try testing it out
>
> I’ve been keeping it approximately up to date with chromium releases.
> There’s .deb binaries linked from the repo that you can experiment with,
> and there’s an example page that uses the api at
> https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html
> .
>
>  Gyan> Excellent
>
> I’m looking into alternatives that might have a better chance at moving
> forward and getting adoption based on the feedback we got so far, and as
> soon as one of those is operational I’ll probably stop maintaining that
> fork and put up a note to the new thing, but for now that’s what I’ve got.
>
> Gyan>  Alternative that might get adopted by Google so they can integrate
> natively into the browser?
>

>
> The primary discussion venue for this is the W3C multicast community
> group.  You can get a rough idea of what we’ve been thinking from the
> meeting logs and videos:
>
>  Gyan> Thanks
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Tue,2022-02-22 at 8:15 PM
> *To: *"Holland, Jake" <[email-masked]>, MBONED WG <[email-masked]>,
> Toerless Eckert <[email-masked]>
> *Subject: *Re: [blink-dev] Intent to Prototype: Multicast Receive API
>
>
>
>
>
> <https://urldefense.com/v3/__https:/groups.google.com/a/chromium.org/g/net-dev/c/TjbMyPKuRHs?pli=1__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFRnRSVq8$>
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.google.com/chrome__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFJ2r6e6c$>
>
>
>
>
>
> <https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFmW_6mkM$>
>
>
> Specification
>
>
>
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-ambi/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFhiTQ8xc$>
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-dorms/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFpBPIpck$>
>
> - draft-ietf-mboned-mnat
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-mnat/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEzNi_XI$>
> <https://urldefense.com/v3/__http:/draft-ietf-mboned-cbacc/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNF9SrvDFo$>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEOI0wLY$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Feb 2022 11:49:21 -0500

Jake

Have you looked at WebRTC.

I believe there is a chrome plugin but not sure if the plug-in allows
multicast to play natively.  I wonder if that plug-in could be tweaked to
get multicast to work as well as an alternative.

Thanks

Gyan

On Wed, Feb 23, 2022 at 11:46 AM Gyan Mishra <[email-masked]> wrote:

>> which has security and privacy consequences. net-dev@ is the mailing
>> list where this conversation should start. From private communications with
>> the proposers of this new API their primary goal at this stage of
>> development is to land an experimental implementation within Chromium in
>> order to facilitate iteration and evaluation of the technology.
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 23 Feb 2022 17:58:46 +0000

Hi Gyan,

> Have you looked at WebRTC.

As I understand it (not very deeply), WebRTC does not support multicast since it requires the use of SRTP.
> Gyan>  Did google say why they are not interested?
In the net-dev thread you linked, I believe they indicated it needs good consensus on the security implications before they’d consider accepting it.

We tried to kick off that discussion at 112, but nobody has responded with further discussion yet except for the comments during the secdispatch presentation.  But the discussion was dispatched to the msec list:
https://mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/

The other thing they said in the net-dev thread you linked was they don’t want it to be part of their maintenance burden even if it’s cleaned up.  I expect this would change if the multicast traffic were likely to be delivered, which is why (as described in the msec message) we’re shifting focus to start getting some deployment of non-browser multicast to establish some places where delivery does actually work.

They also indicated in the thread that they do not have a goal of making multicast delivery more attractive to ISPs by adding support in the browser.  I hope to change their minds eventually, but that’s still where it stands today.

> Gyan>  Alternative that might get adopted by Google so they can integrate natively into the browser?

Yes.  The rough approach I’m starting is also outlined in the msec thread linked above, but I don’t have a draft written yet.  Not certain whether it’ll be out for 113, but maybe.  Probably will still be working on it though and won’t have a presentation about it yet.

HTH, and I’m glad you’re interested.  I’d love to know more about what kind of use cases you’re looking into.

-Jake

From: Gyan Mishra <[email-masked]>
Date: Wed,2022-02-23 at 8:49 AM
To: "Holland, Jake" <[email-masked]>
Cc: MBONED WG <[email-masked]>, Toerless Eckert <[email-masked]>
Subject: Re: [blink-dev] Intent to Prototype: Multicast Receive API

Jake

I believe there is a chrome plugin but not sure if the plug-in allows multicast to play natively.  I wonder if that plug-in could be tweaked to get multicast to work as well as an alternative.

Thanks

Gyan

On Wed, Feb 23, 2022 at 11:46 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Excellent!

Questions in-line

Thanks

Gyan

On Wed, Feb 23, 2022 at 11:04 AM Holland, Jake <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

it’s not currently expected to make it into the upstream, as Google said they’re not interested.  However, an implementation is available for experimenting with.
 Gyan>  Did google say why they are not interested?
I’ve been maintaining a fork that implements the proposed api (but does not have the authentication functionality implemented):
https://github.com/GrumpyOldTroll/chromium_fork<https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/chromium_fork__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRAzhk2S4$>
 Gyan>  That’s great.   I will try testing it out
I’ve been keeping it approximately up to date with chromium releases.  There’s .deb binaries linked from the repo that you can experiment with, and there’s an example page that uses the api at https://grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html<https://urldefense.com/v3/__https:/grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVR0cZe9DQ$>.
 Gyan> Excellent
I’m looking into alternatives that might have a better chance at moving forward and getting adoption based on the feedback we got so far, and as soon as one of those is operational I’ll probably stop maintaining that fork and put up a note to the new thing, but for now that’s what I’ve got.
Gyan>  Alternative that might get adopted by Google so they can integrate natively into the browser?

The primary discussion venue for this is the W3C multicast community group.  You can get a rough idea of what we’ve been thinking from the meeting logs and videos:
https://github.com/w3c/multicast-cg/tree/main/meetings<https://urldefense.com/v3/__https:/github.com/w3c/multicast-cg/tree/main/meetings__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRUVb7XEU$>
 Gyan> Thanks
HTH,
Jake

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tue,2022-02-22 at 8:15 PM
To: "Holland, Jake" <[email-masked]<mailto:[email-masked]>>, MBONED WG <[email-masked]<mailto:[email-masked]>>, Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Subject: Re: [blink-dev] Intent to Prototype: Multicast Receive API

This work proposes adding support for new network protocols to Chromium, which has security and privacy consequences. net-dev@ is the mailing list where this conversation should start. From private communications with the proposers of this new API their primary goal at this stage of development is to land an experimental implementation within Chromium in order to facilitate iteration and evaluation of the technology.
Reilly Grant | Software Engineer | [email-masked]<mailto:[email-masked]> | Google Chrome<https://urldefense.com/v3/__https:/www.google.com/chrome__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFJ2r6e6c$>

On Thu, Feb 4, 2021 at 1:31 PM 'Holland, Jake' via blink-dev <[email-masked]<mailto:[email-masked]>> wrote:
Contact emails
[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Explainer

Specification

Summary

Error! Filename not specified.<https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!DhNFIJSjLlBTt2ff1aIHLB55Hz9D_vR8WG3b2uPJ37dr9hNIU4dghgNFEOI0wLY$>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRgbkYpRA$>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRgbkYpRA$>

Gyan Mishra

M 301 502-1347

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 24 Feb 2022 07:46:48 +1300

> On Feb 24, 2022, at 6:58 AM, Holland, Jake <jholland=[email-masked]> wrote:
> 
> Hi Gyan,
>  

SRTP can be used on multicast streams.  The reason why WebRTC does not support multicast is simply because it was defined (standardized) for unicast streams only - not for any reason having to do with SRTP.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 23 Feb 2022 17:49:50 -0500

Hi Jake

Am glad we have connected on this topic.

Thank you for all your feedback and I will try to connect to some of the
other threads and monitor the progress of this critical project as this
same issue am sure plagues other operators worldwide.  Also any help I can
provide on this critical project as well as you can use our use case which
I think applies to any company.

So our major use case for this is for distribution of multicast SSM  feed
for enterprise webcasts to all Verizon Entities over our corporate intranet
which  spans the globe to 150k employees.

We have been using Ramp for video delivery ever since we started using
Chrome browser on windows and MAC for office productivity which does not
support NPAPI plugin so cannot play multicast natively.

https://www.rampecdn.com/

With Ramp the multicast source sender ingests the HLS or Dash unicast feed
encapsulates in UDP RTP header and sources the multicast distribution over
the network worldwide.  The Ramp receiver apps are loaded on all 150k
employees desktops which removes the outer header unpackages and plays out
locally over localhost signed certificate over 127.0.0.1 and the HLS or
Dash steam plays natively now on the browser.

The major problem we have had with this solution is the Ramp receiver on
each desktop has to be pushed out every time there is a software upgrade
and recently we have had security issue with new chrome flags allowing
playing locally as each host now acts as local web server - to prevent
malware attacks and thus the knob cannot be enabled.  So we are still
working with Ramp on a workaround as well as alternatives such as the best
of course would be Chrome playing multicast natively.

So this is a major problem and we are eagerly waiting to see when Chrome
will support playing multicast natively.

Responses in-line Gyan2>

Kind Regards

Gyan

On Wed, Feb 23, 2022 at 12:59 PM Holland, Jake <[email-masked]> wrote:

> In the net-dev thread you linked, I believe they indicated it needs good
> consensus on the security implications before they’d consider accepting it.
>
> Gyan2> I see so sounds like we are close but have a gap with security
>
> We tried to kick off that discussion at 112, but nobody has responded with
> further discussion yet except for the comments during the secdispatch
> presentation.  But the discussion was dispatched to the msec list:
>
>  Gyan> Thank you I will review the ML
>
> The other thing they said in the net-dev thread you linked was they don’t
> want it to be part of their maintenance burden even if it’s cleaned up.  I
> expect this would change if the multicast traffic were likely to be
> delivered, which is why (as described in the msec message) we’re shifting
> focus to start getting some deployment of non-browser multicast to
> establish some places where delivery does actually work.
>
> Gyan2>  So you think there is hope that Google will get on board once
> security issues clean up is resolved if we are able to prove multicast
> delivery with non browser deployments then Google may get back on board.
>
> They also indicated in the thread that they do not have a goal of making
> multicast delivery more attractive to ISPs by adding support in the
> browser.  I hope to change their minds eventually, but that’s still where
> it stands today.
>
>  Gyan2>  Interesting as I wonder if they have unicast video working I
> guess and ISPs have plenty of bandwidth although with beyond 4k and VR as
> that blossoms with 5G network services Slicing as operators continue to
> build out OTN optical network from  400G to 800G and beyond its a moving
> target and multicast is the end all be all bandwidth management savior do
> hopefully they come around.
>
> Yes.  The rough approach I’m starting is also outlined in the msec thread
> linked above, but I don’t have a draft written yet.  Not certain whether
> it’ll be out for 113, but maybe.  Probably will still be working on it
> though and won’t have a presentation about it yet.
>
> Gyan2> Excellent work by you and the MBONE and PIM and all WGs involved in
> this critical project.
>
>  Gyan2>   Maybe we can get together and go over the use case details.
> Also our use case am sure exists for all corporations trying to use
> multicast for video delivery using Chrome.
>
> -Jake
>
>
>
> *Date: *Wed,2022-02-23 at 8:49 AM
> *To: *"Holland, Jake" <[email-masked]>
> *Cc: *MBONED WG <[email-masked]>, Toerless Eckert <[email-masked]>
> <https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/chromium_fork__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRAzhk2S4$>
>
> <https://urldefense.com/v3/__https:/grumpyoldtroll.github.io/wicg-multicast-receiver-api/demo-multicast-receive-api.html__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVR0cZe9DQ$>
> .
>
>  Gyan> Excellent
>
> <https://urldefense.com/v3/__https:/github.com/w3c/multicast-cg/tree/main/meetings__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRUVb7XEU$>
>
>  Gyan> Thanks
>
> HTH,
>
> Jake
>
>
>
> *Error! Filename not specified.*
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRgbkYpRA$>
>
> *Gyan Mishra*
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!GjvTz_vk!FBIPYCQrN0By_vJcKO_V9-zzmIyeuhaXJE1vlu09N1VmnYDsPvSJ-lVRgbkYpRA$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

*M 301 502-1347*