Subject: Re: [Sipping] Re: WGLC: SIP service quality reporting

From: "David R. Oran" <[email-masked]>
Date: Mon, 18 Apr 2005 15:31:16 -0400

On Apr 18, 2005, at 2:27 PM, Amy Pendleton wrote:

> I am not implying that anyone is trying to halt the progress. From my 
> perspective we were making a great deal of progress but lately the 
> progress has been impeded by attempting redefine the scope to 
> reporting RTP media quality generically.  If we simply limit the event 
> to voice quality only, while allowing very simple extension for future 
> usage for voice only, it should be easy to finish this draft.  I do 
> agree that the definition of the session information, in particular 
> the codec and address information, needs to be clearly defined to 
> ensure it work for most audio codecs.
>
> What I currently have in the syntax defintion for the reduce session 
> description is the following:
>
>         SessionDescription  = ("SessionDesc") EQUAL
>                                PayloadType WSP
>                                [PayloadDesc WSP]
>                                [SampleRate WSP]
>                                [FrameSize WSP]
>                                [PacketizationRate WSP]
>                                [FramesPerPacket WSP]
>                                PacketLossConcealment
>
These may be adequate for common situations, but what about things that 
appear in coder-specific fmtp= fields? How, for example, do you know if 
comfort noise is in use for the integral G.729 CN payloads?

