[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt



Dear a a,

> It looks pretty good. 

Thanks.

> I have a question rather than a comment:
> In this draft we are trying to add some new objects to
> the base RSVP-TE. RSVP or RSVP-TE so far have been
> kept immune from the applications that could make use
> of it. So, why are we planning to add something like
> "VoIP-CallIds" instead of some generic name or
> identifier that could be used by different
> applications in different contexts? The L3PID anyway
> would define the kind of the payload being carried and
> applications would be free to interpret that "generic
> identifier" in the fashion they want. (Pls. excuse me
> if I'm not privy to some information or earlier
> discussions).

This is a good comment.  I think a generic name is appropriate such that the protocol is applicable to any real-time ECRTP flow over MPLS.  We'll generalize that in the next Rev.

> Today we have SIP (in VoIP networks) and that's why
> usage of VoIP-CallIds may be justified in some sense
> but tomorrow there could be some other protocol (that
> may use some other identifier instead of callId) and
> hence we may have to accommodate that as well.

Good point.  Needs to be generalized.
 
> The other minor comments that I have are:
> * Though the draft states that packet type field would
> be prepended to the "packet formats" defined in ECRTP
> (RFC3545), a pictorial representation would be useful.

OK.
 
> * Most of the SIP RFCs and SIP drafts have associated
> example "Call Flows" with DETAILED message contents -
> either in separate drafts/RFCs or in Appendix sections
> to the main RFC/drafts. Can we do something similar
> for this draft as well? (It has some message sequence
> shown but it's not that detailed). It would be useful
> to see the data plane encodings as well (with label
> stacks, packet types and compressed payloads etc.).

As you suggest, I think a separate draft (or perhaps an Appendix) would be appropriate for detailed message flows.

Thanks a lot for your review, comments, and suggestions.
Jerry

> --- "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
> wrote:
> > All,
> > 
> > Please review and comment on 'Protocol Extensions for ECRTP over MPLS'
> > http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt.
> > The protocol extensions enable the use of MPLS to
> > route enhanced compressed RTP (ECRTP) compressed packets over an MPLS LSP without
> > compression/decompression cycles at each router.
> > 
> > The proposed extensions are based on the
> > requirements documented in 'Requirements for ECRTP over MPLS'
> http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-01.txt.
> > 
> > Thanks,
> > Jerry

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