Subject: [Megaco] H.248 processing time

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 30 Nov 2006 10:52:30 -0500

I received a note from an engineer who is deployment an NGN network and 
has measured the following components of end-to-end call setup time:

- V5 processing (CDMA2000): 1 second
- H.248 processing:         3 seconds
- SS7 processing:           4 seconds

Does anyone want to comment either directly to me (to be forwarded to 
the original party) or on the list about typical H.248 processing times 
as part of call setup?

The original request was actually for a pointer to a standard governing 
H.248 processing times. I'm not aware of such a standard, though 30 
years ago ITU-T Study Groups 2 and 11 used to work on that sort of 
thing. I know SG 11 doesn't do that now, but maybe SG 2 does. Does 
anyone know?

Tom Taylor

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: [email-masked]
Date: Thu, 30 Nov 2006 18:08:06 +0100

Tom,

in general:
   your measurement data is lacking the indication of the underlying
   measurement points (MP).
   E.g. are the MPs related to external network element interfaces, and/or
   internal ones? What does "H.248 processing" means: MPs at the "MGC
   API"?, MPs at the H.248 interface?, a single MGC-MG tandem or are two
   tandems or one MGC and two associated MGs? ...
The measurements are questionable without information about the MPs IMHO.

>thing. I know SG 11 doesn't do that now, but maybe SG 2 does. Does

I'm not aware of an explicit document, but following references touching
this performance topic:

1) Y.1530 (05/04) Call processing performance for voice service in hybrid
IP networks
   => Appendix II: Measurement methods for estimating VoIP signalling
   performance

2) H.Sup6 (04/06) Decomposed gateways - Control load quantum - Busy hour
context attempts (BHCoA) and busy hour session attempts (BHSA)
   => e.g. H.248 Context service time
   => H.248 "MG processing time" based on service/waiting times, see Figure
   9
   It has to be noted that the scope of this supplement was limited on
   qualitative considerations only, i.e., any type of quantitative
   objectives are not addressed (see clause 1.2).

3) Telcordia GR-3059 CORE (03/00) Generic Requirements for Voice over
Packet End-to-End Performance
      => useful definition of MPs
      => § 5: Network Element Performance
      => e.g. "H.248 processing time" objectives,
      => e.g. call setup delay objectives: MGC budget of 200 ms for CSD, MG
budget of 100 to 200 ms (dependent on access or trunking MG)

4) Draft ETSI TRxxxx (WI-06024) IMS Benchmark Procedure; Analysis of ITU-T
Q.543 for Reference Workloads
   => you may find some initial design objectives for processing times of
   IMS/NGN equipment

Concerning user plane, e.g. like transfer delay, Y.1541 provides some
objectives for H.248 MGs:
5) Y.1541 (02/06) Network performance objectives for IP-based services
   => Appendix II: Measurement methods for estimating VoIP signalling
   performance

Best regards,
Albrecht

                      "Tom-PT Taylor"                                                                                                 
                      <[email-masked]         To:      [email-masked]                                                               
                      om>                      cc:                                                                                    
                                               Subject: [Megaco] H.248 processing time                                                
                      30.11.2006 16:52                                                                                                

Tom Taylor

---

From: "Annie Benitez Pelaez" <[email-masked]>
Date: Thu, 30 Nov 2006 12:24:43 -0500

All,

Is there a way to re-start both profile and H.248 version negotiation on an
existing H.248 control association?

Allow me to explain further the particular case I had in mind...

Let there be a succesful H.248 control association established between MGC-1
and MG-1 (say they negotiated to version 2).
Let MGC-1 restart.

Therefore MG-1 may notify an inactivity timeout event, that message will
fail to be responded (since MGC-1 is restarting), then MG-1 will continue to
try to send ServiceChange with Disconnected Method (assuming there's no
secondary MGC configured here).

Once MGC-1 restarts, MGC-1 gets the ServiceChange Disconnected from MG-1
(encoded in v2 since that was previously negotiated). 

So at this point is there a way for MGC-1 to initialized profile and version
negotiation? And if so how? (one way would be to have the MGC send down a
restart to the MG, but let's assume we don't want to clear any state on the
MG...)

I'd appreciate your thoughts on this one...
Thanks!

Annie

---

From: Ashish Singh <[email-masked]>
Date: Thu, 30 Nov 2006 12:23:44 -0800

Version negotiation is optional in Servicechange message with 
Disconnected method. So I think MG can send version and profile field 
even in Disconnected case and do version negotiation.

I am giving an example where doing version negotiation is useful in 
disconnected case. Let say MGC-1 goes down and comes up with higher 
version. In that case, MGC1 would expect version negotiation even if its 
the same MGC instance.

Thanks
Ashish

---

From: "Maridi Raju Makaraju\(Raju\)" <[email-masked]>
Date: Thu, 30 Nov 2006 15:26:48 -0600

Annie,

Any Initial Service Change on ROOT with which MG announces it's availability
is considered as "Registration". So, the all ROOT service change methods except
Forced should be considered as part of registration.

Section 7 of version 2 spec says:
================
8) ServiceChange: The ServiceChange command allows the Media Gateway to notify the
Media Gateway Controller that a Termination or group of Terminations is about to be taken
out of service or has just been returned to service. ServiceChange is also used by the MG to
announce its availability to a MGC (registration), and to notify the MGC of impending or
completed restart of the MG.
================

Based on this I would assume that version negotiation and profile exchange can
happen in Disconnected method also.

Also, the section "11.3 Negotiation of protocol version" of H.248 spec says:
	>Protocol version negotiation may also occur at "handoff" and "failover" ServiceChanges.

Thanks
Raju

> -----Original Message-----
> From: Annie Benitez Pelaez [mailto:[email-masked]]
> Sent: Thursday, November 30, 2006 11:25 AM
> To: [email-masked]
> Subject: [Megaco] Version/Profile Re-Negotiation
> 
> 
> All,
>

---

From: "Maridi Raju Makaraju\(Raju\)" <[email-masked]>
Date: Thu, 30 Nov 2006 12:08:11 -0600

Annie,

Thanks
Raju

---

From: "Annie Benitez Pelaez" <[email-masked]>
Date: Thu, 30 Nov 2006 18:43:10 -0500

Ashish/Raju,

Thanks for your responses...

I guess since the MG will never know when the MGC may have been rebooted
(vs. simple a timeout on the H248 control interface for say a link failure
for example) then is it expected that those Disconnected messages are
encoded in Version 1 and include Version Negotiation in the Service Change
command..?

Since a Disconnected isn't really starting a new control association (in
theory), that's why it seems a bit odd to me I suppose, but I see no other
way around it...

Thx,
Annie

-----Original Message-----
From: Ashish Singh [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 3:24 PM
To: Annie Benitez Pelaez
Cc: [email-masked]
Subject: Re: [Megaco] Version/Profile Re-Negotiation

Version negotiation is optional in Servicechange message with Disconnected
method. So I think MG can send version and profile field even in
Disconnected case and do version negotiation.

I am giving an example where doing version negotiation is useful in
disconnected case. Let say MGC-1 goes down and comes up with higher version.
In that case, MGC1 would expect version negotiation even if its the same MGC
instance.

Thanks
Ashish

Annie Benitez Pelaez wrote:
> All,
>
> Is there a way to re-start both profile and H.248 version negotiation 
> on an existing H.248 control association?
>
> Let there be a succesful H.248 control association established between 
> MGC-1 and MG-1 (say they negotiated to version 2).
> Let MGC-1 restart.
>
> Therefore MG-1 may notify an inactivity timeout event, that message 
> will fail to be responded (since MGC-1 is restarting), then MG-1 will 
> continue to try to send ServiceChange with Disconnected Method 
> (assuming there's no secondary MGC configured here).
>
> Once MGC-1 restarts, MGC-1 gets the ServiceChange Disconnected from 
> MG-1 (encoded in v2 since that was previously negotiated).
>
> So at this point is there a way for MGC-1 to initialized profile and 
> version negotiation? And if so how? (one way would be to have the MGC 
> send down a restart to the MG, but let's assume we don't want to clear 
> any state on the
> MG...)
>

---

From: Ashish Singh <[email-masked]>
Date: Thu, 30 Nov 2006 18:34:13 -0800

Annie,

Even Handoff and Failover doesn't really start a new control 
association, but H.248.1 recommends to do version negotiation in those 
case. So I think disconnected should also be treated in similar way.

Regards
Ashish