Subject: [Megaco] ServiceChange for a single termination (Cold Start)

From: "Barcotti, Glauco" <[email-masked]>
Date: Tue, 16 Apr 2002 15:26:22 -0400

Hi,

	Assuming a Gateway with 2 terminations, one of them is OK and the other is Malfunctioning. How should I proceed if I want to bring just the working termination up (Cold Start)?

a) If a ServiceChange is issued for ROOT termination MGC will think that all terminations are up and, until another ServiceChange is issued taking the defective Termination out of service, a call could be attempted on that defective termination

b) If a ServiceChange is issued just for the working Termination The ability to redirect the gateway to another MGC will be lost (See quotation from spec below) 

"The return from ServiceChange is empty except when the Root terminationID is used.  In that case it includes the following parameters as required:"

Thanks,
Glauco

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

---

From: "Barcotti, Glauco" <[email-masked]>
Date: Wed, 17 Apr 2002 10:10:23 -0400

Hi,

>>         Assuming a Gateway with 2 terminations, one of >them is OK and the other is Malfunctioning. How should I >proceed if I want to bring just the working termination >up (Cold Start)?
>>

>I don't agree. A ServiceChange for ROOT will indicate that the MG is up, not specific terminations. You would then have to send additonal ServiceChange commands, with Reason code 900, for each termination you want to put in-service.

The example in the spec (Appendix A) and the draft-madhu-megaco-callflows-00.txt tell me that when I address ROOT on a ServiceChange all terminations are addressed (One ServiceChange ROOT is sent and the terminations are available to use). Where did you find information about ServiceChange ROOT not bringing all terminations up? 

Thanks,
Glauco

>Regards,

>hrister Holmberg
>ricsson Finland

---

From: "SRD Wang JuLin" <[email-masked]>
Date: Thu, 18 Apr 2002 14:13:10 +0800

Hi,
Well,I send the ServiceChange for Root to Softswitch,it only send 4 modify messages  to RGW.So i can only use 4 out of the 8 phones located in RGW.
(I had provisioned 8 terminations into Softswitch

)
16:46:17.873046 eth0 < 10.10.0.122.11122 > coco2.2944: udp 114
                         4500 008e 028b 0000 3f11 63de 0a0a 007a
                         0a0a 0069 2b72 0b80 007a d67f 212f 3120
                         5b31 302e 3130 2e30 2e31 3232 5d0a 543d
                         317b 433d 2d7b 5343 3d52 4f4f 547b 5356
                         7b4d 543d 5253 2c52 453d 3930 312c 4144
                         3d31 3131 3232 2c50 463d 416e 616c 6f67
                         5f4c 696e 655f 496e 7465 726f 7065 7261
                         6269 6c69 7479 5f54 6573 745f 5072 6f66
                         696c 652f 312c 563d 317d 7d7d 7d0a
 
                          E^@ ^@.. ^B.. ^@^@  ?^Q  c.. ^J^J ^@ z
                         ^J^J ^@ i  + r ^K.. ^@ z ..^? ! /  1
                          [ 1  0 .  1 0  . 0  . 1  2 2  ]^J  T =
                          1 {  C =  - {  S C  = R  O O  T {  S V
                          { M  T =  R S  , R  E =  9 0  1 ,  A D
                          = 1  1 1  2 2  , P  F =  A n  a l  o g
                          _ L  i n  e _  I n  t e  r o  p e  r a
                          b i  l i  t y  _ T  e s  t _  P r  o f
                          i l  e /  1 ,  V =  1 }  } }  }^J
16:46:17.874841 eth0 > coco2.2944 > 10.10.0.122.11122: udp 62
                         4500 005a 2bdf 0000 4011 39be 0a0a 0069
                         0a0a 007a 0b80 2b72 0046 7f1d 212f 3120
                         5b31 302e 3130 2e30 2e31 3035 5d20 503d
                         317b 433d 2d7b 5343 3d52 4f4f 547b 5356
                         7b41 443d 3131 3132 322c 5046 3d43 4c53
                         2f31 2c56 3d31 7d7d 7d7d
 
                          E^@ ^@ Z  +.. ^@^@  @^Q  9.. ^J^J ^@ i
                         ^J^J ^@ z ^K..  + r ^@ F ^縙]  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  0 5  ]    P =
                          1 {  C =  - {  S C  = R  O O  T {  S V
                          { A  D =  1 1  1 2  2 ,  P F  = C  L S
                          / 1  , V  = 1  } }  } }
