Subject: RE: [Megaco] difference between Cold Start and Registration

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 1 Aug 2002 16:24:29 -0400

I propose that 901 cold boot implies what I said below: initialized state.
902 warm boot implies active state, but possible state mismatches with the
MGC, implying that the MGC should do an audit. 

-----Original Message-----
From: Pascal Lambers [mailto:[email-masked]]
Sent: Thursday, August 01, 2002 3:48 PM
To: Taylor, Tom-PT [CAR:B602:EXCH]
Cc: [email-masked]
Subject: Re: [Megaco] difference between Cold Start and Registration

Hello,
 
What can the MGC controller do with the ServiceChangeReason in a
ServiceChange message that it receives from the MG? 
 
Nothing in the in the Megaco/H.248 spec (neither in version 1, nor in
version 2) seems to determine how ServiceChangeReasons can be distinctive
for the MGC.
 
Eg. When the MG sends a ServiceChange with ServiceChangeMethod Restart, the
ServiceChangeReason can be 901 cold boot or 902 warm boot. Should the MGC
behave differently in both cases, according to the spec?
 
Pascal

----- Original Message ----- 
From: "Tom-PT Taylor" <[email-masked]>
To: "'Ryan Cho'" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 01, 2002 6:46 PM
Subject: RE: [Megaco] difference between Cold Start and Registration

> 
> Hi.  Answers inline.
> 
> -----Original Message-----
> From: Ryan Cho [mailto:[email-masked]]
> Sent: Thursday, August 01, 2002 10:37 AM
> To: [email-masked]
> Subject: [Megaco] difference between Cold Start and Registration
> 
> 
> Hi, 
> 
> 1. I want to know the difference between "Cold Start" and "Registration"
of
> MG from the MGC's point of view. Does it depend on the presence of
> 'ServiceChangeAddress' parameter of SvcChange command ? 
> [PTT]
> In my personal view, for which I hope to gain consensus, the "Cold Start"
> Reason is used to indicate that the MG is in initial state: all physical
> terminations have default property values and are in the NULL context, and
> only the NULL context exists.  This is independent of whether the MG had a
> control association with this or another MGC.
> 
> "Registration" is defined by the fact that the MGC does not already have a
> control association in progress with a device with the same MId.  This, of
> course, raises the issue of potential MId collisions, and also of the need
> for the MGC to authenticate the MG.
> [/PTT]
> 
> 2. In registration, if UDP is used as transport protocol, initial
SvcChange
> request with new port number in ServiceChangeAddress parameter is sent to
> default port number. (this means MGC might open UDP (client) socket for
new
> MG's port) 
> Is MGC alwalys send reply with new MGC port number in ServiceChangeAddress
> ? (and this means MGC might open another UDP (server) socket for new MGC
> port number) 
> [PTT] 
> That depends on whether the MGC application prefers to demultiplex MG
> requests at the transport layer or at the application layer (using MId).
> 
> 
> 2. Generally, the signal applied specific termination might be clear by
> sending modify command with null signal descriptor such as Signals = {}.
> What about event ? especially with embeded signal ? 
> 
> for example, 
> suppose physical termination is applied event like this 
> 
> Modify = Trunk1/Line1 { 
> Events = 100 {r2/sz Embed { Signals {r2/sa}, Events=101 { r2/clear Signals
> { r2/clear }, r2/address}} 
> } 
> 
> the signal described below can be replaced without cancellation of signal
? 
> 
> Modify = Trunk1/Line1 { 
> Signals = {r2/sz}, 
> Events = 200 {r2/sa Embed {Signals {r2/address {si = 1234, di =
> 5678}},Events = 201 {r2/clear, r2/answer} 
> } 
> [PTT]
> That depends on whether the signals are in progress as a result of
> observing the event.  Assuming they are, clearing of the Events descriptor
> has no effect.  But if event r2/sa has not been observed yet, the embedded
> signals will not happen if the Events descriptor is cleared.
> 
> 
> 
> Thanks for your comment in advance. 
> 
> Ryan
> 
> 
> 
> 
> 
> ���̹�-���ѹα� ��ǥ �˻�����, ���̹�
> Ư���� e ������ ���� ��, ���׷��̵� ���̹� ����
> http://www.naver.com
> 
> _______________________________________________
> 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: "Pascal Lambers" <[email-masked]>
Date: Thu, 1 Aug 2002 23:31:00 +0200

Unfortunately, as long as the spec does not clearly define what to do with
the ServiceChangeReason, one company's MGC can react totally different than
another company's MGC.

Pascal

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
To: "'Pascal Lambers'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 01, 2002 10:24 PM
Subject: RE: [Megaco] difference between Cold Start and Registration

> > ³×ÀÌ¹ö-´ëÇÑ¹Î±¹ ´ëÇ¥ °Ë»öÆ÷ÅÐ, ³×ÀÌ¹ö
> > Æ¯º°ÇÑ e ¸ÞÀÏÀ» ¿øÇÒ ¶©, ¾÷±×·¹ÀÌµå ³×ÀÌ¹ö ¸ÞÀÏ
> > http://www.naver.com
> >

---

From: "Pascal Lambers" <[email-masked]>
Date: Thu, 1 Aug 2002 23:31:00 +0200

Pascal

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 10:16:21 +1000

G'Day,

H.248.8 (Previously Annex L) discusses what the serviceChangereasons are and
what assumptions can be made.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 10:16:21 +1000

G'Day,

Regards, Christian