Subject: [Sipping] comments on draft-malas-performance-metrics-05

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 18:04:55 -0500

Section 3.1.2 says it measures the delay from the register request to a 
failure response, yet the figure shows the interval as from REGISTER to 
the 200 OK, through the 401. This seems in conflict.

Section 3.2 claims that SRD is the same as PDD, but its not. Only the 
definition in 3.2.1 could be consider PDD.

Section 3.3 - why do you include timeouts here and not in the other 
metrics?

Section 3.4 - should consider when a BYE comes in the reverse direction

Section 3.5 - this is not the same as ASR. I thought that ASR includes 
failure cases which are still a consequence of successfully reaching the 
called party, most notably 'busy'. The metric you define is not that 
useful as a consequence. So you would need to include specific error 
response codes in here. That will not be an easy task. For example do 
you include 403?

Section 3.6 - why not other 5xx codes?

Section 3.8 - so what values of Reason are included in this?

Section 3.9 - this definition is vague. How do you know whether the 
response comes from the the intended proxy or UA?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Daryl Malas <[email-masked]>
Date: Thu, 02 Nov 2006 11:22:42 -0700

Thanks for questions, comments in-line...

> the 200 OK, through the 401. This seems in conflict.
This is intended to be an example of a failed REGISTER attempt due to
invalid authorization credentials.  I could have used a 400, 403, or 423
failure example as described in section 10.3 of 3261, if that makes more
sense.  The examples of failures is not intended to be exhaustive.  I
will likely change this to avoid confusion with the first "successful"
example.
> definition in 3.2.1 could be consider PDD.
I use to only include successfully setup calls for SRD, but some
suggested the same should be considered for failed calls as well.  The
thought is related to sending an INVITE and then waiting for any
response....even if it is a failure.  The result is the same to the user
experience of waiting...waiting...waiting...for either "ring-back", an
"early-media" automated failure response, or a "re-order" tone.  I have
debated this one both internal to Level 3 and externally with a number
of people.  Opinions are appreciated...the debate continues... :-)  I'll
bring this up in San Diego.
> Section 3.3 - why do you include timeouts here and not in the other 
Hmmm....wish I had a brilliant answer here.  I didn't try to make the
other failure situations exhaustive to include timeouts, but it seemed
to make sense to include this one in this section.  I hope that makes
sense.  I could add them to the others, but I'm just trying to avoid
(maybe hopelessly) in describing every failure situation in each metric.
> Section 3.4 - should consider when a BYE comes in the reverse direction
I can add this, as it probably makes sense to be described in this
section; also, I will be adding sections relative to the UAS, which will
also provide examples of this scenario.
> response codes in here. That will not be an easy task. For example do 
Actually, seizure has to do with "seizing" the media path in a voice
call.  The difficulty here is deciding exactly when "seizure" takes
place.  Since, an ACM and 183 w/SDP can indicate media is being sent
from the UAS or far-end switch, this could indicate "seizure".  However,
an ACM and 183 can also be sent without media being cut-through.  In
either of the previous two examples, media is only uni-directional.  In
order to avoid a difficult process of parsing ACM's and 183's to
determine if media was sent, I think "seizure" should only be considered
when media is bi-directionally sent.  This only occurs after a 200 OK is
sent and/or a ANM in the PSTN world.  A busy is consider a REL w/ cause
17...or a 486.  This is not considered "seizure".
> Section 3.6 - why not other 5xx codes?
I used a "commonly" defined set of ISUP codes in determining DPM
(Defects per Million) in the PSTN world.  I then used RFC 3398 to map
those to SIP release values.  Due to the 1:n relationship with ISUP:SIP,
this resulted in only the 3 SIP releases.  I am open to discussing
others.
> Section 3.8 - so what values of Reason are included in this?
RFC 3326 does not specify any for this condition, so I would suggest
this one should be used:
Reason: SIP ;cause=BYE ;text="Media Failure"
> response comes from the the intended proxy or UA?
Good point...this might be more easily described with a 408 or Timer F
expiry.