Subject: RE: [Sipping] Session Establishment Efficiency Rate

From: "Marian Delkinov \(LN/EAB\)" <[email-masked]>
Date: Tue, 3 Apr 2007 12:28:28 +0200

Reza, 

Exactly because of the analogy with NER and the meaning it has as
telephony metric I wanted to make clear the right counters, including
for release codes, are used to achieve the same meaning in SIP. I didn't
understand for when you foresee the implementation?

Best regards!
Mario.

-----Original Message-----
From: Fardid, Reza [mailto:[email-masked]] 
Sent: Friday, 30 March, 2007 22:02
To: Marian Delkinov (LN/EAB); Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Mario,

What I had in mind when I proposed inclusion of SEER in this draft was a
SIP performance metric analogous to NER in the PSTN, within the
framework defined by Daryl:

Telephony Metric/Standard (ITU-T, BellCore, etc.) ==> SIP ETE Metric

Clearly some SIP metrics defined in this draft do not have a telephony
counterpart.  For the rest, IMO, it is good to stay within the above
framework and leave exclusion/inclusion of specific release codes from
defined metrics to implementation.

Regards,
Reza Fardid
Covad Communications

-----Original Message-----
From: Marian Delkinov (LN/EAB) [mailto:[email-masked]]
Sent: Thursday, March 29, 2007 1:07 AM
To: Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

I haven't got your opinion about my comments on the SEER definition.
Have you considered them? 
Would also be interested to know when a finalized document on the
performance metrics can be released. 

Thanks!

Best regards!
Mario.

-----Original Message-----
From: Marian Delkinov (LN/EAB)
Sent: Monday, 05 March, 2007 17:06
To: 'Daryl Malas'
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

In principle, I agree with you in case we considered this from a user
perspective - then 3xx is not final. However my idea behind including
the 3xx codes was based on the involvement of "#Invite" in the formula.
If a 3xx code would result in sending a new Invite, then it sounds
logical to me to add the 3xx codes in the numerator. (NB: RFC3261
defines 3xx responses as "final" for the SIP transaction, ref. to page
21, Final Response).

Best regards!
Mario.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Friday, 23 February, 2007 17:00
To: Marian Delkinov (LN/EAB)
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

I don't think 3xx codes should be included, since they would not be
considered a "Final" release cause code.  --Daryl

On Fri, 2007-02-23 at 12:22 +0100, Marian Delkinov (LN/EAB) wrote:
> Hi,
> 
> If the Network Efficiency Rate is designed to express the ability of 
> the network to deliver calls (in SIP terms one should perhaps say 
> "establish sessions"), I think that it might be reasonable to include 
> few more cases (cause codes) in the numerator: e.g. all redirection 
> 3xx codes, all 4xx except 408 codes and all 6xx codes. (If you agree 
> that those are the ones that exclude network failures, congestion and 
> any other network malfunction).
> 
> Actually it sounds fair to me if it's the opposite of the Ineffective 
> Session Attempts (ISA):
> SEER% =
> 	   Total # of Invite Requests - # of ISA
> ---------------------------------------------------- x 100
> 	   Total # of Invite Requests
> 
> What do you think?
> 
> Best regards!
> Mario.
> 
> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]]
> Sent: Friday, 23 February, 2007 01:14
> To: [email-masked]
> Subject: [Sipping] Session Establishment Efficiency Rate
> 
> A couple more people have expressed to me that this adaptation of the 
> ITU-T E.411 Network Efficiency Rate metric is very valuable.  The 
> snapshot of the metric from the draft is:
> 
> "This metric is similar to Session Establishment Rate, but it is 
> intended to exclude the effects of customer behavior and user agent 
> behavior.  Essentially, the attempts resulting with a final cause code

> of 480, 486, and 600 would be added to the SER numerator."
> 
> Does anyone else want to see this metric in the draft?  I personally 
> think it is an interesting metric.
> 
> Thanks...
> 
> --Daryl
> 
> 
> 
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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: "Fardid, Reza" <[email-masked]>
Date: Mon, 9 Apr 2007 11:05:15 -0700

Mario,

IMO, if the objective is to eliminate called party behavior from ASR
(and SER), minimally the following response codes need to be excluded:
User Busy		~480
RNA			~486
Busy Everywhere	~600

I fail to see how exclusion of 3xx, other 4xx, and 6xx codes (with the
possible exception of 603) will serve this objective.  

It appears that the metric you are proposing has a much broader scope.
Perhaps, the confusion is caused by the inclusion of "user agent"
behavior in the definition of SEER, which should only exclude the
effects of "called party" behavior.

Regards,
-Reza

-----Original Message-----
From: Marian Delkinov (LN/EAB) [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 3:28 AM
To: Fardid, Reza; Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Reza, 

Best regards!
Mario.

-----Original Message-----
From: Fardid, Reza [mailto:[email-masked]] 
Sent: Friday, 30 March, 2007 22:02
To: Marian Delkinov (LN/EAB); Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Mario,

Regards,
Reza Fardid
Covad Communications

-----Original Message-----
From: Marian Delkinov (LN/EAB) [mailto:[email-masked]]
Sent: Thursday, March 29, 2007 1:07 AM
To: Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

Thanks!

Best regards!
Mario.

-----Original Message-----
From: Marian Delkinov (LN/EAB)
Sent: Monday, 05 March, 2007 17:06
To: 'Daryl Malas'
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

Best regards!
Mario.

---

From: "Marian Delkinov \(LN/EAB\)" <[email-masked]>
Date: Tue, 10 Apr 2007 15:57:11 +0200

Reza,

As far as I know the standard telephony - it functions a bit
differently. For instance if a user activates a service as "Call
Diversion" (similar to redirect in SIP), it's the network that handles
that hidden for the calling party, i.e. the caller does not need to dial
another number. And when such case occurs, in terms of PSTN for  the
calling party it's 1 call (1 seizure produced) only. Or in NER formula
you will have:

(1 answer, or RNA, or BUSY etc)/ 1 call = 100% NER

If we try to apply same to SIP. When redirect is received, the UA has to
send another INVITE, right? (Tell me if I'm wrong). And if we count the
300 code as network failure, and assume the second INVITE is successful,
then we have:

1 OK /2 #INVITE = 50% SEER, which IMO isn't correct. Do you agree, or
please explain.

Best regards!
Mario.

-----Original Message-----
From: Fardid, Reza [mailto:[email-masked]] 
Sent: Monday, 09 April, 2007 20:05
To: Marian Delkinov (LN/EAB); Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Mario,

Regards,
-Reza

-----Original Message-----
From: Marian Delkinov (LN/EAB) [mailto:[email-masked]]
Sent: Tuesday, April 03, 2007 3:28 AM
To: Fardid, Reza; Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Reza, 

Best regards!
Mario.

-----Original Message-----
From: Fardid, Reza [mailto:[email-masked]]
Sent: Friday, 30 March, 2007 22:02
To: Marian Delkinov (LN/EAB); Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Mario,

Regards,
Reza Fardid
Covad Communications

-----Original Message-----
From: Marian Delkinov (LN/EAB) [mailto:[email-masked]]
Sent: Thursday, March 29, 2007 1:07 AM
To: Daryl Malas
Cc: [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

Thanks!

Best regards!
Mario.

-----Original Message-----
From: Marian Delkinov (LN/EAB)
Sent: Monday, 05 March, 2007 17:06
To: 'Daryl Malas'
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

Best regards!
Mario.

---

From: Daryl Malas <[email-masked]>
Date: Tue, 10 Apr 2007 11:07:54 -0600

It sends a new INVITE, but the call id doesn't change.  This allows
tools to identify it as the same call or 1 OK/ 1 INVITE = 100% SER.

--Daryl

---

From: "Marian Delkinov \(LN/EAB\)" <[email-masked]>
Date: Tue, 10 Apr 2007 20:39:59 +0200

Daryl,

I understand what you mean and with the condition about the same Call
ID, I agree with it. The reason for my comments as  I wrote you earlier,
was the inclusion of #INVITE in the formula. What you are talking about
should perhaps be described as #Call Attempts. Because if we consider
all INVITEs with same Call ID as 1 call attempt and put that in the
formula, then everything fits on place.

In that case the definition would look:

SEER = (#Invite w/200 OK + #480 + #486 + #600)/# Total Call Attempts

(with note e.g: #Total Call Attempts = # distinct(Call_IDs)

What worries me yet is how we handle the forking. 

Best regards!
Mario.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, 10 April, 2007 19:08
To: Marian Delkinov (LN/EAB)
Cc: Fardid, Reza; [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

--Daryl

> that hidden for the calling party, i.e. the caller does not need to 
> dial another number. And when such case occurs, in terms of PSTN for  
> the calling party it's 1 call (1 seizure produced) only. Or in NER 
> formula you will have:
> 
> If we try to apply same to SIP. When redirect is received, the UA has 
> to send another INVITE, right? (Tell me if I'm wrong). And if we count

> the 300 code as network failure, and assume the second INVITE is 
> successful, then we have:
> 

> for release codes, are used to achieve the same meaning in SIP. I 
> didn't understand for when you foresee the implementation?
> 
> Best regards!
> Mario.
> 
> What I had in mind when I proposed inclusion of SEER in this draft was

> a SIP performance metric analogous to NER in the PSTN, within the 

> > "establish sessions"), I think that it might be reasonable to 
> > include few more cases (cause codes) in the numerator: e.g. all 
> > redirection 3xx codes, all 4xx except 408 codes and all 6xx codes. 
> > (If you agree that those are the ones that exclude network failures,

> > congestion and any other network malfunction).
> > 
> > Actually it sounds fair to me if it's the opposite of the 
> > Ineffective Session Attempts (ISA):
> > SEER% =
> > A couple more people have expressed to me that this adaptation of 
> > the ITU-T E.411 Network Efficiency Rate metric is very valuable.  
> > The snapshot of the metric from the draft is:
> >

---

From: Daryl Malas <[email-masked]>
Date: Tue, 10 Apr 2007 13:14:45 -0600

Okay...I think I understand your point.  The denominator needs to be
clarified in Section 3.6 and then relative to SEER.  It needs to make
sure it does not include INVITE's that are redirected or similar, as
this will skew the data.  Is this what you are referring to?

--Daryl

---

From: "Marian Delkinov \(LN/EAB\)" <[email-masked]>
Date: Wed, 11 Apr 2007 12:54:53 +0200

Hi Daryl,

Precisely! 

Best regards!
Mario.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, 10 April, 2007 21:15
To: Marian Delkinov (LN/EAB)
Cc: Fardid, Reza; [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

--Daryl

On Tue, 2007-04-10 at 20:39 +0200, Marian Delkinov (LN/EAB) wrote:
> ID, I agree with it. The reason for my comments as  I wrote you 
> earlier, was the inclusion of #INVITE in the formula. What you are 
> talking about should perhaps be described as #Call Attempts. Because 
> if we consider all INVITEs with same Call ID as 1 call attempt and put

> that in the formula, then everything fits on place.
> 

> > If we try to apply same to SIP. When redirect is received, the UA 
> > has to send another INVITE, right? (Tell me if I'm wrong). And if we

> > count
> > 1 OK /2 #INVITE = 50% SEER, which IMO isn't correct. Do you agree, 
> > or please explain.
> > 
> > Best regards!
> > Mario.
> > 

> > telephony metric I wanted to make clear the right counters, 
> > including for release codes, are used to achieve the same meaning in

> > SIP. I didn't understand for when you foresee the implementation?
> > 
> > Best regards!
> > Mario.
> > 

> > In principle, I agree with you in case we considered this from a 
> > user perspective - then 3xx is not final. However my idea behind 
> > including the 3xx codes was based on the involvement of "#Invite" in

> > the
> formula.
> > > intended to exclude the effects of customer behavior and user 
> > > agent behavior.  Essentially, the attempts resulting with a final 
> > > cause code
> > 
> > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Fardid, Reza" <[email-masked]>
Date: Wed, 11 Apr 2007 11:50:44 -0700

Agreed. This is a good change to both SER and SEER definitions.
There is, however, an implicit assumption that call-legs can be properly
correlated to produce Total Call Attempts.  A note to this effect may be
worth adding to either section 5.1 or 5.3.

Regards,
-Reza

-----Original Message-----
From: Marian Delkinov (LN/EAB) [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 3:55 AM
To: Daryl Malas
Cc: Fardid, Reza; [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

Hi Daryl,

Precisely! 

Best regards!
Mario.

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, 10 April, 2007 21:15
To: Marian Delkinov (LN/EAB)
Cc: Fardid, Reza; [email-masked]
Subject: RE: [Sipping] Session Establishment Efficiency Rate

--Daryl

---

From: Daryl Malas <[email-masked]>
Date: Wed, 11 Apr 2007 14:06:04 -0600

Good idea.  I'll add some context to it in those sections.
Thanks...--Daryl

---

From: Kapil Nayar <[email-masked]>
Date: Wed, 11 Apr 2007 21:28:53 +0100 (BST)

Hi

In section 9 the draft refers to using 302-Moved
Temporarily with contact header containing Replaces
parameter (technique from Dan Petrie). I am looking
for further details on this technique - in the sense
that including multiple contact headers with Replaces
parameters, exactly how legal it is use this technique
etc.

In essence can somebody point me to the draft/ RFC
which explains this technique in more detail?

thanks,
Kapil

      ___________________________________________________________ 
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html

---

From: [email-masked]
Date: Wed, 11 Apr 2007 16:50:28 -0400

From: Kapil Nayar <[email-masked]>

   In section 9 the draft refers to using 302-Moved Temporarily with
   contact header containing Replaces parameter (technique from Dan
   Petrie). I am looking for further details on this technique - in
   the sense that including multiple contact headers with Replaces
   parameters, exactly how legal it is use this technique etc.

If you have multiple contact headers with Replaces, it's processed
exactly as you'd expect -- the call forks, and the first successful
contact establishes the dialog.

   In essence can somebody point me to the draft/ RFC which explains
   this technique in more detail?

You know of RFC 3261, of course.  INVITE with Replaces is described in
RFC 3891.  I should probably reference those.

Dale

---

From: Kapil Nayar <[email-masked]>
Date: Fri, 13 Apr 2007 19:23:51 +0100 (BST)

Thanks Dale.
The scenario that I was indicating is slightly
different. 

There could be 2 incoming calls on target123 and when
executingset456 tries to do a call pickup, it is
offered both the calls by way of 302-redirection -
multiple contact header. Is it legal?
Now if 456 forks the INVITE (with replaces) to both
the callers, it is likely that both would succeed.
And, if we try to sustain only the first established
dialog, we may end up terminating the other call. It
may be important to implement some level of call
screening either at the Pickup-agent level or
optionally at the 456 level.

It was in this respect that I wanted a pointer to the
Dan Petrie's technique.

thanks,
Kapil

--- [email-masked] wrote:

> Temporarily with

      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

---

From: [email-masked]
Date: Mon, 16 Apr 2007 16:54:27 -0400

It is legal.

   Now if 456 forks the INVITE (with replaces) to both
   the callers, it is likely that both would succeed.
   And, if we try to sustain only the first established
   dialog, we may end up terminating the other call.

Yes, that could happen.

In practice (e.g., in the sipX system), the redirector always picks
one target dialog (usually the one that has been ringing the longest,
with the largest <duration> value), and returns a single Contact.

   It may be important to implement some level of call screening
   either at the Pickup-agent level or optionally at the 456 level.

I received the information verbally from Dan Petrie, so there is no
further reference you can follow.

Dale