RE: [AVT] AVT agenda for Atlanta

In-line [ranjith]....

-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org] 
Sent: Thursday, November 14, 2002 7:59 PM
To: ranjith.mukundan@wipro.com
Cc: avt@ietf.org
Subject: Re: [AVT] AVT agenda for Atlanta 

Ranjith,

--> Ranjith Mukundan writes:
>Apologies for bringing this up at the eleventh hour.
>
>I would like to check the possibility of a discussion slot at the AVT
WG
>meeting to *briefly* discuss on a new RTP profile that we need to
support
>for on-hook/off-hook voiceband data transmission over RTP using the
>encoding rules (SDMF, MDMF, GDMF) & procedures for the same, as defined
in
>TR-57, GR-30 & GR-31. In circuit switched world, this is primarily used
to
>transfer the calling line ID information, Visual Message Waiting
Indicator,
>caller ID on a call waiting call etc from an IDT (logical part of a
central
>office)  to an RDT (remote digital terminal), over a DLC interface
(like
>GR-303) without actually DTMF/MF encoding the digits. This requirements
>stems from a need to implement the DLC system over a packet network.

I'm not familiar with most of those acronyms, but this sounds like it
may
be similar to RFC 2833? Also, what would be the relation to the
signaling
channel?

[ranjith]
Yes, it would be similar to RFC2833, we just need to define one more
payload type and the concomitant RTP profile. Taking it a step further,
the GRs for voice-band data txn (esp GR30) does not have any field in
the encoded message assembly layer to distinguish between the 3 possible
encoding types - SDMF/MDMF/GDMF. But, whilst transporting these frames
over RTP, it would infact be more efficient to define 3 payload types
instead of just one to identify the 3 possible framing formats used for
transporting the voiceband data.

It's relation to the signaling channel:
As I have mentioned, these frames are carried in-band, in the
dynamically or statically allocated bearer DS0s that will eventually be
used for the voice call after the session matures to the answer phase.
The D-channel (signaling channel) is just used to dynamically allocate
the ds0s and the rest of the line-side supervision (like providing an
indication of applying the first power-ringing cycle) happens in-band,
via RBS (for which, RFC2833 already defines the NSEs and the
corresponding payload types.  

>Due to a scheduling oversight on our part, this bubbled up our priority
>list quite late - and hence we are now very close to the deadline, if
not
>too late already, to request for an official slot on the AVT WG
meeting.

It's too late to get agenda time in the meeting, especially given that
there is no I-D to discuss. I'd be happy to talk informally in Atlanta
or on the list.

[ranjith]
Sounds good, I'll touch base after the AVT WG meeting on Tuesday

>As the requirment is quite straight-foward, we are of the opinion that
a
>brief informal discussion would also help/suffice - and might not need
a
>slot on AVT WG meeting, after all. But all the same, do please let us
know
>if a slot (5-10 mins max) for this can be squeezed into to AVT agenda,
if
>it is not too late already. I shall post 2-3 slides and any other info
>(summary of requirements etc) that you folks think would be relevant to
the
>list, before we can take this up for discussion in Atlanta.
>
>As the I-D for detailing this requirement is going to be very brief, we
>felt that it would help do a viability check on this list and analyse
the
>need rather than first submit an I-D.

If you could send more details, that would be helpful.

[ranjith]
I guess it would probably be better to submit an ID with enough
background info. We'll do that after the 55th meeting.

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt