Re: [AVTCORE] Update proposal; RE: [Megaco] Types of monitoring architectures; RE: I-D Action: draft-ietf-avtcore-monarch-08.txt
Qin Wu <[email protected]> Tue, 13 Dec 2011 10:00:19 +0800
| Newsgroups | gmane.ietf.avt,gmane.ietf.megaco |
|---|---|
| Message-ID | <[email protected]> |
Hi, Albrecht: Thank for your proposal. I will how your proposed text can fit into RTP monitoring architecture and reflect them in the new update. Thanks again. Regards! -Qin ----- Original Message ----- From: "Schwarz, Albrecht (Albrecht)" <[email protected]> To: "Qin Wu" <[email protected]>; <[email protected]> Cc: <[email protected]> Sent: Monday, December 12, 2011 6:55 PM Subject: Update proposal; RE: [Megaco] [AVTCORE] Types of monitoring architectures; RE: I-D Action: draft-ietf-avtcore-monarch-08.txt Might be more effective by continuing the discussion with a concrete text proposal, see attachments. Any comments? Albrecht > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Schwarz, > Albrecht (Albrecht) > Sent: Montag, 12. Dezember 2011 11:33 > To: Qin Wu; [email protected] > Cc: [email protected] > Subject: Re: [Megaco] [AVTCORE] Types of monitoring > architectures; RE: I-D Action: draft-ietf-avtcore-monarch-08.txt > > Hi Qin, > > I'm very aware about all that. > It looks like that you are now agreeing that QoE measurements > are CONDITIONAL ("you got a number of IF statements, there > might be even more ..."). > > MONARCH is not talking about such conditions, thus some > readers may got the impression that the metrics related to > RTP traffic are UNCONDITIONAL (which is not true as you confirmed). > > If you go back to my very first email: I did just propose to > indicate the conditional aspect. Don't understand why such > kind of valuable info would be not in scope of MONARCH. Hm? > > Regards, > Albrecht > > PS > I did use the notion of a control plane agnostic "RTP-to-PSTN > gateway". You did indicate control plane specific gateway > types like SIP-to-PSTN or SIP-to-H.323. Now issue to use such > signalling protocol specific examples, but it doesn't change > the underlying issue. > The SIP side reporting capability based on RFC 6035 allows to > report the outlined measurements, but the RFC itself does not > specify whether the reported information is meaningful (which > is OK because this is not subject of a reporting interface > spec, it is rather subject of a network monitoring doc like MONARCH). > QoE measurements would be conditional in both gateway types > (because such a gateway is NOT a user device despite the fact > of an embedded SIP user agent entity). > Actually I would even question here the condition of > "customer knows the original content" in many real network scenarios. > > > > > -----Original Message----- > > From: Qin Wu [mailto:[email protected]] > > Sent: Montag, 12. Dezember 2011 05:05 > > To: Schwarz, Albrecht (Albrecht); [email protected] > > Cc: [email protected] > > Subject: Re: [AVTCORE] Types of monitoring architectures; RE: > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > Hi, Albrecht: > > My understanding to QoE measurment is: > > The factors that influence the QoE metric include encoding system, > > transport network, access network,home network and end device. > > If the customer(e.g., network operator) doesn't know the original > > content, the QoE metric should be usually measured at the > user device. > > If the customer knows the original content, the QoE metric can be > > measured either in the network or at the user device. > > Given the growing popularity of connected devices, these > devices may > > have different capability corresponding to CPU load, processing > > overhead, storage, batteries. > > If the cusomer want to measure QoE without considering connected > > devices with various capability , the QoE metric can be measured at > > the point between access network and home network. > > > > Regarding the monitoring scenario you mentioned, I am not familiar > > with such scenario with RTP-to-PSTN gateway deployed. > > But I am aware that there are scenarios with SIP to PSTN gateway or > > SIP to H.323 gateway widely deployed, RFC6035 defines a > new SIP event > > package, vq-rtcpxr that enable the collection and reporting of > > metrics that measure quality for RTP sessions. In such > cases, RTCP XR > > VOIP metric with QoE metric included is measured at the user device > > and mapped into the equivalent SIP vq-rtcpxr parameter since SIP > > session call is established end to end and RTP media stream is > > exchanged directly between one endpoint and the other endpoint. > > > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Schwarz, Albrecht (Albrecht)" > > <[email protected]> > > To: "Qin Wu" <[email protected]>; <[email protected]> > > Cc: <[email protected]> > > Sent: Saturday, December 10, 2011 12:01 AM > > Subject: RE: [AVTCORE] Types of monitoring architectures; RE: > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > How do you explain to a network operator the value of QoE > measurements > > by an RTP receiver / RTP monitor component located in an > RTP-to-PSTN > > gateway? > > > > This would be a monitoring scenario inline with MONARCH, but with > > valueless QoE results, right? > > > > > > > -----Original Message----- > > > From: Qin Wu [mailto:[email protected]] > > > Sent: Donnerstag, 8. Dezember 2011 03:26 > > > To: Schwarz, Albrecht (Albrecht); [email protected] > > > Cc: [email protected] > > > Subject: Re: [AVTCORE] Types of monitoring architectures; RE: > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > You reiterate what you propose for physical entities in the early > > > email. > > > I am still not convicing with that. > > > > > > Since we have RTP components like RTP end system, RTP mixer, RTP > > > media translator, RTP transport translator, RTP monitor > specified in > > > RFC3550 can be built into these component as a application. also > > > monitor can be disjointed from these RTP components as a > third party > > > monitor. why we need to specify how to map RTP end system > into user > > > equipment, RTP translator or RTP mixer can be mapped into > RTP-PSTN > > > gateway, or IP to IP border gateway since we have already mapped > > > monitor into different RTP components. > > > How many PE types you can enumerate? why they should be > scope of RTP > > > monitoring architecture? > > > > > > Also as specified in MONARCH draft, we have end sytem metrics, > > > transport level metric, transport level metric, they can > be measured > > > and collected from the different RTP comoponents specified in > > > RFC3550, RFC5117. Apparently end system metric can only > be collected > > > from RTP end system. > > > transport metric is collected from any RTP system in the RTP > > > monitoring architecture, regarding application level metric, > > > apparently they should be measured at the application > layer and can > > > not be collected from RTP transport translator, Also RTP > transport > > > translator is still a functional entity rather than a physical > > > entity. I am not convincing with what you said about > > > "contradiction", "lead to possible wrong expectations". > > > > > > Regards! > > > -Qin > > > ----- Original Message ----- > > > From: "Schwarz, Albrecht (Albrecht)" > > > <[email protected]> > > > To: "Qin Wu" <[email protected]>; <[email protected]> > > > Cc: <[email protected]> > > > Sent: Thursday, December 08, 2011 12:24 AM > > > Subject: RE: [AVTCORE] Types of monitoring architectures; RE: > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > Qin, > > > that's NOT the point. > > > > > > All RFC 3550 and RFC 5117 RTP components are FUNCTIONAL > > ENTITIES (FE). > > > e.g., > > > - the RTP Monitor or RTP receiver FE may be located in different > > > PHYSICAL ENTITIES (PE), e.g. > > > a1) a user equipment > > > a2) a RTP-to-PSTN gateway > > > a3) an IP-to-IP session border gateway (in a back-to-back > > > RTP endsystem topology) > > > a3) ... > > > > > > - the RTP Monitor may be associated to an RTP transport > > translator ... > > > b1) an IP-to-IP session border gateway > > > > > > The "RTP monitoring architecture" is IMPACTED by each > > > functional-to-physical mapping because e.g. > > > * QoE related metrics are questionable in case of a2 > ("despite the > > > fact of a RTP receiver function") > > > * application level metrics at the location of a RTP transport > > > translator are a contradiction in itself > > > * ... > > > > > > Again, it's not really changing the MONARCH draft because in the > > > very majority of scenarios it is correct. However, there are few > > > cases where the MONARCH description would be "too high > level", "not > > > fully correct", "lead to possible wrong expectations", ... > > > > > > Regards, > > > Albrecht > > > > > > > > > > > > > -----Original Message----- > > > > From: Qin Wu [mailto:[email protected]] > > > > Sent: Dienstag, 6. Dezember 2011 07:13 > > > > To: Schwarz, Albrecht (Albrecht); [email protected] > > > > Cc: [email protected] > > > > Subject: Re: [AVTCORE] Types of monitoring architectures; RE: > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > If you talk about existing RFC5117 RTP topology > components, this > > > > has already been covered by the current version of > > > > draft-ietf-avtcore-monarch. > > > > In most cases, an RTP system using RTCP XR is > architecturally no > > > > different from an RTP system which does not use RTCP XR. > > > > > > > > Regards! > > > > -Qin > > > > ----- Original Message ----- > > > > From: "Schwarz, Albrecht (Albrecht)" > > > > <[email protected]> > > > > To: "Qin Wu" <[email protected]>; <[email protected]> > > > > Cc: <[email protected]> > > > > Sent: Monday, December 05, 2011 10:48 PM > > > > Subject: RE: [AVTCORE] Types of monitoring architectures; RE: > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > > > Hello Qin, > > > > > > > > to 1) Physical monitoring architecture Of course > consideration of > > > > generic physical entities (PE), not specific to any network > > > > reference architectures defined by SDOs (like your refered > > > > entities). > > > > There would be just a few PE types ("given by the > limited set of > > > > RTP topology components (RFC 5117)"). > > > > > > > > to 2) (RFC 3550) Monitor function > > > > Right, that's a functional entity. The applicability of > a monitor > > > > may be limited, dependent on ... (like in P.NAMS). > > > > > > > > to 3) your IMS network example > > > > Don't see the need to refer from MONARCH to a specific network > > > > architecture like IMS. > > > > Please also note that IMS is a functional architecture, not a > > > > physical architecture. > > > > > > > > Regards, > > > > Albrecht > > > > > > > > PS > > > > There are multiple options for adding the "RTP monitoring > > > > architecture" to a functional/physical network architecture: > > > > a) integrated approach: extension of existing > functional entities > > > > or/and addition of RTP monitoring architectural components, > > > > extension or/and addition of signalling/management > interfaces for > > > > control and configuration of RTP monitoring services, and > > > > reporting interfaces for measurement data ... > > > > b) overlay approach: separate specification to ... > > > > > > > > > > > > PSS > > > > BTW: there's a discussion paper with regards to the > location of a > > > > monitor function in an IMS H.248 gateway entity: > > > > Measurements and statistics in IMS - Use Cases > > > > http://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_5 > > > > 8_Kyoto_Japan/Docs/C3-100469.zip > > > > This is just fyi. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:[email protected]] On > > > > > Behalf Of Qin Wu > > > > > Sent: Freitag, 2. Dezember 2011 02:55 > > > > > To: Schwarz, Albrecht (Albrecht); [email protected] > > > > > Cc: [email protected] > > > > > Subject: Re: [AVTCORE] Types of monitoring architectures; RE: > > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > Hi, Albrecht: > > > > > No offence, I am not really convinced with your proposal on > > > > > physical monitoring architecture. > > > > > my counterquestion is what does physical monitoring > > > > > architecture looks like in your mind? > > > > > How many components do we have in such physical monitroing > > > > > architecture? what are they? > > > > > Take IMS network architecture as a example, they may have > > > > > P-CSCF,S-CSCF, SIP PBX, SBC, why do you believe monitor > > > > > described in draft-ietf-avtcore-monarch is mapped > into P-CSCF, > > > > > S-CSCF, SBC, Media Gateway, Media Gateway Controller > should be > > > > > in the scope of IETF RTP monitoring > > archtiecture draft? > > > > > > > > > > Monitor described in draft-ietf-avtcore-monarch is > well defined > > > > > in the section 3 of RFC3550 as follows: > > > > > " > > > > > > > > > > Monitor: An application that receives RTCP packets sent by > > > > > participants in an RTP session, in particular the > > reception > > > > > reports, and estimates the current quality of > service for > > > > > distribution monitoring, fault diagnosis and long-term > > > > > statistics. > > > > > The monitor function is likely to be built into the > > > > > application(s) > > > > > participating in the session, but may also be a separate > > > > > application that does not otherwise participate > and does > > > > > not send > > > > > or receive the RTP data packets (since they are on > > > a separate > > > > > port). These are called third-party monitors. > It is also > > > > > acceptable for a third-party monitor to receive > > the RTP data > > > > > packets but not send RTCP packets or otherwise be > > > > counted in the > > > > > session. > > > > > > > > > > " > > > > > Isn't how to implent monitor into IMS netowork archtiecture a > > > > > implentation specific issue? > > > > > If this issue are really interesting, isn't it a good idea to > > > > > produce another new document to talk about this? > > > > > One good example for this motivation is this draft I like to > > > > > share with you: > > > > > http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-taxonom > > > > > y-00#section-4.6 > > > > > > > > > > Regards! > > > > > -Qin > > > > > ----- Original Message ----- > > > > > From: "Schwarz, Albrecht (Albrecht)" > > > > > <[email protected]> > > > > > To: "Qin Wu" <[email protected]>; <[email protected]> > > > > > Cc: <[email protected]> > > > > > Sent: Friday, December 02, 2011 12:20 AM > > > > > Subject: RE: [AVTCORE] Types of monitoring architectures; RE: > > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > > > > > > My replies below ... > > > > > -Albrecht > > > > > > > > > > > -----Original Message----- > > > > > > From: Qin Wu [mailto:[email protected]] > > > > > > Sent: Donnerstag, 1. Dezember 2011 02:42 > > > > > > To: Schwarz, Albrecht (Albrecht); [email protected] > > > > > > Cc: [email protected] > > > > > > Subject: Re: [AVTCORE] Types of monitoring > architectures; RE: > > > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > > > Hi, > > > > > > ----- Original Message ----- > > > > > > From: "Schwarz, Albrecht (Albrecht)" > > > > > > <[email protected]> > > > > > > To: "Qin Wu" <[email protected]>; <[email protected]> > > > > > > Cc: <[email protected]> > > > > > > Sent: Thursday, December 01, 2011 1:24 AM > > > > > > Subject: RE: [AVTCORE] Types of monitoring > architectures; RE: > > > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > > > > > > > > > My replies below inline, > > > > > > Albrecht > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Qin Wu [mailto:[email protected]] > > > > > > > Sent: Mittwoch, 30. November 2011 04:51 > > > > > > > To: Schwarz, Albrecht (Albrecht); [email protected] > > > > > > > Cc: [email protected] > > > > > > > Subject: Re: [AVTCORE] Types of monitoring > > architectures; RE: > > > > > > > I-D Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > > > > > Hi, > > > > > > > ----- Original Message ----- > > > > > > > From: "Schwarz, Albrecht (Albrecht)" > > > > > > > <[email protected]> > > > > > > > To: <[email protected]> > > > > > > > Cc: <[email protected]> > > > > > > > Sent: Tuesday, November 29, 2011 7:32 PM > > > > > > > Subject: [AVTCORE] Types of monitoring > > architectures; RE: I-D > > > > > > > Action: draft-ietf-avtcore-monarch-08.txt > > > > > > > > > > > > > > > > > > > > > > Dear All, > > > > > > > > > > > > > > > > there are different types of monitoring architectures, > > > > > > > particularily from perspective of QoE related performance > > > > > > parameters. > > > > > > > > Let's recall QoE (e.g., ITU-T P.10 Amendment 2): > > > > > > > > > > > > > > > > Quality of Experience (QoE): > > > > > > > > The overall acceptability of an application or > service, as > > > > > > > perceived subjectively by the end-user. > > > > > > > > NOTE 1 - Quality of experience includes the complete > > > > > > > end-to-end system effects (client, terminal, network, > > > > > > > services infrastructure, etc.). > > > > > > > > NOTE 2 - Overall acceptability may be influenced by user > > > > > > > expectations and context. > > > > > > > > > > > > > > > > Important for MONARCH: > > > > > > > > 1st ... perceived by end-user 2nd QoE includes the > > > > > > > > complete end-to-end sytem effects ... > > > > > > > > > > > > > > > > That said, present RTP monitoring architecture > in MONARCH > > > > > > > according clause 3 is not specific on the type of > monitoring > > > > > > > architecture. For instance, Fig. 1, it is > possibly supposed > > > > > > > that the "RTP Sender" and "RTP Receiver" entities > are equal > > > > > > > to a terminal/user equipment (UE). This would be an > > > > > > > end-to-end IP network scenario. > > > > > > > > > > > > > > > > However, the "RTP Sender" and "RTP Receiver" > entities may > > > > > > > be also located at the edge of an IP network, e.g. in a > > > > > > > gateway for IP-to-non-IP interworking, i.e. an UE > located in > > > > > > > the non-IP network part. > > > > > > > > Note: such scenarios are considered by MEGACO gateways > > > > > > > (I've Cc'd megaco list). > > > > > > > > > > > > > > > > An RTP Sender/Receiver located NOT in the UE > > would question > > > > > > > the value of RTP/RTCP QoE related performance > measurements > > > > > > > (because the UE is located outside the RTP domain). > > > > > > > > > > > > > > > > Conclusions: > > > > > > > > - the set of meaningful performance metrics may be > > > > > > > dependent on the location of the RTP Sender/Receiver, e.g. > > > > > > > whether in a UE, gateway, ... > > > > > > > > - don't see any impact on transport level metrics > > > > > > > > - ... but the set of meaningful application > level metrics > > > > > > > > > > > > > > > > Proposal for MONARCH: > > > > > > > > #1: insert sub-clause title "3.1 End-to-end IP network > > > > > > > architecture" below clause 3 > > > > > > > > > > > > > > > > #2: add a sub-clause 3.2 at the end of clause > 3, sth like > > > > > > > > > > > > > > > > "3.2 RTP Sender/Receiver entities located in > network nodes > > > > > > > > The location of the RTP Sender/Receiver entity > may impact > > > > > > > the set of meaningful metrics. > > > > > > > > For instance: application level metrics for QoE related > > > > > > > performance metrics are questionable (or doesn't > really make > > > > > > > sense at all) when measured in a network node > (terminating > > > > > > > the RTP) instead of the user equipment." > > > > > > > > > > > > > > > > Something like this would help to avoid confusion. > > > > > > > > I even believe that a QoE measurement in a network node > > > > > > > would violate the QoE definition. Would be rather > something > > > > > > > like QoE* ("remote QoE"):-( > > > > > > > > > > > > > > > > Such information would improve the MONARCH doc in > > > my opinion. > > > > > > > > Sorry for that late comment. > > > > > > > > Any views? > > > > > > > > > > > > > > [Qin]: > > > > > > > Albrrecht, if you follow ealry list discussion on > > > > > > > draft-hunt-avt-monarch-01, you will see the rough > consensus > > > > > > > to position this document was this daft should focus on > > > > > > > guidelines for defining reporting blocks. That is > to say the > > > > > > > main purpose of MONARCH draft > > > > > is how to > > > > > > > provide guidelines for the development of new > RTCP XR block > > > > > > > types in XRBlock working group. > > > > > > > > > > > > [ABS] ... then the title "monitoring architectures" is > > > misleading. > > > > > > Proposal: keep title, revise scope section on focus > > > > > > > > > > > > [Qin]: No, the title is *RTP* monitoring > architecture, we can > > > > > > not expand scope into IP monitoring architecture. > > > > > > > > > > [ABS] That's wasn't the intent! Did just focus on the > key word. > > > > > > > > > > > > > > > > > > > > > > > > > Therefore how and where to collect the metric from RTP > > > > > > > endpoint is not scope of this document, in my > opinion. since > > > > > > > you may have many ways to do this and different > vendors have > > > > > > > their different appoaches. It will be better to > leave this > > > > > > > beyond the scope. But you are right, it will be more > > > > > > > reasonable to measure QoE related performance > metric at the > > > > > > > RTP receiver. > > > > > > > > > > > > [ABS] I would disagree. At least your statement should be > > > > > > conditional, sth like "QoE related performance > metrics may be > > > > > > measured in a RTP receiver, IF the RTP receiver function is > > > > > > located in user equipment (e.g. IP terminal), because QoE > > > > > > performance metrics are tightly coupled to the > point of view > > > > > > of a 'user'. > > > > > > ... IF NOT, then ..." > > > > > > > > > > > > [Qin]: I am not sure user equipment or IP terminal is the > > > > > > right term from RTP perspective. > > > > > > > > > > > > Also if you read P.NAMS, P.NAMS model for calculating QoE > > > > > > related metric can be placed either at the network or at > > > > the client. > > > > > > So I disagree with what you said. > > > > > > > > > > [ABS] Not convinced at all. > > > > > Guess you are referring to the "mid-point" models, right? > > > > > The usage of such that models depends on "prior > knowledge ..." > > > > > information. > > > > > Thus, the applicability is conditional. You may not > make such a > > > > > general statement. > > > > > > > > > > > > > > > > > > > > > > Also as I said, how and where to collect the metric > from RTP > > > > > > endpoint is not scope of this document. It depends on the > > > > > > model you are choosing, e.g., four operation modes > specified > > > > > > in P.NAMS. > > > > > > Apparently this should not be specified again in RTP > > > > > > monitoring architecture document. > > > > > > > > > > > > > > > > > > > > Another point is it is not clear to me how RTP > > monitoring has > > > > > > > to do with architectureend to end IP network > architecture . > > > > > > > this draft mostly focus on discussing RTP level stuff. > > > > > > > Therefore I am quite doubt that we should > describe anything > > > > > > > in this document like how RTP entties is mapped > into network > > > > > > > entities/nodes at > > > > the IP layer. > > > > > > > > > > > > [ABS] I don't got any problems to talk about architectural > > > > > > framework for monitoring in this document. Such > information is > > > > > > required and this is the only IETF AVT doc about it. > > > > > > The solution to this issue is rather simple to me: > > > > > > - split the MONARCH "monitoring architecture" in > > > > > > 1) a functional monitoring architecture (let's call it > > > 'FMA') and > > > > > > 2) a physical monitoring architecture (... 'PMA'). > > > > > > > > > > > > - the present MONARCH doc would describe the FMA at > the level > > > > > > of RTP entities (i.e., Fig. 1 entities, incl. all the RTP > > > > > > topology components according RFC 5117) > > > > > > > > > > > > - there are many options of functional-to-physical > mappings, > > > > > > i.e. how a FMA would be mapped on a PMA > > > > > > - the mapping is typically dependent on considered network > > > > > > architecture (like SIP, H.323, MGCP, IMS, wireless, etc > > > networks) > > > > > > > > > > > > - the present MONARCH doc would describe the FMA-to-PMA > > > > > > mapping IF all RTP receiver/sender entities would > be located > > > > > > in physical IP terminals (UEs) > > > > > > - etc > > > > > > > > > > > > [Qin]: I can understand your point, but you can not do that. > > > > > > Since this document is only focus on *RTP* monitoring > > > > > > architecture, that is what it said in AVTCore milestone: > > > > > > " > > > > > > > > > > > > Goals and Milestones: > > > > > > > > > > > > Feb 2011 - Submit Monitoring Architecture for RTP for > > > > > Informational > > > > > > > > > > > > " > > > > > > > > > > [ABS] If you go back to my first email on this > subject, and if > > > > > you look at my proposal: that's not a lot, nothing which > > > > > violates the charter, goals and milestones. > > > > > > > > > > > > > > > > Also if you really don't see how to map FMA to PMA, you may > > > > > > look at the P.NAMS models specifed in ITU-T P.NAMS. > > > > > > As for how to use RTP monitoring architecture or > RTP XR Report > > > > > > in the IMS network architecture, you may look at: > > > > > > http://tools.ietf.org/html/rfc6035 > > > > > > > > > > [ABS] That's the SIP reporting interface, i.e., applicable > > > > > primarily for physical IP user equipment with embedded RTP > > > > > sender/receiver function and SIP UA function. > > > > > However, the applicability of RFC 6035 is limited for a > > > > > SIP-to-PSTN gateway (because the RTP sender/receiver would be > > > > > located NOT in user equipment. Also the P.NAMS > mid-point model > > > > > fails for such a scenario. > > > > > > > > > > > ITU-T H.248.48. > > > > > > But I haven't check the current status of H.248.48. > > > > > > > > > > [ABS] Work is finalized, see > > > > > http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T09-SG16-1 > > > > > 11121-TD-PLEN-0419 > > > > > > > > > > > > > > > > > > > > > > > > > But as the author of this document, I am > interested and open > > > > > > > to other opinions.:-) > > > > > > > > > > > > [ABS] Like to add a further aspect: a "functional > monitoring > > > > > > architecture" may be considered as a network overlay, > > > > > > something which adds additional capabilities (here: > > > > > > measurement services, reporting services on top of > basic RTP > > > > > > services). > > > > > > Such an overlay concept is nothing new: e.g., the > MultiService > > > > > > Forum did define a "Performance Measurement & Monitoring > > > > > > (PMM)" overlay network, or IETF RMON may be also > considered as > > > > > > such. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Albrecht > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > > >> From: [email protected] > > [mailto:[email protected]] On > > > > > > > >> Behalf Of [email protected] > > > > > > > >> Sent: Dienstag, 29. November 2011 08:56 > > > > > > > >> To: [email protected] > > > > > > > >> Cc: [email protected] > > > > > > > >> Subject: [AVTCORE] I-D Action: > > > > > draft-ietf-avtcore-monarch-08.txt > > > > > > > >> > > > > > > > >> > > > > > > > >> A New Internet-Draft is available from the on-line > > > > > > > >> Internet-Drafts directories. This draft is a work > > > item of the > > > > > > > >> Audio/Video Transport Core Maintenance Working Group > > > > > of the IETF. > > > > > > > >> > > > > > > > >> Title : Monitoring Architectures for RTP > > > > > > > >> Author(s) : Qin Wu > > > > > > > >> Geoff Hunt > > > > > > > >> Philip Arden > > > > > > > >> Filename : draft-ietf-avtcore-monarch-08.txt > > > > > > > >> Pages : 25 > > > > > > > >> Date : 2011-11-28 > > > > > > > >> > > > > > > > >> This memo proposes an architecture for > > > extending RTCP with > > > > > > > >> a new RTCP > > > > > > > >> XR (RFC3611) block type to report new metrics > > > > > regarding media > > > > > > > >> transmission or reception quality, following RTCP > > > > guideline > > > > > > > >> established in RFC5968. This memo suggests > that a new > > > > > > > block should > > > > > > > >> contain a single metric or a small number of metrics > > > > > > > relevant to a > > > > > > > >> single parameter of interest or concern, rather than > > > > > > > containing a > > > > > > > >> number of metrics which attempt to provide > > full coverage > > > > > > > >> of all those > > > > > > > >> parameters of concern to a specific application. > > > > > > > Applications may > > > > > > > >> then "mix and match" to create a set of > blocks which > > > > > > > >> covers their set > > > > > > > >> of concerns. Where possible, a specific > > block should be > > > > > > > >> designed to > > > > > > > >> be re-usable across more than one application, for > > > > > > > example, for all > > > > > > > >> of voice, streaming audio and video. > > > > > > > >> > > > > > > > >> > > > > > > > >> A URL for this Internet-Draft is: > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-08.txt > > > > > > > >> > > > > > > > >> Internet-Drafts are also available by anonymous FTP at: > > > > > > > >> ftp://ftp.ietf.org/internet-drafts/ > > > > > > > >> > > > > > > > >> This Internet-Draft can be retrieved at: > > > > > > > >> > > > > > > > > > > > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-08.txt > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> Audio/Video Transport Core Maintenance [email protected] > > > > > > > >> https://www.ietf.org/mailman/listinfo/avt > > > > > > > >> > > > > > > > > _______________________________________________ > > > > > > > > Audio/Video Transport Core Maintenance [email protected] > > > > > > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > > = > > > > > _______________________________________________ > > > > > Audio/Video Transport Core Maintenance [email protected] > > > > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > > > > > _______________________________________________ > Megaco mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/megaco > _______________________________________________ Audio/Video Transport Core Maintenance [email protected] https://www.ietf.org/mailman/listinfo/avt