>         PayloadType  = "PT" COLON (1*3DIGIT / notAvail)
>         PayloadDesc  = "PD" COLON alphanum [*alphanum]
>         SampleRate = "SR" COLON (1*5DIGIT / notAvail)
>         FrameSize  = "FS" COLON (1*3DIGIT / notAvail)
>         FramesPerPacket = "FPP" COLON (DIGIT / notAvail)
>         PacketizatonRate = "PR" COLON (1*3DIGIT / notAvail)
>         PacketLossConcealment  = ("PLC") COLON ("0" / "1" / "2" / "3")
>
>
> PayloadType will use the static IANA definitions used in both SDP 
> media description and the RTP payload type field. 
>
> PayloadDesc should be used like the rtpmap attribute line field 
> "encoding name where a particular codec does not have an IANA 
> definition or the implementer uses only dynamic payload types.
>
> SampleRate equates to the "clock rate" field of the rtpmap attribute. 
>
> Framesize provides the number of bytes in each frame in a packet.
>
> Frames per packet is self-explanatory; implementations frequently use 
> multiple frames per packet and this is important to capture for 
> accurately calculating jitter buffer performance and estimating the 
> impact of packet loss.
>
> Packetization rate express the same information as the "ptime" 
> attribute.
>
> Packet loss concealment is reused from RTCP XR defintion.
>
> There are likely things I have missed; can someone please share with 
> me what other parameters are needed for the audio (voice) media type?
>
> Thanks,
> Amy
>
> -----Original Message-----
> From: David R Oran [mailto:[email-masked]]
> Sent: Monday, April 18, 2005 10:44 AM
> To: Pendleton, Amy [NGC:B601:EXCH]
> Cc: Jean-Francois Mule; Alan Clark; [email-masked]; Sinnreich, 
> Heinrich (Henry Sinnreich); [email-masked]
> Subject: Re: [Sipping] Re: WGLC: SIP service quality reporting
>
>
>
> On Apr 18, 2005, at 11:22 AM, Amy Pendleton wrote:
>
> > David,
> >
> > I wasn't proposing any specific mechanism and I have left a [*token]
> > in the definition for extension currently. 
> >
> > I agree there were issues with the original format that would need to
> > be addressed, but there were many more dissenters than supporters of
> > this option.  Mostly I heard compliants about the fact that 
> collectors
> > of performance data, which would not normally need to parse SDP, must
> > now do so in order to obtain this voice quality information.   Also,
> > the syntax does not align with the current definition of this event,
> > and I would need to import the SDP constructs and rewrite the entire
> > event.  For an event that was intended to be fairly straightforward,
> > this has become ridiculously complex.
> >
> As I said, it isn't the syntax, it's the information carried in the SDP
> m= lines. Re-encode it any way you like, but there's plenty of stuff
> there and in a= and fmpt= that you need to make sense of what's being
> reported.
>
> > If any of those against SDP usage would like to chime in, feel free.
> > I am trying to keep this simple and get this work, which is very
> > important to many companies, completed.
> >
> No one argues that this isn't important. All the more reason that it be
> technically sound and complete. Recall that the suggestion to import
> SDP syntax was because of specific items missing without it. this is
> especially true for salable coders where you don't know much about
> what's really been negotiated without the options present in SDP.
>
> > Thanks,
> > Amy
> >
> > -----Original Message-----
> > From: David R Oran [mailto:[email-masked]]
> > Sent: Monday, April 18, 2005 7:44 AM
> > To: Pendleton, Amy [NGC:B601:EXCH]
> > Cc: Jean-Francois Mule; Sinnreich, Heinrich (Henry Sinnreich); Alan
> > Clark; [email-masked]; [email-masked]
> > Subject: Re: [Sipping] Re: WGLC: SIP service quality reporting
> >
> >
> >
> > On Apr 15, 2005, at 1:53 PM, Amy Pendleton wrote:
> >
> > > You are not the only one to point out that the title is not
> > > appropriate and I have reached the conclusion that you are right.
> > > Also, I have received numerous complaints about the use of SDP 
> lines
> > > while I only seem to have had one person, other than myself, in
> > > favor of it. Given these facts, I have two suggestions for changes
> > > to the
> > > draft:
> > >
> > > 1) Title goes back to "Voice Quality Reporting for SIP Sessions" or
> > > something along those lines.  If there are other suggestion, please
> > > chime in.  I don't want to tie this completely to RTCP XR though --
> > > the defined event does include metrics that are not currently in
> > scope
> > > for RTCP XR.  We were hoping for a draft that would allow other
> > > media types to be included, but that is not covered and it would be
> > > easy enough to define an extension or a new event type later.
> > >
> > I'm not one to obsess over titles, but here's a slightly modified,
> > future proof title proposal: "Media session quality reporting for
> > SIP". I'm ok with Amy's proposed title, but I *am* more than a little
> > nervous about the lack of clarity about what the extension mechanism
> > ought to be.
> >
> > > 2) Remove the SDP lines, go back to codec lines.  I am not crazy
> > about
> > > this, but there have sufficiently many compliants about the
> > complexity
> > > involved that I think the original definition was better suited.
> > >
> > Well, I object because the reason we switched to using SDP M= lines
> > was because the original definition did not give you enough
> > information to interpret the statistics properly. I'm not hung up on
> > the syntax but I'd like to hear arguments as to why people believe
> > they can properly process the other information without the
> > information from the SDP m= lines.
> >
> > > If anyone disagrees with these, please send something soon.
> > >
> > > Thanks,
> > > Amy
> > >
> > > -----Original Message-----
> > > From: Jean-Francois Mule [mailto:[email-masked]]
> > > Sent: Wednesday, April 13, 2005 5:01 PM
> > > To: Pendleton, Amy [NGC:B601:EXCH]
> > > Cc: Alan Clark; [email-masked]; [email-masked];
> > > Sinnreich,Heinrich (Henry Sinnreich)
> > > Subject: RE: [Sipping] Re: WGLC: SIP service quality reporting
> > >
> > >
> > > Amy,
> > > Thanks for the note. Inline.
> > > Jean-Francois
> > >
> > > You wrote:
> > > > -----Original Message-----
> > > > From: Amy Pendleton [mailto:[email-masked]]
> > > > Sent: Wednesday, March 30, 2005 1:49 PM
> > > > To: Jean-Francois Mule; Dean Willis
> > > > Cc: Rohan Mahy; Alan Clark; [email-masked];
> > [email-masked];
> > > > Gonzalo Camarillo; Sinnreich,Heinrich (Henry Sinnreich)
> > > > Subject: RE: [Sipping] Re: WGLC: SIP service quality reporting
> > > >
> > > > Jean-Francois,
> > > >
> > > [snip]
> > >
> > >
> > > > I do recall that you raised an issue on use of this reporting
> > > > mechanism for more than just voice applications.
> > > My email from 3/11 raised the inconsistencies of the draft in that
> > > area: the title of the ID is not inline with the rest of the text. 
> I
> > > will re-iterate that the original name, or something closer is much
> > > appropriate ("Extended RTCP Metric Reporting via SIP").
> > >
> > > > There was a brief
> > > > discussion on this topic
> > >                      ^^^^^
> > > I screened my local list archive and can't find any conclusion on
> > this
> > > one. Others (like Eric Burger) also expressed sticking with the 
> RTCP
> > > name. Can you point out to the "discussions" you are referring to?
> > >
> > > My main concern is summarized in my earlier comment: the text in 
> the
> > > ID does not nearly represent what "SIP service quality reporting"
> > > could mean to end-users or operators.
> > >
> > > If the goal was about defining a flexible mechanism for "SIP 
> Service
> > > quality reporting", some guidance on how to define metrics, how to
> > > consider service quality for SIP (one some users and operators care
> > > about may be the equivalent of the PSTN post-dial-delay), etc. I
> > don't
> > > think this ID is the place for doing that and I like the content as
> > it
> > > is. I just don't think "marketing" the ID as the overall "SIP
> > > Service quality reporting" does any good.
> > >
> > >
> > > > just prior to the first WGLC and I took away
> > > > that most people were happy with the usage of SDP lines for
> > > describing
> > > > the codec parameters.  My intention at this point is not to go
> > > > back
> > > to
> > > > the formats in version 5 but to keep the SDP lines but again,
> > > > let's discussion on the list.
> > > I think you are mixing the m= issue raised by Marc, Dean and others
> > > and my comments. I did not express any comments on the above, did 
> I?
> > >
> > > >
> > > > Regards,
> > > > Amy
> > >
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use
> > > [email-masked] for questions on current sip Use
> > > [email-masked] for new developments of core SIP
> > David R. Oran
> > Cisco Fellow
> > Cisco Systems
> > 7 Ladyslipper Lane
> > Acton, MA 01720 USA
> > Tel: +1 978 264 2048
> > Email: [email-masked]
> >
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: [email-masked]
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 18 Apr 2005 17:46:13 -0500

David,

Thanks sincerely for your early support and interest. Amy has done great
work and maybe you can now OK it?

Henry

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Monday, April 18, 2005 2:31 PM
To: Amy Pendleton
Cc: Jean-Francois Mule; Alan Clark; [email-masked]; Sinnreich, Heinrich
(Henry Sinnreich); [email-masked]
Subject: Re: [Sipping] Re: WGLC: SIP service quality reporting

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Amy Pendleton" <[email-masked]>
Date: Mon, 18 Apr 2005 14:27:03 -0400

I am not implying that anyone is trying to halt the progress. From my
perspective we were making a great deal of progress but lately the progress
has been impeded by attempting redefine the scope to reporting RTP media
quality generically.  If we simply limit the event to voice quality only,
while allowing very simple extension for future usage for voice only, it
should be easy to finish this draft.  I do agree that the definition of the
session information, in particular the codec and address information, needs
to be clearly defined to ensure it work for most audio codecs.

PayloadType will use the static IANA definitions used in both SDP media
description and the RTP payload type field.  

PayloadDesc should be used like the rtpmap attribute line field "encoding
name where a particular codec does not have an IANA definition or the
implementer uses only dynamic payload types.

Frames per packet is self-explanatory; implementations frequently use
multiple frames per packet and this is important to capture for accurately
calculating jitter buffer performance and estimating the impact of packet
loss.

Packetization rate express the same information as the "ptime" attribute.

There are likely things I have missed; can someone please share with me what
other parameters are needed for the audio (voice) media type?

Thanks,
Amy

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Monday, April 18, 2005 10:44 AM
To: Pendleton, Amy [NGC:B601:EXCH]
Cc: Jean-Francois Mule; Alan Clark; [email-masked]; Sinnreich, Heinrich

On Apr 18, 2005, at 11:22 AM, Amy Pendleton wrote:

> this option.  Mostly I heard compliants about the fact that collectors 

> > Also, I have received numerous complaints about the use of SDP lines 
> > area: the title of the ID is not inline with the rest of the text. I 
> > one. Others (like Eric Burger) also expressed sticking with the RTCP 
> > My main concern is summarized in my earlier comment: the text in the 
> > If the goal was about defining a flexible mechanism for "SIP Service 
> > and my comments. I did not express any comments on the above, did I?
> >
> > >
> > > Regards,
> > > Amy
> >
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]