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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 4 Oct 2005 14:31:36 -0600

Amy, Alan and all,

   Thanks for the updated ID.

   Just 2 or 3 quick comments after a brief scan on the update draft-johnston-sipping-rtcp-summary-07.txt:

--- 1. Payload type and use of encoding name in PD
The text says:
> ; PayloadDesc provides a text description of the codec in PayloadType
>   PayloadDesc  = "PD" COLON word

and the example in the ID revision has:
>    SessionDesc=PT:0 PD:G.711 SR:8000 FD:20 FPP:2 PLC:3 SSUP:on
                              ^^^^^
This is an issue. If the payload type is PT, the description must be PCMU. Please use the encoding name registered with IANA. What concerns me is that the BNF does not provide any means to enforce the requirements: could any MUST requirement be added to provide better guidance to implementers?

--- 2. QoEEstAlg:VQMonv2.1
For the purpose of this ID, any reason why you could not use a well-known standard for MOSCQEstAlg and use G.107 in the example?
Using a vendor-proprietary algorithm like VQMonv2.1 does not seem to bring much...

The other issue is the lack of BNF definition for MOSCQEstAlg values. You have some examples in the form of comments in:
>   MOSCQEstAlg = "MOSCQEstAlg" COLON word ; "PESQ", "G.107", or other

That means one vendor will use MOSCQEstAlg:G.107 and another one will put MOSCQEstAlg:ITU-T G.107, and some others will start appending the version or the last published date of the spec, etc.

I haven't done a full review but thought the first 2 comments were important to note.

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

I agree that use of CN in general should be reported as its use may impact quality.  Should the type (G.729 annex B versus RFC3389) also should be provided, or is that sufficiently implied by the payload type field and does it really matter?  Also, I recognize that the sample rate should also be added as it can differ from the codec's sample rate.
While we are at, perhaps it is also important to note use of silence suppression?  I think a simple yes/no type would suffice.
For other things beyond current scope, perhaps offering an extension field for coder specific information would work? 
Thanks, 
Amy 
-----Original Message----- 
From: David R. Oran [mailto:[email-masked]] 
Sent: Monday, April 18, 2005 2:31 PM 
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 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. 

_______________________________________________
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: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 4 Oct 2005 14:37:47 -0600

> >    SessionDesc=PT:0 PD:G.711 SR:8000 FD:20 FPP:2 PLC:3 SSUP:on
                           ^^^^^
And the comment should have been more precise as well:
If the payload type is PT==0, the payload description must be PD:PCMU.

> PCMU. Please use the encoding name registered with IANA. What concerns
> me is that the BNF does not provide any means to enforce the
> requirements: could any MUST requirement be added to provide better
> guidance to implementers?

Jean-François