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

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
> :-)Jerry Wang
tel:(8621)58541240 ext 9615
mailto:[email-masked]
Shanghai Bell Co.LTD

-----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:

> 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 ^ç¸(tm)]  ! /  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,
>
> >>         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
>
> >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
>
> >
> >
> > 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
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

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

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Thu, 18 Apr 2002 09:58:19 -0400

Hi,

I agree with Christer's views.

If MG sends a ServiceChange 'ROOT', it only means that the gateway is in
or out of service (Refer to Section 6.2.5 & 7.2.8 of the RFC3015). The
protocol is very clear on this, I think.

Given that -- SVC(ROOT) means that the gateway is up -- now there are
many ways MGC could come to know of what terminations are in service:

1. MG sends ServiceChange for all the terminations that are in service
individually (If there are large number of terminations, the MG could
use *ranges* of TerminationIds(?) to limit the number of such messages)

2. MGC could audit the MG for the list of terminations that are in
service in which case the MG returns the list of terminations that are
in service.

But clearly sending a ServiceChange('ROOT') does not mean that all the
terminations in the MG are in service. This presents lot of operational
problems as Christer pointed out.

-- Bala

__________________
Bala Pitchandi
UTStarcom Inc.

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

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:

> 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
>
> )
>                           / 1  , V  = 1  } }  } } 16:46:18.325927 eth0

> > coco2.11122 > 10.10.0.122.11122: udp 164
> >>         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
>
> >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
>
> >
> >
> > 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
> >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
>

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Thu, 18 Apr 2002 09:58:19 -0400

Hi,

-- Bala

__________________
Bala Pitchandi
UTStarcom Inc.

-----Original Message-----

Hi,

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,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 18 Apr 2002 14:46:21 -0400

I cannot agree that 6.2.5 and/or 7.2.8 is clear on this (it makes no
statement one way or the other) and it is apparent that there is not
agreement on what we want.  I believe that there are three possible
positions and that we should clarify this through the IG once we agree.

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.
3) has no implication whether physical terminations are up or down, but MGC
may be provisioned to know whether an MG will indicate terminations that are
up or those that are down.

I should say that I do not like #3 but am including it as a possibility.

Preference for #1 or #2 probably depend on:
1) whether most physical terminations are available almost immediately or
come up slowly and at different speeds.
2) whether MGC is provisioned with knowledge about the available physical
terminations on an MG or expects to learn about them through ServiceChanges
or Audits

Note that #1 can be implemented from #2 by adding:
    ServiceChange = *{Services{Method=Restart}}
to the action, and conversely #2 can be implemented from #1 by adding:
    ServiceChange = *{Services{Method=Forced}}

In either case exceptions (up or down) to the ALL can be indicated by
additional ServiceChange commands.

So (IMHO) it doesn't seem too critical which we choose, but we should choose
and document one.

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.

What do folks prefer?

--

------------------------------------------------------------
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: Terry L Anderson <[email-masked]>
Date: Thu, 18 Apr 2002 14:46:21 -0400

Possible clarifications:

What do folks prefer?

--

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Thu, 18 Apr 2002 17:18:48 -0400

Please see my comments embedded as [BP] below.

Thanks
Bala

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Terry L Anderson
Sent: Thursday, April 18, 2002 2:46 PM
To: [email-masked]
Subject: Re: [Megaco] ServiceChange for a single termination (Cold
Start)

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.

[BP] The key here is what does *all* physical terminations represent.
Does it represent (a) all the terminations that are provisioned and are
in service (provisioned and hardware available & ready) at the time when
the MG sends the ServiceChange on ROOT (b) all the terminations that the
MG *expects* to be in service by the time it can start expecting
messages from MGC (c) all the terminations that are there in the system
irrespective of whether they come up later or sooner? 