16:46:18.325927 eth0 > coco2.11122 > 10.10.0.122.11122: udp 164
                         4500 00c0 2bf3 0000 4011 3944 0a0a 0069
                         0a0a 007a 2b72 2b72 00ac 1537 212f 3120
                         5b31 302e 3130 2e30 2e31 3035 5d20 543d
                         3432 307b 433d 2d7b 4d46 3d61 6777 5f6a
                         756c 772f 327b 453d 3538 3938 3239 7b61
                         6c2f 6f66 7b73 7472 6963 743d 6578 6163
                         742c 454d 7b53 477b 6367 2f64 747d 2c45
                         3d33 3933 3231 377b 6464 2f63 657b 2044
                         4d3d 6469 616c 706c 616e 317d 2c61 6c2f
                         6f6e 7b73 7472 6963 743d 6578 6163 747d
                         2c67 2f73 637d 7d7d 2c61 6c2f 6f6e 7b73
                         7472 6963 743d 6578 6163 747d 7d7d 7d7d
 
                          E^@ ^@..  +.. ^@^@  @^Q  9 D ^J^J ^@ i
                         ^J^J ^@ z  + r  + r ^@.. ^U 7  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  0 5  ]    T =
                          4 2  0 {  C =  - {  M F  = a  g w  _ j
                          u l  w /  2 {  E =  5 8  9 8  2 9  { a
                          l /  o f  { s  t r  i c  t =  e x  a c
                          t ,  E M  { S  G {  c g  / d  t }  , E
                          = 3  9 3  2 1  7 {  d d  / c  e {    D
                          M =  d i  a l  p l  a n  1 }  , a  l /
                          o n  { s  t r  i c  t =  e x  a c  t }
                          , g  / s  c }  } }  , a  l /  o n  { s
                          t r  i c  t =  e x  a c  t }  } }  } }
16:46:18.329845 eth0 > coco2.11122 > 10.10.0.122.11122: udp 164
                         4500 00c0 2bf9 0000 4011 393e 0a0a 0069
                         0a0a 007a 2b72 2b72 00ac 1337 212f 3120
                         5b31 302e 3130 2e30 2e31 3035 5d20 543d
                         3432 317b 433d 2d7b 4d46 3d61 6777 5f6a
                         756c 772f 337b 453d 3538 3938 3239 7b61
                         6c2f 6f66 7b73 7472 6963 743d 6578 6163
                         742c 454d 7b53 477b 6367 2f64 747d 2c45
                         3d33 3933 3231 377b 6464 2f63 657b 2044
                         4d3d 6469 616c 706c 616e 317d 2c61 6c2f
                         6f6e 7b73 7472 6963 743d 6578 6163 747d
                         2c67 2f73 637d 7d7d 2c61 6c2f 6f6e 7b73
                         7472 6963 743d 6578 6163 747d 7d7d 7d7d
 
                          E^@ ^@..  +.. ^@^@  @^Q  9 > ^J^J ^@ i
                         ^J^J ^@ z  + r  + r ^@.. ^S 7  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  0 5  ]    T =
                          4 2  1 {  C =  - {  M F  = a  g w  _ j
                          u l  w /  3 {  E =  5 8  9 8  2 9  { a
                          l /  o f  { s  t r  i c  t =  e x  a c
                          t ,  E M  { S  G {  c g  / d  t }  , E
                          = 3  9 3  2 1  7 {  d d  / c  e {    D
                          M =  d i  a l  p l  a n  1 }  , a  l /
                          o n  { s  t r  i c  t =  e x  a c  t }
                          , g  / s  c }  } }  , a  l /  o n  { s
                          t r  i c  t =  e x  a c  t }  } }  } }
16:46:18.333869 eth0 > coco2.11122 > 10.10.0.122.11122: udp 164
                         4500 00c0 2c01 0000 4011 3936 0a0a 0069
                         0a0a 007a 2b72 2b72 00ac 1037 212f 3120
                         5b31 302e 3130 2e30 2e31 3035 5d20 543d
                         3432 327b 433d 2d7b 4d46 3d61 6777 5f6a
                         756c 772f 357b 453d 3538 3938 3239 7b61
                         6c2f 6f66 7b73 7472 6963 743d 6578 6163
                         742c 454d 7b53 477b 6367 2f64 747d 2c45
                         3d33 3933 3231 377b 6464 2f63 657b 2044
                         4d3d 6469 616c 706c 616e 317d 2c61 6c2f
                         6f6e 7b73 7472 6963 743d 6578 6163 747d
                         2c67 2f73 637d 7d7d 2c61 6c2f 6f6e 7b73
                         7472 6963 743d 6578 6163 747d 7d7d 7d7d
 
                          E^@ ^@..  ,^A ^@^@  @^Q  9 6 ^J^J ^@ i
                         ^J^J ^@ z  + r  + r ^@.. ^P 7  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  0 5  ]    T =
                          4 2  2 {  C =  - {  M F  = a  g w  _ j
                          u l  w /  5 {  E =  5 8  9 8  2 9  { a
                          l /  o f  { s  t r  i c  t =  e x  a c
                          t ,  E M  { S  G {  c g  / d  t }  , E
                          = 3  9 3  2 1  7 {  d d  / c  e {    D
                          M =  d i  a l  p l  a n  1 }  , a  l /
                          o n  { s  t r  i c  t =  e x  a c  t }
                          , g  / s  c }  } }  , a  l /  o n  { s
                          t r  i c  t =  e x  a c  t }  } }  } }
16:46:18.336658 eth0 > coco2.11122 > 10.10.0.122.11122: udp 164
                         4500 00c0 2c04 0000 4011 3933 0a0a 0069
                         0a0a 007a 2b72 2b72 00ac 0e37 212f 3120
                         5b31 302e 3130 2e30 2e31 3035 5d20 543d
                         3432 337b 433d 2d7b 4d46 3d61 6777 5f6a
                         756c 772f 367b 453d 3538 3938 3239 7b61
                         6c2f 6f66 7b73 7472 6963 743d 6578 6163
                         742c 454d 7b53 477b 6367 2f64 747d 2c45
                         3d33 3933 3231 377b 6464 2f63 657b 2044
                         4d3d 6469 616c 706c 616e 317d 2c61 6c2f
                         6f6e 7b73 7472 6963 743d 6578 6163 747d
                         2c67 2f73 637d 7d7d 2c61 6c2f 6f6e 7b73
                         7472 6963 743d 6578 6163 747d 7d7d 7d7d
 
                          E^@ ^@..  ,^D ^@^@  @^Q  9 3 ^J^J ^@ i
                         ^J^J ^@ z  + r  + r ^@.. ^N 7  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  0 5  ]    T =
                          4 2  3 {  C =  - {  M F  = a  g w  _ j
                          u l  w /  6 {  E =  5 8  9 8  2 9  { a
                          l /  o f  { s  t r  i c  t =  e x  a c
                          t ,  E M  { S  G {  c g  / d  t }  , E
                          = 3  9 3  2 1  7 {  d d  / c  e {    D
                          M =  d i  a l  p l  a n  1 }  , a  l /
                          o n  { s  t r  i c  t =  e x  a c  t }
                          , g  / s  c }  } }  , a  l /  o n  { s
                          t r  i c  t =  e x  a c  t }  } }  } }
16:46:18.405818 eth0 < 10.10.0.122.11122 > coco2.11122: udp 70
                         4500 0062 0293 0000 3f11 6402 0a0a 007a
                         0a0a 0069 2b72 2b72 004e 705a 212f 3120
                         5b31 302e 3130 2e30 2e31 3232 5d0a 503d
                         3432 307b 433d 2d7b 4d46 3d61 6777 5f6a
                         756c 772f 327d 7d0a 503d 3432 317b 433d
                         2d7b 4d46 3d61 6777 5f6a 756c 772f 337d
                         7d0a
 
                          E^@ ^@ b ^B.. ^@^@  ?^Q  d^B ^J^J ^@ z
                         ^J^J ^@ i  + r  + r ^@ N  p Z  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  2 2  ]^J  P =
                          4 2  0 {  C =  - {  M F  = a  g w  _ j
                          u l  w /  2 }  }^J  P =  4 2  1 {  C =
                          - {  M F  = a  g w  _ j  u l  w /  3 }
                          }^J
16:46:18.506842 eth0 < 10.10.0.122.11122 > coco2.11122: udp 70
                         4500 0062 0294 0000 3f11 6401 0a0a 007a
                         0a0a 0069 2b72 2b72 004e 665a 212f 3120
                         5b31 302e 3130 2e30 2e31 3232 5d0a 503d
                         3432 327b 433d 2d7b 4d46 3d61 6777 5f6a
                         756c 772f 357d 7d0a 503d 3432 337b 433d
                         2d7b 4d46 3d61 6777 5f6a 756c 772f 367d
                         7d0a
 
                          E^@ ^@ b ^B.. ^@^@  ?^Q  d^A ^J^J ^@ z
                         ^J^J ^@ i  + r  + r ^@ N  f Z  ! /  1
                          [ 1  0 .  1 0  . 0  . 1  2 2  ]^J  P =
                          4 2  2 {  C =  - {  M F  = a  g w  _ j
                          u l  w /  5 }  }^J  P =  4 2  3 {  C =
                          - {  M F  = a  g w  _ j  u l  w /  6 }
                          }^J

 

 

best  regards
> :-)Jerry Wang
tel:(8621)58541240 ext 9615
mailto:[email-masked]
Shanghai Bell Co.LTD

-----Original Message-----
From: Barcotti, Glauco [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 10:10 PM
To: 'Christer Holmberg'
Cc: [email-masked]'
Subject: RE: [Megaco] ServiceChange for a single termination (Cold Start)

Hi,

Thanks,
Glauco

---

From: "SRD Wang JuLin" <[email-masked]>
Date: Thu, 18 Apr 2002 14:51:55 +0800

Hi,
Well,I think MGC should send Modify messages (the number of it equals to the number of terminations in RGW,I only refer to Residential GW) to check the terminations's events  after MG reboot with Cold Start as a whole entity.
All terminations will start up.In case of some terminations fail to use,of course,we should send SC for definite invalid termination with restored method  to Softswtich.
Before you WANT to use a termination,you should know whether it is ABLE to use (ie.in service or out of  service).

best  regards

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 2:27 PM
To: SRD Wang JuLin
Cc: Barcotti, Glauco; [email-masked]
Subject: Re: [Megaco] ServiceChange for a single termination (Cold Start)

Hi,

So, you want me to send a MODIFY to each of the THOUSANDS of terminations I may want to use????

And, the issue is not which termination I WANT to use (ie which I want the MGC to "enable" in the MG), but which termination I am ABLE (ie which termination has at a certain time been booted/loaded/whatevver) to use...

Regards,

Christer Holmberg
Ericsson Finland

SRD Wang JuLin wrote:

>                          ^J^J ^@ z ^K..  + r ^@ F ^ç¸(tm)]  ! /  1

---

From: "Barcotti, Glauco" <[email-masked]>
Date: Thu, 18 Apr 2002 14:06:44 -0400

Christer,

	I do understand your point.
	I have read section 6.2.5 but I have also seen the example in the Appendix A and they are contradictory.
	If the Appendix A had 2 ServiceChange messages (One ROOT and one for Termination-X) I would not be asking this question and we would be in agreement.
	There is also a Draft document (draft-hss-megaco-control-association-state-machine-00.txt) that seems to support the idea that ServiceChange-ROOT-restart will indicate that all terminations are in-service.

	Are the Appendix A and the Draft document on a need for an update? If so how do we proceed to eliminate these inconsistencies?

Glauco

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 1:53 AM
To: Barcotti, Glauco
Cc: [email-masked]'
Subject: Re: [Megaco] ServiceChange for a single termination (Cold
Start)

Hi,

> The example in the spec (Appendix A) and the draft-madhu-megaco-callflows-00.txt tell me that when I address ROOT on a ServiceChange all terminations are addressed (One ServiceChange ROOT is sent a…

Assume my MG comes up, but for whatever reason I don't have TDM interface card X available, so those timeslots/terminations are not available. Now, to tell the MGC that there are two options:

1. I configure the MGC manually not to use those terminations.

2. The MGC will have to do Audit to find out which terminations are in servce.

Now, I don't like option 1.

And, when card X is put back into service, or I put a new card in my MG, there will have to be ServiceChanges for those terminations anyway, because I don't think we can assume the MGC to Audit the MG all the time.
Also, if I have a very big MG it may take different time before all interfaces are up. But, I still want to start using some interfaces, so I don't want to wait with the registration ServiceChange until all interfaces are up. But, again, the MGC would now have to start doing frequent Audits, to find out which interfaces are up, and
which are not, until it realizes all terminations are up.

Chapter 6.2.5 defines that the ROOT specify the whole MG, rather than specific terminations. My understanding is that it does NOT say that includes the terminations. Also, how would you define the difference between TerminationID=ROOT and TerminationID=ALL???

Also, IF ROOT would include all terminations, why am I not to send a Subtract with ContextID=ALL and TerminationID=ROOT???

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Barcotti, Glauco" <[email-masked]>
Date: Thu, 18 Apr 2002 14:06:44 -0400

Christer,

Glauco

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 1:53 AM
To: Barcotti, Glauco
Cc: [email-masked]'
Subject: Re: [Megaco] ServiceChange for a single termination (Cold
Start)

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: [email-masked]
Date: Fri, 19 Apr 2002 09:49:34 +0530

Al,
       The advantage you have cited below will hold true only under the
assumption
  that MG sends ServiceChange for individual terminations instead of using a
wildcard.
  Sending ServiceChange for individual terminations would be too expensive in
terms
  of network bandwidth as well as MG processing for extremely large sized
Gateways.
  I would expect that if MGC is interested in finding out configuration
inconsistencies
  with its MGs, it would do an Audit at lesiure in parallel to handling normal
calls.

 IMHO, "ServiceChange on ROOT" should indicate all terminations are up at the
MG.
 ServiceChange for Out Of Service Terminations can be sent subsequently. Total
number of messages required in this scenario would be
(1 ServiceChange on ROOT + x ServiceChange for configured but unequipped
terminations)

Even if we go by approach #2 suggested below, the latter step (i.e. sending
ServiceChange
for Out Of Service Terminations) will anyway have to be executed.
 Subsequent to a ServiceChange on ROOT, if MG uses Wildcarded Termination Id
to indicate that all terminations in the MG are In Service, it will need to send
 Out of Service ServiceChange for those terminations that have been configured
 but not hardware equipped. The number of messages required in this scenario
would be

(1 ServiceChange on ROOT + 1 ServiceChange with Termination Id "*"+ n
ServiceChange
  for configured but unequipped terminations (Term Id = "/TG!/Fac1/*))

The MG may of course choose not to use a wildcarded
termination signifiying all terminations on the MG and instead use multiple
ServiceChange commands each with a Termination Id (tg1/fac1/*) that siginfies a
DS0 aggregation. In this case, the number of ServiceChange commands would equal
the number of such DS0 aggregations in the MG i.e. several ServiceChange
messages
 would be needed to complete the initial MG-MGC startup sequence. The number of
 messages required in this scenario would be

(1 ServiceChange on ROOT + n ServiceChange for configured and equipped
terminations
    (Term Id = "/TG!/Fac1/*))

{Assuming most of the terminations in MG would be In Service, n could be a large
value unless
  the MG is intelligent and can optimize on the number of messages}

To summarize, IMO that number of (ServiceChange) messages required at startup
 would turn out to be larger in approach #2 than in approach #1. So, why not
choose
 a strategy that is optimal ?

Rgds,

Vikas Bajaj
NGN Group
Hughes Software Systems
(www.hssworld.com)

Al Varney <[email-masked]> on 04/19/2002 04:59:53 AM

To:   [email-masked]
cc:    (bcc: Vikas Bajaj/HSS)

At 02:46 PM 4/18/02 -0400, Terry L Anderson wrote:
>Possible clarifications:
>ServiceChange on ROOT with method=restart (a registration):
>1) implies that all physical terminations on MG are also up.  Exceptions
>should be indicated by additional ServiceChanges on the down terminations
>using Forced, preferrably in the same message and using wildcards where
>possible.
>2) implies that all physical terminations on MG are down.  Those that are up
>will be indicated by additional ServiceChanges on the up terminations using
>method=restart, preferrably in the same message and using wildcards were
>possible.

...

>Even though I think that most GWs probably would not register until all or
>most of their physical terminations are available, I would probably prefer
>#2 since I can easily indicated them all up with only one additional
>ServiceChange and it seems more natural to indicate those up those that are
>down.  But I can be happy with either #1 or #2.

    #2 has the added (slight?) advantage that physical termination ID
mis-matches (between MGC and MG) are identified when the MG sends
SVC(restart) on a termination ID unknown to the MGC.  #1 relies on MGC
discovering these (non-existent) terminations 1 at a time, when connections
are attempted.  With #1, a mis-match of this type might go undetected for
days, until the MGC attempted to use/audit that particular termination ID.

    Terminations known only to the MGC will still go "undetected", but
since no SVC(restart) is ever received for them, at least the MGC would not
be trying to use them.  An audit might eventually reveal the reason for the
OOS terminations.  (It is not unusual in "old" voice switches to have
termination data populated without having the hardware yet in place, so a
mis-match cannot be considered an error in all cases.)

    Is there an assumption that MG SVC(ROOT,restart) implies the ephemeral
interface(s) are all operational?  If it makes sense to positively assert
SVC(restart) on physical terminations, why wouldn't it also make sense to
indicate availability of ephemeral interfaces?  I'm thinking particularly
of MGs with multiple ephemeral interfaces (IP, ATM, etc.).

    Assuming a reasonable SVC mechanism with "ranges" exists, #2 is not a
big burden after MG restart.  If SVC is needed for every individual
physical termination, then #1 becomes attractive.

Al Varney

---

From: [email-masked]
Date: Mon, 22 Apr 2002 10:30:09 +0530

Sankar,
            IMHO that, while it is right to refer to legacy switching to ensure
that we don't miss out on something
 obvious, we need not adopt all strategies that have been used in the past. The
architecture that has
 evolved for the new networks is different (it is distributed and has in its
core a packet network) and
a different strategy may need to be evolved to account for these changes. It is
possible to implement
 a solution in conformance to a defined protocol but it may not be easy to come
out with new revisions
of the protocol to address deployment issues. Hence, in my opinion whatever
through discussions
seems to be optimal from deployment perspective should be adopted.

Rgds,

Vikas Bajaj
NGN Group
Hughes Softsware Systems
(www.hssworld.com)

Sankar Raman <[email-masked]> on 04/19/2002 10:44:24 PM

To:   Terry L Anderson <[email-masked]>, Christian Groves
      <[email-masked]>
cc:   Vikas Bajaj/HSS@HSS, Al Varney <[email-masked]>, [email-masked]

Terry:

In my expereince working with different swicthes and gateways,
typical internal implementation of these boxes are such that when
the box comes up, all T1 lines are asumed down untill they come up
in which case the T1 framer chip notifies this event to the upper layers.
Typical implementation is such that when the T1 hardware is reset, no
events will be generated until a line comes up. Line down evets are
generated by T1 hardware only if the line was up before.
This means, if a MGC asssumes on registation, that all lines are up, and
if certain do not come up at the MG, the MG will not be able to indicate
this to
the MGC, unless the MG implelements periodic polling of some sort.

I feel, it is better, that default state for physical terminations,
when MGC registers with ROOT in service, should be out of service.
Upon registration, the MGC assumes all lines are down until explicitly
indicated
by service change by the MG for the physical lines. As lines come up
at the MG, the MG will send svcchg in svc for each as it happens.
This will be simpler for MGs and go with their typical internal
implementation.
(although it may generate more traffic which can be cut down by using wildcard
for the lines).

Also, this way MGs do not have to worry about how long should it wait for
all lines
to come up before registering with MGC. Some lines may never come up due to
some
fault at the far end switch or may come up much later than some other lines.

At 11:47 AM 4/19/02 -0400, Terry L Anderson wrote:
>Christian
>Good point.  I missed the relevance of the ServiceState property in 7.1.5.
 There is
>states that "in service" is default.  While Service State is not defined
to be
>precisely the same as ServiceChange forced and restart (maybe it should be
for a
>termination), I agree that this default indicates the intention defaulting to
>inservice.  Thus I think that my assumption #1 is the more consistent.  I
still think
>that the link between ServiceState and ServiceChange for a termination is
ambiguous

>enough that it would be helpful to restate the assumption in 7.2.8.
>
>I propose we add the following to 7.2.8 at the end of the current Restart
entry:
>
>"When applied to ROOT, this specifies that the Media Gateway as a whole
will be in
>service and includes all its physical terminations which will be in their
default
>state ("in service").  Exceptions can be indicated by additional
ServiceChange
>commands."
>
>As Vikas points out, most uses of wildcard ALL assumes that MGC knows the
range of
>valid terminationIDs for the GW.  Packages have been proposed (but not yet
approved)
>for MGC to discover this range if it is not known from provisioning.  Sending
>individual (non-wildcard) ServiceChange for every distinct physical
termination would
>be legal but impractical for most large MGs.
>
>Al Varney asked:
>
>There has been previous discussions about the applicability of
ServiceChange for
>ephemerals.  While there is nothing stating that one could not use
ServiceChange to
>take an ephemeral out of service, but since it would then be subtracted
from any
>context it was in, it would cease to exist and so could never be
"restarted".  Clearly
>serviceChange cannot be used to indicate whether an ephemeral Add will
succeed or not
>(availability of any underlying network or gateway resources).  I think
that the
>assumption is that if a GW is in service then any ephemeral Add can be
attempted.
>Failure of an underlying network can be indicated using nt/netfail, but
since events
>are only set on terminations, one must Add an ephemeral before such an
event can be
>used.
>
>I think we currently have no good way to announce that the MG is in
service but one or
>more classes of ephemerals are unavailable.  I think that a specific error
to indicate
>this after an Add attempt might be sufficient (I don't believe that there
is a good
>one now).
>
>
>Christian Groves wrote:
>
>> G'Day Vikas,
>>
>> I believe you are getting what you asked for. The default state of all
>> terminaton is "inservice".
>> If the MG cold starts and sends ServiceChange on "ROOT" then the MGC can
assume
>> that:
>> o as the MG is running and
>> o a MG contains terminations and
>> o the termination's natural state is "inservice"

>> therefore the individual terminations are running also.
>>
>> Regards, Christian
>>
>> [email-masked] wrote:
>> >
>> > Al,
Start)

>--
>------------------------------------------------------------
>Terry L Anderson              mailto:[email-masked]

>Tel:732.949.5628   Fax:732.949.7016
>Lucent Technologies/INS/Voice Over IP Access Networks
>Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
>http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>
>
>

---

From: [email-masked]
Date: Mon, 22 Apr 2002 10:30:09 +0530

Sankar,

Rgds,

Vikas Bajaj
NGN Group
Hughes Softsware Systems
(www.hssworld.com)

Terry:

 There is
to be
for a
still think
ambiguous

will be in
default
ServiceChange
range of
approved)
termination would
ServiceChange for
ServiceChange to
from any
"restarted".  Clearly
succeed or not
that the
attempted.
since events
event can be
service but one or
to indicate
is a good
assume

Start)