Subject: RE: [AVT] Re: Clearmode definition.

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 23 Mar 2004 13:36:05 +0200

> Yaakov,
> One of the cases you mention include an RTP encapsulation of 
> Nx64. Unless you have already done so, I recommend you 
> register a MIME for it and allow its session-by-session 
> negotiation using SDP, H.245 or other means. My guess from 
> having read the PWE3 drafts in the past is that you are 
> limiting the application to a provisioned RTP Nx64 session. 
> While that is adequate in some applications, others will 
> require/prefer the signaled establishment of Nx64 sessions.

Rajesh, 

Since this is a PW protocol, it works in the PWE fashion.
Either the PW is manually provisioned, or it is set up
using the PW control protocol. 

In either case it is not envisioned that this connection
will be set-up and torn-down on a "session per session" basis,
just as a T1 or E1 is not torn-down after a phone conversation.

This is another difference between what we are doing in PWE3,
and the typical AVT method of working.

The point of my previous email was that even if it is decided
that PWE is a proper place to standardize methods for
transport of N*64 flows over IP, their treatment at PWE3
may not be what you are looking for.

In particular, MIME types and use of SDP are entirely
alien to the PWE3 way of doing things.

Hence if you have a need for an RTP encapsulation of N*64k, 
I would suggest that the AVT WG look into it,
trying to keep the encapsulation compatible with the
appropriate PWE draft.

Y(J)S

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Rajesh Kumar <[email-masked]>
Date: Tue, 23 Mar 2004 07:34:24 -0800

Yaakov,

>trying to keep the encapsulation compatible with the

This is what I requested from the AVT group but they indicated I go to the 
PWE3 group for it. However, if, between the two groups, we think that a 
MIME for nx64 over RTP will not be widely useful, then we can drop it. 
Registration of vendor-specific MIMEs is also possible, but is this the way 
we want to go? Either way, I would like us in AVT and PWE3 to make a 
conscious choice.

Rajesh

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Mar 2004 15:42:16 +0000

--> Rajesh Kumar <[email-masked]> writes:
...
> This is what I requested from the AVT group but they indicated I go to
> the PWE3 group for it. However, if, between the two groups, we think that
> a MIME for nx64 over RTP will not be widely useful, then we can drop it. 
> Registration of vendor-specific MIMEs is also possible, but is this the
> way we want to go? Either way, I would like us in AVT and PWE3 to make a 
> conscious choice.

What would be the use case for having the MIME type registered? I've not
heard a reason why the mechanisms being developed in PWE3 are insufficient.

-- 
Colin Perkins
http://csperkins.org/

---

From: Rajesh Kumar <[email-masked]>
Date: Tue, 23 Mar 2004 08:25:21 -0800

At 04:11 PM 3/23/2004 +0000, Colin Perkins wrote:
> > At 03:42 PM 3/23/2004 +0000, Colin Perkins wrote:
> > Say you set up an 384 kbps call via SIP for your video. You do not use
> > the relevant video MIME because what gets put in RTP is nx64 and the
> > video/audio is one step removed.
> >
> > You may not want to proliferate signaling in your network.
>
>Again, what is the application scenario? Why the need to signal Nx64 kbps
>clearmode, rather than the appropriate video format?

Because in this case you would encapsulate a 384 kbps clear channel in RTP. 
The video and other streams would be within this Nx64 container.

> > This may not be of general interest so I am dropping AVT.
>
>Added back, since I'd like input from the wider group.
>
>--
>Colin Perkins
>http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 23 Mar 2004 16:11:09 +0000

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Mar 2004 11:02:38 +0000

--> Rajesh Kumar <[email-masked]> writes:
> > > >What would be the use case for having the MIME type registered? I've
> > > >not heard a reason why the mechanisms being developed in PWE3 are
> > > >insufficient.
> > >
> > > Say you set up an 384 kbps call via SIP for your video. You do not
> > > use the relevant video MIME because what gets put in RTP is nx64 and
> > > the video/audio is one step removed.
> > >
> >Again, what is the application scenario? Why the need to signal Nx64
> >kbps clearmode, rather than the appropriate video format?
> 
> Because in this case you would encapsulate a 384 kbps clear channel in
> RTP. The video and other streams would be within this Nx64 container.

Right - you have a pseudo-wire emulation, running multiple streams within
the pseudo-wire. This would seem to be a typical application for the PWE3
mechanisms, rather than something AVT should consider. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Rajesh Kumar <[email-masked]>
Date: Fri, 26 Mar 2004 08:40:38 -0800

>mechanisms, rather than something AVT should consider.

In some applications, this places a demand for two, not one, signaling 
mechanisms at the multimedia endpoints for RTP media e.g. SIP and PWE3 
control. These are applications where it might set up nx64 sessions and 
other (not necessarily simultaneous) sessions outside the pseudo-wire.

Perhaps, the PWE3 group should MIME this RTP media so that SIP and H.248 
can be used for setting up nx64 sessions. However, if there is no 
wide-spread demand for the SIP or H.248 signaling of the nx64 codec, the 
vendors may define their proprietary MIMEs in the 'vnd' tree.

Rajesh

---

From: Colin Perkins <[email-masked]>
Date: Mon, 29 Mar 2004 09:24:18 +0100

--> Rajesh Kumar <[email-masked]> writes:
> >Right - you have a pseudo-wire emulation, running multiple streams
> >within the pseudo-wire. This would seem to be a typical application for
> >the PWE3 mechanisms, rather than something AVT should consider.
> 
> can be used for setting up nx64 sessions. 

Is that sufficient? You don't need to signal anything about the contents of
the pseudo-wire? Before proposing solutions, what are your requirements?

> However, if there is no 

Or, perhaps, the vendors should work with PWE3 to define an appropriate
signalling mechanism (be that using SIP or otherwise)? 

-- 
Colin Perkins
http://csperkins.org/

---

From: Christian Groves <[email-masked]>
Date: Tue, 30 Mar 2004 21:03:37 +1000

Hello Rajesh,

H.248 can already signal the use of Nx64k through the use of the multiplex 
descriptor.

Regards, Christian

> vendors may define their proprietary MIMEs in the 'vnd' tree.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.