[BP] Also this would warrant the MG to send a lot of 'forced'
ServiceChanges to bring the terminations down (up in the latter case)
particularly if the wildcarding cannot be used -- ie. when the
terminationIds are not contiguous. And it presents a potential error at
MGC, if the MG fails to send such a set of 'forced' ServiceChanges for
the terminations that are down (up in the latter case).

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.

[BP] Same as above. What does *all* represent?

3) has no implication whether physical terminations are up or down, but
MGC may be provisioned to know whether an MG will indicate terminations
that are up or those that are down.

[BP] IMHO, this option is better because of the following reasons - (a)
It does not present any confusion about the status of the terminations
available in the MG and hence leaves it to MG/MGC to figure/inform of
the status of the terminations separately through an audit or
ServiceChange. (b) This gives flexibility to the implementors to choose
the options.

Preference for #1 or #2 probably depend on:
1) whether most physical terminations are available almost immediately
or come up slowly and at different speeds.
[BP] This is a larger unknown/assumption and the protocol cannot assume
anything on how soon/late the terminations can come up.

2) whether MGC is provisioned with knowledge about the available
physical terminations on an MG or expects to learn about them through
ServiceChanges or Audits
[BP] The choice should be left to the implementation and I think, the
protocol should leave it as it is.

So (IMHO) it doesn't seem too critical which we choose, but we should
choose and document one.

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.

[BP] Most (or many) implementations would want the gateway to just be up
so that it can be configured and then be gradually be brought up to its
full load. In that case, it would be appropriate to have the option #3
where the MG just informs the MGC of its registration and then let the
MGC know of the active terminations using the audit/ServiceChanges.

What do folks prefer?

[BP] That’s my two cents. :)

Balasubramanian Pitchandi wrote:

> If MG sends a ServiceChange 'ROOT', it only means that the gateway is 
> in or out of service (Refer to Section 6.2.5 & 7.2.8 of the RFC3015). 
> The protocol is very clear on this, I think.
>

> terminations in the MG are in service. This presents lot of 
> operational problems as Christer pointed out.
>
> -- Bala
>
> __________________
> Bala Pitchandi
> UTStarcom Inc.
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of SRD Wang JuLin
> 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 
> 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
> > :-)Jerry Wang

> which termination has at a certain time been booted/loaded/whatevver) 
> to use...
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> SRD Wang JuLin wrote:
>
> > 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
>
> > >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.
> >

--

---

From: "Balasubramanian Pitchandi" <[email-masked]>
Date: Thu, 18 Apr 2002 17:18:48 -0400

Thanks
Bala

-----Original Message-----

Possible clarifications:

What do folks prefer?

--

---

From: Al Varney <[email-masked]>
Date: Thu, 18 Apr 2002 18:29:53 -0500

>method=restart, preferrably in the same message and using wildcards were

...

>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: Al Varney <[email-masked]>
Date: Thu, 18 Apr 2002 18:29:53 -0500

...

Al Varney

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Apr 2002 07:40:20 +0300

Hi,

Opton 1) vs 2) is what we have been discussing in this thread so far, and I
would prefear option 2).

I don't think option 3) - it would just be a compromise, since we couldn't agree
on something else :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Apr 2002 07:40:20 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Fernando Vallejo Lazaro <[email-masked]>
Date: Fri, 19 Apr 2002 09:14:37 +0200

Hi,

As you have said in previous emails the pstn gateways from
the old point of view of switching may have different boards
with different terminations. And the may start up in a lapse of
seconds...
IMO I would wait for all to restart before sending a SVC (Restart).
In the best case no more messages will be sent, we can suppose
tha a faulty termination is not the normal case.
Another thing is that we may not be able to use wildcards... this
implies a message per termination.
I would prefer option 1)

Fernando Vallejo
Alcatel Spain

--
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL

---

From: Fernando Vallejo Lazaro <[email-masked]>
Date: Fri, 19 Apr 2002 09:14:37 +0200

Hi,

Fernando Vallejo
Alcatel Spain

--
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL