[SIPForum-discussion] Post Dialing Delay (PDD)

Fri Apr 18 19:12:57 UTC 2008

Right, no biggie, but essentially for SIP the "PDD" time for a phone call is typically the time from when the INVITE is sent, to when a provisional 18x response is received (or a 200 or other response if there was no 18x).  So for example, from the perspective of your phone, when you press that last digit it generates an INVITE, and when it gets a 180 that signifies the ringing event in some form or other.  (I'm speaking in general common use, but there are exceptions to this)

While you could certainly measure that on the phone itself, it's fairly rare to do so in practice, and instead the Enterprise or Provider's SIP systems do that (proxies/SBCs/gateways/whatever).  Even if separate elements measure it, what's nice is that PDD does not depend on absolute time synchronization, just relative difference inside each element - because the response is part of the same SIP request transaction and will be received by whichever and each system that forwarded the request.

If you have no such SIP systems, and only endpoints/phones, then you could get such measurements off the phones, or have them report it somewhere somehow.  For example, draft-ietf-sipping-rtcp-summary-02.txt provides a way for UA's to report their media QoS measurements to central systems using the SIP PUBLISH method. (Though whether that mechanism will become widely implemented by phones I don't know)  Or you could certainly monitor the network LANs using mirror ports and try to discern it as you suggested, if the phones don't do TLS or IPSEC.

-hadriel

________________________________
From: Halit Sakca [mailto:sakcahalit at hotmail.com]
Sent: Friday, April 18, 2008 2:19 PM
To: Hadriel Kaplan; mario.baron at ericsson.com; discussion at sipforum.org
Subject: RE: [SIPForum-discussion] Post Dialing Delay (PDD)

Hadriel,

what I understand from PDD is http://www.voip-news.com/dictionary/pdd// and when we think about a NGN network as you know we will need separate elements that will have conversations.

Basically I thought Mario was asking a PDD "time" what I suggested him is a basic measurement via tools. (and how to do it)

If it is not related with subject sorry about that.

Selamlar,
Halit Sakca

________________________________
From: HKaplan at acmepacket.com
To: sakcahalit at hotmail.com; mario.baron at ericsson.com; discussion at sipforum.org
Date: Fri, 18 Apr 2008 14:02:25 -0400
Subject: RE: [SIPForum-discussion] Post Dialing Delay (PDD)
I'm not sure I understand what you mean?  Which part of the "network" do you mean, and what type of "health"?
PDD isn't really useful for network health checks in my opinion, although some people use it for determining peer provider "quality", just as they use ASR.  It's a very coarse way of determining this, because obviously the PDD or ASR is unique per called destination and even time of day, not per next-domain, so it has to be carefully "averaged" over long periods of time with a large data set to make smart decisions about the relative quality among multiple peers.  Many SIP systems have that ability.
If you mean measuring the PDD for a specific UA endpoint from the provider, there are ways of doing that too - for example using PRACKs for the provisional response.
If you mean accurate measurement of end-end network layer health for media, RTP and RTCP quality measurements are often employed, and obviously SBC's have been measuring that for ages.

But anyway, if you feel something else is needed for SIP layer measurements that isn't specified in draft-ietf-pmol-sip-perf-metrics-00.txt, then I encourage you join the PMOL WG mailing list and email your comments there so that they can be discussed and included in the draft. (to join go to https://www1.ietf.org/mailman/listinfo/pmol)

-hadriel

________________________________
From: Halit Sakca [mailto:sakcahalit at hotmail.com]
Sent: Friday, April 18, 2008 1:36 PM
To: Hadriel Kaplan; mario.baron at ericsson.com; discussion at sipforum.org
Subject: RE: [SIPForum-discussion] Post Dialing Delay (PDD)

you are right for far end perspective we don't need a mirrored port. BUT what about network health check I mean this measurement should be done from whole elements that will use 180 Ringing anyway.

Selamlar,
Halit Sakca
________________________________
From: HKaplan at acmepacket.com
To: sakcahalit at hotmail.com; mario.baron at ericsson.com; discussion at sipforum.org
Date: Fri, 18 Apr 2008 12:35:53 -0400
Subject: RE: [SIPForum-discussion] Post Dialing Delay (PDD)

________________________________
From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of Halit Sakca
Sent: Friday, April 18, 2008 11:43 AM

> Can Anyone help me how we can measure and verify that the PDD is under
> a certain value?
>
> Is there any ITU-T value for the PDD to take as a reference?
>
> Our NGN provides the IP connetivity to IP carriers through Acmepacket SBCs.

For doing that mentioned above you will need a mirror port on switch anyway.
If you can not set the time of all components same via NTP and trace separately.

No, you don't need to do that with mirroring - most SBC's measure that time already and report it, as do other SIP device types.  PDD can typically be fully measured at one spot, although it may not represent the user's perceived PDD if it's not measured at the originating provider.
Also, you don't really need NTP, because the number is a differential value measured by the same entity that sends the INVITE request.  Thus the local view of global time does not really matter. (it does matter for reporting/determining when calls are made, but not for their delays or durations)

-hadriel

________________________________
Pahalı telefon faturaları? Windows Live Messenger'dan ücretsiz ve sınırsız bilgisayardan bilgisayara aramalar - buradan ÜCRETSİZ yükleyin! Buraya tıkla!<http://get.live.com/messenger/overview>

________________________________
Aileye katılmanın tam zamanı! Windows Live Messenger'ın 2008 versiyonunu yükleyin! Ücretsiz! Buraya tıkla!<http://get.live.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20080418/303c92e5/attachment-0002.html>