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

From: David R Oran <[email-masked]>
Date: Mon, 18 Apr 2005 11:44:08 -0400

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]

_______________________________________________
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: "Amy Pendleton" <[email-masked]>
Date: Mon, 18 Apr 2005 11:22:26 -0400

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. 

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.

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:

> the defined event does include metrics that are not currently in scope 

> 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 

> > Cc: Rohan Mahy; Alan Clark; [email-masked]; [email-masked]; 
> I screened my local list archive and can't find any conclusion on this
> 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 
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]