From megaco-admin@ietf.org  Tue Apr  1 02:58:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28165
	for <megaco-archive@lists.ietf.org>; Tue, 1 Apr 2003 02:58:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318EQK07124;
	Tue, 1 Apr 2003 03:14:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3189pK06963
	for <megaco@optimus.ietf.org>; Tue, 1 Apr 2003 03:09:51 -0500
Received: from eins.siemens.at (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27970
	for <megaco@ietf.org>; Tue, 1 Apr 2003 02:45:41 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h317m1dp024535;
	Tue, 1 Apr 2003 09:48:01 +0200
Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41])
	by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h317lvqH005669;
	Tue, 1 Apr 2003 09:47:59 +0200 (MET DST)
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <HXZV82L5>; Tue, 1 Apr 2003 09:48:56 +0200
Message-ID: <D9F2B9CD7BD5D21196BC0800060D9ED607CE264E@vies186a.sie.siemens.at>
From: Kalleitner Franz <franz.kalleitner@siemens.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com.au>
Cc: megaco@ietf.org
Subject: AW: [Megaco] Signal  status after move from specific to NULL cont
	ext
Date: Tue, 1 Apr 2003 09:48:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F823.20618140"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F823.20618140
Content-Type: text/plain

Hi Christian,

in the MEGACO specification I only found a statement concering properties
which will be resetted to the default values if a phy. termination 
will be moved back to the NULL context. However I didn't find any reference
where the handling of signals is specified in such a configuration.
May be I have overseen something. I kindly ask, if you could send me a
reference.

Thanks in advance 
Franz

-----Ursprungliche Nachricht-----
Von: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
Gesendet: Freitag, 28. Marz 2003 04:11
An: Kalleitner Franz
Betreff: Re: [Megaco] Signal status after move from specific to NULL
context


b). deactived because of the subtract command.

Christian

Kalleitner Franz wrote:
> 
> Dear Megaco-List members,
> 
> A physical termination is added into in a specifc context and a signal is
> connected to that phy. termination.
> Afterwards the physical termination is subtracted and shall be removed
back to
> the NULL context.
> 
> What is the status of the signal after the subtract command?
> 
> a.) is it still active
> b.) deactivated because of the subtract command.
> 
> yours sincerly


------_=_NextPart_001_01C2F823.20618140
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPkFXOiBbTWVn
YWNvXSBTaWduYWwgIHN0YXR1cyBhZnRlciBtb3ZlIGZyb20gc3BlY2lmaWMgdG8gTlVMTCBjb250
ZXh0PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGkgQ2hyaXN0
aWFuLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPmluIHRoZSBNRUdBQ08gc3BlY2lm
aWNhdGlvbiBJIG9ubHkgZm91bmQgYSBzdGF0ZW1lbnQgY29uY2VyaW5nIHByb3BlcnRpZXMgd2hp
Y2ggd2lsbCBiZSByZXNldHRlZCB0byB0aGUgZGVmYXVsdCB2YWx1ZXMgaWYgYSBwaHkuIHRlcm1p
bmF0aW9uIDwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj53aWxsIGJlIG1vdmVkIGJhY2sg
dG8gdGhlIE5VTEwgY29udGV4dC4gSG93ZXZlciBJIGRpZG4ndCBmaW5kIGFueSByZWZlcmVuY2Ug
d2hlcmUgdGhlIGhhbmRsaW5nIG9mIHNpZ25hbHMgaXMgc3BlY2lmaWVkIGluIHN1Y2ggYSBjb25m
aWd1cmF0aW9uLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5NYXkgYmUgSSBoYXZlIG92
ZXJzZWVuIHNvbWV0aGluZy4gSSBraW5kbHkgYXNrLCBpZiB5b3UgY291bGQgc2VuZCBtZSBhIHJl
ZmVyZW5jZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGFua3MgaW4gYWR2YW5j
ZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkZyYW56PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9O
VCBTSVpFPTI+LS0tLS1VcnNwcnVuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj5Wb246IENocmlzdGlhbiBHcm92ZXMgWzxBIEhSRUY9Im1haWx0bzpDaHJpc3Rp
YW4uR3JvdmVzQGVyaWNzc29uLmNvbS5hdSI+bWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAZXJpY3Nz
b24uY29tLmF1PC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkdlc2VuZGV0OiBGcmVpdGFn
LCAyOC4gTWFyeiAyMDAzIDA0OjExPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5BbjogS2FsbGVp
dG5lciBGcmFuejwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+QmV0cmVmZjogUmU6IFtNZWdhY29d
IFNpZ25hbCBzdGF0dXMgYWZ0ZXIgbW92ZSBmcm9tIHNwZWNpZmljIHRvIE5VTEw8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPmNvbnRleHQ8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5iKS4gZGVhY3RpdmVkIGJlY2F1c2Ugb2YgdGhlIHN1YnRyYWN0IGNvbW1hbmQuPC9GT05U
Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Q2hyaXN0aWFuPC9GT05UPg0KPC9QPg0KDQo8UD48
Rk9OVCBTSVpFPTI+S2FsbGVpdG5lciBGcmFueiB3cm90ZTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IERlYXIgTWVnYWNvLUxpc3Qg
bWVtYmVycyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IEEgcGh5c2ljYWwgdGVybWluYXRpb24gaXMgYWRkZWQgaW50byBpbiBhIHNw
ZWNpZmMgY29udGV4dCBhbmQgYSBzaWduYWwgaXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgY29ubmVjdGVkIHRvIHRoYXQgcGh5LiB0ZXJtaW5hdGlvbi48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgQWZ0ZXJ3YXJkcyB0aGUgcGh5c2ljYWwgdGVybWluYXRpb24gaXMgc3VidHJh
Y3RlZCBhbmQgc2hhbGwgYmUgcmVtb3ZlZCBiYWNrIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IHRoZSBOVUxMIGNvbnRleHQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBXaGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhlIHNp
Z25hbCBhZnRlciB0aGUgc3VidHJhY3QgY29tbWFuZD88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGEuKSBpcyBpdCBzdGlsbCBhY3Rp
dmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYi4pIGRlYWN0aXZhdGVkIGJlY2F1c2Ug
b2YgdGhlIHN1YnRyYWN0IGNvbW1hbmQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB5b3VycyBzaW5jZXJseTwvRk9OVD4NCjwvUD4N
Cg0KPC9CT0RZPg0KPC9IVE1MPg==

------_=_NextPart_001_01C2F823.20618140--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr  1 02:59:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28201
	for <megaco-archive@odin.ietf.org>; Tue, 1 Apr 2003 02:59:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h318NY207540
	for megaco-archive@odin.ietf.org; Tue, 1 Apr 2003 03:23:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318NYK07537
	for <megaco-web-archive@optimus.ietf.org>; Tue, 1 Apr 2003 03:23:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28196
	for <megaco-web-archive@ietf.org>; Tue, 1 Apr 2003 02:59:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318EQK07124;
	Tue, 1 Apr 2003 03:14:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3189pK06963
	for <megaco@optimus.ietf.org>; Tue, 1 Apr 2003 03:09:51 -0500
Received: from eins.siemens.at (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27970
	for <megaco@ietf.org>; Tue, 1 Apr 2003 02:45:41 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h317m1dp024535;
	Tue, 1 Apr 2003 09:48:01 +0200
Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41])
	by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h317lvqH005669;
	Tue, 1 Apr 2003 09:47:59 +0200 (MET DST)
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <HXZV82L5>; Tue, 1 Apr 2003 09:48:56 +0200
Message-ID: <D9F2B9CD7BD5D21196BC0800060D9ED607CE264E@vies186a.sie.siemens.at>
From: Kalleitner Franz <franz.kalleitner@siemens.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com.au>
Cc: megaco@ietf.org
Subject: AW: [Megaco] Signal  status after move from specific to NULL cont
	ext
Date: Tue, 1 Apr 2003 09:48:47 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F823.20618140"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F823.20618140
Content-Type: text/plain

Hi Christian,

in the MEGACO specification I only found a statement concering properties
which will be resetted to the default values if a phy. termination 
will be moved back to the NULL context. However I didn't find any reference
where the handling of signals is specified in such a configuration.
May be I have overseen something. I kindly ask, if you could send me a
reference.

Thanks in advance 
Franz

-----Ursprungliche Nachricht-----
Von: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
Gesendet: Freitag, 28. Marz 2003 04:11
An: Kalleitner Franz
Betreff: Re: [Megaco] Signal status after move from specific to NULL
context


b). deactived because of the subtract command.

Christian

Kalleitner Franz wrote:
> 
> Dear Megaco-List members,
> 
> A physical termination is added into in a specifc context and a signal is
> connected to that phy. termination.
> Afterwards the physical termination is subtracted and shall be removed
back to
> the NULL context.
> 
> What is the status of the signal after the subtract command?
> 
> a.) is it still active
> b.) deactivated because of the subtract command.
> 
> yours sincerly


------_=_NextPart_001_01C2F823.20618140
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPkFXOiBbTWVn
YWNvXSBTaWduYWwgIHN0YXR1cyBhZnRlciBtb3ZlIGZyb20gc3BlY2lmaWMgdG8gTlVMTCBjb250
ZXh0PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGkgQ2hyaXN0
aWFuLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPmluIHRoZSBNRUdBQ08gc3BlY2lm
aWNhdGlvbiBJIG9ubHkgZm91bmQgYSBzdGF0ZW1lbnQgY29uY2VyaW5nIHByb3BlcnRpZXMgd2hp
Y2ggd2lsbCBiZSByZXNldHRlZCB0byB0aGUgZGVmYXVsdCB2YWx1ZXMgaWYgYSBwaHkuIHRlcm1p
bmF0aW9uIDwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj53aWxsIGJlIG1vdmVkIGJhY2sg
dG8gdGhlIE5VTEwgY29udGV4dC4gSG93ZXZlciBJIGRpZG4ndCBmaW5kIGFueSByZWZlcmVuY2Ug
d2hlcmUgdGhlIGhhbmRsaW5nIG9mIHNpZ25hbHMgaXMgc3BlY2lmaWVkIGluIHN1Y2ggYSBjb25m
aWd1cmF0aW9uLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5NYXkgYmUgSSBoYXZlIG92
ZXJzZWVuIHNvbWV0aGluZy4gSSBraW5kbHkgYXNrLCBpZiB5b3UgY291bGQgc2VuZCBtZSBhIHJl
ZmVyZW5jZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UaGFua3MgaW4gYWR2YW5j
ZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkZyYW56PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9O
VCBTSVpFPTI+LS0tLS1VcnNwcnVuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9Mj5Wb246IENocmlzdGlhbiBHcm92ZXMgWzxBIEhSRUY9Im1haWx0bzpDaHJpc3Rp
YW4uR3JvdmVzQGVyaWNzc29uLmNvbS5hdSI+bWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAZXJpY3Nz
b24uY29tLmF1PC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkdlc2VuZGV0OiBGcmVpdGFn
LCAyOC4gTWFyeiAyMDAzIDA0OjExPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5BbjogS2FsbGVp
dG5lciBGcmFuejwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+QmV0cmVmZjogUmU6IFtNZWdhY29d
IFNpZ25hbCBzdGF0dXMgYWZ0ZXIgbW92ZSBmcm9tIHNwZWNpZmljIHRvIE5VTEw8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPmNvbnRleHQ8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5iKS4gZGVhY3RpdmVkIGJlY2F1c2Ugb2YgdGhlIHN1YnRyYWN0IGNvbW1hbmQuPC9GT05U
Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Q2hyaXN0aWFuPC9GT05UPg0KPC9QPg0KDQo8UD48
Rk9OVCBTSVpFPTI+S2FsbGVpdG5lciBGcmFueiB3cm90ZTo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IERlYXIgTWVnYWNvLUxpc3Qg
bWVtYmVycyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9Mj4mZ3Q7IEEgcGh5c2ljYWwgdGVybWluYXRpb24gaXMgYWRkZWQgaW50byBpbiBhIHNw
ZWNpZmMgY29udGV4dCBhbmQgYSBzaWduYWwgaXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn
dDsgY29ubmVjdGVkIHRvIHRoYXQgcGh5LiB0ZXJtaW5hdGlvbi48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgQWZ0ZXJ3YXJkcyB0aGUgcGh5c2ljYWwgdGVybWluYXRpb24gaXMgc3VidHJh
Y3RlZCBhbmQgc2hhbGwgYmUgcmVtb3ZlZCBiYWNrIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IHRoZSBOVUxMIGNvbnRleHQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBXaGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhlIHNp
Z25hbCBhZnRlciB0aGUgc3VidHJhY3QgY29tbWFuZD88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
PiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGEuKSBpcyBpdCBzdGlsbCBhY3Rp
dmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYi4pIGRlYWN0aXZhdGVkIGJlY2F1c2Ug
b2YgdGhlIHN1YnRyYWN0IGNvbW1hbmQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB5b3VycyBzaW5jZXJseTwvRk9OVD4NCjwvUD4N
Cg0KPC9CT0RZPg0KPC9IVE1MPg==

------_=_NextPart_001_01C2F823.20618140--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From mailman-admin@ietf.org  Tue Apr  1 10:21:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19395
	for <megaco-archive@lists.ietf.org>; Tue, 1 Apr 2003 10:21:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FjXK04090
	for <megaco-archive@lists.ietf.org>; Tue, 1 Apr 2003 10:45:33 -0500
Date: Tue, 01 Apr 2003 10:45:33 -0500
Message-ID: <20030401154533.29326.26009.Mailman@www1.ietf.org>
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@www1.ietf.org
To: megaco-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: mailman-admin@ietf.org
Errors-To: mailman-admin@ietf.org
X-BeenThere: mailman@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk

This is a reminder, sent out once a month, about your ietf.org mailing
list memberships.  It includes your subscription info and how to use
it to change it or unsubscribe from a list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, megaco-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.

***************************************************************************


                              Note Well

All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026,
which grants to the IETF and its participants certain licenses and
rights in such statements. Such statements include verbal statements
in IETF meetings, as well as written and electronic communications
made at any time or place, which are addressed to

        * the IETF plenary session,
        * any IETF working group or portion thereof,
        * the IESG, or any member thereof on behalf of the IESG,
        * the IAB or any member thereof on behalf of the IAB,
        * any IETF mailing list, including the IETF list itself, any
working
            group or design team list, or any other list functioning
under IETF
            auspices,
        * the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.

   
***************************************************************************


If you have questions, problems, comments, etc, send them to
mailman-owner@www1.ietf.org.  Thanks!

Passwords for megaco-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
megaco@ietf.org                          rFKd      
https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org


From megaco-admin@ietf.org  Tue Apr  1 18:04:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19642
	for <megaco-archive@lists.ietf.org>; Tue, 1 Apr 2003 18:04:32 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NRtK30113;
	Tue, 1 Apr 2003 18:27:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NQpK30066
	for <megaco@optimus.ietf.org>; Tue, 1 Apr 2003 18:26:51 -0500
Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19463
	for <megaco@ietf.org>; Tue, 1 Apr 2003 18:02:23 -0500 (EST)
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h31N4oZr000591
	for <megaco@ietf.org>; Tue, 1 Apr 2003 16:04:50 -0700 (MST)
Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA02573 for <megaco@ietf.org>; Tue, 1 Apr 2003 16:04:22 -0700 (MST)]
Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31])
	by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h31N4mm18390;
	Tue, 1 Apr 2003 17:04:48 -0600
Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205])
	by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id RAA16601;
	Tue, 1 Apr 2003 17:06:49 -0600 (CST)
Message-ID: <3E8A17C8.F23738D5@motorola.com>
Date: Tue, 01 Apr 2003 16:50:48 -0600
From: Qiaobing Xie<Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] implementation info needed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi, all,

I wonder if anyone has information about Megaco implementation that
supports SCTP transport (i.e., H.248/Annex H).

regards,
-Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr  1 18:05:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19788
	for <megaco-archive@odin.ietf.org>; Tue, 1 Apr 2003 18:05:37 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h31NTY930195
	for megaco-archive@odin.ietf.org; Tue, 1 Apr 2003 18:29:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NTYK30192
	for <megaco-web-archive@optimus.ietf.org>; Tue, 1 Apr 2003 18:29:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19703
	for <megaco-web-archive@ietf.org>; Tue, 1 Apr 2003 18:05:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NRtK30113;
	Tue, 1 Apr 2003 18:27:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31NQpK30066
	for <megaco@optimus.ietf.org>; Tue, 1 Apr 2003 18:26:51 -0500
Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19463
	for <megaco@ietf.org>; Tue, 1 Apr 2003 18:02:23 -0500 (EST)
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h31N4oZr000591
	for <megaco@ietf.org>; Tue, 1 Apr 2003 16:04:50 -0700 (MST)
Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA02573 for <megaco@ietf.org>; Tue, 1 Apr 2003 16:04:22 -0700 (MST)]
Received: from Q.Xie (quantix20.cig.mot.com [160.47.58.31])
	by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h31N4mm18390;
	Tue, 1 Apr 2003 17:04:48 -0600
Received: from motorola.com (d50-38cd.cig.mot.com [160.47.56.205])
	by Q.Xie (8.8.8+Sun/8.8.8) with ESMTP id RAA16601;
	Tue, 1 Apr 2003 17:06:49 -0600 (CST)
Message-ID: <3E8A17C8.F23738D5@motorola.com>
Date: Tue, 01 Apr 2003 16:50:48 -0600
From: Qiaobing Xie<Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] implementation info needed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi, all,

I wonder if anyone has information about Megaco implementation that
supports SCTP transport (i.e., H.248/Annex H).

regards,
-Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr  1 20:30:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24338
	for <megaco-archive@lists.ietf.org>; Tue, 1 Apr 2003 20:30:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321qQK07433;
	Tue, 1 Apr 2003 20:52:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321o5K07339
	for <megaco@optimus.ietf.org>; Tue, 1 Apr 2003 20:50:05 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24172
	for <megaco@ietf.org>; Tue, 1 Apr 2003 20:25:33 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h321S1UE013045;
	Wed, 2 Apr 2003 03:28:01 +0200 (MEST)
Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A493G1F; Wed, 2 Apr 2003 03:28:01 +0200
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h321RvL17390;
	Wed, 2 Apr 2003 11:27:57 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.238]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2C697GA8; Wed, 2 Apr 2003 11:27:55 +1000
Message-ID: <3E8A3C95.2AB10714@ericsson.com.au>
Date: Wed, 02 Apr 2003 11:27:49 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kalleitner Franz <franz.kalleitner@siemens.com>
CC: megaco@ietf.org
Subject: Re: AW: [Megaco] Signal  status after move from specific to NULL context
References: <D9F2B9CD7BD5D21196BC0800060D9ED607CE264E@vies186a.sie.siemens.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Franz,

There is no explicit statement about what happens to terminations playing
signals that are subtracted to the NULL context, so you have not overseen this.
However it comes back to the fact that properties default back to their default
state, which I assume for terminations in NULL is inactive. If this is the case
media related to the signal cannot flow from the termination. Another reason is
that ephemeral termination disappear and a signal can't be played so physical
and ephemeral termination are symmetric in behaviour.

Regards, Christian



Kalleitner Franz wrote:
> 
> Hi Christian,
> 
> in the MEGACO specification I only found a statement concering properties
> which will be resetted to the default values if a phy. termination
> 
> will be moved back to the NULL context. However I didn't find any reference
> where the handling of signals is specified in such a configuration.
> 
> May be I have overseen something. I kindly ask, if you could send me a
> reference.
> 
> Thanks in advance
> Franz
> 
> -----Ursprungliche Nachricht-----
> Von: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
> Gesendet: Freitag, 28. Marz 2003 04:11
> An: Kalleitner Franz
> Betreff: Re: [Megaco] Signal status after move from specific to NULL
> context
> 
> b). deactived because of the subtract command.
> 
> Christian
> 
> Kalleitner Franz wrote:
> >
> > Dear Megaco-List members,
> >
> > A physical termination is added into in a specifc context and a signal is
> > connected to that phy. termination.
> > Afterwards the physical termination is subtracted and shall be removed back
> to
> > the NULL context.
> >
> > What is the status of the signal after the subtract command?
> >
> > a.) is it still active
> > b.) deactivated because of the subtract command.
> >
> > yours sincerly
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr  1 20:31:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24402
	for <megaco-archive@odin.ietf.org>; Tue, 1 Apr 2003 20:31:47 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h321tmw07664
	for megaco-archive@odin.ietf.org; Tue, 1 Apr 2003 20:55:48 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321tlK07661
	for <megaco-web-archive@optimus.ietf.org>; Tue, 1 Apr 2003 20:55:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24389
	for <megaco-web-archive@ietf.org>; Tue, 1 Apr 2003 20:31:16 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321qQK07433;
	Tue, 1 Apr 2003 20:52:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321o5K07339
	for <megaco@optimus.ietf.org>; Tue, 1 Apr 2003 20:50:05 -0500
Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24172
	for <megaco@ietf.org>; Tue, 1 Apr 2003 20:25:33 -0500 (EST)
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h321S1UE013045;
	Wed, 2 Apr 2003 03:28:01 +0200 (MEST)
Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id 2A493G1F; Wed, 2 Apr 2003 03:28:01 +0200
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h321RvL17390;
	Wed, 2 Apr 2003 11:27:57 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.238]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2C697GA8; Wed, 2 Apr 2003 11:27:55 +1000
Message-ID: <3E8A3C95.2AB10714@ericsson.com.au>
Date: Wed, 02 Apr 2003 11:27:49 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kalleitner Franz <franz.kalleitner@siemens.com>
CC: megaco@ietf.org
Subject: Re: AW: [Megaco] Signal  status after move from specific to NULL context
References: <D9F2B9CD7BD5D21196BC0800060D9ED607CE264E@vies186a.sie.siemens.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Franz,

There is no explicit statement about what happens to terminations playing
signals that are subtracted to the NULL context, so you have not overseen this.
However it comes back to the fact that properties default back to their default
state, which I assume for terminations in NULL is inactive. If this is the case
media related to the signal cannot flow from the termination. Another reason is
that ephemeral termination disappear and a signal can't be played so physical
and ephemeral termination are symmetric in behaviour.

Regards, Christian



Kalleitner Franz wrote:
> 
> Hi Christian,
> 
> in the MEGACO specification I only found a statement concering properties
> which will be resetted to the default values if a phy. termination
> 
> will be moved back to the NULL context. However I didn't find any reference
> where the handling of signals is specified in such a configuration.
> 
> May be I have overseen something. I kindly ask, if you could send me a
> reference.
> 
> Thanks in advance
> Franz
> 
> -----Ursprungliche Nachricht-----
> Von: Christian Groves [mailto:Christian.Groves@ericsson.com.au]
> Gesendet: Freitag, 28. Marz 2003 04:11
> An: Kalleitner Franz
> Betreff: Re: [Megaco] Signal status after move from specific to NULL
> context
> 
> b). deactived because of the subtract command.
> 
> Christian
> 
> Kalleitner Franz wrote:
> >
> > Dear Megaco-List members,
> >
> > A physical termination is added into in a specifc context and a signal is
> > connected to that phy. termination.
> > Afterwards the physical termination is subtracted and shall be removed back
> to
> > the NULL context.
> >
> > What is the status of the signal after the subtract command?
> >
> > a.) is it still active
> > b.) deactivated because of the subtract command.
> >
> > yours sincerly
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr  3 05:54:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13270
	for <megaco-archive@lists.ietf.org>; Thu, 3 Apr 2003 05:54:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AqTK00537;
	Thu, 3 Apr 2003 05:52:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AoKK00434
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 05:50:20 -0500
Received: from lodmsg01.corp.audiocodes.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13067
	for <megaco@ietf.org>; Thu, 3 Apr 2003 05:47:33 -0500 (EST)
content-class: urn:content-classes:message
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties
Date: Thu, 3 Apr 2003 13:47:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <14B7C5B03853404495D29CFA4A54B21C360E68@lodmsg01.corp.audiocodes.com>
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [Megaco] Processing Order of Context Properties and Terminati on Properties
Thread-Index: AcL0muv9EQtTfGfxQRmXpKBJpRYYiQFO5T5g
From: "Nurit Shenhar" <NuritS@audiocodes.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <ckaushik@hss.hns.com>
Cc: <megaco@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33AoKK00435
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Kevin

In this case, what should the MG do if one of the terminations defined in the topology is illegal? (i.e belongs to another context). Should there be some session of legality check for the topology?

Nurit

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, March 27, 2003 9:54 PM
To: ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties


Clearly you cannot add the new term before modifying T2.  So the steps are
thus:

1. Process the TP descriptor, noting that there is a term that will be added
later in the action which will be isolated from all the other existing terms
in the context.
2. Process the Modify T2 command.
3. Process the Add command, and add the new term.  Note that because the TP
descriptor has ALREADY been processed, the term is added isolated from all
other terms in the context.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] 
Sent: Thursday, March 27, 2003 1:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi Kevin/List,
Taking the discussion a bit further, please clarify if the following
sequence for implementing Topology Descriptor is correct. Transaction
receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}}

Processing steps:
1. Resolve the termination name i.e. select one termination conforming to
the name specified in the Add command. 2. Add this termination to the
Context. This step may involve using some information given in the Add
command. 3. If the addition of the termination is successful proceed
further. If the addition of termination to Context is not successful give a
Context Level Error in the response. 4. Apply Topology for the newly added
termination. 5. Process the Modify command. 6. Process the Add command. Some
information present in this command will be used while adding the
termination to the Context. Rest of the information is processed here.

Please correct me if I am wrong.

Regards,
Chintan...
www.hssworld.com





"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/20/2003 12:14:08 PM

To:   Chintan Kaushik/HSS@HSS, David Kao <david.kao@verizon.net>
cc:   megaco@ietf.org

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



This is not correct.  As has been repeatedly covered, the Topology
descriptor is executed before any commands, regardless of the information
available.  The difference between this statement, and what you have
expressed is this:

C=1{TP{$,*,IS},A=${...}

Topology first:
The new term is added already isolated from all other terms in the context.

Topology once "enough information" is present:
The new term is added bothway to all terms, and then topology is altered to
isolate the term from all other terms in the context.

As you can see there is a significant difference between these two
scenarios.  If the command fails, then it is up to the MGC to clean up any
potential mess that results from having executed the TP descriptor.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
Sent: Wednesday, March 19, 2003 11:27 PM
To: David Kao
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi,
A small addition to what Kevin has already mentioned: -
Attempt is made to apply the Topology descriptor before any commands for
that action. However, if due to some reason this is not possible then the
Topology Descriptor is applied as soon as all the information to apply it is
known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
{... In this case Topology will be applied once the "Add=$" command has been
executed successfully.

Regards,
Chintan...




"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/19/2003 12:30:27 AM

To:   David Kao <david.kao@verizon.net>, megaco@ietf.org
cc:    (bcc: Chintan Kaushik/HSS)

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



Comments inline. [KJBII]

Kevin

-----Original Message-----
From: David Kao [mailto:david.kao@verizon.net]
Sent: Monday, March 17, 2003 10:22 PM
To: megaco@ietf.org
Subject: [Megaco] Processing Order of Context Properties and Termination
Properties



Please accept my apology if the same questions were asked and discussed
before.



The spec says, "Transactions guarantee ordered Command processing. That is,
Commands within a Transaction are executed sequentially." I have two
relevant questions based on this statement.



1. How about the processing order of context properties? Are they supposed
to be processed in the same same sequential order like the commands?



For instance, based on previously posted emails from Christian Grove,
topology descriptor should be processed before commands in an action, since
"The Topology descriptor occurs before the commands in an action." In fact,
all contextRequests come before the commands. If this is the case, is the
following generalization correct?



"In a transaction, actions are executed sequentially. In an action, context
requests (including context property modifications and context property
audits) and commands are executed sequentially."
[KJBII] Yes.  H.248 is, essentially, a left to right protocol.



2. How about the processing order of termination properties? Without a
well-defined order, different MG implementations can respond differently to
the same command. For instance, if Signals descriptor is processed before
Events descriptor can produce different results than the case when Events
descriptor is processed first. [KJBII] See above comment.



Regards,



David Kao



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr  3 05:55:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13308
	for <megaco-archive@odin.ietf.org>; Thu, 3 Apr 2003 05:55:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33AwAM00868
	for megaco-archive@odin.ietf.org; Thu, 3 Apr 2003 05:58:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AwAK00865
	for <megaco-web-archive@optimus.ietf.org>; Thu, 3 Apr 2003 05:58:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13302
	for <megaco-web-archive@ietf.org>; Thu, 3 Apr 2003 05:55:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AqTK00537;
	Thu, 3 Apr 2003 05:52:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AoKK00434
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 05:50:20 -0500
Received: from lodmsg01.corp.audiocodes.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13067
	for <megaco@ietf.org>; Thu, 3 Apr 2003 05:47:33 -0500 (EST)
content-class: urn:content-classes:message
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties
Date: Thu, 3 Apr 2003 13:47:27 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <14B7C5B03853404495D29CFA4A54B21C360E68@lodmsg01.corp.audiocodes.com>
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [Megaco] Processing Order of Context Properties and Terminati on Properties
Thread-Index: AcL0muv9EQtTfGfxQRmXpKBJpRYYiQFO5T5g
From: "Nurit Shenhar" <NuritS@audiocodes.com>
To: "Kevin Boyle" <kboyle@nortelnetworks.com>, <ckaushik@hss.hns.com>
Cc: <megaco@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33AoKK00435
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Kevin

In this case, what should the MG do if one of the terminations defined in the topology is illegal? (i.e belongs to another context). Should there be some session of legality check for the topology?

Nurit

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, March 27, 2003 9:54 PM
To: ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati on Properties


Clearly you cannot add the new term before modifying T2.  So the steps are
thus:

1. Process the TP descriptor, noting that there is a term that will be added
later in the action which will be isolated from all the other existing terms
in the context.
2. Process the Modify T2 command.
3. Process the Add command, and add the new term.  Note that because the TP
descriptor has ALREADY been processed, the term is added isolated from all
other terms in the context.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] 
Sent: Thursday, March 27, 2003 1:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi Kevin/List,
Taking the discussion a bit further, please clarify if the following
sequence for implementing Topology Descriptor is correct. Transaction
receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}}

Processing steps:
1. Resolve the termination name i.e. select one termination conforming to
the name specified in the Add command. 2. Add this termination to the
Context. This step may involve using some information given in the Add
command. 3. If the addition of the termination is successful proceed
further. If the addition of termination to Context is not successful give a
Context Level Error in the response. 4. Apply Topology for the newly added
termination. 5. Process the Modify command. 6. Process the Add command. Some
information present in this command will be used while adding the
termination to the Context. Rest of the information is processed here.

Please correct me if I am wrong.

Regards,
Chintan...
www.hssworld.com





"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/20/2003 12:14:08 PM

To:   Chintan Kaushik/HSS@HSS, David Kao <david.kao@verizon.net>
cc:   megaco@ietf.org

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



This is not correct.  As has been repeatedly covered, the Topology
descriptor is executed before any commands, regardless of the information
available.  The difference between this statement, and what you have
expressed is this:

C=1{TP{$,*,IS},A=${...}

Topology first:
The new term is added already isolated from all other terms in the context.

Topology once "enough information" is present:
The new term is added bothway to all terms, and then topology is altered to
isolate the term from all other terms in the context.

As you can see there is a significant difference between these two
scenarios.  If the command fails, then it is up to the MGC to clean up any
potential mess that results from having executed the TP descriptor.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
Sent: Wednesday, March 19, 2003 11:27 PM
To: David Kao
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi,
A small addition to what Kevin has already mentioned: -
Attempt is made to apply the Topology descriptor before any commands for
that action. However, if due to some reason this is not possible then the
Topology Descriptor is applied as soon as all the information to apply it is
known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
{... In this case Topology will be applied once the "Add=$" command has been
executed successfully.

Regards,
Chintan...




"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/19/2003 12:30:27 AM

To:   David Kao <david.kao@verizon.net>, megaco@ietf.org
cc:    (bcc: Chintan Kaushik/HSS)

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



Comments inline. [KJBII]

Kevin

-----Original Message-----
From: David Kao [mailto:david.kao@verizon.net]
Sent: Monday, March 17, 2003 10:22 PM
To: megaco@ietf.org
Subject: [Megaco] Processing Order of Context Properties and Termination
Properties



Please accept my apology if the same questions were asked and discussed
before.



The spec says, "Transactions guarantee ordered Command processing. That is,
Commands within a Transaction are executed sequentially." I have two
relevant questions based on this statement.



1. How about the processing order of context properties? Are they supposed
to be processed in the same same sequential order like the commands?



For instance, based on previously posted emails from Christian Grove,
topology descriptor should be processed before commands in an action, since
"The Topology descriptor occurs before the commands in an action." In fact,
all contextRequests come before the commands. If this is the case, is the
following generalization correct?



"In a transaction, actions are executed sequentially. In an action, context
requests (including context property modifications and context property
audits) and commands are executed sequentially."
[KJBII] Yes.  H.248 is, essentially, a left to right protocol.



2. How about the processing order of termination properties? Without a
well-defined order, different MG implementations can respond differently to
the same command. For instance, if Signals descriptor is processed before
Events descriptor can produce different results than the case when Events
descriptor is processed first. [KJBII] See above comment.



Regards,



David Kao



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr  3 07:46:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17901
	for <megaco-archive@lists.ietf.org>; Thu, 3 Apr 2003 07:46:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CljK10437;
	Thu, 3 Apr 2003 07:47:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Cj0K10212
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 07:45:00 -0500
Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17789
	for <megaco@ietf.org>; Thu, 3 Apr 2003 07:42:12 -0500 (EST)
From: bvswamy@hss.hns.com
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h33CgPs03027
	for <megaco@ietf.org>; Thu, 3 Apr 2003 18:12:35 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h33Cfe202978
	for <megaco@ietf.org>; Thu, 3 Apr 2003 18:11:50 +0530 (IST)
Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h33CiI105338
	for <megaco@ietf.org>; Thu, 3 Apr 2003 18:14:28 +0530 (IST)
Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 65256CFD.004496D6 ; Thu, 3 Apr 2003 17:59:10 +0530
X-Lotus-FromDomain: HSS
To: megaco@ietf.org
Message-ID: <65256CFD.004496A6.00@dlfmail1.hss.hns.com>
Date: Thu, 3 Apr 2003 18:15:21 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Megaco] ADD handling for Out-of-service termination
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>



Hi

I have a query  related to ADD command processing for terminations involving
out-of-service terminations:
      An ADD request is received by an MG to add a termination in a context
which already has a OOS termination.
     Scenario:
     1) A termination added in a Context.
     2) MG operator puts the termination out of service
     3) MG sends Service change Forced to the MGC.
     4) Before MGC receives a ServiceChange, it has sent an ADD request(without
a Topolgy descriptor) to MG to add the termination in the
          above context.
Though it can be argued that MGC will always send substract request whenever it
receives ServiceChange Forced but
does it worth exchanging substract messages when ADD failure could have solved
the problem.
However there can be exception to this scenario where multiple terminations are
in context and only one termination is made OOS. Then
if MGC properly specifies the topology descriptor then ADD command should work.

Regards
venkat



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr  3 07:47:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17977
	for <megaco-archive@odin.ietf.org>; Thu, 3 Apr 2003 07:47:55 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33CoB110600
	for megaco-archive@odin.ietf.org; Thu, 3 Apr 2003 07:50:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CoAK10597
	for <megaco-web-archive@optimus.ietf.org>; Thu, 3 Apr 2003 07:50:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17955
	for <megaco-web-archive@ietf.org>; Thu, 3 Apr 2003 07:47:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CljK10437;
	Thu, 3 Apr 2003 07:47:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Cj0K10212
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 07:45:00 -0500
Received: from hindon.hss.co.in (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17789
	for <megaco@ietf.org>; Thu, 3 Apr 2003 07:42:12 -0500 (EST)
From: bvswamy@hss.hns.com
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h33CgPs03027
	for <megaco@ietf.org>; Thu, 3 Apr 2003 18:12:35 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h33Cfe202978
	for <megaco@ietf.org>; Thu, 3 Apr 2003 18:11:50 +0530 (IST)
Received: from dlfmail1.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id h33CiI105338
	for <megaco@ietf.org>; Thu, 3 Apr 2003 18:14:28 +0530 (IST)
Received: by dlfmail1.hss.hns.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 65256CFD.004496D6 ; Thu, 3 Apr 2003 17:59:10 +0530
X-Lotus-FromDomain: HSS
To: megaco@ietf.org
Message-ID: <65256CFD.004496A6.00@dlfmail1.hss.hns.com>
Date: Thu, 3 Apr 2003 18:15:21 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Megaco] ADD handling for Out-of-service termination
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>



Hi

I have a query  related to ADD command processing for terminations involving
out-of-service terminations:
      An ADD request is received by an MG to add a termination in a context
which already has a OOS termination.
     Scenario:
     1) A termination added in a Context.
     2) MG operator puts the termination out of service
     3) MG sends Service change Forced to the MGC.
     4) Before MGC receives a ServiceChange, it has sent an ADD request(without
a Topolgy descriptor) to MG to add the termination in the
          above context.
Though it can be argued that MGC will always send substract request whenever it
receives ServiceChange Forced but
does it worth exchanging substract messages when ADD failure could have solved
the problem.
However there can be exception to this scenario where multiple terminations are
in context and only one termination is made OOS. Then
if MGC properly specifies the topology descriptor then ADD command should work.

Regards
venkat



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr  3 09:07:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20332
	for <megaco-archive@lists.ietf.org>; Thu, 3 Apr 2003 09:07:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33E7QK16924;
	Thu, 3 Apr 2003 09:07:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33E0uK15994
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 09:00:56 -0500
Received: from web10707.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20029
	for <megaco@ietf.org>; Thu, 3 Apr 2003 08:58:07 -0500 (EST)
Message-ID: <20030403140035.46097.qmail@web10707.mail.yahoo.com>
Received: from [203.124.158.2] by web10707.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 00:00:35 EST
Date: Fri, 4 Apr 2003 00:00:35 +1000 (EST)
From: =?iso-8859-1?q?petric=20john?= <petric_john@yahoo.com.au>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Megaco] Processing of command, action ...
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Hi,

This is in context of the text mentioned in 8.2.2 as
below.

S1: If the end of an action cannot be reliably
determined but one or more commands can be parsed, it
will process them and then send 422 - Syntax Error in
Action as the last action for the transaction.

S2: If the end of a transaction cannot be reliably
determined and one or more Actions can be parsed, it
will process them and then return 403 - Syntax Error
in Transaction as the last action reply for the
transaction. 

In both the above statemets, it is mentioned about the
unreliable determination of the action, and
transaction respectively. 

As mentioned, does processing of the commands (in S1)
means the execution of the commands, and does
processing of the action (in S2) means the execution
in the context of the MGC/MG application??? 

This apprently shows that even if the parsing
(decoding) of the given component of the protocol
message is partial, the decoded information is still
passed on to the MG/MGC application for further
processing/execution.

So far I am under impression that even a single parse
failure (at any level) of the messgge would prohibit
it from sending it to the application, thus rejecting
it compeletely.

what is the significance of the word "it will process
them"???

regards,



=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr  3 09:08:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20358
	for <megaco-archive@odin.ietf.org>; Thu, 3 Apr 2003 09:08:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33EAVe17361
	for megaco-archive@odin.ietf.org; Thu, 3 Apr 2003 09:10:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EAUK17358
	for <megaco-web-archive@optimus.ietf.org>; Thu, 3 Apr 2003 09:10:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20351
	for <megaco-web-archive@ietf.org>; Thu, 3 Apr 2003 09:07:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33E7QK16924;
	Thu, 3 Apr 2003 09:07:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33E0uK15994
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 09:00:56 -0500
Received: from web10707.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20029
	for <megaco@ietf.org>; Thu, 3 Apr 2003 08:58:07 -0500 (EST)
Message-ID: <20030403140035.46097.qmail@web10707.mail.yahoo.com>
Received: from [203.124.158.2] by web10707.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 00:00:35 EST
Date: Fri, 4 Apr 2003 00:00:35 +1000 (EST)
From: =?iso-8859-1?q?petric=20john?= <petric_john@yahoo.com.au>
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Megaco] Processing of command, action ...
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Hi,

This is in context of the text mentioned in 8.2.2 as
below.

S1: If the end of an action cannot be reliably
determined but one or more commands can be parsed, it
will process them and then send 422 - Syntax Error in
Action as the last action for the transaction.

S2: If the end of a transaction cannot be reliably
determined and one or more Actions can be parsed, it
will process them and then return 403 - Syntax Error
in Transaction as the last action reply for the
transaction. 

In both the above statemets, it is mentioned about the
unreliable determination of the action, and
transaction respectively. 

As mentioned, does processing of the commands (in S1)
means the execution of the commands, and does
processing of the action (in S2) means the execution
in the context of the MGC/MG application??? 

This apprently shows that even if the parsing
(decoding) of the given component of the protocol
message is partial, the decoded information is still
passed on to the MG/MGC application for further
processing/execution.

So far I am under impression that even a single parse
failure (at any level) of the messgge would prohibit
it from sending it to the application, thus rejecting
it compeletely.

what is the significance of the word "it will process
them"???

regards,



=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr  3 10:30:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25017
	for <megaco-archive@lists.ietf.org>; Thu, 3 Apr 2003 10:30:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FQrK24009;
	Thu, 3 Apr 2003 10:26:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33F7KK22531
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 10:07:20 -0500
Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22607
	for <megaco@ietf.org>; Thu, 3 Apr 2003 10:04:28 -0500 (EST)
Received: through eSafe SMTP Relay 1049380506; Thu Apr 03 18:03:45 2003
Received: by EXCHANGE with Internet Mail Service (5.5.2653.19)
	id <1SWY9GK1>; Thu, 3 Apr 2003 18:05:57 +0200
Message-ID: <B1584457374ED211B7A90008C7242DEF451571@EXCHANGE>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'petric john'" <petric_john@yahoo.com.au>, megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...
Date: Thu, 3 Apr 2003 18:05:56 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F9FA.E8E86600"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F9FA.E8E86600
Content-Type: text/plain;
	charset="iso-8859-1"

See [FSRT] within.

Raphael Tryster

-----Original Message-----
From: petric john [mailto:petric_john@yahoo.com.au]
Sent: Thursday, 3 April 2003 16:01
To: megaco@ietf.org
Subject: [Megaco] Processing of command, action ...


Hi,

This is in context of the text mentioned in 8.2.2 as
below.

S1: If the end of an action cannot be reliably
determined but one or more commands can be parsed, it
will process them and then send 422 - Syntax Error in
Action as the last action for the transaction.

S2: If the end of a transaction cannot be reliably
determined and one or more Actions can be parsed, it
will process them and then return 403 - Syntax Error
in Transaction as the last action reply for the
transaction. 

In both the above statemets, it is mentioned about the
unreliable determination of the action, and
transaction respectively. 

As mentioned, does processing of the commands (in S1)
means the execution of the commands, and does
processing of the action (in S2) means the execution
in the context of the MGC/MG application??? 

[FSRT] Yes.

This apprently shows that even if the parsing
(decoding) of the given component of the protocol
message is partial, the decoded information is still
passed on to the MG/MGC application for further
processing/execution.

[FSRT]  Yes.  In practice, it means your parser has to be able to generate
partial output, as well as an indication that the only processing required
for a specific command or action is to return an error.

So far I am under impression that even a single parse
failure (at any level) of the messgge would prohibit
it from sending it to the application, thus rejecting
it compeletely.

[FSRT]  That was my impression once too, but I couldn't find anything in the
standard to support it.

what is the significance of the word "it will process
them"???

[FSRT]  As if there were no subsequent error.

regards,



=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------_=_NextPart_001_01C2F9FA.E8E86600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>RE: [Megaco] Processing of command, action ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>See [FSRT] within.</FONT>
</P>

<P><FONT SIZE=3D2>Raphael Tryster</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: petric john [<A HREF=3D"mailto:petric_john@yahoo=
=2Ecom.au">mailto:petric_john@yahoo.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, 3 April 2003 16:01</FONT>
<BR><FONT SIZE=3D2>To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [Megaco] Processing of command, action ....</=
FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>This is in context of the text mentioned in 8.2.2 as</F=
ONT>
<BR><FONT SIZE=3D2>below.</FONT>
</P>

<P><FONT SIZE=3D2>S1: If the end of an action cannot be reliably</FONT>
<BR><FONT SIZE=3D2>determined but one or more commands can be parsed, it<=
/FONT>
<BR><FONT SIZE=3D2>will process them and then send 422 - Syntax Error in<=
/FONT>
<BR><FONT SIZE=3D2>Action as the last action for the transaction.</FONT>
</P>

<P><FONT SIZE=3D2>S2: If the end of a transaction cannot be reliably</FON=
T>
<BR><FONT SIZE=3D2>determined and one or more Actions can be parsed, it</=
FONT>
<BR><FONT SIZE=3D2>will process them and then return 403 - Syntax Error</=
FONT>
<BR><FONT SIZE=3D2>in Transaction as the last action reply for the</FONT>
<BR><FONT SIZE=3D2>transaction. </FONT>
</P>

<P><FONT SIZE=3D2>In both the above statemets, it is mentioned about the<=
/FONT>
<BR><FONT SIZE=3D2>unreliable determination of the action, and</FONT>
<BR><FONT SIZE=3D2>transaction respectively. </FONT>
</P>

<P><FONT SIZE=3D2>As mentioned, does processing of the commands (in S1)</=
FONT>
<BR><FONT SIZE=3D2>means the execution of the commands, and does</FONT>
<BR><FONT SIZE=3D2>processing of the action (in S2) means the execution</=
FONT>
<BR><FONT SIZE=3D2>in the context of the MGC/MG application??? </FONT>
</P>

<P><FONT SIZE=3D2>[FSRT] Yes.</FONT>
</P>

<P><FONT SIZE=3D2>This apprently shows that even if the parsing</FONT>
<BR><FONT SIZE=3D2>(decoding) of the given component of the protocol</FON=
T>
<BR><FONT SIZE=3D2>message is partial, the decoded information is still</=
FONT>
<BR><FONT SIZE=3D2>passed on to the MG/MGC application for further</FONT>
<BR><FONT SIZE=3D2>processing/execution.</FONT>
</P>

<P><FONT SIZE=3D2>[FSRT]&nbsp; Yes.&nbsp; In practice, it means your pars=
er has to be able to generate partial output, as well as an indication th=
at the only processing required for a specific command or action is to re=
turn an error.</FONT></P>

<P><FONT SIZE=3D2>So far I am under impression that even a single parse</=
FONT>
<BR><FONT SIZE=3D2>failure (at any level) of the messgge would prohibit</=
FONT>
<BR><FONT SIZE=3D2>it from sending it to the application, thus rejecting<=
/FONT>
<BR><FONT SIZE=3D2>it compeletely.</FONT>
</P>

<P><FONT SIZE=3D2>[FSRT]&nbsp; That was my impression once too, but I cou=
ldn't find anything in the standard to support it.</FONT>
</P>

<P><FONT SIZE=3D2>what is the significance of the word &quot;it will proc=
ess</FONT>
<BR><FONT SIZE=3D2>them&quot;???</FONT>
</P>

<P><FONT SIZE=3D2>[FSRT]&nbsp; As if there were no subsequent error.</FON=
T>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>~|~ </FONT>
<BR><FONT SIZE=3D2>&nbsp;o </FONT>
<BR><FONT SIZE=3D2>John</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://mobile.yahoo.com.au" TARGET=3D"_blank=
">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>- Check &amp; compose your email via SMS on your Telst=
ra or Vodafone mobile.</FONT>
<BR><FONT SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"https://www1.ietf.org/mailman/listinfo/mega=
co" TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></=
FONT>
</P>

</BODY>
</HTML>

------_=_NextPart_001_01C2F9FA.E8E86600--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr  3 10:31:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25099
	for <megaco-archive@odin.ietf.org>; Thu, 3 Apr 2003 10:31:30 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h33FXnt24714
	for megaco-archive@odin.ietf.org; Thu, 3 Apr 2003 10:33:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FXnK24711
	for <megaco-web-archive@optimus.ietf.org>; Thu, 3 Apr 2003 10:33:49 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25078
	for <megaco-web-archive@ietf.org>; Thu, 3 Apr 2003 10:30:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33FQrK24009;
	Thu, 3 Apr 2003 10:26:53 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33F7KK22531
	for <megaco@optimus.ietf.org>; Thu, 3 Apr 2003 10:07:20 -0500
Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22607
	for <megaco@ietf.org>; Thu, 3 Apr 2003 10:04:28 -0500 (EST)
Received: through eSafe SMTP Relay 1049380506; Thu Apr 03 18:03:45 2003
Received: by EXCHANGE with Internet Mail Service (5.5.2653.19)
	id <1SWY9GK1>; Thu, 3 Apr 2003 18:05:57 +0200
Message-ID: <B1584457374ED211B7A90008C7242DEF451571@EXCHANGE>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'petric john'" <petric_john@yahoo.com.au>, megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...
Date: Thu, 3 Apr 2003 18:05:56 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2F9FA.E8E86600"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F9FA.E8E86600
Content-Type: text/plain;
	charset="iso-8859-1"

See [FSRT] within.

Raphael Tryster

-----Original Message-----
From: petric john [mailto:petric_john@yahoo.com.au]
Sent: Thursday, 3 April 2003 16:01
To: megaco@ietf.org
Subject: [Megaco] Processing of command, action ...


Hi,

This is in context of the text mentioned in 8.2.2 as
below.

S1: If the end of an action cannot be reliably
determined but one or more commands can be parsed, it
will process them and then send 422 - Syntax Error in
Action as the last action for the transaction.

S2: If the end of a transaction cannot be reliably
determined and one or more Actions can be parsed, it
will process them and then return 403 - Syntax Error
in Transaction as the last action reply for the
transaction. 

In both the above statemets, it is mentioned about the
unreliable determination of the action, and
transaction respectively. 

As mentioned, does processing of the commands (in S1)
means the execution of the commands, and does
processing of the action (in S2) means the execution
in the context of the MGC/MG application??? 

[FSRT] Yes.

This apprently shows that even if the parsing
(decoding) of the given component of the protocol
message is partial, the decoded information is still
passed on to the MG/MGC application for further
processing/execution.

[FSRT]  Yes.  In practice, it means your parser has to be able to generate
partial output, as well as an indication that the only processing required
for a specific command or action is to return an error.

So far I am under impression that even a single parse
failure (at any level) of the messgge would prohibit
it from sending it to the application, thus rejecting
it compeletely.

[FSRT]  That was my impression once too, but I couldn't find anything in the
standard to support it.

what is the significance of the word "it will process
them"???

[FSRT]  As if there were no subsequent error.

regards,



=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------_=_NextPart_001_01C2F9FA.E8E86600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>RE: [Megaco] Processing of command, action ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>See [FSRT] within.</FONT>
</P>

<P><FONT SIZE=3D2>Raphael Tryster</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: petric john [<A HREF=3D"mailto:petric_john@yahoo=
=2Ecom.au">mailto:petric_john@yahoo.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, 3 April 2003 16:01</FONT>
<BR><FONT SIZE=3D2>To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [Megaco] Processing of command, action ....</=
FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>This is in context of the text mentioned in 8.2.2 as</F=
ONT>
<BR><FONT SIZE=3D2>below.</FONT>
</P>

<P><FONT SIZE=3D2>S1: If the end of an action cannot be reliably</FONT>
<BR><FONT SIZE=3D2>determined but one or more commands can be parsed, it<=
/FONT>
<BR><FONT SIZE=3D2>will process them and then send 422 - Syntax Error in<=
/FONT>
<BR><FONT SIZE=3D2>Action as the last action for the transaction.</FONT>
</P>

<P><FONT SIZE=3D2>S2: If the end of a transaction cannot be reliably</FON=
T>
<BR><FONT SIZE=3D2>determined and one or more Actions can be parsed, it</=
FONT>
<BR><FONT SIZE=3D2>will process them and then return 403 - Syntax Error</=
FONT>
<BR><FONT SIZE=3D2>in Transaction as the last action reply for the</FONT>
<BR><FONT SIZE=3D2>transaction. </FONT>
</P>

<P><FONT SIZE=3D2>In both the above statemets, it is mentioned about the<=
/FONT>
<BR><FONT SIZE=3D2>unreliable determination of the action, and</FONT>
<BR><FONT SIZE=3D2>transaction respectively. </FONT>
</P>

<P><FONT SIZE=3D2>As mentioned, does processing of the commands (in S1)</=
FONT>
<BR><FONT SIZE=3D2>means the execution of the commands, and does</FONT>
<BR><FONT SIZE=3D2>processing of the action (in S2) means the execution</=
FONT>
<BR><FONT SIZE=3D2>in the context of the MGC/MG application??? </FONT>
</P>

<P><FONT SIZE=3D2>[FSRT] Yes.</FONT>
</P>

<P><FONT SIZE=3D2>This apprently shows that even if the parsing</FONT>
<BR><FONT SIZE=3D2>(decoding) of the given component of the protocol</FON=
T>
<BR><FONT SIZE=3D2>message is partial, the decoded information is still</=
FONT>
<BR><FONT SIZE=3D2>passed on to the MG/MGC application for further</FONT>
<BR><FONT SIZE=3D2>processing/execution.</FONT>
</P>

<P><FONT SIZE=3D2>[FSRT]&nbsp; Yes.&nbsp; In practice, it means your pars=
er has to be able to generate partial output, as well as an indication th=
at the only processing required for a specific command or action is to re=
turn an error.</FONT></P>

<P><FONT SIZE=3D2>So far I am under impression that even a single parse</=
FONT>
<BR><FONT SIZE=3D2>failure (at any level) of the messgge would prohibit</=
FONT>
<BR><FONT SIZE=3D2>it from sending it to the application, thus rejecting<=
/FONT>
<BR><FONT SIZE=3D2>it compeletely.</FONT>
</P>

<P><FONT SIZE=3D2>[FSRT]&nbsp; That was my impression once too, but I cou=
ldn't find anything in the standard to support it.</FONT>
</P>

<P><FONT SIZE=3D2>what is the significance of the word &quot;it will proc=
ess</FONT>
<BR><FONT SIZE=3D2>them&quot;???</FONT>
</P>

<P><FONT SIZE=3D2>[FSRT]&nbsp; As if there were no subsequent error.</FON=
T>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>~|~ </FONT>
<BR><FONT SIZE=3D2>&nbsp;o </FONT>
<BR><FONT SIZE=3D2>John</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://mobile.yahoo.com.au" TARGET=3D"_blank=
">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>- Check &amp; compose your email via SMS on your Telst=
ra or Vodafone mobile.</FONT>
<BR><FONT SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"https://www1.ietf.org/mailman/listinfo/mega=
co" TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></=
FONT>
</P>

</BODY>
</HTML>

------_=_NextPart_001_01C2F9FA.E8E86600--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr  4 00:49:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26694
	for <megaco-archive@lists.ietf.org>; Fri, 4 Apr 2003 00:49:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345oFK02997;
	Fri, 4 Apr 2003 00:50:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345lpK02903
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 00:47:51 -0500
Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26601
	for <megaco@ietf.org>; Fri, 4 Apr 2003 00:44:42 -0500 (EST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h345kwVS023177;
	Thu, 3 Apr 2003 23:47:07 -0600 (CST)
Received: from axws59 ([10.255.5.109])
	by ssd.usa.alcatel.com (8.12.8/8.12.8) with SMTP id h345k01B027576;
	Thu, 3 Apr 2003 23:46:00 -0600 (CST)
Message-ID: <00ae01c2fa6f$a5626c80$6d05ff0a@axws59>
From: "Selvam.V" <sveeragh@ssd.usa.alcatel.com>
To: <bvswamy@hss.hns.com>, <megaco@ietf.org>
References: <65256CFD.004496A6.00@dlfmail1.hss.hns.com>
Subject: Re: [Megaco] ADD handling for Out-of-service termination
Date: Fri, 4 Apr 2003 11:31:31 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,
        Is there is a need to send a subtract command.
        what will be the contextID in the subtract command.
        when the Termination is OOS, it will be returning an error for the
ADD
        request.

        Best Regards,
        selva

----- Original Message -----
From: <bvswamy@hss.hns.com>
To: <megaco@ietf.org>
Sent: Thursday, April 03, 2003 6:15 PM
Subject: [Megaco] ADD handling for Out-of-service termination


>
>
> Hi
>
> I have a query  related to ADD command processing for terminations
involving
> out-of-service terminations:
>       An ADD request is received by an MG to add a termination in a
context
> which already has a OOS termination.
>      Scenario:
>      1) A termination added in a Context.
>      2) MG operator puts the termination out of service
>      3) MG sends Service change Forced to the MGC.
>      4) Before MGC receives a ServiceChange, it has sent an ADD
request(without
> a Topolgy descriptor) to MG to add the termination in the
>           above context.
> Though it can be argued that MGC will always send substract request
whenever it
> receives ServiceChange Forced but
> does it worth exchanging substract messages when ADD failure could have
solved
> the problem.
> However there can be exception to this scenario where multiple
terminations are
> in context and only one termination is made OOS. Then
> if MGC properly specifies the topology descriptor then ADD command should
work.
>
> Regards
> venkat
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr  4 00:51:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26750
	for <megaco-archive@odin.ietf.org>; Fri, 4 Apr 2003 00:51:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h345rvX03162
	for megaco-archive@odin.ietf.org; Fri, 4 Apr 2003 00:53:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345ruK03159
	for <megaco-web-archive@optimus.ietf.org>; Fri, 4 Apr 2003 00:53:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26728
	for <megaco-web-archive@ietf.org>; Fri, 4 Apr 2003 00:50:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345oFK02997;
	Fri, 4 Apr 2003 00:50:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h345lpK02903
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 00:47:51 -0500
Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26601
	for <megaco@ietf.org>; Fri, 4 Apr 2003 00:44:42 -0500 (EST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h345kwVS023177;
	Thu, 3 Apr 2003 23:47:07 -0600 (CST)
Received: from axws59 ([10.255.5.109])
	by ssd.usa.alcatel.com (8.12.8/8.12.8) with SMTP id h345k01B027576;
	Thu, 3 Apr 2003 23:46:00 -0600 (CST)
Message-ID: <00ae01c2fa6f$a5626c80$6d05ff0a@axws59>
From: "Selvam.V" <sveeragh@ssd.usa.alcatel.com>
To: <bvswamy@hss.hns.com>, <megaco@ietf.org>
References: <65256CFD.004496A6.00@dlfmail1.hss.hns.com>
Subject: Re: [Megaco] ADD handling for Out-of-service termination
Date: Fri, 4 Apr 2003 11:31:31 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,
        Is there is a need to send a subtract command.
        what will be the contextID in the subtract command.
        when the Termination is OOS, it will be returning an error for the
ADD
        request.

        Best Regards,
        selva

----- Original Message -----
From: <bvswamy@hss.hns.com>
To: <megaco@ietf.org>
Sent: Thursday, April 03, 2003 6:15 PM
Subject: [Megaco] ADD handling for Out-of-service termination


>
>
> Hi
>
> I have a query  related to ADD command processing for terminations
involving
> out-of-service terminations:
>       An ADD request is received by an MG to add a termination in a
context
> which already has a OOS termination.
>      Scenario:
>      1) A termination added in a Context.
>      2) MG operator puts the termination out of service
>      3) MG sends Service change Forced to the MGC.
>      4) Before MGC receives a ServiceChange, it has sent an ADD
request(without
> a Topolgy descriptor) to MG to add the termination in the
>           above context.
> Though it can be argued that MGC will always send substract request
whenever it
> receives ServiceChange Forced but
> does it worth exchanging substract messages when ADD failure could have
solved
> the problem.
> However there can be exception to this scenario where multiple
terminations are
> in context and only one termination is made OOS. Then
> if MGC properly specifies the topology descriptor then ADD command should
work.
>
> Regards
> venkat
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr  4 04:25:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12035
	for <megaco-archive@lists.ietf.org>; Fri, 4 Apr 2003 04:25:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349QZK28448;
	Fri, 4 Apr 2003 04:26:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349NYK28352
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 04:23:34 -0500
Received: from qmail-b.directi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11901
	for <megaco@ietf.org>; Fri, 4 Apr 2003 04:20:21 -0500 (EST)
Received: (qmail 15045 invoked by uid 0); 4 Apr 2003 09:22:45 -0000
Received: from unknown (HELO omair) (203.129.216.107)
  by 203.199.107.94 with SMTP; 4 Apr 2003 09:22:45 -0000
Message-ID: <004201c2fa8b$c45e55b0$6bd881cb@ilocus.com>
From: "Omair Nissar" <omair@ilocus.com>
To: <megaco@ietf.org>
Date: Fri, 4 Apr 2003 14:52:24 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003D_01C2FAB9.CD7B9F80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Megaco] MEGACO Marketplace
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C2FAB9.CD7B9F80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear...,

             i am doing research on Megaco Marketplace and i am supposed =
to prepare a report on Megaco and its Marketplace .i have recently =
subscribed for Megaco mailing list.i would like to have some information =
regarding Megaco.Below are some queries

1. Deployment of Megaco
2.Revenue generated from this stack
3.Market share from Megaco
4.Estimate and forecast



Regards

omair

Business Dev.Associate

iLocus

15-sidco Electronics Complex
Rangreth,Budgam-7,J&K, India
Tel :- 0194 2300594
E-Mail :- omair@ilocus.com

------=_NextPart_000_003D_01C2FAB9.CD7B9F80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear...,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
i am doing research on Megaco Marketplace and i am supposed to prepare a =
report=20
on Megaco and its Marketplace .i have recently subscribed for Megaco =
mailing=20
list.i would like to have some information regarding Megaco.Below are =
some=20
queries</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. Deployment of Megaco</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2.Revenue generated from this =
stack</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3.Market share from Megaco</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>4.Estimate and forecast</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Regards</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>omair</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Business =
Dev.Associate</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>iLocus</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff>15-sidco =
Electronics=20
Complex<BR>Rangreth,Budgam-7,J&amp;K, India<BR>Tel :- 0194 =
2300594<BR>E-Mail :-=20
</FONT><A=20
href=3D"mailto:omair@ilocus.com">omair@ilocus.com</A><BR></FONT></DIV></B=
ODY></HTML>

------=_NextPart_000_003D_01C2FAB9.CD7B9F80--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr  4 04:27:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12061
	for <megaco-archive@odin.ietf.org>; Fri, 4 Apr 2003 04:27:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h349U7r28543
	for megaco-archive@odin.ietf.org; Fri, 4 Apr 2003 04:30:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349U6K28540
	for <megaco-web-archive@optimus.ietf.org>; Fri, 4 Apr 2003 04:30:06 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12052
	for <megaco-web-archive@ietf.org>; Fri, 4 Apr 2003 04:26:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349QZK28448;
	Fri, 4 Apr 2003 04:26:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349NYK28352
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 04:23:34 -0500
Received: from qmail-b.directi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11901
	for <megaco@ietf.org>; Fri, 4 Apr 2003 04:20:21 -0500 (EST)
Received: (qmail 15045 invoked by uid 0); 4 Apr 2003 09:22:45 -0000
Received: from unknown (HELO omair) (203.129.216.107)
  by 203.199.107.94 with SMTP; 4 Apr 2003 09:22:45 -0000
Message-ID: <004201c2fa8b$c45e55b0$6bd881cb@ilocus.com>
From: "Omair Nissar" <omair@ilocus.com>
To: <megaco@ietf.org>
Date: Fri, 4 Apr 2003 14:52:24 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003D_01C2FAB9.CD7B9F80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [Megaco] MEGACO Marketplace
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_003D_01C2FAB9.CD7B9F80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear...,

             i am doing research on Megaco Marketplace and i am supposed =
to prepare a report on Megaco and its Marketplace .i have recently =
subscribed for Megaco mailing list.i would like to have some information =
regarding Megaco.Below are some queries

1. Deployment of Megaco
2.Revenue generated from this stack
3.Market share from Megaco
4.Estimate and forecast



Regards

omair

Business Dev.Associate

iLocus

15-sidco Electronics Complex
Rangreth,Budgam-7,J&K, India
Tel :- 0194 2300594
E-Mail :- omair@ilocus.com

------=_NextPart_000_003D_01C2FAB9.CD7B9F80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear...,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
i am doing research on Megaco Marketplace and i am supposed to prepare a =
report=20
on Megaco and its Marketplace .i have recently subscribed for Megaco =
mailing=20
list.i would like to have some information regarding Megaco.Below are =
some=20
queries</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. Deployment of Megaco</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2.Revenue generated from this =
stack</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3.Market share from Megaco</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>4.Estimate and forecast</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Regards</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>omair</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Business =
Dev.Associate</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>iLocus</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff>15-sidco =
Electronics=20
Complex<BR>Rangreth,Budgam-7,J&amp;K, India<BR>Tel :- 0194 =
2300594<BR>E-Mail :-=20
</FONT><A=20
href=3D"mailto:omair@ilocus.com">omair@ilocus.com</A><BR></FONT></DIV></B=
ODY></HTML>

------=_NextPart_000_003D_01C2FAB9.CD7B9F80--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr  4 06:39:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14839
	for <megaco-archive@lists.ietf.org>; Fri, 4 Apr 2003 06:39:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Bd7K04560;
	Fri, 4 Apr 2003 06:39:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BZQK03694
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 06:35:26 -0500
Received: from web10704.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14586
	for <megaco@ietf.org>; Fri, 4 Apr 2003 06:32:10 -0500 (EST)
Message-ID: <20030404113440.69089.qmail@web10704.mail.yahoo.com>
Received: from [203.124.158.2] by web10704.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 21:34:40 EST
Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)
From: =?iso-8859-1?q?petric=20john?= <petric_john@yahoo.com.au>
Subject: RE: [Megaco] Processing of command, action ...
To: megaco@ietf.org, petric john <petric_john@yahoo.com.au>,
        Raphael Tryster <raphael@tdsoft.com>
Cc: taylor@nortelnetworks.com, kboyle@nortelnetworks.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Sorry, forgot to post it to mailing list.
Repeating the same.

-- john

 --- petric john <petric_john@yahoo.com.au> wrote: >
see the comments with [PJJ]
> 
>  --- Raphael Tryster <raphael@tdsoft.com> wrote: >
> See
> [FSRT] within.
> > 
> > Raphael Tryster
> > 
> > -----Original Message-----
> > From: petric john
> [mailto:petric_john@yahoo.com.au]
> > Sent: Thursday, 3 April 2003 16:01
> > To: megaco@ietf.org
> > Subject: [Megaco] Processing of command, action
> ...
> > 
> > 
> > Hi,
> > 
> > This is in context of the text mentioned in 8.2.2
> as
> > below.
> > 
> > S1: If the end of an action cannot be reliably
> > determined but one or more commands can be parsed,
> > it
> > will process them and then send 422 - Syntax Error
> > in
> > Action as the last action for the transaction.
> > 
> > S2: If the end of a transaction cannot be reliably
> > determined and one or more Actions can be parsed,
> it
> > will process them and then return 403 - Syntax
> Error
> > in Transaction as the last action reply for the
> > transaction. 
> > 
> > In both the above statemets, it is mentioned about
> > the
> > unreliable determination of the action, and
> > transaction respectively. 
> > 
> > As mentioned, does processing of the commands (in
> > S1)
> > means the execution of the commands, and does
> > processing of the action (in S2) means the
> execution
> > in the context of the MGC/MG application??? 
> > 
> > [FSRT] Yes.
> > 
> [PJJ] I think then there are more issues asociated
> with this. See below.
> 
> > This apprently shows that even if the parsing
> > (decoding) of the given component of the protocol
> > message is partial, the decoded information is
> still
> > passed on to the MG/MGC application for further
> > processing/execution.
> > 
> > [FSRT]  Yes.  In practice, it means your parser
> has
> > to be able to generate
> > partial output, as well as an indication that the
> > only processing required
> > for a specific command or action is to return an
> > error.
> > 
> [PJJ] 
> 
> 1. Assume that there are four commands in an action.
> Now the parsing of the command 1 and 2 was
> successful,
> and the third one failed. Then according to the
> above,
> we shall send the command 1 and 2 to the
> application.
> What about the command command number 4 in the
> action
> (which could be syntactically correct)? What we
> should
> do to it??
> 
> 2. If we have to still parse for the command 4 in
> the
> action, then it is going to be difficult to know the
> exact start of the command 4 in the action.
> 
> 3. What would be the action on the sender's side in
> this case?? As we shall report the error "422 -
> Syntax
> Error in Action" to the sender, how its going to
> retransmitt the commands 3 and 4??
> 
> 4. Partial decoding is certainly not applicable in
> case of command, as it does make any sense to do so.
> Also the basic unit of the data that has to go to
> the
> application is Command, and it should be complete at
> any point of time. Thus when sender, after receiving
> the 422, shall send the command 3 and 4 with the
> same
> TransactionId (hopefully), in which case it will be
> the re-transmission of the Transaction (which is
> again
> not correct). The resending of the commands 3 and 4
> has to be a new Transaction. Correct me if wrong.
> 
> 5. To make above process more complex, assume if the
> command 1 and 3 were parsed successfully. then
> should
> we send command 1 and 3 to the application?? (even
> otherwise parsing of the alternate commands is
> definitely not easy. Same is the case with Action,
> see
> below.
> 
> 6. I would like to make a point here that as long as
> the parsing of the commands in the action (and so
> actions in the Transaction) is moving successfully,
> the information is useful. But we should stop
> parsing
> as soon as the command decode is failure, and jump
> to
> the next action in the Transaction (if present).
> 
> 7. The parsing logic is certainly going to be
> complex
> to find out the next Action in the Transaction. 
> 
> looking forward for the clarifications. ;-)
> 
> > So far I am under impression that even a single
> > parse
> > failure (at any level) of the messgge would
> prohibit
> > it from sending it to the application, thus
> > rejecting
> > it compeletely.
> > 
> > [FSRT]  That was my impression once too, but I
> > couldn't find anything in the
> > standard to support it.
> > 
> [PJJ] Same here. I guess there is no support in the
> standard too for the some of the doubts raised
> above.
> 
> > what is the significance of the word "it will
> > process
> > them"???
> > 
> > [FSRT]  As if there were no subsequent error.
> > 
> > regards,
> > 
> > 
> > 
> > =====
> > ~|~ 
> >  o 
> > John
> > 
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your
> Telstra
> > or Vodafone mobile.
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >  
> 
> =====
> ~|~ 
>  o 
> John
> 
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra
> or Vodafone mobile.
>  

=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr  4 06:41:44 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14931
	for <megaco-archive@odin.ietf.org>; Fri, 4 Apr 2003 06:41:44 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h34BiS204779
	for megaco-archive@odin.ietf.org; Fri, 4 Apr 2003 06:44:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BiSK04776
	for <megaco-web-archive@optimus.ietf.org>; Fri, 4 Apr 2003 06:44:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14926
	for <megaco-web-archive@ietf.org>; Fri, 4 Apr 2003 06:41:12 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Bd7K04560;
	Fri, 4 Apr 2003 06:39:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BZQK03694
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 06:35:26 -0500
Received: from web10704.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14586
	for <megaco@ietf.org>; Fri, 4 Apr 2003 06:32:10 -0500 (EST)
Message-ID: <20030404113440.69089.qmail@web10704.mail.yahoo.com>
Received: from [203.124.158.2] by web10704.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 21:34:40 EST
Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)
From: =?iso-8859-1?q?petric=20john?= <petric_john@yahoo.com.au>
Subject: RE: [Megaco] Processing of command, action ...
To: megaco@ietf.org, petric john <petric_john@yahoo.com.au>,
        Raphael Tryster <raphael@tdsoft.com>
Cc: taylor@nortelnetworks.com, kboyle@nortelnetworks.com
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Sorry, forgot to post it to mailing list.
Repeating the same.

-- john

 --- petric john <petric_john@yahoo.com.au> wrote: >
see the comments with [PJJ]
> 
>  --- Raphael Tryster <raphael@tdsoft.com> wrote: >
> See
> [FSRT] within.
> > 
> > Raphael Tryster
> > 
> > -----Original Message-----
> > From: petric john
> [mailto:petric_john@yahoo.com.au]
> > Sent: Thursday, 3 April 2003 16:01
> > To: megaco@ietf.org
> > Subject: [Megaco] Processing of command, action
> ...
> > 
> > 
> > Hi,
> > 
> > This is in context of the text mentioned in 8.2.2
> as
> > below.
> > 
> > S1: If the end of an action cannot be reliably
> > determined but one or more commands can be parsed,
> > it
> > will process them and then send 422 - Syntax Error
> > in
> > Action as the last action for the transaction.
> > 
> > S2: If the end of a transaction cannot be reliably
> > determined and one or more Actions can be parsed,
> it
> > will process them and then return 403 - Syntax
> Error
> > in Transaction as the last action reply for the
> > transaction. 
> > 
> > In both the above statemets, it is mentioned about
> > the
> > unreliable determination of the action, and
> > transaction respectively. 
> > 
> > As mentioned, does processing of the commands (in
> > S1)
> > means the execution of the commands, and does
> > processing of the action (in S2) means the
> execution
> > in the context of the MGC/MG application??? 
> > 
> > [FSRT] Yes.
> > 
> [PJJ] I think then there are more issues asociated
> with this. See below.
> 
> > This apprently shows that even if the parsing
> > (decoding) of the given component of the protocol
> > message is partial, the decoded information is
> still
> > passed on to the MG/MGC application for further
> > processing/execution.
> > 
> > [FSRT]  Yes.  In practice, it means your parser
> has
> > to be able to generate
> > partial output, as well as an indication that the
> > only processing required
> > for a specific command or action is to return an
> > error.
> > 
> [PJJ] 
> 
> 1. Assume that there are four commands in an action.
> Now the parsing of the command 1 and 2 was
> successful,
> and the third one failed. Then according to the
> above,
> we shall send the command 1 and 2 to the
> application.
> What about the command command number 4 in the
> action
> (which could be syntactically correct)? What we
> should
> do to it??
> 
> 2. If we have to still parse for the command 4 in
> the
> action, then it is going to be difficult to know the
> exact start of the command 4 in the action.
> 
> 3. What would be the action on the sender's side in
> this case?? As we shall report the error "422 -
> Syntax
> Error in Action" to the sender, how its going to
> retransmitt the commands 3 and 4??
> 
> 4. Partial decoding is certainly not applicable in
> case of command, as it does make any sense to do so.
> Also the basic unit of the data that has to go to
> the
> application is Command, and it should be complete at
> any point of time. Thus when sender, after receiving
> the 422, shall send the command 3 and 4 with the
> same
> TransactionId (hopefully), in which case it will be
> the re-transmission of the Transaction (which is
> again
> not correct). The resending of the commands 3 and 4
> has to be a new Transaction. Correct me if wrong.
> 
> 5. To make above process more complex, assume if the
> command 1 and 3 were parsed successfully. then
> should
> we send command 1 and 3 to the application?? (even
> otherwise parsing of the alternate commands is
> definitely not easy. Same is the case with Action,
> see
> below.
> 
> 6. I would like to make a point here that as long as
> the parsing of the commands in the action (and so
> actions in the Transaction) is moving successfully,
> the information is useful. But we should stop
> parsing
> as soon as the command decode is failure, and jump
> to
> the next action in the Transaction (if present).
> 
> 7. The parsing logic is certainly going to be
> complex
> to find out the next Action in the Transaction. 
> 
> looking forward for the clarifications. ;-)
> 
> > So far I am under impression that even a single
> > parse
> > failure (at any level) of the messgge would
> prohibit
> > it from sending it to the application, thus
> > rejecting
> > it compeletely.
> > 
> > [FSRT]  That was my impression once too, but I
> > couldn't find anything in the
> > standard to support it.
> > 
> [PJJ] Same here. I guess there is no support in the
> standard too for the some of the doubts raised
> above.
> 
> > what is the significance of the word "it will
> > process
> > them"???
> > 
> > [FSRT]  As if there were no subsequent error.
> > 
> > regards,
> > 
> > 
> > 
> > =====
> > ~|~ 
> >  o 
> > John
> > 
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your
> Telstra
> > or Vodafone mobile.
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >  
> 
> =====
> ~|~ 
>  o 
> John
> 
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra
> or Vodafone mobile.
>  

=====
~|~ 
 o 
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr  4 06:49:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16288
	for <megaco-archive@lists.ietf.org>; Fri, 4 Apr 2003 06:49:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BnhK05421;
	Fri, 4 Apr 2003 06:49:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BlVK05228
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 06:47:31 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15418;
	Fri, 4 Apr 2003 06:44:15 -0500 (EST)
Message-Id: <200304041144.GAA15418@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: megaco@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 04 Apr 2003 06:44:15 -0500
Subject: [Megaco] I-D ACTION:draft-ietf-megaco-h248v2-04.txt
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

	Title		: The Megaco/H.248v2 Gateway Control Protocol, version 2
	Author(s)	: C. Groves, M. Pantaleo et al.
	Filename	: draft-ietf-megaco-h248v2-04.txt
	Pages		: 219
	Date		: 2003-4-3
	
This document describes the second version of the general-purpose 
gateway control protocol standardized as Megaco in the IETF and as 
Recommendation H.248 (now H.248.1) in the ITU-T.  It is common text 
with Recommendation H.248.1 (05/02), published by the ITU-T.  Megaco 
v2 includes the corrections to RFC 3015 which resulted in RFC xxxx 
[draft-ietf-megaco-3015corr-02.txt], plus the following new 
capabilities: 
- ability to audit specific properties, events, signals and 
statistics 
- use of serviceChange to indicate that capabilities have changed in 
the Media Gateway 
- playing a signal on the Root Termination 
- limiting the number of repetitions of transaction pending 
- allowing topology to be set per stream 
- ability to audit context properties 
- new Nx64K multiplex type 
- provision for digit buffering when a digit map completes. 
In addition, the use of the Modem Descriptor was deprecated. 
A detailed list of changes from draft-ietf-megaco-3015corr-
02.txt/H.248.1 (03/02) to this document is given in Appendix II at 
the end of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-megaco-h248v2-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-4065214.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-megaco-h248v2-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-4065214.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr  4 06:52:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16849
	for <megaco-archive@odin.ietf.org>; Fri, 4 Apr 2003 06:52:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h34Bsxk06716
	for megaco-archive@odin.ietf.org; Fri, 4 Apr 2003 06:54:59 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BsxK06713
	for <megaco-web-archive@optimus.ietf.org>; Fri, 4 Apr 2003 06:54:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16619
	for <megaco-web-archive@ietf.org>; Fri, 4 Apr 2003 06:51:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BnhK05421;
	Fri, 4 Apr 2003 06:49:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BlVK05228
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 06:47:31 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15418;
	Fri, 4 Apr 2003 06:44:15 -0500 (EST)
Message-Id: <200304041144.GAA15418@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: megaco@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 04 Apr 2003 06:44:15 -0500
Subject: [Megaco] I-D ACTION:draft-ietf-megaco-h248v2-04.txt
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

	Title		: The Megaco/H.248v2 Gateway Control Protocol, version 2
	Author(s)	: C. Groves, M. Pantaleo et al.
	Filename	: draft-ietf-megaco-h248v2-04.txt
	Pages		: 219
	Date		: 2003-4-3
	
This document describes the second version of the general-purpose 
gateway control protocol standardized as Megaco in the IETF and as 
Recommendation H.248 (now H.248.1) in the ITU-T.  It is common text 
with Recommendation H.248.1 (05/02), published by the ITU-T.  Megaco 
v2 includes the corrections to RFC 3015 which resulted in RFC xxxx 
[draft-ietf-megaco-3015corr-02.txt], plus the following new 
capabilities: 
- ability to audit specific properties, events, signals and 
statistics 
- use of serviceChange to indicate that capabilities have changed in 
the Media Gateway 
- playing a signal on the Root Termination 
- limiting the number of repetitions of transaction pending 
- allowing topology to be set per stream 
- ability to audit context properties 
- new Nx64K multiplex type 
- provision for digit buffering when a digit map completes. 
In addition, the use of the Modem Descriptor was deprecated. 
A detailed list of changes from draft-ietf-megaco-3015corr-
02.txt/H.248.1 (03/02) to this document is given in Appendix II at 
the end of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-megaco-h248v2-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-4065214.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-megaco-h248v2-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-4065214.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr  4 08:56:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22003
	for <megaco-archive@lists.ietf.org>; Fri, 4 Apr 2003 08:56:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DuYK17034;
	Fri, 4 Apr 2003 08:56:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DqFK16906
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 08:52:15 -0500
Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21781
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:48:58 -0500 (EST)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DpQU24940
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:51:26 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GD8QL72S>; Fri, 4 Apr 2003 08:51:26 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C088D9020@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bvswamy@hss.hns.com, megaco@ietf.org
Subject: RE: [Megaco] ADD handling for Out-of-service termination
Date: Fri, 4 Apr 2003 08:51:24 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Having an OOS term in a context does NOT preclude addition of another term.

It is clearly stated in the spec that the MGC will subtract the OOS term.
However, if another term is added in the meantime, the MG should do as it is
told, and add the new term into the context.

Also, what does TP have to do with adding a term if one is OOS?  The term
will be subtracted imminently -- I do not see the problem here.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] 
Sent: Thursday, April 03, 2003 7:45 AM
To: megaco@ietf.org
Subject: [Megaco] ADD handling for Out-of-service termination




Hi

I have a query  related to ADD command processing for terminations involving
out-of-service terminations:
      An ADD request is received by an MG to add a termination in a context
which already has a OOS termination.
     Scenario:
     1) A termination added in a Context.
     2) MG operator puts the termination out of service
     3) MG sends Service change Forced to the MGC.
     4) Before MGC receives a ServiceChange, it has sent an ADD
request(without a Topolgy descriptor) to MG to add the termination in the
          above context.
Though it can be argued that MGC will always send substract request whenever
it receives ServiceChange Forced but does it worth exchanging substract
messages when ADD failure could have solved the problem. However there can
be exception to this scenario where multiple terminations are in context and
only one termination is made OOS. Then if MGC properly specifies the
topology descriptor then ADD command should work.

Regards
venkat



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr  4 08:59:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22035
	for <megaco-archive@odin.ietf.org>; Fri, 4 Apr 2003 08:59:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h34E1pG17346
	for megaco-archive@odin.ietf.org; Fri, 4 Apr 2003 09:01:51 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34E1pK17343
	for <megaco-web-archive@optimus.ietf.org>; Fri, 4 Apr 2003 09:01:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22029
	for <megaco-web-archive@ietf.org>; Fri, 4 Apr 2003 08:58:34 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DuYK17034;
	Fri, 4 Apr 2003 08:56:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DqFK16906
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 08:52:15 -0500
Received: from zrtps06s.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21781
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:48:58 -0500 (EST)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DpQU24940
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:51:26 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GD8QL72S>; Fri, 4 Apr 2003 08:51:26 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C088D9020@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: bvswamy@hss.hns.com, megaco@ietf.org
Subject: RE: [Megaco] ADD handling for Out-of-service termination
Date: Fri, 4 Apr 2003 08:51:24 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Having an OOS term in a context does NOT preclude addition of another term.

It is clearly stated in the spec that the MGC will subtract the OOS term.
However, if another term is added in the meantime, the MG should do as it is
told, and add the new term into the context.

Also, what does TP have to do with adding a term if one is OOS?  The term
will be subtracted imminently -- I do not see the problem here.

Kevin

-----Original Message-----
From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] 
Sent: Thursday, April 03, 2003 7:45 AM
To: megaco@ietf.org
Subject: [Megaco] ADD handling for Out-of-service termination




Hi

I have a query  related to ADD command processing for terminations involving
out-of-service terminations:
      An ADD request is received by an MG to add a termination in a context
which already has a OOS termination.
     Scenario:
     1) A termination added in a Context.
     2) MG operator puts the termination out of service
     3) MG sends Service change Forced to the MGC.
     4) Before MGC receives a ServiceChange, it has sent an ADD
request(without a Topolgy descriptor) to MG to add the termination in the
          above context.
Though it can be argued that MGC will always send substract request whenever
it receives ServiceChange Forced but does it worth exchanging substract
messages when ADD failure could have solved the problem. However there can
be exception to this scenario where multiple terminations are in context and
only one termination is made OOS. Then if MGC properly specifies the
topology descriptor then ADD command should work.

Regards
venkat



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr  4 09:00:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22127
	for <megaco-archive@lists.ietf.org>; Fri, 4 Apr 2003 09:00:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DwtK17120;
	Fri, 4 Apr 2003 08:58:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DqFK16910
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 08:52:15 -0500
Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21779
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:48:58 -0500 (EST)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DpQ222909
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:51:26 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GD8QL72T>; Fri, 4 Apr 2003 08:51:26 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C088D901F@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: NuritS@audiocodes.com, ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
	 on Properties
Date: Fri, 4 Apr 2003 08:51:23 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

If one of the terms is illegal in terms of the context in question, the MG
should return an error.

Kevin

-----Original Message-----
From: Nurit Shenhar [mailto:NuritS@audiocodes.com] 
Sent: Thursday, April 03, 2003 6:47 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties


Kevin

In this case, what should the MG do if one of the terminations defined in
the topology is illegal? (i.e belongs to another context). Should there be
some session of legality check for the topology?

Nurit

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, March 27, 2003 9:54 PM
To: ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties


Clearly you cannot add the new term before modifying T2.  So the steps are
thus:

1. Process the TP descriptor, noting that there is a term that will be added
later in the action which will be isolated from all the other existing terms
in the context. 2. Process the Modify T2 command. 3. Process the Add
command, and add the new term.  Note that because the TP descriptor has
ALREADY been processed, the term is added isolated from all other terms in
the context.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] 
Sent: Thursday, March 27, 2003 1:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi Kevin/List,
Taking the discussion a bit further, please clarify if the following
sequence for implementing Topology Descriptor is correct. Transaction
receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}}

Processing steps:
1. Resolve the termination name i.e. select one termination conforming to
the name specified in the Add command. 2. Add this termination to the
Context. This step may involve using some information given in the Add
command. 3. If the addition of the termination is successful proceed
further. If the addition of termination to Context is not successful give a
Context Level Error in the response. 4. Apply Topology for the newly added
termination. 5. Process the Modify command. 6. Process the Add command. Some
information present in this command will be used while adding the
termination to the Context. Rest of the information is processed here.

Please correct me if I am wrong.

Regards,
Chintan...
www.hssworld.com





"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/20/2003 12:14:08 PM

To:   Chintan Kaushik/HSS@HSS, David Kao <david.kao@verizon.net>
cc:   megaco@ietf.org

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



This is not correct.  As has been repeatedly covered, the Topology
descriptor is executed before any commands, regardless of the information
available.  The difference between this statement, and what you have
expressed is this:

C=1{TP{$,*,IS},A=${...}

Topology first:
The new term is added already isolated from all other terms in the context.

Topology once "enough information" is present:
The new term is added bothway to all terms, and then topology is altered to
isolate the term from all other terms in the context.

As you can see there is a significant difference between these two
scenarios.  If the command fails, then it is up to the MGC to clean up any
potential mess that results from having executed the TP descriptor.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
Sent: Wednesday, March 19, 2003 11:27 PM
To: David Kao
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi,
A small addition to what Kevin has already mentioned: -
Attempt is made to apply the Topology descriptor before any commands for
that action. However, if due to some reason this is not possible then the
Topology Descriptor is applied as soon as all the information to apply it is
known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
{... In this case Topology will be applied once the "Add=$" command has been
executed successfully.

Regards,
Chintan...




"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/19/2003 12:30:27 AM

To:   David Kao <david.kao@verizon.net>, megaco@ietf.org
cc:    (bcc: Chintan Kaushik/HSS)

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



Comments inline. [KJBII]

Kevin

-----Original Message-----
From: David Kao [mailto:david.kao@verizon.net]
Sent: Monday, March 17, 2003 10:22 PM
To: megaco@ietf.org
Subject: [Megaco] Processing Order of Context Properties and Termination
Properties



Please accept my apology if the same questions were asked and discussed
before.



The spec says, "Transactions guarantee ordered Command processing. That is,
Commands within a Transaction are executed sequentially." I have two
relevant questions based on this statement.



1. How about the processing order of context properties? Are they supposed
to be processed in the same same sequential order like the commands?



For instance, based on previously posted emails from Christian Grove,
topology descriptor should be processed before commands in an action, since
"The Topology descriptor occurs before the commands in an action." In fact,
all contextRequests come before the commands. If this is the case, is the
following generalization correct?



"In a transaction, actions are executed sequentially. In an action, context
requests (including context property modifications and context property
audits) and commands are executed sequentially."
[KJBII] Yes.  H.248 is, essentially, a left to right protocol.



2. How about the processing order of termination properties? Without a
well-defined order, different MG implementations can respond differently to
the same command. For instance, if Signals descriptor is processed before
Events descriptor can produce different results than the case when Events
descriptor is processed first. [KJBII] See above comment.



Regards,



David Kao



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr  4 09:02:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22229
	for <megaco-archive@odin.ietf.org>; Fri, 4 Apr 2003 09:02:45 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h34E5VO17623
	for megaco-archive@odin.ietf.org; Fri, 4 Apr 2003 09:05:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34E5VK17620
	for <megaco-web-archive@optimus.ietf.org>; Fri, 4 Apr 2003 09:05:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22185
	for <megaco-web-archive@ietf.org>; Fri, 4 Apr 2003 09:02:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DwtK17120;
	Fri, 4 Apr 2003 08:58:55 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DqFK16910
	for <megaco@optimus.ietf.org>; Fri, 4 Apr 2003 08:52:15 -0500
Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21779
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:48:58 -0500 (EST)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DpQ222909
	for <megaco@ietf.org>; Fri, 4 Apr 2003 08:51:26 -0500 (EST)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <GD8QL72T>; Fri, 4 Apr 2003 08:51:26 -0500
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C088D901F@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: NuritS@audiocodes.com, ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
	 on Properties
Date: Fri, 4 Apr 2003 08:51:23 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

If one of the terms is illegal in terms of the context in question, the MG
should return an error.

Kevin

-----Original Message-----
From: Nurit Shenhar [mailto:NuritS@audiocodes.com] 
Sent: Thursday, April 03, 2003 6:47 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties


Kevin

In this case, what should the MG do if one of the terminations defined in
the topology is illegal? (i.e belongs to another context). Should there be
some session of legality check for the topology?

Nurit

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Thursday, March 27, 2003 9:54 PM
To: ckaushik@hss.hns.com
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties


Clearly you cannot add the new term before modifying T2.  So the steps are
thus:

1. Process the TP descriptor, noting that there is a term that will be added
later in the action which will be isolated from all the other existing terms
in the context. 2. Process the Modify T2 command. 3. Process the Add
command, and add the new term.  Note that because the TP descriptor has
ALREADY been processed, the term is added isolated from all other terms in
the context.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com] 
Sent: Thursday, March 27, 2003 1:48 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi Kevin/List,
Taking the discussion a bit further, please clarify if the following
sequence for implementing Topology Descriptor is correct. Transaction
receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...}, Add=${...}}

Processing steps:
1. Resolve the termination name i.e. select one termination conforming to
the name specified in the Add command. 2. Add this termination to the
Context. This step may involve using some information given in the Add
command. 3. If the addition of the termination is successful proceed
further. If the addition of termination to Context is not successful give a
Context Level Error in the response. 4. Apply Topology for the newly added
termination. 5. Process the Modify command. 6. Process the Add command. Some
information present in this command will be used while adding the
termination to the Context. Rest of the information is processed here.

Please correct me if I am wrong.

Regards,
Chintan...
www.hssworld.com





"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/20/2003 12:14:08 PM

To:   Chintan Kaushik/HSS@HSS, David Kao <david.kao@verizon.net>
cc:   megaco@ietf.org

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



This is not correct.  As has been repeatedly covered, the Topology
descriptor is executed before any commands, regardless of the information
available.  The difference between this statement, and what you have
expressed is this:

C=1{TP{$,*,IS},A=${...}

Topology first:
The new term is added already isolated from all other terms in the context.

Topology once "enough information" is present:
The new term is added bothway to all terms, and then topology is altered to
isolate the term from all other terms in the context.

As you can see there is a significant difference between these two
scenarios.  If the command fails, then it is up to the MGC to clean up any
potential mess that results from having executed the TP descriptor.

Kevin

-----Original Message-----
From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
Sent: Wednesday, March 19, 2003 11:27 PM
To: David Kao
Cc: megaco@ietf.org
Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
on Properties





Hi,
A small addition to what Kevin has already mentioned: -
Attempt is made to apply the Topology descriptor before any commands for
that action. However, if due to some reason this is not possible then the
Topology Descriptor is applied as soon as all the information to apply it is
known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
{... In this case Topology will be applied once the "Add=$" command has been
executed successfully.

Regards,
Chintan...




"Kevin Boyle" <kboyle@nortelnetworks.com> on 03/19/2003 12:30:27 AM

To:   David Kao <david.kao@verizon.net>, megaco@ietf.org
cc:    (bcc: Chintan Kaushik/HSS)

Subject:  RE: [Megaco] Processing Order of Context Properties and Terminati
on
      Properties



Comments inline. [KJBII]

Kevin

-----Original Message-----
From: David Kao [mailto:david.kao@verizon.net]
Sent: Monday, March 17, 2003 10:22 PM
To: megaco@ietf.org
Subject: [Megaco] Processing Order of Context Properties and Termination
Properties



Please accept my apology if the same questions were asked and discussed
before.



The spec says, "Transactions guarantee ordered Command processing. That is,
Commands within a Transaction are executed sequentially." I have two
relevant questions based on this statement.



1. How about the processing order of context properties? Are they supposed
to be processed in the same same sequential order like the commands?



For instance, based on previously posted emails from Christian Grove,
topology descriptor should be processed before commands in an action, since
"The Topology descriptor occurs before the commands in an action." In fact,
all contextRequests come before the commands. If this is the case, is the
following generalization correct?



"In a transaction, actions are executed sequentially. In an action, context
requests (including context property modifications and context property
audits) and commands are executed sequentially."
[KJBII] Yes.  H.248 is, essentially, a left to right protocol.



2. How about the processing order of termination properties? Without a
well-defined order, different MG implementations can respond differently to
the same command. For instance, if Signals descriptor is processed before
Events descriptor can produce different results than the case when Events
descriptor is processed first. [KJBII] See above comment.



Regards,



David Kao



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sun Apr  6 04:45:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24408
	for <megaco-archive@lists.ietf.org>; Sun, 6 Apr 2003 04:45:53 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h368Z5827758;
	Sun, 6 Apr 2003 04:35:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h368Q9827586
	for <megaco@optimus.ietf.org>; Sun, 6 Apr 2003 04:26:09 -0400
Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24170
	for <megaco@ietf.org>; Sun, 6 Apr 2003 04:21:55 -0400 (EDT)
Received: through eSafe SMTP Relay 1049608062; Sun Apr 06 11:21:22 2003
Received: by EXCHANGE with Internet Mail Service (5.5.2653.19)
	id <1SWY92Y0>; Sun, 6 Apr 2003 11:23:40 +0200
Message-ID: <B1584457374ED211B7A90008C7242DEF451577@EXCHANGE>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'petric john'" <petric_john@yahoo.com.au>, megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...
Date: Sun, 6 Apr 2003 11:23:38 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FC1E.34FD0210"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2FC1E.34FD0210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think most of your questions can be answered by recalling the following=
:

   A TransactionRequest has been processed=20
   =20
   =B8    when all actions in that TransactionRequest have been=20
        processed, or=20
   =20
   =B8    when an error is encountered in processing that=20
        TransactionRequest except when the error is in an optional=20
        command.=20

Thus, you will never process a command following the one in which an erro=
r
occurred unless the failed command was optional.  I think that the quote =
you
called S1 in your original posting implies that if the error was in parsi=
ng,
then you send error 422 which terminates both the action and the transact=
ion
processing, even if the erroneous command was optional.  Therefore, the o=
nly
thing you have to worry about is processing the commands before the one i=
n
which you found the error, and everything after it goes in the garbage.

Regarding your questions about sender recovery, I would be surprised to
learn about the existence of implementations that rephrase their requests
when the recipient doesn't like the syntax.  Perhaps the Megaco gurus wou=
ld
like to comment.  I think errors like 422 and 403 are more likely to be
found during interoperability tests, and hopefully not after deployment.

Raphael Tryster




-----Original Message-----
From: petric john [mailto:petric_john@yahoo.com.au]
Sent: Friday, 4 April 2003 13:35
To: megaco@ietf.org; petric john; Raphael Tryster
Cc: taylor@nortelnetworks.com; kboyle@nortelnetworks.com
Subject: RE: [Megaco] Processing of command, action ...


Sorry, forgot to post it to mailing list.
Repeating the same.

-- john

 --- petric john <petric_john@yahoo.com.au> wrote: >
see the comments with [PJJ]
>=20
>  --- Raphael Tryster <raphael@tdsoft.com> wrote: >
> See
> [FSRT] within.
> >=20
> > Raphael Tryster
> >=20
> > -----Original Message-----
> > From: petric john
> [mailto:petric_john@yahoo.com.au]
> > Sent: Thursday, 3 April 2003 16:01
> > To: megaco@ietf.org
> > Subject: [Megaco] Processing of command, action
> ...
> >=20
> >=20
> > Hi,
> >=20
> > This is in context of the text mentioned in 8.2.2
> as
> > below.
> >=20
> > S1: If the end of an action cannot be reliably
> > determined but one or more commands can be parsed,
> > it
> > will process them and then send 422 - Syntax Error
> > in
> > Action as the last action for the transaction.
> >=20
> > S2: If the end of a transaction cannot be reliably
> > determined and one or more Actions can be parsed,
> it
> > will process them and then return 403 - Syntax
> Error
> > in Transaction as the last action reply for the
> > transaction.=20
> >=20
> > In both the above statemets, it is mentioned about
> > the
> > unreliable determination of the action, and
> > transaction respectively.=20
> >=20
> > As mentioned, does processing of the commands (in
> > S1)
> > means the execution of the commands, and does
> > processing of the action (in S2) means the
> execution
> > in the context of the MGC/MG application???=20
> >=20
> > [FSRT] Yes.
> >=20
> [PJJ] I think then there are more issues asociated
> with this. See below.
>=20
> > This apprently shows that even if the parsing
> > (decoding) of the given component of the protocol
> > message is partial, the decoded information is
> still
> > passed on to the MG/MGC application for further
> > processing/execution.
> >=20
> > [FSRT]  Yes.  In practice, it means your parser
> has
> > to be able to generate
> > partial output, as well as an indication that the
> > only processing required
> > for a specific command or action is to return an
> > error.
> >=20
> [PJJ]=20
>=20
> 1. Assume that there are four commands in an action.
> Now the parsing of the command 1 and 2 was
> successful,
> and the third one failed. Then according to the
> above,
> we shall send the command 1 and 2 to the
> application.
> What about the command command number 4 in the
> action
> (which could be syntactically correct)? What we
> should
> do to it??
>=20
> 2. If we have to still parse for the command 4 in
> the
> action, then it is going to be difficult to know the
> exact start of the command 4 in the action.
>=20
> 3. What would be the action on the sender's side in
> this case?? As we shall report the error "422 -
> Syntax
> Error in Action" to the sender, how its going to
> retransmitt the commands 3 and 4??
>=20
> 4. Partial decoding is certainly not applicable in
> case of command, as it does make any sense to do so.
> Also the basic unit of the data that has to go to
> the
> application is Command, and it should be complete at
> any point of time. Thus when sender, after receiving
> the 422, shall send the command 3 and 4 with the
> same
> TransactionId (hopefully), in which case it will be
> the re-transmission of the Transaction (which is
> again
> not correct). The resending of the commands 3 and 4
> has to be a new Transaction. Correct me if wrong.
>=20
> 5. To make above process more complex, assume if the
> command 1 and 3 were parsed successfully. then
> should
> we send command 1 and 3 to the application?? (even
> otherwise parsing of the alternate commands is
> definitely not easy. Same is the case with Action,
> see
> below.
>=20
> 6. I would like to make a point here that as long as
> the parsing of the commands in the action (and so
> actions in the Transaction) is moving successfully,
> the information is useful. But we should stop
> parsing
> as soon as the command decode is failure, and jump
> to
> the next action in the Transaction (if present).
>=20
> 7. The parsing logic is certainly going to be
> complex
> to find out the next Action in the Transaction.=20
>=20
> looking forward for the clarifications. ;-)
>=20
> > So far I am under impression that even a single
> > parse
> > failure (at any level) of the messgge would
> prohibit
> > it from sending it to the application, thus
> > rejecting
> > it compeletely.
> >=20
> > [FSRT]  That was my impression once too, but I
> > couldn't find anything in the
> > standard to support it.
> >=20
> [PJJ] Same here. I guess there is no support in the
> standard too for the some of the doubts raised
> above.
>=20
> > what is the significance of the word "it will
> > process
> > them"???
> >=20
> > [FSRT]  As if there were no subsequent error.
> >=20
> > regards,
> >=20
> >=20
> >=20
> > =3D=3D=3D=3D=3D
> > ~|~=20
> >  o=20
> > John
> >=20
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your
> Telstra
> > or Vodafone mobile.
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > =20
>=20
> =3D=3D=3D=3D=3D
> ~|~=20
>  o=20
> John
>=20
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra
> or Vodafone mobile.
> =20

=3D=3D=3D=3D=3D
~|~=20
 o=20
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.


------_=_NextPart_001_01C2FC1E.34FD0210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>RE: [Megaco] Processing of command, action ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think most of your questions can be answered by recal=
ling the following:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; A TransactionRequest has been processed </=
FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; =B8&nbsp;&nbsp;&nbsp; when all actions in=
 that TransactionRequest have been </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; processed, =
or </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; =B8&nbsp;&nbsp;&nbsp; when an error is en=
countered in processing that </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Transaction=
Request except when the error is in an optional </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command. </=
FONT>
</P>

<P><FONT SIZE=3D2>Thus, you will never process a command following the on=
e in which an error occurred unless the failed command was optional.&nbsp=
; I think that the quote you called S1 in your original posting implies t=
hat if the error was in parsing, then you send error 422 which terminates=
 both the action and the transaction processing, even if the erroneous co=
mmand was optional.&nbsp; Therefore, the only thing you have to worry abo=
ut is processing the commands before the one in which you found the error=
, and everything after it goes in the garbage.</FONT></P>

<P><FONT SIZE=3D2>Regarding your questions about sender recovery, I would=
 be surprised to learn about the existence of implementations that rephra=
se their requests when the recipient doesn't like the syntax.&nbsp; Perha=
ps the Megaco gurus would like to comment.&nbsp; I think errors like 422 =
and 403 are more likely to be found during interoperability tests, and ho=
pefully not after deployment.</FONT></P>

<P><FONT SIZE=3D2>Raphael Tryster</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: petric john [<A HREF=3D"mailto:petric_john@yahoo=
=2Ecom.au">mailto:petric_john@yahoo.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, 4 April 2003 13:35</FONT>
<BR><FONT SIZE=3D2>To: megaco@ietf.org; petric john; Raphael Tryster</FON=
T>
<BR><FONT SIZE=3D2>Cc: taylor@nortelnetworks.com; kboyle@nortelnetworks.c=
om</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Processing of command, action ..=
=2E.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sorry, forgot to post it to mailing list.</FONT>
<BR><FONT SIZE=3D2>Repeating the same.</FONT>
</P>

<P><FONT SIZE=3D2>-- john</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;--- petric john &lt;petric_john@yahoo.com.au&gt; =
wrote: &gt;</FONT>
<BR><FONT SIZE=3D2>see the comments with [PJJ]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; --- Raphael Tryster &lt;raphael@tdsoft.com&=
gt; wrote: &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; See</FONT>
<BR><FONT SIZE=3D2>&gt; [FSRT] within.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Raphael Tryster</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: petric john</FONT>
<BR><FONT SIZE=3D2>&gt; [<A HREF=3D"mailto:petric_john@yahoo.com.au">mail=
to:petric_john@yahoo.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, 3 April 2003 16:01</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [Megaco] Processing of command, act=
ion</FONT>
<BR><FONT SIZE=3D2>&gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is in context of the text mentioned in =
8.2.2</FONT>
<BR><FONT SIZE=3D2>&gt; as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; below.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; S1: If the end of an action cannot be reliab=
ly</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; determined but one or more commands can be p=
arsed,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will process them and then send 422 - Syntax=
 Error</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Action as the last action for the transactio=
n.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; S2: If the end of a transaction cannot be re=
liably</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; determined and one or more Actions can be pa=
rsed,</FONT>
<BR><FONT SIZE=3D2>&gt; it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will process them and then return 403 - Synt=
ax</FONT>
<BR><FONT SIZE=3D2>&gt; Error</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in Transaction as the last action reply for =
the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transaction. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In both the above statemets, it is mentioned=
 about</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; unreliable determination of the action, and<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transaction respectively. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As mentioned, does processing of the command=
s (in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; S1)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; means the execution of the commands, and doe=
s</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; processing of the action (in S2) means the</=
FONT>
<BR><FONT SIZE=3D2>&gt; execution</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the context of the MGC/MG application??? =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT] Yes.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [PJJ] I think then there are more issues asociate=
d</FONT>
<BR><FONT SIZE=3D2>&gt; with this. See below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This apprently shows that even if the parsin=
g</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (decoding) of the given component of the pro=
tocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message is partial, the decoded information =
is</FONT>
<BR><FONT SIZE=3D2>&gt; still</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; passed on to the MG/MGC application for furt=
her</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; processing/execution.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT]&nbsp; Yes.&nbsp; In practice, it mean=
s your parser</FONT>
<BR><FONT SIZE=3D2>&gt; has</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to be able to generate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; partial output, as well as an indication tha=
t the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; only processing required</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for a specific command or action is to retur=
n an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; error.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [PJJ] </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. Assume that there are four commands in an acti=
on.</FONT>
<BR><FONT SIZE=3D2>&gt; Now the parsing of the command 1 and 2 was</FONT>
<BR><FONT SIZE=3D2>&gt; successful,</FONT>
<BR><FONT SIZE=3D2>&gt; and the third one failed. Then according to the</=
FONT>
<BR><FONT SIZE=3D2>&gt; above,</FONT>
<BR><FONT SIZE=3D2>&gt; we shall send the command 1 and 2 to the</FONT>
<BR><FONT SIZE=3D2>&gt; application.</FONT>
<BR><FONT SIZE=3D2>&gt; What about the command command number 4 in the</F=
ONT>
<BR><FONT SIZE=3D2>&gt; action</FONT>
<BR><FONT SIZE=3D2>&gt; (which could be syntactically correct)? What we</=
FONT>
<BR><FONT SIZE=3D2>&gt; should</FONT>
<BR><FONT SIZE=3D2>&gt; do to it??</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. If we have to still parse for the command 4 in=
</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; action, then it is going to be difficult to know =
the</FONT>
<BR><FONT SIZE=3D2>&gt; exact start of the command 4 in the action.</FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3. What would be the action on the sender's side =
in</FONT>
<BR><FONT SIZE=3D2>&gt; this case?? As we shall report the error &quot;42=
2 -</FONT>
<BR><FONT SIZE=3D2>&gt; Syntax</FONT>
<BR><FONT SIZE=3D2>&gt; Error in Action&quot; to the sender, how its goin=
g to</FONT>
<BR><FONT SIZE=3D2>&gt; retransmitt the commands 3 and 4??</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4. Partial decoding is certainly not applicable i=
n</FONT>
<BR><FONT SIZE=3D2>&gt; case of command, as it does make any sense to do =
so.</FONT>
<BR><FONT SIZE=3D2>&gt; Also the basic unit of the data that has to go to=
</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; application is Command, and it should be complete=
 at</FONT>
<BR><FONT SIZE=3D2>&gt; any point of time. Thus when sender, after receiv=
ing</FONT>
<BR><FONT SIZE=3D2>&gt; the 422, shall send the command 3 and 4 with the<=
/FONT>
<BR><FONT SIZE=3D2>&gt; same</FONT>
<BR><FONT SIZE=3D2>&gt; TransactionId (hopefully), in which case it will =
be</FONT>
<BR><FONT SIZE=3D2>&gt; the re-transmission of the Transaction (which is<=
/FONT>
<BR><FONT SIZE=3D2>&gt; again</FONT>
<BR><FONT SIZE=3D2>&gt; not correct). The resending of the commands 3 and=
 4</FONT>
<BR><FONT SIZE=3D2>&gt; has to be a new Transaction. Correct me if wrong.=
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 5. To make above process more complex, assume if =
the</FONT>
<BR><FONT SIZE=3D2>&gt; command 1 and 3 were parsed successfully. then</F=
ONT>
<BR><FONT SIZE=3D2>&gt; should</FONT>
<BR><FONT SIZE=3D2>&gt; we send command 1 and 3 to the application?? (eve=
n</FONT>
<BR><FONT SIZE=3D2>&gt; otherwise parsing of the alternate commands is</F=
ONT>
<BR><FONT SIZE=3D2>&gt; definitely not easy. Same is the case with Action=
,</FONT>
<BR><FONT SIZE=3D2>&gt; see</FONT>
<BR><FONT SIZE=3D2>&gt; below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 6. I would like to make a point here that as long=
 as</FONT>
<BR><FONT SIZE=3D2>&gt; the parsing of the commands in the action (and so=
</FONT>
<BR><FONT SIZE=3D2>&gt; actions in the Transaction) is moving successfull=
y,</FONT>
<BR><FONT SIZE=3D2>&gt; the information is useful. But we should stop</FO=
NT>
<BR><FONT SIZE=3D2>&gt; parsing</FONT>
<BR><FONT SIZE=3D2>&gt; as soon as the command decode is failure, and jum=
p</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; the next action in the Transaction (if present).<=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 7. The parsing logic is certainly going to be</FO=
NT>
<BR><FONT SIZE=3D2>&gt; complex</FONT>
<BR><FONT SIZE=3D2>&gt; to find out the next Action in the Transaction. <=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; looking forward for the clarifications. ;-)</FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So far I am under impression that even a sin=
gle</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; parse</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; failure (at any level) of the messgge would<=
/FONT>
<BR><FONT SIZE=3D2>&gt; prohibit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it from sending it to the application, thus<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; rejecting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it compeletely.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT]&nbsp; That was my impression once too=
, but I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; couldn't find anything in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; standard to support it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [PJJ] Same here. I guess there is no support in t=
he</FONT>
<BR><FONT SIZE=3D2>&gt; standard too for the some of the doubts raised</F=
ONT>
<BR><FONT SIZE=3D2>&gt; above.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; what is the significance of the word &quot;i=
t will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; process</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; them&quot;???</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT]&nbsp; As if there were no subsequent =
error.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ~|~ </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; o </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://mobile.yahoo.com.au" TARGE=
T=3D"_blank">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; - Check &amp; compose your email via SMS on =
your</FONT>
<BR><FONT SIZE=3D2>&gt; Telstra</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or Vodafone mobile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ____________________________________________=
___</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"https://www1.ietf.org/mailman/lis=
tinfo/megaco" TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/me=
gaco</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; ~|~ </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; o </FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://mobile.yahoo.com.au" TARGET=3D"=
_blank">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>&gt; - Check &amp; compose your email via SMS on your =
Telstra</FONT>
<BR><FONT SIZE=3D2>&gt; or Vodafone mobile.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>~|~ </FONT>
<BR><FONT SIZE=3D2>&nbsp;o </FONT>
<BR><FONT SIZE=3D2>John</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://mobile.yahoo.com.au" TARGET=3D"_blank=
">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>- Check &amp; compose your email via SMS on your Telst=
ra or Vodafone mobile.</FONT>
</P>

</BODY>
</HTML>

------_=_NextPart_001_01C2FC1E.34FD0210--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Sun Apr  6 04:48:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24439
	for <megaco-archive@odin.ietf.org>; Sun, 6 Apr 2003 04:48:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h368pmk28940
	for megaco-archive@odin.ietf.org; Sun, 6 Apr 2003 04:51:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h368pm828937
	for <megaco-web-archive@optimus.ietf.org>; Sun, 6 Apr 2003 04:51:48 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24436
	for <megaco-web-archive@ietf.org>; Sun, 6 Apr 2003 04:47:37 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h368Z5827758;
	Sun, 6 Apr 2003 04:35:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h368Q9827586
	for <megaco@optimus.ietf.org>; Sun, 6 Apr 2003 04:26:09 -0400
Received: from exchange.td-soft.co.il (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24170
	for <megaco@ietf.org>; Sun, 6 Apr 2003 04:21:55 -0400 (EDT)
Received: through eSafe SMTP Relay 1049608062; Sun Apr 06 11:21:22 2003
Received: by EXCHANGE with Internet Mail Service (5.5.2653.19)
	id <1SWY92Y0>; Sun, 6 Apr 2003 11:23:40 +0200
Message-ID: <B1584457374ED211B7A90008C7242DEF451577@EXCHANGE>
From: Raphael Tryster <raphael@tdsoft.com>
To: "'petric john'" <petric_john@yahoo.com.au>, megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...
Date: Sun, 6 Apr 2003 11:23:38 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2FC1E.34FD0210"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2FC1E.34FD0210
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think most of your questions can be answered by recalling the following=
:

   A TransactionRequest has been processed=20
   =20
   =B8    when all actions in that TransactionRequest have been=20
        processed, or=20
   =20
   =B8    when an error is encountered in processing that=20
        TransactionRequest except when the error is in an optional=20
        command.=20

Thus, you will never process a command following the one in which an erro=
r
occurred unless the failed command was optional.  I think that the quote =
you
called S1 in your original posting implies that if the error was in parsi=
ng,
then you send error 422 which terminates both the action and the transact=
ion
processing, even if the erroneous command was optional.  Therefore, the o=
nly
thing you have to worry about is processing the commands before the one i=
n
which you found the error, and everything after it goes in the garbage.

Regarding your questions about sender recovery, I would be surprised to
learn about the existence of implementations that rephrase their requests
when the recipient doesn't like the syntax.  Perhaps the Megaco gurus wou=
ld
like to comment.  I think errors like 422 and 403 are more likely to be
found during interoperability tests, and hopefully not after deployment.

Raphael Tryster




-----Original Message-----
From: petric john [mailto:petric_john@yahoo.com.au]
Sent: Friday, 4 April 2003 13:35
To: megaco@ietf.org; petric john; Raphael Tryster
Cc: taylor@nortelnetworks.com; kboyle@nortelnetworks.com
Subject: RE: [Megaco] Processing of command, action ...


Sorry, forgot to post it to mailing list.
Repeating the same.

-- john

 --- petric john <petric_john@yahoo.com.au> wrote: >
see the comments with [PJJ]
>=20
>  --- Raphael Tryster <raphael@tdsoft.com> wrote: >
> See
> [FSRT] within.
> >=20
> > Raphael Tryster
> >=20
> > -----Original Message-----
> > From: petric john
> [mailto:petric_john@yahoo.com.au]
> > Sent: Thursday, 3 April 2003 16:01
> > To: megaco@ietf.org
> > Subject: [Megaco] Processing of command, action
> ...
> >=20
> >=20
> > Hi,
> >=20
> > This is in context of the text mentioned in 8.2.2
> as
> > below.
> >=20
> > S1: If the end of an action cannot be reliably
> > determined but one or more commands can be parsed,
> > it
> > will process them and then send 422 - Syntax Error
> > in
> > Action as the last action for the transaction.
> >=20
> > S2: If the end of a transaction cannot be reliably
> > determined and one or more Actions can be parsed,
> it
> > will process them and then return 403 - Syntax
> Error
> > in Transaction as the last action reply for the
> > transaction.=20
> >=20
> > In both the above statemets, it is mentioned about
> > the
> > unreliable determination of the action, and
> > transaction respectively.=20
> >=20
> > As mentioned, does processing of the commands (in
> > S1)
> > means the execution of the commands, and does
> > processing of the action (in S2) means the
> execution
> > in the context of the MGC/MG application???=20
> >=20
> > [FSRT] Yes.
> >=20
> [PJJ] I think then there are more issues asociated
> with this. See below.
>=20
> > This apprently shows that even if the parsing
> > (decoding) of the given component of the protocol
> > message is partial, the decoded information is
> still
> > passed on to the MG/MGC application for further
> > processing/execution.
> >=20
> > [FSRT]  Yes.  In practice, it means your parser
> has
> > to be able to generate
> > partial output, as well as an indication that the
> > only processing required
> > for a specific command or action is to return an
> > error.
> >=20
> [PJJ]=20
>=20
> 1. Assume that there are four commands in an action.
> Now the parsing of the command 1 and 2 was
> successful,
> and the third one failed. Then according to the
> above,
> we shall send the command 1 and 2 to the
> application.
> What about the command command number 4 in the
> action
> (which could be syntactically correct)? What we
> should
> do to it??
>=20
> 2. If we have to still parse for the command 4 in
> the
> action, then it is going to be difficult to know the
> exact start of the command 4 in the action.
>=20
> 3. What would be the action on the sender's side in
> this case?? As we shall report the error "422 -
> Syntax
> Error in Action" to the sender, how its going to
> retransmitt the commands 3 and 4??
>=20
> 4. Partial decoding is certainly not applicable in
> case of command, as it does make any sense to do so.
> Also the basic unit of the data that has to go to
> the
> application is Command, and it should be complete at
> any point of time. Thus when sender, after receiving
> the 422, shall send the command 3 and 4 with the
> same
> TransactionId (hopefully), in which case it will be
> the re-transmission of the Transaction (which is
> again
> not correct). The resending of the commands 3 and 4
> has to be a new Transaction. Correct me if wrong.
>=20
> 5. To make above process more complex, assume if the
> command 1 and 3 were parsed successfully. then
> should
> we send command 1 and 3 to the application?? (even
> otherwise parsing of the alternate commands is
> definitely not easy. Same is the case with Action,
> see
> below.
>=20
> 6. I would like to make a point here that as long as
> the parsing of the commands in the action (and so
> actions in the Transaction) is moving successfully,
> the information is useful. But we should stop
> parsing
> as soon as the command decode is failure, and jump
> to
> the next action in the Transaction (if present).
>=20
> 7. The parsing logic is certainly going to be
> complex
> to find out the next Action in the Transaction.=20
>=20
> looking forward for the clarifications. ;-)
>=20
> > So far I am under impression that even a single
> > parse
> > failure (at any level) of the messgge would
> prohibit
> > it from sending it to the application, thus
> > rejecting
> > it compeletely.
> >=20
> > [FSRT]  That was my impression once too, but I
> > couldn't find anything in the
> > standard to support it.
> >=20
> [PJJ] Same here. I guess there is no support in the
> standard too for the some of the doubts raised
> above.
>=20
> > what is the significance of the word "it will
> > process
> > them"???
> >=20
> > [FSRT]  As if there were no subsequent error.
> >=20
> > regards,
> >=20
> >=20
> >=20
> > =3D=3D=3D=3D=3D
> > ~|~=20
> >  o=20
> > John
> >=20
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your
> Telstra
> > or Vodafone mobile.
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> > =20
>=20
> =3D=3D=3D=3D=3D
> ~|~=20
>  o=20
> John
>=20
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra
> or Vodafone mobile.
> =20

=3D=3D=3D=3D=3D
~|~=20
 o=20
John

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.


------_=_NextPart_001_01C2FC1E.34FD0210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-885=
9-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.1=
2">
<TITLE>RE: [Megaco] Processing of command, action ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think most of your questions can be answered by recal=
ling the following:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; A TransactionRequest has been processed </=
FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; =B8&nbsp;&nbsp;&nbsp; when all actions in=
 that TransactionRequest have been </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; processed, =
or </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; =B8&nbsp;&nbsp;&nbsp; when an error is en=
countered in processing that </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Transaction=
Request except when the error is in an optional </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command. </=
FONT>
</P>

<P><FONT SIZE=3D2>Thus, you will never process a command following the on=
e in which an error occurred unless the failed command was optional.&nbsp=
; I think that the quote you called S1 in your original posting implies t=
hat if the error was in parsing, then you send error 422 which terminates=
 both the action and the transaction processing, even if the erroneous co=
mmand was optional.&nbsp; Therefore, the only thing you have to worry abo=
ut is processing the commands before the one in which you found the error=
, and everything after it goes in the garbage.</FONT></P>

<P><FONT SIZE=3D2>Regarding your questions about sender recovery, I would=
 be surprised to learn about the existence of implementations that rephra=
se their requests when the recipient doesn't like the syntax.&nbsp; Perha=
ps the Megaco gurus would like to comment.&nbsp; I think errors like 422 =
and 403 are more likely to be found during interoperability tests, and ho=
pefully not after deployment.</FONT></P>

<P><FONT SIZE=3D2>Raphael Tryster</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: petric john [<A HREF=3D"mailto:petric_john@yahoo=
=2Ecom.au">mailto:petric_john@yahoo.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, 4 April 2003 13:35</FONT>
<BR><FONT SIZE=3D2>To: megaco@ietf.org; petric john; Raphael Tryster</FON=
T>
<BR><FONT SIZE=3D2>Cc: taylor@nortelnetworks.com; kboyle@nortelnetworks.c=
om</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Megaco] Processing of command, action ..=
=2E.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Sorry, forgot to post it to mailing list.</FONT>
<BR><FONT SIZE=3D2>Repeating the same.</FONT>
</P>

<P><FONT SIZE=3D2>-- john</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;--- petric john &lt;petric_john@yahoo.com.au&gt; =
wrote: &gt;</FONT>
<BR><FONT SIZE=3D2>see the comments with [PJJ]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; --- Raphael Tryster &lt;raphael@tdsoft.com&=
gt; wrote: &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; See</FONT>
<BR><FONT SIZE=3D2>&gt; [FSRT] within.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Raphael Tryster</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: petric john</FONT>
<BR><FONT SIZE=3D2>&gt; [<A HREF=3D"mailto:petric_john@yahoo.com.au">mail=
to:petric_john@yahoo.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, 3 April 2003 16:01</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [Megaco] Processing of command, act=
ion</FONT>
<BR><FONT SIZE=3D2>&gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is in context of the text mentioned in =
8.2.2</FONT>
<BR><FONT SIZE=3D2>&gt; as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; below.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; S1: If the end of an action cannot be reliab=
ly</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; determined but one or more commands can be p=
arsed,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will process them and then send 422 - Syntax=
 Error</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Action as the last action for the transactio=
n.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; S2: If the end of a transaction cannot be re=
liably</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; determined and one or more Actions can be pa=
rsed,</FONT>
<BR><FONT SIZE=3D2>&gt; it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will process them and then return 403 - Synt=
ax</FONT>
<BR><FONT SIZE=3D2>&gt; Error</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in Transaction as the last action reply for =
the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transaction. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In both the above statemets, it is mentioned=
 about</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; unreliable determination of the action, and<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transaction respectively. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As mentioned, does processing of the command=
s (in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; S1)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; means the execution of the commands, and doe=
s</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; processing of the action (in S2) means the</=
FONT>
<BR><FONT SIZE=3D2>&gt; execution</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the context of the MGC/MG application??? =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT] Yes.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [PJJ] I think then there are more issues asociate=
d</FONT>
<BR><FONT SIZE=3D2>&gt; with this. See below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This apprently shows that even if the parsin=
g</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (decoding) of the given component of the pro=
tocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; message is partial, the decoded information =
is</FONT>
<BR><FONT SIZE=3D2>&gt; still</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; passed on to the MG/MGC application for furt=
her</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; processing/execution.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT]&nbsp; Yes.&nbsp; In practice, it mean=
s your parser</FONT>
<BR><FONT SIZE=3D2>&gt; has</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to be able to generate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; partial output, as well as an indication tha=
t the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; only processing required</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for a specific command or action is to retur=
n an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; error.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [PJJ] </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. Assume that there are four commands in an acti=
on.</FONT>
<BR><FONT SIZE=3D2>&gt; Now the parsing of the command 1 and 2 was</FONT>
<BR><FONT SIZE=3D2>&gt; successful,</FONT>
<BR><FONT SIZE=3D2>&gt; and the third one failed. Then according to the</=
FONT>
<BR><FONT SIZE=3D2>&gt; above,</FONT>
<BR><FONT SIZE=3D2>&gt; we shall send the command 1 and 2 to the</FONT>
<BR><FONT SIZE=3D2>&gt; application.</FONT>
<BR><FONT SIZE=3D2>&gt; What about the command command number 4 in the</F=
ONT>
<BR><FONT SIZE=3D2>&gt; action</FONT>
<BR><FONT SIZE=3D2>&gt; (which could be syntactically correct)? What we</=
FONT>
<BR><FONT SIZE=3D2>&gt; should</FONT>
<BR><FONT SIZE=3D2>&gt; do to it??</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. If we have to still parse for the command 4 in=
</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; action, then it is going to be difficult to know =
the</FONT>
<BR><FONT SIZE=3D2>&gt; exact start of the command 4 in the action.</FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 3. What would be the action on the sender's side =
in</FONT>
<BR><FONT SIZE=3D2>&gt; this case?? As we shall report the error &quot;42=
2 -</FONT>
<BR><FONT SIZE=3D2>&gt; Syntax</FONT>
<BR><FONT SIZE=3D2>&gt; Error in Action&quot; to the sender, how its goin=
g to</FONT>
<BR><FONT SIZE=3D2>&gt; retransmitt the commands 3 and 4??</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 4. Partial decoding is certainly not applicable i=
n</FONT>
<BR><FONT SIZE=3D2>&gt; case of command, as it does make any sense to do =
so.</FONT>
<BR><FONT SIZE=3D2>&gt; Also the basic unit of the data that has to go to=
</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; application is Command, and it should be complete=
 at</FONT>
<BR><FONT SIZE=3D2>&gt; any point of time. Thus when sender, after receiv=
ing</FONT>
<BR><FONT SIZE=3D2>&gt; the 422, shall send the command 3 and 4 with the<=
/FONT>
<BR><FONT SIZE=3D2>&gt; same</FONT>
<BR><FONT SIZE=3D2>&gt; TransactionId (hopefully), in which case it will =
be</FONT>
<BR><FONT SIZE=3D2>&gt; the re-transmission of the Transaction (which is<=
/FONT>
<BR><FONT SIZE=3D2>&gt; again</FONT>
<BR><FONT SIZE=3D2>&gt; not correct). The resending of the commands 3 and=
 4</FONT>
<BR><FONT SIZE=3D2>&gt; has to be a new Transaction. Correct me if wrong.=
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 5. To make above process more complex, assume if =
the</FONT>
<BR><FONT SIZE=3D2>&gt; command 1 and 3 were parsed successfully. then</F=
ONT>
<BR><FONT SIZE=3D2>&gt; should</FONT>
<BR><FONT SIZE=3D2>&gt; we send command 1 and 3 to the application?? (eve=
n</FONT>
<BR><FONT SIZE=3D2>&gt; otherwise parsing of the alternate commands is</F=
ONT>
<BR><FONT SIZE=3D2>&gt; definitely not easy. Same is the case with Action=
,</FONT>
<BR><FONT SIZE=3D2>&gt; see</FONT>
<BR><FONT SIZE=3D2>&gt; below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 6. I would like to make a point here that as long=
 as</FONT>
<BR><FONT SIZE=3D2>&gt; the parsing of the commands in the action (and so=
</FONT>
<BR><FONT SIZE=3D2>&gt; actions in the Transaction) is moving successfull=
y,</FONT>
<BR><FONT SIZE=3D2>&gt; the information is useful. But we should stop</FO=
NT>
<BR><FONT SIZE=3D2>&gt; parsing</FONT>
<BR><FONT SIZE=3D2>&gt; as soon as the command decode is failure, and jum=
p</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; the next action in the Transaction (if present).<=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 7. The parsing logic is certainly going to be</FO=
NT>
<BR><FONT SIZE=3D2>&gt; complex</FONT>
<BR><FONT SIZE=3D2>&gt; to find out the next Action in the Transaction. <=
/FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; looking forward for the clarifications. ;-)</FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So far I am under impression that even a sin=
gle</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; parse</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; failure (at any level) of the messgge would<=
/FONT>
<BR><FONT SIZE=3D2>&gt; prohibit</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it from sending it to the application, thus<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; rejecting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it compeletely.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT]&nbsp; That was my impression once too=
, but I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; couldn't find anything in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; standard to support it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [PJJ] Same here. I guess there is no support in t=
he</FONT>
<BR><FONT SIZE=3D2>&gt; standard too for the some of the doubts raised</F=
ONT>
<BR><FONT SIZE=3D2>&gt; above.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; what is the significance of the word &quot;i=
t will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; process</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; them&quot;???</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [FSRT]&nbsp; As if there were no subsequent =
error.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ~|~ </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; o </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://mobile.yahoo.com.au" TARGE=
T=3D"_blank">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; - Check &amp; compose your email via SMS on =
your</FONT>
<BR><FONT SIZE=3D2>&gt; Telstra</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or Vodafone mobile.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ____________________________________________=
___</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"https://www1.ietf.org/mailman/lis=
tinfo/megaco" TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/me=
gaco</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; ~|~ </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; o </FONT>
<BR><FONT SIZE=3D2>&gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://mobile.yahoo.com.au" TARGET=3D"=
_blank">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>&gt; - Check &amp; compose your email via SMS on your =
Telstra</FONT>
<BR><FONT SIZE=3D2>&gt; or Vodafone mobile.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>~|~ </FONT>
<BR><FONT SIZE=3D2>&nbsp;o </FONT>
<BR><FONT SIZE=3D2>John</FONT>
</P>

<P><FONT SIZE=3D2><A HREF=3D"http://mobile.yahoo.com.au" TARGET=3D"_blank=
">http://mobile.yahoo.com.au</A> - Yahoo! Mobile</FONT>
<BR><FONT SIZE=3D2>- Check &amp; compose your email via SMS on your Telst=
ra or Vodafone mobile.</FONT>
</P>

</BODY>
</HTML>

------_=_NextPart_001_01C2FC1E.34FD0210--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr  7 07:16:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15384
	for <megaco-archive@lists.ietf.org>; Mon, 7 Apr 2003 07:16:51 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BAj801054;
	Mon, 7 Apr 2003 07:10:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37B5b832545
	for <megaco@optimus.ietf.org>; Mon, 7 Apr 2003 07:05:37 -0400
Received: from qmail-b.directi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14645
	for <megaco@ietf.org>; Mon, 7 Apr 2003 07:00:46 -0400 (EDT)
Received: (qmail 18084 invoked by uid 0); 7 Apr 2003 11:03:07 -0000
Received: from unknown (HELO omair) (203.129.216.107)
  by 203.199.107.94 with SMTP; 7 Apr 2003 11:03:07 -0000
Message-ID: <003701c2fcf5$4a41ab80$6bd881cb@ilocus.com>
From: "Omair Nissar" <omair@ilocus.com>
To: <megaco@ietf.org>
References: <20030404170002.30794.45254.Mailman@www1.ietf.org>
Date: Mon, 7 Apr 2003 16:32:48 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Megaco Marketplace
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Dear....,

            i am having some queries related to Megaco :-

what is the market share from Megaco in terms of revenue.

what is the future prospect of Megaco

percentage of companies who deploy Megaco.

please do send me the details and the possible sources of information
regarding these queries.



----- Original Message -----
From: <megaco-request@ietf.org>
To: <megaco@ietf.org>
Sent: Friday, April 04, 2003 10:30 PM
Subject: Megaco digest, Vol 1 #855 - 7 msgs


> Send Megaco mailing list submissions to
> megaco@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> megaco-request@ietf.org
>
> You can reach the person managing the list at
> megaco-admin@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
>
>
> Today's Topics:
>
>    1. Re: ADD handling for Out-of-service termination (Selvam.V)
>    2. MEGACO Marketplace (Omair Nissar)
>    3. RE: Processing of command, action ...
(=?iso-8859-1?q?petric=20john?=)
>    4. I-D ACTION:draft-ietf-megaco-h248v2-04.txt
(Internet-Drafts@ietf.org)
>    5. RE: ADD handling for Out-of-service termination (Kevin Boyle)
>    6. RE: Processing Order of Context Properties and Terminati
>        on Properties (Kevin Boyle)
>
> --__--__--
>
> Message: 1
> From: "Selvam.V" <sveeragh@ssd.usa.alcatel.com>
> To: <bvswamy@hss.hns.com>, <megaco@ietf.org>
> Subject: Re: [Megaco] ADD handling for Out-of-service termination
> Date: Fri, 4 Apr 2003 11:31:31 +0530
>
> Hi,
>         Is there is a need to send a subtract command.
>         what will be the contextID in the subtract command.
>         when the Termination is OOS, it will be returning an error for the
> ADD
>         request.
>
>         Best Regards,
>         selva
>
> ----- Original Message -----
> From: <bvswamy@hss.hns.com>
> To: <megaco@ietf.org>
> Sent: Thursday, April 03, 2003 6:15 PM
> Subject: [Megaco] ADD handling for Out-of-service termination
>
>
> >
> >
> > Hi
> >
> > I have a query  related to ADD command processing for terminations
> involving
> > out-of-service terminations:
> >       An ADD request is received by an MG to add a termination in a
> context
> > which already has a OOS termination.
> >      Scenario:
> >      1) A termination added in a Context.
> >      2) MG operator puts the termination out of service
> >      3) MG sends Service change Forced to the MGC.
> >      4) Before MGC receives a ServiceChange, it has sent an ADD
> request(without
> > a Topolgy descriptor) to MG to add the termination in the
> >           above context.
> > Though it can be argued that MGC will always send substract request
> whenever it
> > receives ServiceChange Forced but
> > does it worth exchanging substract messages when ADD failure could have
> solved
> > the problem.
> > However there can be exception to this scenario where multiple
> terminations are
> > in context and only one termination is made OOS. Then
> > if MGC properly specifies the topology descriptor then ADD command
should
> work.
> >
> > Regards
> > venkat
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>
>
> --__--__--
>
> Message: 2
> From: "Omair Nissar" <omair@ilocus.com>
> To: <megaco@ietf.org>
> Date: Fri, 4 Apr 2003 14:52:24 +0530
> Subject: [Megaco] MEGACO Marketplace
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Dear...,
>
>              i am doing research on Megaco Marketplace and i am supposed =
> to prepare a report on Megaco and its Marketplace .i have recently =
> subscribed for Megaco mailing list.i would like to have some information =
> regarding Megaco.Below are some queries
>
> 1. Deployment of Megaco
> 2.Revenue generated from this stack
> 3.Market share from Megaco
> 4.Estimate and forecast
>
>
>
> Regards
>
> omair
>
> Business Dev.Associate
>
> iLocus
>
> 15-sidco Electronics Complex
> Rangreth,Budgam-7,J&K, India
> Tel :- 0194 2300594
> E-Mail :- omair@ilocus.com
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>Dear...,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;=20
> i am doing research on Megaco Marketplace and i am supposed to prepare a =
> report=20
> on Megaco and its Marketplace .i have recently subscribed for Megaco =
> mailing=20
> list.i would like to have some information regarding Megaco.Below are =
> some=20
> queries</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>1. Deployment of Megaco</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>2.Revenue generated from this =
> stack</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>3.Market share from Megaco</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>4.Estimate and forecast</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Regards</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>omair</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Business =
> Dev.Associate</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>iLocus</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff>15-sidco =
> Electronics=20
> Complex<BR>Rangreth,Budgam-7,J&amp;K, India<BR>Tel :- 0194 =
> 2300594<BR>E-Mail :-=20
> </FONT><A=20
> href=3D"mailto:omair@ilocus.com">omair@ilocus.com</A><BR></FONT></DIV></B=
> ODY></HTML>
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80--
>
>
> --__--__--
>
> Message: 3
> Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)
> From: =?iso-8859-1?q?petric=20john?= <petric_john@yahoo.com.au>
> Subject: RE: [Megaco] Processing of command, action ...
> To: megaco@ietf.org, petric john <petric_john@yahoo.com.au>,
>    Raphael Tryster <raphael@tdsoft.com>
> Cc: taylor@nortelnetworks.com, kboyle@nortelnetworks.com
>
> Sorry, forgot to post it to mailing list.
> Repeating the same.
>
> -- john
>
>  --- petric john <petric_john@yahoo.com.au> wrote: >
> see the comments with [PJJ]
> >
> >  --- Raphael Tryster <raphael@tdsoft.com> wrote: >
> > See
> > [FSRT] within.
> > >
> > > Raphael Tryster
> > >
> > > -----Original Message-----
> > > From: petric john
> > [mailto:petric_john@yahoo.com.au]
> > > Sent: Thursday, 3 April 2003 16:01
> > > To: megaco@ietf.org
> > > Subject: [Megaco] Processing of command, action
> > ...
> > >
> > >
> > > Hi,
> > >
> > > This is in context of the text mentioned in 8.2.2
> > as
> > > below.
> > >
> > > S1: If the end of an action cannot be reliably
> > > determined but one or more commands can be parsed,
> > > it
> > > will process them and then send 422 - Syntax Error
> > > in
> > > Action as the last action for the transaction.
> > >
> > > S2: If the end of a transaction cannot be reliably
> > > determined and one or more Actions can be parsed,
> > it
> > > will process them and then return 403 - Syntax
> > Error
> > > in Transaction as the last action reply for the
> > > transaction.
> > >
> > > In both the above statemets, it is mentioned about
> > > the
> > > unreliable determination of the action, and
> > > transaction respectively.
> > >
> > > As mentioned, does processing of the commands (in
> > > S1)
> > > means the execution of the commands, and does
> > > processing of the action (in S2) means the
> > execution
> > > in the context of the MGC/MG application???
> > >
> > > [FSRT] Yes.
> > >
> > [PJJ] I think then there are more issues asociated
> > with this. See below.
> >
> > > This apprently shows that even if the parsing
> > > (decoding) of the given component of the protocol
> > > message is partial, the decoded information is
> > still
> > > passed on to the MG/MGC application for further
> > > processing/execution.
> > >
> > > [FSRT]  Yes.  In practice, it means your parser
> > has
> > > to be able to generate
> > > partial output, as well as an indication that the
> > > only processing required
> > > for a specific command or action is to return an
> > > error.
> > >
> > [PJJ]
> >
> > 1. Assume that there are four commands in an action.
> > Now the parsing of the command 1 and 2 was
> > successful,
> > and the third one failed. Then according to the
> > above,
> > we shall send the command 1 and 2 to the
> > application.
> > What about the command command number 4 in the
> > action
> > (which could be syntactically correct)? What we
> > should
> > do to it??
> >
> > 2. If we have to still parse for the command 4 in
> > the
> > action, then it is going to be difficult to know the
> > exact start of the command 4 in the action.
> >
> > 3. What would be the action on the sender's side in
> > this case?? As we shall report the error "422 -
> > Syntax
> > Error in Action" to the sender, how its going to
> > retransmitt the commands 3 and 4??
> >
> > 4. Partial decoding is certainly not applicable in
> > case of command, as it does make any sense to do so.
> > Also the basic unit of the data that has to go to
> > the
> > application is Command, and it should be complete at
> > any point of time. Thus when sender, after receiving
> > the 422, shall send the command 3 and 4 with the
> > same
> > TransactionId (hopefully), in which case it will be
> > the re-transmission of the Transaction (which is
> > again
> > not correct). The resending of the commands 3 and 4
> > has to be a new Transaction. Correct me if wrong.
> >
> > 5. To make above process more complex, assume if the
> > command 1 and 3 were parsed successfully. then
> > should
> > we send command 1 and 3 to the application?? (even
> > otherwise parsing of the alternate commands is
> > definitely not easy. Same is the case with Action,
> > see
> > below.
> >
> > 6. I would like to make a point here that as long as
> > the parsing of the commands in the action (and so
> > actions in the Transaction) is moving successfully,
> > the information is useful. But we should stop
> > parsing
> > as soon as the command decode is failure, and jump
> > to
> > the next action in the Transaction (if present).
> >
> > 7. The parsing logic is certainly going to be
> > complex
> > to find out the next Action in the Transaction.
> >
> > looking forward for the clarifications. ;-)
> >
> > > So far I am under impression that even a single
> > > parse
> > > failure (at any level) of the messgge would
> > prohibit
> > > it from sending it to the application, thus
> > > rejecting
> > > it compeletely.
> > >
> > > [FSRT]  That was my impression once too, but I
> > > couldn't find anything in the
> > > standard to support it.
> > >
> > [PJJ] Same here. I guess there is no support in the
> > standard too for the some of the doubts raised
> > above.
> >
> > > what is the significance of the word "it will
> > > process
> > > them"???
> > >
> > > [FSRT]  As if there were no subsequent error.
> > >
> > > regards,
> > >
> > >
> > >
> > > =====
> > > ~|~
> > >  o
> > > John
> > >
> > > http://mobile.yahoo.com.au - Yahoo! Mobile
> > > - Check & compose your email via SMS on your
> > Telstra
> > > or Vodafone mobile.
> > > _______________________________________________
> > > Megaco mailing list
> > > Megaco@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> >
> > =====
> > ~|~
> >  o
> > John
> >
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your Telstra
> > or Vodafone mobile.
> >
>
> =====
> ~|~
>  o
> John
>
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra or Vodafone mobile.
>
> --__--__--
>
> Message: 4
> To: IETF-Announce: ;
> Cc: megaco@ietf.org
> From: Internet-Drafts@ietf.org
> Reply-to: Internet-Drafts@ietf.org
> Date: Fri, 04 Apr 2003 06:44:15 -0500
> Subject: [Megaco] I-D ACTION:draft-ietf-megaco-h248v2-04.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Media Gateway Control Working Group of
the IETF.
>
> Title : The Megaco/H.248v2 Gateway Control Protocol, version 2
> Author(s) : C. Groves, M. Pantaleo et al.
> Filename : draft-ietf-megaco-h248v2-04.txt
> Pages : 219
> Date : 2003-4-3
>
> This document describes the second version of the general-purpose
> gateway control protocol standardized as Megaco in the IETF and as
> Recommendation H.248 (now H.248.1) in the ITU-T.  It is common text
> with Recommendation H.248.1 (05/02), published by the ITU-T.  Megaco
> v2 includes the corrections to RFC 3015 which resulted in RFC xxxx
> [draft-ietf-megaco-3015corr-02.txt], plus the following new
> capabilities:
> - ability to audit specific properties, events, signals and
> statistics
> - use of serviceChange to indicate that capabilities have changed in
> the Media Gateway
> - playing a signal on the Root Termination
> - limiting the number of repetitions of transaction pending
> - allowing topology to be set per stream
> - ability to audit context properties
> - new Nx64K multiplex type
> - provision for digit buffering when a digit map completes.
> In addition, the use of the Modem Descriptor was deprecated.
> A detailed list of changes from draft-ietf-megaco-3015corr-
> 02.txt/H.248.1 (03/02) to this document is given in Appendix II at
> the end of this document.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-megaco-h248v2-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="mailserv@ietf.org"
>
> Content-Type: text/plain
> Content-ID: <2003-4-4065214.I-D@ietf.org>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-ietf-megaco-h248v2-04.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <2003-4-4065214.I-D@ietf.org>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 5
> From: "Kevin Boyle" <kboyle@nortelnetworks.com>
> To: bvswamy@hss.hns.com, megaco@ietf.org
> Subject: RE: [Megaco] ADD handling for Out-of-service termination
> Date: Fri, 4 Apr 2003 08:51:24 -0500
>
> Having an OOS term in a context does NOT preclude addition of another
term.
>
> It is clearly stated in the spec that the MGC will subtract the OOS term.
> However, if another term is added in the meantime, the MG should do as it
is
> told, and add the new term into the context.
>
> Also, what does TP have to do with adding a term if one is OOS?  The term
> will be subtracted imminently -- I do not see the problem here.
>
> Kevin
>
> -----Original Message-----
> From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
> Sent: Thursday, April 03, 2003 7:45 AM
> To: megaco@ietf.org
> Subject: [Megaco] ADD handling for Out-of-service termination
>
>
>
>
> Hi
>
> I have a query  related to ADD command processing for terminations
involving
> out-of-service terminations:
>       An ADD request is received by an MG to add a termination in a
context
> which already has a OOS termination.
>      Scenario:
>      1) A termination added in a Context.
>      2) MG operator puts the termination out of service
>      3) MG sends Service change Forced to the MGC.
>      4) Before MGC receives a ServiceChange, it has sent an ADD
> request(without a Topolgy descriptor) to MG to add the termination in the
>           above context.
> Though it can be argued that MGC will always send substract request
whenever
> it receives ServiceChange Forced but does it worth exchanging substract
> messages when ADD failure could have solved the problem. However there can
> be exception to this scenario where multiple terminations are in context
and
> only one termination is made OOS. Then if MGC properly specifies the
> topology descriptor then ADD command should work.
>
> Regards
> venkat
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
> --__--__--
>
> Message: 6
> From: "Kevin Boyle" <kboyle@nortelnetworks.com>
> To: NuritS@audiocodes.com, ckaushik@hss.hns.com
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
> Date: Fri, 4 Apr 2003 08:51:23 -0500
>
> If one of the terms is illegal in terms of the context in question, the MG
> should return an error.
>
> Kevin
>
> -----Original Message-----
> From: Nurit Shenhar [mailto:NuritS@audiocodes.com]
> Sent: Thursday, April 03, 2003 6:47 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; ckaushik@hss.hns.com
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
> Kevin
>
> In this case, what should the MG do if one of the terminations defined in
> the topology is illegal? (i.e belongs to another context). Should there be
> some session of legality check for the topology?
>
> Nurit
>
> -----Original Message-----
> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> Sent: Thursday, March 27, 2003 9:54 PM
> To: ckaushik@hss.hns.com
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
> Clearly you cannot add the new term before modifying T2.  So the steps are
> thus:
>
> 1. Process the TP descriptor, noting that there is a term that will be
added
> later in the action which will be isolated from all the other existing
terms
> in the context. 2. Process the Modify T2 command. 3. Process the Add
> command, and add the new term.  Note that because the TP descriptor has
> ALREADY been processed, the term is added isolated from all other terms in
> the context.
>
> Kevin
>
> -----Original Message-----
> From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
> Sent: Thursday, March 27, 2003 1:48 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
>
>
>
> Hi Kevin/List,
> Taking the discussion a bit further, please clarify if the following
> sequence for implementing Topology Descriptor is correct. Transaction
> receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...},
Add=${...}}
>
> Processing steps:
> 1. Resolve the termination name i.e. select one termination conforming to
> the name specified in the Add command. 2. Add this termination to the
> Context. This step may involve using some information given in the Add
> command. 3. If the addition of the termination is successful proceed
> further. If the addition of termination to Context is not successful give
a
> Context Level Error in the response. 4. Apply Topology for the newly added
> termination. 5. Process the Modify command. 6. Process the Add command.
Some
> information present in this command will be used while adding the
> termination to the Context. Rest of the information is processed here.
>
> Please correct me if I am wrong.
>
> Regards,
> Chintan...
> www.hssworld.com
>
>
>
>
>
> "Kevin Boyle" <kboyle@nortelnetworks.com> on 03/20/2003 12:14:08 PM
>
> To:   Chintan Kaushik/HSS@HSS, David Kao <david.kao@verizon.net>
> cc:   megaco@ietf.org
>
> Subject:  RE: [Megaco] Processing Order of Context Properties and
Terminati
> on
>       Properties
>
>
>
> This is not correct.  As has been repeatedly covered, the Topology
> descriptor is executed before any commands, regardless of the information
> available.  The difference between this statement, and what you have
> expressed is this:
>
> C=1{TP{$,*,IS},A=${...}
>
> Topology first:
> The new term is added already isolated from all other terms in the
context.
>
> Topology once "enough information" is present:
> The new term is added bothway to all terms, and then topology is altered
to
> isolate the term from all other terms in the context.
>
> As you can see there is a significant difference between these two
> scenarios.  If the command fails, then it is up to the MGC to clean up any
> potential mess that results from having executed the TP descriptor.
>
> Kevin
>
> -----Original Message-----
> From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
> Sent: Wednesday, March 19, 2003 11:27 PM
> To: David Kao
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
>
>
>
> Hi,
> A small addition to what Kevin has already mentioned: -
> Attempt is made to apply the Topology descriptor before any commands for
> that action. However, if due to some reason this is not possible then the
> Topology Descriptor is applied as soon as all the information to apply it
is
> known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
> {... In this case Topology will be applied once the "Add=$" command has
been
> executed successfully.
>
> Regards,
> Chintan...
>
>
>
>
> "Kevin Boyle" <kboyle@nortelnetworks.com> on 03/19/2003 12:30:27 AM
>
> To:   David Kao <david.kao@verizon.net>, megaco@ietf.org
> cc:    (bcc: Chintan Kaushik/HSS)
>
> Subject:  RE: [Megaco] Processing Order of Context Properties and
Terminati
> on
>       Properties
>
>
>
> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: David Kao [mailto:david.kao@verizon.net]
> Sent: Monday, March 17, 2003 10:22 PM
> To: megaco@ietf.org
> Subject: [Megaco] Processing Order of Context Properties and Termination
> Properties
>
>
>
> Please accept my apology if the same questions were asked and discussed
> before.
>
>
>
> The spec says, "Transactions guarantee ordered Command processing. That
is,
> Commands within a Transaction are executed sequentially." I have two
> relevant questions based on this statement.
>
>
>
> 1. How about the processing order of context properties? Are they supposed
> to be processed in the same same sequential order like the commands?
>
>
>
> For instance, based on previously posted emails from Christian Grove,
> topology descriptor should be processed before commands in an action,
since
> "The Topology descriptor occurs before the commands in an action." In
fact,
> all contextRequests come before the commands. If this is the case, is the
> following generalization correct?
>
>
>
> "In a transaction, actions are executed sequentially. In an action,
context
> requests (including context property modifications and context property
> audits) and commands are executed sequentially."
> [KJBII] Yes.  H.248 is, essentially, a left to right protocol.
>
>
>
> 2. How about the processing order of termination properties? Without a
> well-defined order, different MG implementations can respond differently
to
> the same command. For instance, if Signals descriptor is processed before
> Events descriptor can produce different results than the case when Events
> descriptor is processed first. [KJBII] See above comment.
>
>
>
> Regards,
>
>
>
> David Kao
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> --__--__--
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> End of Megaco Digest
>
>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr  7 07:19:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15466
	for <megaco-archive@odin.ietf.org>; Mon, 7 Apr 2003 07:19:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h37BNNQ01673
	for megaco-archive@odin.ietf.org; Mon, 7 Apr 2003 07:23:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BNN801670
	for <megaco-web-archive@optimus.ietf.org>; Mon, 7 Apr 2003 07:23:23 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15447
	for <megaco-web-archive@ietf.org>; Mon, 7 Apr 2003 07:18:38 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37BAj801054;
	Mon, 7 Apr 2003 07:10:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37B5b832545
	for <megaco@optimus.ietf.org>; Mon, 7 Apr 2003 07:05:37 -0400
Received: from qmail-b.directi.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14645
	for <megaco@ietf.org>; Mon, 7 Apr 2003 07:00:46 -0400 (EDT)
Received: (qmail 18084 invoked by uid 0); 7 Apr 2003 11:03:07 -0000
Received: from unknown (HELO omair) (203.129.216.107)
  by 203.199.107.94 with SMTP; 7 Apr 2003 11:03:07 -0000
Message-ID: <003701c2fcf5$4a41ab80$6bd881cb@ilocus.com>
From: "Omair Nissar" <omair@ilocus.com>
To: <megaco@ietf.org>
References: <20030404170002.30794.45254.Mailman@www1.ietf.org>
Date: Mon, 7 Apr 2003 16:32:48 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Megaco Marketplace
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Dear....,

            i am having some queries related to Megaco :-

what is the market share from Megaco in terms of revenue.

what is the future prospect of Megaco

percentage of companies who deploy Megaco.

please do send me the details and the possible sources of information
regarding these queries.



----- Original Message -----
From: <megaco-request@ietf.org>
To: <megaco@ietf.org>
Sent: Friday, April 04, 2003 10:30 PM
Subject: Megaco digest, Vol 1 #855 - 7 msgs


> Send Megaco mailing list submissions to
> megaco@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> megaco-request@ietf.org
>
> You can reach the person managing the list at
> megaco-admin@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
>
>
> Today's Topics:
>
>    1. Re: ADD handling for Out-of-service termination (Selvam.V)
>    2. MEGACO Marketplace (Omair Nissar)
>    3. RE: Processing of command, action ...
(=?iso-8859-1?q?petric=20john?=)
>    4. I-D ACTION:draft-ietf-megaco-h248v2-04.txt
(Internet-Drafts@ietf.org)
>    5. RE: ADD handling for Out-of-service termination (Kevin Boyle)
>    6. RE: Processing Order of Context Properties and Terminati
>        on Properties (Kevin Boyle)
>
> --__--__--
>
> Message: 1
> From: "Selvam.V" <sveeragh@ssd.usa.alcatel.com>
> To: <bvswamy@hss.hns.com>, <megaco@ietf.org>
> Subject: Re: [Megaco] ADD handling for Out-of-service termination
> Date: Fri, 4 Apr 2003 11:31:31 +0530
>
> Hi,
>         Is there is a need to send a subtract command.
>         what will be the contextID in the subtract command.
>         when the Termination is OOS, it will be returning an error for the
> ADD
>         request.
>
>         Best Regards,
>         selva
>
> ----- Original Message -----
> From: <bvswamy@hss.hns.com>
> To: <megaco@ietf.org>
> Sent: Thursday, April 03, 2003 6:15 PM
> Subject: [Megaco] ADD handling for Out-of-service termination
>
>
> >
> >
> > Hi
> >
> > I have a query  related to ADD command processing for terminations
> involving
> > out-of-service terminations:
> >       An ADD request is received by an MG to add a termination in a
> context
> > which already has a OOS termination.
> >      Scenario:
> >      1) A termination added in a Context.
> >      2) MG operator puts the termination out of service
> >      3) MG sends Service change Forced to the MGC.
> >      4) Before MGC receives a ServiceChange, it has sent an ADD
> request(without
> > a Topolgy descriptor) to MG to add the termination in the
> >           above context.
> > Though it can be argued that MGC will always send substract request
> whenever it
> > receives ServiceChange Forced but
> > does it worth exchanging substract messages when ADD failure could have
> solved
> > the problem.
> > However there can be exception to this scenario where multiple
> terminations are
> > in context and only one termination is made OOS. Then
> > if MGC properly specifies the topology descriptor then ADD command
should
> work.
> >
> > Regards
> > venkat
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>
>
> --__--__--
>
> Message: 2
> From: "Omair Nissar" <omair@ilocus.com>
> To: <megaco@ietf.org>
> Date: Fri, 4 Apr 2003 14:52:24 +0530
> Subject: [Megaco] MEGACO Marketplace
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Dear...,
>
>              i am doing research on Megaco Marketplace and i am supposed =
> to prepare a report on Megaco and its Marketplace .i have recently =
> subscribed for Megaco mailing list.i would like to have some information =
> regarding Megaco.Below are some queries
>
> 1. Deployment of Megaco
> 2.Revenue generated from this stack
> 3.Market share from Megaco
> 4.Estimate and forecast
>
>
>
> Regards
>
> omair
>
> Business Dev.Associate
>
> iLocus
>
> 15-sidco Electronics Complex
> Rangreth,Budgam-7,J&K, India
> Tel :- 0194 2300594
> E-Mail :- omair@ilocus.com
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#ffffff>
> <DIV><FONT face=3DArial size=3D2>Dear...,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;=20
> i am doing research on Megaco Marketplace and i am supposed to prepare a =
> report=20
> on Megaco and its Marketplace .i have recently subscribed for Megaco =
> mailing=20
> list.i would like to have some information regarding Megaco.Below are =
> some=20
> queries</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>1. Deployment of Megaco</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>2.Revenue generated from this =
> stack</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>3.Market share from Megaco</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>4.Estimate and forecast</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Regards</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>omair</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>Business =
> Dev.Associate</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>iLocus</FONT></DIV>
> <DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2><FONT color=3D#0000ff>15-sidco =
> Electronics=20
> Complex<BR>Rangreth,Budgam-7,J&amp;K, India<BR>Tel :- 0194 =
> 2300594<BR>E-Mail :-=20
> </FONT><A=20
> href=3D"mailto:omair@ilocus.com">omair@ilocus.com</A><BR></FONT></DIV></B=
> ODY></HTML>
>
> ------=_NextPart_000_003D_01C2FAB9.CD7B9F80--
>
>
> --__--__--
>
> Message: 3
> Date: Fri, 4 Apr 2003 21:34:40 +1000 (EST)
> From: =?iso-8859-1?q?petric=20john?= <petric_john@yahoo.com.au>
> Subject: RE: [Megaco] Processing of command, action ...
> To: megaco@ietf.org, petric john <petric_john@yahoo.com.au>,
>    Raphael Tryster <raphael@tdsoft.com>
> Cc: taylor@nortelnetworks.com, kboyle@nortelnetworks.com
>
> Sorry, forgot to post it to mailing list.
> Repeating the same.
>
> -- john
>
>  --- petric john <petric_john@yahoo.com.au> wrote: >
> see the comments with [PJJ]
> >
> >  --- Raphael Tryster <raphael@tdsoft.com> wrote: >
> > See
> > [FSRT] within.
> > >
> > > Raphael Tryster
> > >
> > > -----Original Message-----
> > > From: petric john
> > [mailto:petric_john@yahoo.com.au]
> > > Sent: Thursday, 3 April 2003 16:01
> > > To: megaco@ietf.org
> > > Subject: [Megaco] Processing of command, action
> > ...
> > >
> > >
> > > Hi,
> > >
> > > This is in context of the text mentioned in 8.2.2
> > as
> > > below.
> > >
> > > S1: If the end of an action cannot be reliably
> > > determined but one or more commands can be parsed,
> > > it
> > > will process them and then send 422 - Syntax Error
> > > in
> > > Action as the last action for the transaction.
> > >
> > > S2: If the end of a transaction cannot be reliably
> > > determined and one or more Actions can be parsed,
> > it
> > > will process them and then return 403 - Syntax
> > Error
> > > in Transaction as the last action reply for the
> > > transaction.
> > >
> > > In both the above statemets, it is mentioned about
> > > the
> > > unreliable determination of the action, and
> > > transaction respectively.
> > >
> > > As mentioned, does processing of the commands (in
> > > S1)
> > > means the execution of the commands, and does
> > > processing of the action (in S2) means the
> > execution
> > > in the context of the MGC/MG application???
> > >
> > > [FSRT] Yes.
> > >
> > [PJJ] I think then there are more issues asociated
> > with this. See below.
> >
> > > This apprently shows that even if the parsing
> > > (decoding) of the given component of the protocol
> > > message is partial, the decoded information is
> > still
> > > passed on to the MG/MGC application for further
> > > processing/execution.
> > >
> > > [FSRT]  Yes.  In practice, it means your parser
> > has
> > > to be able to generate
> > > partial output, as well as an indication that the
> > > only processing required
> > > for a specific command or action is to return an
> > > error.
> > >
> > [PJJ]
> >
> > 1. Assume that there are four commands in an action.
> > Now the parsing of the command 1 and 2 was
> > successful,
> > and the third one failed. Then according to the
> > above,
> > we shall send the command 1 and 2 to the
> > application.
> > What about the command command number 4 in the
> > action
> > (which could be syntactically correct)? What we
> > should
> > do to it??
> >
> > 2. If we have to still parse for the command 4 in
> > the
> > action, then it is going to be difficult to know the
> > exact start of the command 4 in the action.
> >
> > 3. What would be the action on the sender's side in
> > this case?? As we shall report the error "422 -
> > Syntax
> > Error in Action" to the sender, how its going to
> > retransmitt the commands 3 and 4??
> >
> > 4. Partial decoding is certainly not applicable in
> > case of command, as it does make any sense to do so.
> > Also the basic unit of the data that has to go to
> > the
> > application is Command, and it should be complete at
> > any point of time. Thus when sender, after receiving
> > the 422, shall send the command 3 and 4 with the
> > same
> > TransactionId (hopefully), in which case it will be
> > the re-transmission of the Transaction (which is
> > again
> > not correct). The resending of the commands 3 and 4
> > has to be a new Transaction. Correct me if wrong.
> >
> > 5. To make above process more complex, assume if the
> > command 1 and 3 were parsed successfully. then
> > should
> > we send command 1 and 3 to the application?? (even
> > otherwise parsing of the alternate commands is
> > definitely not easy. Same is the case with Action,
> > see
> > below.
> >
> > 6. I would like to make a point here that as long as
> > the parsing of the commands in the action (and so
> > actions in the Transaction) is moving successfully,
> > the information is useful. But we should stop
> > parsing
> > as soon as the command decode is failure, and jump
> > to
> > the next action in the Transaction (if present).
> >
> > 7. The parsing logic is certainly going to be
> > complex
> > to find out the next Action in the Transaction.
> >
> > looking forward for the clarifications. ;-)
> >
> > > So far I am under impression that even a single
> > > parse
> > > failure (at any level) of the messgge would
> > prohibit
> > > it from sending it to the application, thus
> > > rejecting
> > > it compeletely.
> > >
> > > [FSRT]  That was my impression once too, but I
> > > couldn't find anything in the
> > > standard to support it.
> > >
> > [PJJ] Same here. I guess there is no support in the
> > standard too for the some of the doubts raised
> > above.
> >
> > > what is the significance of the word "it will
> > > process
> > > them"???
> > >
> > > [FSRT]  As if there were no subsequent error.
> > >
> > > regards,
> > >
> > >
> > >
> > > =====
> > > ~|~
> > >  o
> > > John
> > >
> > > http://mobile.yahoo.com.au - Yahoo! Mobile
> > > - Check & compose your email via SMS on your
> > Telstra
> > > or Vodafone mobile.
> > > _______________________________________________
> > > Megaco mailing list
> > > Megaco@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> >
> > =====
> > ~|~
> >  o
> > John
> >
> > http://mobile.yahoo.com.au - Yahoo! Mobile
> > - Check & compose your email via SMS on your Telstra
> > or Vodafone mobile.
> >
>
> =====
> ~|~
>  o
> John
>
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra or Vodafone mobile.
>
> --__--__--
>
> Message: 4
> To: IETF-Announce: ;
> Cc: megaco@ietf.org
> From: Internet-Drafts@ietf.org
> Reply-to: Internet-Drafts@ietf.org
> Date: Fri, 04 Apr 2003 06:44:15 -0500
> Subject: [Megaco] I-D ACTION:draft-ietf-megaco-h248v2-04.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Media Gateway Control Working Group of
the IETF.
>
> Title : The Megaco/H.248v2 Gateway Control Protocol, version 2
> Author(s) : C. Groves, M. Pantaleo et al.
> Filename : draft-ietf-megaco-h248v2-04.txt
> Pages : 219
> Date : 2003-4-3
>
> This document describes the second version of the general-purpose
> gateway control protocol standardized as Megaco in the IETF and as
> Recommendation H.248 (now H.248.1) in the ITU-T.  It is common text
> with Recommendation H.248.1 (05/02), published by the ITU-T.  Megaco
> v2 includes the corrections to RFC 3015 which resulted in RFC xxxx
> [draft-ietf-megaco-3015corr-02.txt], plus the following new
> capabilities:
> - ability to audit specific properties, events, signals and
> statistics
> - use of serviceChange to indicate that capabilities have changed in
> the Media Gateway
> - playing a signal on the Root Termination
> - limiting the number of repetitions of transaction pending
> - allowing topology to be set per stream
> - ability to audit context properties
> - new Nx64K multiplex type
> - provision for digit buffering when a digit map completes.
> In addition, the use of the Modem Descriptor was deprecated.
> A detailed list of changes from draft-ietf-megaco-3015corr-
> 02.txt/H.248.1 (03/02) to this document is given in Appendix II at
> the end of this document.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248v2-04.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-megaco-h248v2-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
> --OtherAccess
> Content-Type: Message/External-body;
> access-type="mail-server";
> server="mailserv@ietf.org"
>
> Content-Type: text/plain
> Content-ID: <2003-4-4065214.I-D@ietf.org>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-megaco-h248v2-04.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-ietf-megaco-h248v2-04.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <2003-4-4065214.I-D@ietf.org>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 5
> From: "Kevin Boyle" <kboyle@nortelnetworks.com>
> To: bvswamy@hss.hns.com, megaco@ietf.org
> Subject: RE: [Megaco] ADD handling for Out-of-service termination
> Date: Fri, 4 Apr 2003 08:51:24 -0500
>
> Having an OOS term in a context does NOT preclude addition of another
term.
>
> It is clearly stated in the spec that the MGC will subtract the OOS term.
> However, if another term is added in the meantime, the MG should do as it
is
> told, and add the new term into the context.
>
> Also, what does TP have to do with adding a term if one is OOS?  The term
> will be subtracted imminently -- I do not see the problem here.
>
> Kevin
>
> -----Original Message-----
> From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com]
> Sent: Thursday, April 03, 2003 7:45 AM
> To: megaco@ietf.org
> Subject: [Megaco] ADD handling for Out-of-service termination
>
>
>
>
> Hi
>
> I have a query  related to ADD command processing for terminations
involving
> out-of-service terminations:
>       An ADD request is received by an MG to add a termination in a
context
> which already has a OOS termination.
>      Scenario:
>      1) A termination added in a Context.
>      2) MG operator puts the termination out of service
>      3) MG sends Service change Forced to the MGC.
>      4) Before MGC receives a ServiceChange, it has sent an ADD
> request(without a Topolgy descriptor) to MG to add the termination in the
>           above context.
> Though it can be argued that MGC will always send substract request
whenever
> it receives ServiceChange Forced but does it worth exchanging substract
> messages when ADD failure could have solved the problem. However there can
> be exception to this scenario where multiple terminations are in context
and
> only one termination is made OOS. Then if MGC properly specifies the
> topology descriptor then ADD command should work.
>
> Regards
> venkat
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
> --__--__--
>
> Message: 6
> From: "Kevin Boyle" <kboyle@nortelnetworks.com>
> To: NuritS@audiocodes.com, ckaushik@hss.hns.com
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
> Date: Fri, 4 Apr 2003 08:51:23 -0500
>
> If one of the terms is illegal in terms of the context in question, the MG
> should return an error.
>
> Kevin
>
> -----Original Message-----
> From: Nurit Shenhar [mailto:NuritS@audiocodes.com]
> Sent: Thursday, April 03, 2003 6:47 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; ckaushik@hss.hns.com
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
> Kevin
>
> In this case, what should the MG do if one of the terminations defined in
> the topology is illegal? (i.e belongs to another context). Should there be
> some session of legality check for the topology?
>
> Nurit
>
> -----Original Message-----
> From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
> Sent: Thursday, March 27, 2003 9:54 PM
> To: ckaushik@hss.hns.com
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
> Clearly you cannot add the new term before modifying T2.  So the steps are
> thus:
>
> 1. Process the TP descriptor, noting that there is a term that will be
added
> later in the action which will be isolated from all the other existing
terms
> in the context. 2. Process the Modify T2 command. 3. Process the Add
> command, and add the new term.  Note that because the TP descriptor has
> ALREADY been processed, the term is added isolated from all other terms in
> the context.
>
> Kevin
>
> -----Original Message-----
> From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
> Sent: Thursday, March 27, 2003 1:48 AM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
>
>
>
> Hi Kevin/List,
> Taking the discussion a bit further, please clarify if the following
> sequence for implementing Topology Descriptor is correct. Transaction
> receieved: ...Context=1{Topology{$, *, isolate}, Modify=T2{...},
Add=${...}}
>
> Processing steps:
> 1. Resolve the termination name i.e. select one termination conforming to
> the name specified in the Add command. 2. Add this termination to the
> Context. This step may involve using some information given in the Add
> command. 3. If the addition of the termination is successful proceed
> further. If the addition of termination to Context is not successful give
a
> Context Level Error in the response. 4. Apply Topology for the newly added
> termination. 5. Process the Modify command. 6. Process the Add command.
Some
> information present in this command will be used while adding the
> termination to the Context. Rest of the information is processed here.
>
> Please correct me if I am wrong.
>
> Regards,
> Chintan...
> www.hssworld.com
>
>
>
>
>
> "Kevin Boyle" <kboyle@nortelnetworks.com> on 03/20/2003 12:14:08 PM
>
> To:   Chintan Kaushik/HSS@HSS, David Kao <david.kao@verizon.net>
> cc:   megaco@ietf.org
>
> Subject:  RE: [Megaco] Processing Order of Context Properties and
Terminati
> on
>       Properties
>
>
>
> This is not correct.  As has been repeatedly covered, the Topology
> descriptor is executed before any commands, regardless of the information
> available.  The difference between this statement, and what you have
> expressed is this:
>
> C=1{TP{$,*,IS},A=${...}
>
> Topology first:
> The new term is added already isolated from all other terms in the
context.
>
> Topology once "enough information" is present:
> The new term is added bothway to all terms, and then topology is altered
to
> isolate the term from all other terms in the context.
>
> As you can see there is a significant difference between these two
> scenarios.  If the command fails, then it is up to the MGC to clean up any
> potential mess that results from having executed the TP descriptor.
>
> Kevin
>
> -----Original Message-----
> From: ckaushik@hss.hns.com [mailto:ckaushik@hss.hns.com]
> Sent: Wednesday, March 19, 2003 11:27 PM
> To: David Kao
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Processing Order of Context Properties and Terminati
> on Properties
>
>
>
>
>
> Hi,
> A small addition to what Kevin has already mentioned: -
> Attempt is made to apply the Topology descriptor before any commands for
> that action. However, if due to some reason this is not possible then the
> Topology Descriptor is applied as soon as all the information to apply it
is
> known to the MG. e.g. ... Context = 1{Topology{idstr1,$,Bothway } ,Add=$
> {... In this case Topology will be applied once the "Add=$" command has
been
> executed successfully.
>
> Regards,
> Chintan...
>
>
>
>
> "Kevin Boyle" <kboyle@nortelnetworks.com> on 03/19/2003 12:30:27 AM
>
> To:   David Kao <david.kao@verizon.net>, megaco@ietf.org
> cc:    (bcc: Chintan Kaushik/HSS)
>
> Subject:  RE: [Megaco] Processing Order of Context Properties and
Terminati
> on
>       Properties
>
>
>
> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: David Kao [mailto:david.kao@verizon.net]
> Sent: Monday, March 17, 2003 10:22 PM
> To: megaco@ietf.org
> Subject: [Megaco] Processing Order of Context Properties and Termination
> Properties
>
>
>
> Please accept my apology if the same questions were asked and discussed
> before.
>
>
>
> The spec says, "Transactions guarantee ordered Command processing. That
is,
> Commands within a Transaction are executed sequentially." I have two
> relevant questions based on this statement.
>
>
>
> 1. How about the processing order of context properties? Are they supposed
> to be processed in the same same sequential order like the commands?
>
>
>
> For instance, based on previously posted emails from Christian Grove,
> topology descriptor should be processed before commands in an action,
since
> "The Topology descriptor occurs before the commands in an action." In
fact,
> all contextRequests come before the commands. If this is the case, is the
> following generalization correct?
>
>
>
> "In a transaction, actions are executed sequentially. In an action,
context
> requests (including context property modifications and context property
> audits) and commands are executed sequentially."
> [KJBII] Yes.  H.248 is, essentially, a left to right protocol.
>
>
>
> 2. How about the processing order of termination properties? Without a
> well-defined order, different MG implementations can respond differently
to
> the same command. For instance, if Signals descriptor is processed before
> Events descriptor can produce different results than the case when Events
> descriptor is processed first. [KJBII] See above comment.
>
>
>
> Regards,
>
>
>
> David Kao
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> --__--__--
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> End of Megaco Digest
>
>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr  7 14:43:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00453
	for <megaco-archive@lists.ietf.org>; Mon, 7 Apr 2003 14:43:58 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Idq802355;
	Mon, 7 Apr 2003 14:39:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IZm801408
	for <megaco@optimus.ietf.org>; Mon, 7 Apr 2003 14:35:48 -0400
Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00059
	for <megaco@ietf.org>; Mon, 7 Apr 2003 14:30:56 -0400 (EDT)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h37IXR404445
	for <megaco@ietf.org>; Mon, 7 Apr 2003 14:33:28 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J9579P4>; Mon, 7 Apr 2003 14:33:29 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0898E7F2@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Raphael Tryster <raphael@tdsoft.com>,
        "'petric john'"
	 <petric_john@yahoo.com.au>, megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...
Date: Mon, 7 Apr 2003 14:33:26 -0400 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Raphael is correct.  As for syntax errors, an MGC could be smart enough to
figure out which command contained the error, and then resend anything after
the error.  However, generally speaking, commands grouped in the same action
or transaction tend to be related, so a failure of one will make the others
difficult/impossible to execute, or they will become irrelevant.
 
I will echo Raphael's sentiment that syntax errors that make it to the field
indicate bigger problems than needing to resend unexecuted commands.
 
Kevin

-----Original Message-----
From: Raphael Tryster [mailto:raphael@tdsoft.com] 
Sent: Sunday, April 06, 2003 5:24 AM
To: 'petric john'; megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...



I think most of your questions can be answered by recalling the following: 

   A TransactionRequest has been processed 
    
   ¸    when all actions in that TransactionRequest have been 
        processed, or 
    
   ¸    when an error is encountered in processing that 
        TransactionRequest except when the error is in an optional 
        command. 

Thus, you will never process a command following the one in which an error
occurred unless the failed command was optional.  I think that the quote you
called S1 in your original posting implies that if the error was in parsing,
then you send error 422 which terminates both the action and the transaction
processing, even if the erroneous command was optional.  Therefore, the only
thing you have to worry about is processing the commands before the one in
which you found the error, and everything after it goes in the garbage.

Regarding your questions about sender recovery, I would be surprised to
learn about the existence of implementations that rephrase their requests
when the recipient doesn't like the syntax.  Perhaps the Megaco gurus would
like to comment.  I think errors like 422 and 403 are more likely to be
found during interoperability tests, and hopefully not after deployment.

Raphael Tryster 




-----Original Message----- 
From: petric john [mailto:petric_john@yahoo.com.au
<mailto:petric_john@yahoo.com.au> ] 
Sent: Friday, 4 April 2003 13:35 
To: megaco@ietf.org; petric john; Raphael Tryster 
Cc: taylor@nortelnetworks.com; kboyle@nortelnetworks.com 
Subject: RE: [Megaco] Processing of command, action .... 


Sorry, forgot to post it to mailing list. 
Repeating the same. 

-- john 

 --- petric john <petric_john@yahoo.com.au> wrote: > 
see the comments with [PJJ] 
> 
>  --- Raphael Tryster <raphael@tdsoft.com> wrote: > 
> See 
> [FSRT] within. 
> > 
> > Raphael Tryster 
> > 
> > -----Original Message----- 
> > From: petric john 
> [mailto:petric_john@yahoo.com.au <mailto:petric_john@yahoo.com.au> ] 
> > Sent: Thursday, 3 April 2003 16:01 
> > To: megaco@ietf.org 
> > Subject: [Megaco] Processing of command, action 
> ... 
> > 
> > 
> > Hi, 
> > 
> > This is in context of the text mentioned in 8.2.2 
> as 
> > below. 
> > 
> > S1: If the end of an action cannot be reliably 
> > determined but one or more commands can be parsed, 
> > it 
> > will process them and then send 422 - Syntax Error 
> > in 
> > Action as the last action for the transaction. 
> > 
> > S2: If the end of a transaction cannot be reliably 
> > determined and one or more Actions can be parsed, 
> it 
> > will process them and then return 403 - Syntax 
> Error 
> > in Transaction as the last action reply for the 
> > transaction. 
> > 
> > In both the above statemets, it is mentioned about 
> > the 
> > unreliable determination of the action, and 
> > transaction respectively. 
> > 
> > As mentioned, does processing of the commands (in 
> > S1) 
> > means the execution of the commands, and does 
> > processing of the action (in S2) means the 
> execution 
> > in the context of the MGC/MG application??? 
> > 
> > [FSRT] Yes. 
> > 
> [PJJ] I think then there are more issues asociated 
> with this. See below. 
> 
> > This apprently shows that even if the parsing 
> > (decoding) of the given component of the protocol 
> > message is partial, the decoded information is 
> still 
> > passed on to the MG/MGC application for further 
> > processing/execution. 
> > 
> > [FSRT]  Yes.  In practice, it means your parser 
> has 
> > to be able to generate 
> > partial output, as well as an indication that the 
> > only processing required 
> > for a specific command or action is to return an 
> > error. 
> > 
> [PJJ] 
> 
> 1. Assume that there are four commands in an action. 
> Now the parsing of the command 1 and 2 was 
> successful, 
> and the third one failed. Then according to the 
> above, 
> we shall send the command 1 and 2 to the 
> application. 
> What about the command command number 4 in the 
> action 
> (which could be syntactically correct)? What we 
> should 
> do to it?? 
> 
> 2. If we have to still parse for the command 4 in 
> the 
> action, then it is going to be difficult to know the 
> exact start of the command 4 in the action. 
> 
> 3. What would be the action on the sender's side in 
> this case?? As we shall report the error "422 - 
> Syntax 
> Error in Action" to the sender, how its going to 
> retransmitt the commands 3 and 4?? 
> 
> 4. Partial decoding is certainly not applicable in 
> case of command, as it does make any sense to do so. 
> Also the basic unit of the data that has to go to 
> the 
> application is Command, and it should be complete at 
> any point of time. Thus when sender, after receiving 
> the 422, shall send the command 3 and 4 with the 
> same 
> TransactionId (hopefully), in which case it will be 
> the re-transmission of the Transaction (which is 
> again 
> not correct). The resending of the commands 3 and 4 
> has to be a new Transaction. Correct me if wrong. 
> 
> 5. To make above process more complex, assume if the 
> command 1 and 3 were parsed successfully. then 
> should 
> we send command 1 and 3 to the application?? (even 
> otherwise parsing of the alternate commands is 
> definitely not easy. Same is the case with Action, 
> see 
> below. 
> 
> 6. I would like to make a point here that as long as 
> the parsing of the commands in the action (and so 
> actions in the Transaction) is moving successfully, 
> the information is useful. But we should stop 
> parsing 
> as soon as the command decode is failure, and jump 
> to 
> the next action in the Transaction (if present). 
> 
> 7. The parsing logic is certainly going to be 
> complex 
> to find out the next Action in the Transaction. 
> 
> looking forward for the clarifications. ;-) 
> 
> > So far I am under impression that even a single 
> > parse 
> > failure (at any level) of the messgge would 
> prohibit 
> > it from sending it to the application, thus 
> > rejecting 
> > it compeletely. 
> > 
> > [FSRT]  That was my impression once too, but I 
> > couldn't find anything in the 
> > standard to support it. 
> > 
> [PJJ] Same here. I guess there is no support in the 
> standard too for the some of the doubts raised 
> above. 
> 
> > what is the significance of the word "it will 
> > process 
> > them"??? 
> > 
> > [FSRT]  As if there were no subsequent error. 
> > 
> > regards, 
> > 
> > 
> > 
> > ===== 
> > ~|~ 
> >  o 
> > John 
> > 
> > http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile

> > - Check & compose your email via SMS on your 
> Telstra 
> > or Vodafone mobile. 
> > _______________________________________________ 
> > Megaco mailing list 
> > Megaco@ietf.org 
> > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
> >  
> 
> ===== 
> ~|~ 
>  o 
> John 
> 
> http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile 
> - Check & compose your email via SMS on your Telstra 
> or Vodafone mobile. 
>  

===== 
~|~ 
 o 
John 

http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile 
- Check & compose your email via SMS on your Telstra or Vodafone mobile. 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr  7 14:45:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00498
	for <megaco-archive@odin.ietf.org>; Mon, 7 Apr 2003 14:45:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h37IntW02770
	for megaco-archive@odin.ietf.org; Mon, 7 Apr 2003 14:49:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Int802767
	for <megaco-web-archive@optimus.ietf.org>; Mon, 7 Apr 2003 14:49:55 -0400
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00483
	for <megaco-web-archive@ietf.org>; Mon, 7 Apr 2003 14:45:03 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Idq802355;
	Mon, 7 Apr 2003 14:39:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37IZm801408
	for <megaco@optimus.ietf.org>; Mon, 7 Apr 2003 14:35:48 -0400
Received: from zrtps0kn.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00059
	for <megaco@ietf.org>; Mon, 7 Apr 2003 14:30:56 -0400 (EDT)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h37IXR404445
	for <megaco@ietf.org>; Mon, 7 Apr 2003 14:33:28 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J9579P4>; Mon, 7 Apr 2003 14:33:29 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C0898E7F2@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Raphael Tryster <raphael@tdsoft.com>,
        "'petric john'"
	 <petric_john@yahoo.com.au>, megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...
Date: Mon, 7 Apr 2003 14:33:26 -0400 
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Raphael is correct.  As for syntax errors, an MGC could be smart enough to
figure out which command contained the error, and then resend anything after
the error.  However, generally speaking, commands grouped in the same action
or transaction tend to be related, so a failure of one will make the others
difficult/impossible to execute, or they will become irrelevant.
 
I will echo Raphael's sentiment that syntax errors that make it to the field
indicate bigger problems than needing to resend unexecuted commands.
 
Kevin

-----Original Message-----
From: Raphael Tryster [mailto:raphael@tdsoft.com] 
Sent: Sunday, April 06, 2003 5:24 AM
To: 'petric john'; megaco@ietf.org
Subject: RE: [Megaco] Processing of command, action ...



I think most of your questions can be answered by recalling the following: 

   A TransactionRequest has been processed 
    
   ¸    when all actions in that TransactionRequest have been 
        processed, or 
    
   ¸    when an error is encountered in processing that 
        TransactionRequest except when the error is in an optional 
        command. 

Thus, you will never process a command following the one in which an error
occurred unless the failed command was optional.  I think that the quote you
called S1 in your original posting implies that if the error was in parsing,
then you send error 422 which terminates both the action and the transaction
processing, even if the erroneous command was optional.  Therefore, the only
thing you have to worry about is processing the commands before the one in
which you found the error, and everything after it goes in the garbage.

Regarding your questions about sender recovery, I would be surprised to
learn about the existence of implementations that rephrase their requests
when the recipient doesn't like the syntax.  Perhaps the Megaco gurus would
like to comment.  I think errors like 422 and 403 are more likely to be
found during interoperability tests, and hopefully not after deployment.

Raphael Tryster 




-----Original Message----- 
From: petric john [mailto:petric_john@yahoo.com.au
<mailto:petric_john@yahoo.com.au> ] 
Sent: Friday, 4 April 2003 13:35 
To: megaco@ietf.org; petric john; Raphael Tryster 
Cc: taylor@nortelnetworks.com; kboyle@nortelnetworks.com 
Subject: RE: [Megaco] Processing of command, action .... 


Sorry, forgot to post it to mailing list. 
Repeating the same. 

-- john 

 --- petric john <petric_john@yahoo.com.au> wrote: > 
see the comments with [PJJ] 
> 
>  --- Raphael Tryster <raphael@tdsoft.com> wrote: > 
> See 
> [FSRT] within. 
> > 
> > Raphael Tryster 
> > 
> > -----Original Message----- 
> > From: petric john 
> [mailto:petric_john@yahoo.com.au <mailto:petric_john@yahoo.com.au> ] 
> > Sent: Thursday, 3 April 2003 16:01 
> > To: megaco@ietf.org 
> > Subject: [Megaco] Processing of command, action 
> ... 
> > 
> > 
> > Hi, 
> > 
> > This is in context of the text mentioned in 8.2.2 
> as 
> > below. 
> > 
> > S1: If the end of an action cannot be reliably 
> > determined but one or more commands can be parsed, 
> > it 
> > will process them and then send 422 - Syntax Error 
> > in 
> > Action as the last action for the transaction. 
> > 
> > S2: If the end of a transaction cannot be reliably 
> > determined and one or more Actions can be parsed, 
> it 
> > will process them and then return 403 - Syntax 
> Error 
> > in Transaction as the last action reply for the 
> > transaction. 
> > 
> > In both the above statemets, it is mentioned about 
> > the 
> > unreliable determination of the action, and 
> > transaction respectively. 
> > 
> > As mentioned, does processing of the commands (in 
> > S1) 
> > means the execution of the commands, and does 
> > processing of the action (in S2) means the 
> execution 
> > in the context of the MGC/MG application??? 
> > 
> > [FSRT] Yes. 
> > 
> [PJJ] I think then there are more issues asociated 
> with this. See below. 
> 
> > This apprently shows that even if the parsing 
> > (decoding) of the given component of the protocol 
> > message is partial, the decoded information is 
> still 
> > passed on to the MG/MGC application for further 
> > processing/execution. 
> > 
> > [FSRT]  Yes.  In practice, it means your parser 
> has 
> > to be able to generate 
> > partial output, as well as an indication that the 
> > only processing required 
> > for a specific command or action is to return an 
> > error. 
> > 
> [PJJ] 
> 
> 1. Assume that there are four commands in an action. 
> Now the parsing of the command 1 and 2 was 
> successful, 
> and the third one failed. Then according to the 
> above, 
> we shall send the command 1 and 2 to the 
> application. 
> What about the command command number 4 in the 
> action 
> (which could be syntactically correct)? What we 
> should 
> do to it?? 
> 
> 2. If we have to still parse for the command 4 in 
> the 
> action, then it is going to be difficult to know the 
> exact start of the command 4 in the action. 
> 
> 3. What would be the action on the sender's side in 
> this case?? As we shall report the error "422 - 
> Syntax 
> Error in Action" to the sender, how its going to 
> retransmitt the commands 3 and 4?? 
> 
> 4. Partial decoding is certainly not applicable in 
> case of command, as it does make any sense to do so. 
> Also the basic unit of the data that has to go to 
> the 
> application is Command, and it should be complete at 
> any point of time. Thus when sender, after receiving 
> the 422, shall send the command 3 and 4 with the 
> same 
> TransactionId (hopefully), in which case it will be 
> the re-transmission of the Transaction (which is 
> again 
> not correct). The resending of the commands 3 and 4 
> has to be a new Transaction. Correct me if wrong. 
> 
> 5. To make above process more complex, assume if the 
> command 1 and 3 were parsed successfully. then 
> should 
> we send command 1 and 3 to the application?? (even 
> otherwise parsing of the alternate commands is 
> definitely not easy. Same is the case with Action, 
> see 
> below. 
> 
> 6. I would like to make a point here that as long as 
> the parsing of the commands in the action (and so 
> actions in the Transaction) is moving successfully, 
> the information is useful. But we should stop 
> parsing 
> as soon as the command decode is failure, and jump 
> to 
> the next action in the Transaction (if present). 
> 
> 7. The parsing logic is certainly going to be 
> complex 
> to find out the next Action in the Transaction. 
> 
> looking forward for the clarifications. ;-) 
> 
> > So far I am under impression that even a single 
> > parse 
> > failure (at any level) of the messgge would 
> prohibit 
> > it from sending it to the application, thus 
> > rejecting 
> > it compeletely. 
> > 
> > [FSRT]  That was my impression once too, but I 
> > couldn't find anything in the 
> > standard to support it. 
> > 
> [PJJ] Same here. I guess there is no support in the 
> standard too for the some of the doubts raised 
> above. 
> 
> > what is the significance of the word "it will 
> > process 
> > them"??? 
> > 
> > [FSRT]  As if there were no subsequent error. 
> > 
> > regards, 
> > 
> > 
> > 
> > ===== 
> > ~|~ 
> >  o 
> > John 
> > 
> > http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile

> > - Check & compose your email via SMS on your 
> Telstra 
> > or Vodafone mobile. 
> > _______________________________________________ 
> > Megaco mailing list 
> > Megaco@ietf.org 
> > https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  
> >  
> 
> ===== 
> ~|~ 
>  o 
> John 
> 
> http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile 
> - Check & compose your email via SMS on your Telstra 
> or Vodafone mobile. 
>  

===== 
~|~ 
 o 
John 

http://mobile.yahoo.com.au <http://mobile.yahoo.com.au>  - Yahoo! Mobile 
- Check & compose your email via SMS on your Telstra or Vodafone mobile. 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 11 12:16:54 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19653
	for <megaco-archive@lists.ietf.org>; Fri, 11 Apr 2003 12:16:54 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGME807111;
	Fri, 11 Apr 2003 12:22:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGFK806882
	for <megaco@optimus.ietf.org>; Fri, 11 Apr 2003 12:15:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19488
	for <megaco@ietf.org>; Fri, 11 Apr 2003 12:08:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19417P-0003q2-00
	for megaco@ietf.org; Fri, 11 Apr 2003 12:11:11 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19417O-0003pz-00
	for megaco@ietf.org; Fri, 11 Apr 2003 12:11:10 -0400
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h3BGBA6a003513
	for <megaco@ietf.org>; Fri, 11 Apr 2003 09:11:10 -0700 (MST)
Received: from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3BGB8XL016649
	for <megaco@ietf.org>; Fri, 11 Apr 2003 11:11:08 -0500
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59)
	id <166WJ2DM>; Fri, 11 Apr 2003 09:11:08 -0700
Message-ID: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0A@az33exm05.corp.mot.com>
From: Majeed Arif-P27336 <Arif.Majeed@motorola.com>
To: megaco@ietf.org
Subject: [Megaco] Wild carding ephemeral terminations or multiple contexts
	 in ServiceChange for OOS
Date: Fri, 11 Apr 2003 09:10:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

All,

The MG has "n" number of boards for bearer processing. The "board1" has four active calls (but has capacity to handle "m" number of calls). All terminations on the MG are ephemeral and are structured like "Term/board1/term1" to "Term/boardn/termm". The "board1" abruptly goes out of service. Which of the following service change command from MG to MGC is more appropriate or even valid? (Suggestions for improvement are welcomed).

MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = * { 
           ServiceChange = Term/board1/* {Services {
               Method=Forced }
               }
        }
   } 


MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = 678 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 977 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 1274 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 170 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
   }

Do the MGC have to clear each of above calls with a subtract command (in some out of service situations, the MG does not have time to handle subtract command)?

Arif
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 11 12:18:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19700
	for <megaco-archive@odin.ietf.org>; Fri, 11 Apr 2003 12:18:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3BGOFb07232
	for megaco-archive@odin.ietf.org; Fri, 11 Apr 2003 12:24:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGOF807229
	for <megaco-web-archive@optimus.ietf.org>; Fri, 11 Apr 2003 12:24:15 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19669
	for <megaco-web-archive@ietf.org>; Fri, 11 Apr 2003 12:17:31 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1941G2-0003sa-00
	for megaco-web-archive@ietf.org; Fri, 11 Apr 2003 12:20:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1941G2-0003sX-00
	for megaco-web-archive@ietf.org; Fri, 11 Apr 2003 12:20:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGME807111;
	Fri, 11 Apr 2003 12:22:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BGFK806882
	for <megaco@optimus.ietf.org>; Fri, 11 Apr 2003 12:15:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19488
	for <megaco@ietf.org>; Fri, 11 Apr 2003 12:08:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19417P-0003q2-00
	for megaco@ietf.org; Fri, 11 Apr 2003 12:11:11 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19417O-0003pz-00
	for megaco@ietf.org; Fri, 11 Apr 2003 12:11:10 -0400
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h3BGBA6a003513
	for <megaco@ietf.org>; Fri, 11 Apr 2003 09:11:10 -0700 (MST)
Received: from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3BGB8XL016649
	for <megaco@ietf.org>; Fri, 11 Apr 2003 11:11:08 -0500
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59)
	id <166WJ2DM>; Fri, 11 Apr 2003 09:11:08 -0700
Message-ID: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0A@az33exm05.corp.mot.com>
From: Majeed Arif-P27336 <Arif.Majeed@motorola.com>
To: megaco@ietf.org
Subject: [Megaco] Wild carding ephemeral terminations or multiple contexts
	 in ServiceChange for OOS
Date: Fri, 11 Apr 2003 09:10:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

All,

The MG has "n" number of boards for bearer processing. The "board1" has four active calls (but has capacity to handle "m" number of calls). All terminations on the MG are ephemeral and are structured like "Term/board1/term1" to "Term/boardn/termm". The "board1" abruptly goes out of service. Which of the following service change command from MG to MGC is more appropriate or even valid? (Suggestions for improvement are welcomed).

MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = * { 
           ServiceChange = Term/board1/* {Services {
               Method=Forced }
               }
        }
   } 


MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = 678 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 977 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 1274 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 170 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
   }

Do the MGC have to clear each of above calls with a subtract command (in some out of service situations, the MG does not have time to handle subtract command)?

Arif
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 11 19:56:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05865
	for <megaco-archive@lists.ietf.org>; Fri, 11 Apr 2003 19:56:25 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3C01m809314;
	Fri, 11 Apr 2003 20:01:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BNst809093
	for <megaco@optimus.ietf.org>; Fri, 11 Apr 2003 19:54:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05734
	for <megaco@ietf.org>; Fri, 11 Apr 2003 19:48:01 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1948I0-0006iq-00
	for megaco@ietf.org; Fri, 11 Apr 2003 19:50:36 -0400
Received: from mail.afc.com ([207.104.129.12] helo=sparky.afc.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1948Hz-0006if-00
	for megaco@ietf.org; Fri, 11 Apr 2003 19:50:36 -0400
Received: (qmail 3969 invoked from network); 11 Apr 2003 23:40:05 -0000
Received: from unknown (HELO zzzconn03.afc.local) (10.1.4.53)
  by 0 with SMTP; 11 Apr 2003 23:40:05 -0000
Received: FROM xconn01.afc.local BY zzzconn03.afc.local ; Fri Apr 11 16:51:53 2003 -0700
Received: by xconn01.afc.local with Internet Mail Service (5.5.2653.19)
	id <FNFYNTR2>; Fri, 11 Apr 2003 16:48:48 -0700
Message-ID: <C56CF4033A34994ABCE50037C724DD92B8329D@zzzmail03.fibre.com>
From: John Stock <John.Stock@afc.com>
To: John Stock <John.Stock@afc.com>, "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Questions about auditing terminations
Date: Fri, 11 Apr 2003 16:49:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Anyone?

Thanks.

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Monday, March 17, 2003 10:00 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Questions about auditing terminations


Hi,

I have a few questions about auditing terminations.  The case I'm concerned
about is where an MGC wishes to audit individual terminations in the MG.
The MGC may or may not know the state of the termination in a call, i.e.
whether or not it's involved in a context or not.  This may arise out of
these conditions I can think of:

1.  The MGC resets and loses its connection database, and wants to query the
MG to rebuild it.
2.  The MG performs a switchover and loses a connection which it has Replied
to the MGC.  The MGC now has the context/term relationship but the MG does
not.  The MGC may wish to audit the terminations which had recent activity,
based on receipt of ServiceChange with method Disconnected.
3.  Other bad stuff like message loss, software bug, etc.

My questions are:

- In version 2, there's a new mechanism to retrieve a ContextID for a
termination, using AuditValue with a specific TerminationId and a ContextId
of ALL.  However per the spec this applies only to non-NULL contexts.  Why?
The MGC may not know whether or not the termination is involved in a
context, thus it seems inappropriate for the MG to fail the command if the
termination is in the NULL context.  It seems like it would be appropriate
to just return a null ContextId if the termination is not in a call.

- Relating to the previous question, it seems like it would be appropriate
for the MGC to use a value of CHOOSE in this case instead of ALL.  ALL
implies that multiple values may be returned, however since a termination
can only be involved in one context at a time this isn't valid.  I know the
MG isn't creating a new Context here, but it seems like in the AuditValue
case the CHOOSE ContextId could be defined to query an existing ID instead
of creating a new one.

- The spec seems to be quite ambiguous regarding wildcard values, especially
for ContextID.  The text ABNF lists (UNIT32 / "*" / "-" / "$") as valid
values for ContextId, however nowhere in the ABNF, or even elsewhere in the
spec (that I can see - maybe I'm missing it), does it explicitly say what
each of these parameters means, nor does it state in the referenced RFC2234.
The only mention that "$" is used for CHOOSE is in the last sentence in B.1:
"The CHOOSE TerminationID '$' may be used to signal to the MG that it has to
create an ephemeral Termination...", however this seems to be merely a
descriptive paragraph and not a specification, and doesn't even reference
ContextID; it's discussing TerminationID.  I'm actually more concerned about
"*" vs. "-"  -- which one of these is ALL?  I'm sure it's the former, but it
doesn't seem to be specified anywhere.

Thanks.

John Stock
Systems Engineering
Advanced Fibre Communications
john.stock@afc.com
707-792-6249

And now for the standard disclaimer (don't lawyers just make life fun?):

This message (including any attachments) is intended only for the use of the
named addressee(s), and may contain information that is legally privileged,
confidential or exempt from disclosure under applicable law. If you are not
a named addressee, you are hereby notified that any use, dissemination,
distribution or copying of this message is strictly prohibited. If you have
received this message in error, please notify the original sender
immediately by telephone or by return E-mail and delete this message, along
with any attachments, from your computer. Thank you.


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 11 19:57:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05891
	for <megaco-archive@odin.ietf.org>; Fri, 11 Apr 2003 19:57:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3C03sD09401
	for megaco-archive@odin.ietf.org; Fri, 11 Apr 2003 20:03:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3C03s809398
	for <megaco-web-archive@optimus.ietf.org>; Fri, 11 Apr 2003 20:03:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05885
	for <megaco-web-archive@ietf.org>; Fri, 11 Apr 2003 19:56:59 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1948Qh-0006ke-00
	for megaco-web-archive@ietf.org; Fri, 11 Apr 2003 19:59:35 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1948Qg-0006ka-00
	for megaco-web-archive@ietf.org; Fri, 11 Apr 2003 19:59:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3C01m809314;
	Fri, 11 Apr 2003 20:01:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BNst809093
	for <megaco@optimus.ietf.org>; Fri, 11 Apr 2003 19:54:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05734
	for <megaco@ietf.org>; Fri, 11 Apr 2003 19:48:01 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1948I0-0006iq-00
	for megaco@ietf.org; Fri, 11 Apr 2003 19:50:36 -0400
Received: from mail.afc.com ([207.104.129.12] helo=sparky.afc.com)
	by ietf-mx with smtp (Exim 4.12)
	id 1948Hz-0006if-00
	for megaco@ietf.org; Fri, 11 Apr 2003 19:50:36 -0400
Received: (qmail 3969 invoked from network); 11 Apr 2003 23:40:05 -0000
Received: from unknown (HELO zzzconn03.afc.local) (10.1.4.53)
  by 0 with SMTP; 11 Apr 2003 23:40:05 -0000
Received: FROM xconn01.afc.local BY zzzconn03.afc.local ; Fri Apr 11 16:51:53 2003 -0700
Received: by xconn01.afc.local with Internet Mail Service (5.5.2653.19)
	id <FNFYNTR2>; Fri, 11 Apr 2003 16:48:48 -0700
Message-ID: <C56CF4033A34994ABCE50037C724DD92B8329D@zzzmail03.fibre.com>
From: John Stock <John.Stock@afc.com>
To: John Stock <John.Stock@afc.com>, "'megaco@ietf.org'" <megaco@ietf.org>
Subject: RE: [Megaco] Questions about auditing terminations
Date: Fri, 11 Apr 2003 16:49:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Anyone?

Thanks.

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Monday, March 17, 2003 10:00 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Questions about auditing terminations


Hi,

I have a few questions about auditing terminations.  The case I'm concerned
about is where an MGC wishes to audit individual terminations in the MG.
The MGC may or may not know the state of the termination in a call, i.e.
whether or not it's involved in a context or not.  This may arise out of
these conditions I can think of:

1.  The MGC resets and loses its connection database, and wants to query the
MG to rebuild it.
2.  The MG performs a switchover and loses a connection which it has Replied
to the MGC.  The MGC now has the context/term relationship but the MG does
not.  The MGC may wish to audit the terminations which had recent activity,
based on receipt of ServiceChange with method Disconnected.
3.  Other bad stuff like message loss, software bug, etc.

My questions are:

- In version 2, there's a new mechanism to retrieve a ContextID for a
termination, using AuditValue with a specific TerminationId and a ContextId
of ALL.  However per the spec this applies only to non-NULL contexts.  Why?
The MGC may not know whether or not the termination is involved in a
context, thus it seems inappropriate for the MG to fail the command if the
termination is in the NULL context.  It seems like it would be appropriate
to just return a null ContextId if the termination is not in a call.

- Relating to the previous question, it seems like it would be appropriate
for the MGC to use a value of CHOOSE in this case instead of ALL.  ALL
implies that multiple values may be returned, however since a termination
can only be involved in one context at a time this isn't valid.  I know the
MG isn't creating a new Context here, but it seems like in the AuditValue
case the CHOOSE ContextId could be defined to query an existing ID instead
of creating a new one.

- The spec seems to be quite ambiguous regarding wildcard values, especially
for ContextID.  The text ABNF lists (UNIT32 / "*" / "-" / "$") as valid
values for ContextId, however nowhere in the ABNF, or even elsewhere in the
spec (that I can see - maybe I'm missing it), does it explicitly say what
each of these parameters means, nor does it state in the referenced RFC2234.
The only mention that "$" is used for CHOOSE is in the last sentence in B.1:
"The CHOOSE TerminationID '$' may be used to signal to the MG that it has to
create an ephemeral Termination...", however this seems to be merely a
descriptive paragraph and not a specification, and doesn't even reference
ContextID; it's discussing TerminationID.  I'm actually more concerned about
"*" vs. "-"  -- which one of these is ALL?  I'm sure it's the former, but it
doesn't seem to be specified anywhere.

Thanks.

John Stock
Systems Engineering
Advanced Fibre Communications
john.stock@afc.com
707-792-6249

And now for the standard disclaimer (don't lawyers just make life fun?):

This message (including any attachments) is intended only for the use of the
named addressee(s), and may contain information that is legally privileged,
confidential or exempt from disclosure under applicable law. If you are not
a named addressee, you are hereby notified that any use, dissemination,
distribution or copying of this message is strictly prohibited. If you have
received this message in error, please notify the original sender
immediately by telephone or by return E-mail and delete this message, along
with any attachments, from your computer. Thank you.


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Sat Apr 12 11:28:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29533
	for <megaco-archive@lists.ietf.org>; Sat, 12 Apr 2003 11:28:20 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFXY804445;
	Sat, 12 Apr 2003 11:33:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFR8804309
	for <megaco@optimus.ietf.org>; Sat, 12 Apr 2003 11:27:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29427
	for <megaco@ietf.org>; Sat, 12 Apr 2003 11:19:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Mpq-0001a2-00
	for megaco@ietf.org; Sat, 12 Apr 2003 11:22:30 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Mpp-0001Zz-00
	for megaco@ietf.org; Sat, 12 Apr 2003 11:22:29 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZWVVD>; Sat, 12 Apr 2003 11:17:10 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA220D7B@wench.telica.com>
From: Arnab Sengupta <asengupt@telica.com>
To: "'John Stock'" <John.Stock@afc.com>,
        "'megaco@ietf.org'"
	 <megaco@ietf.org>
Subject: RE: [Megaco] Questions about auditing terminations
Date: Sat, 12 Apr 2003 11:17:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

John,

A quick solution to your problem could be to send two Optional AuditValue
commands for the same termination; one on ALL context and the other on NULL
context. That way, the MG would return a positive reply for one and an error
for the other, thereby returning the state information of the termination.
An example transaction could look something like this:

Transaction = 111 {
   Context = * {
                O-AuditValue = TermA {
                     Audit {Media}
                   }    
                  },
   Context = - {
                O-AuditValue = TermA {
                     Audit {Media}
                  }
                }
         }


Regards
Arnab

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Friday, April 11, 2003 7:50 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] Questions about auditing terminations


Anyone?

Thanks.

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Monday, March 17, 2003 10:00 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Questions about auditing terminations


Hi,

I have a few questions about auditing terminations.  The case I'm concerned
about is where an MGC wishes to audit individual terminations in the MG.
The MGC may or may not know the state of the termination in a call, i.e.
whether or not it's involved in a context or not.  This may arise out of
these conditions I can think of:

1.  The MGC resets and loses its connection database, and wants to query the
MG to rebuild it.
2.  The MG performs a switchover and loses a connection which it has Replied
to the MGC.  The MGC now has the context/term relationship but the MG does
not.  The MGC may wish to audit the terminations which had recent activity,
based on receipt of ServiceChange with method Disconnected.
3.  Other bad stuff like message loss, software bug, etc.

My questions are:

- In version 2, there's a new mechanism to retrieve a ContextID for a
termination, using AuditValue with a specific TerminationId and a ContextId
of ALL.  However per the spec this applies only to non-NULL contexts.  Why?
The MGC may not know whether or not the termination is involved in a
context, thus it seems inappropriate for the MG to fail the command if the
termination is in the NULL context.  It seems like it would be appropriate
to just return a null ContextId if the termination is not in a call.

- Relating to the previous question, it seems like it would be appropriate
for the MGC to use a value of CHOOSE in this case instead of ALL.  ALL
implies that multiple values may be returned, however since a termination
can only be involved in one context at a time this isn't valid.  I know the
MG isn't creating a new Context here, but it seems like in the AuditValue
case the CHOOSE ContextId could be defined to query an existing ID instead
of creating a new one.

- The spec seems to be quite ambiguous regarding wildcard values, especially
for ContextID.  The text ABNF lists (UNIT32 / "*" / "-" / "$") as valid
values for ContextId, however nowhere in the ABNF, or even elsewhere in the
spec (that I can see - maybe I'm missing it), does it explicitly say what
each of these parameters means, nor does it state in the referenced RFC2234.
The only mention that "$" is used for CHOOSE is in the last sentence in B.1:
"The CHOOSE TerminationID '$' may be used to signal to the MG that it has to
create an ephemeral Termination...", however this seems to be merely a
descriptive paragraph and not a specification, and doesn't even reference
ContextID; it's discussing TerminationID.  I'm actually more concerned about
"*" vs. "-"  -- which one of these is ALL?  I'm sure it's the former, but it
doesn't seem to be specified anywhere.

Thanks.

John Stock
Systems Engineering
Advanced Fibre Communications
john.stock@afc.com
707-792-6249

And now for the standard disclaimer (don't lawyers just make life fun?):

This message (including any attachments) is intended only for the use of the
named addressee(s), and may contain information that is legally privileged,
confidential or exempt from disclosure under applicable law. If you are not
a named addressee, you are hereby notified that any use, dissemination,
distribution or copying of this message is strictly prohibited. If you have
received this message in error, please notify the original sender
immediately by telephone or by return E-mail and delete this message, along
with any attachments, from your computer. Thank you.


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Sat Apr 12 11:29:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29567
	for <megaco-archive@odin.ietf.org>; Sat, 12 Apr 2003 11:29:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3CFa9e04568
	for megaco-archive@odin.ietf.org; Sat, 12 Apr 2003 11:36:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFa9804565
	for <megaco-web-archive@optimus.ietf.org>; Sat, 12 Apr 2003 11:36:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29564
	for <megaco-web-archive@ietf.org>; Sat, 12 Apr 2003 11:28:55 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194MyY-0001bX-00
	for megaco-web-archive@ietf.org; Sat, 12 Apr 2003 11:31:30 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 194MyY-0001bU-00
	for megaco-web-archive@ietf.org; Sat, 12 Apr 2003 11:31:30 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFXY804445;
	Sat, 12 Apr 2003 11:33:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFR8804309
	for <megaco@optimus.ietf.org>; Sat, 12 Apr 2003 11:27:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29427
	for <megaco@ietf.org>; Sat, 12 Apr 2003 11:19:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Mpq-0001a2-00
	for megaco@ietf.org; Sat, 12 Apr 2003 11:22:30 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 194Mpp-0001Zz-00
	for megaco@ietf.org; Sat, 12 Apr 2003 11:22:29 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZWVVD>; Sat, 12 Apr 2003 11:17:10 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA220D7B@wench.telica.com>
From: Arnab Sengupta <asengupt@telica.com>
To: "'John Stock'" <John.Stock@afc.com>,
        "'megaco@ietf.org'"
	 <megaco@ietf.org>
Subject: RE: [Megaco] Questions about auditing terminations
Date: Sat, 12 Apr 2003 11:17:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

John,

A quick solution to your problem could be to send two Optional AuditValue
commands for the same termination; one on ALL context and the other on NULL
context. That way, the MG would return a positive reply for one and an error
for the other, thereby returning the state information of the termination.
An example transaction could look something like this:

Transaction = 111 {
   Context = * {
                O-AuditValue = TermA {
                     Audit {Media}
                   }    
                  },
   Context = - {
                O-AuditValue = TermA {
                     Audit {Media}
                  }
                }
         }


Regards
Arnab

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Friday, April 11, 2003 7:50 PM
To: John Stock; 'megaco@ietf.org'
Subject: RE: [Megaco] Questions about auditing terminations


Anyone?

Thanks.

-----Original Message-----
From: John Stock [mailto:John.Stock@afc.com]
Sent: Monday, March 17, 2003 10:00 AM
To: 'megaco@ietf.org'
Subject: [Megaco] Questions about auditing terminations


Hi,

I have a few questions about auditing terminations.  The case I'm concerned
about is where an MGC wishes to audit individual terminations in the MG.
The MGC may or may not know the state of the termination in a call, i.e.
whether or not it's involved in a context or not.  This may arise out of
these conditions I can think of:

1.  The MGC resets and loses its connection database, and wants to query the
MG to rebuild it.
2.  The MG performs a switchover and loses a connection which it has Replied
to the MGC.  The MGC now has the context/term relationship but the MG does
not.  The MGC may wish to audit the terminations which had recent activity,
based on receipt of ServiceChange with method Disconnected.
3.  Other bad stuff like message loss, software bug, etc.

My questions are:

- In version 2, there's a new mechanism to retrieve a ContextID for a
termination, using AuditValue with a specific TerminationId and a ContextId
of ALL.  However per the spec this applies only to non-NULL contexts.  Why?
The MGC may not know whether or not the termination is involved in a
context, thus it seems inappropriate for the MG to fail the command if the
termination is in the NULL context.  It seems like it would be appropriate
to just return a null ContextId if the termination is not in a call.

- Relating to the previous question, it seems like it would be appropriate
for the MGC to use a value of CHOOSE in this case instead of ALL.  ALL
implies that multiple values may be returned, however since a termination
can only be involved in one context at a time this isn't valid.  I know the
MG isn't creating a new Context here, but it seems like in the AuditValue
case the CHOOSE ContextId could be defined to query an existing ID instead
of creating a new one.

- The spec seems to be quite ambiguous regarding wildcard values, especially
for ContextID.  The text ABNF lists (UNIT32 / "*" / "-" / "$") as valid
values for ContextId, however nowhere in the ABNF, or even elsewhere in the
spec (that I can see - maybe I'm missing it), does it explicitly say what
each of these parameters means, nor does it state in the referenced RFC2234.
The only mention that "$" is used for CHOOSE is in the last sentence in B.1:
"The CHOOSE TerminationID '$' may be used to signal to the MG that it has to
create an ephemeral Termination...", however this seems to be merely a
descriptive paragraph and not a specification, and doesn't even reference
ContextID; it's discussing TerminationID.  I'm actually more concerned about
"*" vs. "-"  -- which one of these is ALL?  I'm sure it's the former, but it
doesn't seem to be specified anywhere.

Thanks.

John Stock
Systems Engineering
Advanced Fibre Communications
john.stock@afc.com
707-792-6249

And now for the standard disclaimer (don't lawyers just make life fun?):

This message (including any attachments) is intended only for the use of the
named addressee(s), and may contain information that is legally privileged,
confidential or exempt from disclosure under applicable law. If you are not
a named addressee, you are hereby notified that any use, dissemination,
distribution or copying of this message is strictly prohibited. If you have
received this message in error, please notify the original sender
immediately by telephone or by return E-mail and delete this message, along
with any attachments, from your computer. Thank you.


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 05:11:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19658
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 05:11:51 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9J1818884;
	Tue, 15 Apr 2003 05:19:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9BK818681
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 05:11:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19584
	for <megaco@ietf.org>; Tue, 15 Apr 2003 05:02:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195MNS-00012h-00
	for megaco@ietf.org; Tue, 15 Apr 2003 05:05:18 -0400
Received: from shardagate.mahindrabt.com ([203.124.158.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 195MNQ-00012e-00
	for megaco@ietf.org; Tue, 15 Apr 2003 05:05:17 -0400
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3F94w4L004890
	for <megaco@ietf.org>; Tue, 15 Apr 2003 14:35:03 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Tue, 15 Apr 2003 14:21:07 +0530
Date: Tue, 15 Apr 2003 14:21:07 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: anilj@mahindrabt.com
Received: from dscp00986 ([10.5.6.22])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id OAA28661
	for <megaco@ietf.org>; Tue, 15 Apr 2003 14:34:53 +0530
Message-ID: <008101c3032e$bc0a5ac0$1606050a@mahindrabt.com>
From: "Anil Jangam" <anilj@mahindrabt.com>
To: <megaco@ietf.org>
Date: Tue, 15 Apr 2003 14:39:35 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Reuse of TransactionIds in Three-way handshake
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

As specified in the RFC, point D.1.1:

The copy of the responses may be destroyed either LONG-TIMER seconds after
the response is issued, or when the entity receives a confirmation that the
response has been received, through the "Response Acknowledgement
parameter". For transactions that are acknowledged through this parameter,
the entity shall keep a copy of the transaction-id for LONG-TIMER seconds
after the response is issued, in order to detect and ignore duplicate copies
of the transaction request that could be produced by the network.

(Issentially it says that the TransactionIds shall not be reused untill the
LONG-TIMER associated with it is elapsed).

Whereas in point D.1.2.2 specifies that :

The "confirmed transaction-id ranges" values shall not be used if more than
LONG-TIMER seconds have elapsed since the MG issued its last response to
that MGC, or when a MG resumes operation. In this situation, transactions
should be accepted and processed, without any test on the transaction.id.

What confuses me here is that text in D.1.1 metions about when to reuse the
TransactionIds, where as text in D.1.2.2 doesn't really agrees with it. What
is the relation between these two???

====

Regards,
/anil

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 05:12:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19717
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 05:12:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3F9L0C19023
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 05:21:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9L0819020
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 05:21:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19690
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 05:12:26 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195MWo-00013v-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 05:14:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195MWn-00013r-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 05:14:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9J1818884;
	Tue, 15 Apr 2003 05:19:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F9BK818681
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 05:11:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19584
	for <megaco@ietf.org>; Tue, 15 Apr 2003 05:02:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195MNS-00012h-00
	for megaco@ietf.org; Tue, 15 Apr 2003 05:05:18 -0400
Received: from shardagate.mahindrabt.com ([203.124.158.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 195MNQ-00012e-00
	for megaco@ietf.org; Tue, 15 Apr 2003 05:05:17 -0400
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3F94w4L004890
	for <megaco@ietf.org>; Tue, 15 Apr 2003 14:35:03 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Tue, 15 Apr 2003 14:21:07 +0530
Date: Tue, 15 Apr 2003 14:21:07 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: anilj@mahindrabt.com
Received: from dscp00986 ([10.5.6.22])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id OAA28661
	for <megaco@ietf.org>; Tue, 15 Apr 2003 14:34:53 +0530
Message-ID: <008101c3032e$bc0a5ac0$1606050a@mahindrabt.com>
From: "Anil Jangam" <anilj@mahindrabt.com>
To: <megaco@ietf.org>
Date: Tue, 15 Apr 2003 14:39:35 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Reuse of TransactionIds in Three-way handshake
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

As specified in the RFC, point D.1.1:

The copy of the responses may be destroyed either LONG-TIMER seconds after
the response is issued, or when the entity receives a confirmation that the
response has been received, through the "Response Acknowledgement
parameter". For transactions that are acknowledged through this parameter,
the entity shall keep a copy of the transaction-id for LONG-TIMER seconds
after the response is issued, in order to detect and ignore duplicate copies
of the transaction request that could be produced by the network.

(Issentially it says that the TransactionIds shall not be reused untill the
LONG-TIMER associated with it is elapsed).

Whereas in point D.1.2.2 specifies that :

The "confirmed transaction-id ranges" values shall not be used if more than
LONG-TIMER seconds have elapsed since the MG issued its last response to
that MGC, or when a MG resumes operation. In this situation, transactions
should be accepted and processed, without any test on the transaction.id.

What confuses me here is that text in D.1.1 metions about when to reuse the
TransactionIds, where as text in D.1.2.2 doesn't really agrees with it. What
is the relation between these two???

====

Regards,
/anil

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 07:14:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22060
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 07:14:01 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBLQ826777;
	Tue, 15 Apr 2003 07:21:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBGp826634
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 07:16:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21695
	for <megaco@ietf.org>; Tue, 15 Apr 2003 07:08:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OKs-0001Sp-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:10:47 -0400
Received: from [202.144.91.188] (helo=ipgen-india.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OKs-0001Sl-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:10:46 -0400
Received: from sureshchandra [192.168.1.230]
	by ipgen-india.com [192.168.1.15]
	with SMTP (MDaemon.PRO.v5.0.7.T)
	for <megaco@ietf.org>; Tue, 15 Apr 2003 16:40:03 +0530
Message-ID: <003601c3033f$bfcde2b0$e601a8c0@sureshchandra>
From: "H.S.Sureshchandra" <suresh@ipgen.com>
To: <megaco@ietf.org>, "Anil Jangam" <anilj@mahindrabt.com>
References: <008101c3032e$bc0a5ac0$1606050a@mahindrabt.com>
Subject: Re: [Megaco] Reuse of TransactionIds in Three-way handshake
Date: Tue, 15 Apr 2003 16:41:20 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MDRemoteIP: 192.168.1.230
X-Return-Path: suresh@ipgen.com
X-MDaemon-Deliver-To: megaco@ietf.org
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Anil,

In D.1.2.2 there are two cases mentioned.

If LT expires, do not take into account "confirmed transaction-id ranges" -
which is fair enough and same as stated in D.1.1

The second case pertains to MG resuming operation ie.. Restart - Here it is
but natural that all previous Transaction IDs will not matter and MG should
process ALL Transaction IDs and therefore ignore "confirmed transaction-id
ranges" .

I hope this clarifies the issue adequately.

Thanks.

Suresh


----- Original Message -----
From: "Anil Jangam" <anilj@mahindrabt.com>
To: <megaco@ietf.org>
Sent: Tuesday, April 15, 2003 2:21 PM
Subject: [Megaco] Reuse of TransactionIds in Three-way handshake


> Hi,
>
> As specified in the RFC, point D.1.1:
>
> The copy of the responses may be destroyed either LONG-TIMER seconds after
> the response is issued, or when the entity receives a confirmation that
the
> response has been received, through the "Response Acknowledgement
> parameter". For transactions that are acknowledged through this parameter,
> the entity shall keep a copy of the transaction-id for LONG-TIMER seconds
> after the response is issued, in order to detect and ignore duplicate
copies
> of the transaction request that could be produced by the network.
>
> (Issentially it says that the TransactionIds shall not be reused untill
the
> LONG-TIMER associated with it is elapsed).
>
> Whereas in point D.1.2.2 specifies that :
>
> The "confirmed transaction-id ranges" values shall not be used if more
than
> LONG-TIMER seconds have elapsed since the MG issued its last response to
> that MGC, or when a MG resumes operation. In this situation, transactions
> should be accepted and processed, without any test on the transaction.id.
>
> What confuses me here is that text in D.1.1 metions about when to reuse
the
> TransactionIds, where as text in D.1.2.2 doesn't really agrees with it.
What
> is the relation between these two???
>
> ====
>
> Regards,
> /anil
>
> *********************************************************
> Disclaimer
>
> This message (including any attachments) contains
> confidential information intended for a specific
> individual and purpose, and is protected by law.
> If you are not the intended recipient, you should
> delete this message and are hereby notified that
> any disclosure, copying, or distribution of this
> message, or the taking of any action based on it,
> is strictly prohibited.
>
> *********************************************************
> Visit us at http://www.mahindrabt.com
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 07:15:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22125
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 07:15:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FBNDk26859
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 07:23:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBND826856
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 07:23:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22086
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 07:14:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OR2-0001UK-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 07:17:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OR2-0001UH-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 07:17:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBLQ826777;
	Tue, 15 Apr 2003 07:21:26 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBGp826634
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 07:16:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21695
	for <megaco@ietf.org>; Tue, 15 Apr 2003 07:08:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OKs-0001Sp-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:10:47 -0400
Received: from [202.144.91.188] (helo=ipgen-india.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195OKs-0001Sl-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:10:46 -0400
Received: from sureshchandra [192.168.1.230]
	by ipgen-india.com [192.168.1.15]
	with SMTP (MDaemon.PRO.v5.0.7.T)
	for <megaco@ietf.org>; Tue, 15 Apr 2003 16:40:03 +0530
Message-ID: <003601c3033f$bfcde2b0$e601a8c0@sureshchandra>
From: "H.S.Sureshchandra" <suresh@ipgen.com>
To: <megaco@ietf.org>, "Anil Jangam" <anilj@mahindrabt.com>
References: <008101c3032e$bc0a5ac0$1606050a@mahindrabt.com>
Subject: Re: [Megaco] Reuse of TransactionIds in Three-way handshake
Date: Tue, 15 Apr 2003 16:41:20 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MDRemoteIP: 192.168.1.230
X-Return-Path: suresh@ipgen.com
X-MDaemon-Deliver-To: megaco@ietf.org
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Anil,

In D.1.2.2 there are two cases mentioned.

If LT expires, do not take into account "confirmed transaction-id ranges" -
which is fair enough and same as stated in D.1.1

The second case pertains to MG resuming operation ie.. Restart - Here it is
but natural that all previous Transaction IDs will not matter and MG should
process ALL Transaction IDs and therefore ignore "confirmed transaction-id
ranges" .

I hope this clarifies the issue adequately.

Thanks.

Suresh


----- Original Message -----
From: "Anil Jangam" <anilj@mahindrabt.com>
To: <megaco@ietf.org>
Sent: Tuesday, April 15, 2003 2:21 PM
Subject: [Megaco] Reuse of TransactionIds in Three-way handshake


> Hi,
>
> As specified in the RFC, point D.1.1:
>
> The copy of the responses may be destroyed either LONG-TIMER seconds after
> the response is issued, or when the entity receives a confirmation that
the
> response has been received, through the "Response Acknowledgement
> parameter". For transactions that are acknowledged through this parameter,
> the entity shall keep a copy of the transaction-id for LONG-TIMER seconds
> after the response is issued, in order to detect and ignore duplicate
copies
> of the transaction request that could be produced by the network.
>
> (Issentially it says that the TransactionIds shall not be reused untill
the
> LONG-TIMER associated with it is elapsed).
>
> Whereas in point D.1.2.2 specifies that :
>
> The "confirmed transaction-id ranges" values shall not be used if more
than
> LONG-TIMER seconds have elapsed since the MG issued its last response to
> that MGC, or when a MG resumes operation. In this situation, transactions
> should be accepted and processed, without any test on the transaction.id.
>
> What confuses me here is that text in D.1.1 metions about when to reuse
the
> TransactionIds, where as text in D.1.2.2 doesn't really agrees with it.
What
> is the relation between these two???
>
> ====
>
> Regards,
> /anil
>
> *********************************************************
> Disclaimer
>
> This message (including any attachments) contains
> confidential information intended for a specific
> individual and purpose, and is protected by law.
> If you are not the intended recipient, you should
> delete this message and are hereby notified that
> any disclosure, copying, or distribution of this
> message, or the taking of any action based on it,
> is strictly prohibited.
>
> *********************************************************
> Visit us at http://www.mahindrabt.com
>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 07:50:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24267
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 07:50:41 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBvl829327;
	Tue, 15 Apr 2003 07:57:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBr8829171
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 07:53:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23921
	for <megaco@ietf.org>; Tue, 15 Apr 2003 07:44:30 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Oty-0001zr-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:47:02 -0400
Received: from mx0.rambler.ru ([81.19.66.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Oty-0001zo-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:47:02 -0400
Received: from mail4.rambler.ru (mail4.rambler.ru [217.73.192.33])
	by mx0.rambler.ru (Postfix) with SMTP id B456D42F57E
	for <megaco@ietf.org>; Tue, 15 Apr 2003 16:04:14 +0400 (MSD)
	(envelope-from fhuval@rambler.ru)
Received: from 217.73.192.36 by rambler.ru with SMTP id AA11392 for
 megaco@ietf.org; Tue, 15 Apr 2003 15:36:49 +0400 (MSD)
From: Fhuval Hittay <fhuval@rambler.ru>
To: megaco@ietf.org
Message-Id: <3E9BF091.AA16406@mb3.rambler.ru>
Content-Type: text/plain; charset=koi8-r
MIME-Version: 1.0
Date: Tue, 15 Apr 2003 15:44:17 +0400 (MSD)
Subject: [Megaco] using UDP in MEGACO
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hello all,
could anyone answer how could be avoided wrong sequence of received MEGACO 
messages when using UDP as a transport mechanism?

thanks in advance.

---------
http://www.rambler.ru/
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 07:51:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24308
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 07:51:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FBxqu29464
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 07:59:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBxq829460
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 07:59:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24292
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 07:51:14 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195P0U-000278-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 07:53:46 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195P0U-000275-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 07:53:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBvl829327;
	Tue, 15 Apr 2003 07:57:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBr8829171
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 07:53:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23921
	for <megaco@ietf.org>; Tue, 15 Apr 2003 07:44:30 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Oty-0001zr-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:47:02 -0400
Received: from mx0.rambler.ru ([81.19.66.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Oty-0001zo-00
	for megaco@ietf.org; Tue, 15 Apr 2003 07:47:02 -0400
Received: from mail4.rambler.ru (mail4.rambler.ru [217.73.192.33])
	by mx0.rambler.ru (Postfix) with SMTP id B456D42F57E
	for <megaco@ietf.org>; Tue, 15 Apr 2003 16:04:14 +0400 (MSD)
	(envelope-from fhuval@rambler.ru)
Received: from 217.73.192.36 by rambler.ru with SMTP id AA11392 for
 megaco@ietf.org; Tue, 15 Apr 2003 15:36:49 +0400 (MSD)
From: Fhuval Hittay <fhuval@rambler.ru>
To: megaco@ietf.org
Message-Id: <3E9BF091.AA16406@mb3.rambler.ru>
Content-Type: text/plain; charset=koi8-r
MIME-Version: 1.0
Date: Tue, 15 Apr 2003 15:44:17 +0400 (MSD)
Subject: [Megaco] using UDP in MEGACO
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hello all,
could anyone answer how could be avoided wrong sequence of received MEGACO 
messages when using UDP as a transport mechanism?

thanks in advance.

---------
http://www.rambler.ru/
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 11:06:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00722
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 11:06:18 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFDM810829;
	Tue, 15 Apr 2003 11:13:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FF8K810640
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 11:08:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00496
	for <megaco@ietf.org>; Tue, 15 Apr 2003 10:59:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Rwp-0002wW-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:02:11 -0400
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Rwp-0002wA-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:02:11 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FF1kq11852
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:01:47 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GDFVHBYA; Tue, 15 Apr 2003 11:01:47 -0400
Received: from nortelnetworks.com (acart1b6.ca.nortel.com [47.129.129.16]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2WPXXPBB; Tue, 15 Apr 2003 11:01:46 -0400
Message-ID: <3E9C1ED4.4000508@nortelnetworks.com>
Date: Tue, 15 Apr 2003 11:01:40 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Restriction on Modification Of Terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1) prior to 
its release, and got a slight surprise.  At the end of section 6.2.1 there is this 
sentence:

"An MGC can only release/modify Terminations
    and the resources that the Termination represents which it has
    previously seized via, e.g., the Add command."

It seems to me this precludes doing Modifies in the NULL context, but I've seen 
various call flows that do just that.  Should we feed this back to SG 16 as 
something that should be fixed up to conform with practice?

Tom Taylor

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 11:07:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00758
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 11:07:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FFFX710956
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 11:15:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFFX810949
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 11:15:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00750
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 11:06:52 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195S3n-0002z2-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 11:09:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195S3n-0002yz-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 11:09:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFDM810829;
	Tue, 15 Apr 2003 11:13:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FF8K810640
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 11:08:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00496
	for <megaco@ietf.org>; Tue, 15 Apr 2003 10:59:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195Rwp-0002wW-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:02:11 -0400
Received: from zcars0m9.nortelnetworks.com ([47.129.242.157])
	by ietf-mx with esmtp (Exim 4.12)
	id 195Rwp-0002wA-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:02:11 -0400
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FF1kq11852
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:01:47 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GDFVHBYA; Tue, 15 Apr 2003 11:01:47 -0400
Received: from nortelnetworks.com (acart1b6.ca.nortel.com [47.129.129.16]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2WPXXPBB; Tue, 15 Apr 2003 11:01:46 -0400
Message-ID: <3E9C1ED4.4000508@nortelnetworks.com>
Date: Tue, 15 Apr 2003 11:01:40 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Restriction on Modification Of Terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1) prior to 
its release, and got a slight surprise.  At the end of section 6.2.1 there is this 
sentence:

"An MGC can only release/modify Terminations
    and the resources that the Termination represents which it has
    previously seized via, e.g., the Add command."

It seems to me this precludes doing Modifies in the NULL context, but I've seen 
various call flows that do just that.  Should we feed this back to SG 16 as 
something that should be fixed up to conform with practice?

Tom Taylor

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 11:10:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00849
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 11:10:12 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFHY811036;
	Tue, 15 Apr 2003 11:17:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFA8810709
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 11:10:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00555
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:01:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195RyZ-0002xD-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:03:59 -0400
Received: from [144.189.100.106] (helo=motgate6.mot.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195RyY-0002x8-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:03:58 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100])
	by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3FF458T003751
	for <megaco@ietf.org>; Tue, 15 Apr 2003 08:04:05 -0700 (MST)
Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA22058 for <megaco@ietf.org>; Tue, 15 Apr 2003 08:04:04 -0700 (MST)]
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59)
	id <166WKZVS>; Tue, 15 Apr 2003 08:03:19 -0700
Message-ID: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0C@az33exm05.corp.mot.com>
From: Majeed Arif-P27336 <Arif.Majeed@motorola.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: [Megaco] Wild carding ephemeral terminations or multiple contexts
	 in ServiceChange for OOS notification
Date: Tue, 15 Apr 2003 08:02:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


**** Retransmitted. Sorry for a low SNR. I did not receive any comment *******


All,

The MG has "N" number of boards for bearer processing. The "board1" has four active calls (but has capacity to handle "M" number of calls). All terminations on the MG are ephemeral and are structured like "Term/board1/term1" thru "Term/boardn/termM". The "board1" abruptly goes out of service. Which of the following service change command from MG to MGC is more appropriate or even valid? (Suggestions for improvement are welcomed).

MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = * { 
           ServiceChange = Term/board1/* {Services {
               Method=Forced }
               }
        }
   } 


MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = 678 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 977 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 1274 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 170 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
   }

Note: All terminations in a context span within the same board in the above example. However, the above command may not be valid when a context contains terminations, which span through out the ROOT. 

Arif
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 11:11:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00893
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 11:11:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FFJRX11150
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 11:19:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFJQ811147
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 11:19:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00875
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 11:10:46 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195S7Z-0002zy-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 11:13:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195S7Y-0002zv-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 11:13:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFHY811036;
	Tue, 15 Apr 2003 11:17:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFA8810709
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 11:10:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00555
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:01:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195RyZ-0002xD-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:03:59 -0400
Received: from [144.189.100.106] (helo=motgate6.mot.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195RyY-0002x8-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:03:58 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100])
	by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h3FF458T003751
	for <megaco@ietf.org>; Tue, 15 Apr 2003 08:04:05 -0700 (MST)
Received: [from az33exm05.corp.mot.com (az33exm05.corp.mot.com [199.2.84.25]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA22058 for <megaco@ietf.org>; Tue, 15 Apr 2003 08:04:04 -0700 (MST)]
Received: by az33exm05.corp.mot.com with Internet Mail Service (5.5.2656.59)
	id <166WKZVS>; Tue, 15 Apr 2003 08:03:19 -0700
Message-ID: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0C@az33exm05.corp.mot.com>
From: Majeed Arif-P27336 <Arif.Majeed@motorola.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: [Megaco] Wild carding ephemeral terminations or multiple contexts
	 in ServiceChange for OOS notification
Date: Tue, 15 Apr 2003 08:02:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


**** Retransmitted. Sorry for a low SNR. I did not receive any comment *******


All,

The MG has "N" number of boards for bearer processing. The "board1" has four active calls (but has capacity to handle "M" number of calls). All terminations on the MG are ephemeral and are structured like "Term/board1/term1" thru "Term/boardn/termM". The "board1" abruptly goes out of service. Which of the following service change command from MG to MGC is more appropriate or even valid? (Suggestions for improvement are welcomed).

MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = * { 
           ServiceChange = Term/board1/* {Services {
               Method=Forced }
               }
        }
   } 


MEGACO/1 [10.1.33.61]: 25000
   Transaction = 4321 {
       Context = 678 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 977 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 1274 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
       Context = 170 { 
           ServiceChange = * {Services {
               Method=Forced }
               }
        }
   }

Note: All terminations in a context span within the same board in the above example. However, the above command may not be valid when a context contains terminations, which span through out the ROOT. 

Arif
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 12:10:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02640
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 12:10:19 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FGHH815932;
	Tue, 15 Apr 2003 12:17:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FG0Z814074
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 12:00:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02247
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:51:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195SlN-0003EP-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:54:25 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 195SlM-0003EM-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:54:24 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FFrtA17029
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:53:56 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96AYCB>; Tue, 15 Apr 2003 11:53:56 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08BE98D9@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
Date: Tue, 15 Apr 2003 11:53:46 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Clearly this is an error, since, for example, the MG wouldn't want a phone
in a context just to detect off-hook.  Likewise, if that set is currently in
Null and looking for off-hook, then the MGC may wish to stop looking for
off-hook (for any of a number of reasons) by Modifying the term with an
empty Events descriptor.

Any objections to striking the "/modify" portion of the sentence via the IG?

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Tuesday, April 15, 2003 11:02 AM
To: megaco@ietf.org
Subject: [Megaco] Restriction on Modification Of Terminations


I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1)
prior to 
its release, and got a slight surprise.  At the end of section 6.2.1 there
is this 
sentence:

"An MGC can only release/modify Terminations
    and the resources that the Termination represents which it has
    previously seized via, e.g., the Add command."

It seems to me this precludes doing Modifies in the NULL context, but I've
seen 
various call flows that do just that.  Should we feed this back to SG 16 as 
something that should be fixed up to conform with practice?

Tom Taylor

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 12:11:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02697
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 12:11:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FGJeR16122
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 12:19:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FGJe816119
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 12:19:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02673
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 12:10:58 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195T3p-0003JC-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 12:13:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195T3p-0003J9-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 12:13:29 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FGHH815932;
	Tue, 15 Apr 2003 12:17:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FG0Z814074
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 12:00:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02247
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:51:54 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195SlN-0003EP-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:54:25 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 195SlM-0003EM-00
	for megaco@ietf.org; Tue, 15 Apr 2003 11:54:24 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FFrtA17029
	for <megaco@ietf.org>; Tue, 15 Apr 2003 11:53:56 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96AYCB>; Tue, 15 Apr 2003 11:53:56 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08BE98D9@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: "Tom-PT Taylor" <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
Date: Tue, 15 Apr 2003 11:53:46 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Clearly this is an error, since, for example, the MG wouldn't want a phone
in a context just to detect off-hook.  Likewise, if that set is currently in
Null and looking for off-hook, then the MGC may wish to stop looking for
off-hook (for any of a number of reasons) by Modifying the term with an
empty Events descriptor.

Any objections to striking the "/modify" portion of the sentence via the IG?

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Tuesday, April 15, 2003 11:02 AM
To: megaco@ietf.org
Subject: [Megaco] Restriction on Modification Of Terminations


I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1)
prior to 
its release, and got a slight surprise.  At the end of section 6.2.1 there
is this 
sentence:

"An MGC can only release/modify Terminations
    and the resources that the Termination represents which it has
    previously seized via, e.g., the Add command."

It seems to me this precludes doing Modifies in the NULL context, but I've
seen 
various call flows that do just that.  Should we feed this back to SG 16 as 
something that should be fixed up to conform with practice?

Tom Taylor

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 13:38:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05018
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 13:38:01 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHjW822510;
	Tue, 15 Apr 2003 13:45:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHeB822355
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 13:40:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04899
	for <megaco@ietf.org>; Tue, 15 Apr 2003 13:31:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UJj-0003em-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:33:59 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UJi-0003ej-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:33:58 -0400
Received: from bulb ([10.0.1.99]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Apr 2003 13:33:35 -0400
Date: Tue, 15 Apr 2003 13:33:35 -0400 (EDT)
From: Srinivasan Krishnamoorthy <ksrini@winphoria.com>
Reply-To: ksrini@winphoria.com
To: Kevin Boyle <kboyle@nortelnetworks.com>
cc: Tom-PT Taylor <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C08BE98D9@zrtpd0jq.us.nortel.com>
Message-ID: <Pine.LNX.4.21.0304151331240.3031-100000@bulb.winphoria.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 15 Apr 2003 17:33:35.0496 (UTC) FILETIME=[24807080:01C30375]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Hi,

What happens in the case where a Handoff to a redundant MGC has
happened, but the contexts where originally created by a 
primary MGC.

So, shouldn't we actually allow Subtracts from the new MGC,
as well then?

Thanks,
-Srini

On Tue, 15 Apr 2003, Kevin Boyle wrote:

kboyle>Clearly this is an error, since, for example, the MG wouldn't want a phone
kboyle>in a context just to detect off-hook.  Likewise, if that set is currently in
kboyle>Null and looking for off-hook, then the MGC may wish to stop looking for
kboyle>off-hook (for any of a number of reasons) by Modifying the term with an
kboyle>empty Events descriptor.
kboyle>
kboyle>Any objections to striking the "/modify" portion of the sentence via the IG?
kboyle>
kboyle>Kevin
kboyle>
kboyle>-----Original Message-----
kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH] 
kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
kboyle>To: megaco@ietf.org
kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
kboyle>
kboyle>
kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1)
kboyle>prior to 
kboyle>its release, and got a slight surprise.  At the end of section 6.2.1 there
kboyle>is this 
kboyle>sentence:
kboyle>
kboyle>"An MGC can only release/modify Terminations
kboyle>    and the resources that the Termination represents which it has
kboyle>    previously seized via, e.g., the Add command."
kboyle>
kboyle>It seems to me this precludes doing Modifies in the NULL context, but I've
kboyle>seen 
kboyle>various call flows that do just that.  Should we feed this back to SG 16 as 
kboyle>something that should be fixed up to conform with practice?
kboyle>
kboyle>Tom Taylor
kboyle>
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 13:39:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05074
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 13:39:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FHlNK22604
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 13:47:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHlN822601
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 13:47:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05060
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 13:38:39 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UQg-0003gL-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 13:41:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UQg-0003gI-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 13:41:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHjW822510;
	Tue, 15 Apr 2003 13:45:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHeB822355
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 13:40:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04899
	for <megaco@ietf.org>; Tue, 15 Apr 2003 13:31:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UJj-0003em-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:33:59 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UJi-0003ej-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:33:58 -0400
Received: from bulb ([10.0.1.99]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 15 Apr 2003 13:33:35 -0400
Date: Tue, 15 Apr 2003 13:33:35 -0400 (EDT)
From: Srinivasan Krishnamoorthy <ksrini@winphoria.com>
Reply-To: ksrini@winphoria.com
To: Kevin Boyle <kboyle@nortelnetworks.com>
cc: Tom-PT Taylor <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C08BE98D9@zrtpd0jq.us.nortel.com>
Message-ID: <Pine.LNX.4.21.0304151331240.3031-100000@bulb.winphoria.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 15 Apr 2003 17:33:35.0496 (UTC) FILETIME=[24807080:01C30375]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Hi,

What happens in the case where a Handoff to a redundant MGC has
happened, but the contexts where originally created by a 
primary MGC.

So, shouldn't we actually allow Subtracts from the new MGC,
as well then?

Thanks,
-Srini

On Tue, 15 Apr 2003, Kevin Boyle wrote:

kboyle>Clearly this is an error, since, for example, the MG wouldn't want a phone
kboyle>in a context just to detect off-hook.  Likewise, if that set is currently in
kboyle>Null and looking for off-hook, then the MGC may wish to stop looking for
kboyle>off-hook (for any of a number of reasons) by Modifying the term with an
kboyle>empty Events descriptor.
kboyle>
kboyle>Any objections to striking the "/modify" portion of the sentence via the IG?
kboyle>
kboyle>Kevin
kboyle>
kboyle>-----Original Message-----
kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH] 
kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
kboyle>To: megaco@ietf.org
kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
kboyle>
kboyle>
kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1)
kboyle>prior to 
kboyle>its release, and got a slight surprise.  At the end of section 6.2.1 there
kboyle>is this 
kboyle>sentence:
kboyle>
kboyle>"An MGC can only release/modify Terminations
kboyle>    and the resources that the Termination represents which it has
kboyle>    previously seized via, e.g., the Add command."
kboyle>
kboyle>It seems to me this precludes doing Modifies in the NULL context, but I've
kboyle>seen 
kboyle>various call flows that do just that.  Should we feed this back to SG 16 as 
kboyle>something that should be fixed up to conform with practice?
kboyle>
kboyle>Tom Taylor
kboyle>
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 13:43:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05209
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 13:43:28 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHon822735;
	Tue, 15 Apr 2003 13:50:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHkk822554
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 13:46:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05035
	for <megaco@ietf.org>; Tue, 15 Apr 2003 13:38:02 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UQ5-0003fv-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:40:33 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 195UQ5-0003fc-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:40:33 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FHe4A00453
	for <megaco@ietf.org>; Tue, 15 Apr 2003 13:40:04 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96A597>; Tue, 15 Apr 2003 13:40:03 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08BE9BE3@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: ksrini@winphoria.com
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
Date: Tue, 15 Apr 2003 13:39:54 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The argument can be made that the resources were previously seized via an
Add.  I will look back through some older IGs and see if I can find where
this came from...

Kevin

-----Original Message-----
From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com] 
Sent: Tuesday, April 15, 2003 1:34 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations



Hi,

What happens in the case where a Handoff to a redundant MGC has happened,
but the contexts where originally created by a 
primary MGC.

So, shouldn't we actually allow Subtracts from the new MGC,
as well then?

Thanks,
-Srini

On Tue, 15 Apr 2003, Kevin Boyle wrote:

kboyle>Clearly this is an error, since, for example, the MG wouldn't 
kboyle>want a phone in a context just to detect off-hook.  Likewise, if 
kboyle>that set is currently in Null and looking for off-hook, then the 
kboyle>MGC may wish to stop looking for off-hook (for any of a number of 
kboyle>reasons) by Modifying the term with an empty Events descriptor.
kboyle>
kboyle>Any objections to striking the "/modify" portion of the sentence 
kboyle>via the IG?
kboyle>
kboyle>Kevin
kboyle>
kboyle>-----Original Message-----
kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
kboyle>To: megaco@ietf.org
kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
kboyle>
kboyle>
kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. 
kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At 
kboyle>the end of section 6.2.1 there is this
kboyle>sentence:
kboyle>
kboyle>"An MGC can only release/modify Terminations
kboyle>    and the resources that the Termination represents which it has
kboyle>    previously seized via, e.g., the Add command."
kboyle>
kboyle>It seems to me this precludes doing Modifies in the NULL context, 
kboyle>but I've seen various call flows that do just that.  Should we 
kboyle>feed this back to SG 16 as something that should be fixed up to 
kboyle>conform with practice?
kboyle>
kboyle>Tom Taylor
kboyle>
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 13:44:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05252
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 13:44:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3FHquN22860
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 13:52:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHqu822857
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 13:52:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05240
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 13:44:11 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UW3-0003iR-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 13:46:43 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UVx-0003iN-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 13:46:37 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHon822735;
	Tue, 15 Apr 2003 13:50:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FHkk822554
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 13:46:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05035
	for <megaco@ietf.org>; Tue, 15 Apr 2003 13:38:02 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195UQ5-0003fv-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:40:33 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 195UQ5-0003fc-00
	for megaco@ietf.org; Tue, 15 Apr 2003 13:40:33 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3FHe4A00453
	for <megaco@ietf.org>; Tue, 15 Apr 2003 13:40:04 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96A597>; Tue, 15 Apr 2003 13:40:03 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08BE9BE3@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: ksrini@winphoria.com
Cc: "Tom-PT Taylor" <taylor@nortelnetworks.com>, megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
Date: Tue, 15 Apr 2003 13:39:54 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

The argument can be made that the resources were previously seized via an
Add.  I will look back through some older IGs and see if I can find where
this came from...

Kevin

-----Original Message-----
From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com] 
Sent: Tuesday, April 15, 2003 1:34 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations



Hi,

What happens in the case where a Handoff to a redundant MGC has happened,
but the contexts where originally created by a 
primary MGC.

So, shouldn't we actually allow Subtracts from the new MGC,
as well then?

Thanks,
-Srini

On Tue, 15 Apr 2003, Kevin Boyle wrote:

kboyle>Clearly this is an error, since, for example, the MG wouldn't 
kboyle>want a phone in a context just to detect off-hook.  Likewise, if 
kboyle>that set is currently in Null and looking for off-hook, then the 
kboyle>MGC may wish to stop looking for off-hook (for any of a number of 
kboyle>reasons) by Modifying the term with an empty Events descriptor.
kboyle>
kboyle>Any objections to striking the "/modify" portion of the sentence 
kboyle>via the IG?
kboyle>
kboyle>Kevin
kboyle>
kboyle>-----Original Message-----
kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
kboyle>To: megaco@ietf.org
kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
kboyle>
kboyle>
kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. 
kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At 
kboyle>the end of section 6.2.1 there is this
kboyle>sentence:
kboyle>
kboyle>"An MGC can only release/modify Terminations
kboyle>    and the resources that the Termination represents which it has
kboyle>    previously seized via, e.g., the Add command."
kboyle>
kboyle>It seems to me this precludes doing Modifies in the NULL context, 
kboyle>but I've seen various call flows that do just that.  Should we 
kboyle>feed this back to SG 16 as something that should be fixed up to 
kboyle>conform with practice?
kboyle>
kboyle>Tom Taylor
kboyle>
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>Megaco@ietf.org
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 15 22:03:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19733
	for <megaco-archive@lists.ietf.org>; Tue, 15 Apr 2003 22:03:06 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2AM825627;
	Tue, 15 Apr 2003 22:10:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G26G824634
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 22:06:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19622
	for <megaco@ietf.org>; Tue, 15 Apr 2003 21:57:21 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195cDJ-0005xV-00
	for megaco@ietf.org; Tue, 15 Apr 2003 21:59:53 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 195cDI-0005xM-00
	for megaco@ietf.org; Tue, 15 Apr 2003 21:59:52 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3G1vbK20437;
	Wed, 16 Apr 2003 11:57:37 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3G1xuD09879;
	Wed, 16 Apr 2003 11:59:56 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.254]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 24N94JJ4; Wed, 16 Apr 2003 11:59:53 +1000
Message-ID: <3E9CA180.3A9B7275@ericsson.com.au>
Date: Wed, 16 Apr 2003 10:19:12 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: ksrini@winphoria.com, Tom-PT Taylor <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations
References: <ABA227A15B80D511BD1A00508BF93A1C08BE9BE3@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day Kevin,

The text has been there from way back when we determined H.248 version 1. It
seems noone has paid attention to it since then!!!

How about adding:
An MGC can only release/modify terminations and the resources that the
termination represents <<which are in the NULL context or>> which >>delete:it
has<< <<have been>> previously seized via, e.g., the Add command.

The removal of "it has" should cover the servicechange concern.

Regards, Christian

Kevin Boyle wrote:
> 
> The argument can be made that the resources were previously seized via an
> Add.  I will look back through some older IGs and see if I can find where
> this came from...
> 
> Kevin
> 
> -----Original Message-----
> From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com]
> Sent: Tuesday, April 15, 2003 1:34 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Restriction on Modification Of Terminations
> 
> Hi,
> 
> What happens in the case where a Handoff to a redundant MGC has happened,
> but the contexts where originally created by a
> primary MGC.
> 
> So, shouldn't we actually allow Subtracts from the new MGC,
> as well then?
> 
> Thanks,
> -Srini
> 
> On Tue, 15 Apr 2003, Kevin Boyle wrote:
> 
> kboyle>Clearly this is an error, since, for example, the MG wouldn't
> kboyle>want a phone in a context just to detect off-hook.  Likewise, if
> kboyle>that set is currently in Null and looking for off-hook, then the
> kboyle>MGC may wish to stop looking for off-hook (for any of a number of
> kboyle>reasons) by Modifying the term with an empty Events descriptor.
> kboyle>
> kboyle>Any objections to striking the "/modify" portion of the sentence
> kboyle>via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>-----Original Message-----
> kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> kboyle>To: megaco@ietf.org
> kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> kboyle>
> kboyle>
> kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e.
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At
> kboyle>the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>"An MGC can only release/modify Terminations
> kboyle>    and the resources that the Termination represents which it has
> kboyle>    previously seized via, e.g., the Add command."
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL context,
> kboyle>but I've seen various call flows that do just that.  Should we
> kboyle>feed this back to SG 16 as something that should be fixed up to
> kboyle>conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org
> kboyle>https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 15 22:04:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19803
	for <megaco-archive@odin.ietf.org>; Tue, 15 Apr 2003 22:04:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3G2Cb325757
	for megaco-archive@odin.ietf.org; Tue, 15 Apr 2003 22:12:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2Cb825754
	for <megaco-web-archive@optimus.ietf.org>; Tue, 15 Apr 2003 22:12:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19766
	for <megaco-web-archive@ietf.org>; Tue, 15 Apr 2003 22:03:43 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195cJR-0005yZ-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 22:06:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195cJR-0005yW-00
	for megaco-web-archive@ietf.org; Tue, 15 Apr 2003 22:06:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2AM825627;
	Tue, 15 Apr 2003 22:10:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G26G824634
	for <megaco@optimus.ietf.org>; Tue, 15 Apr 2003 22:06:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19622
	for <megaco@ietf.org>; Tue, 15 Apr 2003 21:57:21 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195cDJ-0005xV-00
	for megaco@ietf.org; Tue, 15 Apr 2003 21:59:53 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 195cDI-0005xM-00
	for megaco@ietf.org; Tue, 15 Apr 2003 21:59:52 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3G1vbK20437;
	Wed, 16 Apr 2003 11:57:37 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3G1xuD09879;
	Wed, 16 Apr 2003 11:59:56 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.254]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 24N94JJ4; Wed, 16 Apr 2003 11:59:53 +1000
Message-ID: <3E9CA180.3A9B7275@ericsson.com.au>
Date: Wed, 16 Apr 2003 10:19:12 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: ksrini@winphoria.com, Tom-PT Taylor <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations
References: <ABA227A15B80D511BD1A00508BF93A1C08BE9BE3@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day Kevin,

The text has been there from way back when we determined H.248 version 1. It
seems noone has paid attention to it since then!!!

How about adding:
An MGC can only release/modify terminations and the resources that the
termination represents <<which are in the NULL context or>> which >>delete:it
has<< <<have been>> previously seized via, e.g., the Add command.

The removal of "it has" should cover the servicechange concern.

Regards, Christian

Kevin Boyle wrote:
> 
> The argument can be made that the resources were previously seized via an
> Add.  I will look back through some older IGs and see if I can find where
> this came from...
> 
> Kevin
> 
> -----Original Message-----
> From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com]
> Sent: Tuesday, April 15, 2003 1:34 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Restriction on Modification Of Terminations
> 
> Hi,
> 
> What happens in the case where a Handoff to a redundant MGC has happened,
> but the contexts where originally created by a
> primary MGC.
> 
> So, shouldn't we actually allow Subtracts from the new MGC,
> as well then?
> 
> Thanks,
> -Srini
> 
> On Tue, 15 Apr 2003, Kevin Boyle wrote:
> 
> kboyle>Clearly this is an error, since, for example, the MG wouldn't
> kboyle>want a phone in a context just to detect off-hook.  Likewise, if
> kboyle>that set is currently in Null and looking for off-hook, then the
> kboyle>MGC may wish to stop looking for off-hook (for any of a number of
> kboyle>reasons) by Modifying the term with an empty Events descriptor.
> kboyle>
> kboyle>Any objections to striking the "/modify" portion of the sentence
> kboyle>via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>-----Original Message-----
> kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> kboyle>To: megaco@ietf.org
> kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> kboyle>
> kboyle>
> kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e.
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At
> kboyle>the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>"An MGC can only release/modify Terminations
> kboyle>    and the resources that the Termination represents which it has
> kboyle>    previously seized via, e.g., the Add command."
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL context,
> kboyle>but I've seen various call flows that do just that.  Should we
> kboyle>feed this back to SG 16 as something that should be fixed up to
> kboyle>conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org
> kboyle>https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 16 12:29:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07669
	for <megaco-archive@lists.ietf.org>; Wed, 16 Apr 2003 12:29:04 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GGap802634;
	Wed, 16 Apr 2003 12:36:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GGAT801472
	for <megaco@optimus.ietf.org>; Wed, 16 Apr 2003 12:10:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06833
	for <megaco@ietf.org>; Wed, 16 Apr 2003 12:01:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195pO0-0002OK-00
	for megaco@ietf.org; Wed, 16 Apr 2003 12:03:48 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195pNy-0002OH-00
	for megaco@ietf.org; Wed, 16 Apr 2003 12:03:47 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXCVG>; Wed, 16 Apr 2003 11:58:31 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA15D685@wench.telica.com>
From: Praveen Shivaswamy <praveen@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>,
        Praveen Shivaswamy
	 <praveen@telica.com>
Date: Wed, 16 Apr 2003 11:58:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] (no subject)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

When trying to model GR-303 into the MG/MGC architecture i'm having
hard time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is peeled
from the MG
    and backhaul to the MGC. Thats fine. But a resulting side effect is that
i'm not
    finding any reference that describes how to take care of this problem.

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line and
CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for calls
originating
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0).

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2 gets
the
   same DS0, we need to do GS signaling and so on and so forth. This calls
for
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do you
plan
   achieve this?

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02.
   In all the places it is assumed that the signaling model is
pre-provisioned. In case
   of GR-303, signaling model can be logically tied to a CRV and not a DS0
(as done
   for regular CAS lines/trunks). MG will not be provisioned with any CRV
information.

2) Also should a GR303 termination and a regular CAS termination be
addressed
    alike? Both are plain vanilla DS0's

3) Once we are done with the call there should be a way to shut off the RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting
    the channel(s) into IDLE state.

Appreciate your response.


Praveen Shivaswamy
Telica Inc

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 16 12:30:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07718
	for <megaco-archive@odin.ietf.org>; Wed, 16 Apr 2003 12:30:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GGcsW03563
	for megaco-archive@odin.ietf.org; Wed, 16 Apr 2003 12:38:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GGcs803560
	for <megaco-web-archive@optimus.ietf.org>; Wed, 16 Apr 2003 12:38:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07703
	for <megaco-web-archive@ietf.org>; Wed, 16 Apr 2003 12:29:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195ppU-0002Wg-00
	for megaco-web-archive@ietf.org; Wed, 16 Apr 2003 12:32:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195ppT-0002Wc-00
	for megaco-web-archive@ietf.org; Wed, 16 Apr 2003 12:32:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GGap802634;
	Wed, 16 Apr 2003 12:36:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GGAT801472
	for <megaco@optimus.ietf.org>; Wed, 16 Apr 2003 12:10:29 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06833
	for <megaco@ietf.org>; Wed, 16 Apr 2003 12:01:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195pO0-0002OK-00
	for megaco@ietf.org; Wed, 16 Apr 2003 12:03:48 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195pNy-0002OH-00
	for megaco@ietf.org; Wed, 16 Apr 2003 12:03:47 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXCVG>; Wed, 16 Apr 2003 11:58:31 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA15D685@wench.telica.com>
From: Praveen Shivaswamy <praveen@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>,
        Praveen Shivaswamy
	 <praveen@telica.com>
Date: Wed, 16 Apr 2003 11:58:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] (no subject)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

When trying to model GR-303 into the MG/MGC architecture i'm having
hard time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is peeled
from the MG
    and backhaul to the MGC. Thats fine. But a resulting side effect is that
i'm not
    finding any reference that describes how to take care of this problem.

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line and
CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for calls
originating
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0).

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2 gets
the
   same DS0, we need to do GS signaling and so on and so forth. This calls
for
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do you
plan
   achieve this?

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02.
   In all the places it is assumed that the signaling model is
pre-provisioned. In case
   of GR-303, signaling model can be logically tied to a CRV and not a DS0
(as done
   for regular CAS lines/trunks). MG will not be provisioned with any CRV
information.

2) Also should a GR303 termination and a regular CAS termination be
addressed
    alike? Both are plain vanilla DS0's

3) Once we are done with the call there should be a way to shut off the RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting
    the channel(s) into IDLE state.

Appreciate your response.


Praveen Shivaswamy
Telica Inc

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 16 13:23:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08970
	for <megaco-archive@lists.ietf.org>; Wed, 16 Apr 2003 13:23:25 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHVD806617;
	Wed, 16 Apr 2003 13:31:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHSH806519
	for <megaco@optimus.ietf.org>; Wed, 16 Apr 2003 13:28:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08853
	for <megaco@ietf.org>; Wed, 16 Apr 2003 13:19:04 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195qbG-0002j7-00
	for megaco@ietf.org; Wed, 16 Apr 2003 13:21:34 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 195qbG-0002j4-00
	for megaco@ietf.org; Wed, 16 Apr 2003 13:21:34 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GHLCo04454
	for <megaco@ietf.org>; Wed, 16 Apr 2003 13:21:12 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96BPDT>; Wed, 16 Apr 2003 13:21:13 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08C3905D@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Praveen Shivaswamy <praveen@telica.com>,
        "'megaco@ietf.org'"
	 <megaco@ietf.org>
Subject: RE: [Megaco] (no subject)
Date: Wed, 16 Apr 2003 13:21:12 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline.  [KJBII]

Remember, GR303 is NOT trunks -- it's lines.  Taking packages that are built
specifically for trunking and trying to shoehorn GR303 into the model will
most certainly be difficult at best.

Kevin

-----Original Message-----
From: Praveen Shivaswamy [mailto:praveen@telica.com] 
Sent: Wednesday, April 16, 2003 11:59 AM
To: 'megaco@ietf.org'; Praveen Shivaswamy
Subject: [Megaco] (no subject)


When trying to model GR-303 into the MG/MGC architecture i'm having hard
time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is peeled
from the MG
    and backhaul to the MGC. Thats fine. But a resulting side effect is that
i'm not
    finding any reference that describes how to take care of this problem.

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line and
CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for calls
originating
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0).

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2 gets
the
   same DS0, we need to do GS signaling and so on and so forth. This calls
for
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do you
plan
   achieve this?

[KJBII] For GR303, call control signalling should be backhauled.  Would this
not go over the SCTP link?

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02.
   In all the places it is assumed that the signaling model is
pre-provisioned. In case
   of GR-303, signaling model can be logically tied to a CRV and not a DS0
(as done
   for regular CAS lines/trunks). MG will not be provisioned with any CRV
information.

[KJBII] I know of no CAS lines -- CAS is for trunking.  I know of no
handsets that generate MF digits.  Therefore, it seems that this should be
modeled as lines, and whatever trunking is present should be handled
independently.

2) Also should a GR303 termination and a regular CAS termination be
addressed
    alike? Both are plain vanilla DS0's

[KJBII] By addressed, do you mean network addressing for bearer?  If so, it
depends upon you implementation.  If you mean term names, then all terms
must have unique names within the MG.

3) Once we are done with the call there should be a way to shut off the RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting
    the channel(s) into IDLE state.

[KJBII] Subtract the term.

Appreciate your response.


Praveen Shivaswamy
Telica Inc

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 16 13:24:29 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09005
	for <megaco-archive@odin.ietf.org>; Wed, 16 Apr 2003 13:24:29 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GHXBE06704
	for megaco-archive@odin.ietf.org; Wed, 16 Apr 2003 13:33:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHXB806701
	for <megaco-web-archive@optimus.ietf.org>; Wed, 16 Apr 2003 13:33:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09002
	for <megaco-web-archive@ietf.org>; Wed, 16 Apr 2003 13:23:58 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195qg0-0002kI-00
	for megaco-web-archive@ietf.org; Wed, 16 Apr 2003 13:26:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195qg0-0002kF-00
	for megaco-web-archive@ietf.org; Wed, 16 Apr 2003 13:26:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHVD806617;
	Wed, 16 Apr 2003 13:31:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GHSH806519
	for <megaco@optimus.ietf.org>; Wed, 16 Apr 2003 13:28:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08853
	for <megaco@ietf.org>; Wed, 16 Apr 2003 13:19:04 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195qbG-0002j7-00
	for megaco@ietf.org; Wed, 16 Apr 2003 13:21:34 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 195qbG-0002j4-00
	for megaco@ietf.org; Wed, 16 Apr 2003 13:21:34 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GHLCo04454
	for <megaco@ietf.org>; Wed, 16 Apr 2003 13:21:12 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96BPDT>; Wed, 16 Apr 2003 13:21:13 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08C3905D@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Praveen Shivaswamy <praveen@telica.com>,
        "'megaco@ietf.org'"
	 <megaco@ietf.org>
Subject: RE: [Megaco] (no subject)
Date: Wed, 16 Apr 2003 13:21:12 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline.  [KJBII]

Remember, GR303 is NOT trunks -- it's lines.  Taking packages that are built
specifically for trunking and trying to shoehorn GR303 into the model will
most certainly be difficult at best.

Kevin

-----Original Message-----
From: Praveen Shivaswamy [mailto:praveen@telica.com] 
Sent: Wednesday, April 16, 2003 11:59 AM
To: 'megaco@ietf.org'; Praveen Shivaswamy
Subject: [Megaco] (no subject)


When trying to model GR-303 into the MG/MGC architecture i'm having hard
time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is peeled
from the MG
    and backhaul to the MGC. Thats fine. But a resulting side effect is that
i'm not
    finding any reference that describes how to take care of this problem.

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line and
CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for calls
originating
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0).

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2 gets
the
   same DS0, we need to do GS signaling and so on and so forth. This calls
for
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do you
plan
   achieve this?

[KJBII] For GR303, call control signalling should be backhauled.  Would this
not go over the SCTP link?

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02.
   In all the places it is assumed that the signaling model is
pre-provisioned. In case
   of GR-303, signaling model can be logically tied to a CRV and not a DS0
(as done
   for regular CAS lines/trunks). MG will not be provisioned with any CRV
information.

[KJBII] I know of no CAS lines -- CAS is for trunking.  I know of no
handsets that generate MF digits.  Therefore, it seems that this should be
modeled as lines, and whatever trunking is present should be handled
independently.

2) Also should a GR303 termination and a regular CAS termination be
addressed
    alike? Both are plain vanilla DS0's

[KJBII] By addressed, do you mean network addressing for bearer?  If so, it
depends upon you implementation.  If you mean term names, then all terms
must have unique names within the MG.

3) Once we are done with the call there should be a way to shut off the RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting
    the channel(s) into IDLE state.

[KJBII] Subtract the term.

Appreciate your response.


Praveen Shivaswamy
Telica Inc

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 16 14:30:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10997
	for <megaco-archive@lists.ietf.org>; Wed, 16 Apr 2003 14:30:55 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GId3812456;
	Wed, 16 Apr 2003 14:39:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIQl810962
	for <megaco@optimus.ietf.org>; Wed, 16 Apr 2003 14:26:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10667
	for <megaco@ietf.org>; Wed, 16 Apr 2003 14:17:33 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195rVr-00030V-00
	for megaco@ietf.org; Wed, 16 Apr 2003 14:20:03 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195rVq-00030S-00
	for megaco@ietf.org; Wed, 16 Apr 2003 14:20:02 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXD3H>; Wed, 16 Apr 2003 14:14:46 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA15D687@wench.telica.com>
From: Praveen Shivaswamy <praveen@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Praveen Shivaswamy
	 <praveen@telica.com>,
        "'megaco@ietf.org'" <megaco@ietf.org>
Cc: John Hutchins <jhutchins@telica.com>
Subject: RE: [Megaco] (no subject)
Date: Wed, 16 Apr 2003 14:14:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30444.0F1D5A58"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C30444.0F1D5A58
Content-Type: text/plain;
	charset="iso-8859-1"

Kevin,
 
thanks for the quick response. However here is my question.
 
Basic Analog line supervison package + Enhanced Analog line package
address the Loop start signaling requirements (as commented in
http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-01.txt
<http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-01.txt>
). Which package addressess
other line side signaling models, like Ground start/Loop reverse battery
etc.
 
Also please see my inline response.

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, April 16, 2003 1:21 PM
To: Praveen Shivaswamy; 'megaco@ietf.org'
Subject: RE: [Megaco] (no subject)



Comments inline.  [KJBII] 

Remember, GR303 is NOT trunks -- it's lines.  Taking packages that are built
specifically for trunking and trying to shoehorn GR303 into the model will
most certainly be difficult at best.

Kevin 

-----Original Message----- 
From: Praveen Shivaswamy [ mailto:praveen@telica.com
<mailto:praveen@telica.com> ] 
Sent: Wednesday, April 16, 2003 11:59 AM 
To: 'megaco@ietf.org'; Praveen Shivaswamy 
Subject: [Megaco] (no subject) 


When trying to model GR-303 into the MG/MGC architecture i'm having hard
time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is peeled
from the MG 
    and backhaul to the MGC. Thats fine. But a resulting side effect is that
i'm not 
    finding any reference that describes how to take care of this problem. 

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line and
CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for calls
originating 
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0). 

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2 gets
the 
   same DS0, we need to do GS signaling and so on and so forth. This calls
for 
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do you
plan 
   achieve this? 

[KJBII] For GR303, call control signalling should be backhauled.  Would this
not go over the SCTP link? 
[Praveen Shivaswamy] Yes. That was my first statement. 

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02. 
   In all the places it is assumed that the signaling model is
pre-provisioned. In case 
   of GR-303, signaling model can be logically tied to a CRV and not a DS0
(as done 
   for regular CAS lines/trunks). MG will not be provisioned with any CRV
information. 

[KJBII] I know of no CAS lines -- CAS is for trunking.  I know of no
handsets that generate MF digits.  Therefore, it seems that this should be
modeled as lines, and whatever trunking is present should be handled
independently.
[Praveen Shivaswamy] I was referring to a scenario where we can have CAS
lines coming from an IAD (channel bank) to the MG. These would be considered
as lines. 

2) Also should a GR303 termination and a regular CAS termination be
addressed 
    alike? Both are plain vanilla DS0's 

[KJBII] By addressed, do you mean network addressing for bearer?  If so, it
depends upon you implementation.  If you mean term names, then all terms
must have unique names within the MG.

3) Once we are done with the call there should be a way to shut off the RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting 
    the channel(s) into IDLE state. 

[KJBII] Subtract the term. 

Appreciate your response. 


Praveen Shivaswamy 
Telica Inc 

_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  


------_=_NextPart_001_01C30444.0F1D5A58
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [Megaco] (no subject)</TITLE>

<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1>thanks for the quick response. However here is my=20
question.</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1>Basic=20
Analog line supervison package + Enhanced Analog line=20
package</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1>address the Loop start signaling requirements (as commented=20
in</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkg=
s-01.txt">http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalp=
kgs-01.txt</A>).=20
Which package addressess</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1>other=20
line side signaling models, like Ground start/Loop reverse battery=20
etc.</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1>Also=20
please see my inline response.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, April =
16, 2003=20
  1:21 PM<BR><B>To:</B> Praveen Shivaswamy; =
'megaco@ietf.org'<BR><B>Subject:</B>=20
  RE: [Megaco] (no subject)<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Comments inline.&nbsp; [KJBII]</FONT> </P>
  <P><FONT size=3D2>Remember, GR303 is NOT trunks -- it's lines.&nbsp; =
Taking=20
  packages that are built specifically for trunking and trying to =
shoehorn GR303=20
  into the model will most certainly be difficult at best.</FONT></P>
  <P><FONT size=3D2>Kevin</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Praveen Shivaswamy [<A=20
  href=3D"mailto:praveen@telica.com">mailto:praveen@telica.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Wednesday, April 16, 2003 11:59 =
AM</FONT>=20
  <BR><FONT size=3D2>To: 'megaco@ietf.org'; Praveen Shivaswamy</FONT> =
<BR><FONT=20
  size=3D2>Subject: [Megaco] (no subject)</FONT> </P><BR>
  <P><FONT size=3D2>When trying to model GR-303 into the MG/MGC =
architecture i'm=20
  having hard time trying to solve the problem stated below. Please=20
  advice,</FONT></P>
  <P><FONT size=3D2>1) As specified in =
draft-ietf-sigtran-gr303ua-00.txt,=20
  TMC/EOC/PPS is peeled from the MG</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  and backhaul to the MGC. Thats fine. But a resulting side effect is =
that i'm=20
  not</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; finding any =
reference that=20
  describes how to take care of this problem.</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; Assume CRV 1 is a loop start line and =
CRV 2 is a=20
  ground start line and CRV 3 is </FONT><BR><FONT size=3D2>&nbsp;&nbsp; =
loop=20
  reverse battery line. Let us say we have DS0-1 allocated for calls=20
  originating</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; from CRV 1,2 and 3 =
(each done=20
  seperately, but gets the same DS0).</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; For CRV 1 we need to do LS signaling =
on the DS0,=20
  later when CRV 2 gets the</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; same =
DS0, we=20
  need to do GS signaling and so on and so forth. This calls for</FONT> =

  <BR><FONT size=3D2>&nbsp;&nbsp; applying the signaling model (like =
LS/GS/LRB=20
  etc) on the fly. How do you plan</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; achieve=20
  this?</FONT> </P>
  <P><FONT size=3D2>[KJBII] For GR303, call control signalling should =
be=20
  backhauled.&nbsp; Would this not go over the SCTP link?</FONT> =
<BR><SPAN=20
  class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>[Praveen=20
  Shivaswamy]&nbsp;Yes. That was my first =
statement.&nbsp;</FONT></SPAN></P>
  <P><FONT size=3D2>&nbsp;&nbsp; This is not addressed in the rfc-3015 =
or=20
  draft-manyfolks-megaco-caspackage-02.</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; In=20
  all the places it is assumed that the signaling model is =
pre-provisioned. In=20
  case</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; of GR-303, signaling =
model can be=20
  logically tied to a CRV and not a DS0 (as done</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; for regular CAS lines/trunks). MG will not be =
provisioned=20
  with any CRV information.</FONT> </P>
  <P><FONT size=3D2>[KJBII] I know of no CAS lines -- CAS is for =
trunking.&nbsp; I=20
  know of no handsets that generate MF digits.&nbsp; Therefore, it =
seems that=20
  this should be modeled as lines, and whatever trunking is present =
should be=20
  handled independently.<BR></FONT><SPAN =
class=3D040331218-16042003><FONT=20
  face=3DTahoma color=3D#0000ff size=3D1>[Praveen Shivaswamy]&nbsp;I =
was referring to=20
  a scenario where we can&nbsp;have CAS lines coming =
</FONT></SPAN><SPAN=20
  class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>from an IAD=20
  (channel bank)&nbsp;to the MG. These would be&nbsp;considered as=20
  lines.&nbsp;</FONT></SPAN></P>
  <P><FONT size=3D2>2) Also should a GR303 termination and a regular =
CAS=20
  termination be addressed</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
alike?=20
  Both are plain vanilla DS0's</FONT> </P>
  <P><FONT size=3D2>[KJBII] By addressed, do you mean network =
addressing for=20
  bearer?&nbsp; If so, it depends upon you implementation.&nbsp; If you =
mean=20
  term names, then all terms must have unique names within the =
MG.</FONT></P>
  <P><FONT size=3D2>3) Once we are done with the call there should be a =
way to=20
  shut off the RBS </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
  detection/insertion&nbsp; from the MG. How can the MG be instructed =
about=20
  putting</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; the channel(s) =
into IDLE=20
  state.</FONT> </P>
  <P><FONT size=3D2>[KJBII] Subtract the term.</FONT> </P>
  <P><FONT size=3D2>Appreciate your response.</FONT> </P><BR>
  <P><FONT size=3D2>Praveen Shivaswamy</FONT> <BR><FONT size=3D2>Telica =
Inc</FONT>=20
  </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT>=
=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C30444.0F1D5A58--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 16 14:32:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11088
	for <megaco-archive@odin.ietf.org>; Wed, 16 Apr 2003 14:32:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3GIeiO12622
	for megaco-archive@odin.ietf.org; Wed, 16 Apr 2003 14:40:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIei812619
	for <megaco-web-archive@optimus.ietf.org>; Wed, 16 Apr 2003 14:40:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11051
	for <megaco-web-archive@ietf.org>; Wed, 16 Apr 2003 14:31:29 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195rjL-00034Q-00
	for megaco-web-archive@ietf.org; Wed, 16 Apr 2003 14:33:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 195rjL-00034N-00
	for megaco-web-archive@ietf.org; Wed, 16 Apr 2003 14:33:59 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GId3812456;
	Wed, 16 Apr 2003 14:39:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIQl810962
	for <megaco@optimus.ietf.org>; Wed, 16 Apr 2003 14:26:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10667
	for <megaco@ietf.org>; Wed, 16 Apr 2003 14:17:33 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 195rVr-00030V-00
	for megaco@ietf.org; Wed, 16 Apr 2003 14:20:03 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 195rVq-00030S-00
	for megaco@ietf.org; Wed, 16 Apr 2003 14:20:02 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXD3H>; Wed, 16 Apr 2003 14:14:46 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA15D687@wench.telica.com>
From: Praveen Shivaswamy <praveen@telica.com>
To: "'Kevin Boyle'" <kboyle@nortelnetworks.com>,
        Praveen Shivaswamy
	 <praveen@telica.com>,
        "'megaco@ietf.org'" <megaco@ietf.org>
Cc: John Hutchins <jhutchins@telica.com>
Subject: RE: [Megaco] (no subject)
Date: Wed, 16 Apr 2003 14:14:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30444.0F1D5A58"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C30444.0F1D5A58
Content-Type: text/plain;
	charset="iso-8859-1"

Kevin,
 
thanks for the quick response. However here is my question.
 
Basic Analog line supervison package + Enhanced Analog line package
address the Loop start signaling requirements (as commented in
http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-01.txt
<http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-01.txt>
). Which package addressess
other line side signaling models, like Ground start/Loop reverse battery
etc.
 
Also please see my inline response.

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, April 16, 2003 1:21 PM
To: Praveen Shivaswamy; 'megaco@ietf.org'
Subject: RE: [Megaco] (no subject)



Comments inline.  [KJBII] 

Remember, GR303 is NOT trunks -- it's lines.  Taking packages that are built
specifically for trunking and trying to shoehorn GR303 into the model will
most certainly be difficult at best.

Kevin 

-----Original Message----- 
From: Praveen Shivaswamy [ mailto:praveen@telica.com
<mailto:praveen@telica.com> ] 
Sent: Wednesday, April 16, 2003 11:59 AM 
To: 'megaco@ietf.org'; Praveen Shivaswamy 
Subject: [Megaco] (no subject) 


When trying to model GR-303 into the MG/MGC architecture i'm having hard
time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is peeled
from the MG 
    and backhaul to the MGC. Thats fine. But a resulting side effect is that
i'm not 
    finding any reference that describes how to take care of this problem. 

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line and
CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for calls
originating 
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0). 

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2 gets
the 
   same DS0, we need to do GS signaling and so on and so forth. This calls
for 
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do you
plan 
   achieve this? 

[KJBII] For GR303, call control signalling should be backhauled.  Would this
not go over the SCTP link? 
[Praveen Shivaswamy] Yes. That was my first statement. 

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02. 
   In all the places it is assumed that the signaling model is
pre-provisioned. In case 
   of GR-303, signaling model can be logically tied to a CRV and not a DS0
(as done 
   for regular CAS lines/trunks). MG will not be provisioned with any CRV
information. 

[KJBII] I know of no CAS lines -- CAS is for trunking.  I know of no
handsets that generate MF digits.  Therefore, it seems that this should be
modeled as lines, and whatever trunking is present should be handled
independently.
[Praveen Shivaswamy] I was referring to a scenario where we can have CAS
lines coming from an IAD (channel bank) to the MG. These would be considered
as lines. 

2) Also should a GR303 termination and a regular CAS termination be
addressed 
    alike? Both are plain vanilla DS0's 

[KJBII] By addressed, do you mean network addressing for bearer?  If so, it
depends upon you implementation.  If you mean term names, then all terms
must have unique names within the MG.

3) Once we are done with the call there should be a way to shut off the RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting 
    the channel(s) into IDLE state. 

[KJBII] Subtract the term. 

Appreciate your response. 


Praveen Shivaswamy 
Telica Inc 

_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  


------_=_NextPart_001_01C30444.0F1D5A58
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [Megaco] (no subject)</TITLE>

<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1>Kevin,</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1>thanks for the quick response. However here is my=20
question.</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1>Basic=20
Analog line supervison package + Enhanced Analog line=20
package</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1>address the Loop start signaling requirements (as commented=20
in</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkg=
s-01.txt">http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalp=
kgs-01.txt</A>).=20
Which package addressess</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1>other=20
line side signaling models, like Ground start/Loop reverse battery=20
etc.</FONT></SPAN></DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
size=3D1></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1>Also=20
please see my inline response.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Kevin Boyle=20
  [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, April =
16, 2003=20
  1:21 PM<BR><B>To:</B> Praveen Shivaswamy; =
'megaco@ietf.org'<BR><B>Subject:</B>=20
  RE: [Megaco] (no subject)<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Comments inline.&nbsp; [KJBII]</FONT> </P>
  <P><FONT size=3D2>Remember, GR303 is NOT trunks -- it's lines.&nbsp; =
Taking=20
  packages that are built specifically for trunking and trying to =
shoehorn GR303=20
  into the model will most certainly be difficult at best.</FONT></P>
  <P><FONT size=3D2>Kevin</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Praveen Shivaswamy [<A=20
  href=3D"mailto:praveen@telica.com">mailto:praveen@telica.com</A>]=20
  </FONT><BR><FONT size=3D2>Sent: Wednesday, April 16, 2003 11:59 =
AM</FONT>=20
  <BR><FONT size=3D2>To: 'megaco@ietf.org'; Praveen Shivaswamy</FONT> =
<BR><FONT=20
  size=3D2>Subject: [Megaco] (no subject)</FONT> </P><BR>
  <P><FONT size=3D2>When trying to model GR-303 into the MG/MGC =
architecture i'm=20
  having hard time trying to solve the problem stated below. Please=20
  advice,</FONT></P>
  <P><FONT size=3D2>1) As specified in =
draft-ietf-sigtran-gr303ua-00.txt,=20
  TMC/EOC/PPS is peeled from the MG</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  and backhaul to the MGC. Thats fine. But a resulting side effect is =
that i'm=20
  not</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; finding any =
reference that=20
  describes how to take care of this problem.</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; Assume CRV 1 is a loop start line and =
CRV 2 is a=20
  ground start line and CRV 3 is </FONT><BR><FONT size=3D2>&nbsp;&nbsp; =
loop=20
  reverse battery line. Let us say we have DS0-1 allocated for calls=20
  originating</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; from CRV 1,2 and 3 =
(each done=20
  seperately, but gets the same DS0).</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp; For CRV 1 we need to do LS signaling =
on the DS0,=20
  later when CRV 2 gets the</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; same =
DS0, we=20
  need to do GS signaling and so on and so forth. This calls for</FONT> =

  <BR><FONT size=3D2>&nbsp;&nbsp; applying the signaling model (like =
LS/GS/LRB=20
  etc) on the fly. How do you plan</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; achieve=20
  this?</FONT> </P>
  <P><FONT size=3D2>[KJBII] For GR303, call control signalling should =
be=20
  backhauled.&nbsp; Would this not go over the SCTP link?</FONT> =
<BR><SPAN=20
  class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>[Praveen=20
  Shivaswamy]&nbsp;Yes. That was my first =
statement.&nbsp;</FONT></SPAN></P>
  <P><FONT size=3D2>&nbsp;&nbsp; This is not addressed in the rfc-3015 =
or=20
  draft-manyfolks-megaco-caspackage-02.</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; In=20
  all the places it is assumed that the signaling model is =
pre-provisioned. In=20
  case</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; of GR-303, signaling =
model can be=20
  logically tied to a CRV and not a DS0 (as done</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; for regular CAS lines/trunks). MG will not be =
provisioned=20
  with any CRV information.</FONT> </P>
  <P><FONT size=3D2>[KJBII] I know of no CAS lines -- CAS is for =
trunking.&nbsp; I=20
  know of no handsets that generate MF digits.&nbsp; Therefore, it =
seems that=20
  this should be modeled as lines, and whatever trunking is present =
should be=20
  handled independently.<BR></FONT><SPAN =
class=3D040331218-16042003><FONT=20
  face=3DTahoma color=3D#0000ff size=3D1>[Praveen Shivaswamy]&nbsp;I =
was referring to=20
  a scenario where we can&nbsp;have CAS lines coming =
</FONT></SPAN><SPAN=20
  class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>from an IAD=20
  (channel bank)&nbsp;to the MG. These would be&nbsp;considered as=20
  lines.&nbsp;</FONT></SPAN></P>
  <P><FONT size=3D2>2) Also should a GR303 termination and a regular =
CAS=20
  termination be addressed</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; =
alike?=20
  Both are plain vanilla DS0's</FONT> </P>
  <P><FONT size=3D2>[KJBII] By addressed, do you mean network =
addressing for=20
  bearer?&nbsp; If so, it depends upon you implementation.&nbsp; If you =
mean=20
  term names, then all terms must have unique names within the =
MG.</FONT></P>
  <P><FONT size=3D2>3) Once we are done with the call there should be a =
way to=20
  shut off the RBS </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
  detection/insertion&nbsp; from the MG. How can the MG be instructed =
about=20
  putting</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; the channel(s) =
into IDLE=20
  state.</FONT> </P>
  <P><FONT size=3D2>[KJBII] Subtract the term.</FONT> </P>
  <P><FONT size=3D2>Appreciate your response.</FONT> </P><BR>
  <P><FONT size=3D2>Praveen Shivaswamy</FONT> <BR><FONT size=3D2>Telica =
Inc</FONT>=20
  </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT>=
=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C30444.0F1D5A58--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 00:22:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26278
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 00:22:01 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4U5819829;
	Thu, 17 Apr 2003 00:30:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4Q8819740
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 00:26:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26220
	for <megaco@ietf.org>; Thu, 17 Apr 2003 00:16:43 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1960rf-00056g-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:19:11 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1960re-00056d-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:19:11 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4JJZb000891
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:19 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4JIqs011915
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:18 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4JITT002331
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:18 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA14690
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:17 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA21203
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:17 +0900 (JST)
Message-Id: <5.0.2.7.2.20030417112226.061cdec8@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Thu, 17 Apr 2003 13:20:34 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Megaco] AuditReply from MG with no specific context
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi all,

What type of reply message should the MG with no specific context
send back to the MGC, when receiving an AuditValue message with
ContextID=ALL and TerminationID=ROOT ?

I think we may have some choices for that, that is (a) command reply
with the audit list contains no information, (b) command reply contains
no information, and (c) action reply contains no information.

Is there any syntax error in each choice above ?
And which is the best choice from above or any other solutions ?

Thanks,
-Susumu 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 00:23:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26308
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 00:23:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3H4W1v19892
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 00:32:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4W1819883
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 00:32:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26300
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 00:22:35 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1960xM-000587-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 00:25:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1960xL-000584-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 00:25:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4U5819829;
	Thu, 17 Apr 2003 00:30:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4Q8819740
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 00:26:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26220
	for <megaco@ietf.org>; Thu, 17 Apr 2003 00:16:43 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1960rf-00056g-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:19:11 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1960re-00056d-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:19:11 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4JJZb000891
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:19 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4JIqs011915
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:18 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4JITT002331
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:18 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA14690
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:17 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA21203
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:19:17 +0900 (JST)
Message-Id: <5.0.2.7.2.20030417112226.061cdec8@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Thu, 17 Apr 2003 13:20:34 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Megaco] AuditReply from MG with no specific context
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi all,

What type of reply message should the MG with no specific context
send back to the MGC, when receiving an AuditValue message with
ContextID=ALL and TerminationID=ROOT ?

I think we may have some choices for that, that is (a) command reply
with the audit list contains no information, (b) command reply contains
no information, and (c) action reply contains no information.

Is there any syntax error in each choice above ?
And which is the best choice from above or any other solutions ?

Thanks,
-Susumu 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 00:42:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27081
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 00:42:04 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4o5821376;
	Thu, 17 Apr 2003 00:50:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4lB821273
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 00:47:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27028
	for <megaco@ietf.org>; Thu, 17 Apr 2003 00:37:45 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961C2-0005BR-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:40:14 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1961C1-0005BO-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:40:14 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4eNZb007572
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:23 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4eMqs015321
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:22 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4eMTT007058
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:22 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA16800
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:21 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA25057
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:21 +0900 (JST)
Message-Id: <5.0.2.7.2.20030417132035.063fba88@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Thu, 17 Apr 2003 13:41:39 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Megaco] trigger for Null context to include terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi all,

I have a question regarding the trigger for Null context to include
specific TerminationIDs in an MG.

In general, we have some phases to provide call operation capability
in an MG after starting the MG, that is (a) to mount physical channels
with configuration commands and (b) to take the physical channels into
service state with specific commands.

Which should be a trigger that the corresponding physical TerminationIDs
show up in Null context in the MG ?

Also when we stop the service on specific physical terminations,
we may at first take the terminations out of service with commands
temporarily, and in the second we may dismount the termination to
delete these from configuration files.

Which should be a trigger that the corresponding physical TerminaionIDs
disappeared from Null context ?

I think that we may have both choices in both cases above along the
MEGACO standard. It seems that we have no description regarding
this in, and this would be a implementation matter.

Please let me know your idea.

Thanks,
-Susumu 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 00:43:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27103
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 00:43:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3H4q4M21458
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 00:52:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4q3821455
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 00:52:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27097
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 00:42:37 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961Gk-0005CM-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 00:45:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961Gk-0005CJ-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 00:45:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4o5821376;
	Thu, 17 Apr 2003 00:50:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H4lB821273
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 00:47:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27028
	for <megaco@ietf.org>; Thu, 17 Apr 2003 00:37:45 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961C2-0005BR-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:40:14 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1961C1-0005BO-00
	for megaco@ietf.org; Thu, 17 Apr 2003 00:40:14 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4eNZb007572
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:23 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4eMqs015321
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:22 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H4eMTT007058
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:22 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA16800
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:21 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA25057
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:40:21 +0900 (JST)
Message-Id: <5.0.2.7.2.20030417132035.063fba88@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Thu, 17 Apr 2003 13:41:39 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [Megaco] trigger for Null context to include terminations
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi all,

I have a question regarding the trigger for Null context to include
specific TerminationIDs in an MG.

In general, we have some phases to provide call operation capability
in an MG after starting the MG, that is (a) to mount physical channels
with configuration commands and (b) to take the physical channels into
service state with specific commands.

Which should be a trigger that the corresponding physical TerminationIDs
show up in Null context in the MG ?

Also when we stop the service on specific physical terminations,
we may at first take the terminations out of service with commands
temporarily, and in the second we may dismount the termination to
delete these from configuration files.

Which should be a trigger that the corresponding physical TerminaionIDs
disappeared from Null context ?

I think that we may have both choices in both cases above along the
MEGACO standard. It seems that we have no description regarding
this in, and this would be a implementation matter.

Please let me know your idea.

Thanks,
-Susumu 


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 01:11:57 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27605
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 01:11:57 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H5K7823372;
	Thu, 17 Apr 2003 01:20:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H5Hb823278
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 01:17:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27506
	for <megaco@ietf.org>; Thu, 17 Apr 2003 01:08:11 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961fU-0005HU-00
	for megaco@ietf.org; Thu, 17 Apr 2003 01:10:40 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1961fS-0005HR-00
	for megaco@ietf.org; Thu, 17 Apr 2003 01:10:39 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3H58B026558
	for <megaco@ietf.org>; Thu, 17 Apr 2003 10:38:11 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3H589926549;
	Thu, 17 Apr 2003 10:38:10 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3H5B5d24853;
	Thu, 17 Apr 2003 10:41:10 +0530 (IST)
Subject: Re: [Megaco] trigger for Null context to include terminations
To: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Cc: megaco@ietf.org
Date: Thu, 17 Apr 2003 10:36:08 +0530
Message-ID: <OF20B9F196.48BDD964-ON65256D0B.001AA057@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 17/04/2003
 10:36:09 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>






Hi

      In my view:
      All the physical terminations that are configured and not in a valid
context are in
Null context. Hence configuration commands  can taken as triggers for
terminations appearing/disappearing
from a Null context . This is further clarified with the following
specification statement:
" Terminations in the null Context can have their parameters examined
   or modified, and may have events detected on them"
so even  a service change request requires a terminations to be present in
a null context also.


Regards
Venkat





"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
10:11:39 AM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org
cc:

Subject:    [Megaco] trigger for Null context to include terminations


Hi all,

I have a question regarding the trigger for Null context to include
specific TerminationIDs in an MG.

In general, we have some phases to provide call operation capability
in an MG after starting the MG, that is (a) to mount physical channels
with configuration commands and (b) to take the physical channels into
service state with specific commands.

Which should be a trigger that the corresponding physical TerminationIDs
show up in Null context in the MG ?

Also when we stop the service on specific physical terminations,
we may at first take the terminations out of service with commands
temporarily, and in the second we may dismount the termination to
delete these from configuration files.

Which should be a trigger that the corresponding physical TerminaionIDs
disappeared from Null context ?

I think that we may have both choices in both cases above along the
MEGACO standard. It seems that we have no description regarding
this in, and this would be a implementation matter.

Please let me know your idea.

Thanks,
-Susumu


_______________________________________________
Megaco mailing list
Megaco@ietf.org
 https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 01:13:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27629
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 01:13:02 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3H5LwB23418
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 01:21:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H5Lw823415
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 01:21:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27621
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 01:12:31 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961jg-0005IO-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 01:15:00 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961jg-0005IL-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 01:15:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H5K7823372;
	Thu, 17 Apr 2003 01:20:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H5Hb823278
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 01:17:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27506
	for <megaco@ietf.org>; Thu, 17 Apr 2003 01:08:11 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1961fU-0005HU-00
	for megaco@ietf.org; Thu, 17 Apr 2003 01:10:40 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1961fS-0005HR-00
	for megaco@ietf.org; Thu, 17 Apr 2003 01:10:39 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3H58B026558
	for <megaco@ietf.org>; Thu, 17 Apr 2003 10:38:11 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3H589926549;
	Thu, 17 Apr 2003 10:38:10 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3H5B5d24853;
	Thu, 17 Apr 2003 10:41:10 +0530 (IST)
Subject: Re: [Megaco] trigger for Null context to include terminations
To: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Cc: megaco@ietf.org
Date: Thu, 17 Apr 2003 10:36:08 +0530
Message-ID: <OF20B9F196.48BDD964-ON65256D0B.001AA057@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 17/04/2003
 10:36:09 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>






Hi

      In my view:
      All the physical terminations that are configured and not in a valid
context are in
Null context. Hence configuration commands  can taken as triggers for
terminations appearing/disappearing
from a Null context . This is further clarified with the following
specification statement:
" Terminations in the null Context can have their parameters examined
   or modified, and may have events detected on them"
so even  a service change request requires a terminations to be present in
a null context also.


Regards
Venkat





"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
10:11:39 AM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org
cc:

Subject:    [Megaco] trigger for Null context to include terminations


Hi all,

I have a question regarding the trigger for Null context to include
specific TerminationIDs in an MG.

In general, we have some phases to provide call operation capability
in an MG after starting the MG, that is (a) to mount physical channels
with configuration commands and (b) to take the physical channels into
service state with specific commands.

Which should be a trigger that the corresponding physical TerminationIDs
show up in Null context in the MG ?

Also when we stop the service on specific physical terminations,
we may at first take the terminations out of service with commands
temporarily, and in the second we may dismount the termination to
delete these from configuration files.

Which should be a trigger that the corresponding physical TerminaionIDs
disappeared from Null context ?

I think that we may have both choices in both cases above along the
MEGACO standard. It seems that we have no description regarding
this in, and this would be a implementation matter.

Please let me know your idea.

Thanks,
-Susumu


_______________________________________________
Megaco mailing list
Megaco@ietf.org
 https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 04:07:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11978
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 04:07:13 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8Ec813533;
	Thu, 17 Apr 2003 04:14:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8Ax813430
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 04:10:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11924
	for <megaco@ietf.org>; Thu, 17 Apr 2003 04:01:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1964NB-000624-00
	for megaco@ietf.org; Thu, 17 Apr 2003 04:03:57 -0400
Received: from wiprom2mx1.wipro.com ([203.197.164.41])
	by ietf-mx with esmtp (Exim 4.12)
	id 1964Mz-00061w-00
	for megaco@ietf.org; Thu, 17 Apr 2003 04:03:46 -0400
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h3H83NN12973
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:33:23 +0530 (IST)
Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 17 Apr 2003 13:33:07 +0530
Received: from RANJITHEC ([192.168.178.175]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 17 Apr 2003 13:33:07 +0530
Reply-To: <ranjith.mukundan@wipro.com>
From: "Ranjith Mukundan" <ranjith.mukundan@wipro.com>
To: "'Praveen Shivaswamy'" <praveen@telica.com>,
        "'Kevin Boyle'" <kboyle@nortelnetworks.com>, <megaco@ietf.org>
Cc: "'John Hutchins'" <jhutchins@telica.com>, <mtaylor@coppercom.com>
Subject: RE: [Megaco] (no subject)
Date: Thu, 17 Apr 2003 13:32:53 +0530
Organization: Wipro Technologies
Message-ID: <002b01c304b7$bf5dd5f0$afb2a8c0@RANJITHEC>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-5d35e18a-7085-11d7-ba7f-006067005148"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <C9AFC8E904D49C4593EB077A2E8402BA15D687@wench.telica.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
X-OriginalArrivalTime: 17 Apr 2003 08:03:07.0586 (UTC) FILETIME=[C7E75A20:01C304B7]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPartTM-000-5d35e18a-7085-11d7-ba7f-006067005148
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002C_01C304E5.D9179890"

------=_NextPart_000_002C_01C304E5.D9179890
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

praveen, 
 
this is not the first time we are touching upon this topic - both on
sigtran and megaco; you are bound to find some stuff in the archives.
But here is a summary;
 
- GR303UA sigtran draft addresses the message based part - viz: TMC/CSC
and EOC.
- For the in-band signaling, as you've pointed out, you could use a
combination of packages [enhalpkg + Al supervision pkg) - but this does
*NOT* cater to all line types (incl LRB et al).
- As an alternative, you may also want to take a look at ATM Forum's LES
Using AAL2 - H.248 Signaling Addendum (BTD-VMOA-LESH248-01.02) which
provides a summary of how differnet gr303 signaling states can be mapped
to available pkgs' events and signals - of course, thats not a standard
way of supporting a new termination type (like gr303 DLC) off a gateway;
but is an alternative all the same.
 
I was working and was in discussion with Martin (cc'd here) for putting
together a comperehensive MEGACO-gr303pkg sometime back; but that got
droped off my list owing to other priorities. I'll review that draft
with Martin and mail it over to you in a couple weeks time from now for
your reference/inputs.
 
Also, another aspect to note is that of the voiceband data transmission
requirement (for support of supplementary services like callerID, MWI
etc over a DLC) over RTP while emulating a GR303 trunking over RTP. I am
in the process of putting together a RTP payload format for achieveing
this and will submit as an individual ID on the AVT soon.
 
hth,
ranjith..
 
 
 
 

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Praveen Shivaswamy
Sent: Wednesday, April 16, 2003 11:45 PM
To: 'Kevin Boyle'; Praveen Shivaswamy; 'megaco@ietf.org'
Cc: John Hutchins
Subject: RE: [Megaco] (no subject)


Kevin,
 
thanks for the quick response. However here is my question.
 
Basic Analog line supervison package + Enhanced Analog line package
address the Loop start signaling requirements (as commented in
http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-01.txt
). Which package addressess
other line side signaling models, like Ground start/Loop reverse battery
etc.
 
Also please see my inline response.

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, April 16, 2003 1:21 PM
To: Praveen Shivaswamy; 'megaco@ietf.org'
Subject: RE: [Megaco] (no subject)



Comments inline.  [KJBII] 

Remember, GR303 is NOT trunks -- it's lines.  Taking packages that are
built specifically for trunking and trying to shoehorn GR303 into the
model will most certainly be difficult at best.

Kevin 

-----Original Message----- 
From: Praveen Shivaswamy [mailto:praveen@telica.com] 
Sent: Wednesday, April 16, 2003 11:59 AM 
To: 'megaco@ietf.org'; Praveen Shivaswamy 
Subject: [Megaco] (no subject) 


When trying to model GR-303 into the MG/MGC architecture i'm having hard
time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is
peeled from the MG 
    and backhaul to the MGC. Thats fine. But a resulting side effect is
that i'm not 
    finding any reference that describes how to take care of this
problem. 

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line
and CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for
calls originating 
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0). 

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2
gets the 
   same DS0, we need to do GS signaling and so on and so forth. This
calls for 
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do
you plan 
   achieve this? 

[KJBII] For GR303, call control signalling should be backhauled.  Would
this not go over the SCTP link? 
[Praveen Shivaswamy] Yes. That was my first statement. 

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02. 
   In all the places it is assumed that the signaling model is
pre-provisioned. In case 
   of GR-303, signaling model can be logically tied to a CRV and not a
DS0 (as done 
   for regular CAS lines/trunks). MG will not be provisioned with any
CRV information. 

[KJBII] I know of no CAS lines -- CAS is for trunking.  I know of no
handsets that generate MF digits.  Therefore, it seems that this should
be modeled as lines, and whatever trunking is present should be handled
independently.
[Praveen Shivaswamy] I was referring to a scenario where we can have CAS
lines coming from an IAD (channel bank) to the MG. These would be
considered as lines. 

2) Also should a GR303 termination and a regular CAS termination be
addressed 
    alike? Both are plain vanilla DS0's 

[KJBII] By addressed, do you mean network addressing for bearer?  If so,
it depends upon you implementation.  If you mean term names, then all
terms must have unique names within the MG.

3) Once we are done with the call there should be a way to shut off the
RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting 
    the channel(s) into IDLE state. 

[KJBII] Subtract the term. 

Appreciate your response. 


Praveen Shivaswamy 
Telica Inc 

_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco 


------=_NextPart_000_002C_01C304E5.D9179890
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2>praveen, </FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =
size=3D2>this=20
is not the first time we are touching upon this topic - both on sigtran =
and=20
megaco; you are bound to find some stuff in the archives. But here is a=20
summary;</FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
GR303UA sigtran draft addresses the message based part - viz: TMC/CSC =
and=20
EOC.</FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =
size=3D2>- For=20
the in-band signaling, as you've pointed out, you could use a =
combination of=20
packages [enhalpkg + Al supervision pkg) - but this does&nbsp;*NOT* =
cater to all=20
line types (incl&nbsp;LRB et al).</FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff>- As an alternative, you may also want to take a look at =
ATM=20
Forum's <SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3>LES Using AAL2 &#8211; H.248 Signaling Addendum (B<SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">TD-VMOA-LESH248-01.02)=20
which provides a summary of how differnet gr303 signaling states can be =
mapped=20
to available pkgs' events and signals - of course, thats not a standard =
way of=20
supporting a new termination type (like gr303 DLC)&nbsp;off a gateway; =
but is an=20
alternative all the =
same.</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">I=20
was working and was in discussion with Martin (cc'd here) for putting =
together a=20
comperehensive MEGACO-gr303pkg sometime back; but that got droped off my =
list=20
owing to other priorities. I'll review that draft with Martin and mail =
it over=20
to you in a couple weeks time from now for your=20
reference/inputs.</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">Also,=20
another aspect to note is that of the voiceband data transmission =
requirement=20
(for support of supplementary services like callerID, MWI etc over a=20
DLC)&nbsp;over RTP while emulating a GR303 trunking over RTP. I am in =
the=20
process of putting together a RTP payload format for achieveing this and =
will=20
submit as an individual ID on the AVT=20
soon.</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt">hth,</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt">ranjith..</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Praveen Shivaswamy<BR><B>Sent:</B> Wednesday, April 16, 2003 11:45 =

  PM<BR><B>To:</B> 'Kevin Boyle'; Praveen Shivaswamy;=20
  'megaco@ietf.org'<BR><B>Cc:</B> John Hutchins<BR><B>Subject:</B> RE: =
[Megaco]=20
  (no subject)<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>Kevin,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>thanks for the quick response. However here is my=20
  question.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>Basic Analog line supervison package + Enhanced Analog line=20
  package</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>address the Loop start signaling requirements (as commented=20
  in</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs=
-01.txt">http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkg=
s-01.txt</A>).=20
  Which package addressess</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>other line side signaling models, like Ground start/Loop =
reverse=20
  battery etc.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>Also please see my inline response.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Kevin Boyle=20
    [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, April =
16, 2003=20
    1:21 PM<BR><B>To:</B> Praveen Shivaswamy;=20
    'megaco@ietf.org'<BR><B>Subject:</B> RE: [Megaco] (no=20
    subject)<BR><BR></FONT></DIV>
    <P><FONT size=3D2>Comments inline.&nbsp; [KJBII]</FONT> </P>
    <P><FONT size=3D2>Remember, GR303 is NOT trunks -- it's lines.&nbsp; =
Taking=20
    packages that are built specifically for trunking and trying to =
shoehorn=20
    GR303 into the model will most certainly be difficult at =
best.</FONT></P>
    <P><FONT size=3D2>Kevin</FONT> </P>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    Praveen Shivaswamy [<A=20
    href=3D"mailto:praveen@telica.com">mailto:praveen@telica.com</A>]=20
    </FONT><BR><FONT size=3D2>Sent: Wednesday, April 16, 2003 11:59 =
AM</FONT>=20
    <BR><FONT size=3D2>To: 'megaco@ietf.org'; Praveen Shivaswamy</FONT> =
<BR><FONT=20
    size=3D2>Subject: [Megaco] (no subject)</FONT> </P><BR>
    <P><FONT size=3D2>When trying to model GR-303 into the MG/MGC =
architecture i'm=20
    having hard time trying to solve the problem stated below. Please=20
    advice,</FONT></P>
    <P><FONT size=3D2>1) As specified in =
draft-ietf-sigtran-gr303ua-00.txt,=20
    TMC/EOC/PPS is peeled from the MG</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
    and backhaul to the MGC. Thats fine. But a resulting side effect is =
that i'm=20
    not</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; finding any =
reference that=20
    describes how to take care of this problem.</FONT> </P>
    <P><FONT size=3D2>&nbsp;&nbsp; Assume CRV 1 is a loop start line and =
CRV 2 is=20
    a ground start line and CRV 3 is </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp; loop=20
    reverse battery line. Let us say we have DS0-1 allocated for calls=20
    originating</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; from CRV 1,2 and =
3 (each=20
    done seperately, but gets the same DS0).</FONT> </P>
    <P><FONT size=3D2>&nbsp;&nbsp; For CRV 1 we need to do LS signaling =
on the=20
    DS0, later when CRV 2 gets the</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; same=20
    DS0, we need to do GS signaling and so on and so forth. This calls=20
    for</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; applying the signaling =
model (like=20
    LS/GS/LRB etc) on the fly. How do you plan</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp; achieve this?</FONT> </P>
    <P><FONT size=3D2>[KJBII] For GR303, call control signalling should =
be=20
    backhauled.&nbsp; Would this not go over the SCTP link?</FONT> =
<BR><SPAN=20
    class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>[Praveen=20
    Shivaswamy]&nbsp;Yes. That was my first =
statement.&nbsp;</FONT></SPAN></P>
    <P><FONT size=3D2>&nbsp;&nbsp; This is not addressed in the rfc-3015 =
or=20
    draft-manyfolks-megaco-caspackage-02.</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
    In all the places it is assumed that the signaling model is =
pre-provisioned.=20
    In case</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; of GR-303, signaling =
model can=20
    be logically tied to a CRV and not a DS0 (as done</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp; for regular CAS lines/trunks). MG will not be=20
    provisioned with any CRV information.</FONT> </P>
    <P><FONT size=3D2>[KJBII] I know of no CAS lines -- CAS is for =
trunking.&nbsp;=20
    I know of no handsets that generate MF digits.&nbsp; Therefore, it =
seems=20
    that this should be modeled as lines, and whatever trunking is =
present=20
    should be handled independently.<BR></FONT><SPAN=20
    class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>[Praveen=20
    Shivaswamy]&nbsp;I was referring to a scenario where we =
can&nbsp;have CAS=20
    lines coming </FONT></SPAN><SPAN class=3D040331218-16042003><FONT =
face=3DTahoma=20
    color=3D#0000ff size=3D1>from an IAD (channel bank)&nbsp;to the MG. =
These would=20
    be&nbsp;considered as lines.&nbsp;</FONT></SPAN></P>
    <P><FONT size=3D2>2) Also should a GR303 termination and a regular =
CAS=20
    termination be addressed</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp; alike?=20
    Both are plain vanilla DS0's</FONT> </P>
    <P><FONT size=3D2>[KJBII] By addressed, do you mean network =
addressing for=20
    bearer?&nbsp; If so, it depends upon you implementation.&nbsp; If =
you mean=20
    term names, then all terms must have unique names within the =
MG.</FONT></P>
    <P><FONT size=3D2>3) Once we are done with the call there should be =
a way to=20
    shut off the RBS </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
    detection/insertion&nbsp; from the MG. How can the MG be instructed =
about=20
    putting</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; the channel(s) =
into IDLE=20
    state.</FONT> </P>
    <P><FONT size=3D2>[KJBII] Subtract the term.</FONT> </P>
    <P><FONT size=3D2>Appreciate your response.</FONT> </P><BR>
    <P><FONT size=3D2>Praveen Shivaswamy</FONT> <BR><FONT =
size=3D2>Telica Inc</FONT>=20
    </P>
    <P><FONT =
size=3D2>_______________________________________________</FONT>=20
    <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
    size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A =
target=3D_blank=20
    =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.=
org/mailman/listinfo/megaco</A></FONT>=20
    </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002C_01C304E5.D9179890--


------=_NextPartTM-000-5d35e18a-7085-11d7-ba7f-006067005148--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 04:08:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11998
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 04:08:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3H8HNG13637
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 04:17:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8HN813634
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 04:17:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11994
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 04:07:51 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1964TN-00062S-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 04:10:21 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1964TN-00062P-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 04:10:21 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8Ec813533;
	Thu, 17 Apr 2003 04:14:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8Ax813430
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 04:10:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11924
	for <megaco@ietf.org>; Thu, 17 Apr 2003 04:01:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1964NB-000624-00
	for megaco@ietf.org; Thu, 17 Apr 2003 04:03:57 -0400
Received: from wiprom2mx1.wipro.com ([203.197.164.41])
	by ietf-mx with esmtp (Exim 4.12)
	id 1964Mz-00061w-00
	for megaco@ietf.org; Thu, 17 Apr 2003 04:03:46 -0400
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h3H83NN12973
	for <megaco@ietf.org>; Thu, 17 Apr 2003 13:33:23 +0530 (IST)
Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 17 Apr 2003 13:33:07 +0530
Received: from RANJITHEC ([192.168.178.175]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 17 Apr 2003 13:33:07 +0530
Reply-To: <ranjith.mukundan@wipro.com>
From: "Ranjith Mukundan" <ranjith.mukundan@wipro.com>
To: "'Praveen Shivaswamy'" <praveen@telica.com>,
        "'Kevin Boyle'" <kboyle@nortelnetworks.com>, <megaco@ietf.org>
Cc: "'John Hutchins'" <jhutchins@telica.com>, <mtaylor@coppercom.com>
Subject: RE: [Megaco] (no subject)
Date: Thu, 17 Apr 2003 13:32:53 +0530
Organization: Wipro Technologies
Message-ID: <002b01c304b7$bf5dd5f0$afb2a8c0@RANJITHEC>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPartTM-000-5d35e18a-7085-11d7-ba7f-006067005148"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <C9AFC8E904D49C4593EB077A2E8402BA15D687@wench.telica.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
X-OriginalArrivalTime: 17 Apr 2003 08:03:07.0586 (UTC) FILETIME=[C7E75A20:01C304B7]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPartTM-000-5d35e18a-7085-11d7-ba7f-006067005148
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002C_01C304E5.D9179890"

------=_NextPart_000_002C_01C304E5.D9179890
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

praveen, 
 
this is not the first time we are touching upon this topic - both on
sigtran and megaco; you are bound to find some stuff in the archives.
But here is a summary;
 
- GR303UA sigtran draft addresses the message based part - viz: TMC/CSC
and EOC.
- For the in-band signaling, as you've pointed out, you could use a
combination of packages [enhalpkg + Al supervision pkg) - but this does
*NOT* cater to all line types (incl LRB et al).
- As an alternative, you may also want to take a look at ATM Forum's LES
Using AAL2 - H.248 Signaling Addendum (BTD-VMOA-LESH248-01.02) which
provides a summary of how differnet gr303 signaling states can be mapped
to available pkgs' events and signals - of course, thats not a standard
way of supporting a new termination type (like gr303 DLC) off a gateway;
but is an alternative all the same.
 
I was working and was in discussion with Martin (cc'd here) for putting
together a comperehensive MEGACO-gr303pkg sometime back; but that got
droped off my list owing to other priorities. I'll review that draft
with Martin and mail it over to you in a couple weeks time from now for
your reference/inputs.
 
Also, another aspect to note is that of the voiceband data transmission
requirement (for support of supplementary services like callerID, MWI
etc over a DLC) over RTP while emulating a GR303 trunking over RTP. I am
in the process of putting together a RTP payload format for achieveing
this and will submit as an individual ID on the AVT soon.
 
hth,
ranjith..
 
 
 
 

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On Behalf Of
Praveen Shivaswamy
Sent: Wednesday, April 16, 2003 11:45 PM
To: 'Kevin Boyle'; Praveen Shivaswamy; 'megaco@ietf.org'
Cc: John Hutchins
Subject: RE: [Megaco] (no subject)


Kevin,
 
thanks for the quick response. However here is my question.
 
Basic Analog line supervison package + Enhanced Analog line package
address the Loop start signaling requirements (as commented in
http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs-01.txt
). Which package addressess
other line side signaling models, like Ground start/Loop reverse battery
etc.
 
Also please see my inline response.

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortelnetworks.com]
Sent: Wednesday, April 16, 2003 1:21 PM
To: Praveen Shivaswamy; 'megaco@ietf.org'
Subject: RE: [Megaco] (no subject)



Comments inline.  [KJBII] 

Remember, GR303 is NOT trunks -- it's lines.  Taking packages that are
built specifically for trunking and trying to shoehorn GR303 into the
model will most certainly be difficult at best.

Kevin 

-----Original Message----- 
From: Praveen Shivaswamy [mailto:praveen@telica.com] 
Sent: Wednesday, April 16, 2003 11:59 AM 
To: 'megaco@ietf.org'; Praveen Shivaswamy 
Subject: [Megaco] (no subject) 


When trying to model GR-303 into the MG/MGC architecture i'm having hard
time trying to solve the problem stated below. Please advice,

1) As specified in draft-ietf-sigtran-gr303ua-00.txt, TMC/EOC/PPS is
peeled from the MG 
    and backhaul to the MGC. Thats fine. But a resulting side effect is
that i'm not 
    finding any reference that describes how to take care of this
problem. 

   Assume CRV 1 is a loop start line and CRV 2 is a ground start line
and CRV 3 is 
   loop reverse battery line. Let us say we have DS0-1 allocated for
calls originating 
   from CRV 1,2 and 3 (each done seperately, but gets the same DS0). 

   For CRV 1 we need to do LS signaling on the DS0, later when CRV 2
gets the 
   same DS0, we need to do GS signaling and so on and so forth. This
calls for 
   applying the signaling model (like LS/GS/LRB etc) on the fly. How do
you plan 
   achieve this? 

[KJBII] For GR303, call control signalling should be backhauled.  Would
this not go over the SCTP link? 
[Praveen Shivaswamy] Yes. That was my first statement. 

   This is not addressed in the rfc-3015 or
draft-manyfolks-megaco-caspackage-02. 
   In all the places it is assumed that the signaling model is
pre-provisioned. In case 
   of GR-303, signaling model can be logically tied to a CRV and not a
DS0 (as done 
   for regular CAS lines/trunks). MG will not be provisioned with any
CRV information. 

[KJBII] I know of no CAS lines -- CAS is for trunking.  I know of no
handsets that generate MF digits.  Therefore, it seems that this should
be modeled as lines, and whatever trunking is present should be handled
independently.
[Praveen Shivaswamy] I was referring to a scenario where we can have CAS
lines coming from an IAD (channel bank) to the MG. These would be
considered as lines. 

2) Also should a GR303 termination and a regular CAS termination be
addressed 
    alike? Both are plain vanilla DS0's 

[KJBII] By addressed, do you mean network addressing for bearer?  If so,
it depends upon you implementation.  If you mean term names, then all
terms must have unique names within the MG.

3) Once we are done with the call there should be a way to shut off the
RBS 
    detection/insertion  from the MG. How can the MG be instructed about
putting 
    the channel(s) into IDLE state. 

[KJBII] Subtract the term. 

Appreciate your response. 


Praveen Shivaswamy 
Telica Inc 

_______________________________________________ 
Megaco mailing list 
Megaco@ietf.org 
https://www1.ietf.org/mailman/listinfo/megaco 


------=_NextPart_000_002C_01C304E5.D9179890
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2>praveen, </FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =
size=3D2>this=20
is not the first time we are touching upon this topic - both on sigtran =
and=20
megaco; you are bound to find some stuff in the archives. But here is a=20
summary;</FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =
size=3D2>-=20
GR303UA sigtran draft addresses the message based part - viz: TMC/CSC =
and=20
EOC.</FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =
size=3D2>- For=20
the in-band signaling, as you've pointed out, you could use a =
combination of=20
packages [enhalpkg + Al supervision pkg) - but this does&nbsp;*NOT* =
cater to all=20
line types (incl&nbsp;LRB et al).</FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff>- As an alternative, you may also want to take a look at =
ATM=20
Forum's <SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3>LES Using AAL2 &#8211; H.248 Signaling Addendum (B<SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">TD-VMOA-LESH248-01.02)=20
which provides a summary of how differnet gr303 signaling states can be =
mapped=20
to available pkgs' events and signals - of course, thats not a standard =
way of=20
supporting a new termination type (like gr303 DLC)&nbsp;off a gateway; =
but is an=20
alternative all the =
same.</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">I=20
was working and was in discussion with Martin (cc'd here) for putting =
together a=20
comperehensive MEGACO-gr303pkg sometime back; but that got droped off my =
list=20
owing to other priorities. I'll review that draft with Martin and mail =
it over=20
to you in a couple weeks time from now for your=20
reference/inputs.</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">Also,=20
another aspect to note is that of the voiceband data transmission =
requirement=20
(for support of supplementary services like callerID, MWI etc over a=20
DLC)&nbsp;over RTP while emulating a GR303 trunking over RTP. I am in =
the=20
process of putting together a RTP payload format for achieveing this and =
will=20
submit as an individual ID on the AVT=20
soon.</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt">hth,</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt">ranjith..</SPAN></FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial size=3D2><FONT=20
color=3D#0000ff><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 11pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: =
10.0pt"></SPAN></FONT></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D512285007-17042003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] <B>On Behalf Of=20
  </B>Praveen Shivaswamy<BR><B>Sent:</B> Wednesday, April 16, 2003 11:45 =

  PM<BR><B>To:</B> 'Kevin Boyle'; Praveen Shivaswamy;=20
  'megaco@ietf.org'<BR><B>Cc:</B> John Hutchins<BR><B>Subject:</B> RE: =
[Megaco]=20
  (no subject)<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>Kevin,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>thanks for the quick response. However here is my=20
  question.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>Basic Analog line supervison package + Enhanced Analog line=20
  package</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>address the Loop start signaling requirements (as commented=20
  in</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff size=3D1><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkgs=
-01.txt">http://www.ietf.org/internet-drafts/draft-taylor-megaco-enhalpkg=
s-01.txt</A>).=20
  Which package addressess</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>other line side signaling models, like Ground start/Loop =
reverse=20
  battery etc.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D040331218-16042003><FONT face=3DTahoma =
color=3D#0000ff=20
  size=3D1>Also please see my inline response.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Kevin Boyle=20
    [mailto:kboyle@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, April =
16, 2003=20
    1:21 PM<BR><B>To:</B> Praveen Shivaswamy;=20
    'megaco@ietf.org'<BR><B>Subject:</B> RE: [Megaco] (no=20
    subject)<BR><BR></FONT></DIV>
    <P><FONT size=3D2>Comments inline.&nbsp; [KJBII]</FONT> </P>
    <P><FONT size=3D2>Remember, GR303 is NOT trunks -- it's lines.&nbsp; =
Taking=20
    packages that are built specifically for trunking and trying to =
shoehorn=20
    GR303 into the model will most certainly be difficult at =
best.</FONT></P>
    <P><FONT size=3D2>Kevin</FONT> </P>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    Praveen Shivaswamy [<A=20
    href=3D"mailto:praveen@telica.com">mailto:praveen@telica.com</A>]=20
    </FONT><BR><FONT size=3D2>Sent: Wednesday, April 16, 2003 11:59 =
AM</FONT>=20
    <BR><FONT size=3D2>To: 'megaco@ietf.org'; Praveen Shivaswamy</FONT> =
<BR><FONT=20
    size=3D2>Subject: [Megaco] (no subject)</FONT> </P><BR>
    <P><FONT size=3D2>When trying to model GR-303 into the MG/MGC =
architecture i'm=20
    having hard time trying to solve the problem stated below. Please=20
    advice,</FONT></P>
    <P><FONT size=3D2>1) As specified in =
draft-ietf-sigtran-gr303ua-00.txt,=20
    TMC/EOC/PPS is peeled from the MG</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
    and backhaul to the MGC. Thats fine. But a resulting side effect is =
that i'm=20
    not</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; finding any =
reference that=20
    describes how to take care of this problem.</FONT> </P>
    <P><FONT size=3D2>&nbsp;&nbsp; Assume CRV 1 is a loop start line and =
CRV 2 is=20
    a ground start line and CRV 3 is </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp; loop=20
    reverse battery line. Let us say we have DS0-1 allocated for calls=20
    originating</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; from CRV 1,2 and =
3 (each=20
    done seperately, but gets the same DS0).</FONT> </P>
    <P><FONT size=3D2>&nbsp;&nbsp; For CRV 1 we need to do LS signaling =
on the=20
    DS0, later when CRV 2 gets the</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp; same=20
    DS0, we need to do GS signaling and so on and so forth. This calls=20
    for</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; applying the signaling =
model (like=20
    LS/GS/LRB etc) on the fly. How do you plan</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp; achieve this?</FONT> </P>
    <P><FONT size=3D2>[KJBII] For GR303, call control signalling should =
be=20
    backhauled.&nbsp; Would this not go over the SCTP link?</FONT> =
<BR><SPAN=20
    class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>[Praveen=20
    Shivaswamy]&nbsp;Yes. That was my first =
statement.&nbsp;</FONT></SPAN></P>
    <P><FONT size=3D2>&nbsp;&nbsp; This is not addressed in the rfc-3015 =
or=20
    draft-manyfolks-megaco-caspackage-02.</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;=20
    In all the places it is assumed that the signaling model is =
pre-provisioned.=20
    In case</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; of GR-303, signaling =
model can=20
    be logically tied to a CRV and not a DS0 (as done</FONT> <BR><FONT=20
    size=3D2>&nbsp;&nbsp; for regular CAS lines/trunks). MG will not be=20
    provisioned with any CRV information.</FONT> </P>
    <P><FONT size=3D2>[KJBII] I know of no CAS lines -- CAS is for =
trunking.&nbsp;=20
    I know of no handsets that generate MF digits.&nbsp; Therefore, it =
seems=20
    that this should be modeled as lines, and whatever trunking is =
present=20
    should be handled independently.<BR></FONT><SPAN=20
    class=3D040331218-16042003><FONT face=3DTahoma color=3D#0000ff =
size=3D1>[Praveen=20
    Shivaswamy]&nbsp;I was referring to a scenario where we =
can&nbsp;have CAS=20
    lines coming </FONT></SPAN><SPAN class=3D040331218-16042003><FONT =
face=3DTahoma=20
    color=3D#0000ff size=3D1>from an IAD (channel bank)&nbsp;to the MG. =
These would=20
    be&nbsp;considered as lines.&nbsp;</FONT></SPAN></P>
    <P><FONT size=3D2>2) Also should a GR303 termination and a regular =
CAS=20
    termination be addressed</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp; alike?=20
    Both are plain vanilla DS0's</FONT> </P>
    <P><FONT size=3D2>[KJBII] By addressed, do you mean network =
addressing for=20
    bearer?&nbsp; If so, it depends upon you implementation.&nbsp; If =
you mean=20
    term names, then all terms must have unique names within the =
MG.</FONT></P>
    <P><FONT size=3D2>3) Once we are done with the call there should be =
a way to=20
    shut off the RBS </FONT><BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;=20
    detection/insertion&nbsp; from the MG. How can the MG be instructed =
about=20
    putting</FONT> <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp; the channel(s) =
into IDLE=20
    state.</FONT> </P>
    <P><FONT size=3D2>[KJBII] Subtract the term.</FONT> </P>
    <P><FONT size=3D2>Appreciate your response.</FONT> </P><BR>
    <P><FONT size=3D2>Praveen Shivaswamy</FONT> <BR><FONT =
size=3D2>Telica Inc</FONT>=20
    </P>
    <P><FONT =
size=3D2>_______________________________________________</FONT>=20
    <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
    size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A =
target=3D_blank=20
    =
href=3D"https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.=
org/mailman/listinfo/megaco</A></FONT>=20
    </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_002C_01C304E5.D9179890--


------=_NextPartTM-000-5d35e18a-7085-11d7-ba7f-006067005148--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 05:54:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13931
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 05:54:18 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HA2O820331;
	Thu, 17 Apr 2003 06:02:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H9xr820171
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 05:59:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13871
	for <megaco@ietf.org>; Thu, 17 Apr 2003 05:50:19 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19664X-0006Ml-00
	for megaco@ietf.org; Thu, 17 Apr 2003 05:52:49 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 19664W-0006MX-00
	for megaco@ietf.org; Thu, 17 Apr 2003 05:52:49 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H9qhZb024000
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:43 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H9qgqs001861
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:42 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H9qgTT014543
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:42 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA12863
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:41 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA18954
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:41 +0900 (JST)
Message-Id: <5.0.2.7.2.20030417181139.061d6f00@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Thu, 17 Apr 2003 18:53:59 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] trigger for Null context to include terminations
In-Reply-To: <OF20B9F196.48BDD964-ON65256D0B.001AA057@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi Venkat,

Thank you for your help.

ServiceChange (restart) should be sent when the terminations have
just returned to the service from section 7.2.8 of MEGACO, therefore
I think we have no indication just when the terminations show up in
Null context along your suggestion.

In effect the terminations which are configured but not in-service yet
could not detect any events on them in the conventional TDM or ATM.
And I think that we have no need to set any parameters on them if
they cannot make any calls or detect any events...

I am confused what the need is for physical terminations not in-service
yet to be kept in Null context ?

It may be good for terminations fault but not taken out-of-service
manually yet to be kept in Null context though.

It seems natural that the terminations show up after the Service
Change(restart) is sent...

Could you please tell me your idea ?

Thanks,
-Susumu

---
>Hi
>
>       In my view:
>       All the physical terminations that are configured and not in a valid
>context are in
>Null context. Hence configuration commands  can taken as triggers for
>terminations appearing/disappearing
>from a Null context . This is further clarified with the following
>specification statement:
>" Terminations in the null Context can have their parameters examined
>    or modified, and may have events detected on them"
>so even  a service change request requires a terminations to be present in
>a null context also.
>
>
>Regards
>Venkat
>
>"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
>10:11:39 AM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:
>
>Subject:    [Megaco] trigger for Null context to include terminations
>
>
>Hi all,
>
>I have a question regarding the trigger for Null context to include
>specific TerminationIDs in an MG.
>
>In general, we have some phases to provide call operation capability
>in an MG after starting the MG, that is (a) to mount physical channels
>with configuration commands and (b) to take the physical channels into
>service state with specific commands.
>
>Which should be a trigger that the corresponding physical TerminationIDs
>show up in Null context in the MG ?
>
>Also when we stop the service on specific physical terminations,
>we may at first take the terminations out of service with commands
>temporarily, and in the second we may dismount the termination to
>delete these from configuration files.
>
>Which should be a trigger that the corresponding physical TerminaionIDs
>disappeared from Null context ?
>
>I think that we may have both choices in both cases above along the
>MEGACO standard. It seems that we have no description regarding
>this in, and this would be a implementation matter.
>
>Please let me know your idea.
>
>Thanks,
>-Susumu
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 05:55:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13970
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 05:55:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HA4R920417
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 06:04:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HA4Q820414
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 06:04:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13963
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 05:54:52 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19668x-0006Nm-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 05:57:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19668w-0006Nj-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 05:57:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HA2O820331;
	Thu, 17 Apr 2003 06:02:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H9xr820171
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 05:59:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13871
	for <megaco@ietf.org>; Thu, 17 Apr 2003 05:50:19 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 19664X-0006Ml-00
	for megaco@ietf.org; Thu, 17 Apr 2003 05:52:49 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 19664W-0006MX-00
	for megaco@ietf.org; Thu, 17 Apr 2003 05:52:49 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H9qhZb024000
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:43 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H9qgqs001861
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:42 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3H9qgTT014543
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:42 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA12863
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:41 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA18954
	for <megaco@ietf.org>; Thu, 17 Apr 2003 18:52:41 +0900 (JST)
Message-Id: <5.0.2.7.2.20030417181139.061d6f00@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Thu, 17 Apr 2003 18:53:59 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] trigger for Null context to include terminations
In-Reply-To: <OF20B9F196.48BDD964-ON65256D0B.001AA057@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi Venkat,

Thank you for your help.

ServiceChange (restart) should be sent when the terminations have
just returned to the service from section 7.2.8 of MEGACO, therefore
I think we have no indication just when the terminations show up in
Null context along your suggestion.

In effect the terminations which are configured but not in-service yet
could not detect any events on them in the conventional TDM or ATM.
And I think that we have no need to set any parameters on them if
they cannot make any calls or detect any events...

I am confused what the need is for physical terminations not in-service
yet to be kept in Null context ?

It may be good for terminations fault but not taken out-of-service
manually yet to be kept in Null context though.

It seems natural that the terminations show up after the Service
Change(restart) is sent...

Could you please tell me your idea ?

Thanks,
-Susumu

---
>Hi
>
>       In my view:
>       All the physical terminations that are configured and not in a valid
>context are in
>Null context. Hence configuration commands  can taken as triggers for
>terminations appearing/disappearing
>from a Null context . This is further clarified with the following
>specification statement:
>" Terminations in the null Context can have their parameters examined
>    or modified, and may have events detected on them"
>so even  a service change request requires a terminations to be present in
>a null context also.
>
>
>Regards
>Venkat
>
>"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
>10:11:39 AM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:
>
>Subject:    [Megaco] trigger for Null context to include terminations
>
>
>Hi all,
>
>I have a question regarding the trigger for Null context to include
>specific TerminationIDs in an MG.
>
>In general, we have some phases to provide call operation capability
>in an MG after starting the MG, that is (a) to mount physical channels
>with configuration commands and (b) to take the physical channels into
>service state with specific commands.
>
>Which should be a trigger that the corresponding physical TerminationIDs
>show up in Null context in the MG ?
>
>Also when we stop the service on specific physical terminations,
>we may at first take the terminations out of service with commands
>temporarily, and in the second we may dismount the termination to
>delete these from configuration files.
>
>Which should be a trigger that the corresponding physical TerminaionIDs
>disappeared from Null context ?
>
>I think that we may have both choices in both cases above along the
>MEGACO standard. It seems that we have no description regarding
>this in, and this would be a implementation matter.
>
>Please let me know your idea.
>
>Thanks,
>-Susumu
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 10:58:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24310
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 10:58:53 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF75809601;
	Thu, 17 Apr 2003 11:07:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCVd830457
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 08:31:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18847
	for <megaco@ietf.org>; Thu, 17 Apr 2003 08:22:04 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1968RM-0007UK-00
	for megaco@ietf.org; Thu, 17 Apr 2003 08:24:32 -0400
Received: from rwcrmhc52.attbi.com ([216.148.227.88])
	by ietf-mx with esmtp (Exim 4.12)
	id 1968RM-0007U5-00
	for megaco@ietf.org; Thu, 17 Apr 2003 08:24:32 -0400
Received: from rutternt (h000476369083.ne.client2.attbi.com[24.60.34.116])
          by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP
          id <2003041712240805200emq51e>; Thu, 17 Apr 2003 12:24:08 +0000
Message-ID: <003b01c304db$fd710fa0$0300a8c0@telica.com>
From: "Carl Rutter" <crutter@attbi.com>
To: <megaco@ietf.org>
Date: Thu, 17 Apr 2003 08:22:18 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0038_01C304BA.7603BB10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4920.2300
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
Subject: [Megaco] Indicator Package Question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C304BA.7603BB10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a question on the Indicator Package outlined in H.248 Annex G.
Its referenced in regards to IP Phones (and User Interface Termination)
but could the package also apply to POTS lines with call waiting etc?
Or is there another package out there that is more appropriate?

Thx,
Carl

------=_NextPart_000_0038_01C304BA.7603BB10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4923.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I have a question on the Indicator =
Package outlined=20
in H.248 Annex G.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Its referenced in regards to IP Phones =
(and User=20
Interface Termination)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>but could the package also apply to =
POTS lines with=20
call waiting etc?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or is there another package out there =
that is more=20
appropriate?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thx,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Carl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0038_01C304BA.7603BB10--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 10:59:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24363
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 10:59:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HF98E10514
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 11:09:08 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF98810511
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 11:09:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24345
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 10:59:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Atf-0000XJ-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 11:01:55 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Atf-0000XG-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 11:01:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HF75809601;
	Thu, 17 Apr 2003 11:07:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCVd830457
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 08:31:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18847
	for <megaco@ietf.org>; Thu, 17 Apr 2003 08:22:04 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 1968RM-0007UK-00
	for megaco@ietf.org; Thu, 17 Apr 2003 08:24:32 -0400
Received: from rwcrmhc52.attbi.com ([216.148.227.88])
	by ietf-mx with esmtp (Exim 4.12)
	id 1968RM-0007U5-00
	for megaco@ietf.org; Thu, 17 Apr 2003 08:24:32 -0400
Received: from rutternt (h000476369083.ne.client2.attbi.com[24.60.34.116])
          by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP
          id <2003041712240805200emq51e>; Thu, 17 Apr 2003 12:24:08 +0000
Message-ID: <003b01c304db$fd710fa0$0300a8c0@telica.com>
From: "Carl Rutter" <crutter@attbi.com>
To: <megaco@ietf.org>
Date: Thu, 17 Apr 2003 08:22:18 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0038_01C304BA.7603BB10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4920.2300
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
Subject: [Megaco] Indicator Package Question
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C304BA.7603BB10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a question on the Indicator Package outlined in H.248 Annex G.
Its referenced in regards to IP Phones (and User Interface Termination)
but could the package also apply to POTS lines with call waiting etc?
Or is there another package out there that is more appropriate?

Thx,
Carl

------=_NextPart_000_0038_01C304BA.7603BB10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4923.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I have a question on the Indicator =
Package outlined=20
in H.248 Annex G.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Its referenced in regards to IP Phones =
(and User=20
Interface Termination)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>but could the package also apply to =
POTS lines with=20
call waiting etc?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Or is there another package out there =
that is more=20
appropriate?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thx,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Carl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0038_01C304BA.7603BB10--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 17:29:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08886
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 17:29:23 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLam810155;
	Thu, 17 Apr 2003 17:36:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLWE809901
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:32:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08551
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:22:26 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196GsI-0002oP-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:24:54 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196GsH-0002oM-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:24:53 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXKBQ>; Thu, 17 Apr 2003 17:19:40 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA3A4A37@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:19:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] Latest CAS info?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Could someone point me to the latest 
documentation(RFCs and Packages etc) on CAS?
Could RFC 3064 we applied?

Thx,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922 
www.telica.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 17:30:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08946
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 17:30:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HLdsH11214
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 17:39:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLds811211
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 17:39:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08922
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 17:30:06 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Gzh-0002td-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:32:33 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Gzh-0002tZ-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:32:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLam810155;
	Thu, 17 Apr 2003 17:36:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLWE809901
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:32:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08551
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:22:26 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196GsI-0002oP-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:24:54 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196GsH-0002oM-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:24:53 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXKBQ>; Thu, 17 Apr 2003 17:19:40 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA3A4A37@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:19:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] Latest CAS info?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Could someone point me to the latest 
documentation(RFCs and Packages etc) on CAS?
Could RFC 3064 we applied?

Thx,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922 
www.telica.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 17:31:53 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09030
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 17:31:53 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLen811288;
	Thu, 17 Apr 2003 17:40:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLcB811174
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:38:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08852
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:28:23 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Gy3-0002tJ-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:30:51 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Gy2-0002tF-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:30:50 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXKC5>; Thu, 17 Apr 2003 17:25:37 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA3A4A39@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:25:36 -0400
Expiry-Date: Sat, 19 Apr 2003 17:31:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Megaco] Recall: Latest CAS info?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Carl Rutter would like to recall the message, "Latest CAS info?".
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 17:32:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09082
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 17:32:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HLgGG11376
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 17:42:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLgG811373
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 17:42:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09066
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 17:32:28 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H1z-0002v4-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:34:55 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H1z-0002v1-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:34:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLen811288;
	Thu, 17 Apr 2003 17:40:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLcB811174
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:38:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08852
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:28:23 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Gy3-0002tJ-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:30:51 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Gy2-0002tF-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:30:50 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXKC5>; Thu, 17 Apr 2003 17:25:37 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA3A4A39@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:25:36 -0400
Expiry-Date: Sat, 19 Apr 2003 17:31:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Megaco] Recall: Latest CAS info?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Carl Rutter would like to recall the message, "Latest CAS info?".
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 17:33:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09140
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 17:33:55 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLgn811432;
	Thu, 17 Apr 2003 17:42:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLeI811263
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:40:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08944
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:30:30 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H05-0002u3-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:32:57 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H05-0002u0-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:32:57 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXKDD>; Thu, 17 Apr 2003 17:27:44 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA3A4A3A@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:27:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] Latest CAS info?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Could someone point me to the latest 
documentation(RFCs and Packages etc) on CAS?
draft-ietf-megaco-callflows-01.txt the best examples?
Could RFC 3064 be applied?

Thx,
Carl


Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922 
www.telica.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 17:35:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09180
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 17:35:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HLiHI11489
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 17:44:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLiH811486
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 17:44:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09167
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 17:34:29 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H3w-0002vs-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:36:57 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H3w-0002vp-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:36:56 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLgn811432;
	Thu, 17 Apr 2003 17:42:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLeI811263
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:40:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08944
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:30:30 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H05-0002u3-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:32:57 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H05-0002u0-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:32:57 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXKDD>; Thu, 17 Apr 2003 17:27:44 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA3A4A3A@wench.telica.com>
From: Carl Rutter <crutter@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:27:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] Latest CAS info?
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Could someone point me to the latest 
documentation(RFCs and Packages etc) on CAS?
draft-ietf-megaco-callflows-01.txt the best examples?
Could RFC 3064 be applied?

Thx,
Carl


Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922 
www.telica.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 17:41:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09371
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 17:41:20 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLnx811748;
	Thu, 17 Apr 2003 17:49:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLl3811671
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:47:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09242
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:37:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H6c-0002xE-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:39:42 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H6c-0002xA-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:39:42 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXK1A>; Thu, 17 Apr 2003 17:34:28 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA01510346@wench.telica.com>
From: Brad Steinka <bsteinka@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:34:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] Megaco CAS support
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


There were several RFC draft document that described various packages to
support CAS, R1, R2, BCAS, etc.
Most of these drafts have expired.

Can anyone tell me what the latest RFCs are that support CAS calls and where
they are in the standards process?

Thanks

Brad Steinka
Director - Software Engineering
734 Forest Street, Building G, Suite 100
Marlboro, Ma.   01752
Tel:  508-480-0909  x154
Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
Web:   www.telica.com <http://www.telica.com>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 17:42:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09417
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 17:42:59 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HLqHK11935
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 17:52:17 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLqH811932
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 17:52:17 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09401
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 17:41:55 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HB9-0002z6-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:44:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HB8-0002z1-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:44:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLnx811748;
	Thu, 17 Apr 2003 17:49:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLl3811671
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:47:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09242
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:37:15 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H6c-0002xE-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:39:42 -0400
Received: from [4.19.224.196] (helo=wench.telica.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196H6c-0002xA-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:39:42 -0400
Received: by wench.telica.com with Internet Mail Service (5.5.2653.19)
	id <G9PZXK1A>; Thu, 17 Apr 2003 17:34:28 -0400
Message-ID: <C9AFC8E904D49C4593EB077A2E8402BA01510346@wench.telica.com>
From: Brad Steinka <bsteinka@telica.com>
To: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Thu, 17 Apr 2003 17:34:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Megaco] Megaco CAS support
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


There were several RFC draft document that described various packages to
support CAS, R1, R2, BCAS, etc.
Most of these drafts have expired.

Can anyone tell me what the latest RFCs are that support CAS calls and where
they are in the standards process?

Thanks

Brad Steinka
Director - Software Engineering
734 Forest Street, Building G, Suite 100
Marlboro, Ma.   01752
Tel:  508-480-0909  x154
Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
Web:   www.telica.com <http://www.telica.com>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 17:51:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09715
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 17:51:13 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLxq812215;
	Thu, 17 Apr 2003 17:59:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLw0812156
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:58:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09629
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:48:11 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HHD-00031O-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:50:39 -0400
Received: from f29.sea2.hotmail.com ([207.68.165.29] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HHC-000318-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:50:38 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 17 Apr 2003 14:50:22 -0700
Received: from 4.21.34.65 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Thu, 17 Apr 2003 21:50:21 GMT
X-Originating-IP: [4.21.34.65]
X-Originating-Email: [hitesh_vank@hotmail.com]
From: "Hitesh Vankani" <hitesh_vank@hotmail.com>
To: megaco@ietf.org
Subject: Re: [Megaco] Latest CAS info?
Date: Thu, 17 Apr 2003 21:50:21 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Sea2-F29bYiMCIqtQvA000073fc@hotmail.com>
X-OriginalArrivalTime: 17 Apr 2003 21:50:22.0385 (UTC) FILETIME=[588CA210:01C3052B]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

RFC 3064 relates to MGCP CAS package and can be used in case you are 
implementing MGCP.



Regards,
        Hitesh





>From: Carl Rutter <crutter@telica.com>
>To: "'megaco@ietf.org'" <megaco@ietf.org>
>Subject: [Megaco] Latest CAS info?
>Date: Thu, 17 Apr 2003 17:27:43 -0400
>
>Could someone point me to the latest
>documentation(RFCs and Packages etc) on CAS?
>draft-ietf-megaco-callflows-01.txt the best examples?
>Could RFC 3064 be applied?
>
>Thx,
>Carl
>
>
>Carl Rutter
>Telica, Inc.
>Building G, Suite 100
>734 Forest Street
>Marlboro, MA 01752
>Email crutter@telica.com
>Voice 508-480-0909 x8178
>Fax 508-480-0922
>www.telica.com
>
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
Get cool ringtones. Make a statement. http://www.msn.co.in/Mobile/tunes/ Get 
noticed.

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 17:52:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09763
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 17:52:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3HM1aq12413
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 18:01:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HM1Z812410
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 18:01:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09748
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 17:51:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HKg-00032t-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:54:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HKg-00032q-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 17:54:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLxq812215;
	Thu, 17 Apr 2003 17:59:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLw0812156
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 17:58:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09629
	for <megaco@ietf.org>; Thu, 17 Apr 2003 17:48:11 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HHD-00031O-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:50:39 -0400
Received: from f29.sea2.hotmail.com ([207.68.165.29] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 196HHC-000318-00
	for megaco@ietf.org; Thu, 17 Apr 2003 17:50:38 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 17 Apr 2003 14:50:22 -0700
Received: from 4.21.34.65 by sea2fd.sea2.hotmail.msn.com with HTTP;
	Thu, 17 Apr 2003 21:50:21 GMT
X-Originating-IP: [4.21.34.65]
X-Originating-Email: [hitesh_vank@hotmail.com]
From: "Hitesh Vankani" <hitesh_vank@hotmail.com>
To: megaco@ietf.org
Subject: Re: [Megaco] Latest CAS info?
Date: Thu, 17 Apr 2003 21:50:21 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Sea2-F29bYiMCIqtQvA000073fc@hotmail.com>
X-OriginalArrivalTime: 17 Apr 2003 21:50:22.0385 (UTC) FILETIME=[588CA210:01C3052B]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

RFC 3064 relates to MGCP CAS package and can be used in case you are 
implementing MGCP.



Regards,
        Hitesh





>From: Carl Rutter <crutter@telica.com>
>To: "'megaco@ietf.org'" <megaco@ietf.org>
>Subject: [Megaco] Latest CAS info?
>Date: Thu, 17 Apr 2003 17:27:43 -0400
>
>Could someone point me to the latest
>documentation(RFCs and Packages etc) on CAS?
>draft-ietf-megaco-callflows-01.txt the best examples?
>Could RFC 3064 be applied?
>
>Thx,
>Carl
>
>
>Carl Rutter
>Telica, Inc.
>Building G, Suite 100
>734 Forest Street
>Marlboro, MA 01752
>Email crutter@telica.com
>Voice 508-480-0909 x8178
>Fax 508-480-0922
>www.telica.com
>
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
Get cool ringtones. Make a statement. http://www.msn.co.in/Mobile/tunes/ Get 
noticed.

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 17 21:54:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16616
	for <megaco-archive@lists.ietf.org>; Thu, 17 Apr 2003 21:54:11 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I22f827689;
	Thu, 17 Apr 2003 22:02:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I1x2827528
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 21:59:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16536
	for <megaco@ietf.org>; Thu, 17 Apr 2003 21:49:09 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196L2O-00044P-00
	for megaco@ietf.org; Thu, 17 Apr 2003 21:51:36 -0400
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 196L2N-00044A-00
	for megaco@ietf.org; Thu, 17 Apr 2003 21:51:35 -0400
Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3I1pFw11629;
	Thu, 17 Apr 2003 21:51:16 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GDF1JR1C; Thu, 17 Apr 2003 21:51:15 -0400
Received: from nortelnetworks.com (acart1d2.ca.nortel.com [47.129.129.78]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2WPXXQC5; Thu, 17 Apr 2003 21:51:16 -0400
Message-ID: <3E9F5A13.1020102@nortelnetworks.com>
Date: Thu, 17 Apr 2003 21:51:15 -0400
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Majeed Arif-P27336 <Arif.Majeed@motorola.com>
CC: Megaco List <megaco@ietf.org>
Subject: Re: [Megaco] Question about Megaco
References: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0F@az33exm05.corp.mot.com>
In-Reply-To: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0F@az33exm05.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I'd say the first request is valid and appropriate.  You don't have to worry about 
the null context, since all terminations are ephemeral.

Majeed Arif-P27336 wrote:
> Tom,
> 
> I sent this question to the forum but no one reply. I will appreciate your comment.
> 
> The MG has "N" number of boards for bearer processing. The "board1" has four active calls (but has capacity to handle "M" number of calls). All terminations on the MG are ephemeral and are structured like "Term/board1/term1" thru "Term/boardn/termM". The "board1" abruptly goes out of service. Which of the following service change command from MG to MGC is more appropriate or even valid? (Suggestions for improvement are welcomed).
> 
> MEGACO/1 [10.1.33.61]: 25000
>    Transaction = 4321 {
>        Context = * { 
>            ServiceChange = Term/board1/* {Services {
>                Method=Forced }
>                }
>         }
>    } 
> 
> 
> MEGACO/1 [10.1.33.61]: 25000
>    Transaction = 4321 {
>        Context = 678 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>        Context = 977 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>        Context = 1274 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>        Context = 170 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>    }
> 
> Note: All terminations in a context span within the same board in the above example. However, the above command may not be valid when a context contains terminations, which span through out the ROOT. 
> 
> Arif
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 17 21:55:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16636
	for <megaco-archive@odin.ietf.org>; Thu, 17 Apr 2003 21:55:16 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3I24cc27776
	for megaco-archive@odin.ietf.org; Thu, 17 Apr 2003 22:04:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I24c827773
	for <megaco-web-archive@optimus.ietf.org>; Thu, 17 Apr 2003 22:04:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16631
	for <megaco-web-archive@ietf.org>; Thu, 17 Apr 2003 21:54:45 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196L7o-00045q-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 21:57:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196L7n-00045n-00
	for megaco-web-archive@ietf.org; Thu, 17 Apr 2003 21:57:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I22f827689;
	Thu, 17 Apr 2003 22:02:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I1x2827528
	for <megaco@optimus.ietf.org>; Thu, 17 Apr 2003 21:59:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16536
	for <megaco@ietf.org>; Thu, 17 Apr 2003 21:49:09 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196L2O-00044P-00
	for megaco@ietf.org; Thu, 17 Apr 2003 21:51:36 -0400
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by ietf-mx with esmtp (Exim 4.12)
	id 196L2N-00044A-00
	for megaco@ietf.org; Thu, 17 Apr 2003 21:51:35 -0400
Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3I1pFw11629;
	Thu, 17 Apr 2003 21:51:16 -0400 (EDT)
Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id GDF1JR1C; Thu, 17 Apr 2003 21:51:15 -0400
Received: from nortelnetworks.com (acart1d2.ca.nortel.com [47.129.129.78]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id 2WPXXQC5; Thu, 17 Apr 2003 21:51:16 -0400
Message-ID: <3E9F5A13.1020102@nortelnetworks.com>
Date: Thu, 17 Apr 2003 21:51:15 -0400
From: Tom Taylor <taylor@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-ca, en-us, en, fr
MIME-Version: 1.0
To: Majeed Arif-P27336 <Arif.Majeed@motorola.com>
CC: Megaco List <megaco@ietf.org>
Subject: Re: [Megaco] Question about Megaco
References: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0F@az33exm05.corp.mot.com>
In-Reply-To: <7FD24C15A06DD511BF9E00D0B73E9952049DFC0F@az33exm05.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I'd say the first request is valid and appropriate.  You don't have to worry about 
the null context, since all terminations are ephemeral.

Majeed Arif-P27336 wrote:
> Tom,
> 
> I sent this question to the forum but no one reply. I will appreciate your comment.
> 
> The MG has "N" number of boards for bearer processing. The "board1" has four active calls (but has capacity to handle "M" number of calls). All terminations on the MG are ephemeral and are structured like "Term/board1/term1" thru "Term/boardn/termM". The "board1" abruptly goes out of service. Which of the following service change command from MG to MGC is more appropriate or even valid? (Suggestions for improvement are welcomed).
> 
> MEGACO/1 [10.1.33.61]: 25000
>    Transaction = 4321 {
>        Context = * { 
>            ServiceChange = Term/board1/* {Services {
>                Method=Forced }
>                }
>         }
>    } 
> 
> 
> MEGACO/1 [10.1.33.61]: 25000
>    Transaction = 4321 {
>        Context = 678 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>        Context = 977 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>        Context = 1274 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>        Context = 170 { 
>            ServiceChange = * {Services {
>                Method=Forced }
>                }
>         }
>    }
> 
> Note: All terminations in a context span within the same board in the above example. However, the above command may not be valid when a context contains terminations, which span through out the ROOT. 
> 
> Arif
> 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 18 00:54:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19811
	for <megaco-archive@lists.ietf.org>; Fri, 18 Apr 2003 00:54:08 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I52l805792;
	Fri, 18 Apr 2003 01:02:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I4uZ805572
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 00:56:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19731
	for <megaco@ietf.org>; Fri, 18 Apr 2003 00:46:38 -0400 (EDT)
From: klaha@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196No9-0004i8-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:49:05 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 196No7-0004i3-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:49:04 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4kic28105
	for <megaco@ietf.org>; Fri, 18 Apr 2003 10:16:44 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4kg928096;
	Fri, 18 Apr 2003 10:16:42 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4ngh29377;
	Fri, 18 Apr 2003 10:19:42 +0530 (IST)
Subject: Re: [Megaco] Latest CAS info?
To: Carl Rutter <crutter@telica.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Fri, 18 Apr 2003 10:15:28 +0530
Message-ID: <OFEA4240F5.5B4C1423-ON65256D0C.00198833@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 18/04/2003
 10:14:41 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>







RFC 3064 is the MGCP CAS package.

For CAS on MEGACO : the following drafts are applicable.....
(1)
http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
(2) http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
(3) http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt

I hope that helps......

regards,
Kushanava Laha
Hughes Software Systems.





Carl Rutter <crutter@telica.com>@ietf.org on 04/18/2003 02:49:39 AM

Sent by:    megaco-admin@ietf.org


To:    "'megaco@ietf.org'" <megaco@ietf.org>
cc:

Subject:    [Megaco] Latest CAS info?


Could someone point me to the latest
documentation(RFCs and Packages etc) on CAS?
Could RFC 3064 we applied?

Thx,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922
www.telica.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
 https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 18 00:55:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19834
	for <megaco-archive@odin.ietf.org>; Fri, 18 Apr 2003 00:55:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3I54bG05858
	for megaco-archive@odin.ietf.org; Fri, 18 Apr 2003 01:04:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I54b805855
	for <megaco-web-archive@optimus.ietf.org>; Fri, 18 Apr 2003 01:04:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19829
	for <megaco-web-archive@ietf.org>; Fri, 18 Apr 2003 00:54:41 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nvv-0004jN-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 00:57:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nvu-0004jK-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 00:57:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I52l805792;
	Fri, 18 Apr 2003 01:02:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I4uZ805572
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 00:56:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19731
	for <megaco@ietf.org>; Fri, 18 Apr 2003 00:46:38 -0400 (EDT)
From: klaha@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196No9-0004i8-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:49:05 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 196No7-0004i3-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:49:04 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4kic28105
	for <megaco@ietf.org>; Fri, 18 Apr 2003 10:16:44 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4kg928096;
	Fri, 18 Apr 2003 10:16:42 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4ngh29377;
	Fri, 18 Apr 2003 10:19:42 +0530 (IST)
Subject: Re: [Megaco] Latest CAS info?
To: Carl Rutter <crutter@telica.com>
Cc: "'megaco@ietf.org'" <megaco@ietf.org>
Date: Fri, 18 Apr 2003 10:15:28 +0530
Message-ID: <OFEA4240F5.5B4C1423-ON65256D0C.00198833@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 18/04/2003
 10:14:41 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>







RFC 3064 is the MGCP CAS package.

For CAS on MEGACO : the following drafts are applicable.....
(1)
http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
(2) http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
(3) http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt

I hope that helps......

regards,
Kushanava Laha
Hughes Software Systems.





Carl Rutter <crutter@telica.com>@ietf.org on 04/18/2003 02:49:39 AM

Sent by:    megaco-admin@ietf.org


To:    "'megaco@ietf.org'" <megaco@ietf.org>
cc:

Subject:    [Megaco] Latest CAS info?


Could someone point me to the latest
documentation(RFCs and Packages etc) on CAS?
Could RFC 3064 we applied?

Thx,
Carl

Carl Rutter
Telica, Inc.
Building G, Suite 100
734 Forest Street
Marlboro, MA 01752
Email crutter@telica.com
Voice 508-480-0909 x8178
Fax 508-480-0922
www.telica.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
 https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 18 00:56:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19857
	for <megaco-archive@lists.ietf.org>; Fri, 18 Apr 2003 00:56:15 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I54j805877;
	Fri, 18 Apr 2003 01:04:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I51Q805748
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 01:01:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19786
	for <megaco@ietf.org>; Fri, 18 Apr 2003 00:51:29 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nsq-0004in-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:53:56 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nsp-0004iY-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:53:55 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4pZZ29016
	for <megaco@ietf.org>; Fri, 18 Apr 2003 10:21:35 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4pY929005;
	Fri, 18 Apr 2003 10:21:34 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4sXR29810;
	Fri, 18 Apr 2003 10:24:34 +0530 (IST)
Subject: Re: [Megaco] trigger for Null context to include terminations
To: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Cc: megaco@ietf.org
Date: Fri, 18 Apr 2003 10:19:20 +0530
Message-ID: <OFF8AAF018.EB90F9D6-ON65256D0C.00195CE0@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 18/04/2003
 10:19:31 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>






Hi Susumu
      Well I think its all implementation dependant and I will again
reiterate that a termination
not in valid context is considered to be in a Null context.

Also find my comment below:[bvswamy].

Regards
Venkat





"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
03:23:59 PM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org
cc:

Subject:    Re: [Megaco] trigger for Null context to include terminations


Hi Venkat,

Thank you for your help.

ServiceChange (restart) should be sent when the terminations have
just returned to the service from section 7.2.8 of MEGACO, therefore
I think we have no indication just when the terminations show up in
Null context along your suggestion.

In effect the terminations which are configured but not in-service yet
could not detect any events on them in the conventional TDM or ATM.
And I think that we have no need to set any parameters on them if
they cannot make any calls or detect any events...

I am confused what the need is for physical terminations not in-service
yet to be kept in Null context ?
[bvswamy]--  Here i think it will be useful to put such terminations in
null context
            if an Audit comes for a wildcard terminations. Here the purpose
of MGC is
            get the terminations which are there in MG and to know about
there state(may
            be due to switchover). Now in this case if the terminations is
not in null context
            then the response message would not carry the information about
this termination and
            MGC will not able to modify the state of this termination if it
had previously put
            it in the Out-of-service state.


It may be good for terminations fault but not taken out-of-service
manually yet to be kept in Null context though.

It seems natural that the terminations show up after the Service
Change(restart) is sent...

Could you please tell me your idea ?

Thanks,
-Susumu

---
>Hi
>
>       In my view:
>       All the physical terminations that are configured and not in a
valid
>context are in
>Null context. Hence configuration commands  can taken as triggers for
>terminations appearing/disappearing
>from a Null context . This is further clarified with the following
>specification statement:
>" Terminations in the null Context can have their parameters examined
>    or modified, and may have events detected on them"
>so even  a service change request requires a terminations to be present in
>a null context also.
>
>
>Regards
>Venkat
>
>"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
>10:11:39 AM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:
>
>Subject:    [Megaco] trigger for Null context to include terminations
>
>
>Hi all,
>
>I have a question regarding the trigger for Null context to include
>specific TerminationIDs in an MG.
>
>In general, we have some phases to provide call operation capability
>in an MG after starting the MG, that is (a) to mount physical channels
>with configuration commands and (b) to take the physical channels into
>service state with specific commands.
>
>Which should be a trigger that the corresponding physical TerminationIDs
>show up in Null context in the MG ?
>
>Also when we stop the service on specific physical terminations,
>we may at first take the terminations out of service with commands
>temporarily, and in the second we may dismount the termination to
>delete these from configuration files.
>
>Which should be a trigger that the corresponding physical TerminaionIDs
>disappeared from Null context ?
>
>I think that we may have both choices in both cases above along the
>MEGACO standard. It seems that we have no description regarding
>this in, and this would be a implementation matter.
>
>Please let me know your idea.
>
>Thanks,
>-Susumu
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
 https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 18 00:57:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19877
	for <megaco-archive@odin.ietf.org>; Fri, 18 Apr 2003 00:57:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3I56iC05928
	for megaco-archive@odin.ietf.org; Fri, 18 Apr 2003 01:06:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I56i805925
	for <megaco-web-archive@optimus.ietf.org>; Fri, 18 Apr 2003 01:06:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19872
	for <megaco-web-archive@ietf.org>; Fri, 18 Apr 2003 00:56:49 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nxy-0004ja-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 00:59:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nxy-0004jX-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 00:59:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I54j805877;
	Fri, 18 Apr 2003 01:04:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I51Q805748
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 01:01:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19786
	for <megaco@ietf.org>; Fri, 18 Apr 2003 00:51:29 -0400 (EDT)
From: bvswamy@hss.hns.com
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nsq-0004in-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:53:56 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 196Nsp-0004iY-00
	for megaco@ietf.org; Fri, 18 Apr 2003 00:53:55 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4pZZ29016
	for <megaco@ietf.org>; Fri, 18 Apr 2003 10:21:35 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4pY929005;
	Fri, 18 Apr 2003 10:21:34 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3I4sXR29810;
	Fri, 18 Apr 2003 10:24:34 +0530 (IST)
Subject: Re: [Megaco] trigger for Null context to include terminations
To: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Cc: megaco@ietf.org
Date: Fri, 18 Apr 2003 10:19:20 +0530
Message-ID: <OFF8AAF018.EB90F9D6-ON65256D0C.00195CE0@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 18/04/2003
 10:19:31 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>






Hi Susumu
      Well I think its all implementation dependant and I will again
reiterate that a termination
not in valid context is considered to be in a Null context.

Also find my comment below:[bvswamy].

Regards
Venkat





"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
03:23:59 PM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org
cc:

Subject:    Re: [Megaco] trigger for Null context to include terminations


Hi Venkat,

Thank you for your help.

ServiceChange (restart) should be sent when the terminations have
just returned to the service from section 7.2.8 of MEGACO, therefore
I think we have no indication just when the terminations show up in
Null context along your suggestion.

In effect the terminations which are configured but not in-service yet
could not detect any events on them in the conventional TDM or ATM.
And I think that we have no need to set any parameters on them if
they cannot make any calls or detect any events...

I am confused what the need is for physical terminations not in-service
yet to be kept in Null context ?
[bvswamy]--  Here i think it will be useful to put such terminations in
null context
            if an Audit comes for a wildcard terminations. Here the purpose
of MGC is
            get the terminations which are there in MG and to know about
there state(may
            be due to switchover). Now in this case if the terminations is
not in null context
            then the response message would not carry the information about
this termination and
            MGC will not able to modify the state of this termination if it
had previously put
            it in the Out-of-service state.


It may be good for terminations fault but not taken out-of-service
manually yet to be kept in Null context though.

It seems natural that the terminations show up after the Service
Change(restart) is sent...

Could you please tell me your idea ?

Thanks,
-Susumu

---
>Hi
>
>       In my view:
>       All the physical terminations that are configured and not in a
valid
>context are in
>Null context. Hence configuration commands  can taken as triggers for
>terminations appearing/disappearing
>from a Null context . This is further clarified with the following
>specification statement:
>" Terminations in the null Context can have their parameters examined
>    or modified, and may have events detected on them"
>so even  a service change request requires a terminations to be present in
>a null context also.
>
>
>Regards
>Venkat
>
>"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
>10:11:39 AM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:
>
>Subject:    [Megaco] trigger for Null context to include terminations
>
>
>Hi all,
>
>I have a question regarding the trigger for Null context to include
>specific TerminationIDs in an MG.
>
>In general, we have some phases to provide call operation capability
>in an MG after starting the MG, that is (a) to mount physical channels
>with configuration commands and (b) to take the physical channels into
>service state with specific commands.
>
>Which should be a trigger that the corresponding physical TerminationIDs
>show up in Null context in the MG ?
>
>Also when we stop the service on specific physical terminations,
>we may at first take the terminations out of service with commands
>temporarily, and in the second we may dismount the termination to
>delete these from configuration files.
>
>Which should be a trigger that the corresponding physical TerminaionIDs
>disappeared from Null context ?
>
>I think that we may have both choices in both cases above along the
>MEGACO standard. It seems that we have no description regarding
>this in, and this would be a implementation matter.
>
>Please let me know your idea.
>
>Thanks,
>-Susumu
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
 https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 18 07:25:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08885
	for <megaco-archive@lists.ietf.org>; Fri, 18 Apr 2003 07:25:25 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBXp807881;
	Fri, 18 Apr 2003 07:33:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBUQ807729
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 07:30:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08688
	for <megaco@ietf.org>; Fri, 18 Apr 2003 07:20:22 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tx9-0006Q0-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:22:47 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tx9-0006Px-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:22:47 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBN1Zb021956
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:23:01 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBN0qs022440
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:23:00 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBN0TT017353
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:23:00 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA11871
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:22:59 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA07765
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:22:59 +0900 (JST)
Message-Id: <5.0.2.7.2.20030418202147.06375ec8@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Fri, 18 Apr 2003 20:24:18 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] trigger for Null context to include terminations
In-Reply-To: <OFF8AAF018.EB90F9D6-ON65256D0C.00195CE0@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi Venkat,

Yes, I think your idea is better, and I agree with you.
I appreciate your kind help.

Thanks,
-Susumu

---
>Hi Susumu
>       Well I think its all implementation dependant and I will again
>reiterate that a termination
>not in valid context is considered to be in a Null context.
>
>Also find my comment below:[bvswamy].
>
>Regards
>Venkat
>
>
>
>
>
>"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
>03:23:59 PM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:
>
>Subject:    Re: [Megaco] trigger for Null context to include terminations
>
>
>Hi Venkat,
>
>Thank you for your help.
>
>ServiceChange (restart) should be sent when the terminations have
>just returned to the service from section 7.2.8 of MEGACO, therefore
>I think we have no indication just when the terminations show up in
>Null context along your suggestion.
>
>In effect the terminations which are configured but not in-service yet
>could not detect any events on them in the conventional TDM or ATM.
>And I think that we have no need to set any parameters on them if
>they cannot make any calls or detect any events...
>
>I am confused what the need is for physical terminations not in-service
>yet to be kept in Null context ?
>[bvswamy]--  Here i think it will be useful to put such terminations in
>null context
>             if an Audit comes for a wildcard terminations. Here the purpose
>of MGC is
>             get the terminations which are there in MG and to know about
>there state(may
>             be due to switchover). Now in this case if the terminations is
>not in null context
>             then the response message would not carry the information about
>this termination and
>             MGC will not able to modify the state of this termination if it
>had previously put
>             it in the Out-of-service state.
>
>
>It may be good for terminations fault but not taken out-of-service
>manually yet to be kept in Null context though.
>
>It seems natural that the terminations show up after the Service
>Change(restart) is sent...
>
>Could you please tell me your idea ?
>
>Thanks,
>-Susumu
>
>---
> >Hi
> >
> >       In my view:
> >       All the physical terminations that are configured and not in a
>valid
> >context are in
> >Null context. Hence configuration commands  can taken as triggers for
> >terminations appearing/disappearing
> >from a Null context . This is further clarified with the following
> >specification statement:
> >" Terminations in the null Context can have their parameters examined
> >    or modified, and may have events detected on them"
> >so even  a service change request requires a terminations to be present in
> >a null context also.
> >
> >
> >Regards
> >Venkat
> >
> >"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
> >10:11:39 AM
> >
> >Sent by:    megaco-admin@ietf.org
> >
> >
> >To:    megaco@ietf.org
> >cc:
> >
> >Subject:    [Megaco] trigger for Null context to include terminations
> >
> >
> >Hi all,
> >
> >I have a question regarding the trigger for Null context to include
> >specific TerminationIDs in an MG.
> >
> >In general, we have some phases to provide call operation capability
> >in an MG after starting the MG, that is (a) to mount physical channels
> >with configuration commands and (b) to take the physical channels into
> >service state with specific commands.
> >
> >Which should be a trigger that the corresponding physical TerminationIDs
> >show up in Null context in the MG ?
> >
> >Also when we stop the service on specific physical terminations,
> >we may at first take the terminations out of service with commands
> >temporarily, and in the second we may dismount the termination to
> >delete these from configuration files.
> >
> >Which should be a trigger that the corresponding physical TerminaionIDs
> >disappeared from Null context ?
> >
> >I think that we may have both choices in both cases above along the
> >MEGACO standard. It seems that we have no description regarding
> >this in, and this would be a implementation matter.
> >
> >Please let me know your idea.
> >
> >Thanks,
> >-Susumu
> >
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >  https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco

-*-*-*-
SUSUMU YAMAMOTO, NTT Corporation


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 18 07:26:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09241
	for <megaco-archive@odin.ietf.org>; Fri, 18 Apr 2003 07:26:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3IBaIV08028
	for megaco-archive@odin.ietf.org; Fri, 18 Apr 2003 07:36:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBaI808025
	for <megaco-web-archive@optimus.ietf.org>; Fri, 18 Apr 2003 07:36:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09111
	for <megaco-web-archive@ietf.org>; Fri, 18 Apr 2003 07:26:14 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196U2p-0006Uq-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 07:28:39 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196U2p-0006Un-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 07:28:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBXp807881;
	Fri, 18 Apr 2003 07:33:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBUQ807729
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 07:30:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08688
	for <megaco@ietf.org>; Fri, 18 Apr 2003 07:20:22 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tx9-0006Q0-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:22:47 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tx9-0006Px-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:22:47 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBN1Zb021956
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:23:01 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBN0qs022440
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:23:00 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBN0TT017353
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:23:00 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA11871
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:22:59 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA07765
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:22:59 +0900 (JST)
Message-Id: <5.0.2.7.2.20030418202147.06375ec8@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Fri, 18 Apr 2003 20:24:18 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] trigger for Null context to include terminations
In-Reply-To: <OFF8AAF018.EB90F9D6-ON65256D0C.00195CE0@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi Venkat,

Yes, I think your idea is better, and I agree with you.
I appreciate your kind help.

Thanks,
-Susumu

---
>Hi Susumu
>       Well I think its all implementation dependant and I will again
>reiterate that a termination
>not in valid context is considered to be in a Null context.
>
>Also find my comment below:[bvswamy].
>
>Regards
>Venkat
>
>
>
>
>
>"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
>03:23:59 PM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org
>cc:
>
>Subject:    Re: [Megaco] trigger for Null context to include terminations
>
>
>Hi Venkat,
>
>Thank you for your help.
>
>ServiceChange (restart) should be sent when the terminations have
>just returned to the service from section 7.2.8 of MEGACO, therefore
>I think we have no indication just when the terminations show up in
>Null context along your suggestion.
>
>In effect the terminations which are configured but not in-service yet
>could not detect any events on them in the conventional TDM or ATM.
>And I think that we have no need to set any parameters on them if
>they cannot make any calls or detect any events...
>
>I am confused what the need is for physical terminations not in-service
>yet to be kept in Null context ?
>[bvswamy]--  Here i think it will be useful to put such terminations in
>null context
>             if an Audit comes for a wildcard terminations. Here the purpose
>of MGC is
>             get the terminations which are there in MG and to know about
>there state(may
>             be due to switchover). Now in this case if the terminations is
>not in null context
>             then the response message would not carry the information about
>this termination and
>             MGC will not able to modify the state of this termination if it
>had previously put
>             it in the Out-of-service state.
>
>
>It may be good for terminations fault but not taken out-of-service
>manually yet to be kept in Null context though.
>
>It seems natural that the terminations show up after the Service
>Change(restart) is sent...
>
>Could you please tell me your idea ?
>
>Thanks,
>-Susumu
>
>---
> >Hi
> >
> >       In my view:
> >       All the physical terminations that are configured and not in a
>valid
> >context are in
> >Null context. Hence configuration commands  can taken as triggers for
> >terminations appearing/disappearing
> >from a Null context . This is further clarified with the following
> >specification statement:
> >" Terminations in the null Context can have their parameters examined
> >    or modified, and may have events detected on them"
> >so even  a service change request requires a terminations to be present in
> >a null context also.
> >
> >
> >Regards
> >Venkat
> >
> >"YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>@ietf.org on 04/17/2003
> >10:11:39 AM
> >
> >Sent by:    megaco-admin@ietf.org
> >
> >
> >To:    megaco@ietf.org
> >cc:
> >
> >Subject:    [Megaco] trigger for Null context to include terminations
> >
> >
> >Hi all,
> >
> >I have a question regarding the trigger for Null context to include
> >specific TerminationIDs in an MG.
> >
> >In general, we have some phases to provide call operation capability
> >in an MG after starting the MG, that is (a) to mount physical channels
> >with configuration commands and (b) to take the physical channels into
> >service state with specific commands.
> >
> >Which should be a trigger that the corresponding physical TerminationIDs
> >show up in Null context in the MG ?
> >
> >Also when we stop the service on specific physical terminations,
> >we may at first take the terminations out of service with commands
> >temporarily, and in the second we may dismount the termination to
> >delete these from configuration files.
> >
> >Which should be a trigger that the corresponding physical TerminaionIDs
> >disappeared from Null context ?
> >
> >I think that we may have both choices in both cases above along the
> >MEGACO standard. It seems that we have no description regarding
> >this in, and this would be a implementation matter.
> >
> >Please let me know your idea.
> >
> >Thanks,
> >-Susumu
> >
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >  https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>  https://www1.ietf.org/mailman/listinfo/megaco

-*-*-*-
SUSUMU YAMAMOTO, NTT Corporation


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 18 07:27:15 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09330
	for <megaco-archive@lists.ietf.org>; Fri, 18 Apr 2003 07:27:15 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBZl807963;
	Fri, 18 Apr 2003 07:35:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBRr807541
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 07:27:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08571
	for <megaco@ietf.org>; Fri, 18 Apr 2003 07:17:50 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tuh-0006PN-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:20:15 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tug-0006PK-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:20:14 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBKRZb021746
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:27 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBKRqs022219
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:27 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBKQTT017025
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:26 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA11729
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:26 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA07527
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:25 +0900 (JST)
Message-Id: <5.0.2.7.2.20030418201413.03d89bf0@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Fri, 18 Apr 2003 20:21:43 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] AuditReply from MG with no specific context
In-Reply-To: <5.0.2.7.2.20030417112226.061cdec8@imb.m.ecl.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi.

Could you please give me any suggestion along your implementation for
this issue ?

It seems that every reply should not challenge the megaco standard,
and the error reply of "No TerminationID matched a wildcard" would be
possible.

Thanks in advance,
-Susumu

---
>Hi all,
>
>What type of reply message should the MG with no specific context
>send back to the MGC, when receiving an AuditValue message with
>ContextID=ALL and TerminationID=ROOT ?
>
>I think we may have some choices for that, that is (a) command reply
>with the audit list contains no information, (b) command reply contains
>no information, and (c) action reply contains no information.
>
>Is there any syntax error in each choice above ?
>And which is the best choice from above or any other solutions ?
>
>Thanks,
>-Susumu


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 18 07:28:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09427
	for <megaco-archive@odin.ietf.org>; Fri, 18 Apr 2003 07:28:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3IBbq009108
	for megaco-archive@odin.ietf.org; Fri, 18 Apr 2003 07:37:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBbq809105
	for <megaco-web-archive@optimus.ietf.org>; Fri, 18 Apr 2003 07:37:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09389
	for <megaco-web-archive@ietf.org>; Fri, 18 Apr 2003 07:27:48 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196U4L-0006ZF-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 07:30:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 196U4L-0006ZC-00
	for megaco-web-archive@ietf.org; Fri, 18 Apr 2003 07:30:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBZl807963;
	Fri, 18 Apr 2003 07:35:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IBRr807541
	for <megaco@optimus.ietf.org>; Fri, 18 Apr 2003 07:27:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08571
	for <megaco@ietf.org>; Fri, 18 Apr 2003 07:17:50 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tuh-0006PN-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:20:15 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 196Tug-0006PK-00
	for megaco@ietf.org; Fri, 18 Apr 2003 07:20:14 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBKRZb021746
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:27 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBKRqs022219
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:27 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3IBKQTT017025
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:26 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA11729
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:26 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id UAA07527
	for <megaco@ietf.org>; Fri, 18 Apr 2003 20:20:25 +0900 (JST)
Message-Id: <5.0.2.7.2.20030418201413.03d89bf0@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Fri, 18 Apr 2003 20:21:43 +0900
To: megaco@ietf.org
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] AuditReply from MG with no specific context
In-Reply-To: <5.0.2.7.2.20030417112226.061cdec8@imb.m.ecl.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi.

Could you please give me any suggestion along your implementation for
this issue ?

It seems that every reply should not challenge the megaco standard,
and the error reply of "No TerminationID matched a wildcard" would be
possible.

Thanks in advance,
-Susumu

---
>Hi all,
>
>What type of reply message should the MG with no specific context
>send back to the MGC, when receiving an AuditValue message with
>ContextID=ALL and TerminationID=ROOT ?
>
>I think we may have some choices for that, that is (a) command reply
>with the audit list contains no information, (b) command reply contains
>no information, and (c) action reply contains no information.
>
>Is there any syntax error in each choice above ?
>And which is the best choice from above or any other solutions ?
>
>Thanks,
>-Susumu


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 04:59:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08045
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 04:59:35 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3L98K814516;
	Mon, 21 Apr 2003 05:08:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3L925813541
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 05:02:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08004
	for <megaco@ietf.org>; Mon, 21 Apr 2003 04:50:37 -0400 (EDT)
From: hektor@etri.re.kr
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197X2o-0006Z7-00
	for megaco@ietf.org; Mon, 21 Apr 2003 04:52:58 -0400
Received: from cms3.etri.re.kr ([129.254.16.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 197X2o-0006Z4-00
	for megaco@ietf.org; Mon, 21 Apr 2003 04:52:58 -0400
Received: by cms3 with Internet Mail Service (5.5.2653.19)
	id <JHJ52YYJ>; Mon, 21 Apr 2003 17:52:57 +0900
Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA532@cms3>
To: megaco@ietf.org
Date: Mon, 21 Apr 2003 17:52:56 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C307E3.66F29390"
Subject: [Megaco] [Question] About unrequested event notification
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C307E3.66F29390
Content-Type: text/plain;
	charset="euc-kr"

G'day.

If a MG send a event notification which is not requested by a MGC,
What shall the MGC do?

TIA.

------_=_NextPart_001_01C307E3.66F29390
Content-Type: text/html;
	charset="euc-kr"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>[Question] About unrequested event notification</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>G'day.</FONT>
</P>

<P><FONT SIZE=2>If a MG send a event notification which is not requested by a MGC,</FONT>
<BR><FONT SIZE=2>What shall the MGC do?</FONT>
</P>

<P><FONT SIZE=2>TIA.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C307E3.66F29390--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 05:00:58 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08098
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 05:00:57 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3L9BuK14586
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 05:11:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3L9Bt814583
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 05:11:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08080
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 05:00:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197XCK-0006Zv-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 05:02:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197XCE-0006Zq-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 05:02:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3L98K814516;
	Mon, 21 Apr 2003 05:08:20 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3L925813541
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 05:02:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08004
	for <megaco@ietf.org>; Mon, 21 Apr 2003 04:50:37 -0400 (EDT)
From: hektor@etri.re.kr
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197X2o-0006Z7-00
	for megaco@ietf.org; Mon, 21 Apr 2003 04:52:58 -0400
Received: from cms3.etri.re.kr ([129.254.16.13])
	by ietf-mx with esmtp (Exim 4.12)
	id 197X2o-0006Z4-00
	for megaco@ietf.org; Mon, 21 Apr 2003 04:52:58 -0400
Received: by cms3 with Internet Mail Service (5.5.2653.19)
	id <JHJ52YYJ>; Mon, 21 Apr 2003 17:52:57 +0900
Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A5DA532@cms3>
To: megaco@ietf.org
Date: Mon, 21 Apr 2003 17:52:56 +0900
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C307E3.66F29390"
Subject: [Megaco] [Question] About unrequested event notification
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C307E3.66F29390
Content-Type: text/plain;
	charset="euc-kr"

G'day.

If a MG send a event notification which is not requested by a MGC,
What shall the MGC do?

TIA.

------_=_NextPart_001_01C307E3.66F29390
Content-Type: text/html;
	charset="euc-kr"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>[Question] About unrequested event notification</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>G'day.</FONT>
</P>

<P><FONT SIZE=2>If a MG send a event notification which is not requested by a MGC,</FONT>
<BR><FONT SIZE=2>What shall the MGC do?</FONT>
</P>

<P><FONT SIZE=2>TIA.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C307E3.66F29390--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 07:58:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11541
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 07:58:05 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC86825009;
	Mon, 21 Apr 2003 08:08:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC3b823695
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 08:03:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10711
	for <megaco@ietf.org>; Mon, 21 Apr 2003 07:52:04 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197ZsR-000705-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:54:27 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 197ZsQ-000700-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:54:26 -0400
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3LBslI3007274;
	Mon, 21 Apr 2003 13:54:47 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JDV2CCGA; Mon, 21 Apr 2003 13:54:48 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3LBsmR6019203;
	Mon, 21 Apr 2003 14:54:48 +0300 (EET DST)
Message-ID: <3EA3DC35.622CE714@lmf.ericsson.se>
Date: Mon, 21 Apr 2003 14:55:33 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
CC: megaco@ietf.org
Subject: Re: [Megaco] AuditReply from MG with no specific context
References: <5.0.2.7.2.20030418201413.03d89bf0@imb.m.ecl.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> Could you please give me any suggestion along your implementation for
> this issue ?
>
> It seems that every reply should not challenge the megaco standard,
> and the error reply of "No TerminationID matched a wildcard" would be
> possible.

I guess you could send that. "Protocol error" would be another option, I'd
say...

Regards,

Christer Holmberg
Ericsson Finland


>
>
> Thanks in advance,
> -Susumu
>
> ---
> >Hi all,
> >
> >What type of reply message should the MG with no specific context
> >send back to the MGC, when receiving an AuditValue message with
> >ContextID=ALL and TerminationID=ROOT ?
> >
> >I think we may have some choices for that, that is (a) command reply
> >with the audit list contains no information, (b) command reply contains
> >no information, and (c) action reply contains no information.
> >
> >Is there any syntax error in each choice above ?
> >And which is the best choice from above or any other solutions ?
> >
> >Thanks,
> >-Susumu
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 07:59:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11639
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 07:59:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LCAGh25161
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 08:10:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LCAG825158
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 08:10:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11607
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 07:58:42 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zyr-0007Gw-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 08:01:05 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zyq-0007Gs-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 08:01:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC86825009;
	Mon, 21 Apr 2003 08:08:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC3b823695
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 08:03:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10711
	for <megaco@ietf.org>; Mon, 21 Apr 2003 07:52:04 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197ZsR-000705-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:54:27 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 197ZsQ-000700-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:54:26 -0400
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3LBslI3007274;
	Mon, 21 Apr 2003 13:54:47 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JDV2CCGA; Mon, 21 Apr 2003 13:54:48 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3LBsmR6019203;
	Mon, 21 Apr 2003 14:54:48 +0300 (EET DST)
Message-ID: <3EA3DC35.622CE714@lmf.ericsson.se>
Date: Mon, 21 Apr 2003 14:55:33 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
CC: megaco@ietf.org
Subject: Re: [Megaco] AuditReply from MG with no specific context
References: <5.0.2.7.2.20030418201413.03d89bf0@imb.m.ecl.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi,

> Could you please give me any suggestion along your implementation for
> this issue ?
>
> It seems that every reply should not challenge the megaco standard,
> and the error reply of "No TerminationID matched a wildcard" would be
> possible.

I guess you could send that. "Protocol error" would be another option, I'd
say...

Regards,

Christer Holmberg
Ericsson Finland


>
>
> Thanks in advance,
> -Susumu
>
> ---
> >Hi all,
> >
> >What type of reply message should the MG with no specific context
> >send back to the MGC, when receiving an AuditValue message with
> >ContextID=ALL and TerminationID=ROOT ?
> >
> >I think we may have some choices for that, that is (a) command reply
> >with the audit list contains no information, (b) command reply contains
> >no information, and (c) action reply contains no information.
> >
> >Is there any syntax error in each choice above ?
> >And which is the best choice from above or any other solutions ?
> >
> >Thanks,
> >-Susumu
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 08:00:51 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11892
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 08:00:51 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LCB6825200;
	Mon, 21 Apr 2003 08:11:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC76824348
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 08:07:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11398
	for <megaco@ietf.org>; Mon, 21 Apr 2003 07:55:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zvn-0007CN-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:57:55 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zvn-0007CK-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:57:55 -0400
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3LBwFRs017494;
	Mon, 21 Apr 2003 13:58:15 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JBTAH82F; Mon, 21 Apr 2003 13:58:13 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3LBvxR6019441;
	Mon, 21 Apr 2003 14:57:59 +0300 (EET DST)
Message-ID: <3EA3DCF4.5F48CCA0@lmf.ericsson.se>
Date: Mon, 21 Apr 2003 14:58:44 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fhuval Hittay <fhuval@rambler.ru>
CC: megaco@ietf.org
Subject: Re: [Megaco] using UDP in MEGACO
References: <3E9BF091.AA16406@mb3.rambler.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi,

> could anyone answer how could be avoided wrong sequence of received MEGACO
> messages when using UDP as a transport mechanism?

I think the only answer to this is: don't send another message (at least not
if it contains actions for the same Context(s)/Termination(s) as the previous
message) until you have received an answer for the previous message.

Regards,

Christer Holmberg
Ericsson Finland


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 08:01:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11992
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 08:01:58 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LCD1w25338
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 08:13:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LCD1825335
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 08:13:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11955
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 08:01:27 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197a1W-0007Nc-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 08:03:50 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197a1W-0007NZ-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 08:03:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LCB6825200;
	Mon, 21 Apr 2003 08:11:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC76824348
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 08:07:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11398
	for <megaco@ietf.org>; Mon, 21 Apr 2003 07:55:32 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zvn-0007CN-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:57:55 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 197Zvn-0007CK-00
	for megaco@ietf.org; Mon, 21 Apr 2003 07:57:55 -0400
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125])
	by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3LBwFRs017494;
	Mon, 21 Apr 2003 13:58:15 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JBTAH82F; Mon, 21 Apr 2003 13:58:13 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3LBvxR6019441;
	Mon, 21 Apr 2003 14:57:59 +0300 (EET DST)
Message-ID: <3EA3DCF4.5F48CCA0@lmf.ericsson.se>
Date: Mon, 21 Apr 2003 14:58:44 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fhuval Hittay <fhuval@rambler.ru>
CC: megaco@ietf.org
Subject: Re: [Megaco] using UDP in MEGACO
References: <3E9BF091.AA16406@mb3.rambler.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi,

> could anyone answer how could be avoided wrong sequence of received MEGACO
> messages when using UDP as a transport mechanism?

I think the only answer to this is: don't send another message (at least not
if it contains actions for the same Context(s)/Termination(s) as the previous
message) until you have received an answer for the previous message.

Regards,

Christer Holmberg
Ericsson Finland


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 09:28:04 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14585
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 09:28:04 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LDb4830101;
	Mon, 21 Apr 2003 09:37:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LDXM829826
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 09:33:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14484
	for <megaco@ietf.org>; Mon, 21 Apr 2003 09:21:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197bHG-0000Fc-00
	for megaco@ietf.org; Mon, 21 Apr 2003 09:24:10 -0400
Received: from shardagate.mahindrabt.com ([203.124.158.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 197bHE-0000FZ-00
	for megaco@ietf.org; Mon, 21 Apr 2003 09:24:09 -0400
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3LDOH4L013901
	for <megaco@ietf.org>; Mon, 21 Apr 2003 18:54:23 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Mon, 21 Apr 2003 18:40:03 +0530
Date: Mon, 21 Apr 2003 18:40:03 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: anilj@mahindrabt.com
Received: from dscp00986 ([10.5.6.22])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA24988;
	Mon, 21 Apr 2003 18:54:01 +0530
Message-ID: <006f01c30809$f2b85380$1606050a@mahindrabt.com>
From: "Anil Jangam" <anilj@mahindrabt.com>
To: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>,
        "Fhuval Hittay" <fhuval@rambler.ru>
Cc: <megaco@ietf.org>, "Tom-PT Taylor" <taylor@nortelnetworks.com>
References: <3E9BF091.AA16406@mb3.rambler.ru> <3EA3DCF4.5F48CCA0@lmf.ericsson.se>
Subject: Re: [Megaco] using UDP in MEGACO
Date: Mon, 21 Apr 2003 18:58:50 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Christer ,

What about the use the ALF (which also recommended when used UDP as
Transport)??
Use of ALF can solve the sequencing problem in UDP.

/anil.

----- Original Message -----
From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
To: "Fhuval Hittay" <fhuval@rambler.ru>
Cc: <megaco@ietf.org>
Sent: Monday, April 21, 2003 5:56 PM
Subject: Re: [Megaco] using UDP in MEGACO

>
> Hi,
>
> > could anyone answer how could be avoided wrong sequence of received
MEGACO
> > messages when using UDP as a transport mechanism?
>
> I think the only answer to this is: don't send another message (at least
not
> if it contains actions for the same Context(s)/Termination(s) as the
previous
> message) until you have received an answer for the previous message.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 09:29:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14623
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 09:29:13 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LDeIZ30966
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 09:40:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LDeI830963
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 09:40:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14614
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 09:28:43 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197bNy-0000Hi-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 09:31:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197bNx-0000Hf-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 09:31:05 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LDb4830101;
	Mon, 21 Apr 2003 09:37:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LDXM829826
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 09:33:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14484
	for <megaco@ietf.org>; Mon, 21 Apr 2003 09:21:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197bHG-0000Fc-00
	for megaco@ietf.org; Mon, 21 Apr 2003 09:24:10 -0400
Received: from shardagate.mahindrabt.com ([203.124.158.2])
	by ietf-mx with esmtp (Exim 4.12)
	id 197bHE-0000FZ-00
	for megaco@ietf.org; Mon, 21 Apr 2003 09:24:09 -0400
Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97])
	by shardagate.mahindrabt.com (8.12.8/8.12.8) with ESMTP id h3LDOH4L013901
	for <megaco@ietf.org>; Mon, 21 Apr 2003 18:54:23 +0530
Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Mon, 21 Apr 2003 18:40:03 +0530
Date: Mon, 21 Apr 2003 18:40:03 +0530
X-Originating-IP: 10.5.0.15
X-Auth-User: anilj@mahindrabt.com
Received: from dscp00986 ([10.5.6.22])
	by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with SMTP id SAA24988;
	Mon, 21 Apr 2003 18:54:01 +0530
Message-ID: <006f01c30809$f2b85380$1606050a@mahindrabt.com>
From: "Anil Jangam" <anilj@mahindrabt.com>
To: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>,
        "Fhuval Hittay" <fhuval@rambler.ru>
Cc: <megaco@ietf.org>, "Tom-PT Taylor" <taylor@nortelnetworks.com>
References: <3E9BF091.AA16406@mb3.rambler.ru> <3EA3DCF4.5F48CCA0@lmf.ericsson.se>
Subject: Re: [Megaco] using UDP in MEGACO
Date: Mon, 21 Apr 2003 18:58:50 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Christer ,

What about the use the ALF (which also recommended when used UDP as
Transport)??
Use of ALF can solve the sequencing problem in UDP.

/anil.

----- Original Message -----
From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
To: "Fhuval Hittay" <fhuval@rambler.ru>
Cc: <megaco@ietf.org>
Sent: Monday, April 21, 2003 5:56 PM
Subject: Re: [Megaco] using UDP in MEGACO

>
> Hi,
>
> > could anyone answer how could be avoided wrong sequence of received
MEGACO
> > messages when using UDP as a transport mechanism?
>
> I think the only answer to this is: don't send another message (at least
not
> if it contains actions for the same Context(s)/Termination(s) as the
previous
> message) until you have received an answer for the previous message.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 11:02:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18898
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 11:02:25 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LFC4804424;
	Mon, 21 Apr 2003 11:12:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LF8s804305
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 11:08:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18751
	for <megaco@ietf.org>; Mon, 21 Apr 2003 10:57:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197clf-0000m0-00
	for megaco@ietf.org; Mon, 21 Apr 2003 10:59:39 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 197clf-0000lw-00
	for megaco@ietf.org; Mon, 21 Apr 2003 10:59:39 -0400
Received: from cisco.com (sjc-vpn3-426.cisco.com [10.21.65.170])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3LExSgE012995
	for <megaco@ietf.org>; Mon, 21 Apr 2003 07:59:29 -0700 (PDT)
Message-ID: <3EA4074F.ADAFD2D9@cisco.com>
Date: Mon, 21 Apr 2003 10:59:27 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Megaco <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Support for redundant MG failover
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Megaco supports some notion of redundant MGs and redundant MG failover,
however there is very little normative language, let alone explanation
of how this is supposed to work (and the current incarnation of the
upcoming Annex F doesn't help much here). The only model described is
the one in Section 11.4, where both the primary and secondary MG are
fully visible at all times and the MGC has to send duplicate messages to
the MG.  However, what about supporting models where the MGC does not
have to send multiple messages ? How does the protocol support the
following models (if at all):

1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
complete state duplication (included for completeness since this one
will be 100% transparent to the MGC).
1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
there is complete Megaco state synchronization
1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
there is Megaco state synchronization at regular checkpoints (i.e. not
real-time so there may be some discrepances between the two)
2a) MG1 and MG2 have different IP addresses, and there is complete
Megaco state synchronization.
2b) MG1 and MG2 have different IP addresses, and there is Megaco state
synchronization at regular checkpoints (i.e. not real-time)

Thanks

        Flemming





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 11:03:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18926
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 11:03:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3LFEdM04525
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 11:14:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LFEc804522
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 11:14:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18919
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 11:03:03 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197crE-0000o5-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 11:05:24 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197crE-0000o1-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 11:05:24 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LFC4804424;
	Mon, 21 Apr 2003 11:12:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LF8s804305
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 11:08:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18751
	for <megaco@ietf.org>; Mon, 21 Apr 2003 10:57:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx)
	by ietf-mx with esmtp (Exim 4.12)
	id 197clf-0000m0-00
	for megaco@ietf.org; Mon, 21 Apr 2003 10:59:39 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 197clf-0000lw-00
	for megaco@ietf.org; Mon, 21 Apr 2003 10:59:39 -0400
Received: from cisco.com (sjc-vpn3-426.cisco.com [10.21.65.170])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3LExSgE012995
	for <megaco@ietf.org>; Mon, 21 Apr 2003 07:59:29 -0700 (PDT)
Message-ID: <3EA4074F.ADAFD2D9@cisco.com>
Date: Mon, 21 Apr 2003 10:59:27 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Megaco <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Support for redundant MG failover
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Megaco supports some notion of redundant MGs and redundant MG failover,
however there is very little normative language, let alone explanation
of how this is supposed to work (and the current incarnation of the
upcoming Annex F doesn't help much here). The only model described is
the one in Section 11.4, where both the primary and secondary MG are
fully visible at all times and the MGC has to send duplicate messages to
the MG.  However, what about supporting models where the MGC does not
have to send multiple messages ? How does the protocol support the
following models (if at all):

1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
complete state duplication (included for completeness since this one
will be 100% transparent to the MGC).
1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
there is complete Megaco state synchronization
1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
there is Megaco state synchronization at regular checkpoints (i.e. not
real-time so there may be some discrepances between the two)
2a) MG1 and MG2 have different IP addresses, and there is complete
Megaco state synchronization.
2b) MG1 and MG2 have different IP addresses, and there is Megaco state
synchronization at regular checkpoints (i.e. not real-time)

Thanks

        Flemming





_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 19:57:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08949
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 19:57:09 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M07s807955;
	Mon, 21 Apr 2003 20:07:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M042806967
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 20:04:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08863
	for <megaco@ietf.org>; Mon, 21 Apr 2003 19:52:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197l7N-0004ok-00
	for megaco@ietf.org; Mon, 21 Apr 2003 19:54:37 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 197l7L-0004oU-00
	for megaco@ietf.org; Mon, 21 Apr 2003 19:54:36 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3LNqX426206;
	Tue, 22 Apr 2003 09:52:33 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3LNsr022763;
	Tue, 22 Apr 2003 09:54:53 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8N4349; Tue, 22 Apr 2003 09:54:52 +1000
Message-ID: <3EA484B4.8C2B5439@ericsson.com.au>
Date: Tue, 22 Apr 2003 09:54:28 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brad Steinka <bsteinka@telica.com>
CC: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: Re: [Megaco] Megaco CAS support
References: <C9AFC8E904D49C4593EB077A2E8402BA01510346@wench.telica.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day Brad and Karl,

I believe the intention is to move the CAS work into the ITU. The contributions
containing the latest drafts can be found at:
ftp://standard.pictel.com/avc-site/0302_San/

AVD-2312	MF Tone Generation and Detection Packages
AVD-2315	Basic CAS Packages
AVD-2316	International CAS Packages
AVD-2317	Enhanced Analog Line Packages

Regards, Christian

Brad Steinka wrote:
> 
> There were several RFC draft document that described various packages to
> support CAS, R1, R2, BCAS, etc.
> Most of these drafts have expired.
> 
> Can anyone tell me what the latest RFCs are that support CAS calls and where
> they are in the standards process?
> 
> Thanks
> 
> Brad Steinka
> Director - Software Engineering
> 734 Forest Street, Building G, Suite 100
> Marlboro, Ma.   01752
> Tel:  508-480-0909  x154
> Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> Web:   www.telica.com <http://www.telica.com>
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 19:58:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08985
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 19:58:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3M09YY08021
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 20:09:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M09Y808018
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 20:09:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08976
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 19:57:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lCi-0004qd-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 20:00:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197lCi-0004qZ-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 20:00:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M07s807955;
	Mon, 21 Apr 2003 20:07:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M042806967
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 20:04:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08863
	for <megaco@ietf.org>; Mon, 21 Apr 2003 19:52:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197l7N-0004ok-00
	for megaco@ietf.org; Mon, 21 Apr 2003 19:54:37 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 197l7L-0004oU-00
	for megaco@ietf.org; Mon, 21 Apr 2003 19:54:36 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3LNqX426206;
	Tue, 22 Apr 2003 09:52:33 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3LNsr022763;
	Tue, 22 Apr 2003 09:54:53 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8N4349; Tue, 22 Apr 2003 09:54:52 +1000
Message-ID: <3EA484B4.8C2B5439@ericsson.com.au>
Date: Tue, 22 Apr 2003 09:54:28 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brad Steinka <bsteinka@telica.com>
CC: "'megaco@ietf.org'" <megaco@ietf.org>
Subject: Re: [Megaco] Megaco CAS support
References: <C9AFC8E904D49C4593EB077A2E8402BA01510346@wench.telica.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day Brad and Karl,

I believe the intention is to move the CAS work into the ITU. The contributions
containing the latest drafts can be found at:
ftp://standard.pictel.com/avc-site/0302_San/

AVD-2312	MF Tone Generation and Detection Packages
AVD-2315	Basic CAS Packages
AVD-2316	International CAS Packages
AVD-2317	Enhanced Analog Line Packages

Regards, Christian

Brad Steinka wrote:
> 
> There were several RFC draft document that described various packages to
> support CAS, R1, R2, BCAS, etc.
> Most of these drafts have expired.
> 
> Can anyone tell me what the latest RFCs are that support CAS calls and where
> they are in the standards process?
> 
> Thanks
> 
> Brad Steinka
> Director - Software Engineering
> 734 Forest Street, Building G, Suite 100
> Marlboro, Ma.   01752
> Tel:  508-480-0909  x154
> Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> Web:   www.telica.com <http://www.telica.com>
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 20:13:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09248
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 20:13:16 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0O3808332;
	Mon, 21 Apr 2003 20:24:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0LZ808286
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 20:21:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09162
	for <megaco@ietf.org>; Mon, 21 Apr 2003 20:09:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOL-0004tH-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:09 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOG-0004tE-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:04 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3M0A4427402;
	Tue, 22 Apr 2003 10:10:04 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3M0CO028581;
	Tue, 22 Apr 2003 10:12:24 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8N4PA3; Tue, 22 Apr 2003 10:12:22 +1000
Message-ID: <3EA488CE.55C88E88@ericsson.com.au>
Date: Tue, 22 Apr 2003 10:11:58 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day Fleming,

The megaco model can support the configurations that you list below. The
scenarios are implemented in such a way that the megaco interface is unaware
that state synchronisation is occuring. It's for this reason that the
specification doesn't say more about it, if you don't need Megaco messages then
there's no point putting it in a megaco specification.

Regards, Christian

Flemming Andreasen wrote:
> 
> Megaco supports some notion of redundant MGs and redundant MG failover,
> however there is very little normative language, let alone explanation
> of how this is supposed to work (and the current incarnation of the
> upcoming Annex F doesn't help much here). The only model described is
> the one in Section 11.4, where both the primary and secondary MG are
> fully visible at all times and the MGC has to send duplicate messages to
> the MG.  However, what about supporting models where the MGC does not
> have to send multiple messages ? How does the protocol support the
> following models (if at all):
> 
> 1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
> complete state duplication (included for completeness since this one
> will be 100% transparent to the MGC).
> 1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> there is complete Megaco state synchronization
> 1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> there is Megaco state synchronization at regular checkpoints (i.e. not
> real-time so there may be some discrepances between the two)
> 2a) MG1 and MG2 have different IP addresses, and there is complete
> Megaco state synchronization.
> 2b) MG1 and MG2 have different IP addresses, and there is Megaco state
> synchronization at regular checkpoints (i.e. not real-time)
> 
> Thanks
> 
>         Flemming
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 20:14:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09284
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 20:14:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3M0PgV08390
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 20:25:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0Pg808387
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 20:25:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09276
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 20:13:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lSK-0004uO-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 20:16:16 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197lSJ-0004uL-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 20:16:15 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0O3808332;
	Mon, 21 Apr 2003 20:24:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0LZ808286
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 20:21:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09162
	for <megaco@ietf.org>; Mon, 21 Apr 2003 20:09:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOL-0004tH-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:09 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOG-0004tE-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:04 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3M0A4427402;
	Tue, 22 Apr 2003 10:10:04 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3M0CO028581;
	Tue, 22 Apr 2003 10:12:24 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.177]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8N4PA3; Tue, 22 Apr 2003 10:12:22 +1000
Message-ID: <3EA488CE.55C88E88@ericsson.com.au>
Date: Tue, 22 Apr 2003 10:11:58 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day Fleming,

The megaco model can support the configurations that you list below. The
scenarios are implemented in such a way that the megaco interface is unaware
that state synchronisation is occuring. It's for this reason that the
specification doesn't say more about it, if you don't need Megaco messages then
there's no point putting it in a megaco specification.

Regards, Christian

Flemming Andreasen wrote:
> 
> Megaco supports some notion of redundant MGs and redundant MG failover,
> however there is very little normative language, let alone explanation
> of how this is supposed to work (and the current incarnation of the
> upcoming Annex F doesn't help much here). The only model described is
> the one in Section 11.4, where both the primary and secondary MG are
> fully visible at all times and the MGC has to send duplicate messages to
> the MG.  However, what about supporting models where the MGC does not
> have to send multiple messages ? How does the protocol support the
> following models (if at all):
> 
> 1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
> complete state duplication (included for completeness since this one
> will be 100% transparent to the MGC).
> 1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> there is complete Megaco state synchronization
> 1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> there is Megaco state synchronization at regular checkpoints (i.e. not
> real-time so there may be some discrepances between the two)
> 2a) MG1 and MG2 have different IP addresses, and there is complete
> Megaco state synchronization.
> 2b) MG1 and MG2 have different IP addresses, and there is Megaco state
> synchronization at regular checkpoints (i.e. not real-time)
> 
> Thanks
> 
>         Flemming
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 20:15:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09325
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 20:15:14 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0Pw808409;
	Mon, 21 Apr 2003 20:25:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0Lg808290
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 20:21:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09165
	for <megaco@ietf.org>; Mon, 21 Apr 2003 20:09:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOT-0004tM-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:17 -0400
Received: from host201.cisp.cc ([65.196.203.201] helo=nocmailsvc001.allthesites.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOS-0004tC-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:16 -0400
Received: from afaith2 (unverified [207.221.246.251]) by copper.net
 (Rockliffe SMTPRA 5.2.5) with ESMTP id <B0013349110@nocmailsvc001.allthesites.org> for <megaco@ietf.org>;
 Mon, 21 Apr 2003 20:12:02 -0400
From: "Paul Long" <plong@packetizer.com>
To: <megaco@ietf.org>
Subject: RE: [Megaco] using UDP in MEGACO
Date: Mon, 21 Apr 2003 19:09:37 -0500
Message-ID: <NEBBIELHMLDIACLLJHCNIEGIELAA.plong@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <006f01c30809$f2b85380$1606050a@mahindrabt.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Anil,

FWIW, this is Brian Rosen's response to the query, "What is ALF?"

>>>>>>>>>
ALF is a set of techniques that allow an application, as opposed 
to a stack, affect how messages are sent to the other side.  
A typical ALF technique is to allow an application to change the 
order of messages sent when there is a queue AFTER it has queued 
them.  There is no spec.

You can JUST follow the procedures in Annex D, and nothing more,
or you can do some other things that might improve performance for
a particular application, but you can't do something that violates
the protocol specification.

Brian
<<<<<<<<<<<<

Paul

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Anil Jangam
Sent: Monday, April 21, 2003 8:10 AM
To: Christer Holmberg; Fhuval Hittay
Cc: megaco@ietf.org; Tom-PT Taylor
Subject: Re: [Megaco] using UDP in MEGACO


Hi Christer ,

What about the use the ALF (which also recommended when used UDP as
Transport)??
Use of ALF can solve the sequencing problem in UDP.

/anil.

----- Original Message -----
From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
To: "Fhuval Hittay" <fhuval@rambler.ru>
Cc: <megaco@ietf.org>
Sent: Monday, April 21, 2003 5:56 PM
Subject: Re: [Megaco] using UDP in MEGACO

>
> Hi,
>
> > could anyone answer how could be avoided wrong sequence of received
MEGACO
> > messages when using UDP as a transport mechanism?
>
> I think the only answer to this is: don't send another message (at least
not
> if it contains actions for the same Context(s)/Termination(s) as the
previous
> message) until you have received an answer for the previous message.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 20:16:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09418
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 20:16:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3M0RdO08460
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 20:27:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0Rd808457
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 20:27:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09365
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 20:15:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lUC-0004vO-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 20:18:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197lUC-0004vL-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 20:18:12 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0Pw808409;
	Mon, 21 Apr 2003 20:25:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M0Lg808290
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 20:21:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09165
	for <megaco@ietf.org>; Mon, 21 Apr 2003 20:09:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOT-0004tM-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:17 -0400
Received: from host201.cisp.cc ([65.196.203.201] helo=nocmailsvc001.allthesites.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197lOS-0004tC-00
	for megaco@ietf.org; Mon, 21 Apr 2003 20:12:16 -0400
Received: from afaith2 (unverified [207.221.246.251]) by copper.net
 (Rockliffe SMTPRA 5.2.5) with ESMTP id <B0013349110@nocmailsvc001.allthesites.org> for <megaco@ietf.org>;
 Mon, 21 Apr 2003 20:12:02 -0400
From: "Paul Long" <plong@packetizer.com>
To: <megaco@ietf.org>
Subject: RE: [Megaco] using UDP in MEGACO
Date: Mon, 21 Apr 2003 19:09:37 -0500
Message-ID: <NEBBIELHMLDIACLLJHCNIEGIELAA.plong@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <006f01c30809$f2b85380$1606050a@mahindrabt.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Anil,

FWIW, this is Brian Rosen's response to the query, "What is ALF?"

>>>>>>>>>
ALF is a set of techniques that allow an application, as opposed 
to a stack, affect how messages are sent to the other side.  
A typical ALF technique is to allow an application to change the 
order of messages sent when there is a queue AFTER it has queued 
them.  There is no spec.

You can JUST follow the procedures in Annex D, and nothing more,
or you can do some other things that might improve performance for
a particular application, but you can't do something that violates
the protocol specification.

Brian
<<<<<<<<<<<<

Paul

-----Original Message-----
From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
Anil Jangam
Sent: Monday, April 21, 2003 8:10 AM
To: Christer Holmberg; Fhuval Hittay
Cc: megaco@ietf.org; Tom-PT Taylor
Subject: Re: [Megaco] using UDP in MEGACO


Hi Christer ,

What about the use the ALF (which also recommended when used UDP as
Transport)??
Use of ALF can solve the sequencing problem in UDP.

/anil.

----- Original Message -----
From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
To: "Fhuval Hittay" <fhuval@rambler.ru>
Cc: <megaco@ietf.org>
Sent: Monday, April 21, 2003 5:56 PM
Subject: Re: [Megaco] using UDP in MEGACO

>
> Hi,
>
> > could anyone answer how could be avoided wrong sequence of received
MEGACO
> > messages when using UDP as a transport mechanism?
>
> I think the only answer to this is: don't send another message (at least
not
> if it contains actions for the same Context(s)/Termination(s) as the
previous
> message) until you have received an answer for the previous message.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 21 21:46:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11715
	for <megaco-archive@lists.ietf.org>; Mon, 21 Apr 2003 21:46:20 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M1ui814142;
	Mon, 21 Apr 2003 21:56:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M1rE814056
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 21:53:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11663
	for <megaco@ietf.org>; Mon, 21 Apr 2003 21:41:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197mp1-0005Wk-00
	for megaco@ietf.org; Mon, 21 Apr 2003 21:43:47 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 197mp0-0005Wb-00
	for megaco@ietf.org; Mon, 21 Apr 2003 21:43:46 -0400
Received: from cisco.com (sjc-vpn3-426.cisco.com [10.21.65.170])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3M1hYmi004504;
	Mon, 21 Apr 2003 18:43:34 -0700 (PDT)
Message-ID: <3EA49E45.58FE4035@cisco.com>
Date: Mon, 21 Apr 2003 21:43:33 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com.au>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi Christian

Christian Groves wrote:

> G'Day Fleming,
>
> The megaco model can support the configurations that you list below. The
> scenarios are implemented in such a way that the megaco interface is unaware
> that state synchronisation is occuring. It's for this reason that the
> specification doesn't say more about it, if you don't need Megaco messages then
> there's no point putting it in a megaco specification.
>

I agree with the last point, however it only applies to case 1a. Clearly something
has to happen in all the other cases, i.e. sending of a ServiceChange since the
failover is not 100% transparent and the MGC needs to be informed about the change
(whether it's a simple address change, mgcId change, or some degree of state loss).
As I noted before, Megaco is silent on this and if you were to conclude anything
from the current draft of Annex F, it would be that only model 1a is actually
supported today (at least in a standard manner). If you believe all of these models
actually are supported, then I'd like to know what ServiceChangeMethod,
ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
you would use in each case (apart from 1a that is).


-- Flemming


>
> Regards, Christian
>
> Flemming Andreasen wrote:
> >
> > Megaco supports some notion of redundant MGs and redundant MG failover,
> > however there is very little normative language, let alone explanation
> > of how this is supposed to work (and the current incarnation of the
> > upcoming Annex F doesn't help much here). The only model described is
> > the one in Section 11.4, where both the primary and secondary MG are
> > fully visible at all times and the MGC has to send duplicate messages to
> > the MG.  However, what about supporting models where the MGC does not
> > have to send multiple messages ? How does the protocol support the
> > following models (if at all):
> >
> > 1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
> > complete state duplication (included for completeness since this one
> > will be 100% transparent to the MGC).
> > 1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > there is complete Megaco state synchronization
> > 1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > there is Megaco state synchronization at regular checkpoints (i.e. not
> > real-time so there may be some discrepances between the two)
> > 2a) MG1 and MG2 have different IP addresses, and there is complete
> > Megaco state synchronization.
> > 2b) MG1 and MG2 have different IP addresses, and there is Megaco state
> > synchronization at regular checkpoints (i.e. not real-time)
> >
> > Thanks
> >
> >         Flemming
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 21 21:47:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11744
	for <megaco-archive@odin.ietf.org>; Mon, 21 Apr 2003 21:47:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3M1wmu14224
	for megaco-archive@odin.ietf.org; Mon, 21 Apr 2003 21:58:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M1wm814221
	for <megaco-web-archive@optimus.ietf.org>; Mon, 21 Apr 2003 21:58:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11736
	for <megaco-web-archive@ietf.org>; Mon, 21 Apr 2003 21:46:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197muO-0005XI-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 21:49:20 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197muN-0005XF-00
	for megaco-web-archive@ietf.org; Mon, 21 Apr 2003 21:49:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M1ui814142;
	Mon, 21 Apr 2003 21:56:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M1rE814056
	for <megaco@optimus.ietf.org>; Mon, 21 Apr 2003 21:53:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11663
	for <megaco@ietf.org>; Mon, 21 Apr 2003 21:41:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197mp1-0005Wk-00
	for megaco@ietf.org; Mon, 21 Apr 2003 21:43:47 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 197mp0-0005Wb-00
	for megaco@ietf.org; Mon, 21 Apr 2003 21:43:46 -0400
Received: from cisco.com (sjc-vpn3-426.cisco.com [10.21.65.170])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3M1hYmi004504;
	Mon, 21 Apr 2003 18:43:34 -0700 (PDT)
Message-ID: <3EA49E45.58FE4035@cisco.com>
Date: Mon, 21 Apr 2003 21:43:33 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com.au>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi Christian

Christian Groves wrote:

> G'Day Fleming,
>
> The megaco model can support the configurations that you list below. The
> scenarios are implemented in such a way that the megaco interface is unaware
> that state synchronisation is occuring. It's for this reason that the
> specification doesn't say more about it, if you don't need Megaco messages then
> there's no point putting it in a megaco specification.
>

I agree with the last point, however it only applies to case 1a. Clearly something
has to happen in all the other cases, i.e. sending of a ServiceChange since the
failover is not 100% transparent and the MGC needs to be informed about the change
(whether it's a simple address change, mgcId change, or some degree of state loss).
As I noted before, Megaco is silent on this and if you were to conclude anything
from the current draft of Annex F, it would be that only model 1a is actually
supported today (at least in a standard manner). If you believe all of these models
actually are supported, then I'd like to know what ServiceChangeMethod,
ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
you would use in each case (apart from 1a that is).


-- Flemming


>
> Regards, Christian
>
> Flemming Andreasen wrote:
> >
> > Megaco supports some notion of redundant MGs and redundant MG failover,
> > however there is very little normative language, let alone explanation
> > of how this is supposed to work (and the current incarnation of the
> > upcoming Annex F doesn't help much here). The only model described is
> > the one in Section 11.4, where both the primary and secondary MG are
> > fully visible at all times and the MGC has to send duplicate messages to
> > the MG.  However, what about supporting models where the MGC does not
> > have to send multiple messages ? How does the protocol support the
> > following models (if at all):
> >
> > 1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
> > complete state duplication (included for completeness since this one
> > will be 100% transparent to the MGC).
> > 1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > there is complete Megaco state synchronization
> > 1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > there is Megaco state synchronization at regular checkpoints (i.e. not
> > real-time so there may be some discrepances between the two)
> > 2a) MG1 and MG2 have different IP addresses, and there is complete
> > Megaco state synchronization.
> > 2b) MG1 and MG2 have different IP addresses, and there is Megaco state
> > synchronization at regular checkpoints (i.e. not real-time)
> >
> > Thanks
> >
> >         Flemming
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 01:12:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15172
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 01:12:11 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M5Lm826347;
	Tue, 22 Apr 2003 01:21:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M5IU826246
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 01:18:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15043
	for <megaco@ietf.org>; Tue, 22 Apr 2003 01:06:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197q1a-0006KI-00
	for megaco@ietf.org; Tue, 22 Apr 2003 01:08:58 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 197q1Z-0006K0-00
	for megaco@ietf.org; Tue, 22 Apr 2003 01:08:57 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3M56q418904;
	Tue, 22 Apr 2003 15:06:52 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3M59C001963;
	Tue, 22 Apr 2003 15:09:12 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.195]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8N4VJC; Tue, 22 Apr 2003 15:09:11 +1000
Message-ID: <3EA4CE5B.2C2AC97B@ericsson.com.au>
Date: Tue, 22 Apr 2003 15:08:43 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day Flemming,

May be my brain hasn't restarted after the Easter break

In cases other than 1a a failover method would be sent with the
ServiceChangeMGCId which the address of the association new or existing. How the
state synchronisation is done is still out of scope of Megaco. MG2 will either
have the up to date state knowledge (eg. duplicate megaco messages) or it will
have to audit or use some other means to find out.

Is it the state sharing part that you are questioning?

Regards, Christian

Flemming Andreasen wrote:
> 
> Hi Christian
> 
> Christian Groves wrote:
> 
> > G'Day Fleming,
> >
> > The megaco model can support the configurations that you list below. The
> > scenarios are implemented in such a way that the megaco interface is unaware
> > that state synchronisation is occuring. It's for this reason that the
> > specification doesn't say more about it, if you don't need Megaco messages then
> > there's no point putting it in a megaco specification.
> >
> 
> I agree with the last point, however it only applies to case 1a. Clearly something
> has to happen in all the other cases, i.e. sending of a ServiceChange since the
> failover is not 100% transparent and the MGC needs to be informed about the change
> (whether it's a simple address change, mgcId change, or some degree of state loss).
> As I noted before, Megaco is silent on this and if you were to conclude anything
> from the current draft of Annex F, it would be that only model 1a is actually
> supported today (at least in a standard manner). If you believe all of these models
> actually are supported, then I'd like to know what ServiceChangeMethod,
> ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
> you would use in each case (apart from 1a that is).
> 
> -- Flemming
> 
> >
> > Regards, Christian
> >
> > Flemming Andreasen wrote:
> > >
> > > Megaco supports some notion of redundant MGs and redundant MG failover,
> > > however there is very little normative language, let alone explanation
> > > of how this is supposed to work (and the current incarnation of the
> > > upcoming Annex F doesn't help much here). The only model described is
> > > the one in Section 11.4, where both the primary and secondary MG are
> > > fully visible at all times and the MGC has to send duplicate messages to
> > > the MG.  However, what about supporting models where the MGC does not
> > > have to send multiple messages ? How does the protocol support the
> > > following models (if at all):
> > >
> > > 1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
> > > complete state duplication (included for completeness since this one
> > > will be 100% transparent to the MGC).
> > > 1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > > there is complete Megaco state synchronization
> > > 1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > > there is Megaco state synchronization at regular checkpoints (i.e. not
> > > real-time so there may be some discrepances between the two)
> > > 2a) MG1 and MG2 have different IP addresses, and there is complete
> > > Megaco state synchronization.
> > > 2b) MG1 and MG2 have different IP addresses, and there is Megaco state
> > > synchronization at regular checkpoints (i.e. not real-time)
> > >
> > > Thanks
> > >
> > >         Flemming
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > Megaco@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 01:13:18 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15207
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 01:13:18 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3M5OfZ26431
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 01:24:41 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M5Of826428
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 01:24:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15195
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 01:12:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197q7Y-0006Lt-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 01:15:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197q7Y-0006Lq-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 01:15:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M5Lm826347;
	Tue, 22 Apr 2003 01:21:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M5IU826246
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 01:18:30 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15043
	for <megaco@ietf.org>; Tue, 22 Apr 2003 01:06:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197q1a-0006KI-00
	for megaco@ietf.org; Tue, 22 Apr 2003 01:08:58 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 197q1Z-0006K0-00
	for megaco@ietf.org; Tue, 22 Apr 2003 01:08:57 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3M56q418904;
	Tue, 22 Apr 2003 15:06:52 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3M59C001963;
	Tue, 22 Apr 2003 15:09:12 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.245.195]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8N4VJC; Tue, 22 Apr 2003 15:09:11 +1000
Message-ID: <3EA4CE5B.2C2AC97B@ericsson.com.au>
Date: Tue, 22 Apr 2003 15:08:43 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day Flemming,

May be my brain hasn't restarted after the Easter break

In cases other than 1a a failover method would be sent with the
ServiceChangeMGCId which the address of the association new or existing. How the
state synchronisation is done is still out of scope of Megaco. MG2 will either
have the up to date state knowledge (eg. duplicate megaco messages) or it will
have to audit or use some other means to find out.

Is it the state sharing part that you are questioning?

Regards, Christian

Flemming Andreasen wrote:
> 
> Hi Christian
> 
> Christian Groves wrote:
> 
> > G'Day Fleming,
> >
> > The megaco model can support the configurations that you list below. The
> > scenarios are implemented in such a way that the megaco interface is unaware
> > that state synchronisation is occuring. It's for this reason that the
> > specification doesn't say more about it, if you don't need Megaco messages then
> > there's no point putting it in a megaco specification.
> >
> 
> I agree with the last point, however it only applies to case 1a. Clearly something
> has to happen in all the other cases, i.e. sending of a ServiceChange since the
> failover is not 100% transparent and the MGC needs to be informed about the change
> (whether it's a simple address change, mgcId change, or some degree of state loss).
> As I noted before, Megaco is silent on this and if you were to conclude anything
> from the current draft of Annex F, it would be that only model 1a is actually
> supported today (at least in a standard manner). If you believe all of these models
> actually are supported, then I'd like to know what ServiceChangeMethod,
> ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
> you would use in each case (apart from 1a that is).
> 
> -- Flemming
> 
> >
> > Regards, Christian
> >
> > Flemming Andreasen wrote:
> > >
> > > Megaco supports some notion of redundant MGs and redundant MG failover,
> > > however there is very little normative language, let alone explanation
> > > of how this is supposed to work (and the current incarnation of the
> > > upcoming Annex F doesn't help much here). The only model described is
> > > the one in Section 11.4, where both the primary and secondary MG are
> > > fully visible at all times and the MGC has to send duplicate messages to
> > > the MG.  However, what about supporting models where the MGC does not
> > > have to send multiple messages ? How does the protocol support the
> > > following models (if at all):
> > >
> > > 1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
> > > complete state duplication (included for completeness since this one
> > > will be 100% transparent to the MGC).
> > > 1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > > there is complete Megaco state synchronization
> > > 1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
> > > there is Megaco state synchronization at regular checkpoints (i.e. not
> > > real-time so there may be some discrepances between the two)
> > > 2a) MG1 and MG2 have different IP addresses, and there is complete
> > > Megaco state synchronization.
> > > 2b) MG1 and MG2 have different IP addresses, and there is Megaco state
> > > synchronization at regular checkpoints (i.e. not real-time)
> > >
> > > Thanks
> > >
> > >         Flemming
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > Megaco@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 09:57:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09455
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 09:57:25 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ME7Z807692;
	Tue, 22 Apr 2003 10:07:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ME0q806606
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 10:00:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09222
	for <megaco@ietf.org>; Tue, 22 Apr 2003 09:48:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yAv-0001q4-00
	for megaco@ietf.org; Tue, 22 Apr 2003 09:51:09 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yAu-0001pq-00
	for megaco@ietf.org; Tue, 22 Apr 2003 09:51:08 -0400
Received: from cisco.com (sjc-vpn3-426.cisco.com [10.21.65.170])
	by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3MDoodL029454;
	Tue, 22 Apr 2003 06:50:58 -0700 (PDT)
Message-ID: <3EA548BA.932C403B@cisco.com>
Date: Tue, 22 Apr 2003 09:50:50 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com.au>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Christian Groves wrote:

> G'Day Flemming,
>
> May be my brain hasn't restarted after the Easter break
>
> In cases other than 1a a failover method would be sent with the
> ServiceChangeMGCId which the address of the association new or existing.

Something like that makes sense to me, however I don't find much support for it in the
H.248 specification. The text in H.248 (more specifically Section 11.4, all other
descriptions of "failover" applies to MGC related failures) suggests that failover is
something the failing MG sends, not the backup.  Again, taking a look at the upcoming
Annex F, I don't find any support for use of failover in these cases either.


> How the
> state synchronisation is done is still out of scope of Megaco. MG2 will either
> have the up to date state knowledge (eg. duplicate megaco messages) or it will
> have to audit or use some other means to find out.
>

Right, however it is imperative that the MGC has a way of figuring out whether state has
been lost or not, and hence can take appropriate recovery action, and that's the part
that seems to be somewhat missing.

>
> Is it the state sharing part that you are questioning?

That as well as the method, reason, and mgcID. Let's take the cases one by one and to
make things clearer let:
- domain(MG) be a single domain name for both MG1 and MG2
- domain(MG1) and domain(MG2) be a domain name for MG1 and MG2
- IP(MG1) and IP(MG2) be the IP address of MG1 and MG2

Also, in cases 1a to 1c, let's assume use of TCP. In cases 2a and 2b, let's assume use of
UDP.


Case 1a)     MG1 (primary) and MG2 (secondary) share the same IP-address with complete
state duplication (included for completeness since this one will be 100% transparent to
the MGC).

When MG1 fails, there will be no messages sent to the MGC, since there is complete state
duplication between MG1 and MG2 (incl. transport layer).


Case 1b)    MG1 (primary) and MG2 (secondary) share the same IP-address, and there is
complete Megaco state synchronization

MG1 crashes and hence cannot send any messages to the MGC. The MG1 TCP connection is
lost, and a new control association between MG2 and MGC must be created. MG2 sends a
ServiceChange with the following parameters:

mid:    domain(MG)
ServiceChangeMethod:    restart ?
ServiceChangeReason:    900 - service restored ?


Note that Annex F currently disallows failover/900, however restart/900 would be allowed.



Case 1c)    MG1 (primary) and MG2 (secondary) share the same IP-address, and there is
Megaco state synchronization at regular checkpoints (i.e. not real-time so there may be
some discrepancies between the two)

MG1 fails completetly and cannot send anything. MG2 sends a ServiceChange with the
following parameters:

mid:    domain(MG)
ServiceChangeMethod:    restart ?
ServiceChangeReason:     900/901/902/9xx ?

Again, failover cannot be combined with 900/901/902 according to current version of Annex
F.
900 would indicate no loss, i.e. latest checkpoint up to date.
901 would indicate total state loss, i.e. no checkpointing ever done
902 would indicate possible loss of transactions in process, but otherwise no state loss
9xx is a missing reason, that would indicate some level of state loss between  total
state loss (901) and only transaction in process state loss (902).


Case 2a)    MG1 and MG2 have different IP addresses, and there is complete Megaco state
synchronization.

MG1 fails completely and MG2 sends a ServiceChange with the following parameters:

mid:    domain(MG) ?
ServiceChangeMethod:    restart ?
ServiceChangeReason:    900 - service restored ?


This one is similar to 1b, but since we have different IP addresses there is another
issue. The mid in the message identifies this as the same MG, however we need to make
sure that messages are sent to MG1, not MG2 (recall we are using UDP now so can't depend
on the TCP connection implicitly handling this). How is this achieved (this problem
applies equally well to the initial registration by MG1) ?


Case 2b)    MG1 and MG2 have different IP addresses, and there is Megaco state
synchronization at regular checkpoints (i.e. not real-time)

mid:    domain(MG) ?
ServiceChangeMethod:    restart ?
ServiceChangeReason:    900/901/902/9xx ?

The issues here are the same as in 1c and 2a.


-- Flemming



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 09:58:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09488
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 09:58:31 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MEA5K07795
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 10:10:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEA5807792
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 10:10:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09484
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 09:58:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yJq-0001th-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 10:00:22 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197yJq-0001te-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 10:00:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ME7Z807692;
	Tue, 22 Apr 2003 10:07:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ME0q806606
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 10:00:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09222
	for <megaco@ietf.org>; Tue, 22 Apr 2003 09:48:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yAv-0001q4-00
	for megaco@ietf.org; Tue, 22 Apr 2003 09:51:09 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by ietf-mx with esmtp (Exim 4.12)
	id 197yAu-0001pq-00
	for megaco@ietf.org; Tue, 22 Apr 2003 09:51:08 -0400
Received: from cisco.com (sjc-vpn3-426.cisco.com [10.21.65.170])
	by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3MDoodL029454;
	Tue, 22 Apr 2003 06:50:58 -0700 (PDT)
Message-ID: <3EA548BA.932C403B@cisco.com>
Date: Tue, 22 Apr 2003 09:50:50 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves <Christian.Groves@ericsson.com.au>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Christian Groves wrote:

> G'Day Flemming,
>
> May be my brain hasn't restarted after the Easter break
>
> In cases other than 1a a failover method would be sent with the
> ServiceChangeMGCId which the address of the association new or existing.

Something like that makes sense to me, however I don't find much support for it in the
H.248 specification. The text in H.248 (more specifically Section 11.4, all other
descriptions of "failover" applies to MGC related failures) suggests that failover is
something the failing MG sends, not the backup.  Again, taking a look at the upcoming
Annex F, I don't find any support for use of failover in these cases either.


> How the
> state synchronisation is done is still out of scope of Megaco. MG2 will either
> have the up to date state knowledge (eg. duplicate megaco messages) or it will
> have to audit or use some other means to find out.
>

Right, however it is imperative that the MGC has a way of figuring out whether state has
been lost or not, and hence can take appropriate recovery action, and that's the part
that seems to be somewhat missing.

>
> Is it the state sharing part that you are questioning?

That as well as the method, reason, and mgcID. Let's take the cases one by one and to
make things clearer let:
- domain(MG) be a single domain name for both MG1 and MG2
- domain(MG1) and domain(MG2) be a domain name for MG1 and MG2
- IP(MG1) and IP(MG2) be the IP address of MG1 and MG2

Also, in cases 1a to 1c, let's assume use of TCP. In cases 2a and 2b, let's assume use of
UDP.


Case 1a)     MG1 (primary) and MG2 (secondary) share the same IP-address with complete
state duplication (included for completeness since this one will be 100% transparent to
the MGC).

When MG1 fails, there will be no messages sent to the MGC, since there is complete state
duplication between MG1 and MG2 (incl. transport layer).


Case 1b)    MG1 (primary) and MG2 (secondary) share the same IP-address, and there is
complete Megaco state synchronization

MG1 crashes and hence cannot send any messages to the MGC. The MG1 TCP connection is
lost, and a new control association between MG2 and MGC must be created. MG2 sends a
ServiceChange with the following parameters:

mid:    domain(MG)
ServiceChangeMethod:    restart ?
ServiceChangeReason:    900 - service restored ?


Note that Annex F currently disallows failover/900, however restart/900 would be allowed.



Case 1c)    MG1 (primary) and MG2 (secondary) share the same IP-address, and there is
Megaco state synchronization at regular checkpoints (i.e. not real-time so there may be
some discrepancies between the two)

MG1 fails completetly and cannot send anything. MG2 sends a ServiceChange with the
following parameters:

mid:    domain(MG)
ServiceChangeMethod:    restart ?
ServiceChangeReason:     900/901/902/9xx ?

Again, failover cannot be combined with 900/901/902 according to current version of Annex
F.
900 would indicate no loss, i.e. latest checkpoint up to date.
901 would indicate total state loss, i.e. no checkpointing ever done
902 would indicate possible loss of transactions in process, but otherwise no state loss
9xx is a missing reason, that would indicate some level of state loss between  total
state loss (901) and only transaction in process state loss (902).


Case 2a)    MG1 and MG2 have different IP addresses, and there is complete Megaco state
synchronization.

MG1 fails completely and MG2 sends a ServiceChange with the following parameters:

mid:    domain(MG) ?
ServiceChangeMethod:    restart ?
ServiceChangeReason:    900 - service restored ?


This one is similar to 1b, but since we have different IP addresses there is another
issue. The mid in the message identifies this as the same MG, however we need to make
sure that messages are sent to MG1, not MG2 (recall we are using UDP now so can't depend
on the TCP connection implicitly handling this). How is this achieved (this problem
applies equally well to the initial registration by MG1) ?


Case 2b)    MG1 and MG2 have different IP addresses, and there is Megaco state
synchronization at regular checkpoints (i.e. not real-time)

mid:    domain(MG) ?
ServiceChangeMethod:    restart ?
ServiceChangeReason:    900/901/902/9xx ?

The issues here are the same as in 1c and 2a.


-- Flemming



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 11:03:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12804
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 11:03:13 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFDt812761;
	Tue, 22 Apr 2003 11:13:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MF2n811490
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 11:02:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12472
	for <megaco@ietf.org>; Tue, 22 Apr 2003 10:50:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197z8q-0002Ij-00
	for megaco@ietf.org; Tue, 22 Apr 2003 10:53:05 -0400
Received: from sess01.rdp.asi.alcatel.es ([159.23.144.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 197z8q-0002Hm-00
	for megaco@ietf.org; Tue, 22 Apr 2003 10:53:04 -0400
Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1])
	by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h3MEqm713148;
	Tue, 22 Apr 2003 16:52:48 +0200 (MEST)
Received: from alcatel.es (serp3121.rpi.ses.alcatel.es [159.23.113.121])
	by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id QAA09703;
	Tue, 22 Apr 2003 16:52:59 +0200 (MET DST)
Message-ID: <3EA557A8.C4FFA7F8@alcatel.es>
Date: Tue, 22 Apr 2003 16:54:32 +0200
From: Manuel Poza <manuel.poza@alcatel.es>
Organization: Alcatel
X-Mailer: Mozilla 4.5 [es] (WinNT; I)
X-Accept-Language: es
MIME-Version: 1.0
To: hektor@etri.re.kr
CC: megaco@ietf.org
Subject: Re: [Megaco] [Question] About unrequested event notification
References: <8470181DABD5D511B3E700D0B7A8AC4A5DA532@cms3>
Content-Type: multipart/alternative;
 boundary="------------4AAC98362DFA1DBC2B865000"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------4AAC98362DFA1DBC2B865000
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by sess01.rdp.asi.alcatel.es id h3MEqm713148
Content-Transfer-Encoding: quoted-printable

Hi, Hektor,

I think the MGC should reply with an error, possibly, error #401
(Protocol error).

Regards,
Manuel

hektor@etri.re.kr escribi=F3:

>
>
> G'day.
>
> If a MG send a event notification which is not requested by a MGC,
> What shall the MGC do?
>
> TIA.

--------------4AAC98362DFA1DBC2B865000
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi, Hektor,
<p>I think the MGC should reply with an error, possibly, error #401 (Protocol
error).
<p>Regards,
<br>Manuel
<p>hektor@etri.re.kr escribi&oacute;:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>G'day.</font>
<p><font size=-1>If a MG send a event notification which is not requested
by a MGC,</font>
<br><font size=-1>What shall the MGC do?</font>
<p><font size=-1>TIA.</font></blockquote>
</html>

--------------4AAC98362DFA1DBC2B865000--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 11:04:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12889
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 11:04:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MFFwZ13105
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 11:15:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFFw813102
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 11:15:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12879
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 11:03:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197zLZ-0002Oj-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 11:06:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197zLZ-0002Og-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 11:06:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFDt812761;
	Tue, 22 Apr 2003 11:13:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MF2n811490
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 11:02:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12472
	for <megaco@ietf.org>; Tue, 22 Apr 2003 10:50:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197z8q-0002Ij-00
	for megaco@ietf.org; Tue, 22 Apr 2003 10:53:05 -0400
Received: from sess01.rdp.asi.alcatel.es ([159.23.144.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 197z8q-0002Hm-00
	for megaco@ietf.org; Tue, 22 Apr 2003 10:53:04 -0400
Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1])
	by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h3MEqm713148;
	Tue, 22 Apr 2003 16:52:48 +0200 (MEST)
Received: from alcatel.es (serp3121.rpi.ses.alcatel.es [159.23.113.121])
	by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id QAA09703;
	Tue, 22 Apr 2003 16:52:59 +0200 (MET DST)
Message-ID: <3EA557A8.C4FFA7F8@alcatel.es>
Date: Tue, 22 Apr 2003 16:54:32 +0200
From: Manuel Poza <manuel.poza@alcatel.es>
Organization: Alcatel
X-Mailer: Mozilla 4.5 [es] (WinNT; I)
X-Accept-Language: es
MIME-Version: 1.0
To: hektor@etri.re.kr
CC: megaco@ietf.org
Subject: Re: [Megaco] [Question] About unrequested event notification
References: <8470181DABD5D511B3E700D0B7A8AC4A5DA532@cms3>
Content-Type: multipart/alternative;
 boundary="------------4AAC98362DFA1DBC2B865000"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------4AAC98362DFA1DBC2B865000
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by sess01.rdp.asi.alcatel.es id h3MEqm713148
Content-Transfer-Encoding: quoted-printable

Hi, Hektor,

I think the MGC should reply with an error, possibly, error #401
(Protocol error).

Regards,
Manuel

hektor@etri.re.kr escribi=F3:

>
>
> G'day.
>
> If a MG send a event notification which is not requested by a MGC,
> What shall the MGC do?
>
> TIA.

--------------4AAC98362DFA1DBC2B865000
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi, Hektor,
<p>I think the MGC should reply with an error, possibly, error #401 (Protocol
error).
<p>Regards,
<br>Manuel
<p>hektor@etri.re.kr escribi&oacute;:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>G'day.</font>
<p><font size=-1>If a MG send a event notification which is not requested
by a MGC,</font>
<br><font size=-1>What shall the MGC do?</font>
<p><font size=-1>TIA.</font></blockquote>
</html>

--------------4AAC98362DFA1DBC2B865000--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 11:34:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13809
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 11:34:42 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFjE815394;
	Tue, 22 Apr 2003 11:45:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFg9815254
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 11:42:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13705
	for <megaco@ietf.org>; Tue, 22 Apr 2003 11:30:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197zku-0002Yn-00
	for megaco@ietf.org; Tue, 22 Apr 2003 11:32:24 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 197zkt-0002Yf-00
	for megaco@ietf.org; Tue, 22 Apr 2003 11:32:23 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 22 Apr 2003 11:32:14 -0400
Message-Id: <5.2.0.9.0.20030422094326.02b5a860@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Apr 2003 10:30:01 -0400
To: Christian Groves <Christian.Groves@ericsson.com.au>, megaco@ietf.org
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: Re: [Megaco] Megaco CAS support
Cc: Brad Steinka <bsteinka@telica.com>
In-Reply-To: <3EA484B4.8C2B5439@ericsson.com.au>
References: <C9AFC8E904D49C4593EB077A2E8402BA01510346@wench.telica.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 22 Apr 2003 15:32:14.0670 (UTC) FILETIME=[59AECEE0:01C308E4]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi Christian,

Then why are these brand new revisions of drafts were just recently submitted?

http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt

More over a quick look through reveals that some of the package items in icas
(ITU) the same as in r2 (IETF) up to the extent of exactly the same wording.

Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
does not seem to be defined in the document and also "conflicts" with above
IETF "CAS Maintenance Package".

There is also reference to r2 package in AVD-2316 nowhere found in ITU.

Also basic CAS packages draft still available at:
http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
but it is slightly different (outdated?) from AVD-2315 ITU version you have 
specified.

The recent submission of the above drafts had lead me to believe that CAS
work is still quite "up and running" in IETF. This is all very confusing.
When was it decided to move the work to ITU? Could someone point me out
to some references (in IETF) of that please?

My two cents on this topic: CAS is not an isolated package and in my opinion
it would be much more productive to keep it on both channels (ITU and IETF)
and in sync, similar to some other items done so far in H.248/MEGACO.
What other folks think about it?

Also in any case can the authors of ITU and IETF CAS related packages work
together to come up with some kind of game plan and post it to the list to 
avoid
any further confusion and inconsistencies?

Thanks!
         Aleks

At 07:54 PM 4/21/2003, Christian Groves wrote:
>G'Day Brad and Karl,
>
>I believe the intention is to move the CAS work into the ITU. The 
>contributions
>containing the latest drafts can be found at:
>ftp://standard.pictel.com/avc-site/0302_San/
>
>AVD-2312        MF Tone Generation and Detection Packages
>AVD-2315        Basic CAS Packages
>AVD-2316        International CAS Packages
>AVD-2317        Enhanced Analog Line Packages
>
>Regards, Christian
>
>Brad Steinka wrote:
> >
> > There were several RFC draft document that described various packages to
> > support CAS, R1, R2, BCAS, etc.
> > Most of these drafts have expired.
> >
> > Can anyone tell me what the latest RFCs are that support CAS calls and 
> where
> > they are in the standards process?
> >
> > Thanks
> >
> > Brad Steinka
> > Director - Software Engineering
> > 734 Forest Street, Building G, Suite 100
> > Marlboro, Ma.   01752
> > Tel:  508-480-0909  x154
> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> > Web:   www.telica.com <http://www.telica.com>
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 11:35:46 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13878
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 11:35:46 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MFlL215511
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 11:47:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFlL815508
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 11:47:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13843
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 11:35:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197zpw-0002ar-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 11:37:36 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 197zpv-0002ao-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 11:37:35 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFjE815394;
	Tue, 22 Apr 2003 11:45:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MFg9815254
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 11:42:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13705
	for <megaco@ietf.org>; Tue, 22 Apr 2003 11:30:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 197zku-0002Yn-00
	for megaco@ietf.org; Tue, 22 Apr 2003 11:32:24 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 197zkt-0002Yf-00
	for megaco@ietf.org; Tue, 22 Apr 2003 11:32:23 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 22 Apr 2003 11:32:14 -0400
Message-Id: <5.2.0.9.0.20030422094326.02b5a860@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Apr 2003 10:30:01 -0400
To: Christian Groves <Christian.Groves@ericsson.com.au>, megaco@ietf.org
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: Re: [Megaco] Megaco CAS support
Cc: Brad Steinka <bsteinka@telica.com>
In-Reply-To: <3EA484B4.8C2B5439@ericsson.com.au>
References: <C9AFC8E904D49C4593EB077A2E8402BA01510346@wench.telica.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 22 Apr 2003 15:32:14.0670 (UTC) FILETIME=[59AECEE0:01C308E4]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi Christian,

Then why are these brand new revisions of drafts were just recently submitted?

http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt

More over a quick look through reveals that some of the package items in icas
(ITU) the same as in r2 (IETF) up to the extent of exactly the same wording.

Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
does not seem to be defined in the document and also "conflicts" with above
IETF "CAS Maintenance Package".

There is also reference to r2 package in AVD-2316 nowhere found in ITU.

Also basic CAS packages draft still available at:
http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
but it is slightly different (outdated?) from AVD-2315 ITU version you have 
specified.

The recent submission of the above drafts had lead me to believe that CAS
work is still quite "up and running" in IETF. This is all very confusing.
When was it decided to move the work to ITU? Could someone point me out
to some references (in IETF) of that please?

My two cents on this topic: CAS is not an isolated package and in my opinion
it would be much more productive to keep it on both channels (ITU and IETF)
and in sync, similar to some other items done so far in H.248/MEGACO.
What other folks think about it?

Also in any case can the authors of ITU and IETF CAS related packages work
together to come up with some kind of game plan and post it to the list to 
avoid
any further confusion and inconsistencies?

Thanks!
         Aleks

At 07:54 PM 4/21/2003, Christian Groves wrote:
>G'Day Brad and Karl,
>
>I believe the intention is to move the CAS work into the ITU. The 
>contributions
>containing the latest drafts can be found at:
>ftp://standard.pictel.com/avc-site/0302_San/
>
>AVD-2312        MF Tone Generation and Detection Packages
>AVD-2315        Basic CAS Packages
>AVD-2316        International CAS Packages
>AVD-2317        Enhanced Analog Line Packages
>
>Regards, Christian
>
>Brad Steinka wrote:
> >
> > There were several RFC draft document that described various packages to
> > support CAS, R1, R2, BCAS, etc.
> > Most of these drafts have expired.
> >
> > Can anyone tell me what the latest RFCs are that support CAS calls and 
> where
> > they are in the standards process?
> >
> > Thanks
> >
> > Brad Steinka
> > Director - Software Engineering
> > 734 Forest Street, Building G, Suite 100
> > Marlboro, Ma.   01752
> > Tel:  508-480-0909  x154
> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> > Web:   www.telica.com <http://www.telica.com>
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 13:46:26 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17955
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 13:46:26 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHur825679;
	Tue, 22 Apr 2003 13:56:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHrC825345
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 13:53:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17757
	for <megaco@ietf.org>; Tue, 22 Apr 2003 13:41:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981ng-0003TG-00
	for megaco@ietf.org; Tue, 22 Apr 2003 13:43:24 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1981nX-0003QV-00
	for megaco@ietf.org; Tue, 22 Apr 2003 13:43:16 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042212403531:203 ;
          Tue, 22 Apr 2003 12:40:35 -0500 
Message-ID: <3EA58019.4090202@tekelec.com>
Date: Tue, 22 Apr 2003 12:47:05 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/22/2003 12:40:35 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/22/2003 12:43:40 PM,
	Serialize complete at 04/22/2003 12:43:40 PM
Content-Type: multipart/alternative;
 boundary="------------090106000602000008070300"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------090106000602000008070300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello, all,

I was wondering what is your oppinion on the following:

Another topic that is not addressed in the MEGACO spec is the case of a 
multi-homed MG, i.e. an MG where:
- the primary controller has 2 physical interfaces A1 and A2, 
potentially on 2 different subnets, working in load-sharing mode (rather 
than active-standby)
- the secondary MG controller can then be either transparrent (it takes 
over A1 and A2 on switchover) or non-transparent (has 2 more physical 
addresses, B1 and B2).

One may argue that multi-homing is not necessary, for example because 
you can always assign a single "logical" IP address A that is reachable 
over both interfaces A1 and A2. Yes, but this schema requires some 
dynamic IP routing capability in the backbone (e.g. to figure out when 
A1 is down and packets for A should be routed to A2), which has a number 
of disadvantages:
- Depending on the routing protocol, the latency for dynamic updates of 
the addresses can be very large (180 seconds in case of RIP), 
unacceptable for telephony.
- Depending on the network topology, interface failures may not become 
visible in the backbone. For example, if there is a LAN switch between 
the MG and the first router, then the router does not see when the 
interface A1 fails (unless the dynamic routing domain is extended to 
include the MG, which is not always the case).
- Some service providers (especially the smaller ones) do not run a 
dynamic IP routing protocol in their (whole) backbone, or they may not 
even have a real backbone, for example they may use leased lines, IP 
over ATM/FR PVCs with no sophisticated routing capabilities.

On the other hand, making the physical addresses A1 and A2 visible 
allows for redundant signaling paths to the MG using only static IP 
routing in the network, which in certain situations is desirable.

The MGC-MG redundancy schema gets even more complicated if you consider 
that the MGC can be multi-homed too. Effectively, it can have the same 
A1, A2, B1, B2 schema as the MG. In this case, what is really useful is 
an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes 
care of all the combinations. But if the MG supports only UDP, it is not 
clear from the standard how to emulate this SCTP behavior. For example:
- Some MGs do a DNS query for the MGC name, get 2 IP addresses in 
response, but they just ignore the second IP address, thus ignoring that 
the MGC is multi-homed.
- Other MGs consider the IP addresses as being 2 different MGCs, rather 
than one multi-homed MG. The problem is that they only talk to one MGC 
at a time, and then they need a "handover" to switch. So while talking 
on A1-A1, the MGC cannot for example audit on A2-A2, because this is 
immediately considered a failover (causing for example the pending 
notifications to be lost). The MGCP spec, for example, explicitly states 
that an MG should not change its controlling entity when being audited 
from another IP address (and it doesn't say whether this is a different 
MGC or the same multi-homed MGC).

I think what needs to be clarified here is:
- Whether an MG/MGC can be multi-homed and how to handle its multiple IP 
addresses.
- Whether an MG/MGC with active-standby controllers, transparent or 
non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
- Whether a domain name for an MG/MGC which yields more than one IP 
address through DNS, is associated with one controller, or with an 
active-standby pair, or possibly even with more active-standby pairs. 

The case with non-transparent MG controller switchover, as Flemming 
mentioned, poses additional problems. For example, if the active MG 
controller loses connectivity over A1 and A2, it may not even notice, 
because not all MGs do heartbeats. So if the MGC determines it can 
actually talk to B1 and B2, it cannot force an MG controller switchover, 
or at least the standard does not define the procedure for this. I would 
note that, in practice, however, most of the MGs and MGCs have 
transparent switchover (there is no B1, B2, they reuse A1, A2 ...).

The MGCP spec is a little more explicit on how the IP addresses are 
handled. So I don't understand why this topic is outside the scope of  
MEGACO.

I raised these issues because, from my experience, every single vendor 
interprets them differently, and MGC-MG redundancy is a delicate 
subject. Any suggestions?

Thanks

Adrian Soncodi,
Tekelec, Richardson, TX




Christian Groves wrote:

>G'Day Flemming,
>
>May be my brain hasn't restarted after the Easter break
>
>In cases other than 1a a failover method would be sent with the
>ServiceChangeMGCId which the address of the association new or existing. How the
>state synchronisation is done is still out of scope of Megaco. MG2 will either
>have the up to date state knowledge (eg. duplicate megaco messages) or it will
>have to audit or use some other means to find out.
>
>Is it the state sharing part that you are questioning?
>
>Regards, Christian
>
>Flemming Andreasen wrote:
>
>>Hi Christian
>>
>>Christian Groves wrote:
>>
>>>G'Day Fleming,
>>>
>>>The megaco model can support the configurations that you list below. The
>>>scenarios are implemented in such a way that the megaco interface is unaware
>>>that state synchronisation is occuring. It's for this reason that the
>>>specification doesn't say more about it, if you don't need Megaco messages then
>>>there's no point putting it in a megaco specification.
>>>
>>I agree with the last point, however it only applies to case 1a. Clearly something
>>has to happen in all the other cases, i.e. sending of a ServiceChange since the
>>failover is not 100% transparent and the MGC needs to be informed about the change
>>(whether it's a simple address change, mgcId change, or some degree of state loss).
>>As I noted before, Megaco is silent on this and if you were to conclude anything
>>from the current draft of Annex F, it would be that only model 1a is actually
>>supported today (at least in a standard manner). If you believe all of these models
>>actually are supported, then I'd like to know what ServiceChangeMethod,
>>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
>>you would use in each case (apart from 1a that is).
>>
>>-- Flemming
>>
>>>Regards, Christian
>>>
>>>Flemming Andreasen wrote:
>>>
>>>>Megaco supports some notion of redundant MGs and redundant MG failover,
>>>>however there is very little normative language, let alone explanation
>>>>of how this is supposed to work (and the current incarnation of the
>>>>upcoming Annex F doesn't help much here). The only model described is
>>>>the one in Section 11.4, where both the primary and secondary MG are
>>>>fully visible at all times and the MGC has to send duplicate messages to
>>>>the MG.  However, what about supporting models where the MGC does not
>>>>have to send multiple messages ? How does the protocol support the
>>>>following models (if at all):
>>>>
>>>>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
>>>>complete state duplication (included for completeness since this one
>>>>will be 100% transparent to the MGC).
>>>>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
>>>>there is complete Megaco state synchronization
>>>>1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
>>>>there is Megaco state synchronization at regular checkpoints (i.e. not
>>>>real-time so there may be some discrepances between the two)
>>>>2a) MG1 and MG2 have different IP addresses, and there is complete
>>>>Megaco state synchronization.
>>>>2b) MG1 and MG2 have different IP addresses, and there is Megaco state
>>>>synchronization at regular checkpoints (i.e. not real-time)
>>>>
>>>>Thanks
>>>>
>>>>        Flemming
>>>>
>>>>_______________________________________________
>>>>Megaco mailing list
>>>>Megaco@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>


--------------090106000602000008070300
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Hello, all,<br>
<br>
I was wondering what is your oppinion on the following:<br>
<br>
Another topic that is not addressed in the MEGACO spec is the case of a multi-homed
MG, i.e. an MG where:<br>
- the primary controller has 2 physical interfaces A1 and A2, potentially
on 2 different subnets, working in load-sharing mode (rather than active-standby)<br>
- the secondary MG controller can then be either transparrent (it takes over
A1 and A2 on switchover) or non-transparent (has 2 more physical addresses,
B1 and B2).<br>
<br>
One may argue that multi-homing is not necessary, for example because you
can always assign a single "logical" IP address A that is reachable over
both interfaces A1 and A2. Yes, but this schema requires some dynamic IP
routing capability in the backbone (e.g. to figure out when A1 is down and
packets for A should be routed to A2), which has a number of disadvantages:<br>
- Depending on the routing protocol, the latency for dynamic updates of the
addresses can be very large (180 seconds in case of RIP), unacceptable for
telephony.<br>
- Depending on the network topology, interface failures may not become visible
in the backbone. For example, if there is a LAN switch between the MG and
the first router, then the router does not see when the interface A1 fails
(unless the dynamic routing domain is extended to include the MG, which is
not always the case).<br>
- Some service providers (especially the smaller ones) do not run a dynamic
IP routing protocol in their (whole) backbone, or they may not even have
a real backbone, for example they may use leased lines, IP over ATM/FR PVCs
with no sophisticated routing capabilities. <br>
<br>
On the other hand, making the physical addresses A1 and A2 visible allows
for redundant signaling paths to the MG using only static IP routing in the
network, which in certain situations is desirable.<br>
<br>
The MGC-MG redundancy schema gets even more complicated if you consider that
the MGC can be multi-homed too. Effectively, it can have the same A1, A2,
B1, B2 schema as the MG. In this case, what is really useful is an SCTP association
(MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes care of all the combinations.
But if the MG supports only UDP, it is not clear from the standard how to
emulate this SCTP behavior. For example:<br>
- Some MGs do a DNS query for the MGC name, get 2 IP addresses in response,
but they just ignore the second IP address, thus ignoring that the MGC is
multi-homed.<br>
- Other MGs consider the IP addresses as being 2 different MGCs, rather than
one multi-homed MG. The problem is that they only talk to one MGC at a time,
and then they need a "handover" to switch. So while talking on A1-A1, the
MGC cannot for example audit on A2-A2, because this is immediately considered
a failover (causing for example the pending notifications to be lost). The
MGCP spec, for example, explicitly states that an MG should not change its
controlling entity when being audited from another IP address (and it doesn't
say whether this is a different MGC or the same multi-homed MGC).<br>
<br>
I think what needs to be clarified here is:<br>
- Whether an MG/MGC can be multi-homed and how to handle its multiple IP
addresses.<br>
- Whether an MG/MGC with active-standby controllers, transparent or non-transparent
switchover, are considered one MG/MGC or 2 MG/MGCs<br>
- Whether a domain name for an MG/MGC which yields more than one IP address
through DNS, is associated with one controller, or with an active-standby
pair, or possibly even with more active-standby pairs.&nbsp; <br>
<br>
The case with non-transparent MG controller switchover, as Flemming mentioned,
poses additional problems. For example, if the active MG controller loses
connectivity over A1 and A2, it may not even notice, because not all MGs
do heartbeats. So if the MGC determines it can actually talk to B1 and B2,
it cannot force an MG controller switchover, or at least the standard does
not define the procedure for this. I would note that, in practice, however,
most of the MGs and MGCs have transparent switchover (there is no B1, B2,
they reuse A1, A2 ...).<br>
<br>
The MGCP spec is a little more explicit on how the IP addresses are handled.
So I don't understand why this topic is outside the scope of&nbsp; MEGACO.<br>
<br>
I raised these issues because, from my experience, every single vendor interprets
them differently, and MGC-MG redundancy is a delicate subject. Any suggestions?<br>
<br>
Thanks<br>
<br>
Adrian Soncodi,<br>
Tekelec, Richardson, TX<br>
<br>
<br>
<br>
<br>
Christian Groves wrote:<br>
<blockquote type="cite" cite="mid:3EA4CE5B.2C2AC97B@ericsson.com.au">
  <pre wrap="">G'Day Flemming,<br><br>May be my brain hasn't restarted after the Easter break<br><br>In cases other than 1a a failover method would be sent with the<br>ServiceChangeMGCId which the address of the association new or existing. How the<br>state synchronisation is done is still out of scope of Megaco. MG2 will either<br>have the up to date state knowledge (eg. duplicate megaco messages) or it will<br>have to audit or use some other means to find out.<br><br>Is it the state sharing part that you are questioning?<br><br>Regards, Christian<br><br>Flemming Andreasen wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">Hi Christian<br><br>Christian Groves wrote:<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">G'Day Fleming,<br><br>The megaco model can support the configurations that you list below. The<br>scenarios are implemented in such a way that the megaco interface is unaware<br>that state synchronisation is occuring. It's for this reason that the<br>specification doesn't say more about it, if you don't need Megaco messages then<br>there's no point putting it in a megaco specification.<br><br></pre>
      </blockquote>
      <pre wrap="">I agree with the last point, however it only applies to case 1a. Clearly something<br>has to happen in all the other cases, i.e. sending of a ServiceChange since the<br>failover is not 100% transparent and the MGC needs to be informed about the change<br>(whether it's a simple address change, mgcId change, or some degree of state loss).<br>As I noted before, Megaco is silent on this and if you were to conclude anything<br>from the current draft of Annex F, it would be that only model 1a is actually<br>supported today (at least in a standard manner). If you believe all of these models<br>actually are supported, then I'd like to know what ServiceChangeMethod,<br>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)<br>you would use in each case (apart from 1a that is).<br><br>-- Flemming<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">Regards, Christian<br><br>Flemming Andreasen wrote:<br></pre>
        <blockquote type="cite">
          <pre wrap="">Megaco supports some notion of redundant MGs and redundant MG failover,<br>however there is very little normative language, let alone explanation<br>of how this is supposed to work (and the current incarnation of the<br>upcoming Annex F doesn't help much here). The only model described is<br>the one in Section 11.4, where both the primary and secondary MG are<br>fully visible at all times and the MGC has to send duplicate messages to<br>the MG.  However, what about supporting models where the MGC does not<br>have to send multiple messages ? How does the protocol support the<br>following models (if at all):<br><br>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with<br>complete state duplication (included for completeness since this one<br>will be 100% transparent to the MGC).<br>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and<br>there is complete Megaco state synchronization<br>1c) MG1 (primary) and MG2 (secondary) 
share the same IP-address, and<br>there is Megaco state synchronization at regular checkpoints (i.e. not<br>real-time so there may be some discrepances between the two)<br>2a) MG1 and MG2 have different IP addresses, and there is complete<br>Megaco state synchronization.<br>2b) MG1 and MG2 have different IP addresses, and there is Megaco state<br>synchronization at regular checkpoints (i.e. not real-time)<br><br>Thanks<br><br>        Flemming<br><br>_______________________________________________<br>Megaco mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a><br><a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a><br></pre>
          </blockquote>
          </blockquote>
          </blockquote>
          <pre wrap=""><!---->_______________________________________________<br>Megaco mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a><br><a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a><br><br></pre>
          </blockquote>
          <br>
          </body>
          </html>

--------------090106000602000008070300--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 13:47:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18007
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 13:47:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MHxEe25826
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 13:59:14 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHxE825823
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 13:59:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17988
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 13:47:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981tV-0003XL-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 13:49:25 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1981tV-0003XI-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 13:49:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHur825679;
	Tue, 22 Apr 2003 13:56:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHrC825345
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 13:53:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17757
	for <megaco@ietf.org>; Tue, 22 Apr 2003 13:41:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1981ng-0003TG-00
	for megaco@ietf.org; Tue, 22 Apr 2003 13:43:24 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1981nX-0003QV-00
	for megaco@ietf.org; Tue, 22 Apr 2003 13:43:16 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042212403531:203 ;
          Tue, 22 Apr 2003 12:40:35 -0500 
Message-ID: <3EA58019.4090202@tekelec.com>
Date: Tue, 22 Apr 2003 12:47:05 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/22/2003 12:40:35 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/22/2003 12:43:40 PM,
	Serialize complete at 04/22/2003 12:43:40 PM
Content-Type: multipart/alternative;
 boundary="------------090106000602000008070300"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------090106000602000008070300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello, all,

I was wondering what is your oppinion on the following:

Another topic that is not addressed in the MEGACO spec is the case of a 
multi-homed MG, i.e. an MG where:
- the primary controller has 2 physical interfaces A1 and A2, 
potentially on 2 different subnets, working in load-sharing mode (rather 
than active-standby)
- the secondary MG controller can then be either transparrent (it takes 
over A1 and A2 on switchover) or non-transparent (has 2 more physical 
addresses, B1 and B2).

One may argue that multi-homing is not necessary, for example because 
you can always assign a single "logical" IP address A that is reachable 
over both interfaces A1 and A2. Yes, but this schema requires some 
dynamic IP routing capability in the backbone (e.g. to figure out when 
A1 is down and packets for A should be routed to A2), which has a number 
of disadvantages:
- Depending on the routing protocol, the latency for dynamic updates of 
the addresses can be very large (180 seconds in case of RIP), 
unacceptable for telephony.
- Depending on the network topology, interface failures may not become 
visible in the backbone. For example, if there is a LAN switch between 
the MG and the first router, then the router does not see when the 
interface A1 fails (unless the dynamic routing domain is extended to 
include the MG, which is not always the case).
- Some service providers (especially the smaller ones) do not run a 
dynamic IP routing protocol in their (whole) backbone, or they may not 
even have a real backbone, for example they may use leased lines, IP 
over ATM/FR PVCs with no sophisticated routing capabilities.

On the other hand, making the physical addresses A1 and A2 visible 
allows for redundant signaling paths to the MG using only static IP 
routing in the network, which in certain situations is desirable.

The MGC-MG redundancy schema gets even more complicated if you consider 
that the MGC can be multi-homed too. Effectively, it can have the same 
A1, A2, B1, B2 schema as the MG. In this case, what is really useful is 
an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes 
care of all the combinations. But if the MG supports only UDP, it is not 
clear from the standard how to emulate this SCTP behavior. For example:
- Some MGs do a DNS query for the MGC name, get 2 IP addresses in 
response, but they just ignore the second IP address, thus ignoring that 
the MGC is multi-homed.
- Other MGs consider the IP addresses as being 2 different MGCs, rather 
than one multi-homed MG. The problem is that they only talk to one MGC 
at a time, and then they need a "handover" to switch. So while talking 
on A1-A1, the MGC cannot for example audit on A2-A2, because this is 
immediately considered a failover (causing for example the pending 
notifications to be lost). The MGCP spec, for example, explicitly states 
that an MG should not change its controlling entity when being audited 
from another IP address (and it doesn't say whether this is a different 
MGC or the same multi-homed MGC).

I think what needs to be clarified here is:
- Whether an MG/MGC can be multi-homed and how to handle its multiple IP 
addresses.
- Whether an MG/MGC with active-standby controllers, transparent or 
non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
- Whether a domain name for an MG/MGC which yields more than one IP 
address through DNS, is associated with one controller, or with an 
active-standby pair, or possibly even with more active-standby pairs. 

The case with non-transparent MG controller switchover, as Flemming 
mentioned, poses additional problems. For example, if the active MG 
controller loses connectivity over A1 and A2, it may not even notice, 
because not all MGs do heartbeats. So if the MGC determines it can 
actually talk to B1 and B2, it cannot force an MG controller switchover, 
or at least the standard does not define the procedure for this. I would 
note that, in practice, however, most of the MGs and MGCs have 
transparent switchover (there is no B1, B2, they reuse A1, A2 ...).

The MGCP spec is a little more explicit on how the IP addresses are 
handled. So I don't understand why this topic is outside the scope of  
MEGACO.

I raised these issues because, from my experience, every single vendor 
interprets them differently, and MGC-MG redundancy is a delicate 
subject. Any suggestions?

Thanks

Adrian Soncodi,
Tekelec, Richardson, TX




Christian Groves wrote:

>G'Day Flemming,
>
>May be my brain hasn't restarted after the Easter break
>
>In cases other than 1a a failover method would be sent with the
>ServiceChangeMGCId which the address of the association new or existing. How the
>state synchronisation is done is still out of scope of Megaco. MG2 will either
>have the up to date state knowledge (eg. duplicate megaco messages) or it will
>have to audit or use some other means to find out.
>
>Is it the state sharing part that you are questioning?
>
>Regards, Christian
>
>Flemming Andreasen wrote:
>
>>Hi Christian
>>
>>Christian Groves wrote:
>>
>>>G'Day Fleming,
>>>
>>>The megaco model can support the configurations that you list below. The
>>>scenarios are implemented in such a way that the megaco interface is unaware
>>>that state synchronisation is occuring. It's for this reason that the
>>>specification doesn't say more about it, if you don't need Megaco messages then
>>>there's no point putting it in a megaco specification.
>>>
>>I agree with the last point, however it only applies to case 1a. Clearly something
>>has to happen in all the other cases, i.e. sending of a ServiceChange since the
>>failover is not 100% transparent and the MGC needs to be informed about the change
>>(whether it's a simple address change, mgcId change, or some degree of state loss).
>>As I noted before, Megaco is silent on this and if you were to conclude anything
>>from the current draft of Annex F, it would be that only model 1a is actually
>>supported today (at least in a standard manner). If you believe all of these models
>>actually are supported, then I'd like to know what ServiceChangeMethod,
>>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
>>you would use in each case (apart from 1a that is).
>>
>>-- Flemming
>>
>>>Regards, Christian
>>>
>>>Flemming Andreasen wrote:
>>>
>>>>Megaco supports some notion of redundant MGs and redundant MG failover,
>>>>however there is very little normative language, let alone explanation
>>>>of how this is supposed to work (and the current incarnation of the
>>>>upcoming Annex F doesn't help much here). The only model described is
>>>>the one in Section 11.4, where both the primary and secondary MG are
>>>>fully visible at all times and the MGC has to send duplicate messages to
>>>>the MG.  However, what about supporting models where the MGC does not
>>>>have to send multiple messages ? How does the protocol support the
>>>>following models (if at all):
>>>>
>>>>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
>>>>complete state duplication (included for completeness since this one
>>>>will be 100% transparent to the MGC).
>>>>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
>>>>there is complete Megaco state synchronization
>>>>1c) MG1 (primary) and MG2 (secondary) share the same IP-address, and
>>>>there is Megaco state synchronization at regular checkpoints (i.e. not
>>>>real-time so there may be some discrepances between the two)
>>>>2a) MG1 and MG2 have different IP addresses, and there is complete
>>>>Megaco state synchronization.
>>>>2b) MG1 and MG2 have different IP addresses, and there is Megaco state
>>>>synchronization at regular checkpoints (i.e. not real-time)
>>>>
>>>>Thanks
>>>>
>>>>        Flemming
>>>>
>>>>_______________________________________________
>>>>Megaco mailing list
>>>>Megaco@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>


--------------090106000602000008070300
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Hello, all,<br>
<br>
I was wondering what is your oppinion on the following:<br>
<br>
Another topic that is not addressed in the MEGACO spec is the case of a multi-homed
MG, i.e. an MG where:<br>
- the primary controller has 2 physical interfaces A1 and A2, potentially
on 2 different subnets, working in load-sharing mode (rather than active-standby)<br>
- the secondary MG controller can then be either transparrent (it takes over
A1 and A2 on switchover) or non-transparent (has 2 more physical addresses,
B1 and B2).<br>
<br>
One may argue that multi-homing is not necessary, for example because you
can always assign a single "logical" IP address A that is reachable over
both interfaces A1 and A2. Yes, but this schema requires some dynamic IP
routing capability in the backbone (e.g. to figure out when A1 is down and
packets for A should be routed to A2), which has a number of disadvantages:<br>
- Depending on the routing protocol, the latency for dynamic updates of the
addresses can be very large (180 seconds in case of RIP), unacceptable for
telephony.<br>
- Depending on the network topology, interface failures may not become visible
in the backbone. For example, if there is a LAN switch between the MG and
the first router, then the router does not see when the interface A1 fails
(unless the dynamic routing domain is extended to include the MG, which is
not always the case).<br>
- Some service providers (especially the smaller ones) do not run a dynamic
IP routing protocol in their (whole) backbone, or they may not even have
a real backbone, for example they may use leased lines, IP over ATM/FR PVCs
with no sophisticated routing capabilities. <br>
<br>
On the other hand, making the physical addresses A1 and A2 visible allows
for redundant signaling paths to the MG using only static IP routing in the
network, which in certain situations is desirable.<br>
<br>
The MGC-MG redundancy schema gets even more complicated if you consider that
the MGC can be multi-homed too. Effectively, it can have the same A1, A2,
B1, B2 schema as the MG. In this case, what is really useful is an SCTP association
(MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes care of all the combinations.
But if the MG supports only UDP, it is not clear from the standard how to
emulate this SCTP behavior. For example:<br>
- Some MGs do a DNS query for the MGC name, get 2 IP addresses in response,
but they just ignore the second IP address, thus ignoring that the MGC is
multi-homed.<br>
- Other MGs consider the IP addresses as being 2 different MGCs, rather than
one multi-homed MG. The problem is that they only talk to one MGC at a time,
and then they need a "handover" to switch. So while talking on A1-A1, the
MGC cannot for example audit on A2-A2, because this is immediately considered
a failover (causing for example the pending notifications to be lost). The
MGCP spec, for example, explicitly states that an MG should not change its
controlling entity when being audited from another IP address (and it doesn't
say whether this is a different MGC or the same multi-homed MGC).<br>
<br>
I think what needs to be clarified here is:<br>
- Whether an MG/MGC can be multi-homed and how to handle its multiple IP
addresses.<br>
- Whether an MG/MGC with active-standby controllers, transparent or non-transparent
switchover, are considered one MG/MGC or 2 MG/MGCs<br>
- Whether a domain name for an MG/MGC which yields more than one IP address
through DNS, is associated with one controller, or with an active-standby
pair, or possibly even with more active-standby pairs.&nbsp; <br>
<br>
The case with non-transparent MG controller switchover, as Flemming mentioned,
poses additional problems. For example, if the active MG controller loses
connectivity over A1 and A2, it may not even notice, because not all MGs
do heartbeats. So if the MGC determines it can actually talk to B1 and B2,
it cannot force an MG controller switchover, or at least the standard does
not define the procedure for this. I would note that, in practice, however,
most of the MGs and MGCs have transparent switchover (there is no B1, B2,
they reuse A1, A2 ...).<br>
<br>
The MGCP spec is a little more explicit on how the IP addresses are handled.
So I don't understand why this topic is outside the scope of&nbsp; MEGACO.<br>
<br>
I raised these issues because, from my experience, every single vendor interprets
them differently, and MGC-MG redundancy is a delicate subject. Any suggestions?<br>
<br>
Thanks<br>
<br>
Adrian Soncodi,<br>
Tekelec, Richardson, TX<br>
<br>
<br>
<br>
<br>
Christian Groves wrote:<br>
<blockquote type="cite" cite="mid:3EA4CE5B.2C2AC97B@ericsson.com.au">
  <pre wrap="">G'Day Flemming,<br><br>May be my brain hasn't restarted after the Easter break<br><br>In cases other than 1a a failover method would be sent with the<br>ServiceChangeMGCId which the address of the association new or existing. How the<br>state synchronisation is done is still out of scope of Megaco. MG2 will either<br>have the up to date state knowledge (eg. duplicate megaco messages) or it will<br>have to audit or use some other means to find out.<br><br>Is it the state sharing part that you are questioning?<br><br>Regards, Christian<br><br>Flemming Andreasen wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">Hi Christian<br><br>Christian Groves wrote:<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">G'Day Fleming,<br><br>The megaco model can support the configurations that you list below. The<br>scenarios are implemented in such a way that the megaco interface is unaware<br>that state synchronisation is occuring. It's for this reason that the<br>specification doesn't say more about it, if you don't need Megaco messages then<br>there's no point putting it in a megaco specification.<br><br></pre>
      </blockquote>
      <pre wrap="">I agree with the last point, however it only applies to case 1a. Clearly something<br>has to happen in all the other cases, i.e. sending of a ServiceChange since the<br>failover is not 100% transparent and the MGC needs to be informed about the change<br>(whether it's a simple address change, mgcId change, or some degree of state loss).<br>As I noted before, Megaco is silent on this and if you were to conclude anything<br>from the current draft of Annex F, it would be that only model 1a is actually<br>supported today (at least in a standard manner). If you believe all of these models<br>actually are supported, then I'd like to know what ServiceChangeMethod,<br>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)<br>you would use in each case (apart from 1a that is).<br><br>-- Flemming<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">Regards, Christian<br><br>Flemming Andreasen wrote:<br></pre>
        <blockquote type="cite">
          <pre wrap="">Megaco supports some notion of redundant MGs and redundant MG failover,<br>however there is very little normative language, let alone explanation<br>of how this is supposed to work (and the current incarnation of the<br>upcoming Annex F doesn't help much here). The only model described is<br>the one in Section 11.4, where both the primary and secondary MG are<br>fully visible at all times and the MGC has to send duplicate messages to<br>the MG.  However, what about supporting models where the MGC does not<br>have to send multiple messages ? How does the protocol support the<br>following models (if at all):<br><br>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with<br>complete state duplication (included for completeness since this one<br>will be 100% transparent to the MGC).<br>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and<br>there is complete Megaco state synchronization<br>1c) MG1 (primary) and MG2 (secondary) 
share the same IP-address, and<br>there is Megaco state synchronization at regular checkpoints (i.e. not<br>real-time so there may be some discrepances between the two)<br>2a) MG1 and MG2 have different IP addresses, and there is complete<br>Megaco state synchronization.<br>2b) MG1 and MG2 have different IP addresses, and there is Megaco state<br>synchronization at regular checkpoints (i.e. not real-time)<br><br>Thanks<br><br>        Flemming<br><br>_______________________________________________<br>Megaco mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a><br><a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a><br></pre>
          </blockquote>
          </blockquote>
          </blockquote>
          <pre wrap=""><!---->_______________________________________________<br>Megaco mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a><br><a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a><br><br></pre>
          </blockquote>
          <br>
          </body>
          </html>

--------------090106000602000008070300--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 17:14:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27025
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 17:14:16 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLOi811468;
	Tue, 22 Apr 2003 17:24:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLBD810684
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 17:11:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26338
	for <megaco@ietf.org>; Tue, 22 Apr 2003 16:59:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1984tF-0005O1-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:01:21 -0400
Received: from f72.law14.hotmail.com ([64.4.21.72] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1984tE-0005NF-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:01:20 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 22 Apr 2003 14:01:09 -0700
Received: from 151.203.212.231 by lw14fd.law14.hotmail.msn.com with HTTP;
	Tue, 22 Apr 2003 21:01:08 GMT
X-Originating-IP: [151.203.212.231]
X-Originating-Email: [michaeldigioia@hotmail.com]
From: "Michael DiGioia" <michaeldigioia@hotmail.com>
To: kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support
Date: Tue, 22 Apr 2003 17:01:08 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law14-F72G5bTHuICqc0000d8c3@hotmail.com>
X-OriginalArrivalTime: 22 Apr 2003 21:01:09.0024 (UTC) FILETIME=[4C464200:01C30912]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Christian,

I agree, CAS should be part of the IETF similar to the original MEGACO draft 
work that held both organizations in sync.

/mpd




>From: Aleksandr Ryabin <kengr@winphoria.com>
>To: Christian Groves <Christian.Groves@ericsson.com.au>, megaco@ietf.org
>CC: Brad Steinka <bsteinka@telica.com>
>Subject: Re: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 10:30:01 -0400
>
>Hi Christian,
>
>Then why are these brand new revisions of drafts were just recently 
>submitted?
>
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>
>More over a quick look through reveals that some of the package items in 
>icas
>(ITU) the same as in r2 (IETF) up to the extent of exactly the same 
>wording.
>
>Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
>does not seem to be defined in the document and also "conflicts" with above
>IETF "CAS Maintenance Package".
>
>There is also reference to r2 package in AVD-2316 nowhere found in ITU.
>
>Also basic CAS packages draft still available at:
>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
>but it is slightly different (outdated?) from AVD-2315 ITU version you have 
>specified.
>
>The recent submission of the above drafts had lead me to believe that CAS
>work is still quite "up and running" in IETF. This is all very confusing.
>When was it decided to move the work to ITU? Could someone point me out
>to some references (in IETF) of that please?
>
>My two cents on this topic: CAS is not an isolated package and in my 
>opinion
>it would be much more productive to keep it on both channels (ITU and IETF)
>and in sync, similar to some other items done so far in H.248/MEGACO.
>What other folks think about it?
>
>Also in any case can the authors of ITU and IETF CAS related packages work
>together to come up with some kind of game plan and post it to the list to 
>avoid
>any further confusion and inconsistencies?
>
>Thanks!
>         Aleks
>
>At 07:54 PM 4/21/2003, Christian Groves wrote:
>>G'Day Brad and Karl,
>>
>>I believe the intention is to move the CAS work into the ITU. The 
>>contributions
>>containing the latest drafts can be found at:
>>ftp://standard.pictel.com/avc-site/0302_San/
>>
>>AVD-2312        MF Tone Generation and Detection Packages
>>AVD-2315        Basic CAS Packages
>>AVD-2316        International CAS Packages
>>AVD-2317        Enhanced Analog Line Packages
>>
>>Regards, Christian
>>
>>Brad Steinka wrote:
>> >
>> > There were several RFC draft document that described various packages 
>>to
>> > support CAS, R1, R2, BCAS, etc.
>> > Most of these drafts have expired.
>> >
>> > Can anyone tell me what the latest RFCs are that support CAS calls and 
>>where
>> > they are in the standards process?
>> >
>> > Thanks
>> >
>> > Brad Steinka
>> > Director - Software Engineering
>> > 734 Forest Street, Building G, Suite 100
>> > Marlboro, Ma.   01752
>> > Tel:  508-480-0909  x154
>> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> > Web:   www.telica.com <http://www.telica.com>
>> >
>> > _______________________________________________
>> > Megaco mailing list
>> > Megaco@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/megaco
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 17:15:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27094
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 17:15:25 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MLR7T11625
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 17:27:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLR7811622
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 17:27:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27075
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 17:14:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19858c-0005VP-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 17:17:14 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19858c-0005VL-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 17:17:14 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLOi811468;
	Tue, 22 Apr 2003 17:24:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLBD810684
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 17:11:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26338
	for <megaco@ietf.org>; Tue, 22 Apr 2003 16:59:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1984tF-0005O1-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:01:21 -0400
Received: from f72.law14.hotmail.com ([64.4.21.72] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1984tE-0005NF-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:01:20 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 22 Apr 2003 14:01:09 -0700
Received: from 151.203.212.231 by lw14fd.law14.hotmail.msn.com with HTTP;
	Tue, 22 Apr 2003 21:01:08 GMT
X-Originating-IP: [151.203.212.231]
X-Originating-Email: [michaeldigioia@hotmail.com]
From: "Michael DiGioia" <michaeldigioia@hotmail.com>
To: kengr@winphoria.com, Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support
Date: Tue, 22 Apr 2003 17:01:08 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law14-F72G5bTHuICqc0000d8c3@hotmail.com>
X-OriginalArrivalTime: 22 Apr 2003 21:01:09.0024 (UTC) FILETIME=[4C464200:01C30912]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


Christian,

I agree, CAS should be part of the IETF similar to the original MEGACO draft 
work that held both organizations in sync.

/mpd




>From: Aleksandr Ryabin <kengr@winphoria.com>
>To: Christian Groves <Christian.Groves@ericsson.com.au>, megaco@ietf.org
>CC: Brad Steinka <bsteinka@telica.com>
>Subject: Re: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 10:30:01 -0400
>
>Hi Christian,
>
>Then why are these brand new revisions of drafts were just recently 
>submitted?
>
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>
>More over a quick look through reveals that some of the package items in 
>icas
>(ITU) the same as in r2 (IETF) up to the extent of exactly the same 
>wording.
>
>Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
>does not seem to be defined in the document and also "conflicts" with above
>IETF "CAS Maintenance Package".
>
>There is also reference to r2 package in AVD-2316 nowhere found in ITU.
>
>Also basic CAS packages draft still available at:
>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
>but it is slightly different (outdated?) from AVD-2315 ITU version you have 
>specified.
>
>The recent submission of the above drafts had lead me to believe that CAS
>work is still quite "up and running" in IETF. This is all very confusing.
>When was it decided to move the work to ITU? Could someone point me out
>to some references (in IETF) of that please?
>
>My two cents on this topic: CAS is not an isolated package and in my 
>opinion
>it would be much more productive to keep it on both channels (ITU and IETF)
>and in sync, similar to some other items done so far in H.248/MEGACO.
>What other folks think about it?
>
>Also in any case can the authors of ITU and IETF CAS related packages work
>together to come up with some kind of game plan and post it to the list to 
>avoid
>any further confusion and inconsistencies?
>
>Thanks!
>         Aleks
>
>At 07:54 PM 4/21/2003, Christian Groves wrote:
>>G'Day Brad and Karl,
>>
>>I believe the intention is to move the CAS work into the ITU. The 
>>contributions
>>containing the latest drafts can be found at:
>>ftp://standard.pictel.com/avc-site/0302_San/
>>
>>AVD-2312        MF Tone Generation and Detection Packages
>>AVD-2315        Basic CAS Packages
>>AVD-2316        International CAS Packages
>>AVD-2317        Enhanced Analog Line Packages
>>
>>Regards, Christian
>>
>>Brad Steinka wrote:
>> >
>> > There were several RFC draft document that described various packages 
>>to
>> > support CAS, R1, R2, BCAS, etc.
>> > Most of these drafts have expired.
>> >
>> > Can anyone tell me what the latest RFCs are that support CAS calls and 
>>where
>> > they are in the standards process?
>> >
>> > Thanks
>> >
>> > Brad Steinka
>> > Director - Software Engineering
>> > 734 Forest Street, Building G, Suite 100
>> > Marlboro, Ma.   01752
>> > Tel:  508-480-0909  x154
>> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> > Web:   www.telica.com <http://www.telica.com>
>> >
>> > _______________________________________________
>> > Megaco mailing list
>> > Megaco@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/megaco
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 17:35:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27697
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 17:35:47 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLkJ813430;
	Tue, 22 Apr 2003 17:46:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLaS812287
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 17:36:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27424
	for <megaco@ietf.org>; Tue, 22 Apr 2003 17:24:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985Hf-0005bi-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:26:35 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985He-0005bP-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:26:34 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MLQLN02390
	for <megaco@ietf.org>; Tue, 22 Apr 2003 17:26:22 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J961AF0>; Tue, 22 Apr 2003 17:26:22 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E02CF5@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,
        Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support
Date: Tue, 22 Apr 2003 17:26:15 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

With all due respect, the IETF had its chance to progress these (and many
other) packages.  In the interests of the larger community, I have taken the
packages to the ITU for standardization, since the IETF does not seem
interested in standardizing any packages.

The work in the IETF is not "up and running".  The drafts published by
Hughes were published after the CAS packages were submitted to the ITU.

Given that the working group is in the process of winding down, I do not see
any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.

Kevin

-----Original Message-----
From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] 
Sent: Tuesday, April 22, 2003 5:01 PM
To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
Cc: bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support



Christian,

I agree, CAS should be part of the IETF similar to the original MEGACO draft

work that held both organizations in sync.

/mpd




>From: Aleksandr Ryabin <kengr@winphoria.com>
>To: Christian Groves <Christian.Groves@ericsson.com.au>, 
>megaco@ietf.org
>CC: Brad Steinka <bsteinka@telica.com>
>Subject: Re: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 10:30:01 -0400
>
>Hi Christian,
>
>Then why are these brand new revisions of drafts were just recently
>submitted?
>
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>
>More over a quick look through reveals that some of the package items 
>in
>icas
>(ITU) the same as in r2 (IETF) up to the extent of exactly the same 
>wording.
>
>Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which 
>does not seem to be defined in the document and also "conflicts" with 
>above IETF "CAS Maintenance Package".
>
>There is also reference to r2 package in AVD-2316 nowhere found in ITU.
>
>Also basic CAS packages draft still available at: 
>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
>2.txt
>but it is slightly different (outdated?) from AVD-2315 ITU version you have

>specified.
>
>The recent submission of the above drafts had lead me to believe that 
>CAS work is still quite "up and running" in IETF. This is all very 
>confusing. When was it decided to move the work to ITU? Could someone 
>point me out to some references (in IETF) of that please?
>
>My two cents on this topic: CAS is not an isolated package and in my
>opinion
>it would be much more productive to keep it on both channels (ITU and IETF)
>and in sync, similar to some other items done so far in H.248/MEGACO.
>What other folks think about it?
>
>Also in any case can the authors of ITU and IETF CAS related packages 
>work together to come up with some kind of game plan and post it to the 
>list to avoid any further confusion and inconsistencies?
>
>Thanks!
>         Aleks
>
>At 07:54 PM 4/21/2003, Christian Groves wrote:
>>G'Day Brad and Karl,
>>
>>I believe the intention is to move the CAS work into the ITU. The
>>contributions
>>containing the latest drafts can be found at:
>>ftp://standard.pictel.com/avc-site/0302_San/
>>
>>AVD-2312        MF Tone Generation and Detection Packages
>>AVD-2315        Basic CAS Packages
>>AVD-2316        International CAS Packages
>>AVD-2317        Enhanced Analog Line Packages
>>
>>Regards, Christian
>>
>>Brad Steinka wrote:
>> >
>> > There were several RFC draft document that described various 
>> > packages
>>to
>> > support CAS, R1, R2, BCAS, etc.
>> > Most of these drafts have expired.
>> >
>> > Can anyone tell me what the latest RFCs are that support CAS calls 
>> > and
>>where
>> > they are in the standards process?
>> >
>> > Thanks
>> >
>> > Brad Steinka
>> > Director - Software Engineering
>> > 734 Forest Street, Building G, Suite 100
>> > Marlboro, Ma.   01752
>> > Tel:  508-480-0909  x154
>> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> > Web:   www.telica.com <http://www.telica.com>
>> >
>> > _______________________________________________
>> > Megaco mailing list
>> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 17:36:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27723
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 17:36:54 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MLmbq13538
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 17:48:37 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLmb813535
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 17:48:37 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27717
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 17:36:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985TQ-0005fQ-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 17:38:44 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1985TP-0005fN-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 17:38:43 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLkJ813430;
	Tue, 22 Apr 2003 17:46:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MLaS812287
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 17:36:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27424
	for <megaco@ietf.org>; Tue, 22 Apr 2003 17:24:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985Hf-0005bi-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:26:35 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 1985He-0005bP-00
	for megaco@ietf.org; Tue, 22 Apr 2003 17:26:34 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3MLQLN02390
	for <megaco@ietf.org>; Tue, 22 Apr 2003 17:26:22 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J961AF0>; Tue, 22 Apr 2003 17:26:22 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E02CF5@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,
        Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support
Date: Tue, 22 Apr 2003 17:26:15 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

With all due respect, the IETF had its chance to progress these (and many
other) packages.  In the interests of the larger community, I have taken the
packages to the ITU for standardization, since the IETF does not seem
interested in standardizing any packages.

The work in the IETF is not "up and running".  The drafts published by
Hughes were published after the CAS packages were submitted to the ITU.

Given that the working group is in the process of winding down, I do not see
any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.

Kevin

-----Original Message-----
From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] 
Sent: Tuesday, April 22, 2003 5:01 PM
To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
Cc: bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support



Christian,

I agree, CAS should be part of the IETF similar to the original MEGACO draft

work that held both organizations in sync.

/mpd




>From: Aleksandr Ryabin <kengr@winphoria.com>
>To: Christian Groves <Christian.Groves@ericsson.com.au>, 
>megaco@ietf.org
>CC: Brad Steinka <bsteinka@telica.com>
>Subject: Re: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 10:30:01 -0400
>
>Hi Christian,
>
>Then why are these brand new revisions of drafts were just recently
>submitted?
>
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>
>More over a quick look through reveals that some of the package items 
>in
>icas
>(ITU) the same as in r2 (IETF) up to the extent of exactly the same 
>wording.
>
>Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which 
>does not seem to be defined in the document and also "conflicts" with 
>above IETF "CAS Maintenance Package".
>
>There is also reference to r2 package in AVD-2316 nowhere found in ITU.
>
>Also basic CAS packages draft still available at: 
>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
>2.txt
>but it is slightly different (outdated?) from AVD-2315 ITU version you have

>specified.
>
>The recent submission of the above drafts had lead me to believe that 
>CAS work is still quite "up and running" in IETF. This is all very 
>confusing. When was it decided to move the work to ITU? Could someone 
>point me out to some references (in IETF) of that please?
>
>My two cents on this topic: CAS is not an isolated package and in my
>opinion
>it would be much more productive to keep it on both channels (ITU and IETF)
>and in sync, similar to some other items done so far in H.248/MEGACO.
>What other folks think about it?
>
>Also in any case can the authors of ITU and IETF CAS related packages 
>work together to come up with some kind of game plan and post it to the 
>list to avoid any further confusion and inconsistencies?
>
>Thanks!
>         Aleks
>
>At 07:54 PM 4/21/2003, Christian Groves wrote:
>>G'Day Brad and Karl,
>>
>>I believe the intention is to move the CAS work into the ITU. The
>>contributions
>>containing the latest drafts can be found at:
>>ftp://standard.pictel.com/avc-site/0302_San/
>>
>>AVD-2312        MF Tone Generation and Detection Packages
>>AVD-2315        Basic CAS Packages
>>AVD-2316        International CAS Packages
>>AVD-2317        Enhanced Analog Line Packages
>>
>>Regards, Christian
>>
>>Brad Steinka wrote:
>> >
>> > There were several RFC draft document that described various 
>> > packages
>>to
>> > support CAS, R1, R2, BCAS, etc.
>> > Most of these drafts have expired.
>> >
>> > Can anyone tell me what the latest RFCs are that support CAS calls 
>> > and
>>where
>> > they are in the standards process?
>> >
>> > Thanks
>> >
>> > Brad Steinka
>> > Director - Software Engineering
>> > 734 Forest Street, Building G, Suite 100
>> > Marlboro, Ma.   01752
>> > Tel:  508-480-0909  x154
>> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> > Web:   www.telica.com <http://www.telica.com>
>> >
>> > _______________________________________________
>> > Megaco mailing list
>> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 19:34:24 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01424
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 19:34:24 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNiW821241;
	Tue, 22 Apr 2003 19:44:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNc4821044
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 19:38:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01324
	for <megaco@ietf.org>; Tue, 22 Apr 2003 19:25:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1987BI-0006Iu-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:28:08 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1987BI-0006In-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:28:08 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 22 Apr 2003 19:27:58 -0400
Message-Id: <5.2.0.9.0.20030422173419.02a99fc0@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Apr 2003 19:04:50 -0400
To: megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: RE: [Megaco] Megaco CAS support
Cc: Michael DiGioia <michaeldigioia@hotmail.com>,
        Christian.Groves@ericsson.com.au, bsteinka@telica.com
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C08E02CF5@zrtpd0jq.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_89129541==.ALT"
X-OriginalArrivalTime: 22 Apr 2003 23:27:58.0576 (UTC) FILETIME=[CF2D3700:01C30926]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_89129541==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I see the reason to push it through ITU, but we definitely would not want to
see two, or more different packages doing the same thing published one through
IETF and another trough ITU. Thus, since MEGACO is (also) published as
IETF standard we should at least make every effort to avoid duplication of 
work.

Unfortunately not all of us have direct access (at least direct say) in ITU 
and
thus at least keeping IETF community informed on progress of MEGACO/H.248
related work would be very useful, as well as using this list for various 
discussions.
In fact AVD-2345 contains the following statement regarding H.248.mf packages:
"It was suggested that we send a liaison to the IESG and MEGACO proposing
this move and asking if this presents a problem to either of them.  Mr Boyle
will draft a liaison for our consideration.  If we do not receive an 
objection from
them we will progress these with a goal of consent in May.  The liaison 
appears
as TD-20a." Should then the r2 package also be included in same liaison?

As far as I remember "CAS packages published by Hughes" are new revisions
of the drafts that were published a long time ago (at least for r2). This 
very fact
that new revisions were published despite the CAS work moved to ITU indicates
the lack of communication.

Can I suggest to put some wording on WG charter home page regarding
each work "moved" to ITU (links to liaisons?) and maybe at least some kind
of sense of ITU schedule for that work? I know there is wording already about
IETF position related to packages, but still info would be very useful.
At least a pointer to latest up to date "packages guide" (AVD-2294) might be
sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph from
AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)

In any case could you please outline an ITU schedule for CAS related packages?
What is the verdict for CAS drafts published in IETF? Are they going to be 
folded
into ITU work? I guess at least some of them (by Nortel) are? What about 
others?
Is r2 package planned to be dropped/replaced with icas?
Are there any additional ITU CAS related packages/documents not listed
in original Christian's email?
Are there any other CAS packages planned?

Thanks
         Aleks

At 05:26 PM 4/22/2003, Kevin Boyle wrote:

>With all due respect, the IETF had its chance to progress these (and many 
>other) packages.  In the interests of the larger community, I have taken 
>the packages to the ITU for standardization, since the IETF does not seem 
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by 
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do not 
>see any benefit to anyone in continuing to allow the IETF to hold up 
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia 
>[<mailto:michaeldigioia@hotmail.com>mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO draft
>work that held both organizations in sync.
>
>/mpd
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> ><http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt>h 
> ttp://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> ><http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0> 
> http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >><ftp://standard.pictel.com/avc-site/0302_San/>ftp://standard.pictel.com/ 
> avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com 
> <<mailto:bsteinka@telica.com>mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <<http://www.telica.com>http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org 
> <https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mai 
> lman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> ><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mail 
> man/listinfo/megaco
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
><http://join.msn.com/?page=features/virus>http://join.msn.com/?page=features/virus 
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>

--=====================_89129541==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
I see the reason to push it through ITU, but we definitely would not want
to<br>
see two, or more different packages doing the same thing published one
through <br>
IETF and another trough ITU. Thus, since MEGACO is (also) published as
<br>
IETF standard we should at least make every effort to avoid duplication
of work.<br><br>
Unfortunately not all of us have direct access (at least direct say) in
ITU and <br>
thus at least keeping IETF community informed on progress of MEGACO/H.248
<br>
related work would be very useful, as well as using this list for various
discussions.<br>
In fact AVD-2345 contains the following statement regarding H.248.mf
packages:<br>
&quot;It was suggested that we send a liaison to the IESG and MEGACO
proposing <br>
this move and asking if this presents a problem to either of them.&nbsp;
Mr Boyle <br>
will draft a liaison for our consideration.&nbsp; If we do not receive an
objection from <br>
them we will progress these with a goal of consent in May.&nbsp; The
liaison appears <br>
as TD-20a.&quot; Should then the r2 package also be included in same
liaison?<br><br>
As far as I remember &quot;CAS packages published by Hughes&quot; are new
revisions<br>
of the drafts that were published a long time ago (at least for r2). This
very fact <br>
that new revisions were published despite the CAS work moved to ITU
indicates <br>
the lack of communication.<br><br>
Can I suggest to put some wording on WG charter home page regarding<br>
each work &quot;moved&quot; to ITU (links to liaisons?) and maybe at
least some kind <br>
of sense of ITU schedule for that work? I know there is wording already
about <br>
IETF position related to packages, but still info would be very
useful.<br>
At least a pointer to latest up to date &quot;packages guide&quot;
(AVD-2294) might be <br>
sufficient and H.248 related parts from 3.1.6 &quot;Document Status&quot;
paragraph from <br>
AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of
ITU)<br><br>
In any case could you please outline an ITU schedule for CAS related
packages?<br>
What is the verdict for CAS drafts published in IETF? Are they going to
be folded <br>
into ITU work? I guess at least some of them (by Nortel) are? What about
others?<br>
Is r2 package planned to be dropped/replaced with icas?<br>
Are there any additional ITU CAS related packages/documents not
listed<br>
in original <font size=2>Christian</font>'s email? <br>
Are there any other CAS packages planned?<br><br>
Thanks<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 05:26 PM 4/22/2003, Kevin Boyle wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>With all due respect,
the IETF had its chance to progress these (and many other)
packages.&nbsp; In the interests of the larger community, I have taken
the packages to the ITU for standardization, since the IETF does not seem
interested in standardizing any packages.<br>
</font><br>
<font size=2>The work in the IETF is not &quot;up and
running&quot;.&nbsp; The drafts published by Hughes were published after
the CAS packages were submitted to the ITU.<br>
</font><br>
<font size=2>Given that the working group is in the process of winding
down, I do not see any benefit to anyone in continuing to allow the IETF
to hold up standardization when the ITU is prepared to consider and
advance the work.<br>
</font><br>
<font size=2>Kevin</font> <br><br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Michael DiGioia
[<a href="mailto:michaeldigioia@hotmail.com">mailto:michaeldigioia@hotmail.com</a>]
</font><br>
<font size=2>Sent: Tuesday, April 22, 2003 5:01 PM</font> <br>
<font size=2>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au;
megaco@ietf.org</font> <br>
<font size=2>Cc: bsteinka@telica.com</font> <br>
<font size=2>Subject: Re: [Megaco] Megaco CAS support</font> <br><br>
<br>
<font size=2>Christian,</font> <br><br>
<font size=2>I agree, CAS should be part of the IETF similar to the
original MEGACO draft </font><br>
<font size=2>work that held both organizations in sync.</font> <br><br>
<font size=2>/mpd</font> <br><br>
<br><br>
<font size=2>&gt;From: Aleksandr Ryabin
&lt;kengr@winphoria.com&gt;</font> <br>
<font size=2>&gt;To: Christian Groves
&lt;Christian.Groves@ericsson.com.au&gt;, </font><br>
<font size=2>&gt;megaco@ietf.org</font> <br>
<font size=2>&gt;CC: Brad Steinka &lt;bsteinka@telica.com&gt;</font>
<br>
<font size=2>&gt;Subject: Re: [Megaco] Megaco CAS support</font> <br>
<font size=2>&gt;Date: Tue, 22 Apr 2003 10:30:01 -0400</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Hi Christian,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Then why are these brand new revisions of drafts were just recently</font> <br>
<font size=2>&gt;submitted?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt</a></font> <br>
<font size=2>&gt;<a href="http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt" eudora="autourl">http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt</a></font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;More over a quick look through reveals that some of the package items </font><br>
<font size=2>&gt;in</font> <br>
<font size=2>&gt;icas</font> <br>
<font size=2>&gt;(ITU) the same as in r2 (IETF) up to the extent of exactly the same </font><br>
<font size=2>&gt;wording.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Same AVD-2316 ITU doc mentions &quot;CAS Blocking&quot; package in summary which </font><br>
<font size=2>&gt;does not seem to be defined in the document and also &quot;conflicts&quot; with </font><br>
<font size=2>&gt;above IETF &quot;CAS Maintenance Package&quot;.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;There is also reference to r2 package in AVD-2316 nowhere found in ITU.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Also basic CAS packages draft still available at: </font><br>
<font size=2>&gt;<a href="http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0">http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0</a></font> <br>
<font size=2>&gt;2.txt</font> <br>
<font size=2>&gt;but it is slightly different (outdated?) from AVD-2315 ITU version you have </font><br>
<font size=2>&gt;specified.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;The recent submission of the above drafts had lead me to believe that </font><br>
<font size=2>&gt;CAS work is still quite &quot;up and running&quot; in IETF. This is all very </font><br>
<font size=2>&gt;confusing. When was it decided to move the work to ITU? Could someone </font><br>
<font size=2>&gt;point me out to some references (in IETF) of that please?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;My two cents on this topic: CAS is not an isolated package and in my</font> <br>
<font size=2>&gt;opinion</font> <br>
<font size=2>&gt;it would be much more productive to keep it on both channels (ITU and IETF)</font> <br>
<font size=2>&gt;and in sync, similar to some other items done so far in H.248/MEGACO.</font> <br>
<font size=2>&gt;What other folks think about it?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Also in any case can the authors of ITU and IETF CAS related packages </font><br>
<font size=2>&gt;work together to come up with some kind of game plan and post it to the </font><br>
<font size=2>&gt;list to avoid any further confusion and inconsistencies?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Thanks!</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;At 07:54 PM 4/21/2003, Christian Groves wrote:</font> <br>
<font size=2>&gt;&gt;G'Day Brad and Karl,</font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;I believe the intention is to move the CAS work into the ITU. The</font> <br>
<font size=2>&gt;&gt;contributions</font> <br>
<font size=2>&gt;&gt;containing the latest drafts can be found at:</font> <br>
<font size=2>&gt;&gt;<a href="ftp://standard.pictel.com/avc-site/0302_San/">ftp://standard.pictel.com/avc-site/0302_San/</a></font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;AVD-2312&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MF Tone Generation and Detection Packages</font> <br>
<font size=2>&gt;&gt;AVD-2315&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Basic CAS Packages</font> <br>
<font size=2>&gt;&gt;AVD-2316&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; International CAS Packages</font> <br>
<font size=2>&gt;&gt;AVD-2317&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Enhanced Analog Line Packages</font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;Regards, Christian</font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;Brad Steinka wrote:</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; There were several RFC draft document that described various </font><br>
<font size=2>&gt;&gt; &gt; packages</font> <br>
<font size=2>&gt;&gt;to</font> <br>
<font size=2>&gt;&gt; &gt; support CAS, R1, R2, BCAS, etc.</font> <br>
<font size=2>&gt;&gt; &gt; Most of these drafts have expired.</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; Can anyone tell me what the latest RFCs are that support CAS calls </font><br>
<font size=2>&gt;&gt; &gt; and</font> <br>
<font size=2>&gt;&gt;where</font> <br>
<font size=2>&gt;&gt; &gt; they are in the standards process?</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; Thanks</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; Brad Steinka</font> <br>
<font size=2>&gt;&gt; &gt; Director - Software Engineering</font> <br>
<font size=2>&gt;&gt; &gt; 734 Forest Street, Building G, Suite 100</font> <br>
<font size=2>&gt;&gt; &gt; Marlboro, Ma.&nbsp;&nbsp; 01752</font> <br>
<font size=2>&gt;&gt; &gt; Tel:&nbsp; 508-480-0909&nbsp; x154</font> <br>
<font size=2>&gt;&gt; &gt; Email: bsteinka@telica.com &lt;<a href="mailto:bsteinka@telica.com">mailto:bsteinka@telica.com</a>&gt;</font> <br>
<font size=2>&gt;&gt; &gt; Web:&nbsp;&nbsp; <a href="http://www.telica.com/" eudora="autourl">www.telica.com</a> &lt;<a href="http://www.telica.com">http://www.telica.com</a>&gt;</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; _______________________________________________</font> <br>
<font size=2>&gt;&gt; &gt; Megaco mailing list</font> <br>
<font size=2>&gt;&gt; &gt; Megaco@ietf.org <a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> <br>
<font size=2>&gt;&gt;_______________________________________________</font> <br>
<font size=2>&gt;&gt;Megaco mailing list</font> <br>
<font size=2>&gt;&gt;Megaco@ietf.org</font> <br>
<font size=2>&gt;&gt;<a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;_______________________________________________</font> <br>
<font size=2>&gt;Megaco mailing list</font> <br>
<font size=2>&gt;Megaco@ietf.org</font> <br>
<font size=2>&gt;<a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> <br><br>
<font size=2>_________________________________________________________________</font> <br>
<font size=2>MSN 8 with e-mail virus protection service: 2 months FREE*&nbsp; </font><br>
<font size=2><a href="http://join.msn.com/?page=features/virus">http://join.msn.com/?page=features/virus</a></font> <br><br>
<font size=2>_______________________________________________</font> <br>
<font size=2>Megaco mailing list</font> <br>
<font size=2>Megaco@ietf.org</font> <br>
<font size=2><a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> </blockquote></body>
</html>

--=====================_89129541==.ALT--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 19:35:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01444
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 19:35:33 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MNlJc21335
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 19:47:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNlI821332
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 19:47:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01441
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 19:35:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1987KF-0006KR-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 19:37:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1987KE-0006KO-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 19:37:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNiW821241;
	Tue, 22 Apr 2003 19:44:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNc4821044
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 19:38:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01324
	for <megaco@ietf.org>; Tue, 22 Apr 2003 19:25:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1987BI-0006Iu-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:28:08 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1987BI-0006In-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:28:08 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 22 Apr 2003 19:27:58 -0400
Message-Id: <5.2.0.9.0.20030422173419.02a99fc0@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Apr 2003 19:04:50 -0400
To: megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: RE: [Megaco] Megaco CAS support
Cc: Michael DiGioia <michaeldigioia@hotmail.com>,
        Christian.Groves@ericsson.com.au, bsteinka@telica.com
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C08E02CF5@zrtpd0jq.us.norte
 l.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_89129541==.ALT"
X-OriginalArrivalTime: 22 Apr 2003 23:27:58.0576 (UTC) FILETIME=[CF2D3700:01C30926]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_89129541==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I see the reason to push it through ITU, but we definitely would not want to
see two, or more different packages doing the same thing published one through
IETF and another trough ITU. Thus, since MEGACO is (also) published as
IETF standard we should at least make every effort to avoid duplication of 
work.

Unfortunately not all of us have direct access (at least direct say) in ITU 
and
thus at least keeping IETF community informed on progress of MEGACO/H.248
related work would be very useful, as well as using this list for various 
discussions.
In fact AVD-2345 contains the following statement regarding H.248.mf packages:
"It was suggested that we send a liaison to the IESG and MEGACO proposing
this move and asking if this presents a problem to either of them.  Mr Boyle
will draft a liaison for our consideration.  If we do not receive an 
objection from
them we will progress these with a goal of consent in May.  The liaison 
appears
as TD-20a." Should then the r2 package also be included in same liaison?

As far as I remember "CAS packages published by Hughes" are new revisions
of the drafts that were published a long time ago (at least for r2). This 
very fact
that new revisions were published despite the CAS work moved to ITU indicates
the lack of communication.

Can I suggest to put some wording on WG charter home page regarding
each work "moved" to ITU (links to liaisons?) and maybe at least some kind
of sense of ITU schedule for that work? I know there is wording already about
IETF position related to packages, but still info would be very useful.
At least a pointer to latest up to date "packages guide" (AVD-2294) might be
sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph from
AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)

In any case could you please outline an ITU schedule for CAS related packages?
What is the verdict for CAS drafts published in IETF? Are they going to be 
folded
into ITU work? I guess at least some of them (by Nortel) are? What about 
others?
Is r2 package planned to be dropped/replaced with icas?
Are there any additional ITU CAS related packages/documents not listed
in original Christian's email?
Are there any other CAS packages planned?

Thanks
         Aleks

At 05:26 PM 4/22/2003, Kevin Boyle wrote:

>With all due respect, the IETF had its chance to progress these (and many 
>other) packages.  In the interests of the larger community, I have taken 
>the packages to the ITU for standardization, since the IETF does not seem 
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by 
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do not 
>see any benefit to anyone in continuing to allow the IETF to hold up 
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia 
>[<mailto:michaeldigioia@hotmail.com>mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO draft
>work that held both organizations in sync.
>
>/mpd
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> ><http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt>h 
> ttp://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> ><http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0> 
> http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >><ftp://standard.pictel.com/avc-site/0302_San/>ftp://standard.pictel.com/ 
> avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com 
> <<mailto:bsteinka@telica.com>mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <<http://www.telica.com>http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org 
> <https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mai 
> lman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> ><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mail 
> man/listinfo/megaco
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
><http://join.msn.com/?page=features/virus>http://join.msn.com/?page=features/virus 
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
><https://www1.ietf.org/mailman/listinfo/megaco>https://www1.ietf.org/mailman/listinfo/megaco 
>

--=====================_89129541==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
I see the reason to push it through ITU, but we definitely would not want
to<br>
see two, or more different packages doing the same thing published one
through <br>
IETF and another trough ITU. Thus, since MEGACO is (also) published as
<br>
IETF standard we should at least make every effort to avoid duplication
of work.<br><br>
Unfortunately not all of us have direct access (at least direct say) in
ITU and <br>
thus at least keeping IETF community informed on progress of MEGACO/H.248
<br>
related work would be very useful, as well as using this list for various
discussions.<br>
In fact AVD-2345 contains the following statement regarding H.248.mf
packages:<br>
&quot;It was suggested that we send a liaison to the IESG and MEGACO
proposing <br>
this move and asking if this presents a problem to either of them.&nbsp;
Mr Boyle <br>
will draft a liaison for our consideration.&nbsp; If we do not receive an
objection from <br>
them we will progress these with a goal of consent in May.&nbsp; The
liaison appears <br>
as TD-20a.&quot; Should then the r2 package also be included in same
liaison?<br><br>
As far as I remember &quot;CAS packages published by Hughes&quot; are new
revisions<br>
of the drafts that were published a long time ago (at least for r2). This
very fact <br>
that new revisions were published despite the CAS work moved to ITU
indicates <br>
the lack of communication.<br><br>
Can I suggest to put some wording on WG charter home page regarding<br>
each work &quot;moved&quot; to ITU (links to liaisons?) and maybe at
least some kind <br>
of sense of ITU schedule for that work? I know there is wording already
about <br>
IETF position related to packages, but still info would be very
useful.<br>
At least a pointer to latest up to date &quot;packages guide&quot;
(AVD-2294) might be <br>
sufficient and H.248 related parts from 3.1.6 &quot;Document Status&quot;
paragraph from <br>
AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of
ITU)<br><br>
In any case could you please outline an ITU schedule for CAS related
packages?<br>
What is the verdict for CAS drafts published in IETF? Are they going to
be folded <br>
into ITU work? I guess at least some of them (by Nortel) are? What about
others?<br>
Is r2 package planned to be dropped/replaced with icas?<br>
Are there any additional ITU CAS related packages/documents not
listed<br>
in original <font size=2>Christian</font>'s email? <br>
Are there any other CAS packages planned?<br><br>
Thanks<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 05:26 PM 4/22/2003, Kevin Boyle wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>With all due respect,
the IETF had its chance to progress these (and many other)
packages.&nbsp; In the interests of the larger community, I have taken
the packages to the ITU for standardization, since the IETF does not seem
interested in standardizing any packages.<br>
</font><br>
<font size=2>The work in the IETF is not &quot;up and
running&quot;.&nbsp; The drafts published by Hughes were published after
the CAS packages were submitted to the ITU.<br>
</font><br>
<font size=2>Given that the working group is in the process of winding
down, I do not see any benefit to anyone in continuing to allow the IETF
to hold up standardization when the ITU is prepared to consider and
advance the work.<br>
</font><br>
<font size=2>Kevin</font> <br><br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Michael DiGioia
[<a href="mailto:michaeldigioia@hotmail.com">mailto:michaeldigioia@hotmail.com</a>]
</font><br>
<font size=2>Sent: Tuesday, April 22, 2003 5:01 PM</font> <br>
<font size=2>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au;
megaco@ietf.org</font> <br>
<font size=2>Cc: bsteinka@telica.com</font> <br>
<font size=2>Subject: Re: [Megaco] Megaco CAS support</font> <br><br>
<br>
<font size=2>Christian,</font> <br><br>
<font size=2>I agree, CAS should be part of the IETF similar to the
original MEGACO draft </font><br>
<font size=2>work that held both organizations in sync.</font> <br><br>
<font size=2>/mpd</font> <br><br>
<br><br>
<font size=2>&gt;From: Aleksandr Ryabin
&lt;kengr@winphoria.com&gt;</font> <br>
<font size=2>&gt;To: Christian Groves
&lt;Christian.Groves@ericsson.com.au&gt;, </font><br>
<font size=2>&gt;megaco@ietf.org</font> <br>
<font size=2>&gt;CC: Brad Steinka &lt;bsteinka@telica.com&gt;</font>
<br>
<font size=2>&gt;Subject: Re: [Megaco] Megaco CAS support</font> <br>
<font size=2>&gt;Date: Tue, 22 Apr 2003 10:30:01 -0400</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Hi Christian,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Then why are these brand new revisions of drafts were just recently</font> <br>
<font size=2>&gt;submitted?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;<a href="http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt</a></font> <br>
<font size=2>&gt;<a href="http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt" eudora="autourl">http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt</a></font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;More over a quick look through reveals that some of the package items </font><br>
<font size=2>&gt;in</font> <br>
<font size=2>&gt;icas</font> <br>
<font size=2>&gt;(ITU) the same as in r2 (IETF) up to the extent of exactly the same </font><br>
<font size=2>&gt;wording.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Same AVD-2316 ITU doc mentions &quot;CAS Blocking&quot; package in summary which </font><br>
<font size=2>&gt;does not seem to be defined in the document and also &quot;conflicts&quot; with </font><br>
<font size=2>&gt;above IETF &quot;CAS Maintenance Package&quot;.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;There is also reference to r2 package in AVD-2316 nowhere found in ITU.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Also basic CAS packages draft still available at: </font><br>
<font size=2>&gt;<a href="http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0">http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0</a></font> <br>
<font size=2>&gt;2.txt</font> <br>
<font size=2>&gt;but it is slightly different (outdated?) from AVD-2315 ITU version you have </font><br>
<font size=2>&gt;specified.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;The recent submission of the above drafts had lead me to believe that </font><br>
<font size=2>&gt;CAS work is still quite &quot;up and running&quot; in IETF. This is all very </font><br>
<font size=2>&gt;confusing. When was it decided to move the work to ITU? Could someone </font><br>
<font size=2>&gt;point me out to some references (in IETF) of that please?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;My two cents on this topic: CAS is not an isolated package and in my</font> <br>
<font size=2>&gt;opinion</font> <br>
<font size=2>&gt;it would be much more productive to keep it on both channels (ITU and IETF)</font> <br>
<font size=2>&gt;and in sync, similar to some other items done so far in H.248/MEGACO.</font> <br>
<font size=2>&gt;What other folks think about it?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Also in any case can the authors of ITU and IETF CAS related packages </font><br>
<font size=2>&gt;work together to come up with some kind of game plan and post it to the </font><br>
<font size=2>&gt;list to avoid any further confusion and inconsistencies?</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;Thanks!</font> <br>
<font size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Aleks</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;At 07:54 PM 4/21/2003, Christian Groves wrote:</font> <br>
<font size=2>&gt;&gt;G'Day Brad and Karl,</font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;I believe the intention is to move the CAS work into the ITU. The</font> <br>
<font size=2>&gt;&gt;contributions</font> <br>
<font size=2>&gt;&gt;containing the latest drafts can be found at:</font> <br>
<font size=2>&gt;&gt;<a href="ftp://standard.pictel.com/avc-site/0302_San/">ftp://standard.pictel.com/avc-site/0302_San/</a></font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;AVD-2312&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MF Tone Generation and Detection Packages</font> <br>
<font size=2>&gt;&gt;AVD-2315&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Basic CAS Packages</font> <br>
<font size=2>&gt;&gt;AVD-2316&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; International CAS Packages</font> <br>
<font size=2>&gt;&gt;AVD-2317&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Enhanced Analog Line Packages</font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;Regards, Christian</font> <br>
<font size=2>&gt;&gt;</font> <br>
<font size=2>&gt;&gt;Brad Steinka wrote:</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; There were several RFC draft document that described various </font><br>
<font size=2>&gt;&gt; &gt; packages</font> <br>
<font size=2>&gt;&gt;to</font> <br>
<font size=2>&gt;&gt; &gt; support CAS, R1, R2, BCAS, etc.</font> <br>
<font size=2>&gt;&gt; &gt; Most of these drafts have expired.</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; Can anyone tell me what the latest RFCs are that support CAS calls </font><br>
<font size=2>&gt;&gt; &gt; and</font> <br>
<font size=2>&gt;&gt;where</font> <br>
<font size=2>&gt;&gt; &gt; they are in the standards process?</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; Thanks</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; Brad Steinka</font> <br>
<font size=2>&gt;&gt; &gt; Director - Software Engineering</font> <br>
<font size=2>&gt;&gt; &gt; 734 Forest Street, Building G, Suite 100</font> <br>
<font size=2>&gt;&gt; &gt; Marlboro, Ma.&nbsp;&nbsp; 01752</font> <br>
<font size=2>&gt;&gt; &gt; Tel:&nbsp; 508-480-0909&nbsp; x154</font> <br>
<font size=2>&gt;&gt; &gt; Email: bsteinka@telica.com &lt;<a href="mailto:bsteinka@telica.com">mailto:bsteinka@telica.com</a>&gt;</font> <br>
<font size=2>&gt;&gt; &gt; Web:&nbsp;&nbsp; <a href="http://www.telica.com/" eudora="autourl">www.telica.com</a> &lt;<a href="http://www.telica.com">http://www.telica.com</a>&gt;</font> <br>
<font size=2>&gt;&gt; &gt;</font> <br>
<font size=2>&gt;&gt; &gt; _______________________________________________</font> <br>
<font size=2>&gt;&gt; &gt; Megaco mailing list</font> <br>
<font size=2>&gt;&gt; &gt; Megaco@ietf.org <a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> <br>
<font size=2>&gt;&gt;_______________________________________________</font> <br>
<font size=2>&gt;&gt;Megaco mailing list</font> <br>
<font size=2>&gt;&gt;Megaco@ietf.org</font> <br>
<font size=2>&gt;&gt;<a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;_______________________________________________</font> <br>
<font size=2>&gt;Megaco mailing list</font> <br>
<font size=2>&gt;Megaco@ietf.org</font> <br>
<font size=2>&gt;<a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> <br><br>
<font size=2>_________________________________________________________________</font> <br>
<font size=2>MSN 8 with e-mail virus protection service: 2 months FREE*&nbsp; </font><br>
<font size=2><a href="http://join.msn.com/?page=features/virus">http://join.msn.com/?page=features/virus</a></font> <br><br>
<font size=2>_______________________________________________</font> <br>
<font size=2>Megaco mailing list</font> <br>
<font size=2>Megaco@ietf.org</font> <br>
<font size=2><a href="https://www1.ietf.org/mailman/listinfo/megaco">https://www1.ietf.org/mailman/listinfo/megaco</a></font> </blockquote></body>
</html>

--=====================_89129541==.ALT--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 19:39:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01479
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 19:39:32 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNnW821397;
	Tue, 22 Apr 2003 19:49:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNia821251
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 19:44:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01408
	for <megaco@ietf.org>; Tue, 22 Apr 2003 19:32:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1987Hc-0006KE-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:34:40 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1987Hc-0006KB-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:34:40 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 22 Apr 2003 19:34:29 -0400
Message-Id: <5.2.0.9.0.20030422192514.02afddc0@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Apr 2003 19:31:19 -0400
To: Manuel Poza <manuel.poza@alcatel.es>, hektor@etri.re.kr, megaco@ietf.org
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: Re: [Megaco] [Question] About unrequested event notification
In-Reply-To: <3EA557A8.C4FFA7F8@alcatel.es>
References: <8470181DABD5D511B3E700D0B7A8AC4A5DA532@cms3>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_89507845==.ALT"
X-OriginalArrivalTime: 22 Apr 2003 23:34:29.0932 (UTC) FILETIME=[B87166C0:01C30927]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_89507845==.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

Exactly this question is answered in the latest IG draft which adds error=
 458
"Unexpected Event/RequestID". "Definition: The command was disregarded
because a notification for an Event / Request ID that the MGC did not=
 request
was received"

ftp://standard.pictel.com/avc-site/0302_San/AVD-2292.zip
ftp://standard.pictel.com/avc-site/0302_San/TD-29.zip

Cheers.
         Aleks

At 10:54 AM 4/22/2003, Manuel Poza wrote:
>Hi, Hektor,
>
>I think the MGC should reply with an error, possibly, error #401 (Protocol=
=20
>error).
>
>Regards,
>Manuel
>
>hektor@etri.re.kr escribi=F3:
>>
>>
>>G'day.
>>
>>If a MG send a event notification which is not requested by a MGC,
>>What shall the MGC do?
>>
>>TIA.

--=====================_89507845==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<body>
Hi,<br><br>
Exactly this question is answered in the latest IG draft which adds error
458 <br>
&quot;Unexpected Event/RequestID&quot;. &quot;Definition: The command was
disregarded <br>
because a notification for an Event / Request ID that the MGC did not
request <br>
was received&quot;<br><br>
<a href=3D"ftp://standard.pictel.com/avc-site/0302_San/AVD-2292.zip"=
 eudora=3D"autourl">ftp://standard.pictel.com/avc-site/0302_San/AVD-2292.zip=
</a><br>
<a href=3D"ftp://standard.pictel.com/avc-site/0302_San/TD-29.zip"=
 eudora=3D"autourl">ftp://standard.pictel.com/avc-site/0302_San/TD-29.zip<br=
><br>
</a>Cheers.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 10:54 AM 4/22/2003, Manuel Poza wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>Hi, Hektor, <br><br>
I think the MGC should reply with an error, possibly, error #401
(Protocol error). <br><br>
Regards, <br>
Manuel <br><br>
hektor@etri.re.kr escribi=F3: <br>
<blockquote type=3Dcite class=3Dcite cite>&nbsp; <br><br>
<font size=3D2>G'day.</font> <br><br>
<font size=3D2>If a MG send a event notification which is not requested by
a MGC,</font> <br>
<font size=3D2>What shall the MGC do?</font> <br><br>
<font size=3D2>TIA.</font></blockquote></blockquote></body>
</html>

--=====================_89507845==.ALT--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 19:40:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01499
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 19:40:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3MNqNG21482
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 19:52:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNqN821479
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 19:52:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01496
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 19:40:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1987P9-0006Kv-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 19:42:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1987P9-0006Ks-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 19:42:27 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNnW821397;
	Tue, 22 Apr 2003 19:49:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MNia821251
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 19:44:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01408
	for <megaco@ietf.org>; Tue, 22 Apr 2003 19:32:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1987Hc-0006KE-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:34:40 -0400
Received: from gw-1.winphoria.com ([12.105.64.190] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1987Hc-0006KB-00
	for megaco@ietf.org; Tue, 22 Apr 2003 19:34:40 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 22 Apr 2003 19:34:29 -0400
Message-Id: <5.2.0.9.0.20030422192514.02afddc0@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 22 Apr 2003 19:31:19 -0400
To: Manuel Poza <manuel.poza@alcatel.es>, hektor@etri.re.kr, megaco@ietf.org
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: Re: [Megaco] [Question] About unrequested event notification
In-Reply-To: <3EA557A8.C4FFA7F8@alcatel.es>
References: <8470181DABD5D511B3E700D0B7A8AC4A5DA532@cms3>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_89507845==.ALT"
X-OriginalArrivalTime: 22 Apr 2003 23:34:29.0932 (UTC) FILETIME=[B87166C0:01C30927]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--=====================_89507845==.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

Exactly this question is answered in the latest IG draft which adds error=
 458
"Unexpected Event/RequestID". "Definition: The command was disregarded
because a notification for an Event / Request ID that the MGC did not=
 request
was received"

ftp://standard.pictel.com/avc-site/0302_San/AVD-2292.zip
ftp://standard.pictel.com/avc-site/0302_San/TD-29.zip

Cheers.
         Aleks

At 10:54 AM 4/22/2003, Manuel Poza wrote:
>Hi, Hektor,
>
>I think the MGC should reply with an error, possibly, error #401 (Protocol=
=20
>error).
>
>Regards,
>Manuel
>
>hektor@etri.re.kr escribi=F3:
>>
>>
>>G'day.
>>
>>If a MG send a event notification which is not requested by a MGC,
>>What shall the MGC do?
>>
>>TIA.

--=====================_89507845==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<body>
Hi,<br><br>
Exactly this question is answered in the latest IG draft which adds error
458 <br>
&quot;Unexpected Event/RequestID&quot;. &quot;Definition: The command was
disregarded <br>
because a notification for an Event / Request ID that the MGC did not
request <br>
was received&quot;<br><br>
<a href=3D"ftp://standard.pictel.com/avc-site/0302_San/AVD-2292.zip"=
 eudora=3D"autourl">ftp://standard.pictel.com/avc-site/0302_San/AVD-2292.zip=
</a><br>
<a href=3D"ftp://standard.pictel.com/avc-site/0302_San/TD-29.zip"=
 eudora=3D"autourl">ftp://standard.pictel.com/avc-site/0302_San/TD-29.zip<br=
><br>
</a>Cheers.<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Aleks<br><br>
At 10:54 AM 4/22/2003, Manuel Poza wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>Hi, Hektor, <br><br>
I think the MGC should reply with an error, possibly, error #401
(Protocol error). <br><br>
Regards, <br>
Manuel <br><br>
hektor@etri.re.kr escribi=F3: <br>
<blockquote type=3Dcite class=3Dcite cite>&nbsp; <br><br>
<font size=3D2>G'day.</font> <br><br>
<font size=3D2>If a MG send a event notification which is not requested by
a MGC,</font> <br>
<font size=3D2>What shall the MGC do?</font> <br><br>
<font size=3D2>TIA.</font></blockquote></blockquote></body>
</html>

--=====================_89507845==.ALT--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 22 20:40:27 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02631
	for <megaco-archive@lists.ietf.org>; Tue, 22 Apr 2003 20:40:27 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N0pe825271;
	Tue, 22 Apr 2003 20:51:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N0lD825100
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 20:47:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02569
	for <megaco@ietf.org>; Tue, 22 Apr 2003 20:34:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1988GC-0006cf-00
	for megaco@ietf.org; Tue, 22 Apr 2003 20:37:16 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1988GA-0006cc-00
	for megaco@ietf.org; Tue, 22 Apr 2003 20:37:14 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3N0Z4403869;
	Wed, 23 Apr 2003 10:35:05 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3N0bO027929;
	Wed, 23 Apr 2003 10:37:24 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8NVCWX; Wed, 23 Apr 2003 10:37:23 +1000
Message-ID: <3EA5E042.582446F3@ericsson.com.au>
Date: Wed, 23 Apr 2003 10:37:22 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael DiGioia <michaeldigioia@hotmail.com>
CC: kengr@winphoria.com, megaco@ietf.org, bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support
References: <Law14-F72G5bTHuICqc0000d8c3@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello Michael and Aleksandr,

Don't shoot the messenger. I'm simply providing you with the information. I did
not decide to take the work to the ITU it was the authors of the IETF drafts.

Regards, Christian

Michael DiGioia wrote:
> 
> Christian,
> 
> I agree, CAS should be part of the IETF similar to the original MEGACO draft
> work that held both organizations in sync.
> 
> /mpd
> 
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>, megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with above
> >IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that CAS
> >work is still quite "up and running" in IETF. This is all very confusing.
> >When was it decided to move the work to ITU? Could someone point me out
> >to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages work
> >together to come up with some kind of game plan and post it to the list to
> >avoid
> >any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> 
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 22 20:41:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02681
	for <megaco-archive@odin.ietf.org>; Tue, 22 Apr 2003 20:41:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N0rNp25317
	for megaco-archive@odin.ietf.org; Tue, 22 Apr 2003 20:53:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N0rN825314
	for <megaco-web-archive@optimus.ietf.org>; Tue, 22 Apr 2003 20:53:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02662
	for <megaco-web-archive@ietf.org>; Tue, 22 Apr 2003 20:41:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1988MA-0006de-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 20:43:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1988MA-0006db-00
	for megaco-web-archive@ietf.org; Tue, 22 Apr 2003 20:43:26 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N0pe825271;
	Tue, 22 Apr 2003 20:51:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N0lD825100
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 20:47:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02569
	for <megaco@ietf.org>; Tue, 22 Apr 2003 20:34:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1988GC-0006cf-00
	for megaco@ietf.org; Tue, 22 Apr 2003 20:37:16 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 1988GA-0006cc-00
	for megaco@ietf.org; Tue, 22 Apr 2003 20:37:14 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3N0Z4403869;
	Wed, 23 Apr 2003 10:35:05 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3N0bO027929;
	Wed, 23 Apr 2003 10:37:24 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8NVCWX; Wed, 23 Apr 2003 10:37:23 +1000
Message-ID: <3EA5E042.582446F3@ericsson.com.au>
Date: Wed, 23 Apr 2003 10:37:22 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael DiGioia <michaeldigioia@hotmail.com>
CC: kengr@winphoria.com, megaco@ietf.org, bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support
References: <Law14-F72G5bTHuICqc0000d8c3@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello Michael and Aleksandr,

Don't shoot the messenger. I'm simply providing you with the information. I did
not decide to take the work to the ITU it was the authors of the IETF drafts.

Regards, Christian

Michael DiGioia wrote:
> 
> Christian,
> 
> I agree, CAS should be part of the IETF similar to the original MEGACO draft
> work that held both organizations in sync.
> 
> /mpd
> 
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>, megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with above
> >IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-02.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that CAS
> >work is still quite "up and running" in IETF. This is all very confusing.
> >When was it decided to move the work to ITU? Could someone point me out
> >to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages work
> >together to come up with some kind of game plan and post it to the list to
> >avoid
> >any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> 
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 00:12:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06609
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 00:12:34 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4Nc806810;
	Wed, 23 Apr 2003 00:23:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4KV806746
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 00:20:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06553
	for <megaco@ietf.org>; Wed, 23 Apr 2003 00:08:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198BaY-0007YV-00
	for megaco@ietf.org; Wed, 23 Apr 2003 00:10:30 -0400
Received: from wiprom2mx1.wipro.com ([203.197.164.41])
	by ietf-mx with esmtp (Exim 4.12)
	id 198BaR-0007YN-00
	for megaco@ietf.org; Wed, 23 Apr 2003 00:10:24 -0400
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h3N4AFN02820
	for <megaco@ietf.org>; Wed, 23 Apr 2003 09:40:15 +0530 (IST)
Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 23 Apr 2003 09:39:51 +0530
Received: from RANJITHEC ([192.168.178.175]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 23 Apr 2003 09:39:51 +0530
Reply-To: <ranjith.mukundan@wipro.com>
From: "Ranjith Mukundan" <ranjith.mukundan@wipro.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com.au>,
        "'Michael DiGioia'" <michaeldigioia@hotmail.com>
Cc: <kengr@winphoria.com>, <megaco@ietf.org>, <bsteinka@telica.com>
Subject: RE: [Megaco] Megaco CAS support
Date: Wed, 23 Apr 2003 09:38:53 +0530
Organization: Wipro Technologies
Message-ID: <000e01c3094e$0d9e40c0$afb2a8c0@RANJITHEC>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <3EA5E042.582446F3@ericsson.com.au>
Importance: Normal
X-OriginalArrivalTime: 23 Apr 2003 04:09:51.0818 (UTC) FILETIME=[304122A0:01C3094E]
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

progressing some packages on ITU and moving it out from IETF is fine.
But, leaving behind traces of the 'moved work' (or a subset there of) in
any of the WG IDs, esp, without precise citation of the existence of the
duplicate equivalent elsewhere (like the ITU) only adds to the confusion
(compounded by the lack of 'easy' access to ITU plans/charter on the
H.248 packages front).

- ranjith..

>-----Original Message-----
>From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
>Behalf Of Christian Groves
>Sent: Wednesday, April 23, 2003 6:07 AM
>To: Michael DiGioia
>Cc: kengr@winphoria.com; megaco@ietf.org; bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>Hello Michael and Aleksandr,
>
>Don't shoot the messenger. I'm simply providing you with the 
>information. I did not decide to take the work to the ITU it 
>was the authors of the IETF drafts.
>
>Regards, Christian
>
>Michael DiGioia wrote:
>> 
>> Christian,
>> 
>> I agree, CAS should be part of the IETF similar to the 
>original MEGACO 
>> draft work that held both organizations in sync.
>> 
>> /mpd
>> 
>> >From: Aleksandr Ryabin <kengr@winphoria.com>
>> >To: Christian Groves <Christian.Groves@ericsson.com.au>, 
>> >megaco@ietf.org
>> >CC: Brad Steinka <bsteinka@telica.com>
>> >Subject: Re: [Megaco] Megaco CAS support
>> >Date: Tue, 22 Apr 2003 10:30:01 -0400
>> >
>> >Hi Christian,
>> >
>> >Then why are these brand new revisions of drafts were just recently 
>> >submitted?
>> >
>> 
>>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.tx
>> >t
>> 
>>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>> >
>> >More over a quick look through reveals that some of the 
>package items 
>> >in icas
>> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same 
>> >wording.
>> >
>> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary 
>> >which does not seem to be defined in the document and also 
>> >"conflicts" with above IETF "CAS Maintenance Package".
>> >
>> >There is also reference to r2 package in AVD-2316 nowhere found in 
>> >ITU.
>> >
>> >Also basic CAS packages draft still available at: 
>> 
>>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage
>> >-02.txt
>> >but it is slightly different (outdated?) from AVD-2315 ITU 
>version you have
>> >specified.
>> >
>> >The recent submission of the above drafts had lead me to 
>believe that 
>> >CAS work is still quite "up and running" in IETF. This is all very 
>> >confusing. When was it decided to move the work to ITU? 
>Could someone 
>> >point me out to some references (in IETF) of that please?
>> >
>> >My two cents on this topic: CAS is not an isolated package 
>and in my 
>> >opinion it would be much more productive to keep it on both 
>channels 
>> >(ITU and IETF) and in sync, similar to some other items done so far 
>> >in H.248/MEGACO. What other folks think about it?
>> >
>> >Also in any case can the authors of ITU and IETF CAS 
>related packages 
>> >work together to come up with some kind of game plan and post it to 
>> >the list to avoid any further confusion and inconsistencies?
>> >
>> >Thanks!
>> >         Aleks
>> >
>> >At 07:54 PM 4/21/2003, Christian Groves wrote:
>> >>G'Day Brad and Karl,
>> >>
>> >>I believe the intention is to move the CAS work into the ITU. The 
>> >>contributions containing the latest drafts can be found at:
>> >>ftp://standard.pictel.com/avc-site/0302_San/
>> >>
>> >>AVD-2312        MF Tone Generation and Detection Packages
>> >>AVD-2315        Basic CAS Packages
>> >>AVD-2316        International CAS Packages
>> >>AVD-2317        Enhanced Analog Line Packages
>> >>
>> >>Regards, Christian
>> >>
>> >>Brad Steinka wrote:
>> >> >
>> >> > There were several RFC draft document that described various 
>> >> > packages
>> >>to
>> >> > support CAS, R1, R2, BCAS, etc.
>> >> > Most of these drafts have expired.
>> >> >
>> >> > Can anyone tell me what the latest RFCs are that support CAS 
>> >> > calls and
>> >>where
>> >> > they are in the standards process?
>> >> >
>> >> > Thanks
>> >> >
>> >> > Brad Steinka
>> >> > Director - Software Engineering
>> >> > 734 Forest Street, Building G, Suite 100
>> >> > Marlboro, Ma.   01752
>> >> > Tel:  508-480-0909  x154
>> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> >> > Web:   www.telica.com <http://www.telica.com>
>> >> >
>> >> > _______________________________________________
>> >> > Megaco mailing list
>> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>> >>_______________________________________________
>> >>Megaco mailing list
>> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>> >
>> >_______________________________________________
>> >Megaco mailing list
>> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>> 
>> _________________________________________________________________
>> MSN 8 with e-mail virus protection service: 2 months FREE* 
>> http://join.msn.com/?page=features/virus
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 00:13:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06634
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 00:13:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N4PZx06866
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 00:25:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4PZ806863
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 00:25:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06628
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 00:13:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198BfS-0007ZK-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 00:15:34 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198BfR-0007ZH-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 00:15:33 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4Nc806810;
	Wed, 23 Apr 2003 00:23:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4KV806746
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 00:20:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06553
	for <megaco@ietf.org>; Wed, 23 Apr 2003 00:08:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198BaY-0007YV-00
	for megaco@ietf.org; Wed, 23 Apr 2003 00:10:30 -0400
Received: from wiprom2mx1.wipro.com ([203.197.164.41])
	by ietf-mx with esmtp (Exim 4.12)
	id 198BaR-0007YN-00
	for megaco@ietf.org; Wed, 23 Apr 2003 00:10:24 -0400
Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h3N4AFN02820
	for <megaco@ietf.org>; Wed, 23 Apr 2003 09:40:15 +0530 (IST)
Received: from blr-ec-msg01.wipro.com ([10.200.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 23 Apr 2003 09:39:51 +0530
Received: from RANJITHEC ([192.168.178.175]) by blr-ec-msg01.wipro.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 23 Apr 2003 09:39:51 +0530
Reply-To: <ranjith.mukundan@wipro.com>
From: "Ranjith Mukundan" <ranjith.mukundan@wipro.com>
To: "'Christian Groves'" <Christian.Groves@ericsson.com.au>,
        "'Michael DiGioia'" <michaeldigioia@hotmail.com>
Cc: <kengr@winphoria.com>, <megaco@ietf.org>, <bsteinka@telica.com>
Subject: RE: [Megaco] Megaco CAS support
Date: Wed, 23 Apr 2003 09:38:53 +0530
Organization: Wipro Technologies
Message-ID: <000e01c3094e$0d9e40c0$afb2a8c0@RANJITHEC>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
In-Reply-To: <3EA5E042.582446F3@ericsson.com.au>
Importance: Normal
X-OriginalArrivalTime: 23 Apr 2003 04:09:51.0818 (UTC) FILETIME=[304122A0:01C3094E]
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

progressing some packages on ITU and moving it out from IETF is fine.
But, leaving behind traces of the 'moved work' (or a subset there of) in
any of the WG IDs, esp, without precise citation of the existence of the
duplicate equivalent elsewhere (like the ITU) only adds to the confusion
(compounded by the lack of 'easy' access to ITU plans/charter on the
H.248 packages front).

- ranjith..

>-----Original Message-----
>From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org] On 
>Behalf Of Christian Groves
>Sent: Wednesday, April 23, 2003 6:07 AM
>To: Michael DiGioia
>Cc: kengr@winphoria.com; megaco@ietf.org; bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>Hello Michael and Aleksandr,
>
>Don't shoot the messenger. I'm simply providing you with the 
>information. I did not decide to take the work to the ITU it 
>was the authors of the IETF drafts.
>
>Regards, Christian
>
>Michael DiGioia wrote:
>> 
>> Christian,
>> 
>> I agree, CAS should be part of the IETF similar to the 
>original MEGACO 
>> draft work that held both organizations in sync.
>> 
>> /mpd
>> 
>> >From: Aleksandr Ryabin <kengr@winphoria.com>
>> >To: Christian Groves <Christian.Groves@ericsson.com.au>, 
>> >megaco@ietf.org
>> >CC: Brad Steinka <bsteinka@telica.com>
>> >Subject: Re: [Megaco] Megaco CAS support
>> >Date: Tue, 22 Apr 2003 10:30:01 -0400
>> >
>> >Hi Christian,
>> >
>> >Then why are these brand new revisions of drafts were just recently 
>> >submitted?
>> >
>> 
>>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.tx
>> >t
>> 
>>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>> >
>> >More over a quick look through reveals that some of the 
>package items 
>> >in icas
>> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same 
>> >wording.
>> >
>> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary 
>> >which does not seem to be defined in the document and also 
>> >"conflicts" with above IETF "CAS Maintenance Package".
>> >
>> >There is also reference to r2 package in AVD-2316 nowhere found in 
>> >ITU.
>> >
>> >Also basic CAS packages draft still available at: 
>> 
>>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage
>> >-02.txt
>> >but it is slightly different (outdated?) from AVD-2315 ITU 
>version you have
>> >specified.
>> >
>> >The recent submission of the above drafts had lead me to 
>believe that 
>> >CAS work is still quite "up and running" in IETF. This is all very 
>> >confusing. When was it decided to move the work to ITU? 
>Could someone 
>> >point me out to some references (in IETF) of that please?
>> >
>> >My two cents on this topic: CAS is not an isolated package 
>and in my 
>> >opinion it would be much more productive to keep it on both 
>channels 
>> >(ITU and IETF) and in sync, similar to some other items done so far 
>> >in H.248/MEGACO. What other folks think about it?
>> >
>> >Also in any case can the authors of ITU and IETF CAS 
>related packages 
>> >work together to come up with some kind of game plan and post it to 
>> >the list to avoid any further confusion and inconsistencies?
>> >
>> >Thanks!
>> >         Aleks
>> >
>> >At 07:54 PM 4/21/2003, Christian Groves wrote:
>> >>G'Day Brad and Karl,
>> >>
>> >>I believe the intention is to move the CAS work into the ITU. The 
>> >>contributions containing the latest drafts can be found at:
>> >>ftp://standard.pictel.com/avc-site/0302_San/
>> >>
>> >>AVD-2312        MF Tone Generation and Detection Packages
>> >>AVD-2315        Basic CAS Packages
>> >>AVD-2316        International CAS Packages
>> >>AVD-2317        Enhanced Analog Line Packages
>> >>
>> >>Regards, Christian
>> >>
>> >>Brad Steinka wrote:
>> >> >
>> >> > There were several RFC draft document that described various 
>> >> > packages
>> >>to
>> >> > support CAS, R1, R2, BCAS, etc.
>> >> > Most of these drafts have expired.
>> >> >
>> >> > Can anyone tell me what the latest RFCs are that support CAS 
>> >> > calls and
>> >>where
>> >> > they are in the standards process?
>> >> >
>> >> > Thanks
>> >> >
>> >> > Brad Steinka
>> >> > Director - Software Engineering
>> >> > 734 Forest Street, Building G, Suite 100
>> >> > Marlboro, Ma.   01752
>> >> > Tel:  508-480-0909  x154
>> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> >> > Web:   www.telica.com <http://www.telica.com>
>> >> >
>> >> > _______________________________________________
>> >> > Megaco mailing list
>> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>> >>_______________________________________________
>> >>Megaco mailing list
>> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>> >
>> >_______________________________________________
>> >Megaco mailing list
>> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>> 
>> _________________________________________________________________
>> MSN 8 with e-mail virus protection service: 2 months FREE* 
>> http://join.msn.com/?page=features/virus
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 04:43:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07814
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 04:43:03 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N8rv804575;
	Wed, 23 Apr 2003 04:53:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N8os804472
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 04:50:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07739
	for <megaco@ietf.org>; Wed, 23 Apr 2003 04:38:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Fo7-0001L2-00
	for megaco@ietf.org; Wed, 23 Apr 2003 04:40:47 -0400
Received: from sess01.rdp.asi.alcatel.es ([159.23.144.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Fo6-0001Ks-00
	for megaco@ietf.org; Wed, 23 Apr 2003 04:40:46 -0400
Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1])
	by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h3N8eW709821;
	Wed, 23 Apr 2003 10:40:32 +0200 (MEST)
Received: from alcatel.es (sers5021 [159.23.115.21])
	by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id KAA20995;
	Wed, 23 Apr 2003 10:40:43 +0200 (MET DST)
Message-ID: <3EA6518B.862FDD51@alcatel.es>
Date: Wed, 23 Apr 2003 10:40:43 +0200
From: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>
Organization: ALCATEL
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com>
Content-Type: multipart/alternative;
 boundary="------------735605A5C6D9BB0528396C03"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------735605A5C6D9BB0528396C03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

Only some comments.

- You say : "So while talking on A1-A1, the MGC cannot for example audit
on A2-A2, because this is immediately considered a failover (...)". I
don't think this is true.
If an MG receives an Audit from MGC-A2 (which it does not know) it will
reject the transaction because there is no association established with
it.

- If the MG is multi-homed you can provision the two IP static addresses
as primary and secondary MGCs. In case one fails it will change to the
other IP which in fact is the
same MGC. Maybe there should be a deep explanation of how to do this to
smooth the process because the MG does not know whether the secondary is
an independent
MGC, a backup or a mirror and depending on this information it can
behave in one way or another (e.g. a ServiceChange Request only
Informational)

- Another thing the MGC can do when it detects the that A1 is going to
die is to send a Handoff to the interface A2 for each MG so that the
connections are restablished
in the new path.

Regards
Fernando

Adrian Soncodi wrote:

> Hello, all,
>
> I was wondering what is your oppinion on the following:
>
> Another topic that is not addressed in the MEGACO spec is the case of
> a multi-homed MG, i.e. an MG where:
> - the primary controller has 2 physical interfaces A1 and A2,
> potentially on 2 different subnets, working in load-sharing mode
> (rather than active-standby)
> - the secondary MG controller can then be either transparrent (it
> takes over A1 and A2 on switchover) or non-transparent (has 2 more
> physical addresses, B1 and B2).
>
> One may argue that multi-homing is not necessary, for example because
> you can always assign a single "logical" IP address A that is
> reachable over both interfaces A1 and A2. Yes, but this schema
> requires some dynamic IP routing capability in the backbone (e.g. to
> figure out when A1 is down and packets for A should be routed to A2),
> which has a number of disadvantages:
> - Depending on the routing protocol, the latency for dynamic updates
> of the addresses can be very large (180 seconds in case of RIP),
> unacceptable for telephony.
> - Depending on the network topology, interface failures may not become
> visible in the backbone. For example, if there is a LAN switch between
> the MG and the first router, then the router does not see when the
> interface A1 fails (unless the dynamic routing domain is extended to
> include the MG, which is not always the case).
> - Some service providers (especially the smaller ones) do not run a
> dynamic IP routing protocol in their (whole) backbone, or they may not
> even have a real backbone, for example they may use leased lines, IP
> over ATM/FR PVCs with no sophisticated routing capabilities.
>
> On the other hand, making the physical addresses A1 and A2 visible
> allows for redundant signaling paths to the MG using only static IP
> routing in the network, which in certain situations is desirable.
>
> The MGC-MG redundancy schema gets even more complicated if you
> consider that the MGC can be multi-homed too. Effectively, it can have
> the same A1, A2, B1, B2 schema as the MG. In this case, what is really
> useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because
> this takes care of all the combinations. But if the MG supports only
> UDP, it is not clear from the standard how to emulate this SCTP
> behavior. For example:
> - Some MGs do a DNS query for the MGC name, get 2 IP addresses in
> response, but they just ignore the second IP address, thus ignoring
> that the MGC is multi-homed.
> - Other MGs consider the IP addresses as being 2 different MGCs,
> rather than one multi-homed MG. The problem is that they only talk to
> one MGC at a time, and then they need a "handover" to switch. So while
> talking on A1-A1, the MGC cannot for example audit on A2-A2, because
> this is immediately considered a failover (causing for example the
> pending notifications to be lost). The MGCP spec, for example,
> explicitly states that an MG should not change its controlling entity
> when being audited from another IP address (and it doesn't say whether
> this is a different MGC or the same multi-homed MGC).
>
> I think what needs to be clarified here is:
> - Whether an MG/MGC can be multi-homed and how to handle its multiple
> IP addresses.
> - Whether an MG/MGC with active-standby controllers, transparent or
> non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
> - Whether a domain name for an MG/MGC which yields more than one IP
> address through DNS, is associated with one controller, or with an
> active-standby pair, or possibly even with more active-standby pairs.
>
> The case with non-transparent MG controller switchover, as Flemming
> mentioned, poses additional problems. For example, if the active MG
> controller loses connectivity over A1 and A2, it may not even notice,
> because not all MGs do heartbeats. So if the MGC determines it can
> actually talk to B1 and B2, it cannot force an MG controller
> switchover, or at least the standard does not define the procedure for
> this. I would note that, in practice, however, most of the MGs and
> MGCs have transparent switchover (there is no B1, B2, they reuse A1,
> A2 ...).
>
> The MGCP spec is a little more explicit on how the IP addresses are
> handled. So I don't understand why this topic is outside the scope of
> MEGACO.
>
> I raised these issues because, from my experience, every single vendor
> interprets them differently, and MGC-MG redundancy is a delicate
> subject. Any suggestions?
>
> Thanks
>
> Adrian Soncodi,
> Tekelec, Richardson, TX
>
>
>
>
> Christian Groves wrote:
>
>> G'Day Flemming,
>>
>> May be my brain hasn't restarted after the Easter break
>>
>> In cases other than 1a a failover method would be sent with the
>> ServiceChangeMGCId which the address of the association new or
>> existing. How the
>> state synchronisation is done is still out of scope of Megaco. MG2
>> will either
>> have the up to date state knowledge (eg. duplicate megaco messages)
>> or it will
>> have to audit or use some other means to find out.
>>
>> Is it the state sharing part that you are questioning?
>>
>> Regards, Christian
>>
>> Flemming Andreasen wrote:
>>
>> > Hi Christian
>> >
>> > Christian Groves wrote:
>> >
>> >
>> >>  G'Day Fleming,
>> >>
>> >>  The megaco model can support the configurations that you list
>> >>  below. The
>> >>  scenarios are implemented in such a way that the megaco interface
>> >>  is unaware
>> >>  that state synchronisation is occuring. It's for this reason that
>> >>  the
>> >>  specification doesn't say more about it, if you don't need Megaco
>> >>  messages then
>> >>  there's no point putting it in a megaco specification.
>> >>
>> >>
>> > I agree with the last point, however it only applies to case 1a.
>> > Clearly something
>> > has to happen in all the other cases, i.e. sending of a
>> > ServiceChange since the
>> > failover is not 100% transparent and the MGC needs to be informed
>> > about the change
>> > (whether it's a simple address change, mgcId change, or some degree
>> > of state loss).
>> > As I noted before, Megaco is silent on this and if you were to
>> > conclude anything
>> > from the current draft of Annex F, it would be that only model 1a
>> > is actually
>> > supported today (at least in a standard manner). If you believe all
>> > of these models
>> > actually are supported, then I'd like to know what
>> > ServiceChangeMethod,
>> > ServiceChangeReason, and ServiceChangeMGCId (and/or possibly
>> > ServiceChangeAddress)
>> > you would use in each case (apart from 1a that is).
>> >
>> > -- Flemming
>> >
>> >
>> >>  Regards, Christian
>> >>
>> >>  Flemming Andreasen wrote:
>> >>
>> >> > Megaco supports some notion of redundant MGs and redundant MG
>> >> > failover,
>> >> > however there is very little normative language, let alone
>> >> > explanation
>> >> > of how this is supposed to work (and the current incarnation of
>> >> > the
>> >> > upcoming Annex F doesn't help much here). The only model
>> >> > described is
>> >> > the one in Section 11.4, where both the primary and secondary
>> >> > MG are
>> >> > fully visible at all times and the MGC has to send duplicate
>> >> > messages to
>> >> > the MG.  However, what about supporting models where the MGC
>> >> > does not
>> >> > have to send multiple messages ? How does the protocol support
>> >> > the
>> >> > following models (if at all):
>> >> >
>> >> > 1a) MG1 (primary) and MG2 (secondary) share the same IP-address
>> >> > with
>> >> > complete state duplication (included for completeness since
>> >> > this one
>> >> > will be 100% transparent to the MGC).
>> >> > 1b) MG1 (primary) and MG2 (secondary) share the same
>> >> > IP-address, and
>> >> > there is complete Megaco state synchronization
>> >> > 1c) MG1 (primary) and MG2 (secondary)
>> >> > share the same IP-address, and
>> >> > there is Megaco state synchronization at regular checkpoints
>> >> > (i.e. not
>> >> > real-time so there may be some discrepances between the two)
>> >> > 2a) MG1 and MG2 have different IP addresses, and there is
>> >> > complete
>> >> > Megaco state synchronization.
>> >> > 2b) MG1 and MG2 have different IP addresses, and there is
>> >> > Megaco state
>> >> > synchronization at regular checkpoints (i.e. not real-time)
>> >> >
>> >> > Thanks
>> >> >
>> >> >         Flemming
>> >> >
>> >> > _______________________________________________
>> >> > Megaco mailing list
>> >> > Megaco@ietf.org
>> >> > https://www1.ietf.org/mailman/listinfo/megaco
>> >> >
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
--
Fernando Vallejo Lazaro
Phone:  +34 91 330 5614
SW  Wireline ASD-Madrid
       ALCATEL



--------------735605A5C6D9BB0528396C03
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi all,
<p>Only some comments.
<p>- You say :&nbsp;"So while talking on A1-A1, the MGC cannot for example
audit on A2-A2, because this is immediately considered a failover (...)".
I don't think this is true.
<br>If an MG receives an Audit from MGC-A2 (which it does not know) it
will reject the transaction because there is no association established
with it.
<p>- If the MG is multi-homed you can provision the two IP&nbsp;static
addresses as primary and secondary MGCs. In case one fails it will change
to the other IP which in fact is the
<br>same MGC.&nbsp;Maybe there should be a deep explanation of how to do
this to smooth the process because the MG&nbsp;does not know whether the
secondary is an independent
<br>MGC, a backup or a mirror and depending on this information it can
behave in one way or another (e.g. a ServiceChange Request only Informational)
<p>- Another thing the MGC can do when it detects the that A1 is going
to die is to send a Handoff to the interface A2 for each MG so that the
connections are restablished
<br>in the new path.
<p>Regards
<br>Fernando
<p>Adrian Soncodi wrote:
<blockquote TYPE=CITE>Hello, all,
<p>I was wondering what is your oppinion on the following:
<p>Another topic that is not addressed in the MEGACO spec is the case of
a multi-homed MG, i.e. an MG where:
<br>- the primary controller has 2 physical interfaces A1 and A2, potentially
on 2 different subnets, working in load-sharing mode (rather than active-standby)
<br>- the secondary MG controller can then be either transparrent (it takes
over A1 and A2 on switchover) or non-transparent (has 2 more physical addresses,
B1 and B2).
<p>One may argue that multi-homing is not necessary, for example because
you can always assign a single "logical" IP address A that is reachable
over both interfaces A1 and A2. Yes, but this schema requires some dynamic
IP routing capability in the backbone (e.g. to figure out when A1 is down
and packets for A should be routed to A2), which has a number of disadvantages:
<br>- Depending on the routing protocol, the latency for dynamic updates
of the addresses can be very large (180 seconds in case of RIP), unacceptable
for telephony.
<br>- Depending on the network topology, interface failures may not become
visible in the backbone. For example, if there is a LAN switch between
the MG and the first router, then the router does not see when the interface
A1 fails (unless the dynamic routing domain is extended to include the
MG, which is not always the case).
<br>- Some service providers (especially the smaller ones) do not run a
dynamic IP routing protocol in their (whole) backbone, or they may not
even have a real backbone, for example they may use leased lines, IP over
ATM/FR PVCs with no sophisticated routing capabilities.
<p>On the other hand, making the physical addresses A1 and A2 visible allows
for redundant signaling paths to the MG using only static IP routing in
the network, which in certain situations is desirable.
<p>The MGC-MG redundancy schema gets even more complicated if you consider
that the MGC can be multi-homed too. Effectively, it can have the same
A1, A2, B1, B2 schema as the MG. In this case, what is really useful is
an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes
care of all the combinations. But if the MG supports only UDP, it is not
clear from the standard how to emulate this SCTP behavior. For example:
<br>- Some MGs do a DNS query for the MGC name, get 2 IP addresses in response,
but they just ignore the second IP address, thus ignoring that the MGC
is multi-homed.
<br>- Other MGs consider the IP addresses as being 2 different MGCs, rather
than one multi-homed MG. The problem is that they only talk to one MGC
at a time, and then they need a "handover" to switch. So while talking
on A1-A1, the MGC cannot for example audit on A2-A2, because this is immediately
considered a failover (causing for example the pending notifications to
be lost). The MGCP spec, for example, explicitly states that an MG should
not change its controlling entity when being audited from another IP address
(and it doesn't say whether this is a different MGC or the same multi-homed
MGC).
<p>I think what needs to be clarified here is:
<br>- Whether an MG/MGC can be multi-homed and how to handle its multiple
IP addresses.
<br>- Whether an MG/MGC with active-standby controllers, transparent or
non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
<br>- Whether a domain name for an MG/MGC which yields more than one IP
address through DNS, is associated with one controller, or with an active-standby
pair, or possibly even with more active-standby pairs.
<p>The case with non-transparent MG controller switchover, as Flemming
mentioned, poses additional problems. For example, if the active MG controller
loses connectivity over A1 and A2, it may not even notice, because not
all MGs do heartbeats. So if the MGC determines it can actually talk to
B1 and B2, it cannot force an MG controller switchover, or at least the
standard does not define the procedure for this. I would note that, in
practice, however, most of the MGs and MGCs have transparent switchover
(there is no B1, B2, they reuse A1, A2 ...).
<p>The MGCP spec is a little more explicit on how the IP addresses are
handled. So I don't understand why this topic is outside the scope of&nbsp;
MEGACO.
<p>I raised these issues because, from my experience, every single vendor
interprets them differently, and MGC-MG redundancy is a delicate subject.
Any suggestions?
<p>Thanks
<p>Adrian Soncodi,
<br>Tekelec, Richardson, TX
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Christian Groves wrote:
<blockquote type="cite" cite="mid:3EA4CE5B.2C2AC97B@ericsson.com.au">
<pre wrap="">G'Day Flemming,

May be my brain hasn't restarted after the Easter break

In cases other than 1a a failover method would be sent with the
ServiceChangeMGCId which the address of the association new or existing. How the
state synchronisation is done is still out of scope of Megaco. MG2 will either
have the up to date state knowledge (eg. duplicate megaco messages) or it will
have to audit or use some other means to find out.

Is it the state sharing part that you are questioning?

Regards, Christian

Flemming Andreasen wrote:</pre>

<blockquote type="cite">
<pre wrap="">Hi Christian

Christian Groves wrote:

</pre>

<blockquote type="cite">
<pre wrap="">G'Day Fleming,

The megaco model can support the configurations that you list below. The
scenarios are implemented in such a way that the megaco interface is unaware
that state synchronisation is occuring. It's for this reason that the
specification doesn't say more about it, if you don't need Megaco messages then
there's no point putting it in a megaco specification.

</pre>
</blockquote>

<pre wrap="">I agree with the last point, however it only applies to case 1a. Clearly something
has to happen in all the other cases, i.e. sending of a ServiceChange since the
failover is not 100% transparent and the MGC needs to be informed about the change
(whether it's a simple address change, mgcId change, or some degree of state loss).
As I noted before, Megaco is silent on this and if you were to conclude anything
from the current draft of Annex F, it would be that only model 1a is actually
supported today (at least in a standard manner). If you believe all of these models
actually are supported, then I'd like to know what ServiceChangeMethod,
ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
you would use in each case (apart from 1a that is).

-- Flemming

</pre>

<blockquote type="cite">
<pre wrap="">Regards, Christian

Flemming Andreasen wrote:</pre>

<blockquote type="cite">
<pre wrap="">Megaco supports some notion of redundant MGs and redundant MG failover,
however there is very little normative language, let alone explanation
of how this is supposed to work (and the current incarnation of the
upcoming Annex F doesn't help much here). The only model described is
the one in Section 11.4, where both the primary and secondary MG are
fully visible at all times and the MGC has to send duplicate messages to
the MG.&nbsp; However, what about supporting models where the MGC does not
have to send multiple messages ? How does the protocol support the
following models (if at all):

1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
complete state duplication (included for completeness since this one
will be 100% transparent to the MGC).
1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
there is complete Megaco state synchronization
1c) MG1 (primary) and MG2 (secondary)&nbsp;
share the same IP-address, and
there is Megaco state synchronization at regular checkpoints (i.e. not
real-time so there may be some discrepances between the two)
2a) MG1 and MG2 have different IP addresses, and there is complete
Megaco state synchronization.
2b) MG1 and MG2 have different IP addresses, and there is Megaco state
synchronization at regular checkpoints (i.e. not real-time)

Thanks

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming

_______________________________________________
Megaco mailing list
<a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org
</a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a></pre>
</blockquote>
</blockquote>
</blockquote>

<pre wrap=""><!---->_______________________________________________
Megaco mailing list
<a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org
</a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a>

</pre>
</blockquote>
</blockquote>

<pre>--&nbsp;
Fernando Vallejo Lazaro
Phone:&nbsp; +34 91 330 5614
SW&nbsp; Wireline ASD-Madrid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ALCATEL</pre>
&nbsp;</html>

--------------735605A5C6D9BB0528396C03--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 04:44:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07861
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 04:44:08 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N8u5804701
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 04:56:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N8u5804698
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 04:56:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07849
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 04:43:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Ft8-0001M2-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 04:45:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Ft7-0001Lz-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 04:45:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N8rv804575;
	Wed, 23 Apr 2003 04:53:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N8os804472
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 04:50:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07739
	for <megaco@ietf.org>; Wed, 23 Apr 2003 04:38:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Fo7-0001L2-00
	for megaco@ietf.org; Wed, 23 Apr 2003 04:40:47 -0400
Received: from sess01.rdp.asi.alcatel.es ([159.23.144.5])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Fo6-0001Ks-00
	for megaco@ietf.org; Wed, 23 Apr 2003 04:40:46 -0400
Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1])
	by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h3N8eW709821;
	Wed, 23 Apr 2003 10:40:32 +0200 (MEST)
Received: from alcatel.es (sers5021 [159.23.115.21])
	by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id KAA20995;
	Wed, 23 Apr 2003 10:40:43 +0200 (MET DST)
Message-ID: <3EA6518B.862FDD51@alcatel.es>
Date: Wed, 23 Apr 2003 10:40:43 +0200
From: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>
Organization: ALCATEL
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com>
Content-Type: multipart/alternative;
 boundary="------------735605A5C6D9BB0528396C03"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------735605A5C6D9BB0528396C03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

Only some comments.

- You say : "So while talking on A1-A1, the MGC cannot for example audit
on A2-A2, because this is immediately considered a failover (...)". I
don't think this is true.
If an MG receives an Audit from MGC-A2 (which it does not know) it will
reject the transaction because there is no association established with
it.

- If the MG is multi-homed you can provision the two IP static addresses
as primary and secondary MGCs. In case one fails it will change to the
other IP which in fact is the
same MGC. Maybe there should be a deep explanation of how to do this to
smooth the process because the MG does not know whether the secondary is
an independent
MGC, a backup or a mirror and depending on this information it can
behave in one way or another (e.g. a ServiceChange Request only
Informational)

- Another thing the MGC can do when it detects the that A1 is going to
die is to send a Handoff to the interface A2 for each MG so that the
connections are restablished
in the new path.

Regards
Fernando

Adrian Soncodi wrote:

> Hello, all,
>
> I was wondering what is your oppinion on the following:
>
> Another topic that is not addressed in the MEGACO spec is the case of
> a multi-homed MG, i.e. an MG where:
> - the primary controller has 2 physical interfaces A1 and A2,
> potentially on 2 different subnets, working in load-sharing mode
> (rather than active-standby)
> - the secondary MG controller can then be either transparrent (it
> takes over A1 and A2 on switchover) or non-transparent (has 2 more
> physical addresses, B1 and B2).
>
> One may argue that multi-homing is not necessary, for example because
> you can always assign a single "logical" IP address A that is
> reachable over both interfaces A1 and A2. Yes, but this schema
> requires some dynamic IP routing capability in the backbone (e.g. to
> figure out when A1 is down and packets for A should be routed to A2),
> which has a number of disadvantages:
> - Depending on the routing protocol, the latency for dynamic updates
> of the addresses can be very large (180 seconds in case of RIP),
> unacceptable for telephony.
> - Depending on the network topology, interface failures may not become
> visible in the backbone. For example, if there is a LAN switch between
> the MG and the first router, then the router does not see when the
> interface A1 fails (unless the dynamic routing domain is extended to
> include the MG, which is not always the case).
> - Some service providers (especially the smaller ones) do not run a
> dynamic IP routing protocol in their (whole) backbone, or they may not
> even have a real backbone, for example they may use leased lines, IP
> over ATM/FR PVCs with no sophisticated routing capabilities.
>
> On the other hand, making the physical addresses A1 and A2 visible
> allows for redundant signaling paths to the MG using only static IP
> routing in the network, which in certain situations is desirable.
>
> The MGC-MG redundancy schema gets even more complicated if you
> consider that the MGC can be multi-homed too. Effectively, it can have
> the same A1, A2, B1, B2 schema as the MG. In this case, what is really
> useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because
> this takes care of all the combinations. But if the MG supports only
> UDP, it is not clear from the standard how to emulate this SCTP
> behavior. For example:
> - Some MGs do a DNS query for the MGC name, get 2 IP addresses in
> response, but they just ignore the second IP address, thus ignoring
> that the MGC is multi-homed.
> - Other MGs consider the IP addresses as being 2 different MGCs,
> rather than one multi-homed MG. The problem is that they only talk to
> one MGC at a time, and then they need a "handover" to switch. So while
> talking on A1-A1, the MGC cannot for example audit on A2-A2, because
> this is immediately considered a failover (causing for example the
> pending notifications to be lost). The MGCP spec, for example,
> explicitly states that an MG should not change its controlling entity
> when being audited from another IP address (and it doesn't say whether
> this is a different MGC or the same multi-homed MGC).
>
> I think what needs to be clarified here is:
> - Whether an MG/MGC can be multi-homed and how to handle its multiple
> IP addresses.
> - Whether an MG/MGC with active-standby controllers, transparent or
> non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
> - Whether a domain name for an MG/MGC which yields more than one IP
> address through DNS, is associated with one controller, or with an
> active-standby pair, or possibly even with more active-standby pairs.
>
> The case with non-transparent MG controller switchover, as Flemming
> mentioned, poses additional problems. For example, if the active MG
> controller loses connectivity over A1 and A2, it may not even notice,
> because not all MGs do heartbeats. So if the MGC determines it can
> actually talk to B1 and B2, it cannot force an MG controller
> switchover, or at least the standard does not define the procedure for
> this. I would note that, in practice, however, most of the MGs and
> MGCs have transparent switchover (there is no B1, B2, they reuse A1,
> A2 ...).
>
> The MGCP spec is a little more explicit on how the IP addresses are
> handled. So I don't understand why this topic is outside the scope of
> MEGACO.
>
> I raised these issues because, from my experience, every single vendor
> interprets them differently, and MGC-MG redundancy is a delicate
> subject. Any suggestions?
>
> Thanks
>
> Adrian Soncodi,
> Tekelec, Richardson, TX
>
>
>
>
> Christian Groves wrote:
>
>> G'Day Flemming,
>>
>> May be my brain hasn't restarted after the Easter break
>>
>> In cases other than 1a a failover method would be sent with the
>> ServiceChangeMGCId which the address of the association new or
>> existing. How the
>> state synchronisation is done is still out of scope of Megaco. MG2
>> will either
>> have the up to date state knowledge (eg. duplicate megaco messages)
>> or it will
>> have to audit or use some other means to find out.
>>
>> Is it the state sharing part that you are questioning?
>>
>> Regards, Christian
>>
>> Flemming Andreasen wrote:
>>
>> > Hi Christian
>> >
>> > Christian Groves wrote:
>> >
>> >
>> >>  G'Day Fleming,
>> >>
>> >>  The megaco model can support the configurations that you list
>> >>  below. The
>> >>  scenarios are implemented in such a way that the megaco interface
>> >>  is unaware
>> >>  that state synchronisation is occuring. It's for this reason that
>> >>  the
>> >>  specification doesn't say more about it, if you don't need Megaco
>> >>  messages then
>> >>  there's no point putting it in a megaco specification.
>> >>
>> >>
>> > I agree with the last point, however it only applies to case 1a.
>> > Clearly something
>> > has to happen in all the other cases, i.e. sending of a
>> > ServiceChange since the
>> > failover is not 100% transparent and the MGC needs to be informed
>> > about the change
>> > (whether it's a simple address change, mgcId change, or some degree
>> > of state loss).
>> > As I noted before, Megaco is silent on this and if you were to
>> > conclude anything
>> > from the current draft of Annex F, it would be that only model 1a
>> > is actually
>> > supported today (at least in a standard manner). If you believe all
>> > of these models
>> > actually are supported, then I'd like to know what
>> > ServiceChangeMethod,
>> > ServiceChangeReason, and ServiceChangeMGCId (and/or possibly
>> > ServiceChangeAddress)
>> > you would use in each case (apart from 1a that is).
>> >
>> > -- Flemming
>> >
>> >
>> >>  Regards, Christian
>> >>
>> >>  Flemming Andreasen wrote:
>> >>
>> >> > Megaco supports some notion of redundant MGs and redundant MG
>> >> > failover,
>> >> > however there is very little normative language, let alone
>> >> > explanation
>> >> > of how this is supposed to work (and the current incarnation of
>> >> > the
>> >> > upcoming Annex F doesn't help much here). The only model
>> >> > described is
>> >> > the one in Section 11.4, where both the primary and secondary
>> >> > MG are
>> >> > fully visible at all times and the MGC has to send duplicate
>> >> > messages to
>> >> > the MG.  However, what about supporting models where the MGC
>> >> > does not
>> >> > have to send multiple messages ? How does the protocol support
>> >> > the
>> >> > following models (if at all):
>> >> >
>> >> > 1a) MG1 (primary) and MG2 (secondary) share the same IP-address
>> >> > with
>> >> > complete state duplication (included for completeness since
>> >> > this one
>> >> > will be 100% transparent to the MGC).
>> >> > 1b) MG1 (primary) and MG2 (secondary) share the same
>> >> > IP-address, and
>> >> > there is complete Megaco state synchronization
>> >> > 1c) MG1 (primary) and MG2 (secondary)
>> >> > share the same IP-address, and
>> >> > there is Megaco state synchronization at regular checkpoints
>> >> > (i.e. not
>> >> > real-time so there may be some discrepances between the two)
>> >> > 2a) MG1 and MG2 have different IP addresses, and there is
>> >> > complete
>> >> > Megaco state synchronization.
>> >> > 2b) MG1 and MG2 have different IP addresses, and there is
>> >> > Megaco state
>> >> > synchronization at regular checkpoints (i.e. not real-time)
>> >> >
>> >> > Thanks
>> >> >
>> >> >         Flemming
>> >> >
>> >> > _______________________________________________
>> >> > Megaco mailing list
>> >> > Megaco@ietf.org
>> >> > https://www1.ietf.org/mailman/listinfo/megaco
>> >> >
>> _______________________________________________
>> Megaco mailing list
>> Megaco@ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
--
Fernando Vallejo Lazaro
Phone:  +34 91 330 5614
SW  Wireline ASD-Madrid
       ALCATEL



--------------735605A5C6D9BB0528396C03
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi all,
<p>Only some comments.
<p>- You say :&nbsp;"So while talking on A1-A1, the MGC cannot for example
audit on A2-A2, because this is immediately considered a failover (...)".
I don't think this is true.
<br>If an MG receives an Audit from MGC-A2 (which it does not know) it
will reject the transaction because there is no association established
with it.
<p>- If the MG is multi-homed you can provision the two IP&nbsp;static
addresses as primary and secondary MGCs. In case one fails it will change
to the other IP which in fact is the
<br>same MGC.&nbsp;Maybe there should be a deep explanation of how to do
this to smooth the process because the MG&nbsp;does not know whether the
secondary is an independent
<br>MGC, a backup or a mirror and depending on this information it can
behave in one way or another (e.g. a ServiceChange Request only Informational)
<p>- Another thing the MGC can do when it detects the that A1 is going
to die is to send a Handoff to the interface A2 for each MG so that the
connections are restablished
<br>in the new path.
<p>Regards
<br>Fernando
<p>Adrian Soncodi wrote:
<blockquote TYPE=CITE>Hello, all,
<p>I was wondering what is your oppinion on the following:
<p>Another topic that is not addressed in the MEGACO spec is the case of
a multi-homed MG, i.e. an MG where:
<br>- the primary controller has 2 physical interfaces A1 and A2, potentially
on 2 different subnets, working in load-sharing mode (rather than active-standby)
<br>- the secondary MG controller can then be either transparrent (it takes
over A1 and A2 on switchover) or non-transparent (has 2 more physical addresses,
B1 and B2).
<p>One may argue that multi-homing is not necessary, for example because
you can always assign a single "logical" IP address A that is reachable
over both interfaces A1 and A2. Yes, but this schema requires some dynamic
IP routing capability in the backbone (e.g. to figure out when A1 is down
and packets for A should be routed to A2), which has a number of disadvantages:
<br>- Depending on the routing protocol, the latency for dynamic updates
of the addresses can be very large (180 seconds in case of RIP), unacceptable
for telephony.
<br>- Depending on the network topology, interface failures may not become
visible in the backbone. For example, if there is a LAN switch between
the MG and the first router, then the router does not see when the interface
A1 fails (unless the dynamic routing domain is extended to include the
MG, which is not always the case).
<br>- Some service providers (especially the smaller ones) do not run a
dynamic IP routing protocol in their (whole) backbone, or they may not
even have a real backbone, for example they may use leased lines, IP over
ATM/FR PVCs with no sophisticated routing capabilities.
<p>On the other hand, making the physical addresses A1 and A2 visible allows
for redundant signaling paths to the MG using only static IP routing in
the network, which in certain situations is desirable.
<p>The MGC-MG redundancy schema gets even more complicated if you consider
that the MGC can be multi-homed too. Effectively, it can have the same
A1, A2, B1, B2 schema as the MG. In this case, what is really useful is
an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes
care of all the combinations. But if the MG supports only UDP, it is not
clear from the standard how to emulate this SCTP behavior. For example:
<br>- Some MGs do a DNS query for the MGC name, get 2 IP addresses in response,
but they just ignore the second IP address, thus ignoring that the MGC
is multi-homed.
<br>- Other MGs consider the IP addresses as being 2 different MGCs, rather
than one multi-homed MG. The problem is that they only talk to one MGC
at a time, and then they need a "handover" to switch. So while talking
on A1-A1, the MGC cannot for example audit on A2-A2, because this is immediately
considered a failover (causing for example the pending notifications to
be lost). The MGCP spec, for example, explicitly states that an MG should
not change its controlling entity when being audited from another IP address
(and it doesn't say whether this is a different MGC or the same multi-homed
MGC).
<p>I think what needs to be clarified here is:
<br>- Whether an MG/MGC can be multi-homed and how to handle its multiple
IP addresses.
<br>- Whether an MG/MGC with active-standby controllers, transparent or
non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
<br>- Whether a domain name for an MG/MGC which yields more than one IP
address through DNS, is associated with one controller, or with an active-standby
pair, or possibly even with more active-standby pairs.
<p>The case with non-transparent MG controller switchover, as Flemming
mentioned, poses additional problems. For example, if the active MG controller
loses connectivity over A1 and A2, it may not even notice, because not
all MGs do heartbeats. So if the MGC determines it can actually talk to
B1 and B2, it cannot force an MG controller switchover, or at least the
standard does not define the procedure for this. I would note that, in
practice, however, most of the MGs and MGCs have transparent switchover
(there is no B1, B2, they reuse A1, A2 ...).
<p>The MGCP spec is a little more explicit on how the IP addresses are
handled. So I don't understand why this topic is outside the scope of&nbsp;
MEGACO.
<p>I raised these issues because, from my experience, every single vendor
interprets them differently, and MGC-MG redundancy is a delicate subject.
Any suggestions?
<p>Thanks
<p>Adrian Soncodi,
<br>Tekelec, Richardson, TX
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Christian Groves wrote:
<blockquote type="cite" cite="mid:3EA4CE5B.2C2AC97B@ericsson.com.au">
<pre wrap="">G'Day Flemming,

May be my brain hasn't restarted after the Easter break

In cases other than 1a a failover method would be sent with the
ServiceChangeMGCId which the address of the association new or existing. How the
state synchronisation is done is still out of scope of Megaco. MG2 will either
have the up to date state knowledge (eg. duplicate megaco messages) or it will
have to audit or use some other means to find out.

Is it the state sharing part that you are questioning?

Regards, Christian

Flemming Andreasen wrote:</pre>

<blockquote type="cite">
<pre wrap="">Hi Christian

Christian Groves wrote:

</pre>

<blockquote type="cite">
<pre wrap="">G'Day Fleming,

The megaco model can support the configurations that you list below. The
scenarios are implemented in such a way that the megaco interface is unaware
that state synchronisation is occuring. It's for this reason that the
specification doesn't say more about it, if you don't need Megaco messages then
there's no point putting it in a megaco specification.

</pre>
</blockquote>

<pre wrap="">I agree with the last point, however it only applies to case 1a. Clearly something
has to happen in all the other cases, i.e. sending of a ServiceChange since the
failover is not 100% transparent and the MGC needs to be informed about the change
(whether it's a simple address change, mgcId change, or some degree of state loss).
As I noted before, Megaco is silent on this and if you were to conclude anything
from the current draft of Annex F, it would be that only model 1a is actually
supported today (at least in a standard manner). If you believe all of these models
actually are supported, then I'd like to know what ServiceChangeMethod,
ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
you would use in each case (apart from 1a that is).

-- Flemming

</pre>

<blockquote type="cite">
<pre wrap="">Regards, Christian

Flemming Andreasen wrote:</pre>

<blockquote type="cite">
<pre wrap="">Megaco supports some notion of redundant MGs and redundant MG failover,
however there is very little normative language, let alone explanation
of how this is supposed to work (and the current incarnation of the
upcoming Annex F doesn't help much here). The only model described is
the one in Section 11.4, where both the primary and secondary MG are
fully visible at all times and the MGC has to send duplicate messages to
the MG.&nbsp; However, what about supporting models where the MGC does not
have to send multiple messages ? How does the protocol support the
following models (if at all):

1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
complete state duplication (included for completeness since this one
will be 100% transparent to the MGC).
1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
there is complete Megaco state synchronization
1c) MG1 (primary) and MG2 (secondary)&nbsp;
share the same IP-address, and
there is Megaco state synchronization at regular checkpoints (i.e. not
real-time so there may be some discrepances between the two)
2a) MG1 and MG2 have different IP addresses, and there is complete
Megaco state synchronization.
2b) MG1 and MG2 have different IP addresses, and there is Megaco state
synchronization at regular checkpoints (i.e. not real-time)

Thanks

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming

_______________________________________________
Megaco mailing list
<a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org
</a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a></pre>
</blockquote>
</blockquote>
</blockquote>

<pre wrap=""><!---->_______________________________________________
Megaco mailing list
<a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org
</a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a>

</pre>
</blockquote>
</blockquote>

<pre>--&nbsp;
Fernando Vallejo Lazaro
Phone:&nbsp; +34 91 330 5614
SW&nbsp; Wireline ASD-Madrid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ALCATEL</pre>
&nbsp;</html>

--------------735605A5C6D9BB0528396C03--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 05:38:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09009
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 05:38:02 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N9n5808588;
	Wed, 23 Apr 2003 05:49:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N9kK808419
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 05:46:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08929
	for <megaco@ietf.org>; Wed, 23 Apr 2003 05:33:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Gfk-0001aS-00
	for megaco@ietf.org; Wed, 23 Apr 2003 05:36:12 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Gfj-0001aM-00
	for megaco@ietf.org; Wed, 23 Apr 2003 05:36:12 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3N9aYT5024181;
	Wed, 23 Apr 2003 18:36:34 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3N9aYoK009402;
	Wed, 23 Apr 2003 18:36:34 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3N9aXTT018694;
	Wed, 23 Apr 2003 18:36:33 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA02044;
	Wed, 23 Apr 2003 18:36:33 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA06780;
	Wed, 23 Apr 2003 18:36:32 +0900 (JST)
Message-Id: <5.0.2.7.2.20030423181944.045d4008@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Wed, 23 Apr 2003 18:37:51 +0900
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] AuditReply from MG with no specific context
Cc: megaco@ietf.org
In-Reply-To: <3EA3DC35.622CE714@lmf.ericsson.se>
References: <5.0.2.7.2.20030418201413.03d89bf0@imb.m.ecl.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi,

Thank you for comments.

This seems rather a minor problem, but we are annoyed by such a kind
of problems whether MGC allow a certain message structure or not.

I think the MGCs should have more capabilities than MGs in actual.

Regards,
-Susumu

---
>Hi,
>
> > Could you please give me any suggestion along your implementation for
> > this issue ?
> >
> > It seems that every reply should not challenge the megaco standard,
> > and the error reply of "No TerminationID matched a wildcard" would be
> > possible.
>
>I guess you could send that. "Protocol error" would be another option, I'd
>say...
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
> >
> >
> > Thanks in advance,
> > -Susumu
> >
> > ---
> > >Hi all,
> > >
> > >What type of reply message should the MG with no specific context
> > >send back to the MGC, when receiving an AuditValue message with
> > >ContextID=ALL and TerminationID=ROOT ?
> > >
> > >I think we may have some choices for that, that is (a) command reply
> > >with the audit list contains no information, (b) command reply contains
> > >no information, and (c) action reply contains no information.
> > >
> > >Is there any syntax error in each choice above ?
> > >And which is the best choice from above or any other solutions ?
> > >
> > >Thanks,
> > >-Susumu
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 05:39:06 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09039
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 05:39:06 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3N9p3u08752
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 05:51:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N9p3808749
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 05:51:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09029
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 05:38:35 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198GkI-0001c1-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 05:40:54 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198GkI-0001by-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 05:40:54 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N9n5808588;
	Wed, 23 Apr 2003 05:49:05 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N9kK808419
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 05:46:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08929
	for <megaco@ietf.org>; Wed, 23 Apr 2003 05:33:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Gfk-0001aS-00
	for megaco@ietf.org; Wed, 23 Apr 2003 05:36:12 -0400
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Gfj-0001aM-00
	for megaco@ietf.org; Wed, 23 Apr 2003 05:36:12 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3N9aYT5024181;
	Wed, 23 Apr 2003 18:36:34 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3N9aYoK009402;
	Wed, 23 Apr 2003 18:36:34 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id h3N9aXTT018694;
	Wed, 23 Apr 2003 18:36:33 +0900 (JST)
Received: from imb.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA02044;
	Wed, 23 Apr 2003 18:36:33 +0900 (JST)
Received: from DYNABOOK-YAMA.lab.ntt.co.jp
	by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA06780;
	Wed, 23 Apr 2003 18:36:32 +0900 (JST)
Message-Id: <5.0.2.7.2.20030423181944.045d4008@imb.m.ecl.ntt.co.jp>
X-Sender: sy001@imb.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2
Date: Wed, 23 Apr 2003 18:37:51 +0900
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
From: "YAMAMOTO, Susumu" <yamamoto.susumu@lab.ntt.co.jp>
Subject: Re: [Megaco] AuditReply from MG with no specific context
Cc: megaco@ietf.org
In-Reply-To: <3EA3DC35.622CE714@lmf.ericsson.se>
References: <5.0.2.7.2.20030418201413.03d89bf0@imb.m.ecl.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi,

Thank you for comments.

This seems rather a minor problem, but we are annoyed by such a kind
of problems whether MGC allow a certain message structure or not.

I think the MGCs should have more capabilities than MGs in actual.

Regards,
-Susumu

---
>Hi,
>
> > Could you please give me any suggestion along your implementation for
> > this issue ?
> >
> > It seems that every reply should not challenge the megaco standard,
> > and the error reply of "No TerminationID matched a wildcard" would be
> > possible.
>
>I guess you could send that. "Protocol error" would be another option, I'd
>say...
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
> >
> >
> > Thanks in advance,
> > -Susumu
> >
> > ---
> > >Hi all,
> > >
> > >What type of reply message should the MG with no specific context
> > >send back to the MGC, when receiving an AuditValue message with
> > >ContextID=ALL and TerminationID=ROOT ?
> > >
> > >I think we may have some choices for that, that is (a) command reply
> > >with the audit list contains no information, (b) command reply contains
> > >no information, and (c) action reply contains no information.
> > >
> > >Is there any syntax error in each choice above ?
> > >And which is the best choice from above or any other solutions ?
> > >
> > >Thanks,
> > >-Susumu
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 08:18:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15105
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 08:18:49 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCTw819683;
	Wed, 23 Apr 2003 08:29:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCPm819499
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 08:25:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14994
	for <megaco@ietf.org>; Wed, 23 Apr 2003 08:13:17 -0400 (EDT)
From: klaha@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198JA0-0003Dw-00
	for megaco@ietf.org; Wed, 23 Apr 2003 08:15:36 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 198J9z-0003Dc-00
	for megaco@ietf.org; Wed, 23 Apr 2003 08:15:36 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3NCDIs14301
	for <megaco@ietf.org>; Wed, 23 Apr 2003 17:43:18 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3NCCt914171;
	Wed, 23 Apr 2003 17:42:55 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3NCFtB00239;
	Wed, 23 Apr 2003 17:45:56 +0530 (IST)
Subject: RE: [Megaco] Megaco CAS support
To: Aleksandr Ryabin <kengr@winphoria.com>
Cc: megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>,
        Michael DiGioia <michaeldigioia@hotmail.com>,
        Christian.Groves@ericsson.com.au, bsteinka@telica.com
Date: Wed, 23 Apr 2003 17:41:40 +0530
Message-ID: <OF0BAD0D76.DB0D008A-ON65256D11.00408581@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 23/04/2003
 05:40:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3NCPm819500
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit







Let me take this opportunity to present the understanding that Hughes has
on this topic.

1. It was 3 years back that Hughes first published the r2 draft. It had
created a
lot of interest on the list, so much so that it was made a formal MEGACO WG
item.

2. Hughes followed it up with the r1 package draft. This stirred a lot of
reaction and
proactive contribution from the list to make it into a generic CAS package
draft
addressing not only r1 but nearly all forms of North American CAS. This
draft
was later renamed to manyfolks CAS package draft and included the "bcas"
package.

3. There was a directive from the list to make r2 a derived package to
bcas.
Hughes entered into a dialogue with Nortel (one of the co-authors along
with Hughes
to the basic CAS package draft) to make certain modifications in bcas
package
so as to enable r2 a true derivative of bcas. It was generally agreed that
there be
yet an abstraction package "icas" which derives from "bcas" and "r2" then
derives
"icas". ( icas does in no way replace r2)

4. The "icas" package never saw the light of the day at IETF. Hughes went
ahead
and resubmitted the "r2" draft aligned as close to the already expired
"bcas" package
as possible. The "bcas" package submission was also not refreshed.

5. All of a sudden now we find that "bcas" and "icas" have found entries
into ITU
package standardization sector but not "r2". The "icas" package draft was
also never floated
to the list for any review.

6. "icas" package submitted to ITU in its present form has flaws.

Given the above background, we clearly need a charter how to move forward
on
the CAS package drafts. Hughes generally agrees that the CAS package
architecture
should follow the hierarchy "bcas"-->"icas"-->"r2" (with some changes in
the icas package
in its present form).

It is to be noted that content-wise whatever is there in the latest r2
package draft submitted to IETF
is authentic and requires no modification. An alignment with icas package
requires certain
signals/events/properties to be moved out of r2 package and placed in icas.

We are willing to synch the CAS package drafts both at IETF and ITU but
question is how?

-- Kushanava








Aleksandr Ryabin <kengr@winphoria.com>@ietf.org on 04/23/2003 04:34:50 AM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
cc:    Michael DiGioia <michaeldigioia@hotmail.com>,
       Christian.Groves@ericsson.com.au, bsteinka@telica.com

Subject:    RE: [Megaco] Megaco CAS support


I see the reason to push it through ITU, but we definitely would not want
to
see two, or more different packages doing the same thing published one
through
IETF and another trough ITU. Thus, since MEGACO is (also) published as
IETF standard we should at least make every effort to avoid duplication of
work.

Unfortunately not all of us have direct access (at least direct say) in ITU
and
thus at least keeping IETF community informed on progress of MEGACO/H.248
related work would be very useful, as well as using this list for various
discussions.
In fact AVD-2345 contains the following statement regarding H.248.mf
packages:
"It was suggested that we send a liaison to the IESG and MEGACO proposing
this move and asking if this presents a problem to either of them.  Mr
Boyle
will draft a liaison for our consideration.  If we do not receive an
objection from
them we will progress these with a goal of consent in May.  The liaison
appears
as TD-20a." Should then the r2 package also be included in same liaison?

As far as I remember "CAS packages published by Hughes" are new revisions
of the drafts that were published a long time ago (at least for r2). This
very fact
that new revisions were published despite the CAS work moved to ITU
indicates
the lack of communication.

Can I suggest to put some wording on WG charter home page regarding
each work "moved" to ITU (links to liaisons?) and maybe at least some kind
of sense of ITU schedule for that work? I know there is wording already
about
IETF position related to packages, but still info would be very useful.
At least a pointer to latest up to date "packages guide" (AVD-2294) might
be
sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph
from
AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)

In any case could you please outline an ITU schedule for CAS related
packages?
What is the verdict for CAS drafts published in IETF? Are they going to be
folded
into ITU work? I guess at least some of them (by Nortel) are? What about
others?
Is r2 package planned to be dropped/replaced with icas?
Are there any additional ITU CAS related packages/documents not listed
in original Christian's email?
Are there any other CAS packages planned?

Thanks
        Aleks

At 05:26 PM 4/22/2003, Kevin Boyle wrote:

With all due respect, the IETF had its chance to progress these (and many
other) packages.  In the interests of the larger community, I have taken
the packages to the ITU for standardization, since the IETF does not seem
interested in standardizing any packages.

The work in the IETF is not "up and running".  The drafts published by
Hughes were published after the CAS packages were submitted to the ITU.

Given that the working group is in the process of winding down, I do not
see any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.

Kevin

-----Original Message-----
From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
Sent: Tuesday, April 22, 2003 5:01 PM
To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
Cc: bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support


Christian,

I agree, CAS should be part of the IETF similar to the original MEGACO
draft
work that held both organizations in sync.

/mpd



>From: Aleksandr Ryabin <kengr@winphoria.com>
>To: Christian Groves <Christian.Groves@ericsson.com.au>,
>megaco@ietf.org
>CC: Brad Steinka <bsteinka@telica.com>
>Subject: Re: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 10:30:01 -0400
>
>Hi Christian,
>
>Then why are these brand new revisions of drafts were just recently
>submitted?
>
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>
>More over a quick look through reveals that some of the package items
>in
>icas
>(ITU) the same as in r2 (IETF) up to the extent of exactly the same
>wording.
>
>Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
>does not seem to be defined in the document and also "conflicts" with
>above IETF "CAS Maintenance Package".
>
>There is also reference to r2 package in AVD-2316 nowhere found in ITU.
>
>Also basic CAS packages draft still available at:
>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
>2.txt
>but it is slightly different (outdated?) from AVD-2315 ITU version you
have
>specified.
>
>The recent submission of the above drafts had lead me to believe that
>CAS work is still quite "up and running" in IETF. This is all very
>confusing. When was it decided to move the work to ITU? Could someone
>point me out to some references (in IETF) of that please?
>
>My two cents on this topic: CAS is not an isolated package and in my
>opinion
>it would be much more productive to keep it on both channels (ITU and
IETF)
>and in sync, similar to some other items done so far in H.248/MEGACO.
>What other folks think about it?
>
>Also in any case can the authors of ITU and IETF CAS related packages
>work together to come up with some kind of game plan and post it to the
>list to avoid any further confusion and inconsistencies?
>
>Thanks!
>         Aleks
>
>At 07:54 PM 4/21/2003, Christian Groves wrote:
>>G'Day Brad and Karl,
>>
>>I believe the intention is to move the CAS work into the ITU. The
>>contributions
>>containing the latest drafts can be found at:
>>ftp://standard.pictel.com/avc-site/0302_San/
>>
>>AVD-2312        MF Tone Generation and Detection Packages
>>AVD-2315        Basic CAS Packages
>>AVD-2316        International CAS Packages
>>AVD-2317        Enhanced Analog Line Packages
>>
>>Regards, Christian
>>
>>Brad Steinka wrote:
>> >
>> > There were several RFC draft document that described various
>> > packages
>>to
>> > support CAS, R1, R2, BCAS, etc.
>> > Most of these drafts have expired.
>> >
>> > Can anyone tell me what the latest RFCs are that support CAS calls
>> > and
>>where
>> > they are in the standards process?
>> >
>> > Thanks
>> >

>> > Director - Software Engineering
>> > 734 Forest Street, Building G, Suite 100
>> > Marlboro, Ma.   01752
>> > Tel:  508-480-0909  x154
>> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> > Web:   www.telica.com <http://www.telica.com>
>> >
>> > _______________________________________________
>> > Megaco mailing list
>> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 08:19:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15236
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 08:19:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NCVNU19784
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 08:31:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCVM819781
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 08:31:22 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15132
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 08:18:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198JFP-0003FX-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 08:21:11 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198JFO-0003FU-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 08:21:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCTw819683;
	Wed, 23 Apr 2003 08:29:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCPm819499
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 08:25:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14994
	for <megaco@ietf.org>; Wed, 23 Apr 2003 08:13:17 -0400 (EDT)
From: klaha@hss.hns.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198JA0-0003Dw-00
	for megaco@ietf.org; Wed, 23 Apr 2003 08:15:36 -0400
Received: from hindon.hss.co.in ([202.54.26.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 198J9z-0003Dc-00
	for megaco@ietf.org; Wed, 23 Apr 2003 08:15:36 -0400
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3NCDIs14301
	for <megaco@ietf.org>; Wed, 23 Apr 2003 17:43:18 +0530 (IST)
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h3NCCt914171;
	Wed, 23 Apr 2003 17:42:55 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h3NCFtB00239;
	Wed, 23 Apr 2003 17:45:56 +0530 (IST)
Subject: RE: [Megaco] Megaco CAS support
To: Aleksandr Ryabin <kengr@winphoria.com>
Cc: megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>,
        Michael DiGioia <michaeldigioia@hotmail.com>,
        Christian.Groves@ericsson.com.au, bsteinka@telica.com
Date: Wed, 23 Apr 2003 17:41:40 +0530
Message-ID: <OF0BAD0D76.DB0D008A-ON65256D11.00408581@hss.hns.com>
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 23/04/2003
 05:40:48 PM
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3NCPm819500
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3NCTw819683
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3NCVM819781
Content-Transfer-Encoding: 8bit







Let me take this opportunity to present the understanding that Hughes has
on this topic.

1. It was 3 years back that Hughes first published the r2 draft. It had
created a
lot of interest on the list, so much so that it was made a formal MEGACO WG
item.

2. Hughes followed it up with the r1 package draft. This stirred a lot of
reaction and
proactive contribution from the list to make it into a generic CAS package
draft
addressing not only r1 but nearly all forms of North American CAS. This
draft
was later renamed to manyfolks CAS package draft and included the "bcas"
package.

3. There was a directive from the list to make r2 a derived package to
bcas.
Hughes entered into a dialogue with Nortel (one of the co-authors along
with Hughes
to the basic CAS package draft) to make certain modifications in bcas
package
so as to enable r2 a true derivative of bcas. It was generally agreed that
there be
yet an abstraction package "icas" which derives from "bcas" and "r2" then
derives
"icas". ( icas does in no way replace r2)

4. The "icas" package never saw the light of the day at IETF. Hughes went
ahead
and resubmitted the "r2" draft aligned as close to the already expired
"bcas" package
as possible. The "bcas" package submission was also not refreshed.

5. All of a sudden now we find that "bcas" and "icas" have found entries
into ITU
package standardization sector but not "r2". The "icas" package draft was
also never floated
to the list for any review.

6. "icas" package submitted to ITU in its present form has flaws.

Given the above background, we clearly need a charter how to move forward
on
the CAS package drafts. Hughes generally agrees that the CAS package
architecture
should follow the hierarchy "bcas"-->"icas"-->"r2" (with some changes in
the icas package
in its present form).

It is to be noted that content-wise whatever is there in the latest r2
package draft submitted to IETF
is authentic and requires no modification. An alignment with icas package
requires certain
signals/events/properties to be moved out of r2 package and placed in icas.

We are willing to synch the CAS package drafts both at IETF and ITU but
question is how?

-- Kushanava








Aleksandr Ryabin <kengr@winphoria.com>@ietf.org on 04/23/2003 04:34:50 AM

Sent by:    megaco-admin@ietf.org


To:    megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
cc:    Michael DiGioia <michaeldigioia@hotmail.com>,
       Christian.Groves@ericsson.com.au, bsteinka@telica.com

Subject:    RE: [Megaco] Megaco CAS support


I see the reason to push it through ITU, but we definitely would not want
to
see two, or more different packages doing the same thing published one
through
IETF and another trough ITU. Thus, since MEGACO is (also) published as
IETF standard we should at least make every effort to avoid duplication of
work.

Unfortunately not all of us have direct access (at least direct say) in ITU
and
thus at least keeping IETF community informed on progress of MEGACO/H.248
related work would be very useful, as well as using this list for various
discussions.
In fact AVD-2345 contains the following statement regarding H.248.mf
packages:
"It was suggested that we send a liaison to the IESG and MEGACO proposing
this move and asking if this presents a problem to either of them.  Mr
Boyle
will draft a liaison for our consideration.  If we do not receive an
objection from
them we will progress these with a goal of consent in May.  The liaison
appears
as TD-20a." Should then the r2 package also be included in same liaison?

As far as I remember "CAS packages published by Hughes" are new revisions
of the drafts that were published a long time ago (at least for r2). This
very fact
that new revisions were published despite the CAS work moved to ITU
indicates
the lack of communication.

Can I suggest to put some wording on WG charter home page regarding
each work "moved" to ITU (links to liaisons?) and maybe at least some kind
of sense of ITU schedule for that work? I know there is wording already
about
IETF position related to packages, but still info would be very useful.
At least a pointer to latest up to date "packages guide" (AVD-2294) might
be
sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph
from
AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)

In any case could you please outline an ITU schedule for CAS related
packages?
What is the verdict for CAS drafts published in IETF? Are they going to be
folded
into ITU work? I guess at least some of them (by Nortel) are? What about
others?
Is r2 package planned to be dropped/replaced with icas?
Are there any additional ITU CAS related packages/documents not listed
in original Christian's email?
Are there any other CAS packages planned?

Thanks
        Aleks

At 05:26 PM 4/22/2003, Kevin Boyle wrote:

With all due respect, the IETF had its chance to progress these (and many
other) packages.  In the interests of the larger community, I have taken
the packages to the ITU for standardization, since the IETF does not seem
interested in standardizing any packages.

The work in the IETF is not "up and running".  The drafts published by
Hughes were published after the CAS packages were submitted to the ITU.

Given that the working group is in the process of winding down, I do not
see any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.

Kevin

-----Original Message-----
From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
Sent: Tuesday, April 22, 2003 5:01 PM
To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
Cc: bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support


Christian,

I agree, CAS should be part of the IETF similar to the original MEGACO
draft
work that held both organizations in sync.

/mpd



>From: Aleksandr Ryabin <kengr@winphoria.com>
>To: Christian Groves <Christian.Groves@ericsson.com.au>,
>megaco@ietf.org
>CC: Brad Steinka <bsteinka@telica.com>
>Subject: Re: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 10:30:01 -0400
>
>Hi Christian,
>
>Then why are these brand new revisions of drafts were just recently
>submitted?
>
>http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
>http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
>
>More over a quick look through reveals that some of the package items
>in
>icas
>(ITU) the same as in r2 (IETF) up to the extent of exactly the same
>wording.
>
>Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
>does not seem to be defined in the document and also "conflicts" with
>above IETF "CAS Maintenance Package".
>
>There is also reference to r2 package in AVD-2316 nowhere found in ITU.
>
>Also basic CAS packages draft still available at:
>http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
>2.txt
>but it is slightly different (outdated?) from AVD-2315 ITU version you
have
>specified.
>
>The recent submission of the above drafts had lead me to believe that
>CAS work is still quite "up and running" in IETF. This is all very
>confusing. When was it decided to move the work to ITU? Could someone
>point me out to some references (in IETF) of that please?
>
>My two cents on this topic: CAS is not an isolated package and in my
>opinion
>it would be much more productive to keep it on both channels (ITU and
IETF)
>and in sync, similar to some other items done so far in H.248/MEGACO.
>What other folks think about it?
>
>Also in any case can the authors of ITU and IETF CAS related packages
>work together to come up with some kind of game plan and post it to the
>list to avoid any further confusion and inconsistencies?
>
>Thanks!
>         Aleks
>
>At 07:54 PM 4/21/2003, Christian Groves wrote:
>>G'Day Brad and Karl,
>>
>>I believe the intention is to move the CAS work into the ITU. The
>>contributions
>>containing the latest drafts can be found at:
>>ftp://standard.pictel.com/avc-site/0302_San/
>>
>>AVD-2312        MF Tone Generation and Detection Packages
>>AVD-2315        Basic CAS Packages
>>AVD-2316        International CAS Packages
>>AVD-2317        Enhanced Analog Line Packages
>>
>>Regards, Christian
>>
>>Brad Steinka wrote:
>> >
>> > There were several RFC draft document that described various
>> > packages
>>to
>> > support CAS, R1, R2, BCAS, etc.
>> > Most of these drafts have expired.
>> >
>> > Can anyone tell me what the latest RFCs are that support CAS calls
>> > and
>>where
>> > they are in the standards process?
>> >
>> > Thanks
>> >

>> > Director - Software Engineering
>> > 734 Forest Street, Building G, Suite 100
>> > Marlboro, Ma.   01752
>> > Tel:  508-480-0909  x154
>> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
>> > Web:   www.telica.com <http://www.telica.com>
>> >
>> > _______________________________________________
>> > Megaco mailing list
>> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>>_______________________________________________
>>Megaco mailing list
>>Megaco@ietf.org
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 12:02:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24572
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 12:02:13 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGDL805815;
	Wed, 23 Apr 2003 12:13:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NG3N804241
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 12:03:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24123
	for <megaco@ietf.org>; Wed, 23 Apr 2003 11:50:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198MYV-00051z-00
	for megaco@ietf.org; Wed, 23 Apr 2003 11:53:07 -0400
Received: from gw-4.winphoria.com ([12.105.64.137] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198MYU-00051Q-00
	for megaco@ietf.org; Wed, 23 Apr 2003 11:53:06 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 23 Apr 2003 11:52:56 -0400
Message-Id: <5.2.0.9.0.20030423105458.02c39d80@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 23 Apr 2003 11:49:53 -0400
To: klaha@hss.hns.com, megaco@ietf.org,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: RE: [Megaco] Megaco CAS support
Cc: Michael DiGioia <michaeldigioia@hotmail.com>,
        Christian.Groves@ericsson.com.au, bsteinka@telica.com
In-Reply-To: <OF0BAD0D76.DB0D008A-ON65256D11.00408581@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 23 Apr 2003 15:52:57.0014 (UTC) FILETIME=[68973560:01C309B0]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi,

I just want to say: excellent, just excellent information!
May I suggest including this info (at least the history part) in liaison to 
IETF?

In my opinion the list is the best mediation/discussion point for this case.

I just hope you (CAS pkgs authors) folks can come up with clean solution
and soon. Please remember that since these drafts were out there for a
quite a while I'm sure there are implementations that use them and which would
have to be updated once final solution is published. The longer this question
is "in the air" the more possibilities of incompatibility of different
implementations we will get.

One more question: what is the position of new casmntc package in all that?
Is the idea for it to become "CAS Blocking" package referenced from AVD-2316?
What is the significance of it to be a separate package?
I mean can't it be folded it into bcas package?

Thanks
         Aleks

At 08:11 AM 4/23/2003, klaha@hss.hns.com wrote:

>Let me take this opportunity to present the understanding that Hughes has
>on this topic.
>
>1. It was 3 years back that Hughes first published the r2 draft. It had
>created a
>lot of interest on the list, so much so that it was made a formal MEGACO WG
>item.
>
>2. Hughes followed it up with the r1 package draft. This stirred a lot of
>reaction and
>proactive contribution from the list to make it into a generic CAS package
>draft
>addressing not only r1 but nearly all forms of North American CAS. This
>draft
>was later renamed to manyfolks CAS package draft and included the "bcas"
>package.
>
>3. There was a directive from the list to make r2 a derived package to
>bcas.
>Hughes entered into a dialogue with Nortel (one of the co-authors along
>with Hughes
>to the basic CAS package draft) to make certain modifications in bcas
>package
>so as to enable r2 a true derivative of bcas. It was generally agreed that
>there be
>yet an abstraction package "icas" which derives from "bcas" and "r2" then
>derives
>"icas". ( icas does in no way replace r2)
>
>4. The "icas" package never saw the light of the day at IETF. Hughes went
>ahead
>and resubmitted the "r2" draft aligned as close to the already expired
>"bcas" package
>as possible. The "bcas" package submission was also not refreshed.
>
>5. All of a sudden now we find that "bcas" and "icas" have found entries
>into ITU
>package standardization sector but not "r2". The "icas" package draft was
>also never floated
>to the list for any review.
>
>6. "icas" package submitted to ITU in its present form has flaws.
>
>Given the above background, we clearly need a charter how to move forward
>on
>the CAS package drafts. Hughes generally agrees that the CAS package
>architecture
>should follow the hierarchy "bcas"-->"icas"-->"r2" (with some changes in
>the icas package
>in its present form).
>
>It is to be noted that content-wise whatever is there in the latest r2
>package draft submitted to IETF
>is authentic and requires no modification. An alignment with icas package
>requires certain
>signals/events/properties to be moved out of r2 package and placed in icas.
>
>We are willing to synch the CAS package drafts both at IETF and ITU but
>question is how?
>
>-- Kushanava
>
>
>
>
>
>
>
>
>Aleksandr Ryabin <kengr@winphoria.com>@ietf.org on 04/23/2003 04:34:50 AM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
>cc:    Michael DiGioia <michaeldigioia@hotmail.com>,
>        Christian.Groves@ericsson.com.au, bsteinka@telica.com
>
>Subject:    RE: [Megaco] Megaco CAS support
>
>
>I see the reason to push it through ITU, but we definitely would not want
>to
>see two, or more different packages doing the same thing published one
>through
>IETF and another trough ITU. Thus, since MEGACO is (also) published as
>IETF standard we should at least make every effort to avoid duplication of
>work.
>
>Unfortunately not all of us have direct access (at least direct say) in ITU
>and
>thus at least keeping IETF community informed on progress of MEGACO/H.248
>related work would be very useful, as well as using this list for various
>discussions.
>In fact AVD-2345 contains the following statement regarding H.248.mf
>packages:
>"It was suggested that we send a liaison to the IESG and MEGACO proposing
>this move and asking if this presents a problem to either of them.  Mr
>Boyle
>will draft a liaison for our consideration.  If we do not receive an
>objection from
>them we will progress these with a goal of consent in May.  The liaison
>appears
>as TD-20a." Should then the r2 package also be included in same liaison?
>
>As far as I remember "CAS packages published by Hughes" are new revisions
>of the drafts that were published a long time ago (at least for r2). This
>very fact
>that new revisions were published despite the CAS work moved to ITU
>indicates
>the lack of communication.
>
>Can I suggest to put some wording on WG charter home page regarding
>each work "moved" to ITU (links to liaisons?) and maybe at least some kind
>of sense of ITU schedule for that work? I know there is wording already
>about
>IETF position related to packages, but still info would be very useful.
>At least a pointer to latest up to date "packages guide" (AVD-2294) might
>be
>sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph
>from
>AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)
>
>In any case could you please outline an ITU schedule for CAS related
>packages?
>What is the verdict for CAS drafts published in IETF? Are they going to be
>folded
>into ITU work? I guess at least some of them (by Nortel) are? What about
>others?
>Is r2 package planned to be dropped/replaced with icas?
>Are there any additional ITU CAS related packages/documents not listed
>in original Christian's email?
>Are there any other CAS packages planned?
>
>Thanks
>         Aleks
>
>At 05:26 PM 4/22/2003, Kevin Boyle wrote:
>
>With all due respect, the IETF had its chance to progress these (and many
>other) packages.  In the interests of the larger community, I have taken
>the packages to the ITU for standardization, since the IETF does not seem
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do not
>see any benefit to anyone in continuing to allow the IETF to hold up
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO
>draft
>work that held both organizations in sync.
>
>/mpd
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you
>have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and
>IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
>
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>htt

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 12:03:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24607
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 12:03:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NGFO506043
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 12:15:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGFN806040
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 12:15:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24596
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 12:02:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Mk7-00057k-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 12:05:07 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Mk6-00057h-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 12:05:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NGDL805815;
	Wed, 23 Apr 2003 12:13:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NG3N804241
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 12:03:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24123
	for <megaco@ietf.org>; Wed, 23 Apr 2003 11:50:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198MYV-00051z-00
	for megaco@ietf.org; Wed, 23 Apr 2003 11:53:07 -0400
Received: from gw-4.winphoria.com ([12.105.64.137] helo=bos-exch01.winphoria.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198MYU-00051Q-00
	for megaco@ietf.org; Wed, 23 Apr 2003 11:53:06 -0400
Received: from smilevm.winphoria.com ([10.0.1.162]) by bos-exch01.winphoria.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 23 Apr 2003 11:52:56 -0400
Message-Id: <5.2.0.9.0.20030423105458.02c39d80@imap.winphoria.com>
X-Sender: kengr@imap.winphoria.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 23 Apr 2003 11:49:53 -0400
To: klaha@hss.hns.com, megaco@ietf.org,
        "Kevin Boyle" <kboyle@nortelnetworks.com>
From: Aleksandr Ryabin <kengr@winphoria.com>
Subject: RE: [Megaco] Megaco CAS support
Cc: Michael DiGioia <michaeldigioia@hotmail.com>,
        Christian.Groves@ericsson.com.au, bsteinka@telica.com
In-Reply-To: <OF0BAD0D76.DB0D008A-ON65256D11.00408581@hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 23 Apr 2003 15:52:57.0014 (UTC) FILETIME=[68973560:01C309B0]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Hi,

I just want to say: excellent, just excellent information!
May I suggest including this info (at least the history part) in liaison to 
IETF?

In my opinion the list is the best mediation/discussion point for this case.

I just hope you (CAS pkgs authors) folks can come up with clean solution
and soon. Please remember that since these drafts were out there for a
quite a while I'm sure there are implementations that use them and which would
have to be updated once final solution is published. The longer this question
is "in the air" the more possibilities of incompatibility of different
implementations we will get.

One more question: what is the position of new casmntc package in all that?
Is the idea for it to become "CAS Blocking" package referenced from AVD-2316?
What is the significance of it to be a separate package?
I mean can't it be folded it into bcas package?

Thanks
         Aleks

At 08:11 AM 4/23/2003, klaha@hss.hns.com wrote:

>Let me take this opportunity to present the understanding that Hughes has
>on this topic.
>
>1. It was 3 years back that Hughes first published the r2 draft. It had
>created a
>lot of interest on the list, so much so that it was made a formal MEGACO WG
>item.
>
>2. Hughes followed it up with the r1 package draft. This stirred a lot of
>reaction and
>proactive contribution from the list to make it into a generic CAS package
>draft
>addressing not only r1 but nearly all forms of North American CAS. This
>draft
>was later renamed to manyfolks CAS package draft and included the "bcas"
>package.
>
>3. There was a directive from the list to make r2 a derived package to
>bcas.
>Hughes entered into a dialogue with Nortel (one of the co-authors along
>with Hughes
>to the basic CAS package draft) to make certain modifications in bcas
>package
>so as to enable r2 a true derivative of bcas. It was generally agreed that
>there be
>yet an abstraction package "icas" which derives from "bcas" and "r2" then
>derives
>"icas". ( icas does in no way replace r2)
>
>4. The "icas" package never saw the light of the day at IETF. Hughes went
>ahead
>and resubmitted the "r2" draft aligned as close to the already expired
>"bcas" package
>as possible. The "bcas" package submission was also not refreshed.
>
>5. All of a sudden now we find that "bcas" and "icas" have found entries
>into ITU
>package standardization sector but not "r2". The "icas" package draft was
>also never floated
>to the list for any review.
>
>6. "icas" package submitted to ITU in its present form has flaws.
>
>Given the above background, we clearly need a charter how to move forward
>on
>the CAS package drafts. Hughes generally agrees that the CAS package
>architecture
>should follow the hierarchy "bcas"-->"icas"-->"r2" (with some changes in
>the icas package
>in its present form).
>
>It is to be noted that content-wise whatever is there in the latest r2
>package draft submitted to IETF
>is authentic and requires no modification. An alignment with icas package
>requires certain
>signals/events/properties to be moved out of r2 package and placed in icas.
>
>We are willing to synch the CAS package drafts both at IETF and ITU but
>question is how?
>
>-- Kushanava
>
>
>
>
>
>
>
>
>Aleksandr Ryabin <kengr@winphoria.com>@ietf.org on 04/23/2003 04:34:50 AM
>
>Sent by:    megaco-admin@ietf.org
>
>
>To:    megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
>cc:    Michael DiGioia <michaeldigioia@hotmail.com>,
>        Christian.Groves@ericsson.com.au, bsteinka@telica.com
>
>Subject:    RE: [Megaco] Megaco CAS support
>
>
>I see the reason to push it through ITU, but we definitely would not want
>to
>see two, or more different packages doing the same thing published one
>through
>IETF and another trough ITU. Thus, since MEGACO is (also) published as
>IETF standard we should at least make every effort to avoid duplication of
>work.
>
>Unfortunately not all of us have direct access (at least direct say) in ITU
>and
>thus at least keeping IETF community informed on progress of MEGACO/H.248
>related work would be very useful, as well as using this list for various
>discussions.
>In fact AVD-2345 contains the following statement regarding H.248.mf
>packages:
>"It was suggested that we send a liaison to the IESG and MEGACO proposing
>this move and asking if this presents a problem to either of them.  Mr
>Boyle
>will draft a liaison for our consideration.  If we do not receive an
>objection from
>them we will progress these with a goal of consent in May.  The liaison
>appears
>as TD-20a." Should then the r2 package also be included in same liaison?
>
>As far as I remember "CAS packages published by Hughes" are new revisions
>of the drafts that were published a long time ago (at least for r2). This
>very fact
>that new revisions were published despite the CAS work moved to ITU
>indicates
>the lack of communication.
>
>Can I suggest to put some wording on WG charter home page regarding
>each work "moved" to ITU (links to liaisons?) and maybe at least some kind
>of sense of ITU schedule for that work? I know there is wording already
>about
>IETF position related to packages, but still info would be very useful.
>At least a pointer to latest up to date "packages guide" (AVD-2294) might
>be
>sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph
>from
>AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)
>
>In any case could you please outline an ITU schedule for CAS related
>packages?
>What is the verdict for CAS drafts published in IETF? Are they going to be
>folded
>into ITU work? I guess at least some of them (by Nortel) are? What about
>others?
>Is r2 package planned to be dropped/replaced with icas?
>Are there any additional ITU CAS related packages/documents not listed
>in original Christian's email?
>Are there any other CAS packages planned?
>
>Thanks
>         Aleks
>
>At 05:26 PM 4/22/2003, Kevin Boyle wrote:
>
>With all due respect, the IETF had its chance to progress these (and many
>other) packages.  In the interests of the larger community, I have taken
>the packages to the ITU for standardization, since the IETF does not seem
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do not
>see any benefit to anyone in continuing to allow the IETF to hold up
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO
>draft
>work that held both organizations in sync.
>
>/mpd
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you
>have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and
>IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
>
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>htt

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 13:16:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26802
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 13:16:03 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHRI811466;
	Wed, 23 Apr 2003 13:27:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MMvh818188
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 18:57:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00606
	for <megaco@ietf.org>; Tue, 22 Apr 2003 18:45:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1986YG-00066F-00
	for megaco@ietf.org; Tue, 22 Apr 2003 18:47:48 -0400
Received: from f8.law14.hotmail.com ([64.4.21.8] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1986YG-000666-00
	for megaco@ietf.org; Tue, 22 Apr 2003 18:47:48 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 22 Apr 2003 15:47:41 -0700
Received: from 151.203.212.231 by lw14fd.law14.hotmail.msn.com with HTTP;
	Tue, 22 Apr 2003 22:47:41 GMT
X-Originating-IP: [151.203.212.231]
X-Originating-Email: [michaeldigioia@hotmail.com]
From: "Michael DiGioia" <michaeldigioia@hotmail.com>
To: kboyle@nortelnetworks.com, kengr@winphoria.com,
        Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support
Date: Tue, 22 Apr 2003 18:47:41 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law14-F8vA9bbbJXncn00005d53@hotmail.com>
X-OriginalArrivalTime: 22 Apr 2003 22:47:41.0770 (UTC) FILETIME=[2EA5E2A0:01C30921]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Kevin,

>>IETF does not seem interested in standardizing any packages.

I don't believe I understand your comment. For many years the IETF has had a 
well know process of making protocols into drafts and then into approved 
standard RFC specifications. Do you imply by this that we should trash IETF? 
I would think not since we produced the Internet as it exists today.

>From a telephony standpoint, I think I can see your point since the ITU is 
the standards body for the telephony world. However, its a closed 
organization that tends to be run by the large telephone companies - i.e., 
not open to world participation without the necessary fees.

This whole idea was accepted by this group back in 99/00 to have concurrent 
standards. Are we all now in agreement that this was a mistake? I was with 
the minority then against this idea and for a quick standard, produced by 
only the IETF, since this is how we (IETF) have been so successful in the 
past.

I produced for my company the first IpTelephone which was at the first 
Bakeoff in NH. However, by that time, the idea of an IpTelephone using the 
media gateway protocols was not accepted by the larger community.

Where is Vince, Tom, and Brian now?

/mpd






>From: "Kevin Boyle" <kboyle@nortelnetworks.com>
>To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,   
>Christian.Groves@ericsson.com.au, megaco@ietf.org
>CC: bsteinka@telica.com
>Subject: RE: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 17:26:15 -0400
>
>With all due respect, the IETF had its chance to progress these (and many
>other) packages.  In the interests of the larger community, I have taken 
>the
>packages to the ITU for standardization, since the IETF does not seem
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do not 
>see
>any benefit to anyone in continuing to allow the IETF to hold up
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO 
>draft
>
>work that held both organizations in sync.
>
>/mpd
>
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you 
>have
>
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and 
>IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 13:16:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26845
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 13:16:35 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NHSgx11534
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 13:28:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHSg811531
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 13:28:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26818
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 13:16:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Nt2-0005gB-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 13:18:24 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Nt1-0005g8-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 13:18:23 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHRI811466;
	Wed, 23 Apr 2003 13:27:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MMvh818188
	for <megaco@optimus.ietf.org>; Tue, 22 Apr 2003 18:57:43 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00606
	for <megaco@ietf.org>; Tue, 22 Apr 2003 18:45:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1986YG-00066F-00
	for megaco@ietf.org; Tue, 22 Apr 2003 18:47:48 -0400
Received: from f8.law14.hotmail.com ([64.4.21.8] helo=hotmail.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1986YG-000666-00
	for megaco@ietf.org; Tue, 22 Apr 2003 18:47:48 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 22 Apr 2003 15:47:41 -0700
Received: from 151.203.212.231 by lw14fd.law14.hotmail.msn.com with HTTP;
	Tue, 22 Apr 2003 22:47:41 GMT
X-Originating-IP: [151.203.212.231]
X-Originating-Email: [michaeldigioia@hotmail.com]
From: "Michael DiGioia" <michaeldigioia@hotmail.com>
To: kboyle@nortelnetworks.com, kengr@winphoria.com,
        Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support
Date: Tue, 22 Apr 2003 18:47:41 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law14-F8vA9bbbJXncn00005d53@hotmail.com>
X-OriginalArrivalTime: 22 Apr 2003 22:47:41.0770 (UTC) FILETIME=[2EA5E2A0:01C30921]
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Kevin,

>>IETF does not seem interested in standardizing any packages.

I don't believe I understand your comment. For many years the IETF has had a 
well know process of making protocols into drafts and then into approved 
standard RFC specifications. Do you imply by this that we should trash IETF? 
I would think not since we produced the Internet as it exists today.

>From a telephony standpoint, I think I can see your point since the ITU is 
the standards body for the telephony world. However, its a closed 
organization that tends to be run by the large telephone companies - i.e., 
not open to world participation without the necessary fees.

This whole idea was accepted by this group back in 99/00 to have concurrent 
standards. Are we all now in agreement that this was a mistake? I was with 
the minority then against this idea and for a quick standard, produced by 
only the IETF, since this is how we (IETF) have been so successful in the 
past.

I produced for my company the first IpTelephone which was at the first 
Bakeoff in NH. However, by that time, the idea of an IpTelephone using the 
media gateway protocols was not accepted by the larger community.

Where is Vince, Tom, and Brian now?

/mpd






>From: "Kevin Boyle" <kboyle@nortelnetworks.com>
>To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,   
>Christian.Groves@ericsson.com.au, megaco@ietf.org
>CC: bsteinka@telica.com
>Subject: RE: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 17:26:15 -0400
>
>With all due respect, the IETF had its chance to progress these (and many
>other) packages.  In the interests of the larger community, I have taken 
>the
>packages to the ITU for standardization, since the IETF does not seem
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do not 
>see
>any benefit to anyone in continuing to allow the IETF to hold up
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO 
>draft
>
>work that held both organizations in sync.
>
>/mpd
>
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you 
>have
>
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and 
>IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 13:27:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27290
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 13:27:22 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHch812915;
	Wed, 23 Apr 2003 13:38:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHYs811920
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 13:34:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27128
	for <megaco@ietf.org>; Wed, 23 Apr 2003 13:22:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Nz1-0005kp-00
	for megaco@ietf.org; Wed, 23 Apr 2003 13:24:35 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Nz1-0005kW-00
	for megaco@ietf.org; Wed, 23 Apr 2003 13:24:35 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NHOO806452
	for <megaco@ietf.org>; Wed, 23 Apr 2003 13:24:25 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J961NBC>; Wed, 23 Apr 2003 13:24:25 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E4A5BD@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,
        Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support
Date: Wed, 23 Apr 2003 13:24:16 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] 
Sent: Tuesday, April 22, 2003 6:48 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; kengr@winphoria.com;
Christian.Groves@ericsson.com.au; megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support


Kevin,

>>IETF does not seem interested in standardizing any packages.

I don't believe I understand your comment. For many years the IETF has had a

well know process of making protocols into drafts and then into approved 
standard RFC specifications. Do you imply by this that we should trash IETF?

I would think not since we produced the Internet as it exists today.

[KJBII] Note that I am talking specifically about H.248 packages, not the
general WG process of creating protocols.  The IETF has had ample
opportunity to standardize MANY H.248 packages.  We would send them to the
IESG for approval as an RFC, only to have the FORMATTING criticized (but no
comments about the TECHNICAL content).  Some of these packages have
languished for over TWO YEARS.  Does this sound like the IETF is interested
in standardizing H.248 packages?

>From a telephony standpoint, I think I can see your point since the ITU is 
the standards body for the telephony world. However, its a closed 
organization that tends to be run by the large telephone companies - i.e., 
not open to world participation without the necessary fees.

[KJBII] The working group interests are always represented at the ITU
meetings.  Case in point: the proposed Context Attributes Descriptor was not
included in v2, solely because of the list feelings on the matter.

This whole idea was accepted by this group back in 99/00 to have concurrent 
standards. Are we all now in agreement that this was a mistake? I was with 
the minority then against this idea and for a quick standard, produced by 
only the IETF, since this is how we (IETF) have been so successful in the 
past.

[KJBII] The Megaco WG is coming to an end.  Part of the reason is because
there has been no work coming out of the WG for at least the last year.  I
believe the plan is that H.248 will continue to be dually published.

I produced for my company the first IpTelephone which was at the first 
Bakeoff in NH. However, by that time, the idea of an IpTelephone using the 
media gateway protocols was not accepted by the larger community.

[KJBII] Hmmm.  The IPPhone packages are published in H.248.3 by the ITU...

Where is Vince, Tom, and Brian now?

[KJBII] Tom is out of the office for the next couple of weeks due to
personal reasons.  He can address all this when he gets back.  Brian, from
my understanding, has a different focus these days, and doesn't have as much
interest in H.248 as he used to.  I'm not sure who Vince is...

/mpd






>From: "Kevin Boyle" <kboyle@nortelnetworks.com>
>To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,   
>Christian.Groves@ericsson.com.au, megaco@ietf.org
>CC: bsteinka@telica.com
>Subject: RE: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 17:26:15 -0400
>
>With all due respect, the IETF had its chance to progress these (and 
>many
>other) packages.  In the interests of the larger community, I have taken 
>the
>packages to the ITU for standardization, since the IETF does not seem
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by 
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do 
>not
>see
>any benefit to anyone in continuing to allow the IETF to hold up
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; 
>megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO
>draft
>
>work that held both organizations in sync.
>
>/mpd
>
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently 
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.tx
> >t
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items 
> >in icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary 
> >which does not seem to be defined in the document and also 
> >"conflicts" with above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in 
> >ITU.
> >
> >Also basic CAS packages draft still available at: 
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage
> >-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you 
>have
>
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that 
> >CAS work is still quite "up and running" in IETF. This is all very 
> >confusing. When was it decided to move the work to ITU? Could someone 
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my 
> >opinion it would be much more productive to keep it on both channels 
> >(ITU and
>IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO. 
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages 
> >work together to come up with some kind of game plan and post it to 
> >the list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The 
> >>contributions containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various 
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS 
> >> > calls and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE* 
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 13:28:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27338
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 13:28:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NHeZW13026
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 13:40:35 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHeZ813023
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 13:40:35 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27325
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 13:27:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198O4X-0005n3-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 13:30:17 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198O4X-0005n0-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 13:30:17 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHch812915;
	Wed, 23 Apr 2003 13:38:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NHYs811920
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 13:34:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27128
	for <megaco@ietf.org>; Wed, 23 Apr 2003 13:22:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Nz1-0005kp-00
	for megaco@ietf.org; Wed, 23 Apr 2003 13:24:35 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Nz1-0005kW-00
	for megaco@ietf.org; Wed, 23 Apr 2003 13:24:35 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NHOO806452
	for <megaco@ietf.org>; Wed, 23 Apr 2003 13:24:25 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J961NBC>; Wed, 23 Apr 2003 13:24:25 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E4A5BD@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,
        Christian.Groves@ericsson.com.au, megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support
Date: Wed, 23 Apr 2003 13:24:16 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Michael DiGioia [mailto:michaeldigioia@hotmail.com] 
Sent: Tuesday, April 22, 2003 6:48 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; kengr@winphoria.com;
Christian.Groves@ericsson.com.au; megaco@ietf.org
Cc: bsteinka@telica.com
Subject: RE: [Megaco] Megaco CAS support


Kevin,

>>IETF does not seem interested in standardizing any packages.

I don't believe I understand your comment. For many years the IETF has had a

well know process of making protocols into drafts and then into approved 
standard RFC specifications. Do you imply by this that we should trash IETF?

I would think not since we produced the Internet as it exists today.

[KJBII] Note that I am talking specifically about H.248 packages, not the
general WG process of creating protocols.  The IETF has had ample
opportunity to standardize MANY H.248 packages.  We would send them to the
IESG for approval as an RFC, only to have the FORMATTING criticized (but no
comments about the TECHNICAL content).  Some of these packages have
languished for over TWO YEARS.  Does this sound like the IETF is interested
in standardizing H.248 packages?

>From a telephony standpoint, I think I can see your point since the ITU is 
the standards body for the telephony world. However, its a closed 
organization that tends to be run by the large telephone companies - i.e., 
not open to world participation without the necessary fees.

[KJBII] The working group interests are always represented at the ITU
meetings.  Case in point: the proposed Context Attributes Descriptor was not
included in v2, solely because of the list feelings on the matter.

This whole idea was accepted by this group back in 99/00 to have concurrent 
standards. Are we all now in agreement that this was a mistake? I was with 
the minority then against this idea and for a quick standard, produced by 
only the IETF, since this is how we (IETF) have been so successful in the 
past.

[KJBII] The Megaco WG is coming to an end.  Part of the reason is because
there has been no work coming out of the WG for at least the last year.  I
believe the plan is that H.248 will continue to be dually published.

I produced for my company the first IpTelephone which was at the first 
Bakeoff in NH. However, by that time, the idea of an IpTelephone using the 
media gateway protocols was not accepted by the larger community.

[KJBII] Hmmm.  The IPPhone packages are published in H.248.3 by the ITU...

Where is Vince, Tom, and Brian now?

[KJBII] Tom is out of the office for the next couple of weeks due to
personal reasons.  He can address all this when he gets back.  Brian, from
my understanding, has a different focus these days, and doesn't have as much
interest in H.248 as he used to.  I'm not sure who Vince is...

/mpd






>From: "Kevin Boyle" <kboyle@nortelnetworks.com>
>To: Michael DiGioia <michaeldigioia@hotmail.com>, kengr@winphoria.com,   
>Christian.Groves@ericsson.com.au, megaco@ietf.org
>CC: bsteinka@telica.com
>Subject: RE: [Megaco] Megaco CAS support
>Date: Tue, 22 Apr 2003 17:26:15 -0400
>
>With all due respect, the IETF had its chance to progress these (and 
>many
>other) packages.  In the interests of the larger community, I have taken 
>the
>packages to the ITU for standardization, since the IETF does not seem
>interested in standardizing any packages.
>
>The work in the IETF is not "up and running".  The drafts published by 
>Hughes were published after the CAS packages were submitted to the ITU.
>
>Given that the working group is in the process of winding down, I do 
>not
>see
>any benefit to anyone in continuing to allow the IETF to hold up
>standardization when the ITU is prepared to consider and advance the work.
>
>Kevin
>
>-----Original Message-----
>From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
>Sent: Tuesday, April 22, 2003 5:01 PM
>To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; 
>megaco@ietf.org
>Cc: bsteinka@telica.com
>Subject: Re: [Megaco] Megaco CAS support
>
>
>
>Christian,
>
>I agree, CAS should be part of the IETF similar to the original MEGACO
>draft
>
>work that held both organizations in sync.
>
>/mpd
>
>
>
>
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently 
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.tx
> >t
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items 
> >in icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary 
> >which does not seem to be defined in the document and also 
> >"conflicts" with above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in 
> >ITU.
> >
> >Also basic CAS packages draft still available at: 
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage
> >-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you 
>have
>
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that 
> >CAS work is still quite "up and running" in IETF. This is all very 
> >confusing. When was it decided to move the work to ITU? Could someone 
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my 
> >opinion it would be much more productive to keep it on both channels 
> >(ITU and
>IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO. 
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages 
> >work together to come up with some kind of game plan and post it to 
> >the list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The 
> >>contributions containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various 
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS 
> >> > calls and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> >> > Brad Steinka
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE* 
>http://join.msn.com/?page=features/virus
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 14:17:35 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28789
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 14:17:35 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NITJ815901;
	Wed, 23 Apr 2003 14:29:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIO2815693
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 14:24:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28589
	for <megaco@ietf.org>; Wed, 23 Apr 2003 14:11:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OkZ-00062n-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:13:43 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 198OkY-00062k-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:13:42 -0400
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3NIE7I3008487;
	Wed, 23 Apr 2003 20:14:07 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JN9WB2P4; Wed, 23 Apr 2003 20:14:09 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3NIE9R6004656;
	Wed, 23 Apr 2003 21:14:09 +0300 (EET DST)
Message-ID: <3EA6D82E.48A9D362@lmf.ericsson.se>
Date: Wed, 23 Apr 2003 21:15:10 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: ksrini@winphoria.com, Tom-PT Taylor <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations
References: <ABA227A15B80D511BD1A00508BF93A1C08BE9BE3@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Hi Kevin,

> The argument can be made that the resources were previously seized via an
> Add.

Yes, but because of the handover the resources were not seized by the same
MGC. The text says that the MGC can release/modify termination resources IT
seized.

I think the important thing is that the release/modification can be done by
the MGC currently controlling those resources.

Regards,

Christer Holmberg
Ericsson Finland





>  I will look back through some older IGs and see if I can find where
> this came from...
>
> Kevin
>
> -----Original Message-----
> From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com]
> Sent: Tuesday, April 15, 2003 1:34 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Restriction on Modification Of Terminations
>
> Hi,
>
> What happens in the case where a Handoff to a redundant MGC has happened,
> but the contexts where originally created by a
> primary MGC.
>
> So, shouldn't we actually allow Subtracts from the new MGC,
> as well then?
>
> Thanks,
> -Srini
>
> On Tue, 15 Apr 2003, Kevin Boyle wrote:
>
> kboyle>Clearly this is an error, since, for example, the MG wouldn't
> kboyle>want a phone in a context just to detect off-hook.  Likewise, if
> kboyle>that set is currently in Null and looking for off-hook, then the
> kboyle>MGC may wish to stop looking for off-hook (for any of a number of
> kboyle>reasons) by Modifying the term with an empty Events descriptor.
> kboyle>
> kboyle>Any objections to striking the "/modify" portion of the sentence
> kboyle>via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>-----Original Message-----
> kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> kboyle>To: megaco@ietf.org
> kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> kboyle>
> kboyle>
> kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e.
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At
> kboyle>the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>"An MGC can only release/modify Terminations
> kboyle>    and the resources that the Termination represents which it has
> kboyle>    previously seized via, e.g., the Add command."
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL context,
> kboyle>but I've seen various call flows that do just that.  Should we
> kboyle>feed this back to SG 16 as something that should be fixed up to
> kboyle>conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org
> kboyle>https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 14:18:40 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28878
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 14:18:40 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NIUmN16032
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 14:30:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIUm816029
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 14:30:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28840
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 14:18:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198Or7-000664-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 14:20:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198Or6-000661-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 14:20:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NITJ815901;
	Wed, 23 Apr 2003 14:29:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIO2815693
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 14:24:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28589
	for <megaco@ietf.org>; Wed, 23 Apr 2003 14:11:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198OkZ-00062n-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:13:43 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se)
	by ietf-mx with esmtp (Exim 4.12)
	id 198OkY-00062k-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:13:42 -0400
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3NIE7I3008487;
	Wed, 23 Apr 2003 20:14:07 +0200 (MEST)
Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id JN9WB2P4; Wed, 23 Apr 2003 20:14:09 +0200
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3NIE9R6004656;
	Wed, 23 Apr 2003 21:14:09 +0300 (EET DST)
Message-ID: <3EA6D82E.48A9D362@lmf.ericsson.se>
Date: Wed, 23 Apr 2003 21:15:10 +0300
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: ksrini@winphoria.com, Tom-PT Taylor <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations
References: <ABA227A15B80D511BD1A00508BF93A1C08BE9BE3@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Hi Kevin,

> The argument can be made that the resources were previously seized via an
> Add.

Yes, but because of the handover the resources were not seized by the same
MGC. The text says that the MGC can release/modify termination resources IT
seized.

I think the important thing is that the release/modification can be done by
the MGC currently controlling those resources.

Regards,

Christer Holmberg
Ericsson Finland





>  I will look back through some older IGs and see if I can find where
> this came from...
>
> Kevin
>
> -----Original Message-----
> From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com]
> Sent: Tuesday, April 15, 2003 1:34 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Restriction on Modification Of Terminations
>
> Hi,
>
> What happens in the case where a Handoff to a redundant MGC has happened,
> but the contexts where originally created by a
> primary MGC.
>
> So, shouldn't we actually allow Subtracts from the new MGC,
> as well then?
>
> Thanks,
> -Srini
>
> On Tue, 15 Apr 2003, Kevin Boyle wrote:
>
> kboyle>Clearly this is an error, since, for example, the MG wouldn't
> kboyle>want a phone in a context just to detect off-hook.  Likewise, if
> kboyle>that set is currently in Null and looking for off-hook, then the
> kboyle>MGC may wish to stop looking for off-hook (for any of a number of
> kboyle>reasons) by Modifying the term with an empty Events descriptor.
> kboyle>
> kboyle>Any objections to striking the "/modify" portion of the sentence
> kboyle>via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>-----Original Message-----
> kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> kboyle>To: megaco@ietf.org
> kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> kboyle>
> kboyle>
> kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e.
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At
> kboyle>the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>"An MGC can only release/modify Terminations
> kboyle>    and the resources that the Termination represents which it has
> kboyle>    previously seized via, e.g., the Add command."
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL context,
> kboyle>but I've seen various call flows that do just that.  Should we
> kboyle>feed this back to SG 16 as something that should be fixed up to
> kboyle>conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org
> kboyle>https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 14:35:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29651
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 14:35:18 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIkk817918;
	Wed, 23 Apr 2003 14:46:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIgA817702
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 14:42:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29449
	for <megaco@ietf.org>; Wed, 23 Apr 2003 14:29:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198P26-0006Ck-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:31:50 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 198P26-0006CR-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:31:50 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NIVeR11259;
	Wed, 23 Apr 2003 14:31:40 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J961PGB>; Wed, 23 Apr 2003 14:31:41 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E4A814@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com.au>
Cc: ksrini@winphoria.com, "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
Date: Wed, 23 Apr 2003 14:31:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C309C6.90A9AA5E"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C309C6.90A9AA5E
Content-Type: text/plain

Since I haven't seen any objections to this wording, I will include it in
the IG for May's SG16 meeting.

Kevin

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] 
Sent: Tuesday, April 15, 2003 8:19 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: ksrini@winphoria.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations


G'Day Kevin,

The text has been there from way back when we determined H.248 version 1. It
seems noone has paid attention to it since then!!!

How about adding:
An MGC can only release/modify terminations and the resources that the
termination represents <<which are in the NULL context or>> which
>>delete:it has<< <<have been>> previously seized via, e.g., the Add
command.

The removal of "it has" should cover the servicechange concern.

Regards, Christian

Kevin Boyle wrote:
> 
> The argument can be made that the resources were previously seized via 
> an Add.  I will look back through some older IGs and see if I can find 
> where this came from...
> 
> Kevin
> 
> -----Original Message-----
> From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com]
> Sent: Tuesday, April 15, 2003 1:34 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Restriction on Modification Of Terminations
> 
> Hi,
> 
> What happens in the case where a Handoff to a redundant MGC has 
> happened, but the contexts where originally created by a primary MGC.
> 
> So, shouldn't we actually allow Subtracts from the new MGC, as well 
> then?
> 
> Thanks,
> -Srini
> 
> On Tue, 15 Apr 2003, Kevin Boyle wrote:
> 
> kboyle>Clearly this is an error, since, for example, the MG wouldn't 
> kboyle>want a phone in a context just to detect off-hook.  Likewise, 
> kboyle>if that set is currently in Null and looking for off-hook, then 
> kboyle>the MGC may wish to stop looking for off-hook (for any of a 
> kboyle>number of
> kboyle>reasons) by Modifying the term with an empty Events descriptor.
> kboyle>
> kboyle>Any objections to striking the "/modify" portion of the 
> kboyle>sentence via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>-----Original Message-----
> kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> kboyle>To: megaco@ietf.org
> kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> kboyle>
> kboyle>
> kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. 
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  
> kboyle>At the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>"An MGC can only release/modify Terminations
> kboyle>    and the resources that the Termination represents which it has
> kboyle>    previously seized via, e.g., the Add command."
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL 
> kboyle>context, but I've seen various call flows that do just that.  
> kboyle>Should we feed this back to SG 16 as something that should be 
> kboyle>fixed up to conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco



------_=_NextPart_001_01C309C6.90A9AA5E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Restriction on Modification Of Terminations</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Since I haven't seen any objections to this wording, =
I will include it in the IG for May's SG16 meeting.</FONT>
</P>

<P><FONT SIZE=3D2>Kevin</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com.au">mailto:Christian.Groves=
@ericsson.com.au</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 15, 2003 8:19 PM</FONT>
<BR><FONT SIZE=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: ksrini@winphoria.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Restriction on Modification Of =
Terminations</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>G'Day Kevin,</FONT>
</P>

<P><FONT SIZE=3D2>The text has been there from way back when we =
determined H.248 version 1. It seems noone has paid attention to it =
since then!!!</FONT></P>

<P><FONT SIZE=3D2>How about adding:</FONT>
<BR><FONT SIZE=3D2>An MGC can only release/modify terminations and the =
resources that the termination represents &lt;&lt;which are in the NULL =
context or&gt;&gt; which &gt;&gt;delete:it has&lt;&lt; &lt;&lt;have =
been&gt;&gt; previously seized via, e.g., the Add command.</FONT></P>

<P><FONT SIZE=3D2>The removal of &quot;it has&quot; should cover the =
servicechange concern.</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Christian</FONT>
</P>

<P><FONT SIZE=3D2>Kevin Boyle wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The argument can be made that the resources =
were previously seized via </FONT>
<BR><FONT SIZE=3D2>&gt; an Add.&nbsp; I will look back through some =
older IGs and see if I can find </FONT>
<BR><FONT SIZE=3D2>&gt; where this came from...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Srinivasan Krishnamoorthy [<A =
HREF=3D"mailto:ksrini@winphoria.com">mailto:ksrini@winphoria.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 15, 2003 1:34 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Megaco] Restriction on =
Modification Of Terminations</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What happens in the case where a Handoff to a =
redundant MGC has </FONT>
<BR><FONT SIZE=3D2>&gt; happened, but the contexts where originally =
created by a primary MGC.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, shouldn't we actually allow Subtracts from =
the new MGC, as well </FONT>
<BR><FONT SIZE=3D2>&gt; then?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; -Srini</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, 15 Apr 2003, Kevin Boyle wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Clearly this is an error, since, for =
example, the MG wouldn't </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;want a phone in a context just to =
detect off-hook.&nbsp; Likewise, </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;if that set is currently in Null and =
looking for off-hook, then </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;the MGC may wish to stop looking for =
off-hook (for any of a </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;number of</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;reasons) by Modifying the term with =
an empty Events descriptor.</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Any objections to striking the =
&quot;/modify&quot; portion of the </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;sentence via the IG?</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;From: Taylor, Tom-PT =
[CAR:5N00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Sent: Tuesday, April 15, 2003 11:02 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Subject: [Megaco] Restriction on =
Modification Of Terminations</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;I've just been proof-reading the =
replacement for RFC 3015 (i.e. </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;H.248.1 v1) prior to its release, and =
got a slight surprise.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;At the end of section 6.2.1 there is =
this</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;sentence:</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;&quot;An MGC can only release/modify =
Terminations</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; and the resources =
that the Termination represents which it has</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; previously seized =
via, e.g., the Add command.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;It seems to me this precludes doing =
Modifies in the NULL </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;context, but I've seen various call =
flows that do just that.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Should we feed this back to SG 16 as =
something that should be </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;fixed up to conform with =
practice?</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Tom Taylor</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
kboyle&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco@ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; =
kboyle&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco@ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C309C6.90A9AA5E--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 14:36:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29708
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 14:36:24 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NImXn18015
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 14:48:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NImX818012
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 14:48:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29690
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 14:35:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198P8H-0006EZ-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 14:38:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198P8H-0006EW-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 14:38:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIkk817918;
	Wed, 23 Apr 2003 14:46:46 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NIgA817702
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 14:42:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29449
	for <megaco@ietf.org>; Wed, 23 Apr 2003 14:29:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198P26-0006Ck-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:31:50 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 198P26-0006CR-00
	for megaco@ietf.org; Wed, 23 Apr 2003 14:31:50 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3NIVeR11259;
	Wed, 23 Apr 2003 14:31:40 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J961PGB>; Wed, 23 Apr 2003 14:31:41 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E4A814@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Christian Groves <Christian.Groves@ericsson.com.au>
Cc: ksrini@winphoria.com, "Tom-PT Taylor" <taylor@nortelnetworks.com>,
        megaco@ietf.org
Subject: RE: [Megaco] Restriction on Modification Of Terminations
Date: Wed, 23 Apr 2003 14:31:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C309C6.90A9AA5E"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C309C6.90A9AA5E
Content-Type: text/plain

Since I haven't seen any objections to this wording, I will include it in
the IG for May's SG16 meeting.

Kevin

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] 
Sent: Tuesday, April 15, 2003 8:19 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: ksrini@winphoria.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations


G'Day Kevin,

The text has been there from way back when we determined H.248 version 1. It
seems noone has paid attention to it since then!!!

How about adding:
An MGC can only release/modify terminations and the resources that the
termination represents <<which are in the NULL context or>> which
>>delete:it has<< <<have been>> previously seized via, e.g., the Add
command.

The removal of "it has" should cover the servicechange concern.

Regards, Christian

Kevin Boyle wrote:
> 
> The argument can be made that the resources were previously seized via 
> an Add.  I will look back through some older IGs and see if I can find 
> where this came from...
> 
> Kevin
> 
> -----Original Message-----
> From: Srinivasan Krishnamoorthy [mailto:ksrini@winphoria.com]
> Sent: Tuesday, April 15, 2003 1:34 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: RE: [Megaco] Restriction on Modification Of Terminations
> 
> Hi,
> 
> What happens in the case where a Handoff to a redundant MGC has 
> happened, but the contexts where originally created by a primary MGC.
> 
> So, shouldn't we actually allow Subtracts from the new MGC, as well 
> then?
> 
> Thanks,
> -Srini
> 
> On Tue, 15 Apr 2003, Kevin Boyle wrote:
> 
> kboyle>Clearly this is an error, since, for example, the MG wouldn't 
> kboyle>want a phone in a context just to detect off-hook.  Likewise, 
> kboyle>if that set is currently in Null and looking for off-hook, then 
> kboyle>the MGC may wish to stop looking for off-hook (for any of a 
> kboyle>number of
> kboyle>reasons) by Modifying the term with an empty Events descriptor.
> kboyle>
> kboyle>Any objections to striking the "/modify" portion of the 
> kboyle>sentence via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>-----Original Message-----
> kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> kboyle>To: megaco@ietf.org
> kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> kboyle>
> kboyle>
> kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. 
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  
> kboyle>At the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>"An MGC can only release/modify Terminations
> kboyle>    and the resources that the Termination represents which it has
> kboyle>    previously seized via, e.g., the Add command."
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL 
> kboyle>context, but I've seen various call flows that do just that.  
> kboyle>Should we feed this back to SG 16 as something that should be 
> kboyle>fixed up to conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>_______________________________________________
> kboyle>Megaco mailing list
> kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> kboyle>
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco



------_=_NextPart_001_01C309C6.90A9AA5E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>RE: [Megaco] Restriction on Modification Of Terminations</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Since I haven't seen any objections to this wording, =
I will include it in the IG for May's SG16 meeting.</FONT>
</P>

<P><FONT SIZE=3D2>Kevin</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Christian Groves [<A =
HREF=3D"mailto:Christian.Groves@ericsson.com.au">mailto:Christian.Groves=
@ericsson.com.au</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, April 15, 2003 8:19 PM</FONT>
<BR><FONT SIZE=3D2>To: Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: ksrini@winphoria.com; Taylor, Tom-PT =
[CAR:5N00:EXCH]; megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Megaco] Restriction on Modification Of =
Terminations</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>G'Day Kevin,</FONT>
</P>

<P><FONT SIZE=3D2>The text has been there from way back when we =
determined H.248 version 1. It seems noone has paid attention to it =
since then!!!</FONT></P>

<P><FONT SIZE=3D2>How about adding:</FONT>
<BR><FONT SIZE=3D2>An MGC can only release/modify terminations and the =
resources that the termination represents &lt;&lt;which are in the NULL =
context or&gt;&gt; which &gt;&gt;delete:it has&lt;&lt; &lt;&lt;have =
been&gt;&gt; previously seized via, e.g., the Add command.</FONT></P>

<P><FONT SIZE=3D2>The removal of &quot;it has&quot; should cover the =
servicechange concern.</FONT>
</P>

<P><FONT SIZE=3D2>Regards, Christian</FONT>
</P>

<P><FONT SIZE=3D2>Kevin Boyle wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The argument can be made that the resources =
were previously seized via </FONT>
<BR><FONT SIZE=3D2>&gt; an Add.&nbsp; I will look back through some =
older IGs and see if I can find </FONT>
<BR><FONT SIZE=3D2>&gt; where this came from...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Srinivasan Krishnamoorthy [<A =
HREF=3D"mailto:ksrini@winphoria.com">mailto:ksrini@winphoria.com</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 15, 2003 1:34 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; =
megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Megaco] Restriction on =
Modification Of Terminations</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What happens in the case where a Handoff to a =
redundant MGC has </FONT>
<BR><FONT SIZE=3D2>&gt; happened, but the contexts where originally =
created by a primary MGC.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, shouldn't we actually allow Subtracts from =
the new MGC, as well </FONT>
<BR><FONT SIZE=3D2>&gt; then?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; -Srini</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, 15 Apr 2003, Kevin Boyle wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Clearly this is an error, since, for =
example, the MG wouldn't </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;want a phone in a context just to =
detect off-hook.&nbsp; Likewise, </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;if that set is currently in Null and =
looking for off-hook, then </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;the MGC may wish to stop looking for =
off-hook (for any of a </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;number of</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;reasons) by Modifying the term with =
an empty Events descriptor.</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Any objections to striking the =
&quot;/modify&quot; portion of the </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;sentence via the IG?</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Kevin</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;From: Taylor, Tom-PT =
[CAR:5N00:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Sent: Tuesday, April 15, 2003 11:02 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;To: megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Subject: [Megaco] Restriction on =
Modification Of Terminations</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;I've just been proof-reading the =
replacement for RFC 3015 (i.e. </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;H.248.1 v1) prior to its release, and =
got a slight surprise.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;At the end of section 6.2.1 there is =
this</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;sentence:</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;&quot;An MGC can only release/modify =
Terminations</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; and the resources =
that the Termination represents which it has</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; previously seized =
via, e.g., the Add command.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;It seems to me this precludes doing =
Modifies in the NULL </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;context, but I've seen various call =
flows that do just that.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Should we feed this back to SG 16 as =
something that should be </FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;fixed up to conform with =
practice?</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Tom Taylor</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
kboyle&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco@ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; =
kboyle&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;Megaco@ietf.org <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; kboyle&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; Megaco@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/megaco" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/megaco</A></FON=
T>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C309C6.90A9AA5E--
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 16:42:33 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05943
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 16:42:33 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKi2829707;
	Wed, 23 Apr 2003 16:44:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKdk829528
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 16:39:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05822
	for <megaco@ietf.org>; Wed, 23 Apr 2003 16:36:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198R1S-0007Gr-00
	for megaco@ietf.org; Wed, 23 Apr 2003 16:39:18 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198R1R-0007Gb-00
	for megaco@ietf.org; Wed, 23 Apr 2003 16:39:18 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042315390578:2697 ;
          Wed, 23 Apr 2003 15:39:05 -0500 
Message-ID: <3EA6FB72.8050208@tekelec.com>
Date: Wed, 23 Apr 2003 15:45:38 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com> <3EA6518B.862FDD51@alcatel.es>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 03:39:05 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 03:39:44 PM,
	Serialize complete at 04/23/2003 03:39:44 PM
Content-Type: multipart/alternative;
 boundary="------------000200070601010907030002"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------000200070601010907030002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Fernando,

Thanks for the reply. See comments inline.

Adrian



Fernando Vallejo Lazaro wrote:

> Hi all,
>
> Only some comments.
>
> - You say : "So while talking on A1-A1, the MGC cannot for example 
> audit on A2-A2, because this is immediately considered a failover 
> (...)". I don't think this is true.
> If an MG receives an Audit from MGC-A2 (which it does not know) it 
> will reject the transaction because there is no association 
> established with it.
>
Some MGs do this, others either don't reply or they failover. The latter 
may be in violation of the standard, but I think that's because it's not 
very well explained.

In my case, since I use the audits on A2-A2 as heartbeats (just to check 
for connectivity), any reply is OK, if only I get it. But this is a 
problem if some other MGC really wants to audit and is rejected. By the 
way, MGCP allows for this extra auditing, why is there a difference in 
approach? This only complicates things for an MGC which controls both 
MGCP and MEGACO MGs.

> - If the MG is multi-homed you can provision the two IP static 
> addresses as primary and secondary MGCs. In case one fails it will 
> change to the other IP which in fact is the
> same MGC.
>
Yes, but if the failure (MGCs interface A1) occurs after the initial 
ServiceChange, sometimes during operations when the MG does not have any 
notifications to send, and if the MG does not do any heartbeats, then it 
won't be aware of the failure, it will just think it's idle. So it will 
not initiate ServiceChange to the "alternate" MGC. Furthermore, even if 
the MG receives a new command from MGC A2, as you showed above, it will 
reply with an error and remain idle. (By the way, where in the standard 
is this rule stated?)

> Maybe there should be a deep explanation of how to do this to smooth 
> the process because the MG does not know whether the secondary is an 
> independent
> MGC, a backup or a mirror and depending on this information it can 
> behave in one way or another (e.g. a ServiceChange Request only 
> Informational)
>
Here, I concur with you and with Flemming, there should be more 
explanations. If you take into account multiple IP addresses, DNS names 
translating to one or more IP addresses, MGs and MGCs working in 
active-standby mode with or without complete state synchronization, as 
well as multiple active-standby pairs handoff, things get complicated 
enough to be worth additional explanations.

> - Another thing the MGC can do when it detects the that A1 is going to 
> die is to send a Handoff to the interface A2 for each MG so that the 
> connections are restablished
> in the new path.
>
This is what it's forced to do, but the MG is not aware that the handoff 
is to the same MGC. Consequently, it continues to send pending 
notifications to the old IP address, as per RFC 3015 section 7.2.8 (and 
still in h248v2-04):

"At the same time, as indicated in clause 9, transaction replies and 
pending indications must be sent to the address from which the 
corresponding requests originated."

This forces the "new" MGC (which is not really new) to re-issue all the 
notification requests, which, apart from being a substantial overhead, 
can cause serious race conditions, especially with packages such as 
bcas. Again, from experience, this is a point of contention, whether or 
not it's the right behavior.

If the MG were somehow aware that this is the same MGC, the signaling 
path switchover between A1-A1 and A2-A2 would be faster and more reliable.

I think the MEGACO spec obviously did not consider multi-homed MGs/MGCs, 
therefore we are trying to see if the existing rules "happen to work" in 
this case. I have had a lot of arguments over it because of different 
interpretations.

> Regards
> Fernando
>

Thanks again,

Adrian




> Adrian Soncodi wrote:
>
>> Hello, all,
>>
>> I was wondering what is your oppinion on the following:
>>
>> Another topic that is not addressed in the MEGACO spec is the case of 
>> a multi-homed MG, i.e. an MG where:
>> - the primary controller has 2 physical interfaces A1 and A2, 
>> potentially on 2 different subnets, working in load-sharing mode 
>> (rather than active-standby)
>> - the secondary MG controller can then be either transparrent (it 
>> takes over A1 and A2 on switchover) or non-transparent (has 2 more 
>> physical addresses, B1 and B2).
>>
>> One may argue that multi-homing is not necessary, for example because 
>> you can always assign a single "logical" IP address A that is 
>> reachable over both interfaces A1 and A2. Yes, but this schema 
>> requires some dynamic IP routing capability in the backbone (e.g. to 
>> figure out when A1 is down and packets for A should be routed to A2), 
>> which has a number of disadvantages:
>> - Depending on the routing protocol, the latency for dynamic updates 
>> of the addresses can be very large (180 seconds in case of RIP), 
>> unacceptable for telephony.
>> - Depending on the network topology, interface failures may not 
>> become visible in the backbone. For example, if there is a LAN switch 
>> between the MG and the first router, then the router does not see 
>> when the interface A1 fails (unless the dynamic routing domain is 
>> extended to include the MG, which is not always the case).
>> - Some service providers (especially the smaller ones) do not run a 
>> dynamic IP routing protocol in their (whole) backbone, or they may 
>> not even have a real backbone, for example they may use leased lines, 
>> IP over ATM/FR PVCs with no sophisticated routing capabilities.
>>
>> On the other hand, making the physical addresses A1 and A2 visible 
>> allows for redundant signaling paths to the MG using only static IP 
>> routing in the network, which in certain situations is desirable.
>>
>> The MGC-MG redundancy schema gets even more complicated if you 
>> consider that the MGC can be multi-homed too. Effectively, it can 
>> have the same A1, A2, B1, B2 schema as the MG. In this case, what is 
>> really useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), 
>> because this takes care of all the combinations. But if the MG 
>> supports only UDP, it is not clear from the standard how to emulate 
>> this SCTP behavior. For example:
>> - Some MGs do a DNS query for the MGC name, get 2 IP addresses in 
>> response, but they just ignore the second IP address, thus ignoring 
>> that the MGC is multi-homed.
>> - Other MGs consider the IP addresses as being 2 different MGCs, 
>> rather than one multi-homed MG. The problem is that they only talk to 
>> one MGC at a time, and then they need a "handover" to switch. So 
>> while talking on A1-A1, the MGC cannot for example audit on A2-A2, 
>> because this is immediately considered a failover (causing for 
>> example the pending notifications to be lost). The MGCP spec, for 
>> example, explicitly states that an MG should not change its 
>> controlling entity when being audited from another IP address (and it 
>> doesn't say whether this is a different MGC or the same multi-homed 
>> MGC).
>>
>> I think what needs to be clarified here is:
>> - Whether an MG/MGC can be multi-homed and how to handle its multiple 
>> IP addresses.
>> - Whether an MG/MGC with active-standby controllers, transparent or 
>> non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
>> - Whether a domain name for an MG/MGC which yields more than one IP 
>> address through DNS, is associated with one controller, or with an 
>> active-standby pair, or possibly even with more active-standby pairs.
>>
>> The case with non-transparent MG controller switchover, as Flemming 
>> mentioned, poses additional problems. For example, if the active MG 
>> controller loses connectivity over A1 and A2, it may not even notice, 
>> because not all MGs do heartbeats. So if the MGC determines it can 
>> actually talk to B1 and B2, it cannot force an MG controller 
>> switchover, or at least the standard does not define the procedure 
>> for this. I would note that, in practice, however, most of the MGs 
>> and MGCs have transparent switchover (there is no B1, B2, they reuse 
>> A1, A2 ...).
>>
>> The MGCP spec is a little more explicit on how the IP addresses are 
>> handled. So I don't understand why this topic is outside the scope 
>> of  MEGACO.
>>
>> I raised these issues because, from my experience, every single 
>> vendor interprets them differently, and MGC-MG redundancy is a 
>> delicate subject. Any suggestions?
>>
>> Thanks
>>
>> Adrian Soncodi,
>> Tekelec, Richardson, TX
>>  
>>  
>>  
>>
>> Christian Groves wrote:
>>
>>>G'Day Flemming,
>>>
>>>May be my brain hasn't restarted after the Easter break
>>>
>>>In cases other than 1a a failover method would be sent with the
>>>ServiceChangeMGCId which the address of the association new or existing. How the
>>>state synchronisation is done is still out of scope of Megaco. MG2 will either
>>>have the up to date state knowledge (eg. duplicate megaco messages) or it will
>>>have to audit or use some other means to find out.
>>>
>>>Is it the state sharing part that you are questioning?
>>>
>>>Regards, Christian
>>>
>>>Flemming Andreasen wrote:
>>>
>>>>Hi Christian
>>>>
>>>>Christian Groves wrote:
>>>>
>>>>>G'Day Fleming,
>>>>>
>>>>>The megaco model can support the configurations that you list below. The
>>>>>scenarios are implemented in such a way that the megaco interface is unaware
>>>>>that state synchronisation is occuring. It's for this reason that the
>>>>>specification doesn't say more about it, if you don't need Megaco messages then
>>>>>there's no point putting it in a megaco specification.
>>>>>
>>>>I agree with the last point, however it only applies to case 1a. Clearly something
>>>>has to happen in all the other cases, i.e. sending of a ServiceChange since the
>>>>failover is not 100% transparent and the MGC needs to be informed about the change
>>>>(whether it's a simple address change, mgcId change, or some degree of state loss).
>>>>As I noted before, Megaco is silent on this and if you were to conclude anything
>>>>from the current draft of Annex F, it would be that only model 1a is actually
>>>>supported today (at least in a standard manner). If you believe all of these models
>>>>actually are supported, then I'd like to know what ServiceChangeMethod,
>>>>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
>>>>you would use in each case (apart from 1a that is).
>>>>
>>>>-- Flemming
>>>>
>>>>>Regards, Christian
>>>>>
>>>>>Flemming Andreasen wrote:
>>>>>
>>>>>>Megaco supports some notion of redundant MGs and redundant MG failover,
>>>>>>however there is very little normative language, let alone explanation
>>>>>>of how this is supposed to work (and the current incarnation of the
>>>>>>upcoming Annex F doesn't help much here). The only model described is
>>>>>>the one in Section 11.4, where both the primary and secondary MG are
>>>>>>fully visible at all times and the MGC has to send duplicate messages to
>>>>>>the MG.  However, what about supporting models where the MGC does not
>>>>>>have to send multiple messages ? How does the protocol support the
>>>>>>following models (if at all):
>>>>>>
>>>>>>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
>>>>>>complete state duplication (included for completeness since this one
>>>>>>will be 100% transparent to the MGC).
>>>>>>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
>>>>>>there is complete Megaco state synchronization
>>>>>>1c) MG1 (primary) a
>>>>>>nd MG2 (secondary) 
>>>>>>share the same IP-address, and
>>>>>>there is Megaco state synchronization at regular checkpoints (i.e. not
>>>>>>real-time so there may be some discrepances between the two)
>>>>>>2a) MG1 and MG2 have different IP addresses, and there is complete
>>>>>>Megaco state synchronization.
>>>>>>2b) MG1 and MG2 have different IP addresses, and there is Megaco state
>>>>>>synchronization at regular checkpoints (i.e. not real-time)
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>        Flemming
>>>>>>
>>>>>>_______________________________________________
>>>>>>Megaco mailing list
>>>>>>Megaco@ietf.org
>>>>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>Megaco@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>-- 
>Fernando Vallejo Lazaro
>Phone:  +34 91 330 5614
>SW  Wireline ASD-Madrid
>       ALCATEL
>
>  




--------------000200070601010907030002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
   Fernando,<br>
<br>
 Thanks for the reply. See comments inline.<br>
<br>
 Adrian<br>
<br>
<br>
<br>
 Fernando Vallejo Lazaro wrote:<br>
<blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">  Hi all,
   
  <p>Only some comments. </p>
  <p>- You say :&nbsp;"So while talking on A1-A1, the MGC cannot for example audit 
on A2-A2, because this is immediately considered a failover (...)". I don't 
think this is true. <br>
 If an MG receives an Audit from MGC-A2 (which it does not know) it will
reject the transaction because there is no association established with it.</p>
  </blockquote>
 Some MGs do this, others either don't reply or they failover. The latter 
may be in violation of the standard, but I think that's because it's not very
well explained.<br>
  <br>
 In my case, since I use the audits on A2-A2 as heartbeats (just to check 
for connectivity), any reply is OK, if only I get it. But this is a problem 
if some other MGC really wants to audit and is rejected. By the way, MGCP 
allows for this extra auditing, why is there a difference in approach? This 
only complicates things for an MGC which controls both MGCP and MEGACO MGs.<br>
  <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
    <p>- If the MG is multi-homed you can provision the two IP&nbsp;static addresses 
as primary and secondary MGCs. In case one fails it will change to the other 
IP which in fact is the <br>
 same MGC.</p>
    </blockquote>
 Yes, but if the failure (MGCs interface A1) occurs after the initial ServiceChange, 
sometimes during operations when the MG does not have any notifications to 
send, and if the MG does not do any heartbeats, then it won't be aware of 
the failure, it will just think it's idle. So it will not initiate ServiceChange 
to the "alternate" MGC. Furthermore, even if the MG receives a new command
from MGC A2, as you showed above, it will reply with an error and remain
idle. (By the way, where in the standard is this rule stated?)<br>
    <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
      <p>Maybe there should be a deep explanation of how to do this to smooth 
the process because the MG&nbsp;does not know whether the secondary is an independent
       <br>
 MGC, a backup or a mirror and depending on this information it can behave 
in one way or another (e.g. a ServiceChange Request only Informational)</p>
      </blockquote>
 Here, I concur with you and with Flemming, there should be more explanations. 
If you take into account multiple IP addresses, DNS names translating to one
or more IP addresses, MGs and MGCs working in active-standby mode with or
without complete state synchronization, as well as multiple active-standby 
pairs handoff, things get complicated enough to be worth additional explanations.<br>
      <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
        <p>- Another thing the MGC can do when it detects the that A1 is going
to die is to send a Handoff to the interface A2 for each MG so that the connections
are restablished <br>
 in the new path.</p>
        </blockquote>
 This is what it's forced to do, but the MG is not aware that the handoff 
is to the same MGC. Consequently, it continues to send pending notifications 
to the old IP address, as per RFC 3015 section 7.2.8 (and still in h248v2-04):<br>
        <br>
 "At the same time, as indicated in clause 9, transaction replies and pending 
indications must be sent to the address from which the corresponding requests 
originated."<br>
        <br>
 This forces the "new" MGC (which is not really new) to re-issue all the
notification requests, which, apart from being a substantial overhead, can
cause serious race conditions, especially with packages such as bcas. Again,
from experience, this is a point of contention, whether or not it's the right
behavior.<br>
        <br>
 If the MG were somehow aware that this is the same MGC, the signaling path
switchover between A1-A1 and A2-A2 would be faster and more reliable.<br>
        <br>
 I think the MEGACO spec obviously did not consider multi-homed MGs/MGCs,
therefore we are trying to see if the existing rules "happen to work" in
this case. I have had a lot of arguments over it because of different interpretations.
 <br>
        <br>
        <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
          <p>Regards <br>
 Fernando</p>
          </blockquote>
          <br>
 Thanks again,<br>
          <br>
 Adrian<br>
          <br>
          <br>
          <br>
          <br>
          <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
            <p>Adrian Soncodi wrote: </p>
            <blockquote type="CITE">Hello, all,                
              <p>I was wondering what is your oppinion on the following:
              </p>
              <p>Another topic that is not addressed in the MEGACO spec is 
the case of a multi-homed MG, i.e. an MG where: <br>
 - the primary controller has 2 physical interfaces A1 and A2, potentially
 on 2 different subnets, working in load-sharing mode (rather than active-standby)
               <br>
 - the secondary MG controller can then be either transparrent (it takes
over A1 and A2 on switchover) or non-transparent (has 2 more physical addresses,
 B1 and B2). </p>
              <p>One may argue that multi-homing is not necessary, for example 
because you can always assign a single "logical" IP address A that is reachable
 over both interfaces A1 and A2. Yes, but this schema requires some dynamic
 IP routing capability in the backbone (e.g. to figure out when A1 is down
 and packets for A should be routed to A2), which has a number of disadvantages:
               <br>
 - Depending on the routing protocol, the latency for dynamic updates of
the addresses can be very large (180 seconds in case of RIP), unacceptable
for telephony. <br>
 - Depending on the network topology, interface failures may not become visible 
in the backbone. For example, if there is a LAN switch between the MG and 
the first router, then the router does not see when the interface A1 fails 
(unless the dynamic routing domain is extended to include the MG, which is 
not always the case). <br>
 - Some service providers (especially the smaller ones) do not run a dynamic 
IP routing protocol in their (whole) backbone, or they may not even have a
real backbone, for example they may use leased lines, IP over ATM/FR PVCs 
with no sophisticated routing capabilities. </p>
              <p>On the other hand, making the physical addresses A1 and A2
visible allows for redundant signaling paths to the MG using only static IP
routing in the network, which in certain situations is desirable. </p>
              <p>The MGC-MG redundancy schema gets even more complicated if
you consider that the MGC can be multi-homed too. Effectively, it can have
the same A1, A2, B1, B2 schema as the MG. In this case, what is really useful
is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes
care of all the combinations. But if the MG supports only UDP, it is not
clear from the standard how to emulate this SCTP behavior. For example:  
             <br>
 - Some MGs do a DNS query for the MGC name, get 2 IP addresses in response,
 but they just ignore the second IP address, thus ignoring that the MGC is 
multi-homed. <br>
 - Other MGs consider the IP addresses as being 2 different MGCs, rather
than one multi-homed MG. The problem is that they only talk to one MGC at
a time, and then they need a "handover" to switch. So while talking on A1-A1,
the MGC cannot for example audit on A2-A2, because this is immediately considered 
a failover (causing for example the pending notifications to be lost). The 
MGCP spec, for example, explicitly states that an MG should not change its 
controlling entity when being audited from another IP address (and it doesn't 
say whether this is a different MGC or the same multi-homed MGC). </p>
              <p>I think what needs to be clarified here is: <br>
 - Whether an MG/MGC can be multi-homed and how to handle its multiple IP 
addresses. <br>
 - Whether an MG/MGC with active-standby controllers, transparent or non-transparent 
switchover, are considered one MG/MGC or 2 MG/MGCs <br>
 - Whether a domain name for an MG/MGC which yields more than one IP address 
through DNS, is associated with one controller, or with an active-standby
 pair, or possibly even with more active-standby pairs. </p>
              <p>The case with non-transparent MG controller switchover, as
Flemming mentioned, poses additional problems. For example, if the active 
MG controller loses connectivity over A1 and A2, it may not even notice, because
not all MGs do heartbeats. So if the MGC determines it can actually talk
to B1 and B2, it cannot force an MG controller switchover, or at least the
standard does not define the procedure for this. I would note that, in  practice,
however, most of the MGs and MGCs have transparent switchover (there is no
B1, B2, they reuse A1, A2 ...). </p>
              <p>The MGCP spec is a little more explicit on how the IP addresses 
are handled. So I don't understand why this topic is outside the scope of&nbsp;
 MEGACO. </p>
              <p>I raised these issues because, from my experience, every 
single vendor interprets them differently, and MGC-MG redundancy is a delicate 
subject. Any suggestions? </p>
              <p>Thanks </p>
              <p>Adrian Soncodi, <br>
 Tekelec, Richardson, TX <br>
 &nbsp; <br>
 &nbsp; <br>
 &nbsp; </p>
              <p>Christian Groves wrote: </p>
              <blockquote type="cite" cite="mid:3EA4CE5B.2C2AC97B@ericsson.com.au">
                <pre wrap="">G'Day Flemming,<br><br>May be my brain hasn't restarted after the Easter break<br><br>In cases other than 1a a failover method would be sent with the<br>ServiceChangeMGCId which the address of the association new or existing. How the<br>state synchronisation is done is still out of scope of Megaco. MG2 will either<br>have the up to date state knowledge (eg. duplicate megaco messages) or it will<br>have to audit or use some other means to find out.<br><br>Is it the state sharing part that you are questioning?<br><br>Regards, Christian<br><br>Flemming Andreasen wrote:</pre>
                <blockquote type="cite">
                  <pre wrap="">Hi Christian<br><br>Christian Groves wrote:<br><br></pre>
                  <blockquote type="cite">
                    <pre wrap="">G'Day Fleming,<br><br>The megaco model can support the configurations that you list below. The<br>scenarios are implemented in such a way that the megaco interface is unaware<br>that state synchronisation is occuring. It's for this reason that the<br>specification doesn't say more about it, if you don't need Megaco messages then<br>there's no point putting it in a megaco specification.<br><br></pre>
                    </blockquote>
                    <pre wrap="">I agree with the last point, however it only applies to case 1a. Clearly something<br>has to happen in all the other cases, i.e. sending of a ServiceChange since the<br>failover is not 100% transparent and the MGC needs to be informed about the change<br>(whether it's a simple address change, mgcId change, or some degree of state loss).<br>As I noted before, Megaco is silent on this and if you were to conclude anything<br>from the current draft of Annex F, it would be that only model 1a is actually<br>supported today (at least in a standard manner). If you believe all of these models<br>actually are supported, then I'd like to know what ServiceChangeMethod,<br>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)<br>you would use in each case (apart from 1a that is).<br><br>-- Flemming<br><br></pre>
                    <blockquote type="cite">
                      <pre wrap="">Regards, Christian<br><br>Flemming Andreasen wrote:</pre>
                      <blockquote type="cite">
                        <pre wrap="">Megaco supports some notion of redundant MGs and redundant MG failover,<br>however there is very little normative language, let alone explanation<br>of how this is supposed to work (and the current incarnation of the<br>upcoming Annex F doesn't help much here). The only model described is<br>the one in Section 11.4, where both the primary and secondary MG are<br>fully visible at all times and the MGC has to send duplicate messages to<br>the MG.&nbsp; However, what about supporting models where the MGC does not<br>have to send multiple messages ? How does the protocol support the<br>following models (if at all):<br><br>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with<br>complete state duplication (included for completeness since this one<br>will be 100% transparent to the MGC).<br>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and<br>there is complete Megaco state synchronization<br>1c) MG1 (primary) a

nd MG2 (secondary)&nbsp;<br>share the same IP-address, and<br>there is Megaco state synchronization at regular checkpoints (i.e. not<br>real-time so there may be some discrepances between the two)<br>2a) MG1 and MG2 have different IP addresses, and there is complete<br>Megaco state synchronization.<br>2b) MG1 and MG2 have different IP addresses, and there is Megaco state<br>synchronization at regular checkpoints (i.e. not real-time)<br><br>Thanks<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming<br><br>_______________________________________________<br>Megaco mailing list<br><a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org<br></a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a></pre>
                        </blockquote>
                        </blockquote>
                        </blockquote>
                        <pre wrap=""><!---->_______________________________________________<br>Megaco mailing list<br><a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org<br></a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a><br><br></pre>
                        </blockquote>
                        </blockquote>
                        <pre>--&nbsp;<br>Fernando Vallejo Lazaro<br>Phone:&nbsp; +34 91 330 5614<br>SW&nbsp; Wireline ASD-Madrid<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ALCATEL</pre>
  &nbsp;</blockquote>
                        <br>
                        <br>
                        </body>
                        </html>

--------------000200070601010907030002--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 16:43:42 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05984
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 16:43:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NKjxv29774
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 16:45:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKjx829771
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 16:45:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05966
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 16:43:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198R7T-0007IP-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 16:45:31 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198R7T-0007IM-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 16:45:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKi2829707;
	Wed, 23 Apr 2003 16:44:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKdk829528
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 16:39:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05822
	for <megaco@ietf.org>; Wed, 23 Apr 2003 16:36:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198R1S-0007Gr-00
	for megaco@ietf.org; Wed, 23 Apr 2003 16:39:18 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198R1R-0007Gb-00
	for megaco@ietf.org; Wed, 23 Apr 2003 16:39:18 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042315390578:2697 ;
          Wed, 23 Apr 2003 15:39:05 -0500 
Message-ID: <3EA6FB72.8050208@tekelec.com>
Date: Wed, 23 Apr 2003 15:45:38 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com> <3EA6518B.862FDD51@alcatel.es>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 03:39:05 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 03:39:44 PM,
	Serialize complete at 04/23/2003 03:39:44 PM
Content-Type: multipart/alternative;
 boundary="------------000200070601010907030002"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------000200070601010907030002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Fernando,

Thanks for the reply. See comments inline.

Adrian



Fernando Vallejo Lazaro wrote:

> Hi all,
>
> Only some comments.
>
> - You say : "So while talking on A1-A1, the MGC cannot for example 
> audit on A2-A2, because this is immediately considered a failover 
> (...)". I don't think this is true.
> If an MG receives an Audit from MGC-A2 (which it does not know) it 
> will reject the transaction because there is no association 
> established with it.
>
Some MGs do this, others either don't reply or they failover. The latter 
may be in violation of the standard, but I think that's because it's not 
very well explained.

In my case, since I use the audits on A2-A2 as heartbeats (just to check 
for connectivity), any reply is OK, if only I get it. But this is a 
problem if some other MGC really wants to audit and is rejected. By the 
way, MGCP allows for this extra auditing, why is there a difference in 
approach? This only complicates things for an MGC which controls both 
MGCP and MEGACO MGs.

> - If the MG is multi-homed you can provision the two IP static 
> addresses as primary and secondary MGCs. In case one fails it will 
> change to the other IP which in fact is the
> same MGC.
>
Yes, but if the failure (MGCs interface A1) occurs after the initial 
ServiceChange, sometimes during operations when the MG does not have any 
notifications to send, and if the MG does not do any heartbeats, then it 
won't be aware of the failure, it will just think it's idle. So it will 
not initiate ServiceChange to the "alternate" MGC. Furthermore, even if 
the MG receives a new command from MGC A2, as you showed above, it will 
reply with an error and remain idle. (By the way, where in the standard 
is this rule stated?)

> Maybe there should be a deep explanation of how to do this to smooth 
> the process because the MG does not know whether the secondary is an 
> independent
> MGC, a backup or a mirror and depending on this information it can 
> behave in one way or another (e.g. a ServiceChange Request only 
> Informational)
>
Here, I concur with you and with Flemming, there should be more 
explanations. If you take into account multiple IP addresses, DNS names 
translating to one or more IP addresses, MGs and MGCs working in 
active-standby mode with or without complete state synchronization, as 
well as multiple active-standby pairs handoff, things get complicated 
enough to be worth additional explanations.

> - Another thing the MGC can do when it detects the that A1 is going to 
> die is to send a Handoff to the interface A2 for each MG so that the 
> connections are restablished
> in the new path.
>
This is what it's forced to do, but the MG is not aware that the handoff 
is to the same MGC. Consequently, it continues to send pending 
notifications to the old IP address, as per RFC 3015 section 7.2.8 (and 
still in h248v2-04):

"At the same time, as indicated in clause 9, transaction replies and 
pending indications must be sent to the address from which the 
corresponding requests originated."

This forces the "new" MGC (which is not really new) to re-issue all the 
notification requests, which, apart from being a substantial overhead, 
can cause serious race conditions, especially with packages such as 
bcas. Again, from experience, this is a point of contention, whether or 
not it's the right behavior.

If the MG were somehow aware that this is the same MGC, the signaling 
path switchover between A1-A1 and A2-A2 would be faster and more reliable.

I think the MEGACO spec obviously did not consider multi-homed MGs/MGCs, 
therefore we are trying to see if the existing rules "happen to work" in 
this case. I have had a lot of arguments over it because of different 
interpretations.

> Regards
> Fernando
>

Thanks again,

Adrian




> Adrian Soncodi wrote:
>
>> Hello, all,
>>
>> I was wondering what is your oppinion on the following:
>>
>> Another topic that is not addressed in the MEGACO spec is the case of 
>> a multi-homed MG, i.e. an MG where:
>> - the primary controller has 2 physical interfaces A1 and A2, 
>> potentially on 2 different subnets, working in load-sharing mode 
>> (rather than active-standby)
>> - the secondary MG controller can then be either transparrent (it 
>> takes over A1 and A2 on switchover) or non-transparent (has 2 more 
>> physical addresses, B1 and B2).
>>
>> One may argue that multi-homing is not necessary, for example because 
>> you can always assign a single "logical" IP address A that is 
>> reachable over both interfaces A1 and A2. Yes, but this schema 
>> requires some dynamic IP routing capability in the backbone (e.g. to 
>> figure out when A1 is down and packets for A should be routed to A2), 
>> which has a number of disadvantages:
>> - Depending on the routing protocol, the latency for dynamic updates 
>> of the addresses can be very large (180 seconds in case of RIP), 
>> unacceptable for telephony.
>> - Depending on the network topology, interface failures may not 
>> become visible in the backbone. For example, if there is a LAN switch 
>> between the MG and the first router, then the router does not see 
>> when the interface A1 fails (unless the dynamic routing domain is 
>> extended to include the MG, which is not always the case).
>> - Some service providers (especially the smaller ones) do not run a 
>> dynamic IP routing protocol in their (whole) backbone, or they may 
>> not even have a real backbone, for example they may use leased lines, 
>> IP over ATM/FR PVCs with no sophisticated routing capabilities.
>>
>> On the other hand, making the physical addresses A1 and A2 visible 
>> allows for redundant signaling paths to the MG using only static IP 
>> routing in the network, which in certain situations is desirable.
>>
>> The MGC-MG redundancy schema gets even more complicated if you 
>> consider that the MGC can be multi-homed too. Effectively, it can 
>> have the same A1, A2, B1, B2 schema as the MG. In this case, what is 
>> really useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), 
>> because this takes care of all the combinations. But if the MG 
>> supports only UDP, it is not clear from the standard how to emulate 
>> this SCTP behavior. For example:
>> - Some MGs do a DNS query for the MGC name, get 2 IP addresses in 
>> response, but they just ignore the second IP address, thus ignoring 
>> that the MGC is multi-homed.
>> - Other MGs consider the IP addresses as being 2 different MGCs, 
>> rather than one multi-homed MG. The problem is that they only talk to 
>> one MGC at a time, and then they need a "handover" to switch. So 
>> while talking on A1-A1, the MGC cannot for example audit on A2-A2, 
>> because this is immediately considered a failover (causing for 
>> example the pending notifications to be lost). The MGCP spec, for 
>> example, explicitly states that an MG should not change its 
>> controlling entity when being audited from another IP address (and it 
>> doesn't say whether this is a different MGC or the same multi-homed 
>> MGC).
>>
>> I think what needs to be clarified here is:
>> - Whether an MG/MGC can be multi-homed and how to handle its multiple 
>> IP addresses.
>> - Whether an MG/MGC with active-standby controllers, transparent or 
>> non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
>> - Whether a domain name for an MG/MGC which yields more than one IP 
>> address through DNS, is associated with one controller, or with an 
>> active-standby pair, or possibly even with more active-standby pairs.
>>
>> The case with non-transparent MG controller switchover, as Flemming 
>> mentioned, poses additional problems. For example, if the active MG 
>> controller loses connectivity over A1 and A2, it may not even notice, 
>> because not all MGs do heartbeats. So if the MGC determines it can 
>> actually talk to B1 and B2, it cannot force an MG controller 
>> switchover, or at least the standard does not define the procedure 
>> for this. I would note that, in practice, however, most of the MGs 
>> and MGCs have transparent switchover (there is no B1, B2, they reuse 
>> A1, A2 ...).
>>
>> The MGCP spec is a little more explicit on how the IP addresses are 
>> handled. So I don't understand why this topic is outside the scope 
>> of  MEGACO.
>>
>> I raised these issues because, from my experience, every single 
>> vendor interprets them differently, and MGC-MG redundancy is a 
>> delicate subject. Any suggestions?
>>
>> Thanks
>>
>> Adrian Soncodi,
>> Tekelec, Richardson, TX
>>  
>>  
>>  
>>
>> Christian Groves wrote:
>>
>>>G'Day Flemming,
>>>
>>>May be my brain hasn't restarted after the Easter break
>>>
>>>In cases other than 1a a failover method would be sent with the
>>>ServiceChangeMGCId which the address of the association new or existing. How the
>>>state synchronisation is done is still out of scope of Megaco. MG2 will either
>>>have the up to date state knowledge (eg. duplicate megaco messages) or it will
>>>have to audit or use some other means to find out.
>>>
>>>Is it the state sharing part that you are questioning?
>>>
>>>Regards, Christian
>>>
>>>Flemming Andreasen wrote:
>>>
>>>>Hi Christian
>>>>
>>>>Christian Groves wrote:
>>>>
>>>>>G'Day Fleming,
>>>>>
>>>>>The megaco model can support the configurations that you list below. The
>>>>>scenarios are implemented in such a way that the megaco interface is unaware
>>>>>that state synchronisation is occuring. It's for this reason that the
>>>>>specification doesn't say more about it, if you don't need Megaco messages then
>>>>>there's no point putting it in a megaco specification.
>>>>>
>>>>I agree with the last point, however it only applies to case 1a. Clearly something
>>>>has to happen in all the other cases, i.e. sending of a ServiceChange since the
>>>>failover is not 100% transparent and the MGC needs to be informed about the change
>>>>(whether it's a simple address change, mgcId change, or some degree of state loss).
>>>>As I noted before, Megaco is silent on this and if you were to conclude anything
>>>>from the current draft of Annex F, it would be that only model 1a is actually
>>>>supported today (at least in a standard manner). If you believe all of these models
>>>>actually are supported, then I'd like to know what ServiceChangeMethod,
>>>>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)
>>>>you would use in each case (apart from 1a that is).
>>>>
>>>>-- Flemming
>>>>
>>>>>Regards, Christian
>>>>>
>>>>>Flemming Andreasen wrote:
>>>>>
>>>>>>Megaco supports some notion of redundant MGs and redundant MG failover,
>>>>>>however there is very little normative language, let alone explanation
>>>>>>of how this is supposed to work (and the current incarnation of the
>>>>>>upcoming Annex F doesn't help much here). The only model described is
>>>>>>the one in Section 11.4, where both the primary and secondary MG are
>>>>>>fully visible at all times and the MGC has to send duplicate messages to
>>>>>>the MG.  However, what about supporting models where the MGC does not
>>>>>>have to send multiple messages ? How does the protocol support the
>>>>>>following models (if at all):
>>>>>>
>>>>>>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with
>>>>>>complete state duplication (included for completeness since this one
>>>>>>will be 100% transparent to the MGC).
>>>>>>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and
>>>>>>there is complete Megaco state synchronization
>>>>>>1c) MG1 (primary) a
>>>>>>nd MG2 (secondary) 
>>>>>>share the same IP-address, and
>>>>>>there is Megaco state synchronization at regular checkpoints (i.e. not
>>>>>>real-time so there may be some discrepances between the two)
>>>>>>2a) MG1 and MG2 have different IP addresses, and there is complete
>>>>>>Megaco state synchronization.
>>>>>>2b) MG1 and MG2 have different IP addresses, and there is Megaco state
>>>>>>synchronization at regular checkpoints (i.e. not real-time)
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>        Flemming
>>>>>>
>>>>>>_______________________________________________
>>>>>>Megaco mailing list
>>>>>>Megaco@ietf.org
>>>>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>Megaco@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>-- 
>Fernando Vallejo Lazaro
>Phone:  +34 91 330 5614
>SW  Wireline ASD-Madrid
>       ALCATEL
>
>  




--------------000200070601010907030002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
   Fernando,<br>
<br>
 Thanks for the reply. See comments inline.<br>
<br>
 Adrian<br>
<br>
<br>
<br>
 Fernando Vallejo Lazaro wrote:<br>
<blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">  Hi all,
   
  <p>Only some comments. </p>
  <p>- You say :&nbsp;"So while talking on A1-A1, the MGC cannot for example audit 
on A2-A2, because this is immediately considered a failover (...)". I don't 
think this is true. <br>
 If an MG receives an Audit from MGC-A2 (which it does not know) it will
reject the transaction because there is no association established with it.</p>
  </blockquote>
 Some MGs do this, others either don't reply or they failover. The latter 
may be in violation of the standard, but I think that's because it's not very
well explained.<br>
  <br>
 In my case, since I use the audits on A2-A2 as heartbeats (just to check 
for connectivity), any reply is OK, if only I get it. But this is a problem 
if some other MGC really wants to audit and is rejected. By the way, MGCP 
allows for this extra auditing, why is there a difference in approach? This 
only complicates things for an MGC which controls both MGCP and MEGACO MGs.<br>
  <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
    <p>- If the MG is multi-homed you can provision the two IP&nbsp;static addresses 
as primary and secondary MGCs. In case one fails it will change to the other 
IP which in fact is the <br>
 same MGC.</p>
    </blockquote>
 Yes, but if the failure (MGCs interface A1) occurs after the initial ServiceChange, 
sometimes during operations when the MG does not have any notifications to 
send, and if the MG does not do any heartbeats, then it won't be aware of 
the failure, it will just think it's idle. So it will not initiate ServiceChange 
to the "alternate" MGC. Furthermore, even if the MG receives a new command
from MGC A2, as you showed above, it will reply with an error and remain
idle. (By the way, where in the standard is this rule stated?)<br>
    <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
      <p>Maybe there should be a deep explanation of how to do this to smooth 
the process because the MG&nbsp;does not know whether the secondary is an independent
       <br>
 MGC, a backup or a mirror and depending on this information it can behave 
in one way or another (e.g. a ServiceChange Request only Informational)</p>
      </blockquote>
 Here, I concur with you and with Flemming, there should be more explanations. 
If you take into account multiple IP addresses, DNS names translating to one
or more IP addresses, MGs and MGCs working in active-standby mode with or
without complete state synchronization, as well as multiple active-standby 
pairs handoff, things get complicated enough to be worth additional explanations.<br>
      <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
        <p>- Another thing the MGC can do when it detects the that A1 is going
to die is to send a Handoff to the interface A2 for each MG so that the connections
are restablished <br>
 in the new path.</p>
        </blockquote>
 This is what it's forced to do, but the MG is not aware that the handoff 
is to the same MGC. Consequently, it continues to send pending notifications 
to the old IP address, as per RFC 3015 section 7.2.8 (and still in h248v2-04):<br>
        <br>
 "At the same time, as indicated in clause 9, transaction replies and pending 
indications must be sent to the address from which the corresponding requests 
originated."<br>
        <br>
 This forces the "new" MGC (which is not really new) to re-issue all the
notification requests, which, apart from being a substantial overhead, can
cause serious race conditions, especially with packages such as bcas. Again,
from experience, this is a point of contention, whether or not it's the right
behavior.<br>
        <br>
 If the MG were somehow aware that this is the same MGC, the signaling path
switchover between A1-A1 and A2-A2 would be faster and more reliable.<br>
        <br>
 I think the MEGACO spec obviously did not consider multi-homed MGs/MGCs,
therefore we are trying to see if the existing rules "happen to work" in
this case. I have had a lot of arguments over it because of different interpretations.
 <br>
        <br>
        <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
          <p>Regards <br>
 Fernando</p>
          </blockquote>
          <br>
 Thanks again,<br>
          <br>
 Adrian<br>
          <br>
          <br>
          <br>
          <br>
          <blockquote type="cite" cite="mid:3EA6518B.862FDD51@alcatel.es">
            <p>Adrian Soncodi wrote: </p>
            <blockquote type="CITE">Hello, all,                
              <p>I was wondering what is your oppinion on the following:
              </p>
              <p>Another topic that is not addressed in the MEGACO spec is 
the case of a multi-homed MG, i.e. an MG where: <br>
 - the primary controller has 2 physical interfaces A1 and A2, potentially
 on 2 different subnets, working in load-sharing mode (rather than active-standby)
               <br>
 - the secondary MG controller can then be either transparrent (it takes
over A1 and A2 on switchover) or non-transparent (has 2 more physical addresses,
 B1 and B2). </p>
              <p>One may argue that multi-homing is not necessary, for example 
because you can always assign a single "logical" IP address A that is reachable
 over both interfaces A1 and A2. Yes, but this schema requires some dynamic
 IP routing capability in the backbone (e.g. to figure out when A1 is down
 and packets for A should be routed to A2), which has a number of disadvantages:
               <br>
 - Depending on the routing protocol, the latency for dynamic updates of
the addresses can be very large (180 seconds in case of RIP), unacceptable
for telephony. <br>
 - Depending on the network topology, interface failures may not become visible 
in the backbone. For example, if there is a LAN switch between the MG and 
the first router, then the router does not see when the interface A1 fails 
(unless the dynamic routing domain is extended to include the MG, which is 
not always the case). <br>
 - Some service providers (especially the smaller ones) do not run a dynamic 
IP routing protocol in their (whole) backbone, or they may not even have a
real backbone, for example they may use leased lines, IP over ATM/FR PVCs 
with no sophisticated routing capabilities. </p>
              <p>On the other hand, making the physical addresses A1 and A2
visible allows for redundant signaling paths to the MG using only static IP
routing in the network, which in certain situations is desirable. </p>
              <p>The MGC-MG redundancy schema gets even more complicated if
you consider that the MGC can be multi-homed too. Effectively, it can have
the same A1, A2, B1, B2 schema as the MG. In this case, what is really useful
is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because this takes
care of all the combinations. But if the MG supports only UDP, it is not
clear from the standard how to emulate this SCTP behavior. For example:  
             <br>
 - Some MGs do a DNS query for the MGC name, get 2 IP addresses in response,
 but they just ignore the second IP address, thus ignoring that the MGC is 
multi-homed. <br>
 - Other MGs consider the IP addresses as being 2 different MGCs, rather
than one multi-homed MG. The problem is that they only talk to one MGC at
a time, and then they need a "handover" to switch. So while talking on A1-A1,
the MGC cannot for example audit on A2-A2, because this is immediately considered 
a failover (causing for example the pending notifications to be lost). The 
MGCP spec, for example, explicitly states that an MG should not change its 
controlling entity when being audited from another IP address (and it doesn't 
say whether this is a different MGC or the same multi-homed MGC). </p>
              <p>I think what needs to be clarified here is: <br>
 - Whether an MG/MGC can be multi-homed and how to handle its multiple IP 
addresses. <br>
 - Whether an MG/MGC with active-standby controllers, transparent or non-transparent 
switchover, are considered one MG/MGC or 2 MG/MGCs <br>
 - Whether a domain name for an MG/MGC which yields more than one IP address 
through DNS, is associated with one controller, or with an active-standby
 pair, or possibly even with more active-standby pairs. </p>
              <p>The case with non-transparent MG controller switchover, as
Flemming mentioned, poses additional problems. For example, if the active 
MG controller loses connectivity over A1 and A2, it may not even notice, because
not all MGs do heartbeats. So if the MGC determines it can actually talk
to B1 and B2, it cannot force an MG controller switchover, or at least the
standard does not define the procedure for this. I would note that, in  practice,
however, most of the MGs and MGCs have transparent switchover (there is no
B1, B2, they reuse A1, A2 ...). </p>
              <p>The MGCP spec is a little more explicit on how the IP addresses 
are handled. So I don't understand why this topic is outside the scope of&nbsp;
 MEGACO. </p>
              <p>I raised these issues because, from my experience, every 
single vendor interprets them differently, and MGC-MG redundancy is a delicate 
subject. Any suggestions? </p>
              <p>Thanks </p>
              <p>Adrian Soncodi, <br>
 Tekelec, Richardson, TX <br>
 &nbsp; <br>
 &nbsp; <br>
 &nbsp; </p>
              <p>Christian Groves wrote: </p>
              <blockquote type="cite" cite="mid:3EA4CE5B.2C2AC97B@ericsson.com.au">
                <pre wrap="">G'Day Flemming,<br><br>May be my brain hasn't restarted after the Easter break<br><br>In cases other than 1a a failover method would be sent with the<br>ServiceChangeMGCId which the address of the association new or existing. How the<br>state synchronisation is done is still out of scope of Megaco. MG2 will either<br>have the up to date state knowledge (eg. duplicate megaco messages) or it will<br>have to audit or use some other means to find out.<br><br>Is it the state sharing part that you are questioning?<br><br>Regards, Christian<br><br>Flemming Andreasen wrote:</pre>
                <blockquote type="cite">
                  <pre wrap="">Hi Christian<br><br>Christian Groves wrote:<br><br></pre>
                  <blockquote type="cite">
                    <pre wrap="">G'Day Fleming,<br><br>The megaco model can support the configurations that you list below. The<br>scenarios are implemented in such a way that the megaco interface is unaware<br>that state synchronisation is occuring. It's for this reason that the<br>specification doesn't say more about it, if you don't need Megaco messages then<br>there's no point putting it in a megaco specification.<br><br></pre>
                    </blockquote>
                    <pre wrap="">I agree with the last point, however it only applies to case 1a. Clearly something<br>has to happen in all the other cases, i.e. sending of a ServiceChange since the<br>failover is not 100% transparent and the MGC needs to be informed about the change<br>(whether it's a simple address change, mgcId change, or some degree of state loss).<br>As I noted before, Megaco is silent on this and if you were to conclude anything<br>from the current draft of Annex F, it would be that only model 1a is actually<br>supported today (at least in a standard manner). If you believe all of these models<br>actually are supported, then I'd like to know what ServiceChangeMethod,<br>ServiceChangeReason, and ServiceChangeMGCId (and/or possibly ServiceChangeAddress)<br>you would use in each case (apart from 1a that is).<br><br>-- Flemming<br><br></pre>
                    <blockquote type="cite">
                      <pre wrap="">Regards, Christian<br><br>Flemming Andreasen wrote:</pre>
                      <blockquote type="cite">
                        <pre wrap="">Megaco supports some notion of redundant MGs and redundant MG failover,<br>however there is very little normative language, let alone explanation<br>of how this is supposed to work (and the current incarnation of the<br>upcoming Annex F doesn't help much here). The only model described is<br>the one in Section 11.4, where both the primary and secondary MG are<br>fully visible at all times and the MGC has to send duplicate messages to<br>the MG.&nbsp; However, what about supporting models where the MGC does not<br>have to send multiple messages ? How does the protocol support the<br>following models (if at all):<br><br>1a) MG1 (primary) and MG2 (secondary) share the same IP-address with<br>complete state duplication (included for completeness since this one<br>will be 100% transparent to the MGC).<br>1b) MG1 (primary) and MG2 (secondary) share the same IP-address, and<br>there is complete Megaco state synchronization<br>1c) MG1 (primary) a

nd MG2 (secondary)&nbsp;<br>share the same IP-address, and<br>there is Megaco state synchronization at regular checkpoints (i.e. not<br>real-time so there may be some discrepances between the two)<br>2a) MG1 and MG2 have different IP addresses, and there is complete<br>Megaco state synchronization.<br>2b) MG1 and MG2 have different IP addresses, and there is Megaco state<br>synchronization at regular checkpoints (i.e. not real-time)<br><br>Thanks<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming<br><br>_______________________________________________<br>Megaco mailing list<br><a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org<br></a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a></pre>
                        </blockquote>
                        </blockquote>
                        </blockquote>
                        <pre wrap=""><!---->_______________________________________________<br>Megaco mailing list<br><a href="mailto:Megaco@ietf.org" class="moz-txt-link-abbreviated">Megaco@ietf.org<br></a><a href="https://www1.ietf.org/mailman/listinfo/megaco" class="moz-txt-link-freetext">https://www1.ietf.org/mailman/listinfo/megaco</a><br><br></pre>
                        </blockquote>
                        </blockquote>
                        <pre>--&nbsp;<br>Fernando Vallejo Lazaro<br>Phone:&nbsp; +34 91 330 5614<br>SW&nbsp; Wireline ASD-Madrid<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ALCATEL</pre>
  &nbsp;</blockquote>
                        <br>
                        <br>
                        </body>
                        </html>

--------------000200070601010907030002--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 23 17:04:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07329
	for <megaco-archive@lists.ietf.org>; Wed, 23 Apr 2003 17:04:01 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NL4u831123;
	Wed, 23 Apr 2003 17:04:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NL0g830743
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 17:00:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07058
	for <megaco@ietf.org>; Wed, 23 Apr 2003 16:57:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198RLi-0007Sw-00
	for megaco@ietf.org; Wed, 23 Apr 2003 17:00:14 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198RLh-0007RN-00
	for megaco@ietf.org; Wed, 23 Apr 2003 17:00:14 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042316000854:2729 ;
          Wed, 23 Apr 2003 16:00:08 -0500 
Message-ID: <3EA70061.7040103@tekelec.com>
Date: Wed, 23 Apr 2003 16:06:41 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations
References: <ABA227A15B80D511BD1A00508BF93A1C08E4A814@zrtpd0jq.us.nortel.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 04:00:08 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 04:00:40 PM,
	Serialize complete at 04/23/2003 04:00:40 PM
Content-Type: multipart/alternative;
 boundary="------------020806030407060607020701"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------020806030407060607020701
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kevin,

I understand a redundant MGC is now allowed to continue modifying a 
termination which has been added by a primary MGC. What happens to the 
pending notifications, if the MG needs to send one for that termination? 
Apparently, according to section 7.2.8, "...transaction replies and 
pending indications must be sent to the address from which the 
corresponding requests originated". This means to the primary MGC, which 
in the meantime (and most likely) has gone out of service.

Adrian Soncodi



Kevin Boyle wrote:

> Since I haven't seen any objections to this wording, I will include it 
> in the IG for May's SG16 meeting.
>
> Kevin
>
> -----Original Message-----
> From: Christian Groves [ mailto:Christian.Groves@ericsson.com.au ]
> Sent: Tuesday, April 15, 2003 8:19 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: ksrini@winphoria.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: Re: [Megaco] Restriction on Modification Of Terminations
>
>
> G'Day Kevin,
>
> The text has been there from way back when we determined H.248 version 
> 1. It seems noone has paid attention to it since then!!!
>
> How about adding:
> An MGC can only release/modify terminations and the resources that the 
> termination represents <<which are in the NULL context or>> which 
> >>delete:it has<< <<have been>> previously seized via, e.g., the Add 
> command.
>
> The removal of "it has" should cover the servicechange concern.
>
> Regards, Christian
>
> Kevin Boyle wrote:
> >
> > The argument can be made that the resources were previously seized via
> > an Add.  I will look back through some older IGs and see if I can find
> > where this came from...
> >
> > Kevin
> >
> > -----Original Message-----
> > From: Srinivasan Krishnamoorthy [ mailto:ksrini@winphoria.com ]
> > Sent: Tuesday, April 15, 2003 1:34 PM
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> > Subject: RE: [Megaco] Restriction on Modification Of Terminations
> >
> > Hi,
> >
> > What happens in the case where a Handoff to a redundant MGC has
> > happened, but the contexts where originally created by a primary MGC.
> >
> > So, shouldn't we actually allow Subtracts from the new MGC, as well
> > then?
> >
> > Thanks,
> > -Srini
> >
> > On Tue, 15 Apr 2003, Kevin Boyle wrote:
> >
> > kboyle>Clearly this is an error, since, for example, the MG wouldn't
> > kboyle>want a phone in a context just to detect off-hook.  Likewise,
> > kboyle>if that set is currently in Null and looking for off-hook, then
> > kboyle>the MGC may wish to stop looking for off-hook (for any of a
> > kboyle>number of
> > kboyle>reasons) by Modifying the term with an empty Events descriptor.
> > kboyle>
> > kboyle>Any objections to striking the "/modify" portion of the
> > kboyle>sentence via the IG?
> > kboyle>
> > kboyle>Kevin
> > kboyle>
> > kboyle>-----Original Message-----
> > kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> > kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> > kboyle>To: megaco@ietf.org
> > kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> > kboyle>
> > kboyle>
> > kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e.
> > kboyle>H.248.1 v1) prior to its release, and got a slight surprise. 
> > kboyle>At the end of section 6.2.1 there is this
> > kboyle>sentence:
> > kboyle>
> > kboyle>"An MGC can only release/modify Terminations
> > kboyle>    and the resources that the Termination represents which 
> it has
> > kboyle>    previously seized via, e.g., the Add command."
> > kboyle>
> > kboyle>It seems to me this precludes doing Modifies in the NULL
> > kboyle>context, but I've seen various call flows that do just that. 
> > kboyle>Should we feed this back to SG 16 as something that should be
> > kboyle>fixed up to conform with practice?
> > kboyle>
> > kboyle>Tom Taylor
> > kboyle>
> > kboyle>_______________________________________________
> > kboyle>Megaco mailing list
> > kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> > kboyle>_______________________________________________
> > kboyle>Megaco mailing list
> > kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> > kboyle>
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>
>


--------------020806030407060607020701
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Kevin,<br>
<br>
I understand a redundant MGC is now allowed to continue modifying a termination
which has been added by a primary MGC. What happens to the pending notifications,
if the MG needs to send one for that termination? Apparently, according to
section 7.2.8, "...transaction replies and pending  indications must be sent
to the address from which the corresponding requests  originated". This means
to the primary MGC, which in the meantime (and most likely) has gone out
of service.<br>
<br>
Adrian Soncodi<br>
<br>
<br>
<br>
Kevin Boyle wrote:<br>
<blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E4A814@zrtpd0jq.us.nortel.com">
  <meta name="Generator" content="MS Exchange Server version 5.5.2656.31">
  <title>RE: [Megaco] Restriction on Modification Of Terminations</title>
  <p><font size="2">Since I haven't seen any objections to this wording,
I will include it in the IG for May's SG16 meeting.</font></p>
  <p><font size="2">Kevin</font></p>
  <p><font size="2">-----Original Message-----</font><br>
  <font size="2">From: Christian Groves [<a href="mailto:Christian.Groves@ericsson.com.au">
mailto:Christian.Groves@ericsson.com.au</a>
] </font><br>
  <font size="2">Sent: Tuesday, April 15, 2003 8:19 PM</font><br>
  <font size="2">To: Boyle, Kevin [NCRTP:3Z40:EXCH]</font><br>
  <font size="2">Cc: <a class="moz-txt-link-abbreviated" href="mailto:ksrini@winphoria.com">ksrini@winphoria.com</a>; Taylor, Tom-PT [CAR:5N00:EXCH];
<a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">Subject: Re: [Megaco] Restriction on Modification Of Terminations</font></p>
  <br>
  <p><font size="2">G'Day Kevin,</font></p>
  <p><font size="2">The text has been there from way back when we determined
H.248 version 1. It seems noone has paid attention to it since then!!!</font></p>
  <p><font size="2">How about adding:</font><br>
  <font size="2">An MGC can only release/modify terminations and the resources
that the termination represents &lt;&lt;which are in the NULL context or&gt;&gt;
which &gt;&gt;delete:it has&lt;&lt; &lt;&lt;have been&gt;&gt; previously
seized via, e.g., the Add command.</font></p>
  <p><font size="2">The removal of "it has" should cover the servicechange
concern.</font></p>
  <p><font size="2">Regards, Christian</font></p>
  <p><font size="2">Kevin Boyle wrote:</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; The argument can be made that the resources were previously
seized via </font><br>
  <font size="2">&gt; an Add.&nbsp; I will look back through some older IGs and
see if I can find </font><br>
  <font size="2">&gt; where this came from...</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; Kevin</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; -----Original Message-----</font><br>
  <font size="2">&gt; From: Srinivasan Krishnamoorthy [<a href="mailto:ksrini@winphoria.com">
mailto:ksrini@winphoria.com</a>
]</font><br>
  <font size="2">&gt; Sent: Tuesday, April 15, 2003 1:34 PM</font><br>
  <font size="2">&gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]</font><br>
  <font size="2">&gt; Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; <a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">&gt; Subject: RE: [Megaco] Restriction on Modification Of
Terminations</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; Hi,</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; What happens in the case where a Handoff to a redundant
MGC has </font><br>
  <font size="2">&gt; happened, but the contexts where originally created
by a primary MGC.</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; So, shouldn't we actually allow Subtracts from the
new MGC, as well </font><br>
  <font size="2">&gt; then?</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; Thanks,</font><br>
  <font size="2">&gt; -Srini</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; On Tue, 15 Apr 2003, Kevin Boyle wrote:</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; kboyle&gt;Clearly this is an error, since, for example,
the MG wouldn't </font><br>
  <font size="2">&gt; kboyle&gt;want a phone in a context just to detect
off-hook.&nbsp; Likewise, </font><br>
  <font size="2">&gt; kboyle&gt;if that set is currently in Null and looking
for off-hook, then </font><br>
  <font size="2">&gt; kboyle&gt;the MGC may wish to stop looking for off-hook
(for any of a </font><br>
  <font size="2">&gt; kboyle&gt;number of</font><br>
  <font size="2">&gt; kboyle&gt;reasons) by Modifying the term with an empty
Events descriptor.</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;Any objections to striking the "/modify"
portion of the </font><br>
  <font size="2">&gt; kboyle&gt;sentence via the IG?</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;Kevin</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;-----Original Message-----</font><br>
  <font size="2">&gt; kboyle&gt;From: Taylor, Tom-PT [CAR:5N00:EXCH]</font><br>
  <font size="2">&gt; kboyle&gt;Sent: Tuesday, April 15, 2003 11:02 AM</font><br>
  <font size="2">&gt; kboyle&gt;To: <a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">&gt; kboyle&gt;Subject: [Megaco] Restriction on Modification
Of Terminations</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;I've just been proof-reading the replacement
for RFC 3015 (i.e. </font><br>
  <font size="2">&gt; kboyle&gt;H.248.1 v1) prior to its release, and got
a slight surprise.&nbsp; </font><br>
  <font size="2">&gt; kboyle&gt;At the end of section 6.2.1 there is this</font><br>
  <font size="2">&gt; kboyle&gt;sentence:</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;"An MGC can only release/modify Terminations</font><br>
  <font size="2">&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; and the resources that the Termination
represents which it has</font><br>
  <font size="2">&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; previously seized via, e.g., the Add
command."</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;It seems to me this precludes doing Modifies
in the NULL </font><br>
  <font size="2">&gt; kboyle&gt;context, but I've seen various call flows
that do just that.&nbsp; </font><br>
  <font size="2">&gt; kboyle&gt;Should we feed this back to SG 16 as something
that should be </font><br>
  <font size="2">&gt; kboyle&gt;fixed up to conform with practice?</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;Tom Taylor</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;_______________________________________________</font><br>
  <font size="2">&gt; kboyle&gt;Megaco mailing list</font><br>
  <font size="2">&gt; kboyle&gt;<a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a> <a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
  </font><br>
  <font size="2">&gt; kboyle&gt;_______________________________________________</font><br>
  <font size="2">&gt; kboyle&gt;Megaco mailing list</font><br>
  <font size="2">&gt; kboyle&gt;<a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a> <a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
  </font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; _______________________________________________</font><br>
  <font size="2">&gt; Megaco mailing list</font><br>
  <font size="2">&gt; <a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a></font><br>
  <font size="2">&gt; <a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
  </font></p>
  <br>
  </blockquote>
  <br>
  </body>
  </html>

--------------020806030407060607020701--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 23 17:05:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07484
	for <megaco-archive@odin.ietf.org>; Wed, 23 Apr 2003 17:05:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3NL7Su31825
	for megaco-archive@odin.ietf.org; Wed, 23 Apr 2003 17:07:28 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NL7R831820
	for <megaco-web-archive@optimus.ietf.org>; Wed, 23 Apr 2003 17:07:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07432
	for <megaco-web-archive@ietf.org>; Wed, 23 Apr 2003 17:04:39 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198RSF-0007Xk-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 17:06:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198RSE-0007Xe-00
	for megaco-web-archive@ietf.org; Wed, 23 Apr 2003 17:06:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NL4u831123;
	Wed, 23 Apr 2003 17:04:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NL0g830743
	for <megaco@optimus.ietf.org>; Wed, 23 Apr 2003 17:00:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07058
	for <megaco@ietf.org>; Wed, 23 Apr 2003 16:57:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198RLi-0007Sw-00
	for megaco@ietf.org; Wed, 23 Apr 2003 17:00:14 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198RLh-0007RN-00
	for megaco@ietf.org; Wed, 23 Apr 2003 17:00:14 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042316000854:2729 ;
          Wed, 23 Apr 2003 16:00:08 -0500 
Message-ID: <3EA70061.7040103@tekelec.com>
Date: Wed, 23 Apr 2003 16:06:41 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Restriction on Modification Of Terminations
References: <ABA227A15B80D511BD1A00508BF93A1C08E4A814@zrtpd0jq.us.nortel.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 04:00:08 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/23/2003 04:00:40 PM,
	Serialize complete at 04/23/2003 04:00:40 PM
Content-Type: multipart/alternative;
 boundary="------------020806030407060607020701"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------020806030407060607020701
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kevin,

I understand a redundant MGC is now allowed to continue modifying a 
termination which has been added by a primary MGC. What happens to the 
pending notifications, if the MG needs to send one for that termination? 
Apparently, according to section 7.2.8, "...transaction replies and 
pending indications must be sent to the address from which the 
corresponding requests originated". This means to the primary MGC, which 
in the meantime (and most likely) has gone out of service.

Adrian Soncodi



Kevin Boyle wrote:

> Since I haven't seen any objections to this wording, I will include it 
> in the IG for May's SG16 meeting.
>
> Kevin
>
> -----Original Message-----
> From: Christian Groves [ mailto:Christian.Groves@ericsson.com.au ]
> Sent: Tuesday, April 15, 2003 8:19 PM
> To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: ksrini@winphoria.com; Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> Subject: Re: [Megaco] Restriction on Modification Of Terminations
>
>
> G'Day Kevin,
>
> The text has been there from way back when we determined H.248 version 
> 1. It seems noone has paid attention to it since then!!!
>
> How about adding:
> An MGC can only release/modify terminations and the resources that the 
> termination represents <<which are in the NULL context or>> which 
> >>delete:it has<< <<have been>> previously seized via, e.g., the Add 
> command.
>
> The removal of "it has" should cover the servicechange concern.
>
> Regards, Christian
>
> Kevin Boyle wrote:
> >
> > The argument can be made that the resources were previously seized via
> > an Add.  I will look back through some older IGs and see if I can find
> > where this came from...
> >
> > Kevin
> >
> > -----Original Message-----
> > From: Srinivasan Krishnamoorthy [ mailto:ksrini@winphoria.com ]
> > Sent: Tuesday, April 15, 2003 1:34 PM
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]
> > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; megaco@ietf.org
> > Subject: RE: [Megaco] Restriction on Modification Of Terminations
> >
> > Hi,
> >
> > What happens in the case where a Handoff to a redundant MGC has
> > happened, but the contexts where originally created by a primary MGC.
> >
> > So, shouldn't we actually allow Subtracts from the new MGC, as well
> > then?
> >
> > Thanks,
> > -Srini
> >
> > On Tue, 15 Apr 2003, Kevin Boyle wrote:
> >
> > kboyle>Clearly this is an error, since, for example, the MG wouldn't
> > kboyle>want a phone in a context just to detect off-hook.  Likewise,
> > kboyle>if that set is currently in Null and looking for off-hook, then
> > kboyle>the MGC may wish to stop looking for off-hook (for any of a
> > kboyle>number of
> > kboyle>reasons) by Modifying the term with an empty Events descriptor.
> > kboyle>
> > kboyle>Any objections to striking the "/modify" portion of the
> > kboyle>sentence via the IG?
> > kboyle>
> > kboyle>Kevin
> > kboyle>
> > kboyle>-----Original Message-----
> > kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
> > kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
> > kboyle>To: megaco@ietf.org
> > kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
> > kboyle>
> > kboyle>
> > kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e.
> > kboyle>H.248.1 v1) prior to its release, and got a slight surprise. 
> > kboyle>At the end of section 6.2.1 there is this
> > kboyle>sentence:
> > kboyle>
> > kboyle>"An MGC can only release/modify Terminations
> > kboyle>    and the resources that the Termination represents which 
> it has
> > kboyle>    previously seized via, e.g., the Add command."
> > kboyle>
> > kboyle>It seems to me this precludes doing Modifies in the NULL
> > kboyle>context, but I've seen various call flows that do just that. 
> > kboyle>Should we feed this back to SG 16 as something that should be
> > kboyle>fixed up to conform with practice?
> > kboyle>
> > kboyle>Tom Taylor
> > kboyle>
> > kboyle>_______________________________________________
> > kboyle>Megaco mailing list
> > kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> > kboyle>_______________________________________________
> > kboyle>Megaco mailing list
> > kboyle>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> > kboyle>
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>
>


--------------020806030407060607020701
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Kevin,<br>
<br>
I understand a redundant MGC is now allowed to continue modifying a termination
which has been added by a primary MGC. What happens to the pending notifications,
if the MG needs to send one for that termination? Apparently, according to
section 7.2.8, "...transaction replies and pending  indications must be sent
to the address from which the corresponding requests  originated". This means
to the primary MGC, which in the meantime (and most likely) has gone out
of service.<br>
<br>
Adrian Soncodi<br>
<br>
<br>
<br>
Kevin Boyle wrote:<br>
<blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E4A814@zrtpd0jq.us.nortel.com">
  <meta name="Generator" content="MS Exchange Server version 5.5.2656.31">
  <title>RE: [Megaco] Restriction on Modification Of Terminations</title>
  <p><font size="2">Since I haven't seen any objections to this wording,
I will include it in the IG for May's SG16 meeting.</font></p>
  <p><font size="2">Kevin</font></p>
  <p><font size="2">-----Original Message-----</font><br>
  <font size="2">From: Christian Groves [<a href="mailto:Christian.Groves@ericsson.com.au">
mailto:Christian.Groves@ericsson.com.au</a>
] </font><br>
  <font size="2">Sent: Tuesday, April 15, 2003 8:19 PM</font><br>
  <font size="2">To: Boyle, Kevin [NCRTP:3Z40:EXCH]</font><br>
  <font size="2">Cc: <a class="moz-txt-link-abbreviated" href="mailto:ksrini@winphoria.com">ksrini@winphoria.com</a>; Taylor, Tom-PT [CAR:5N00:EXCH];
<a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">Subject: Re: [Megaco] Restriction on Modification Of Terminations</font></p>
  <br>
  <p><font size="2">G'Day Kevin,</font></p>
  <p><font size="2">The text has been there from way back when we determined
H.248 version 1. It seems noone has paid attention to it since then!!!</font></p>
  <p><font size="2">How about adding:</font><br>
  <font size="2">An MGC can only release/modify terminations and the resources
that the termination represents &lt;&lt;which are in the NULL context or&gt;&gt;
which &gt;&gt;delete:it has&lt;&lt; &lt;&lt;have been&gt;&gt; previously
seized via, e.g., the Add command.</font></p>
  <p><font size="2">The removal of "it has" should cover the servicechange
concern.</font></p>
  <p><font size="2">Regards, Christian</font></p>
  <p><font size="2">Kevin Boyle wrote:</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; The argument can be made that the resources were previously
seized via </font><br>
  <font size="2">&gt; an Add.&nbsp; I will look back through some older IGs and
see if I can find </font><br>
  <font size="2">&gt; where this came from...</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; Kevin</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; -----Original Message-----</font><br>
  <font size="2">&gt; From: Srinivasan Krishnamoorthy [<a href="mailto:ksrini@winphoria.com">
mailto:ksrini@winphoria.com</a>
]</font><br>
  <font size="2">&gt; Sent: Tuesday, April 15, 2003 1:34 PM</font><br>
  <font size="2">&gt; To: Boyle, Kevin [NCRTP:3Z40:EXCH]</font><br>
  <font size="2">&gt; Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; <a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">&gt; Subject: RE: [Megaco] Restriction on Modification Of
Terminations</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; Hi,</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; What happens in the case where a Handoff to a redundant
MGC has </font><br>
  <font size="2">&gt; happened, but the contexts where originally created
by a primary MGC.</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; So, shouldn't we actually allow Subtracts from the
new MGC, as well </font><br>
  <font size="2">&gt; then?</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; Thanks,</font><br>
  <font size="2">&gt; -Srini</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; On Tue, 15 Apr 2003, Kevin Boyle wrote:</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; kboyle&gt;Clearly this is an error, since, for example,
the MG wouldn't </font><br>
  <font size="2">&gt; kboyle&gt;want a phone in a context just to detect
off-hook.&nbsp; Likewise, </font><br>
  <font size="2">&gt; kboyle&gt;if that set is currently in Null and looking
for off-hook, then </font><br>
  <font size="2">&gt; kboyle&gt;the MGC may wish to stop looking for off-hook
(for any of a </font><br>
  <font size="2">&gt; kboyle&gt;number of</font><br>
  <font size="2">&gt; kboyle&gt;reasons) by Modifying the term with an empty
Events descriptor.</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;Any objections to striking the "/modify"
portion of the </font><br>
  <font size="2">&gt; kboyle&gt;sentence via the IG?</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;Kevin</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;-----Original Message-----</font><br>
  <font size="2">&gt; kboyle&gt;From: Taylor, Tom-PT [CAR:5N00:EXCH]</font><br>
  <font size="2">&gt; kboyle&gt;Sent: Tuesday, April 15, 2003 11:02 AM</font><br>
  <font size="2">&gt; kboyle&gt;To: <a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">&gt; kboyle&gt;Subject: [Megaco] Restriction on Modification
Of Terminations</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;I've just been proof-reading the replacement
for RFC 3015 (i.e. </font><br>
  <font size="2">&gt; kboyle&gt;H.248.1 v1) prior to its release, and got
a slight surprise.&nbsp; </font><br>
  <font size="2">&gt; kboyle&gt;At the end of section 6.2.1 there is this</font><br>
  <font size="2">&gt; kboyle&gt;sentence:</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;"An MGC can only release/modify Terminations</font><br>
  <font size="2">&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; and the resources that the Termination
represents which it has</font><br>
  <font size="2">&gt; kboyle&gt;&nbsp;&nbsp;&nbsp; previously seized via, e.g., the Add
command."</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;It seems to me this precludes doing Modifies
in the NULL </font><br>
  <font size="2">&gt; kboyle&gt;context, but I've seen various call flows
that do just that.&nbsp; </font><br>
  <font size="2">&gt; kboyle&gt;Should we feed this back to SG 16 as something
that should be </font><br>
  <font size="2">&gt; kboyle&gt;fixed up to conform with practice?</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;Tom Taylor</font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; kboyle&gt;_______________________________________________</font><br>
  <font size="2">&gt; kboyle&gt;Megaco mailing list</font><br>
  <font size="2">&gt; kboyle&gt;<a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a> <a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
  </font><br>
  <font size="2">&gt; kboyle&gt;_______________________________________________</font><br>
  <font size="2">&gt; kboyle&gt;Megaco mailing list</font><br>
  <font size="2">&gt; kboyle&gt;<a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a> <a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
  </font><br>
  <font size="2">&gt; kboyle&gt;</font><br>
  <font size="2">&gt; </font><br>
  <font size="2">&gt; _______________________________________________</font><br>
  <font size="2">&gt; Megaco mailing list</font><br>
  <font size="2">&gt; <a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a></font><br>
  <font size="2">&gt; <a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
  </font></p>
  <br>
  </blockquote>
  <br>
  </body>
  </html>

--------------020806030407060607020701--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 10:03:17 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16603
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 10:03:16 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE4n812217;
	Thu, 24 Apr 2003 10:04:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE0e812060
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 10:00:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16482
	for <megaco@ietf.org>; Thu, 24 Apr 2003 09:57:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198hGQ-00065c-00
	for megaco@ietf.org; Thu, 24 Apr 2003 09:59:50 -0400
Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198hGO-00065M-00
	for megaco@ietf.org; Thu, 24 Apr 2003 09:59:49 -0400
Received: (from root@localhost)
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h3OE1KG16130
	for megaco@ietf.org; Thu, 24 Apr 2003 19:31:20 +0530
Received: from euronymous ([132.147.166.61])
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h3OE1Kt16123
	for <megaco@ietf.org>; Thu, 24 Apr 2003 19:31:20 +0530
Reply-To: <milton@hfcl.com>
From: "Milton" <milton@hfcl.com>
To: <megaco@ietf.org>
Date: Thu, 24 Apr 2003 19:28:22 +0530
Message-ID: <000701c30a69$9228d820$3da69384@euronymous>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Xmilter: rnd.hfcl.com
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by netserv.rnd.hfcl.com id h3OE1KG16130
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OE0e812061
Subject: [Megaco] (no subject)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit


Dear All,

We all have seen the mail from Kevin that says: “IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES”. He also said … I am quoting him:
“Given that the working group is in the process of winding down, I do not
see
any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.”

Although his comments ring true but his conclusion is frustrating. First and
foremost question is why you people have decided to “WIND DOWN” the working
group?
- If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

-	If you people think that you are done with Megaco then in my opinion you
are grossly wrong. A protocol is named so because it gives people a
“standardized and optimized” set of rules for “interworking”. Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with “extensions” to the
“base protocol”  - standardizing packages give you that opportunity.
But of course, Kevin was right in saying that IETF is not “up and running”
and not working efficiently. I propose you people in IETF “MUST”(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.


-Milton

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 10:04:22 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16724
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 10:04:22 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OE70r12316
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 10:07:00 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE70812309
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 10:07:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16671
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 10:03:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198hMY-00066t-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 10:06:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198hMY-00066p-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 10:06:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE4n812217;
	Thu, 24 Apr 2003 10:04:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE0e812060
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 10:00:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16482
	for <megaco@ietf.org>; Thu, 24 Apr 2003 09:57:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198hGQ-00065c-00
	for megaco@ietf.org; Thu, 24 Apr 2003 09:59:50 -0400
Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198hGO-00065M-00
	for megaco@ietf.org; Thu, 24 Apr 2003 09:59:49 -0400
Received: (from root@localhost)
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h3OE1KG16130
	for megaco@ietf.org; Thu, 24 Apr 2003 19:31:20 +0530
Received: from euronymous ([132.147.166.61])
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h3OE1Kt16123
	for <megaco@ietf.org>; Thu, 24 Apr 2003 19:31:20 +0530
Reply-To: <milton@hfcl.com>
From: "Milton" <milton@hfcl.com>
To: <megaco@ietf.org>
Date: Thu, 24 Apr 2003 19:28:22 +0530
Message-ID: <000701c30a69$9228d820$3da69384@euronymous>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Xmilter: rnd.hfcl.com
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by netserv.rnd.hfcl.com id h3OE1KG16130
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OE0e812061
Subject: [Megaco] (no subject)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3OE4n812217
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OE70812309
Content-Transfer-Encoding: 8bit


Dear All,

We all have seen the mail from Kevin that says: “IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES”. He also said … I am quoting him:
“Given that the working group is in the process of winding down, I do not
see
any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.”

Although his comments ring true but his conclusion is frustrating. First and
foremost question is why you people have decided to “WIND DOWN” the working
group?
- If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

-	If you people think that you are done with Megaco then in my opinion you
are grossly wrong. A protocol is named so because it gives people a
“standardized and optimized” set of rules for “interworking”. Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with “extensions” to the
“base protocol”  - standardizing packages give you that opportunity.
But of course, Kevin was right in saying that IETF is not “up and running”
and not working efficiently. I propose you people in IETF “MUST”(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.


-Milton

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 10:05:08 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16809
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 10:05:08 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE6n812296;
	Thu, 24 Apr 2003 10:06:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE1L812106
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 10:01:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16496
	for <megaco@ietf.org>; Thu, 24 Apr 2003 09:58:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198hH5-00065q-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:00:31 -0400
Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198hH3-00065g-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:00:30 -0400
Received: (from root@localhost)
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h3OE2tr16144
	for megaco@ietf.org; Thu, 24 Apr 2003 19:32:55 +0530
Received: from euronymous ([132.147.166.61])
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h3OE2st16137
	for <megaco@ietf.org>; Thu, 24 Apr 2003 19:32:54 +0530
Reply-To: <milton@hfcl.com>
From: "Milton" <milton@hfcl.com>
To: <megaco@ietf.org>
Date: Thu, 24 Apr 2003 19:29:56 +0530
Message-ID: <000801c30a69$ca689040$3da69384@euronymous>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Xmilter: rnd.hfcl.com
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by netserv.rnd.hfcl.com id h3OE2tr16144
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OE1L812107
Subject: [Megaco] megaco working group
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit



 -----Original Message-----
From: 	Milton [mailto:milton@hfcl.com]
Sent:	Thursday, April 24, 2003 7:28 PM
To:	'megaco@ietf.org'
Subject:


Dear All,

We all have seen the mail from Kevin that says: “IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES”. He also said … I am quoting him:
“Given that the working group is in the process of winding down, I do not
see
any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.”

Although his comments ring true but his conclusion is frustrating. First and
foremost question is why you people have decided to “WIND DOWN” the working
group?
- If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

-	If you people think that you are done with Megaco then in my opinion you
are grossly wrong. A protocol is named so because it gives people a
“standardized and optimized” set of rules for “interworking”. Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with “extensions” to the
“base protocol”  - standardizing packages give you that opportunity.
But of course, Kevin was right in saying that IETF is not “up and running”
and not working efficiently. I propose you people in IETF “MUST”(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.


-Milton

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 10:06:13 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16940
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 10:06:12 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OE8pB13258
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 10:08:51 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE8p813255
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 10:08:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16879
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 10:05:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198hOK-00067R-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 10:08:01 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198hOK-00067O-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 10:08:00 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE6n812296;
	Thu, 24 Apr 2003 10:06:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OE1L812106
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 10:01:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16496
	for <megaco@ietf.org>; Thu, 24 Apr 2003 09:58:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198hH5-00065q-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:00:31 -0400
Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198hH3-00065g-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:00:30 -0400
Received: (from root@localhost)
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h3OE2tr16144
	for megaco@ietf.org; Thu, 24 Apr 2003 19:32:55 +0530
Received: from euronymous ([132.147.166.61])
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h3OE2st16137
	for <megaco@ietf.org>; Thu, 24 Apr 2003 19:32:54 +0530
Reply-To: <milton@hfcl.com>
From: "Milton" <milton@hfcl.com>
To: <megaco@ietf.org>
Date: Thu, 24 Apr 2003 19:29:56 +0530
Message-ID: <000801c30a69$ca689040$3da69384@euronymous>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Xmilter: rnd.hfcl.com
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by netserv.rnd.hfcl.com id h3OE2tr16144
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OE1L812107
Subject: [Megaco] megaco working group
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3OE6n812296
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OE8p813255
Content-Transfer-Encoding: 8bit



 -----Original Message-----
From: 	Milton [mailto:milton@hfcl.com]
Sent:	Thursday, April 24, 2003 7:28 PM
To:	'megaco@ietf.org'
Subject:


Dear All,

We all have seen the mail from Kevin that says: “IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES”. He also said … I am quoting him:
“Given that the working group is in the process of winding down, I do not
see
any benefit to anyone in continuing to allow the IETF to hold up
standardization when the ITU is prepared to consider and advance the work.”

Although his comments ring true but his conclusion is frustrating. First and
foremost question is why you people have decided to “WIND DOWN” the working
group?
- If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

-	If you people think that you are done with Megaco then in my opinion you
are grossly wrong. A protocol is named so because it gives people a
“standardized and optimized” set of rules for “interworking”. Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with “extensions” to the
“base protocol”  - standardizing packages give you that opportunity.
But of course, Kevin was right in saying that IETF is not “up and running”
and not working efficiently. I propose you people in IETF “MUST”(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.


-Milton

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 10:49:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18723
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 10:49:19 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEp7815998;
	Thu, 24 Apr 2003 10:51:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEm3815904
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 10:48:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18685
	for <megaco@ietf.org>; Thu, 24 Apr 2003 10:44:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198i0G-0006Kh-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:47:12 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 198i0F-0006KT-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:47:11 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OEl8010673
	for <megaco@ietf.org>; Thu, 24 Apr 2003 10:47:08 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J9617V9>; Thu, 24 Apr 2003 10:47:08 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E99424@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: milton@hfcl.com, megaco@ietf.org
Subject: RE: [Megaco] (no subject)
Date: Thu, 24 Apr 2003 10:47:07 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Milton [mailto:milton@hfcl.com] 
Sent: Thursday, April 24, 2003 9:58 AM
To: megaco@ietf.org
Subject: [Megaco] (no subject)



Dear All,

We all have seen the mail from Kevin that says: "IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES". He also said ... I am quoting him: "Given that
the working group is in the process of winding down, I do not see any
benefit to anyone in continuing to allow the IETF to hold up standardization
when the ITU is prepared to consider and advance the work."

Although his comments ring true but his conclusion is frustrating. First and
foremost question is why you people have decided to "WIND DOWN" the working
group?

[KJBII] Closing a working group is decided by the IESG based on completion
of the goals set forth in the group charter, and the work produced by the
group. "We people" did not overtly decide to wind down the working group,
but the fact is that the WG has not produced any work of note in quite some
time.

- If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

[KJBII] IETF and ITU started to progress work on the same topic at the same
time.  Rather than end up with two competing standards, the two
organizations decided to join forces.  I believe that the resultant protocol
shows great success in that collaboration.  I believe we did see the best of
both worlds.  However, the IETF has problems with its processes --
self-acknowledged problems.  I believe these will need to be worked out
before the IETF is prepared to take on more work directly related to
H.248/Megaco.

-	If you people think that you are done with Megaco then in my opinion
you
are grossly wrong. A protocol is named so because it gives people a
"standardized and optimized" set of rules for "interworking". Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with "extensions" to the
"base protocol"  - standardizing packages give you that opportunity. But of
course, Kevin was right in saying that IETF is not "up and running" and not
working efficiently. I propose you people in IETF "MUST"(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.

[KJBII] I do not believe package standardization has ever been a work item
on the charter of the working group.  Therefore, package standardization has
never been in the scope of the working group, other than the courtesy of
allowing the list to comment on packages.  Note that the procedures for
developing packages do not require this courtesy.  I don't believe anybody
said that "we" are "done with Megaco".  I, personally, have several
significant work items in the ITU that will make the protocol better for
everyone.  The ITU meetings are not secret affairs, and the working
documents are available to everyone on the list via anonymous FTP.  Comments
that are raised on the list are discussed at the ITU meetings.  Note that
the list will continue, even after the WG completes at some point in the
future.  Note that the H.248 working documents will also continue to be
available to all, as well.

[KJBII] Your message uses the phrase "you people" quite a bit.  Are you not
a member of the group?  Are you not one of those involved?  Either way,
though, it is a matter of fact that the WG has not produced any work of note
in recent times, and that is one of the criterion looked at when deciding
whether or not it is worthwhile to continue a working group.


-Milton

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 10:50:23 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18760
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 10:50:23 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OEr3016054
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 10:53:03 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEr3816051
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 10:53:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18746
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 10:49:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198i56-0006Lm-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 10:52:12 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198i55-0006Lj-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 10:52:11 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEp7815998;
	Thu, 24 Apr 2003 10:51:07 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEm3815904
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 10:48:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18685
	for <megaco@ietf.org>; Thu, 24 Apr 2003 10:44:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198i0G-0006Kh-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:47:12 -0400
Received: from zrtps06s.nortelnetworks.com ([47.140.48.50])
	by ietf-mx with esmtp (Exim 4.12)
	id 198i0F-0006KT-00
	for megaco@ietf.org; Thu, 24 Apr 2003 10:47:11 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OEl8010673
	for <megaco@ietf.org>; Thu, 24 Apr 2003 10:47:08 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J9617V9>; Thu, 24 Apr 2003 10:47:08 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E99424@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: milton@hfcl.com, megaco@ietf.org
Subject: RE: [Megaco] (no subject)
Date: Thu, 24 Apr 2003 10:47:07 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Milton [mailto:milton@hfcl.com] 
Sent: Thursday, April 24, 2003 9:58 AM
To: megaco@ietf.org
Subject: [Megaco] (no subject)



Dear All,

We all have seen the mail from Kevin that says: "IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES". He also said ... I am quoting him: "Given that
the working group is in the process of winding down, I do not see any
benefit to anyone in continuing to allow the IETF to hold up standardization
when the ITU is prepared to consider and advance the work."

Although his comments ring true but his conclusion is frustrating. First and
foremost question is why you people have decided to "WIND DOWN" the working
group?

[KJBII] Closing a working group is decided by the IESG based on completion
of the goals set forth in the group charter, and the work produced by the
group. "We people" did not overtly decide to wind down the working group,
but the fact is that the WG has not produced any work of note in quite some
time.

- If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

[KJBII] IETF and ITU started to progress work on the same topic at the same
time.  Rather than end up with two competing standards, the two
organizations decided to join forces.  I believe that the resultant protocol
shows great success in that collaboration.  I believe we did see the best of
both worlds.  However, the IETF has problems with its processes --
self-acknowledged problems.  I believe these will need to be worked out
before the IETF is prepared to take on more work directly related to
H.248/Megaco.

-	If you people think that you are done with Megaco then in my opinion
you
are grossly wrong. A protocol is named so because it gives people a
"standardized and optimized" set of rules for "interworking". Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with "extensions" to the
"base protocol"  - standardizing packages give you that opportunity. But of
course, Kevin was right in saying that IETF is not "up and running" and not
working efficiently. I propose you people in IETF "MUST"(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.

[KJBII] I do not believe package standardization has ever been a work item
on the charter of the working group.  Therefore, package standardization has
never been in the scope of the working group, other than the courtesy of
allowing the list to comment on packages.  Note that the procedures for
developing packages do not require this courtesy.  I don't believe anybody
said that "we" are "done with Megaco".  I, personally, have several
significant work items in the ITU that will make the protocol better for
everyone.  The ITU meetings are not secret affairs, and the working
documents are available to everyone on the list via anonymous FTP.  Comments
that are raised on the list are discussed at the ITU meetings.  Note that
the list will continue, even after the WG completes at some point in the
future.  Note that the H.248 working documents will also continue to be
available to all, as well.

[KJBII] Your message uses the phrase "you people" quite a bit.  Are you not
a member of the group?  Are you not one of those involved?  Either way,
though, it is a matter of fact that the WG has not produced any work of note
in recent times, and that is one of the criterion looked at when deciding
whether or not it is worthwhile to continue a working group.


-Milton

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 11:06:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19174
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 11:06:55 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF8W817646;
	Thu, 24 Apr 2003 11:08:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF51816665
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 11:05:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19023
	for <megaco@ietf.org>; Thu, 24 Apr 2003 11:01:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iGf-0006PZ-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:04:09 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iGf-0006PW-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:04:09 -0400
Received: from cisco.com (sjc-vpn2-380.cisco.com [10.21.113.124])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3OF44ID012528;
	Thu, 24 Apr 2003 08:04:04 -0700 (PDT)
Message-ID: <3EA7FCE3.7234E56E@cisco.com>
Date: Thu, 24 Apr 2003 11:04:03 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Adrian Soncodi wrote:

> Hello, all,
>
> I was wondering what is your oppinion on the following:
>
> Another topic that is not addressed in the MEGACO spec is the case of
> a multi-homed MG, i.e. an MG where:
> - the primary controller has 2 physical interfaces A1 and A2,
> potentially on 2 different subnets, working in load-sharing mode
> (rather than active-standby)
> - the secondary MG controller can then be either transparrent (it
> takes over A1 and A2 on switchover) or non-transparent (has 2 more
> physical addresses, B1 and B2).
>
> One may argue that multi-homing is not necessary, for example because
> you can always assign a single "logical" IP address A that is
> reachable over both interfaces A1 and A2. Yes, but this schema
> requires some dynamic IP routing capability in the backbone (e.g. to
> figure out when A1 is down and packets for A should be routed to A2),
> which has a number of disadvantages:
> - Depending on the routing protocol, the latency for dynamic updates
> of the addresses can be very large (180 seconds in case of RIP),
> unacceptable for telephony.
> - Depending on the network topology, interface failures may not become
> visible in the backbone. For example, if there is a LAN switch between
> the MG and the first router, then the router does not see when the
> interface A1 fails (unless the dynamic routing domain is extended to
> include the MG, which is not always the case).
> - Some service providers (especially the smaller ones) do not run a
> dynamic IP routing protocol in their (whole) backbone, or they may not
> even have a real backbone, for example they may use leased lines, IP
> over ATM/FR PVCs with no sophisticated routing capabilities.
>
> On the other hand, making the physical addresses A1 and A2 visible
> allows for redundant signaling paths to the MG using only static IP
> routing in the network, which in certain situations is desirable.
>
> The MGC-MG redundancy schema gets even more complicated if you
> consider that the MGC can be multi-homed too. Effectively, it can have
> the same A1, A2, B1, B2 schema as the MG. In this case, what is really
> useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because
> this takes care of all the combinations. But if the MG supports only
> UDP, it is not clear from the standard how to emulate this SCTP
> behavior. For example:
> - Some MGs do a DNS query for the MGC name, get 2 IP addresses in
> response, but they just ignore the second IP address, thus ignoring
> that the MGC is multi-homed.
> - Other MGs consider the IP addresses as being 2 different MGCs,
> rather than one multi-homed MG. The problem is that they only talk to
> one MGC at a time, and then they need a "handover" to switch. So while
> talking on A1-A1, the MGC cannot for example audit on A2-A2, because
> this is immediately considered a failover (causing for example the
> pending notifications to be lost). The MGCP spec, for example,
> explicitly states that an MG should not change its controlling entity
> when being audited from another IP address (and it doesn't say whether
> this is a different MGC or the same multi-homed MGC).
>
> I think what needs to be clarified here is:
> - Whether an MG/MGC can be multi-homed and how to handle its multiple
> IP addresses.
> - Whether an MG/MGC with active-standby controllers, transparent or
> non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
> - Whether a domain name for an MG/MGC which yields more than one IP
> address through DNS, is associated with one controller, or with an
> active-standby pair, or possibly even with more active-standby pairs.
>

I agree - these are rather big holes in the current specs IMO.


>
> The case with non-transparent MG controller switchover, as Flemming
> mentioned, poses additional problems. For example, if the active MG
> controller loses connectivity over A1 and A2, it may not even notice,
> because not all MGs do heartbeats. So if the MGC determines it can
> actually talk to B1 and B2, it cannot force an MG controller
> switchover, or at least the standard does not define the procedure for
> this. I would note that, in practice, however, most of the MGs and
> MGCs have transparent switchover (there is no B1, B2, they reuse A1,
> A2 ...).
>
> The MGCP spec is a little more explicit on how the IP addresses are
> handled. So I don't understand why this topic is outside the scope of
> MEGACO.
>

Right. I have always thought it was unfortunate, that Megaco did not
specify anything about use of multiple IP addresses and/or interfaces
(apart from the static provisioning of backup MGCs) as this limits the
robustness of the protocol when using UDP/TCP. I was hoping that Annex F
would rectifiy some of that, but it doesn't seem like it.

>
> I raised these issues because, from my experience, every single vendor
> interprets them differently, and MGC-MG redundancy is a delicate
> subject. Any suggestions?

1. Continued discussion on the mailing list (preferably with more input
from some of the traditional Megaco gurus).
2. Write a contribution for SG16 addressing this.
3. Forget about TCP and UDP and just use SCTP.

-- Flemming


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 11:08:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19282
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 11:08:02 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OFAg217821
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 11:10:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OFAg817818
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 11:10:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19227
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 11:07:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iMA-0006SH-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 11:09:50 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198iMA-0006SE-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 11:09:50 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF8W817646;
	Thu, 24 Apr 2003 11:08:32 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF51816665
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 11:05:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19023
	for <megaco@ietf.org>; Thu, 24 Apr 2003 11:01:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iGf-0006PZ-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:04:09 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iGf-0006PW-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:04:09 -0400
Received: from cisco.com (sjc-vpn2-380.cisco.com [10.21.113.124])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3OF44ID012528;
	Thu, 24 Apr 2003 08:04:04 -0700 (PDT)
Message-ID: <3EA7FCE3.7234E56E@cisco.com>
Date: Thu, 24 Apr 2003 11:04:03 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Megaco <megaco@ietf.org>
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Adrian Soncodi wrote:

> Hello, all,
>
> I was wondering what is your oppinion on the following:
>
> Another topic that is not addressed in the MEGACO spec is the case of
> a multi-homed MG, i.e. an MG where:
> - the primary controller has 2 physical interfaces A1 and A2,
> potentially on 2 different subnets, working in load-sharing mode
> (rather than active-standby)
> - the secondary MG controller can then be either transparrent (it
> takes over A1 and A2 on switchover) or non-transparent (has 2 more
> physical addresses, B1 and B2).
>
> One may argue that multi-homing is not necessary, for example because
> you can always assign a single "logical" IP address A that is
> reachable over both interfaces A1 and A2. Yes, but this schema
> requires some dynamic IP routing capability in the backbone (e.g. to
> figure out when A1 is down and packets for A should be routed to A2),
> which has a number of disadvantages:
> - Depending on the routing protocol, the latency for dynamic updates
> of the addresses can be very large (180 seconds in case of RIP),
> unacceptable for telephony.
> - Depending on the network topology, interface failures may not become
> visible in the backbone. For example, if there is a LAN switch between
> the MG and the first router, then the router does not see when the
> interface A1 fails (unless the dynamic routing domain is extended to
> include the MG, which is not always the case).
> - Some service providers (especially the smaller ones) do not run a
> dynamic IP routing protocol in their (whole) backbone, or they may not
> even have a real backbone, for example they may use leased lines, IP
> over ATM/FR PVCs with no sophisticated routing capabilities.
>
> On the other hand, making the physical addresses A1 and A2 visible
> allows for redundant signaling paths to the MG using only static IP
> routing in the network, which in certain situations is desirable.
>
> The MGC-MG redundancy schema gets even more complicated if you
> consider that the MGC can be multi-homed too. Effectively, it can have
> the same A1, A2, B1, B2 schema as the MG. In this case, what is really
> useful is an SCTP association (MGC-A1, MGC-A2, MG-A1, MG-A2), because
> this takes care of all the combinations. But if the MG supports only
> UDP, it is not clear from the standard how to emulate this SCTP
> behavior. For example:
> - Some MGs do a DNS query for the MGC name, get 2 IP addresses in
> response, but they just ignore the second IP address, thus ignoring
> that the MGC is multi-homed.
> - Other MGs consider the IP addresses as being 2 different MGCs,
> rather than one multi-homed MG. The problem is that they only talk to
> one MGC at a time, and then they need a "handover" to switch. So while
> talking on A1-A1, the MGC cannot for example audit on A2-A2, because
> this is immediately considered a failover (causing for example the
> pending notifications to be lost). The MGCP spec, for example,
> explicitly states that an MG should not change its controlling entity
> when being audited from another IP address (and it doesn't say whether
> this is a different MGC or the same multi-homed MGC).
>
> I think what needs to be clarified here is:
> - Whether an MG/MGC can be multi-homed and how to handle its multiple
> IP addresses.
> - Whether an MG/MGC with active-standby controllers, transparent or
> non-transparent switchover, are considered one MG/MGC or 2 MG/MGCs
> - Whether a domain name for an MG/MGC which yields more than one IP
> address through DNS, is associated with one controller, or with an
> active-standby pair, or possibly even with more active-standby pairs.
>

I agree - these are rather big holes in the current specs IMO.


>
> The case with non-transparent MG controller switchover, as Flemming
> mentioned, poses additional problems. For example, if the active MG
> controller loses connectivity over A1 and A2, it may not even notice,
> because not all MGs do heartbeats. So if the MGC determines it can
> actually talk to B1 and B2, it cannot force an MG controller
> switchover, or at least the standard does not define the procedure for
> this. I would note that, in practice, however, most of the MGs and
> MGCs have transparent switchover (there is no B1, B2, they reuse A1,
> A2 ...).
>
> The MGCP spec is a little more explicit on how the IP addresses are
> handled. So I don't understand why this topic is outside the scope of
> MEGACO.
>

Right. I have always thought it was unfortunate, that Megaco did not
specify anything about use of multiple IP addresses and/or interfaces
(apart from the static provisioning of backup MGCs) as this limits the
robustness of the protocol when using UDP/TCP. I was hoping that Annex F
would rectifiy some of that, but it doesn't seem like it.

>
> I raised these issues because, from my experience, every single vendor
> interprets them differently, and MGC-MG redundancy is a delicate
> subject. Any suggestions?

1. Continued discussion on the mailing list (preferably with more input
from some of the traditional Megaco gurus).
2. Write a contribution for SG16 addressing this.
3. Forget about TCP and UDP and just use SCTP.

-- Flemming


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 11:26:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20006
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 11:26:32 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OFS2818584;
	Thu, 24 Apr 2003 11:28:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OFPD818454
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 11:25:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19807
	for <megaco@ietf.org>; Thu, 24 Apr 2003 11:22:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iaE-0006by-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:24:22 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iaD-0006b5-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:24:21 -0400
Received: from cisco.com (sjc-vpn2-380.cisco.com [10.21.113.124])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3OFNpID010810;
	Thu, 24 Apr 2003 08:23:51 -0700 (PDT)
Message-ID: <3EA80186.7538BEEB@cisco.com>
Date: Thu, 24 Apr 2003 11:23:50 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com> <3EA6518B.862FDD51@alcatel.es> <3EA6FB72.8050208@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Adrian Soncodi wrote:

> Fernando,
>
> Thanks for the reply. See comments inline.
>
> Adrian
>
>
>
> Fernando Vallejo Lazaro wrote:
>
>> Hi all,
>>
>> Only some comments.
>>
>> - You say : "So while talking on A1-A1, the MGC cannot for example
>> audit on A2-A2, because this is immediately considered a failover
>> (...)". I don't think this is true.
>> If an MG receives an Audit from MGC-A2 (which it does not know) it
>> will reject the transaction because there is no association
>> established with it.
>
> Some MGs do this, others either don't reply or they failover. The
> latter may be in violation of the standard, but I think that's because
> it's not very well explained.
>

I think part of the problem here is that the concept of a control
association is not very well defined when it comes to UDP; how do you
determine if a message received is part of the UDP control association ?



>
> In my case, since I use the audits on A2-A2 as heartbeats (just to
> check for connectivity), any reply is OK, if only I get it. But this
> is a problem if some other MGC really wants to audit and is rejected.
> By the way, MGCP allows for this extra auditing, why is there a
> difference in approach? This only complicates things for an MGC which
> controls both MGCP and MEGACO MGs.
>
>> - If the MG is multi-homed you can provision the two IP static
>> addresses as primary and secondary MGCs. In case one fails it will
>> change to the other IP which in fact is the
>> same MGC.
>
> Yes, but if the failure (MGCs interface A1) occurs after the initial
> ServiceChange, sometimes during operations when the MG does not have
> any notifications to send, and if the MG does not do any heartbeats,
> then it won't be aware of the failure, it will just think it's idle.
> So it will not initiate ServiceChange to the "alternate" MGC.
> Furthermore, even if the MG receives a new command from MGC A2, as you
> showed above, it will reply with an error and remain idle. (By the
> way, where in the standard is this rule stated?)

Yes, however there are ways around this problem (by design, Megaco chose
to only have the MG be able to initiate the control association, so you
just need to make sure it does that - see H.248.14 for a solution).

There are however a couple of bad things here:
1. Only the statically provisioned list of backup MGCs can be contacted,
and only in the order they were provisioned.
2. The spec is silent on whether a backup MGC replicates the state of
the primary or not. Consequently, you cannot assume that it does, and
hence switching to the backup is something you don't want to do
prematurely.
3. The switchover is not graceful, i.e. there has to be a failure before
you start contacting the backup. In contrast, a more robust redundancy
scheme would detect/suspect the failure earlier during retransmission
and switch to one of the backups to prevent any loss of state.
Furthermore, there should be a way of indicating that a backup is fully
redundant and hence the switchover can be done fairly early without any
risk.


>> Maybe there should be a deep explanation of how to do this to smooth
>> the process because the MG does not know whether the secondary is an
>> independent
>> MGC, a backup or a mirror and depending on this information it can
>> behave in one way or another (e.g. a ServiceChange Request only
>> Informational)
>
> Here, I concur with you and with Flemming, there should be more
> explanations. If you take into account multiple IP addresses, DNS
> names translating to one or more IP addresses, MGs and MGCs working in
> active-standby mode with or without complete state synchronization, as
> well as multiple active-standby pairs handoff, things get complicated
> enough to be worth additional explanations.

Agreed - there is work to be done in this area.


>> - Another thing the MGC can do when it detects the that A1 is going
>> to die is to send a Handoff to the interface A2 for each MG so that
>> the connections are restablished
>> in the new path.
>
> This is what it's forced to do, but the MG is not aware that the
> handoff is to the same MGC. Consequently, it continues to send pending
> notifications to the old IP address, as per RFC 3015 section 7.2.8
> (and still in h248v2-04):
>
> "At the same time, as indicated in clause 9, transaction replies and
> pending indications must be sent to the address from which the
> corresponding requests originated."
>
> This forces the "new" MGC (which is not really new) to re-issue all
> the notification requests, which, apart from being a substantial
> overhead, can cause serious race conditions, especially with packages
> such as bcas. Again, from experience, this is a point of contention,
> whether or not it's the right behavior.
>
> If the MG were somehow aware that this is the same MGC, the signaling
> path switchover between A1-A1 and A2-A2 would be faster and more
> reliable.
>
> I think the MEGACO spec obviously did not consider multi-homed
> MGs/MGCs, therefore we are trying to see if the existing rules "happen
> to work" in this case. I have had a lot of arguments over it because
> of different interpretations.
>

I agree (and actually, I'm surprised nobody has addressed it yet because
it has been known for a long time and pops up on the mailing list from
time time, but without much progress being made).

-- Flemming



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 11:27:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20050
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 11:27:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OFUII18691
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 11:30:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OFUI818688
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 11:30:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20043
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 11:27:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198if8-0006en-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 11:29:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198if7-0006ej-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 11:29:25 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OFS2818584;
	Thu, 24 Apr 2003 11:28:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OFPD818454
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 11:25:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19807
	for <megaco@ietf.org>; Thu, 24 Apr 2003 11:22:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iaE-0006by-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:24:22 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 198iaD-0006b5-00
	for megaco@ietf.org; Thu, 24 Apr 2003 11:24:21 -0400
Received: from cisco.com (sjc-vpn2-380.cisco.com [10.21.113.124])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3OFNpID010810;
	Thu, 24 Apr 2003 08:23:51 -0700 (PDT)
Message-ID: <3EA80186.7538BEEB@cisco.com>
Date: Thu, 24 Apr 2003 11:23:50 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <3EA4074F.ADAFD2D9@cisco.com> <3EA488CE.55C88E88@ericsson.com.au> <3EA49E45.58FE4035@cisco.com> <3EA4CE5B.2C2AC97B@ericsson.com.au> <3EA58019.4090202@tekelec.com> <3EA6518B.862FDD51@alcatel.es> <3EA6FB72.8050208@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Adrian Soncodi wrote:

> Fernando,
>
> Thanks for the reply. See comments inline.
>
> Adrian
>
>
>
> Fernando Vallejo Lazaro wrote:
>
>> Hi all,
>>
>> Only some comments.
>>
>> - You say : "So while talking on A1-A1, the MGC cannot for example
>> audit on A2-A2, because this is immediately considered a failover
>> (...)". I don't think this is true.
>> If an MG receives an Audit from MGC-A2 (which it does not know) it
>> will reject the transaction because there is no association
>> established with it.
>
> Some MGs do this, others either don't reply or they failover. The
> latter may be in violation of the standard, but I think that's because
> it's not very well explained.
>

I think part of the problem here is that the concept of a control
association is not very well defined when it comes to UDP; how do you
determine if a message received is part of the UDP control association ?



>
> In my case, since I use the audits on A2-A2 as heartbeats (just to
> check for connectivity), any reply is OK, if only I get it. But this
> is a problem if some other MGC really wants to audit and is rejected.
> By the way, MGCP allows for this extra auditing, why is there a
> difference in approach? This only complicates things for an MGC which
> controls both MGCP and MEGACO MGs.
>
>> - If the MG is multi-homed you can provision the two IP static
>> addresses as primary and secondary MGCs. In case one fails it will
>> change to the other IP which in fact is the
>> same MGC.
>
> Yes, but if the failure (MGCs interface A1) occurs after the initial
> ServiceChange, sometimes during operations when the MG does not have
> any notifications to send, and if the MG does not do any heartbeats,
> then it won't be aware of the failure, it will just think it's idle.
> So it will not initiate ServiceChange to the "alternate" MGC.
> Furthermore, even if the MG receives a new command from MGC A2, as you
> showed above, it will reply with an error and remain idle. (By the
> way, where in the standard is this rule stated?)

Yes, however there are ways around this problem (by design, Megaco chose
to only have the MG be able to initiate the control association, so you
just need to make sure it does that - see H.248.14 for a solution).

There are however a couple of bad things here:
1. Only the statically provisioned list of backup MGCs can be contacted,
and only in the order they were provisioned.
2. The spec is silent on whether a backup MGC replicates the state of
the primary or not. Consequently, you cannot assume that it does, and
hence switching to the backup is something you don't want to do
prematurely.
3. The switchover is not graceful, i.e. there has to be a failure before
you start contacting the backup. In contrast, a more robust redundancy
scheme would detect/suspect the failure earlier during retransmission
and switch to one of the backups to prevent any loss of state.
Furthermore, there should be a way of indicating that a backup is fully
redundant and hence the switchover can be done fairly early without any
risk.


>> Maybe there should be a deep explanation of how to do this to smooth
>> the process because the MG does not know whether the secondary is an
>> independent
>> MGC, a backup or a mirror and depending on this information it can
>> behave in one way or another (e.g. a ServiceChange Request only
>> Informational)
>
> Here, I concur with you and with Flemming, there should be more
> explanations. If you take into account multiple IP addresses, DNS
> names translating to one or more IP addresses, MGs and MGCs working in
> active-standby mode with or without complete state synchronization, as
> well as multiple active-standby pairs handoff, things get complicated
> enough to be worth additional explanations.

Agreed - there is work to be done in this area.


>> - Another thing the MGC can do when it detects the that A1 is going
>> to die is to send a Handoff to the interface A2 for each MG so that
>> the connections are restablished
>> in the new path.
>
> This is what it's forced to do, but the MG is not aware that the
> handoff is to the same MGC. Consequently, it continues to send pending
> notifications to the old IP address, as per RFC 3015 section 7.2.8
> (and still in h248v2-04):
>
> "At the same time, as indicated in clause 9, transaction replies and
> pending indications must be sent to the address from which the
> corresponding requests originated."
>
> This forces the "new" MGC (which is not really new) to re-issue all
> the notification requests, which, apart from being a substantial
> overhead, can cause serious race conditions, especially with packages
> such as bcas. Again, from experience, this is a point of contention,
> whether or not it's the right behavior.
>
> If the MG were somehow aware that this is the same MGC, the signaling
> path switchover between A1-A1 and A2-A2 would be faster and more
> reliable.
>
> I think the MEGACO spec obviously did not consider multi-homed
> MGs/MGCs, therefore we are trying to see if the existing rules "happen
> to work" in this case. I have had a lot of arguments over it because
> of different interpretations.
>

I agree (and actually, I'm surprised nobody has addressed it yet because
it has been known for a long time and pops up on the mailing list from
time time, but without much progress being made).

-- Flemming



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 12:35:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22786
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 12:35:02 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGaT823527;
	Thu, 24 Apr 2003 12:36:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGXr823355
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 12:33:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22409
	for <megaco@ietf.org>; Thu, 24 Apr 2003 12:30:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198jee-00073p-00
	for megaco@ietf.org; Thu, 24 Apr 2003 12:33:00 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 198jed-00073d-00
	for megaco@ietf.org; Thu, 24 Apr 2003 12:32:59 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OGWtl08435
	for <megaco@ietf.org>; Thu, 24 Apr 2003 12:32:56 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96FACZ>; Thu, 24 Apr 2003 12:32:56 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Flemming Andreasen <fandreas@cisco.com>,
        Adrian Soncodi
	 <adrian.soncodi@tekelec.com>
Cc: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: RE: [Megaco] Support for redundant MG failover
Date: Thu, 24 Apr 2003 12:32:52 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Thursday, April 24, 2003 11:24 AM
To: Adrian Soncodi
Cc: Fernando Vallejo Lazaro; megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover




Adrian Soncodi wrote:

> Fernando,
>
> Thanks for the reply. See comments inline.
>
> Adrian
>
>
>
> Fernando Vallejo Lazaro wrote:
>
>> Hi all,
>>
>> Only some comments.
>>
>> - You say : "So while talking on A1-A1, the MGC cannot for example 
>> audit on A2-A2, because this is immediately considered a failover 
>> (...)". I don't think this is true. If an MG receives an Audit from 
>> MGC-A2 (which it does not know) it will reject the transaction 
>> because there is no association established with it.
>
> Some MGs do this, others either don't reply or they failover. The 
> latter may be in violation of the standard, but I think that's because 
> it's not very well explained.
>

I think part of the problem here is that the concept of a control
association is not very well defined when it comes to UDP; how do you
determine if a message received is part of the UDP control association ?

[KJBII] H.248 control associations have absolutely nothing to do with
transport.  To quote from the most recent version of Annex F: "A control
association is a communication relationship whereby an MGC is controlling an
MG.  A control association is instantiated via registration.  The control
association is terminated by the MG going out of service, being successfully
handed off to an alternate MGC, or successfully failing over to an alternate
MGC.  An MG shall have at most one control association at any time.  Only
MGs may instantiate control associations.  Control associations as defined
here apply only within the context of media gateway control signalling.
This definition should not be confused with that of control associations in
the context of transport (TCP, UDP, etc.)."

[KJBII] So, to go even further on the point above, the MG may "know" MGC-A2
(that is, have it in its list of MGCs), but because there can be only one
control association at any given time, and those associations are
established by the MG, the communication from MGC-A2 should be viewed as, at
best, an inappropriate control message.  At worst, it would be an attack to
attempt to gain control of the MG.  Also, I would like to note that an audit
command would never be construed as a failover.  Only a SC with a method of
failover would be a failover.



>
> In my case, since I use the audits on A2-A2 as heartbeats (just to 
> check for connectivity), any reply is OK, if only I get it. But this 
> is a problem if some other MGC really wants to audit and is rejected. 
> By the way, MGCP allows for this extra auditing, why is there a 
> difference in approach? This only complicates things for an MGC which 
> controls both MGCP and MEGACO MGs.

[KJBII] Megaco and MGCP are not the same.  There are many differences
between the two protocols, and this just happens to be one of them.

>
>> - If the MG is multi-homed you can provision the two IP static 
>> addresses as primary and secondary MGCs. In case one fails it will 
>> change to the other IP which in fact is the same MGC.
>
> Yes, but if the failure (MGCs interface A1) occurs after the initial 
> ServiceChange, sometimes during operations when the MG does not have 
> any notifications to send, and if the MG does not do any heartbeats, 
> then it won't be aware of the failure, it will just think it's idle. 
> So it will not initiate ServiceChange to the "alternate" MGC. 
> Furthermore, even if the MG receives a new command from MGC A2, as you 
> showed above, it will reply with an error and remain idle. (By the 
> way, where in the standard is this rule stated?)

Yes, however there are ways around this problem (by design, Megaco chose to
only have the MG be able to initiate the control association, so you just
need to make sure it does that - see H.248.14 for a solution).

There are however a couple of bad things here:
1. Only the statically provisioned list of backup MGCs can be contacted, and
only in the order they were provisioned. 

[KJBII] This is bad because?

2. The spec is silent on whether a backup MGC replicates the state of the
primary or not. Consequently, you cannot assume that it does, and hence
switching to the backup is something you don't want to do prematurely. 

[KJBII] Why is this the MGs concern?  The backup MGC is responsible for
getting itself attuned to the current state of affairs on the MG.  This can
be done in any number of ways, some of which are more detrimental to
existing connections than others.

3. The switchover is not graceful, i.e. there has to be a failure before you
start contacting the backup. In contrast, a more robust redundancy scheme
would detect/suspect the failure earlier during retransmission and switch to
one of the backups to prevent any loss of state. Furthermore, there should
be a way of indicating that a backup is fully redundant and hence the
switchover can be done fairly early without any risk.

[KJBII] Hmmm.  How would the MG know that the retransmissions were due to
MGC failure, as opposed to network congestion?  I believe that the MG will
have to wait for the retransmissions to run their course, or to utilize a
different method of determining that the MGC had failed that eliminates
network congestion as a possibility.


>> Maybe there should be a deep explanation of how to do this to smooth 
>> the process because the MG does not know whether the secondary is an 
>> independent MGC, a backup or a mirror and depending on this 
>> information it can behave in one way or another (e.g. a ServiceChange 
>> Request only
>> Informational)
>
> Here, I concur with you and with Flemming, there should be more 
> explanations. If you take into account multiple IP addresses, DNS 
> names translating to one or more IP addresses, MGs and MGCs working in 
> active-standby mode with or without complete state synchronization, as 
> well as multiple active-standby pairs handoff, things get complicated 
> enough to be worth additional explanations.

Agreed - there is work to be done in this area.


>> - Another thing the MGC can do when it detects the that A1 is going 
>> to die is to send a Handoff to the interface A2 for each MG so that 
>> the connections are restablished in the new path.
>
> This is what it's forced to do, but the MG is not aware that the 
> handoff is to the same MGC. Consequently, it continues to send pending 
> notifications to the old IP address, as per RFC 3015 section 7.2.8 
> (and still in h248v2-04):
>
> "At the same time, as indicated in clause 9, transaction replies and 
> pending indications must be sent to the address from which the 
> corresponding requests originated."
>
> This forces the "new" MGC (which is not really new) to re-issue all 
> the notification requests, which, apart from being a substantial 
> overhead, can cause serious race conditions, especially with packages 
> such as bcas. Again, from experience, this is a point of contention, 
> whether or not it's the right behavior.

[KJBII] Not true.  Any NEW event detections would go to the "new" MGC.
Remember, events in H.248 persist until a new events descriptor is sent to
replace the old.  Therefore, even through a handoff/failover, the MG should
continue to scan for events and report them to the controlling MGC -- the
"new" MGC once the handoff/failover occurs.

>
> If the MG were somehow aware that this is the same MGC, the signaling 
> path switchover between A1-A1 and A2-A2 would be faster and more 
> reliable.
>
> I think the MEGACO spec obviously did not consider multi-homed 
> MGs/MGCs, therefore we are trying to see if the existing rules "happen 
> to work" in this case. I have had a lot of arguments over it because 
> of different interpretations.
>

I agree (and actually, I'm surprised nobody has addressed it yet because it
has been known for a long time and pops up on the mailing list from time
time, but without much progress being made).

-- Flemming

[KJBII] There are many possibilities for redundancy -- multihoming is not
the only one.  Further, I don't see how the rules don't work, or how we can
optimize this particular case without penalizing the other possibilities.
The MG should not know, or care, that the MGC is multihomed.  The same goes
for the MGC with respect to the MG.  If you change IP addresses, then you
change control association, and that has consequences that have to be
rectified by the MGC.

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 12:36:07 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22855
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 12:36:07 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OGcoi24493
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 12:38:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGcn824490
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 12:38:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22829
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 12:35:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198jjQ-0007AM-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 12:37:56 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198jjQ-0007AJ-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 12:37:56 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGaT823527;
	Thu, 24 Apr 2003 12:36:29 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGXr823355
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 12:33:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22409
	for <megaco@ietf.org>; Thu, 24 Apr 2003 12:30:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198jee-00073p-00
	for megaco@ietf.org; Thu, 24 Apr 2003 12:33:00 -0400
Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55])
	by ietf-mx with esmtp (Exim 4.12)
	id 198jed-00073d-00
	for megaco@ietf.org; Thu, 24 Apr 2003 12:32:59 -0400
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35])
	by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3OGWtl08435
	for <megaco@ietf.org>; Thu, 24 Apr 2003 12:32:56 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2J96FACZ>; Thu, 24 Apr 2003 12:32:56 -0400
Message-ID: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com>
From: "Kevin Boyle" <kboyle@nortelnetworks.com>
To: Flemming Andreasen <fandreas@cisco.com>,
        Adrian Soncodi
	 <adrian.soncodi@tekelec.com>
Cc: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: RE: [Megaco] Support for redundant MG failover
Date: Thu, 24 Apr 2003 12:32:52 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] 
Sent: Thursday, April 24, 2003 11:24 AM
To: Adrian Soncodi
Cc: Fernando Vallejo Lazaro; megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover




Adrian Soncodi wrote:

> Fernando,
>
> Thanks for the reply. See comments inline.
>
> Adrian
>
>
>
> Fernando Vallejo Lazaro wrote:
>
>> Hi all,
>>
>> Only some comments.
>>
>> - You say : "So while talking on A1-A1, the MGC cannot for example 
>> audit on A2-A2, because this is immediately considered a failover 
>> (...)". I don't think this is true. If an MG receives an Audit from 
>> MGC-A2 (which it does not know) it will reject the transaction 
>> because there is no association established with it.
>
> Some MGs do this, others either don't reply or they failover. The 
> latter may be in violation of the standard, but I think that's because 
> it's not very well explained.
>

I think part of the problem here is that the concept of a control
association is not very well defined when it comes to UDP; how do you
determine if a message received is part of the UDP control association ?

[KJBII] H.248 control associations have absolutely nothing to do with
transport.  To quote from the most recent version of Annex F: "A control
association is a communication relationship whereby an MGC is controlling an
MG.  A control association is instantiated via registration.  The control
association is terminated by the MG going out of service, being successfully
handed off to an alternate MGC, or successfully failing over to an alternate
MGC.  An MG shall have at most one control association at any time.  Only
MGs may instantiate control associations.  Control associations as defined
here apply only within the context of media gateway control signalling.
This definition should not be confused with that of control associations in
the context of transport (TCP, UDP, etc.)."

[KJBII] So, to go even further on the point above, the MG may "know" MGC-A2
(that is, have it in its list of MGCs), but because there can be only one
control association at any given time, and those associations are
established by the MG, the communication from MGC-A2 should be viewed as, at
best, an inappropriate control message.  At worst, it would be an attack to
attempt to gain control of the MG.  Also, I would like to note that an audit
command would never be construed as a failover.  Only a SC with a method of
failover would be a failover.



>
> In my case, since I use the audits on A2-A2 as heartbeats (just to 
> check for connectivity), any reply is OK, if only I get it. But this 
> is a problem if some other MGC really wants to audit and is rejected. 
> By the way, MGCP allows for this extra auditing, why is there a 
> difference in approach? This only complicates things for an MGC which 
> controls both MGCP and MEGACO MGs.

[KJBII] Megaco and MGCP are not the same.  There are many differences
between the two protocols, and this just happens to be one of them.

>
>> - If the MG is multi-homed you can provision the two IP static 
>> addresses as primary and secondary MGCs. In case one fails it will 
>> change to the other IP which in fact is the same MGC.
>
> Yes, but if the failure (MGCs interface A1) occurs after the initial 
> ServiceChange, sometimes during operations when the MG does not have 
> any notifications to send, and if the MG does not do any heartbeats, 
> then it won't be aware of the failure, it will just think it's idle. 
> So it will not initiate ServiceChange to the "alternate" MGC. 
> Furthermore, even if the MG receives a new command from MGC A2, as you 
> showed above, it will reply with an error and remain idle. (By the 
> way, where in the standard is this rule stated?)

Yes, however there are ways around this problem (by design, Megaco chose to
only have the MG be able to initiate the control association, so you just
need to make sure it does that - see H.248.14 for a solution).

There are however a couple of bad things here:
1. Only the statically provisioned list of backup MGCs can be contacted, and
only in the order they were provisioned. 

[KJBII] This is bad because?

2. The spec is silent on whether a backup MGC replicates the state of the
primary or not. Consequently, you cannot assume that it does, and hence
switching to the backup is something you don't want to do prematurely. 

[KJBII] Why is this the MGs concern?  The backup MGC is responsible for
getting itself attuned to the current state of affairs on the MG.  This can
be done in any number of ways, some of which are more detrimental to
existing connections than others.

3. The switchover is not graceful, i.e. there has to be a failure before you
start contacting the backup. In contrast, a more robust redundancy scheme
would detect/suspect the failure earlier during retransmission and switch to
one of the backups to prevent any loss of state. Furthermore, there should
be a way of indicating that a backup is fully redundant and hence the
switchover can be done fairly early without any risk.

[KJBII] Hmmm.  How would the MG know that the retransmissions were due to
MGC failure, as opposed to network congestion?  I believe that the MG will
have to wait for the retransmissions to run their course, or to utilize a
different method of determining that the MGC had failed that eliminates
network congestion as a possibility.


>> Maybe there should be a deep explanation of how to do this to smooth 
>> the process because the MG does not know whether the secondary is an 
>> independent MGC, a backup or a mirror and depending on this 
>> information it can behave in one way or another (e.g. a ServiceChange 
>> Request only
>> Informational)
>
> Here, I concur with you and with Flemming, there should be more 
> explanations. If you take into account multiple IP addresses, DNS 
> names translating to one or more IP addresses, MGs and MGCs working in 
> active-standby mode with or without complete state synchronization, as 
> well as multiple active-standby pairs handoff, things get complicated 
> enough to be worth additional explanations.

Agreed - there is work to be done in this area.


>> - Another thing the MGC can do when it detects the that A1 is going 
>> to die is to send a Handoff to the interface A2 for each MG so that 
>> the connections are restablished in the new path.
>
> This is what it's forced to do, but the MG is not aware that the 
> handoff is to the same MGC. Consequently, it continues to send pending 
> notifications to the old IP address, as per RFC 3015 section 7.2.8 
> (and still in h248v2-04):
>
> "At the same time, as indicated in clause 9, transaction replies and 
> pending indications must be sent to the address from which the 
> corresponding requests originated."
>
> This forces the "new" MGC (which is not really new) to re-issue all 
> the notification requests, which, apart from being a substantial 
> overhead, can cause serious race conditions, especially with packages 
> such as bcas. Again, from experience, this is a point of contention, 
> whether or not it's the right behavior.

[KJBII] Not true.  Any NEW event detections would go to the "new" MGC.
Remember, events in H.248 persist until a new events descriptor is sent to
replace the old.  Therefore, even through a handoff/failover, the MG should
continue to scan for events and report them to the controlling MGC -- the
"new" MGC once the handoff/failover occurs.

>
> If the MG were somehow aware that this is the same MGC, the signaling 
> path switchover between A1-A1 and A2-A2 would be faster and more 
> reliable.
>
> I think the MEGACO spec obviously did not consider multi-homed 
> MGs/MGCs, therefore we are trying to see if the existing rules "happen 
> to work" in this case. I have had a lot of arguments over it because 
> of different interpretations.
>

I agree (and actually, I'm surprised nobody has addressed it yet because it
has been known for a long time and pops up on the mailing list from time
time, but without much progress being made).

-- Flemming

[KJBII] There are many possibilities for redundancy -- multihoming is not
the only one.  Further, I don't see how the rules don't work, or how we can
optimize this particular case without penalizing the other possibilities.
The MG should not know, or care, that the MGC is multihomed.  The same goes
for the MGC with respect to the MG.  If you change IP addresses, then you
change control association, and that has consequences that have to be
rectified by the MGC.

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 15:43:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00133
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 15:43:49 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJjX805368;
	Thu, 24 Apr 2003 15:45:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJgf805195
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 15:42:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29975
	for <megaco@ietf.org>; Thu, 24 Apr 2003 15:39:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198mbI-0000Zn-00
	for megaco@ietf.org; Thu, 24 Apr 2003 15:41:44 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198mbH-0000Zj-00
	for megaco@ietf.org; Thu, 24 Apr 2003 15:41:43 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042414413008:4085 ;
          Thu, 24 Apr 2003 14:41:30 -0500 
Message-ID: <3EA83F74.9070100@tekelec.com>
Date: Thu, 24 Apr 2003 14:48:04 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: Flemming Andreasen <fandreas@cisco.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/24/2003 02:41:30 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/24/2003 02:42:11 PM,
	Serialize complete at 04/24/2003 02:42:11 PM
Content-Type: multipart/alternative;
 boundary="------------050900060509020308060905"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------050900060509020308060905
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

More comments inline.

Adrian


Kevin Boyle wrote:

> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com ]
> Sent: Thursday, April 24, 2003 11:24 AM
> To: Adrian Soncodi
> Cc: Fernando Vallejo Lazaro; megaco@ietf.org
> Subject: Re: [Megaco] Support for redundant MG failover
>
>
>
>
> Adrian Soncodi wrote:
>
> > Fernando,
> >
> > Thanks for the reply. See comments inline.
> >
> > Adrian
> >
> >
> >
> > Fernando Vallejo Lazaro wrote:
> >
> >> Hi all,
> >>
> >> Only some comments.
> >>
> >> - You say : "So while talking on A1-A1, the MGC cannot for example
> >> audit on A2-A2, because this is immediately considered a failover
> >> (...)". I don't think this is true. If an MG receives an Audit from
> >> MGC-A2 (which it does not know) it will reject the transaction
> >> because there is no association established with it.
> >
> > Some MGs do this, others either don't reply or they failover. The
> > latter may be in violation of the standard, but I think that's because
> > it's not very well explained.
> >
>
> I think part of the problem here is that the concept of a control 
> association is not very well defined when it comes to UDP; how do you 
> determine if a message received is part of the UDP control association ?
>
> [KJBII] H.248 control associations have absolutely nothing to do with 
> transport.  To quote from the most recent version of Annex F: "A 
> control association is a communication relationship whereby an MGC is 
> controlling an MG.  A control association is instantiated via 
> registration.  The control association is terminated by the MG going 
> out of service, being successfully handed off to an alternate MGC, or 
> successfully failing over to an alternate MGC.  An MG shall have at 
> most one control association at any time.  Only MGs may instantiate 
> control associations.  Control associations as defined here apply only 
> within the context of media gateway control signalling.  This 
> definition should not be confused with that of control associations in 
> the context of transport (TCP, UDP, etc.)."
>
> [KJBII] So, to go even further on the point above, the MG may "know" 
> MGC-A2 (that is, have it in its list of MGCs), but because there can 
> be only one control association at any given time, and those 
> associations are established by the MG, the communication from MGC-A2 
> should be viewed as, at best, an inappropriate control message.  At 
> worst, it would be an attack to attempt to gain control of the MG.  
> Also, I would like to note that an audit command would never be 
> construed as a failover.  Only a SC with a method of failover would be 
> a failover.
>
>
Where does the standard specify that 1 association = 1 IP address? 
Flemming is right, I think the association is poorly defined. It is 
"implied" that 1 association = 1 MGC, but this is precisely what leads 
to confusion when the MGC is multi-homed.

I scanned the document, the association is first mentioned in section 
7.2.8 under 5) Handoff, but with no prior definition, and no definition 
is given further on. The definition you quote from Annex F (why is it 
not in the main document?) doesn't address my question either. Hence, 2 
possible interpretations for the MEGACO control association:

1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN 
(where a number of MGC-FQDN pairs can be provisioned on the MG). In this 
case, if the FQDN yields 2 IP addresses through DNS, then the MGC is 
multi-homed and the MG would know that. The MG can either create one 
SCTP association with the MGC, which would then take care of all the IP 
addresses, or (if SCTP is not supported) it could emulate this behavior 
using UDP. The latter obviously requires new procedures, quite simple in 
fact. But this would be very beneficial, because it would allow a 
redundancy schema with very robust and efficient switchover between 
signaling paths. Many MGs/MGCs could do this today easily, but there are 
interop problems because the exact procedures are not clearly stated.

2) If on the other side you would rather have it as 1 association = 1 IP 
address, then the standard should say that 1 MGC = 1 FQDN which should 
always yield exactly 1 IP address (otherwise it makes no sense). Also 
that a multi-homed MGC should be viewed as 2 distinct MGCs, with 2 
FQDNs, 2 IP addresses.

3) Lacking all that, the standard could at least say that multi-homed 
MGs are just not addressed, which leaves the possibility that procedures 
may be defined in future extensions. I keep telling people that this is 
the case,

In other words, in the current standard the model is not clear (the 
arity of these relationships), which is quite important.

I would prefer 1), because this is more uniform whatever the transport 
is. Under 2), SCTP doesn't even make much sense, it doesn't buy you much.

>
> >
> > In my case, since I use the audits on A2-A2 as heartbeats (just to
> > check for connectivity), any reply is OK, if only I get it. But this
> > is a problem if some other MGC really wants to audit and is rejected.
> > By the way, MGCP allows for this extra auditing, why is there a
> > difference in approach? This only complicates things for an MGC which
> > controls both MGCP and MEGACO MGs.
>
> [KJBII] Megaco and MGCP are not the same.  There are many differences 
> between the two protocols, and this just happens to be one of them.
>
> >
> >> - If the MG is multi-homed you can provision the two IP static
> >> addresses as primary and secondary MGCs. In case one fails it will
> >> change to the other IP which in fact is the same MGC.
> >
> > Yes, but if the failure (MGCs interface A1) occurs after the initial
> > ServiceChange, sometimes during operations when the MG does not have
> > any notifications to send, and if the MG does not do any heartbeats,
> > then it won't be aware of the failure, it will just think it's idle.
> > So it will not initiate ServiceChange to the "alternate" MGC.
> > Furthermore, even if the MG receives a new command from MGC A2, as you
> > showed above, it will reply with an error and remain idle. (By the
> > way, where in the standard is this rule stated?)
>
> Yes, however there are ways around this problem (by design, Megaco 
> chose to only have the MG be able to initiate the control association, 
> so you just need to make sure it does that - see H.248.14 for a solution).
>
> There are however a couple of bad things here:
> 1. Only the statically provisioned list of backup MGCs can be 
> contacted, and only in the order they were provisioned.
>
> [KJBII] This is bad because?
>
> 2. The spec is silent on whether a backup MGC replicates the state of 
> the primary or not. Consequently, you cannot assume that it does, and 
> hence switching to the backup is something you don't want to do 
> prematurely.
>
> [KJBII] Why is this the MGs concern?  The backup MGC is responsible 
> for getting itself attuned to the current state of affairs on the MG.  
> This can be done in any number of ways, some of which are more 
> detrimental to existing connections than others.
>
> 3. The switchover is not graceful, i.e. there has to be a failure 
> before you start contacting the backup. In contrast, a more robust 
> redundancy scheme would detect/suspect the failure earlier during 
> retransmission and switch to one of the backups to prevent any loss of 
> state. Furthermore, there should be a way of indicating that a backup 
> is fully redundant and hence the switchover can be done fairly early 
> without any risk.
>
> [KJBII] Hmmm.  How would the MG know that the retransmissions were due 
> to MGC failure, as opposed to network congestion?  I believe that the 
> MG will have to wait for the retransmissions to run their course, or 
> to utilize a different method of determining that the MGC had failed 
> that eliminates network congestion as a possibility.
>
>
> >> Maybe there should be a deep explanation of how to do this to smooth
> >> the process because the MG does not know whether the secondary is an
> >> independent MGC, a backup or a mirror and depending on this
> >> information it can behave in one way or another (e.g. a ServiceChange
> >> Request only
> >> Informational)
> >
> > Here, I concur with you and with Flemming, there should be more
> > explanations. If you take into account multiple IP addresses, DNS
> > names translating to one or more IP addresses, MGs and MGCs working in
> > active-standby mode with or without complete state synchronization, as
> > well as multiple active-standby pairs handoff, things get complicated
> > enough to be worth additional explanations.
>
> Agreed - there is work to be done in this area.
>
>
> >> - Another thing the MGC can do when it detects the that A1 is going
> >> to die is to send a Handoff to the interface A2 for each MG so that
> >> the connections are restablished in the new path.
> >
> > This is what it's forced to do, but the MG is not aware that the
> > handoff is to the same MGC. Consequently, it continues to send pending
> > notifications to the old IP address, as per RFC 3015 section 7.2.8
> > (and still in h248v2-04):
> >
> > "At the same time, as indicated in clause 9, transaction replies and
> > pending indications must be sent to the address from which the
> > corresponding requests originated."
> >
> > This forces the "new" MGC (which is not really new) to re-issue all
> > the notification requests, which, apart from being a substantial
> > overhead, can cause serious race conditions, especially with packages
> > such as bcas. Again, from experience, this is a point of contention,
> > whether or not it's the right behavior.
>
> [KJBII] Not true.  Any NEW event detections would go to the "new" 
> MGC.  Remember, events in H.248 persist until a new events descriptor 
> is sent to replace the old.  Therefore, even through a 
> handoff/failover, the MG should continue to scan for events and report 
> them to the controlling MGC -- the "new" MGC once the handoff/failover 
> occurs.
>
For new event notifications, I agree with you that this should be the 
behavior. But can you point out the text that backs your statement? 
Because I've been pointed to the text I quoted above by an MG vendor, as 
a reason to implement it the other way around (continue to send  events 
to the old IP address). And yes, I'm talking about the same events 
descriptor that persists.

For replies and their retransmissions, I don't know ... For example, if 
you send an audit just to check for connectivity on a given path 
(A2-A2), then it would be important that replies go back where the 
request came from. So maybe the text I quoted should not put replies and 
indications in the same bin.

> >
> > If the MG were somehow aware that this is the same MGC, the signaling
> > path switchover between A1-A1 and A2-A2 would be faster and more
> > reliable.
> >
> > I think the MEGACO spec obviously did not consider multi-homed
> > MGs/MGCs, therefore we are trying to see if the existing rules "happen
> > to work" in this case. I have had a lot of arguments over it because
> > of different interpretations.
> >
>
> I agree (and actually, I'm surprised nobody has addressed it yet 
> because it has been known for a long time and pops up on the mailing 
> list from time time, but without much progress being made).
>
> -- Flemming
>
> [KJBII] There are many possibilities for redundancy -- multihoming is 
> not the only one.  Further, I don't see how the rules don't work, or 
> how we can optimize this particular case without penalizing the other 
> possibilities.  The MG should not know, or care, that the MGC is 
> multihomed.  The same goes for the MGC with respect to the MG.  If you 
> change IP addresses, then you change control association, and that has 
> consequences that have to be rectified by the MGC.
>
I tend to disagree with this, see comments above. Again, you imply that 
1 association = 1 IP address, but if this is the case, it must be stated 
clearly.

> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


--------------050900060509020308060905
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
More comments inline.<br>
<br>
Adrian<br>
<br>
<br>
Kevin Boyle wrote:<br>
<blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com">
  <meta name="Generator" content="MS Exchange Server version 5.5.2656.31">
  <title>RE: [Megaco] Support for redundant MG failover</title>
  <p><font size="2">Comments inline. [KJBII]</font></p>
  <p><font size="2">Kevin</font></p>
  <p><font size="2">-----Original Message-----</font><br>
  <font size="2">From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">
mailto:fandreas@cisco.com</a>
] </font><br>
  <font size="2">Sent: Thursday, April 24, 2003 11:24 AM</font><br>
  <font size="2">To: Adrian Soncodi</font><br>
  <font size="2">Cc: Fernando Vallejo Lazaro; <a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">Subject: Re: [Megaco] Support for redundant MG failover</font></p>
  <br>
  <br>
  <br>
  <p><font size="2">Adrian Soncodi wrote:</font></p>
  <p><font size="2">&gt; Fernando,</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Thanks for the reply. See comments inline.</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Adrian</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Fernando Vallejo Lazaro wrote:</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt;&gt; Hi all,</font><br>
  <font size="2">&gt;&gt;</font><br>
  <font size="2">&gt;&gt; Only some comments.</font><br>
  <font size="2">&gt;&gt;</font><br>
  <font size="2">&gt;&gt; - You say : "So while talking on A1-A1, the MGC
cannot for example </font><br>
  <font size="2">&gt;&gt; audit on A2-A2, because this is immediately considered
a failover </font><br>
  <font size="2">&gt;&gt; (...)". I don't think this is true. If an MG receives
an Audit from </font><br>
  <font size="2">&gt;&gt; MGC-A2 (which it does not know) it will reject
the transaction </font><br>
  <font size="2">&gt;&gt; because there is no association established with
it.</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Some MGs do this, others either don't reply or they
failover. The </font><br>
  <font size="2">&gt; latter may be in violation of the standard, but I think
that's because </font><br>
  <font size="2">&gt; it's not very well explained.</font><br>
  <font size="2">&gt;</font></p>
  <p><font size="2">I think part of the problem here is that the concept
of a control association is not very well defined when it comes to UDP; how
do you determine if a message received is part of the UDP control association
?</font></p>
  <p><font size="2">[KJBII] H.248 control associations have absolutely nothing
to do with transport.&nbsp; To quote from the most recent version of Annex F:
"A control association is a communication relationship whereby an MGC is
controlling an MG.&nbsp; A control association is instantiated via registration.&nbsp;
The control association is terminated by the MG going out of service, being
successfully handed off to an alternate MGC, or successfully failing over
to an alternate MGC.&nbsp; An MG shall have at most one control association at
any time.&nbsp; Only MGs may instantiate control associations.&nbsp; Control associations
as defined here apply only within the context of media gateway control signalling.&nbsp;
This definition should not be confused with that of control associations
in the context of transport (TCP, UDP, etc.)."</font></p>
  <p><font size="2">[KJBII] So, to go even further on the point above, the
MG may "know" MGC-A2 (that is, have it in its list of MGCs), but because
there can be only one control association at any given time, and those associations
are established by the MG, the communication from MGC-A2 should be viewed
as, at best, an inappropriate control message.&nbsp; At worst, it would be an
attack to attempt to gain control of the MG.&nbsp; Also, I would like to note
that an audit command would never be construed as a failover.&nbsp; Only a SC
with a method of failover would be a failover.</font></p>
  <br>
  </blockquote>
Where does the standard specify that 1 association = 1 IP address? Flemming
is right, I think the association is poorly defined. It is "implied" that
1 association = 1 MGC, but this is precisely what leads to confusion when
the MGC is multi-homed.<br>
  <br>
I scanned the document, the association is first mentioned in section 7.2.8
under 5) Handoff, but with no prior definition, and no definition is given
further on. The definition you quote from Annex F (why is it not in the main
document?) doesn't address my question either. Hence, 2 possible interpretations
for the MEGACO control association:<br>
  <br>
1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN (where
a number of MGC-FQDN pairs can be provisioned on the MG). In this case, if
the FQDN yields 2 IP addresses through DNS, then the MGC is multi-homed and
the MG would know that. The MG can either create one SCTP association with
the MGC, which would then take care of all the IP addresses, or (if SCTP
is not supported) it could emulate this behavior using UDP. The latter obviously
requires new procedures, quite simple in fact. But this would be very beneficial,
because it would allow a redundancy schema with very robust and efficient
switchover between signaling paths. Many MGs/MGCs could do this today easily,
but there are interop problems because the exact procedures are not clearly
stated.<br>
  <br>
2) If on the other side you would rather have it as 1 association = 1 IP
address, then the standard should say that 1 MGC = 1 FQDN which should always
yield exactly 1 IP address (otherwise it makes no sense). Also that a multi-homed
MGC should be viewed as 2 distinct MGCs, with 2 FQDNs, 2 IP addresses.<br>
  <br>
3) Lacking all that, the standard could at least say that multi-homed MGs
are just not addressed, which leaves the possibility that procedures may
be defined in future extensions. I keep telling people that this is the case,
  <br>
  <br>
In other words, in the current standard the model is not clear (the arity
of these relationships), which is quite important.<br>
  <br>
I would prefer 1), because this is more uniform whatever the transport is.
Under 2), SCTP doesn't even make much sense, it doesn't buy you much.<br>
  <blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com"><br>
    <p><font size="2">&gt;</font><br>
    <font size="2">&gt; In my case, since I use the audits on A2-A2 as heartbeats
(just to </font><br>
    <font size="2">&gt; check for connectivity), any reply is OK, if only
I get it. But this </font><br>
    <font size="2">&gt; is a problem if some other MGC really wants to audit
and is rejected. </font><br>
    <font size="2">&gt; By the way, MGCP allows for this extra auditing,
why is there a </font><br>
    <font size="2">&gt; difference in approach? This only complicates things
for an MGC which </font><br>
    <font size="2">&gt; controls both MGCP and MEGACO MGs.</font></p>
    <p><font size="2">[KJBII] Megaco and MGCP are not the same.&nbsp; There are
many differences between the two protocols, and this just happens to be one
of them.</font></p>
    <p><font size="2">&gt;</font><br>
    <font size="2">&gt;&gt; - If the MG is multi-homed you can provision
the two IP static </font><br>
    <font size="2">&gt;&gt; addresses as primary and secondary MGCs. In case
one fails it will </font><br>
    <font size="2">&gt;&gt; change to the other IP which in fact is the same
MGC.</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; Yes, but if the failure (MGCs interface A1) occurs
after the initial </font><br>
    <font size="2">&gt; ServiceChange, sometimes during operations when the
MG does not have </font><br>
    <font size="2">&gt; any notifications to send, and if the MG does not
do any heartbeats, </font><br>
    <font size="2">&gt; then it won't be aware of the failure, it will just
think it's idle. </font><br>
    <font size="2">&gt; So it will not initiate ServiceChange to the "alternate"
MGC. </font><br>
    <font size="2">&gt; Furthermore, even if the MG receives a new command
from MGC A2, as you </font><br>
    <font size="2">&gt; showed above, it will reply with an error and remain
idle. (By the </font><br>
    <font size="2">&gt; way, where in the standard is this rule stated?)</font></p>
    <p><font size="2">Yes, however there are ways around this problem (by
design, Megaco chose to only have the MG be able to initiate the control
association, so you just need to make sure it does that - see H.248.14 for
a solution).</font></p>
    <p><font size="2">There are however a couple of bad things here:</font><br>
    <font size="2">1. Only the statically provisioned list of backup MGCs
can be contacted, and only in the order they were provisioned. </font></p>
    <p><font size="2">[KJBII] This is bad because?</font></p>
    <p><font size="2">2. The spec is silent on whether a backup MGC replicates
the state of the primary or not. Consequently, you cannot assume that it
does, and hence switching to the backup is something you don't want to do
prematurely. </font></p>
    <p><font size="2">[KJBII] Why is this the MGs concern?&nbsp; The backup MGC
is responsible for getting itself attuned to the current state of affairs
on the MG.&nbsp; This can be done in any number of ways, some of which are more
detrimental to existing connections than others.</font></p>
    <p><font size="2">3. The switchover is not graceful, i.e. there has to
be a failure before you start contacting the backup. In contrast, a more
robust redundancy scheme would detect/suspect the failure earlier during
retransmission and switch to one of the backups to prevent any loss of state.
Furthermore, there should be a way of indicating that a backup is fully redundant
and hence the switchover can be done fairly early without any risk.</font></p>
    <p><font size="2">[KJBII] Hmmm.&nbsp; How would the MG know that the retransmissions
were due to MGC failure, as opposed to network congestion?&nbsp; I believe that
the MG will have to wait for the retransmissions to run their course, or
to utilize a different method of determining that the MGC had failed that
eliminates network congestion as a possibility.</font></p>
    <br>
    <p><font size="2">&gt;&gt; Maybe there should be a deep explanation of
how to do this to smooth </font><br>
    <font size="2">&gt;&gt; the process because the MG does not know whether
the secondary is an </font><br>
    <font size="2">&gt;&gt; independent MGC, a backup or a mirror and depending
on this </font><br>
    <font size="2">&gt;&gt; information it can behave in one way or another
(e.g. a ServiceChange </font><br>
    <font size="2">&gt;&gt; Request only</font><br>
    <font size="2">&gt;&gt; Informational)</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; Here, I concur with you and with Flemming, there
should be more </font><br>
    <font size="2">&gt; explanations. If you take into account multiple IP
addresses, DNS </font><br>
    <font size="2">&gt; names translating to one or more IP addresses, MGs
and MGCs working in </font><br>
    <font size="2">&gt; active-standby mode with or without complete state
synchronization, as </font><br>
    <font size="2">&gt; well as multiple active-standby pairs handoff, things
get complicated </font><br>
    <font size="2">&gt; enough to be worth additional explanations.</font></p>
    <p><font size="2">Agreed - there is work to be done in this area.</font></p>
    <br>
    <p><font size="2">&gt;&gt; - Another thing the MGC can do when it detects
the that A1 is going </font><br>
    <font size="2">&gt;&gt; to die is to send a Handoff to the interface
A2 for each MG so that </font><br>
    <font size="2">&gt;&gt; the connections are restablished in the new path.</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; This is what it's forced to do, but the MG is not
aware that the </font><br>
    <font size="2">&gt; handoff is to the same MGC. Consequently, it continues
to send pending </font><br>
    <font size="2">&gt; notifications to the old IP address, as per RFC 3015
section 7.2.8 </font><br>
    <font size="2">&gt; (and still in h248v2-04):</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; "At the same time, as indicated in clause 9, transaction
replies and </font><br>
    <font size="2">&gt; pending indications must be sent to the address from
which the </font><br>
    <font size="2">&gt; corresponding requests originated."</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; This forces the "new" MGC (which is not really new)
to re-issue all </font><br>
    <font size="2">&gt; the notification requests, which, apart from being
a substantial </font><br>
    <font size="2">&gt; overhead, can cause serious race conditions, especially
with packages </font><br>
    <font size="2">&gt; such as bcas. Again, from experience, this is a point
of contention, </font><br>
    <font size="2">&gt; whether or not it's the right behavior.</font></p>
    <p><font size="2">[KJBII] Not true.&nbsp; Any NEW event detections would go
to the "new" MGC.&nbsp; Remember, events in H.248 persist until a new events descriptor
is sent to replace the old.&nbsp; Therefore, even through a handoff/failover,
the MG should continue to scan for events and report them to the controlling
MGC -- the "new" MGC once the handoff/failover occurs.</font></p>
    </blockquote>
For new event notifications, I agree with you that this should be the behavior.
But can you point out the text that backs your statement? Because I've been
pointed to the text I quoted above by an MG vendor, as a reason to implement
it the other way around (continue to send &nbsp;events to the old IP address).
And yes, I'm talking about the same events descriptor that persists.<br>
    <br>
For replies and their retransmissions, I don't know ... For example, if you
send an audit just to check for connectivity on a given path (A2-A2), then
it would be important that replies go back where the request came from. So
maybe the text I quoted should not put replies and indications in the same
bin.<br>
    <blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com">
      <p><font size="2">&gt;</font><br>
      <font size="2">&gt; If the MG were somehow aware that this is the same
MGC, the signaling </font><br>
      <font size="2">&gt; path switchover between A1-A1 and A2-A2 would be
faster and more </font><br>
      <font size="2">&gt; reliable.</font><br>
      <font size="2">&gt;</font><br>
      <font size="2">&gt; I think the MEGACO spec obviously did not consider
multi-homed </font><br>
      <font size="2">&gt; MGs/MGCs, therefore we are trying to see if the
existing rules "happen </font><br>
      <font size="2">&gt; to work" in this case. I have had a lot of arguments
over it because </font><br>
      <font size="2">&gt; of different interpretations.</font><br>
      <font size="2">&gt;</font></p>
      <p><font size="2">I agree (and actually, I'm surprised nobody has addressed
it yet because it has been known for a long time and pops up on the mailing
list from time time, but without much progress being made).</font></p>
      <p><font size="2">-- Flemming</font></p>
      <p><font size="2">[KJBII] There are many possibilities for redundancy
-- multihoming is not the only one.&nbsp; Further, I don't see how the rules don't
work, or how we can optimize this particular case without penalizing the
other possibilities.&nbsp; The MG should not know, or care, that the MGC is multihomed.&nbsp;
The same goes for the MGC with respect to the MG.&nbsp; If you change IP addresses,
then you change control association, and that has consequences that have
to be rectified by the MGC.</font></p>
      </blockquote>
I tend to disagree with this, see comments above. Again, you imply that 1
association = 1 IP address, but if this is the case, it must be stated clearly.<br>
      <blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com">
        <p><font size="2">_______________________________________________</font><br>
        <font size="2">Megaco mailing list</font><br>
        <font size="2"><a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a></font><br>
        <font size="2"><a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
        </font></p>
        </blockquote>
        <br>
        </body>
        </html>

--------------050900060509020308060905--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 15:44:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00188
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 15:44:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3OJlew05556
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 15:47:40 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJle805553
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 15:47:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00170
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 15:44:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198mg7-0000ck-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 15:46:43 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198mg6-0000ch-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 15:46:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJjX805368;
	Thu, 24 Apr 2003 15:45:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OJgf805195
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 15:42:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29975
	for <megaco@ietf.org>; Thu, 24 Apr 2003 15:39:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198mbI-0000Zn-00
	for megaco@ietf.org; Thu, 24 Apr 2003 15:41:44 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198mbH-0000Zj-00
	for megaco@ietf.org; Thu, 24 Apr 2003 15:41:43 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042414413008:4085 ;
          Thu, 24 Apr 2003 14:41:30 -0500 
Message-ID: <3EA83F74.9070100@tekelec.com>
Date: Thu, 24 Apr 2003 14:48:04 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: Flemming Andreasen <fandreas@cisco.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/24/2003 02:41:30 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/24/2003 02:42:11 PM,
	Serialize complete at 04/24/2003 02:42:11 PM
Content-Type: multipart/alternative;
 boundary="------------050900060509020308060905"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------050900060509020308060905
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

More comments inline.

Adrian


Kevin Boyle wrote:

> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: Flemming Andreasen [ mailto:fandreas@cisco.com ]
> Sent: Thursday, April 24, 2003 11:24 AM
> To: Adrian Soncodi
> Cc: Fernando Vallejo Lazaro; megaco@ietf.org
> Subject: Re: [Megaco] Support for redundant MG failover
>
>
>
>
> Adrian Soncodi wrote:
>
> > Fernando,
> >
> > Thanks for the reply. See comments inline.
> >
> > Adrian
> >
> >
> >
> > Fernando Vallejo Lazaro wrote:
> >
> >> Hi all,
> >>
> >> Only some comments.
> >>
> >> - You say : "So while talking on A1-A1, the MGC cannot for example
> >> audit on A2-A2, because this is immediately considered a failover
> >> (...)". I don't think this is true. If an MG receives an Audit from
> >> MGC-A2 (which it does not know) it will reject the transaction
> >> because there is no association established with it.
> >
> > Some MGs do this, others either don't reply or they failover. The
> > latter may be in violation of the standard, but I think that's because
> > it's not very well explained.
> >
>
> I think part of the problem here is that the concept of a control 
> association is not very well defined when it comes to UDP; how do you 
> determine if a message received is part of the UDP control association ?
>
> [KJBII] H.248 control associations have absolutely nothing to do with 
> transport.  To quote from the most recent version of Annex F: "A 
> control association is a communication relationship whereby an MGC is 
> controlling an MG.  A control association is instantiated via 
> registration.  The control association is terminated by the MG going 
> out of service, being successfully handed off to an alternate MGC, or 
> successfully failing over to an alternate MGC.  An MG shall have at 
> most one control association at any time.  Only MGs may instantiate 
> control associations.  Control associations as defined here apply only 
> within the context of media gateway control signalling.  This 
> definition should not be confused with that of control associations in 
> the context of transport (TCP, UDP, etc.)."
>
> [KJBII] So, to go even further on the point above, the MG may "know" 
> MGC-A2 (that is, have it in its list of MGCs), but because there can 
> be only one control association at any given time, and those 
> associations are established by the MG, the communication from MGC-A2 
> should be viewed as, at best, an inappropriate control message.  At 
> worst, it would be an attack to attempt to gain control of the MG.  
> Also, I would like to note that an audit command would never be 
> construed as a failover.  Only a SC with a method of failover would be 
> a failover.
>
>
Where does the standard specify that 1 association = 1 IP address? 
Flemming is right, I think the association is poorly defined. It is 
"implied" that 1 association = 1 MGC, but this is precisely what leads 
to confusion when the MGC is multi-homed.

I scanned the document, the association is first mentioned in section 
7.2.8 under 5) Handoff, but with no prior definition, and no definition 
is given further on. The definition you quote from Annex F (why is it 
not in the main document?) doesn't address my question either. Hence, 2 
possible interpretations for the MEGACO control association:

1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN 
(where a number of MGC-FQDN pairs can be provisioned on the MG). In this 
case, if the FQDN yields 2 IP addresses through DNS, then the MGC is 
multi-homed and the MG would know that. The MG can either create one 
SCTP association with the MGC, which would then take care of all the IP 
addresses, or (if SCTP is not supported) it could emulate this behavior 
using UDP. The latter obviously requires new procedures, quite simple in 
fact. But this would be very beneficial, because it would allow a 
redundancy schema with very robust and efficient switchover between 
signaling paths. Many MGs/MGCs could do this today easily, but there are 
interop problems because the exact procedures are not clearly stated.

2) If on the other side you would rather have it as 1 association = 1 IP 
address, then the standard should say that 1 MGC = 1 FQDN which should 
always yield exactly 1 IP address (otherwise it makes no sense). Also 
that a multi-homed MGC should be viewed as 2 distinct MGCs, with 2 
FQDNs, 2 IP addresses.

3) Lacking all that, the standard could at least say that multi-homed 
MGs are just not addressed, which leaves the possibility that procedures 
may be defined in future extensions. I keep telling people that this is 
the case,

In other words, in the current standard the model is not clear (the 
arity of these relationships), which is quite important.

I would prefer 1), because this is more uniform whatever the transport 
is. Under 2), SCTP doesn't even make much sense, it doesn't buy you much.

>
> >
> > In my case, since I use the audits on A2-A2 as heartbeats (just to
> > check for connectivity), any reply is OK, if only I get it. But this
> > is a problem if some other MGC really wants to audit and is rejected.
> > By the way, MGCP allows for this extra auditing, why is there a
> > difference in approach? This only complicates things for an MGC which
> > controls both MGCP and MEGACO MGs.
>
> [KJBII] Megaco and MGCP are not the same.  There are many differences 
> between the two protocols, and this just happens to be one of them.
>
> >
> >> - If the MG is multi-homed you can provision the two IP static
> >> addresses as primary and secondary MGCs. In case one fails it will
> >> change to the other IP which in fact is the same MGC.
> >
> > Yes, but if the failure (MGCs interface A1) occurs after the initial
> > ServiceChange, sometimes during operations when the MG does not have
> > any notifications to send, and if the MG does not do any heartbeats,
> > then it won't be aware of the failure, it will just think it's idle.
> > So it will not initiate ServiceChange to the "alternate" MGC.
> > Furthermore, even if the MG receives a new command from MGC A2, as you
> > showed above, it will reply with an error and remain idle. (By the
> > way, where in the standard is this rule stated?)
>
> Yes, however there are ways around this problem (by design, Megaco 
> chose to only have the MG be able to initiate the control association, 
> so you just need to make sure it does that - see H.248.14 for a solution).
>
> There are however a couple of bad things here:
> 1. Only the statically provisioned list of backup MGCs can be 
> contacted, and only in the order they were provisioned.
>
> [KJBII] This is bad because?
>
> 2. The spec is silent on whether a backup MGC replicates the state of 
> the primary or not. Consequently, you cannot assume that it does, and 
> hence switching to the backup is something you don't want to do 
> prematurely.
>
> [KJBII] Why is this the MGs concern?  The backup MGC is responsible 
> for getting itself attuned to the current state of affairs on the MG.  
> This can be done in any number of ways, some of which are more 
> detrimental to existing connections than others.
>
> 3. The switchover is not graceful, i.e. there has to be a failure 
> before you start contacting the backup. In contrast, a more robust 
> redundancy scheme would detect/suspect the failure earlier during 
> retransmission and switch to one of the backups to prevent any loss of 
> state. Furthermore, there should be a way of indicating that a backup 
> is fully redundant and hence the switchover can be done fairly early 
> without any risk.
>
> [KJBII] Hmmm.  How would the MG know that the retransmissions were due 
> to MGC failure, as opposed to network congestion?  I believe that the 
> MG will have to wait for the retransmissions to run their course, or 
> to utilize a different method of determining that the MGC had failed 
> that eliminates network congestion as a possibility.
>
>
> >> Maybe there should be a deep explanation of how to do this to smooth
> >> the process because the MG does not know whether the secondary is an
> >> independent MGC, a backup or a mirror and depending on this
> >> information it can behave in one way or another (e.g. a ServiceChange
> >> Request only
> >> Informational)
> >
> > Here, I concur with you and with Flemming, there should be more
> > explanations. If you take into account multiple IP addresses, DNS
> > names translating to one or more IP addresses, MGs and MGCs working in
> > active-standby mode with or without complete state synchronization, as
> > well as multiple active-standby pairs handoff, things get complicated
> > enough to be worth additional explanations.
>
> Agreed - there is work to be done in this area.
>
>
> >> - Another thing the MGC can do when it detects the that A1 is going
> >> to die is to send a Handoff to the interface A2 for each MG so that
> >> the connections are restablished in the new path.
> >
> > This is what it's forced to do, but the MG is not aware that the
> > handoff is to the same MGC. Consequently, it continues to send pending
> > notifications to the old IP address, as per RFC 3015 section 7.2.8
> > (and still in h248v2-04):
> >
> > "At the same time, as indicated in clause 9, transaction replies and
> > pending indications must be sent to the address from which the
> > corresponding requests originated."
> >
> > This forces the "new" MGC (which is not really new) to re-issue all
> > the notification requests, which, apart from being a substantial
> > overhead, can cause serious race conditions, especially with packages
> > such as bcas. Again, from experience, this is a point of contention,
> > whether or not it's the right behavior.
>
> [KJBII] Not true.  Any NEW event detections would go to the "new" 
> MGC.  Remember, events in H.248 persist until a new events descriptor 
> is sent to replace the old.  Therefore, even through a 
> handoff/failover, the MG should continue to scan for events and report 
> them to the controlling MGC -- the "new" MGC once the handoff/failover 
> occurs.
>
For new event notifications, I agree with you that this should be the 
behavior. But can you point out the text that backs your statement? 
Because I've been pointed to the text I quoted above by an MG vendor, as 
a reason to implement it the other way around (continue to send  events 
to the old IP address). And yes, I'm talking about the same events 
descriptor that persists.

For replies and their retransmissions, I don't know ... For example, if 
you send an audit just to check for connectivity on a given path 
(A2-A2), then it would be important that replies go back where the 
request came from. So maybe the text I quoted should not put replies and 
indications in the same bin.

> >
> > If the MG were somehow aware that this is the same MGC, the signaling
> > path switchover between A1-A1 and A2-A2 would be faster and more
> > reliable.
> >
> > I think the MEGACO spec obviously did not consider multi-homed
> > MGs/MGCs, therefore we are trying to see if the existing rules "happen
> > to work" in this case. I have had a lot of arguments over it because
> > of different interpretations.
> >
>
> I agree (and actually, I'm surprised nobody has addressed it yet 
> because it has been known for a long time and pops up on the mailing 
> list from time time, but without much progress being made).
>
> -- Flemming
>
> [KJBII] There are many possibilities for redundancy -- multihoming is 
> not the only one.  Further, I don't see how the rules don't work, or 
> how we can optimize this particular case without penalizing the other 
> possibilities.  The MG should not know, or care, that the MGC is 
> multihomed.  The same goes for the MGC with respect to the MG.  If you 
> change IP addresses, then you change control association, and that has 
> consequences that have to be rectified by the MGC.
>
I tend to disagree with this, see comments above. Again, you imply that 
1 association = 1 IP address, but if this is the case, it must be stated 
clearly.

> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>


--------------050900060509020308060905
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
More comments inline.<br>
<br>
Adrian<br>
<br>
<br>
Kevin Boyle wrote:<br>
<blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com">
  <meta name="Generator" content="MS Exchange Server version 5.5.2656.31">
  <title>RE: [Megaco] Support for redundant MG failover</title>
  <p><font size="2">Comments inline. [KJBII]</font></p>
  <p><font size="2">Kevin</font></p>
  <p><font size="2">-----Original Message-----</font><br>
  <font size="2">From: Flemming Andreasen [<a href="mailto:fandreas@cisco.com">
mailto:fandreas@cisco.com</a>
] </font><br>
  <font size="2">Sent: Thursday, April 24, 2003 11:24 AM</font><br>
  <font size="2">To: Adrian Soncodi</font><br>
  <font size="2">Cc: Fernando Vallejo Lazaro; <a class="moz-txt-link-abbreviated" href="mailto:megaco@ietf.org">megaco@ietf.org</a></font><br>
  <font size="2">Subject: Re: [Megaco] Support for redundant MG failover</font></p>
  <br>
  <br>
  <br>
  <p><font size="2">Adrian Soncodi wrote:</font></p>
  <p><font size="2">&gt; Fernando,</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Thanks for the reply. See comments inline.</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Adrian</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Fernando Vallejo Lazaro wrote:</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt;&gt; Hi all,</font><br>
  <font size="2">&gt;&gt;</font><br>
  <font size="2">&gt;&gt; Only some comments.</font><br>
  <font size="2">&gt;&gt;</font><br>
  <font size="2">&gt;&gt; - You say : "So while talking on A1-A1, the MGC
cannot for example </font><br>
  <font size="2">&gt;&gt; audit on A2-A2, because this is immediately considered
a failover </font><br>
  <font size="2">&gt;&gt; (...)". I don't think this is true. If an MG receives
an Audit from </font><br>
  <font size="2">&gt;&gt; MGC-A2 (which it does not know) it will reject
the transaction </font><br>
  <font size="2">&gt;&gt; because there is no association established with
it.</font><br>
  <font size="2">&gt;</font><br>
  <font size="2">&gt; Some MGs do this, others either don't reply or they
failover. The </font><br>
  <font size="2">&gt; latter may be in violation of the standard, but I think
that's because </font><br>
  <font size="2">&gt; it's not very well explained.</font><br>
  <font size="2">&gt;</font></p>
  <p><font size="2">I think part of the problem here is that the concept
of a control association is not very well defined when it comes to UDP; how
do you determine if a message received is part of the UDP control association
?</font></p>
  <p><font size="2">[KJBII] H.248 control associations have absolutely nothing
to do with transport.&nbsp; To quote from the most recent version of Annex F:
"A control association is a communication relationship whereby an MGC is
controlling an MG.&nbsp; A control association is instantiated via registration.&nbsp;
The control association is terminated by the MG going out of service, being
successfully handed off to an alternate MGC, or successfully failing over
to an alternate MGC.&nbsp; An MG shall have at most one control association at
any time.&nbsp; Only MGs may instantiate control associations.&nbsp; Control associations
as defined here apply only within the context of media gateway control signalling.&nbsp;
This definition should not be confused with that of control associations
in the context of transport (TCP, UDP, etc.)."</font></p>
  <p><font size="2">[KJBII] So, to go even further on the point above, the
MG may "know" MGC-A2 (that is, have it in its list of MGCs), but because
there can be only one control association at any given time, and those associations
are established by the MG, the communication from MGC-A2 should be viewed
as, at best, an inappropriate control message.&nbsp; At worst, it would be an
attack to attempt to gain control of the MG.&nbsp; Also, I would like to note
that an audit command would never be construed as a failover.&nbsp; Only a SC
with a method of failover would be a failover.</font></p>
  <br>
  </blockquote>
Where does the standard specify that 1 association = 1 IP address? Flemming
is right, I think the association is poorly defined. It is "implied" that
1 association = 1 MGC, but this is precisely what leads to confusion when
the MGC is multi-homed.<br>
  <br>
I scanned the document, the association is first mentioned in section 7.2.8
under 5) Handoff, but with no prior definition, and no definition is given
further on. The definition you quote from Annex F (why is it not in the main
document?) doesn't address my question either. Hence, 2 possible interpretations
for the MEGACO control association:<br>
  <br>
1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN (where
a number of MGC-FQDN pairs can be provisioned on the MG). In this case, if
the FQDN yields 2 IP addresses through DNS, then the MGC is multi-homed and
the MG would know that. The MG can either create one SCTP association with
the MGC, which would then take care of all the IP addresses, or (if SCTP
is not supported) it could emulate this behavior using UDP. The latter obviously
requires new procedures, quite simple in fact. But this would be very beneficial,
because it would allow a redundancy schema with very robust and efficient
switchover between signaling paths. Many MGs/MGCs could do this today easily,
but there are interop problems because the exact procedures are not clearly
stated.<br>
  <br>
2) If on the other side you would rather have it as 1 association = 1 IP
address, then the standard should say that 1 MGC = 1 FQDN which should always
yield exactly 1 IP address (otherwise it makes no sense). Also that a multi-homed
MGC should be viewed as 2 distinct MGCs, with 2 FQDNs, 2 IP addresses.<br>
  <br>
3) Lacking all that, the standard could at least say that multi-homed MGs
are just not addressed, which leaves the possibility that procedures may
be defined in future extensions. I keep telling people that this is the case,
  <br>
  <br>
In other words, in the current standard the model is not clear (the arity
of these relationships), which is quite important.<br>
  <br>
I would prefer 1), because this is more uniform whatever the transport is.
Under 2), SCTP doesn't even make much sense, it doesn't buy you much.<br>
  <blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com"><br>
    <p><font size="2">&gt;</font><br>
    <font size="2">&gt; In my case, since I use the audits on A2-A2 as heartbeats
(just to </font><br>
    <font size="2">&gt; check for connectivity), any reply is OK, if only
I get it. But this </font><br>
    <font size="2">&gt; is a problem if some other MGC really wants to audit
and is rejected. </font><br>
    <font size="2">&gt; By the way, MGCP allows for this extra auditing,
why is there a </font><br>
    <font size="2">&gt; difference in approach? This only complicates things
for an MGC which </font><br>
    <font size="2">&gt; controls both MGCP and MEGACO MGs.</font></p>
    <p><font size="2">[KJBII] Megaco and MGCP are not the same.&nbsp; There are
many differences between the two protocols, and this just happens to be one
of them.</font></p>
    <p><font size="2">&gt;</font><br>
    <font size="2">&gt;&gt; - If the MG is multi-homed you can provision
the two IP static </font><br>
    <font size="2">&gt;&gt; addresses as primary and secondary MGCs. In case
one fails it will </font><br>
    <font size="2">&gt;&gt; change to the other IP which in fact is the same
MGC.</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; Yes, but if the failure (MGCs interface A1) occurs
after the initial </font><br>
    <font size="2">&gt; ServiceChange, sometimes during operations when the
MG does not have </font><br>
    <font size="2">&gt; any notifications to send, and if the MG does not
do any heartbeats, </font><br>
    <font size="2">&gt; then it won't be aware of the failure, it will just
think it's idle. </font><br>
    <font size="2">&gt; So it will not initiate ServiceChange to the "alternate"
MGC. </font><br>
    <font size="2">&gt; Furthermore, even if the MG receives a new command
from MGC A2, as you </font><br>
    <font size="2">&gt; showed above, it will reply with an error and remain
idle. (By the </font><br>
    <font size="2">&gt; way, where in the standard is this rule stated?)</font></p>
    <p><font size="2">Yes, however there are ways around this problem (by
design, Megaco chose to only have the MG be able to initiate the control
association, so you just need to make sure it does that - see H.248.14 for
a solution).</font></p>
    <p><font size="2">There are however a couple of bad things here:</font><br>
    <font size="2">1. Only the statically provisioned list of backup MGCs
can be contacted, and only in the order they were provisioned. </font></p>
    <p><font size="2">[KJBII] This is bad because?</font></p>
    <p><font size="2">2. The spec is silent on whether a backup MGC replicates
the state of the primary or not. Consequently, you cannot assume that it
does, and hence switching to the backup is something you don't want to do
prematurely. </font></p>
    <p><font size="2">[KJBII] Why is this the MGs concern?&nbsp; The backup MGC
is responsible for getting itself attuned to the current state of affairs
on the MG.&nbsp; This can be done in any number of ways, some of which are more
detrimental to existing connections than others.</font></p>
    <p><font size="2">3. The switchover is not graceful, i.e. there has to
be a failure before you start contacting the backup. In contrast, a more
robust redundancy scheme would detect/suspect the failure earlier during
retransmission and switch to one of the backups to prevent any loss of state.
Furthermore, there should be a way of indicating that a backup is fully redundant
and hence the switchover can be done fairly early without any risk.</font></p>
    <p><font size="2">[KJBII] Hmmm.&nbsp; How would the MG know that the retransmissions
were due to MGC failure, as opposed to network congestion?&nbsp; I believe that
the MG will have to wait for the retransmissions to run their course, or
to utilize a different method of determining that the MGC had failed that
eliminates network congestion as a possibility.</font></p>
    <br>
    <p><font size="2">&gt;&gt; Maybe there should be a deep explanation of
how to do this to smooth </font><br>
    <font size="2">&gt;&gt; the process because the MG does not know whether
the secondary is an </font><br>
    <font size="2">&gt;&gt; independent MGC, a backup or a mirror and depending
on this </font><br>
    <font size="2">&gt;&gt; information it can behave in one way or another
(e.g. a ServiceChange </font><br>
    <font size="2">&gt;&gt; Request only</font><br>
    <font size="2">&gt;&gt; Informational)</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; Here, I concur with you and with Flemming, there
should be more </font><br>
    <font size="2">&gt; explanations. If you take into account multiple IP
addresses, DNS </font><br>
    <font size="2">&gt; names translating to one or more IP addresses, MGs
and MGCs working in </font><br>
    <font size="2">&gt; active-standby mode with or without complete state
synchronization, as </font><br>
    <font size="2">&gt; well as multiple active-standby pairs handoff, things
get complicated </font><br>
    <font size="2">&gt; enough to be worth additional explanations.</font></p>
    <p><font size="2">Agreed - there is work to be done in this area.</font></p>
    <br>
    <p><font size="2">&gt;&gt; - Another thing the MGC can do when it detects
the that A1 is going </font><br>
    <font size="2">&gt;&gt; to die is to send a Handoff to the interface
A2 for each MG so that </font><br>
    <font size="2">&gt;&gt; the connections are restablished in the new path.</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; This is what it's forced to do, but the MG is not
aware that the </font><br>
    <font size="2">&gt; handoff is to the same MGC. Consequently, it continues
to send pending </font><br>
    <font size="2">&gt; notifications to the old IP address, as per RFC 3015
section 7.2.8 </font><br>
    <font size="2">&gt; (and still in h248v2-04):</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; "At the same time, as indicated in clause 9, transaction
replies and </font><br>
    <font size="2">&gt; pending indications must be sent to the address from
which the </font><br>
    <font size="2">&gt; corresponding requests originated."</font><br>
    <font size="2">&gt;</font><br>
    <font size="2">&gt; This forces the "new" MGC (which is not really new)
to re-issue all </font><br>
    <font size="2">&gt; the notification requests, which, apart from being
a substantial </font><br>
    <font size="2">&gt; overhead, can cause serious race conditions, especially
with packages </font><br>
    <font size="2">&gt; such as bcas. Again, from experience, this is a point
of contention, </font><br>
    <font size="2">&gt; whether or not it's the right behavior.</font></p>
    <p><font size="2">[KJBII] Not true.&nbsp; Any NEW event detections would go
to the "new" MGC.&nbsp; Remember, events in H.248 persist until a new events descriptor
is sent to replace the old.&nbsp; Therefore, even through a handoff/failover,
the MG should continue to scan for events and report them to the controlling
MGC -- the "new" MGC once the handoff/failover occurs.</font></p>
    </blockquote>
For new event notifications, I agree with you that this should be the behavior.
But can you point out the text that backs your statement? Because I've been
pointed to the text I quoted above by an MG vendor, as a reason to implement
it the other way around (continue to send &nbsp;events to the old IP address).
And yes, I'm talking about the same events descriptor that persists.<br>
    <br>
For replies and their retransmissions, I don't know ... For example, if you
send an audit just to check for connectivity on a given path (A2-A2), then
it would be important that replies go back where the request came from. So
maybe the text I quoted should not put replies and indications in the same
bin.<br>
    <blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com">
      <p><font size="2">&gt;</font><br>
      <font size="2">&gt; If the MG were somehow aware that this is the same
MGC, the signaling </font><br>
      <font size="2">&gt; path switchover between A1-A1 and A2-A2 would be
faster and more </font><br>
      <font size="2">&gt; reliable.</font><br>
      <font size="2">&gt;</font><br>
      <font size="2">&gt; I think the MEGACO spec obviously did not consider
multi-homed </font><br>
      <font size="2">&gt; MGs/MGCs, therefore we are trying to see if the
existing rules "happen </font><br>
      <font size="2">&gt; to work" in this case. I have had a lot of arguments
over it because </font><br>
      <font size="2">&gt; of different interpretations.</font><br>
      <font size="2">&gt;</font></p>
      <p><font size="2">I agree (and actually, I'm surprised nobody has addressed
it yet because it has been known for a long time and pops up on the mailing
list from time time, but without much progress being made).</font></p>
      <p><font size="2">-- Flemming</font></p>
      <p><font size="2">[KJBII] There are many possibilities for redundancy
-- multihoming is not the only one.&nbsp; Further, I don't see how the rules don't
work, or how we can optimize this particular case without penalizing the
other possibilities.&nbsp; The MG should not know, or care, that the MGC is multihomed.&nbsp;
The same goes for the MGC with respect to the MG.&nbsp; If you change IP addresses,
then you change control association, and that has consequences that have
to be rectified by the MGC.</font></p>
      </blockquote>
I tend to disagree with this, see comments above. Again, you imply that 1
association = 1 IP address, but if this is the case, it must be stated clearly.<br>
      <blockquote type="cite" cite="mid:ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com">
        <p><font size="2">_______________________________________________</font><br>
        <font size="2">Megaco mailing list</font><br>
        <font size="2"><a class="moz-txt-link-abbreviated" href="mailto:Megaco@ietf.org">Megaco@ietf.org</a></font><br>
        <font size="2"><a href="https://www1.ietf.org/mailman/listinfo/megaco" target="_blank">
https://www1.ietf.org/mailman/listinfo/megaco</a>
        </font></p>
        </blockquote>
        <br>
        </body>
        </html>

--------------050900060509020308060905--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 19:06:38 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09924
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 19:06:38 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ON81820838;
	Thu, 24 Apr 2003 19:08:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ON4g819893
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 19:04:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09804
	for <megaco@ietf.org>; Thu, 24 Apr 2003 19:01:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198pkj-0002pB-00
	for megaco@ietf.org; Thu, 24 Apr 2003 19:03:41 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 198pki-0002p8-00
	for megaco@ietf.org; Thu, 24 Apr 2003 19:03:40 -0400
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h3ON482i008905
	for <megaco@ietf.org>; Thu, 24 Apr 2003 16:04:08 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA07922 for <megaco@ietf.org>; Thu, 24 Apr 2003 16:03:13 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN51XJ; Thu, 24 Apr 2003 18:04:07 -0500
Message-ID: <3EA86D8F.40730808@motorola.com>
Date: Thu, 24 Apr 2003 18:04:47 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Kevin Boyle <kboyle@nortelnetworks.com>,
        Flemming Andreasen <fandreas@cisco.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I disagree with the notion that MEGACO spec fails to address
multi-homing. Multi-homing is elegantly addressed by using SCTP
(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
is to relieve other upper layer protocols, such as MEGACO, from the
complicated task of dealing with multi-homing. 

I'd call it a bad strategy if now some one would insist on using UDP and
duplicate the multi-homing handling complexity of SCTP inside MEGACO
before calling it adequately addressed.

-Qiaobing

Adrian Soncodi wrote:
> 
> More comments inline.
> 
> Adrian
> 
> Kevin Boyle wrote:
> 
> > Comments inline. [KJBII]
> >
> > Kevin
> >
> > -----Original Message-----
> > From: Flemming Andreasen [ mailto:fandreas@cisco.com ]
> > Sent: Thursday, April 24, 2003 11:24 AM
> > To: Adrian Soncodi
> > Cc: Fernando Vallejo Lazaro; megaco@ietf.org
> > Subject: Re: [Megaco] Support for redundant MG failover
> >
> >
> >
> >
> > Adrian Soncodi wrote:
> >
> > > Fernando,
> > >
> > > Thanks for the reply. See comments inline.
> > >
> > > Adrian
> > >
> > >
> > >
> > > Fernando Vallejo Lazaro wrote:
> > >
> > >> Hi all,
> > >>
> > >> Only some comments.
> > >>
> > >> - You say : "So while talking on A1-A1, the MGC cannot for
> > example
> > >> audit on A2-A2, because this is immediately considered a failover
> >
> > >> (...)". I don't think this is true. If an MG receives an Audit
> > from
> > >> MGC-A2 (which it does not know) it will reject the transaction
> > >> because there is no association established with it.
> > >
> > > Some MGs do this, others either don't reply or they failover. The
> > > latter may be in violation of the standard, but I think that's
> > because
> > > it's not very well explained.
> > >
> >
> > I think part of the problem here is that the concept of a control
> > association is not very well defined when it comes to UDP; how do
> > you determine if a message received is part of the UDP control
> > association ?
> >
> > [KJBII] H.248 control associations have absolutely nothing to do
> > with transport.  To quote from the most recent version of Annex F:
> > "A control association is a communication relationship whereby an
> > MGC is controlling an MG.  A control association is instantiated via
> > registration.  The control association is terminated by the MG going
> > out of service, being successfully handed off to an alternate MGC,
> > or successfully failing over to an alternate MGC.  An MG shall have
> > at most one control association at any time.  Only MGs may
> > instantiate control associations.  Control associations as defined
> > here apply only within the context of media gateway control
> > signalling.  This definition should not be confused with that of
> > control associations in the context of transport (TCP, UDP, etc.)."
> >
> > [KJBII] So, to go even further on the point above, the MG may "know"
> > MGC-A2 (that is, have it in its list of MGCs), but because there can
> > be only one control association at any given time, and those
> > associations are established by the MG, the communication from
> > MGC-A2 should be viewed as, at best, an inappropriate control
> > message.  At worst, it would be an attack to attempt to gain control
> > of the MG.  Also, I would like to note that an audit command would
> > never be construed as a failover.  Only a SC with a method of
> > failover would be a failover.
> >
> >
> Where does the standard specify that 1 association = 1 IP address?
> Flemming is right, I think the association is poorly defined. It is
> "implied" that 1 association = 1 MGC, but this is precisely what leads
> to confusion when the MGC is multi-homed.
> 
> I scanned the document, the association is first mentioned in section
> 7.2.8 under 5) Handoff, but with no prior definition, and no
> definition is given further on. The definition you quote from Annex F
> (why is it not in the main document?) doesn't address my question
> either. Hence, 2 possible interpretations for the MEGACO control
> association:
> 
> 1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN
> (where a number of MGC-FQDN pairs can be provisioned on the MG). In
> this case, if the FQDN yields 2 IP addresses through DNS, then the MGC
> is multi-homed and the MG would know that. The MG can either create
> one SCTP association with the MGC, which would then take care of all
> the IP addresses, or (if SCTP is not supported) it could emulate this
> behavior using UDP. The latter obviously requires new procedures,
> quite simple in fact. But this would be very beneficial, because it
> would allow a redundancy schema with very robust and efficient
> switchover between signaling paths. Many MGs/MGCs could do this today
> easily, but there are interop problems because the exact procedures
> are not clearly stated.
> 
> 2) If on the other side you would rather have it as 1 association = 1
> IP address, then the standard should say that 1 MGC = 1 FQDN which
> should always yield exactly 1 IP address (otherwise it makes no
> sense). Also that a multi-homed MGC should be viewed as 2 distinct
> MGCs, with 2 FQDNs, 2 IP addresses.
> 
> 3) Lacking all that, the standard could at least say that multi-homed
> MGs are just not addressed, which leaves the possibility that
> procedures may be defined in future extensions. I keep telling people
> that this is the case,
> 
> In other words, in the current standard the model is not clear (the
> arity of these relationships), which is quite important.
> 
> I would prefer 1), because this is more uniform whatever the transport
> is. Under 2), SCTP doesn't even make much sense, it doesn't buy you
> much.
> 
> >
> > >
> > > In my case, since I use the audits on A2-A2 as heartbeats (just to
> >
> > > check for connectivity), any reply is OK, if only I get it. But
> > this
> > > is a problem if some other MGC really wants to audit and is
> > rejected.
> > > By the way, MGCP allows for this extra auditing, why is there a
> > > difference in approach? This only complicates things for an MGC
> > which
> > > controls both MGCP and MEGACO MGs.
> >
> > [KJBII] Megaco and MGCP are not the same.  There are many
> > differences between the two protocols, and this just happens to be
> > one of them.
> >
> > >
> > >> - If the MG is multi-homed you can provision the two IP static
> > >> addresses as primary and secondary MGCs. In case one fails it
> > will
> > >> change to the other IP which in fact is the same MGC.
> > >
> > > Yes, but if the failure (MGCs interface A1) occurs after the
> > initial
> > > ServiceChange, sometimes during operations when the MG does not
> > have
> > > any notifications to send, and if the MG does not do any
> > heartbeats,
> > > then it won't be aware of the failure, it will just think it's
> > idle.
> > > So it will not initiate ServiceChange to the "alternate" MGC.
> > > Furthermore, even if the MG receives a new command from MGC A2, as
> > you
> > > showed above, it will reply with an error and remain idle. (By the
> >
> > > way, where in the standard is this rule stated?)
> >
> > Yes, however there are ways around this problem (by design, Megaco
> > chose to only have the MG be able to initiate the control
> > association, so you just need to make sure it does that - see
> > H.248.14 for a solution).
> >
> > There are however a couple of bad things here:
> > 1. Only the statically provisioned list of backup MGCs can be
> > contacted, and only in the order they were provisioned.
> >
> > [KJBII] This is bad because?
> >
> > 2. The spec is silent on whether a backup MGC replicates the state
> > of the primary or not. Consequently, you cannot assume that it does,
> > and hence switching to the backup is something you don't want to do
> > prematurely.
> >
> > [KJBII] Why is this the MGs concern?  The backup MGC is responsible
> > for getting itself attuned to the current state of affairs on the
> > MG.  This can be done in any number of ways, some of which are more
> > detrimental to existing connections than others.
> >
> > 3. The switchover is not graceful, i.e. there has to be a failure
> > before you start contacting the backup. In contrast, a more robust
> > redundancy scheme would detect/suspect the failure earlier during
> > retransmission and switch to one of the backups to prevent any loss
> > of state. Furthermore, there should be a way of indicating that a
> > backup is fully redundant and hence the switchover can be done
> > fairly early without any risk.
> >
> > [KJBII] Hmmm.  How would the MG know that the retransmissions were
> > due to MGC failure, as opposed to network congestion?  I believe
> > that the MG will have to wait for the retransmissions to run their
> > course, or to utilize a different method of determining that the MGC
> > had failed that eliminates network congestion as a possibility.
> >
> >
> > >> Maybe there should be a deep explanation of how to do this to
> > smooth
> > >> the process because the MG does not know whether the secondary is
> > an
> > >> independent MGC, a backup or a mirror and depending on this
> > >> information it can behave in one way or another (e.g. a
> > ServiceChange
> > >> Request only
> > >> Informational)
> > >
> > > Here, I concur with you and with Flemming, there should be more
> > > explanations. If you take into account multiple IP addresses, DNS
> > > names translating to one or more IP addresses, MGs and MGCs
> > working in
> > > active-standby mode with or without complete state
> > synchronization, as
> > > well as multiple active-standby pairs handoff, things get
> > complicated
> > > enough to be worth additional explanations.
> >
> > Agreed - there is work to be done in this area.
> >
> >
> > >> - Another thing the MGC can do when it detects the that A1 is
> > going
> > >> to die is to send a Handoff to the interface A2 for each MG so
> > that
> > >> the connections are restablished in the new path.
> > >
> > > This is what it's forced to do, but the MG is not aware that the
> > > handoff is to the same MGC. Consequently, it continues to send
> > pending
> > > notifications to the old IP address, as per RFC 3015 section 7.2.8
> >
> > > (and still in h248v2-04):
> > >
> > > "At the same time, as indicated in clause 9, transaction replies
> > and
> > > pending indications must be sent to the address from which the
> > > corresponding requests originated."
> > >
> > > This forces the "new" MGC (which is not really new) to re-issue
> > all
> > > the notification requests, which, apart from being a substantial
> > > overhead, can cause serious race conditions, especially with
> > packages
> > > such as bcas. Again, from experience, this is a point of
> > contention,
> > > whether or not it's the right behavior.
> >
> > [KJBII] Not true.  Any NEW event detections would go to the "new"
> > MGC.  Remember, events in H.248 persist until a new events
> > descriptor is sent to replace the old.  Therefore, even through a
> > handoff/failover, the MG should continue to scan for events and
> > report them to the controlling MGC -- the "new" MGC once the
> > handoff/failover occurs.
> >
> For new event notifications, I agree with you that this should be the
> behavior. But can you point out the text that backs your statement?
> Because I've been pointed to the text I quoted above by an MG vendor,
> as a reason to implement it the other way around (continue to send
>  events to the old IP address). And yes, I'm talking about the same
> events descriptor that persists.
> 
> For replies and their retransmissions, I don't know ... For example,
> if you send an audit just to check for connectivity on a given path
> (A2-A2), then it would be important that replies go back where the
> request came from. So maybe the text I quoted should not put replies
> and indications in the same bin.
> 
> > >
> > > If the MG were somehow aware that this is the same MGC, the
> > signaling
> > > path switchover between A1-A1 and A2-A2 would be faster and more
> > > reliable.
> > >
> > > I think the MEGACO spec obviously did not consider multi-homed
> > > MGs/MGCs, therefore we are trying to see if the existing rules
> > "happen
> > > to work" in this case. I have had a lot of arguments over it
> > because
> > > of different interpretations.
> > >
> >
> > I agree (and actually, I'm surprised nobody has addressed it yet
> > because it has been known for a long time and pops up on the mailing
> > list from time time, but without much progress being made).
> >
> > -- Flemming
> >
> > [KJBII] There are many possibilities for redundancy -- multihoming
> > is not the only one.  Further, I don't see how the rules don't work,
> > or how we can optimize this particular case without penalizing the
> > other possibilities.  The MG should not know, or care, that the MGC
> > is multihomed.  The same goes for the MGC with respect to the MG.
> > If you change IP addresses, then you change control association, and
> > that has consequences that have to be rectified by the MGC.
> >
> I tend to disagree with this, see comments above. Again, you imply
> that 1 association = 1 IP address, but if this is the case, it must be
> stated clearly.
> 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 19:07:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09951
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 19:07:48 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3ONAaV20913
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 19:10:36 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ONAa820910
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 19:10:36 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09943
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 19:07:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198pqQ-0002sO-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 19:09:34 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198pqQ-0002sL-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 19:09:34 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ON81820838;
	Thu, 24 Apr 2003 19:08:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ON4g819893
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 19:04:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09804
	for <megaco@ietf.org>; Thu, 24 Apr 2003 19:01:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198pkj-0002pB-00
	for megaco@ietf.org; Thu, 24 Apr 2003 19:03:41 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 198pki-0002p8-00
	for megaco@ietf.org; Thu, 24 Apr 2003 19:03:40 -0400
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h3ON482i008905
	for <megaco@ietf.org>; Thu, 24 Apr 2003 16:04:08 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA07922 for <megaco@ietf.org>; Thu, 24 Apr 2003 16:03:13 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN51XJ; Thu, 24 Apr 2003 18:04:07 -0500
Message-ID: <3EA86D8F.40730808@motorola.com>
Date: Thu, 24 Apr 2003 18:04:47 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: Kevin Boyle <kboyle@nortelnetworks.com>,
        Flemming Andreasen <fandreas@cisco.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I disagree with the notion that MEGACO spec fails to address
multi-homing. Multi-homing is elegantly addressed by using SCTP
(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
is to relieve other upper layer protocols, such as MEGACO, from the
complicated task of dealing with multi-homing. 

I'd call it a bad strategy if now some one would insist on using UDP and
duplicate the multi-homing handling complexity of SCTP inside MEGACO
before calling it adequately addressed.

-Qiaobing

Adrian Soncodi wrote:
> 
> More comments inline.
> 
> Adrian
> 
> Kevin Boyle wrote:
> 
> > Comments inline. [KJBII]
> >
> > Kevin
> >
> > -----Original Message-----
> > From: Flemming Andreasen [ mailto:fandreas@cisco.com ]
> > Sent: Thursday, April 24, 2003 11:24 AM
> > To: Adrian Soncodi
> > Cc: Fernando Vallejo Lazaro; megaco@ietf.org
> > Subject: Re: [Megaco] Support for redundant MG failover
> >
> >
> >
> >
> > Adrian Soncodi wrote:
> >
> > > Fernando,
> > >
> > > Thanks for the reply. See comments inline.
> > >
> > > Adrian
> > >
> > >
> > >
> > > Fernando Vallejo Lazaro wrote:
> > >
> > >> Hi all,
> > >>
> > >> Only some comments.
> > >>
> > >> - You say : "So while talking on A1-A1, the MGC cannot for
> > example
> > >> audit on A2-A2, because this is immediately considered a failover
> >
> > >> (...)". I don't think this is true. If an MG receives an Audit
> > from
> > >> MGC-A2 (which it does not know) it will reject the transaction
> > >> because there is no association established with it.
> > >
> > > Some MGs do this, others either don't reply or they failover. The
> > > latter may be in violation of the standard, but I think that's
> > because
> > > it's not very well explained.
> > >
> >
> > I think part of the problem here is that the concept of a control
> > association is not very well defined when it comes to UDP; how do
> > you determine if a message received is part of the UDP control
> > association ?
> >
> > [KJBII] H.248 control associations have absolutely nothing to do
> > with transport.  To quote from the most recent version of Annex F:
> > "A control association is a communication relationship whereby an
> > MGC is controlling an MG.  A control association is instantiated via
> > registration.  The control association is terminated by the MG going
> > out of service, being successfully handed off to an alternate MGC,
> > or successfully failing over to an alternate MGC.  An MG shall have
> > at most one control association at any time.  Only MGs may
> > instantiate control associations.  Control associations as defined
> > here apply only within the context of media gateway control
> > signalling.  This definition should not be confused with that of
> > control associations in the context of transport (TCP, UDP, etc.)."
> >
> > [KJBII] So, to go even further on the point above, the MG may "know"
> > MGC-A2 (that is, have it in its list of MGCs), but because there can
> > be only one control association at any given time, and those
> > associations are established by the MG, the communication from
> > MGC-A2 should be viewed as, at best, an inappropriate control
> > message.  At worst, it would be an attack to attempt to gain control
> > of the MG.  Also, I would like to note that an audit command would
> > never be construed as a failover.  Only a SC with a method of
> > failover would be a failover.
> >
> >
> Where does the standard specify that 1 association = 1 IP address?
> Flemming is right, I think the association is poorly defined. It is
> "implied" that 1 association = 1 MGC, but this is precisely what leads
> to confusion when the MGC is multi-homed.
> 
> I scanned the document, the association is first mentioned in section
> 7.2.8 under 5) Handoff, but with no prior definition, and no
> definition is given further on. The definition you quote from Annex F
> (why is it not in the main document?) doesn't address my question
> either. Hence, 2 possible interpretations for the MEGACO control
> association:
> 
> 1) I am inclined to interpret this as 1 association = 1 MGC = 1 FQDN
> (where a number of MGC-FQDN pairs can be provisioned on the MG). In
> this case, if the FQDN yields 2 IP addresses through DNS, then the MGC
> is multi-homed and the MG would know that. The MG can either create
> one SCTP association with the MGC, which would then take care of all
> the IP addresses, or (if SCTP is not supported) it could emulate this
> behavior using UDP. The latter obviously requires new procedures,
> quite simple in fact. But this would be very beneficial, because it
> would allow a redundancy schema with very robust and efficient
> switchover between signaling paths. Many MGs/MGCs could do this today
> easily, but there are interop problems because the exact procedures
> are not clearly stated.
> 
> 2) If on the other side you would rather have it as 1 association = 1
> IP address, then the standard should say that 1 MGC = 1 FQDN which
> should always yield exactly 1 IP address (otherwise it makes no
> sense). Also that a multi-homed MGC should be viewed as 2 distinct
> MGCs, with 2 FQDNs, 2 IP addresses.
> 
> 3) Lacking all that, the standard could at least say that multi-homed
> MGs are just not addressed, which leaves the possibility that
> procedures may be defined in future extensions. I keep telling people
> that this is the case,
> 
> In other words, in the current standard the model is not clear (the
> arity of these relationships), which is quite important.
> 
> I would prefer 1), because this is more uniform whatever the transport
> is. Under 2), SCTP doesn't even make much sense, it doesn't buy you
> much.
> 
> >
> > >
> > > In my case, since I use the audits on A2-A2 as heartbeats (just to
> >
> > > check for connectivity), any reply is OK, if only I get it. But
> > this
> > > is a problem if some other MGC really wants to audit and is
> > rejected.
> > > By the way, MGCP allows for this extra auditing, why is there a
> > > difference in approach? This only complicates things for an MGC
> > which
> > > controls both MGCP and MEGACO MGs.
> >
> > [KJBII] Megaco and MGCP are not the same.  There are many
> > differences between the two protocols, and this just happens to be
> > one of them.
> >
> > >
> > >> - If the MG is multi-homed you can provision the two IP static
> > >> addresses as primary and secondary MGCs. In case one fails it
> > will
> > >> change to the other IP which in fact is the same MGC.
> > >
> > > Yes, but if the failure (MGCs interface A1) occurs after the
> > initial
> > > ServiceChange, sometimes during operations when the MG does not
> > have
> > > any notifications to send, and if the MG does not do any
> > heartbeats,
> > > then it won't be aware of the failure, it will just think it's
> > idle.
> > > So it will not initiate ServiceChange to the "alternate" MGC.
> > > Furthermore, even if the MG receives a new command from MGC A2, as
> > you
> > > showed above, it will reply with an error and remain idle. (By the
> >
> > > way, where in the standard is this rule stated?)
> >
> > Yes, however there are ways around this problem (by design, Megaco
> > chose to only have the MG be able to initiate the control
> > association, so you just need to make sure it does that - see
> > H.248.14 for a solution).
> >
> > There are however a couple of bad things here:
> > 1. Only the statically provisioned list of backup MGCs can be
> > contacted, and only in the order they were provisioned.
> >
> > [KJBII] This is bad because?
> >
> > 2. The spec is silent on whether a backup MGC replicates the state
> > of the primary or not. Consequently, you cannot assume that it does,
> > and hence switching to the backup is something you don't want to do
> > prematurely.
> >
> > [KJBII] Why is this the MGs concern?  The backup MGC is responsible
> > for getting itself attuned to the current state of affairs on the
> > MG.  This can be done in any number of ways, some of which are more
> > detrimental to existing connections than others.
> >
> > 3. The switchover is not graceful, i.e. there has to be a failure
> > before you start contacting the backup. In contrast, a more robust
> > redundancy scheme would detect/suspect the failure earlier during
> > retransmission and switch to one of the backups to prevent any loss
> > of state. Furthermore, there should be a way of indicating that a
> > backup is fully redundant and hence the switchover can be done
> > fairly early without any risk.
> >
> > [KJBII] Hmmm.  How would the MG know that the retransmissions were
> > due to MGC failure, as opposed to network congestion?  I believe
> > that the MG will have to wait for the retransmissions to run their
> > course, or to utilize a different method of determining that the MGC
> > had failed that eliminates network congestion as a possibility.
> >
> >
> > >> Maybe there should be a deep explanation of how to do this to
> > smooth
> > >> the process because the MG does not know whether the secondary is
> > an
> > >> independent MGC, a backup or a mirror and depending on this
> > >> information it can behave in one way or another (e.g. a
> > ServiceChange
> > >> Request only
> > >> Informational)
> > >
> > > Here, I concur with you and with Flemming, there should be more
> > > explanations. If you take into account multiple IP addresses, DNS
> > > names translating to one or more IP addresses, MGs and MGCs
> > working in
> > > active-standby mode with or without complete state
> > synchronization, as
> > > well as multiple active-standby pairs handoff, things get
> > complicated
> > > enough to be worth additional explanations.
> >
> > Agreed - there is work to be done in this area.
> >
> >
> > >> - Another thing the MGC can do when it detects the that A1 is
> > going
> > >> to die is to send a Handoff to the interface A2 for each MG so
> > that
> > >> the connections are restablished in the new path.
> > >
> > > This is what it's forced to do, but the MG is not aware that the
> > > handoff is to the same MGC. Consequently, it continues to send
> > pending
> > > notifications to the old IP address, as per RFC 3015 section 7.2.8
> >
> > > (and still in h248v2-04):
> > >
> > > "At the same time, as indicated in clause 9, transaction replies
> > and
> > > pending indications must be sent to the address from which the
> > > corresponding requests originated."
> > >
> > > This forces the "new" MGC (which is not really new) to re-issue
> > all
> > > the notification requests, which, apart from being a substantial
> > > overhead, can cause serious race conditions, especially with
> > packages
> > > such as bcas. Again, from experience, this is a point of
> > contention,
> > > whether or not it's the right behavior.
> >
> > [KJBII] Not true.  Any NEW event detections would go to the "new"
> > MGC.  Remember, events in H.248 persist until a new events
> > descriptor is sent to replace the old.  Therefore, even through a
> > handoff/failover, the MG should continue to scan for events and
> > report them to the controlling MGC -- the "new" MGC once the
> > handoff/failover occurs.
> >
> For new event notifications, I agree with you that this should be the
> behavior. But can you point out the text that backs your statement?
> Because I've been pointed to the text I quoted above by an MG vendor,
> as a reason to implement it the other way around (continue to send
>  events to the old IP address). And yes, I'm talking about the same
> events descriptor that persists.
> 
> For replies and their retransmissions, I don't know ... For example,
> if you send an audit just to check for connectivity on a given path
> (A2-A2), then it would be important that replies go back where the
> request came from. So maybe the text I quoted should not put replies
> and indications in the same bin.
> 
> > >
> > > If the MG were somehow aware that this is the same MGC, the
> > signaling
> > > path switchover between A1-A1 and A2-A2 would be faster and more
> > > reliable.
> > >
> > > I think the MEGACO spec obviously did not consider multi-homed
> > > MGs/MGCs, therefore we are trying to see if the existing rules
> > "happen
> > > to work" in this case. I have had a lot of arguments over it
> > because
> > > of different interpretations.
> > >
> >
> > I agree (and actually, I'm surprised nobody has addressed it yet
> > because it has been known for a long time and pops up on the mailing
> > list from time time, but without much progress being made).
> >
> > -- Flemming
> >
> > [KJBII] There are many possibilities for redundancy -- multihoming
> > is not the only one.  Further, I don't see how the rules don't work,
> > or how we can optimize this particular case without penalizing the
> > other possibilities.  The MG should not know, or care, that the MGC
> > is multihomed.  The same goes for the MGC with respect to the MG.
> > If you change IP addresses, then you change control association, and
> > that has consequences that have to be rectified by the MGC.
> >
> I tend to disagree with this, see comments above. Again, you imply
> that 1 association = 1 IP address, but if this is the case, it must be
> stated clearly.
> 
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 20:22:03 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11043
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 20:22:03 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0Nr825148;
	Thu, 24 Apr 2003 20:23:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0KJ825048
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 20:20:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10944
	for <megaco@ietf.org>; Thu, 24 Apr 2003 20:16:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198qvs-0003E5-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:19:16 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 198qvs-0003Dr-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:19:16 -0400
Received: from cisco.com (sjc-vpn3-561.cisco.com [10.21.66.49])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3P0J708027142;
	Thu, 24 Apr 2003 17:19:08 -0700 (PDT)
Message-ID: <3EA87EFA.A9940931@cisco.com>
Date: Thu, 24 Apr 2003 20:19:06 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

> I disagree with the notion that MEGACO spec fails to address
> multi-homing. Multi-homing is elegantly addressed by using SCTP
> (specified in H.248 Annex H). One of the reasons for having SCTP in IETF
> is to relieve other upper layer protocols, such as MEGACO, from the
> complicated task of dealing with multi-homing.
>
> I'd call it a bad strategy if now some one would insist on using UDP and
> duplicate the multi-homing handling complexity of SCTP inside MEGACO
> before calling it adequately addressed.
>

If SCTP support was an integral part of and mandatory in Megaco, then I'd
agree with that, however it's not; TCP and UDP are.

-- Flemming



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 20:23:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11079
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 20:23:11 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3P0Q1N25230
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 20:26:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0Q1825224
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 20:26:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11065
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 20:22:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198r1O-0003Fl-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 20:24:58 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198r1N-0003Fi-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 20:24:57 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0Nr825148;
	Thu, 24 Apr 2003 20:23:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0KJ825048
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 20:20:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10944
	for <megaco@ietf.org>; Thu, 24 Apr 2003 20:16:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198qvs-0003E5-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:19:16 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 198qvs-0003Dr-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:19:16 -0400
Received: from cisco.com (sjc-vpn3-561.cisco.com [10.21.66.49])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3P0J708027142;
	Thu, 24 Apr 2003 17:19:08 -0700 (PDT)
Message-ID: <3EA87EFA.A9940931@cisco.com>
Date: Thu, 24 Apr 2003 20:19:06 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

> I disagree with the notion that MEGACO spec fails to address
> multi-homing. Multi-homing is elegantly addressed by using SCTP
> (specified in H.248 Annex H). One of the reasons for having SCTP in IETF
> is to relieve other upper layer protocols, such as MEGACO, from the
> complicated task of dealing with multi-homing.
>
> I'd call it a bad strategy if now some one would insist on using UDP and
> duplicate the multi-homing handling complexity of SCTP inside MEGACO
> before calling it adequately addressed.
>

If SCTP support was an integral part of and mandatory in Megaco, then I'd
agree with that, however it's not; TCP and UDP are.

-- Flemming



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 20:55:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11721
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 20:55:11 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0vI827309;
	Thu, 24 Apr 2003 20:57:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0sJ827220
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 20:54:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11645
	for <megaco@ietf.org>; Thu, 24 Apr 2003 20:50:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rSl-0003T7-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:53:15 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rSl-0003Sd-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:53:15 -0400
Received: from cisco.com (sjc-vpn3-561.cisco.com [10.21.66.49])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3P0r608013684;
	Thu, 24 Apr 2003 17:53:07 -0700 (PDT)
Message-ID: <3EA886F2.CCAE1EE5@cisco.com>
Date: Thu, 24 Apr 2003 20:53:06 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Kevin Boyle wrote:

>
>
> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Thursday, April 24, 2003 11:24 AM
> To: Adrian Soncodi
> Cc: Fernando Vallejo Lazaro; megaco@ietf.org
> Subject: Re: [Megaco] Support for redundant MG failover
>
>

<snip>

>
>
> I think part of the problem here is that the concept of a control
> association is not very well defined when it comes to UDP; how do you
> determine if a message received is part of the UDP control association
> ?
>
> [KJBII] H.248 control associations have absolutely nothing to do with
> transport.

Why not ? If I'm using TCP, then how can anything be sent outside that
TCP connection in either direction ?


> To quote from the most recent version of Annex F: "A control
> association is a communication relationship whereby an MGC is
> controlling an MG.  A control association is instantiated via
> registration.  The control association is terminated by the MG going
> out of service, being successfully handed off to an alternate MGC, or
> successfully failing over to an alternate MGC.  An MG shall have at
> most one control association at any time.  Only MGs may instantiate
> control associations.  Control associations as defined here apply only
> within the context of media gateway control signalling.  This
> definition should not be confused with that of control associations in
> the context of transport (TCP, UDP, etc.)."
>

I think you need to throw in a bit more text and perhaps some examples.
The above doesn't make it a whole lot clearer exactly what a control
association is and the semantics it carries with it.

>
> [KJBII] So, to go even further on the point above, the MG may "know"
> MGC-A2 (that is, have it in its list of MGCs), but because there can
> be only one control association at any given time, and those
> associations are established by the MG, the communication from MGC-A2
> should be viewed as, at best, an inappropriate control message.

How does the MG "know" that the message comes from MGC-A2 and not MGC-A1
? Is that simply based on the mID in the message header ? If so, the
concept of a control association seems a bit fluffy (anybody can put
whatever name they want in there). If not, what is it based on ?


> At worst, it would be an attack to attempt to gain control of the MG.
> Also, I would like to note that an audit command would never be
> construed as a failover.  Only a SC with a method of failover would be
> a failover.
>

OK, however I'm still missing a clear definition of exactly what a
control association is, and how the MG determines if a message it is
either sending or receiving is part of an existing control association.

>
> Yes, however there are ways around this problem (by design, Megaco
> chose to only have the MG be able to initiate the control association,
> so you just need to make sure it does that - see H.248.14 for a
> solution).
>
> There are however a couple of bad things here:
> 1. Only the statically provisioned list of backup MGCs can be
> contacted, and only in the order they were provisioned.
>
> [KJBII] This is bad because?
>

1. Provisioning in general is bad.
2. The backups cannot be changed dynamically which is problematic in
lots of cases. For example, if I need to change the list of backups due
to upgrades, failures, etc., there's no simple or dynamic way of doing
this. Another example could be that each (or some) of the backups
represent alternative interfaces for a single MGC. How do I now redirect
my MG to not contact any of these interfaces ? Can't be done.

and the list goes on.


>
> 2. The spec is silent on whether a backup MGC replicates the state of
> the primary or not. Consequently, you cannot assume that it does, and
> hence switching to the backup is something you don't want to do
> prematurely.
>
> [KJBII] Why is this the MGs concern?  The backup MGC is responsible
> for getting itself attuned to the current state of affairs on the MG.
> This can be done in any number of ways, some of which are more
> detrimental to existing connections than others.
>

It's a concern because a failure to receive a response may occur for any
number of reasons (as you note below), e.g. interface failure, network
problems, or MGC failure. If you knew, that some of the addresses belong
to the same MGC (which could be a cluster of boxes), then upon not
receiving a response, you could quickly move on to another interface
without any risk. In this way, interface failures and local network
problems that do not affect all interfaces are not catastrophic. As for
a backup MGC to audit an MG to figure out what is going, this is first
of all a time-consuming and resource-intensive task, and secondly it
will not allow for a transparent failover in all cases, let alone
restore the call state that existed on the failed MGC.

>
> 3. The switchover is not graceful, i.e. there has to be a failure
> before you start contacting the backup. In contrast, a more robust
> redundancy scheme would detect/suspect the failure earlier during
> retransmission and switch to one of the backups to prevent any loss of
> state. Furthermore, there should be a way of indicating that a backup
> is fully redundant and hence the switchover can be done fairly early
> without any risk.
>
> [KJBII] Hmmm.  How would the MG know that the retransmissions were due
> to MGC failure, as opposed to network congestion?  I believe that the
> MG will have to wait for the retransmissions to run their course, or
> to utilize a different method of determining that the MGC had failed
> that eliminates network congestion as a possibility.
>

Exactly. The MG will not be able to determine what the real problem is,
however in the event the problem only affects part of the MGC and
communication to a different interface is possible, allowing/requiring
the MG to move on quickly to the next interface is very helpful.

>
> >> - Another thing the MGC can do when it detects the that A1 is going
>
> >> to die is to send a Handoff to the interface A2 for each MG so that
>
> >> the connections are restablished in the new path.
> >
> > This is what it's forced to do, but the MG is not aware that the
> > handoff is to the same MGC. Consequently, it continues to send
> pending
> > notifications to the old IP address, as per RFC 3015 section 7.2.8
> > (and still in h248v2-04):
> >
> > "At the same time, as indicated in clause 9, transaction replies and
>
> > pending indications must be sent to the address from which the
> > corresponding requests originated."
> >
> > This forces the "new" MGC (which is not really new) to re-issue all
> > the notification requests, which, apart from being a substantial
> > overhead, can cause serious race conditions, especially with
> packages
> > such as bcas. Again, from experience, this is a point of contention,
>
> > whether or not it's the right behavior.
>
> [KJBII] Not true.  Any NEW event detections would go to the "new"
> MGC.  Remember, events in H.248 persist until a new events descriptor
> is sent to replace the old.  Therefore, even through a
> handoff/failover, the MG should continue to scan for events and report
> them to the controlling MGC -- the "new" MGC once the handoff/failover
> occurs.
>

Right, but what about old ones that are in the process of being
retransmitted and/or new ones being generated before the new control
association is up ? They should of course go to the new MGC as well, but
does the spec actually say that (it may be implied by the control
association, but if not already specified explicitly, it would be worth
doing so) ?


>
> >
> > If the MG were somehow aware that this is the same MGC, the
> signaling
> > path switchover between A1-A1 and A2-A2 would be faster and more
> > reliable.
> >
> > I think the MEGACO spec obviously did not consider multi-homed
> > MGs/MGCs, therefore we are trying to see if the existing rules
> "happen
> > to work" in this case. I have had a lot of arguments over it because
>
> > of different interpretations.
> >
>
> I agree (and actually, I'm surprised nobody has addressed it yet
> because it has been known for a long time and pops up on the mailing
> list from time time, but without much progress being made).
>
> -- Flemming
>
> [KJBII] There are many possibilities for redundancy -- multihoming is
> not the only one.  Further, I don't see how the rules don't work, or
> how we can optimize this particular case without penalizing the other
> possibilities.  The MG should not know, or care, that the MGC is
> multihomed.  The same goes for the MGC with respect to the MG.  If you
> change IP addresses, then you change control association, and that has
> consequences that have to be rectified by the MGC.
>

I disagree and based on this thread as well as similar ones in the past,
so do others it seems. As an aside, MGCP specified these things in great
detail, and I have yet to hear anybody complain that it is overly
restrictive in its support for multihoming and redundancy. On the
contrary. The same can easily be done for Megaco.

-- Flemming


>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 20:56:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11754
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 20:56:20 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3P0xBj27407
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 20:59:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0xA827404
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 20:59:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11751
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 20:55:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rXS-0003UZ-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 20:58:06 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198rXS-0003UW-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 20:58:06 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0vI827309;
	Thu, 24 Apr 2003 20:57:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P0sJ827220
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 20:54:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11645
	for <megaco@ietf.org>; Thu, 24 Apr 2003 20:50:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rSl-0003T7-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:53:15 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rSl-0003Sd-00
	for megaco@ietf.org; Thu, 24 Apr 2003 20:53:15 -0400
Received: from cisco.com (sjc-vpn3-561.cisco.com [10.21.66.49])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3P0r608013684;
	Thu, 24 Apr 2003 17:53:07 -0700 (PDT)
Message-ID: <3EA886F2.CCAE1EE5@cisco.com>
Date: Thu, 24 Apr 2003 20:53:06 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin Boyle <kboyle@nortelnetworks.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Kevin Boyle wrote:

>
>
> Comments inline. [KJBII]
>
> Kevin
>
> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Thursday, April 24, 2003 11:24 AM
> To: Adrian Soncodi
> Cc: Fernando Vallejo Lazaro; megaco@ietf.org
> Subject: Re: [Megaco] Support for redundant MG failover
>
>

<snip>

>
>
> I think part of the problem here is that the concept of a control
> association is not very well defined when it comes to UDP; how do you
> determine if a message received is part of the UDP control association
> ?
>
> [KJBII] H.248 control associations have absolutely nothing to do with
> transport.

Why not ? If I'm using TCP, then how can anything be sent outside that
TCP connection in either direction ?


> To quote from the most recent version of Annex F: "A control
> association is a communication relationship whereby an MGC is
> controlling an MG.  A control association is instantiated via
> registration.  The control association is terminated by the MG going
> out of service, being successfully handed off to an alternate MGC, or
> successfully failing over to an alternate MGC.  An MG shall have at
> most one control association at any time.  Only MGs may instantiate
> control associations.  Control associations as defined here apply only
> within the context of media gateway control signalling.  This
> definition should not be confused with that of control associations in
> the context of transport (TCP, UDP, etc.)."
>

I think you need to throw in a bit more text and perhaps some examples.
The above doesn't make it a whole lot clearer exactly what a control
association is and the semantics it carries with it.

>
> [KJBII] So, to go even further on the point above, the MG may "know"
> MGC-A2 (that is, have it in its list of MGCs), but because there can
> be only one control association at any given time, and those
> associations are established by the MG, the communication from MGC-A2
> should be viewed as, at best, an inappropriate control message.

How does the MG "know" that the message comes from MGC-A2 and not MGC-A1
? Is that simply based on the mID in the message header ? If so, the
concept of a control association seems a bit fluffy (anybody can put
whatever name they want in there). If not, what is it based on ?


> At worst, it would be an attack to attempt to gain control of the MG.
> Also, I would like to note that an audit command would never be
> construed as a failover.  Only a SC with a method of failover would be
> a failover.
>

OK, however I'm still missing a clear definition of exactly what a
control association is, and how the MG determines if a message it is
either sending or receiving is part of an existing control association.

>
> Yes, however there are ways around this problem (by design, Megaco
> chose to only have the MG be able to initiate the control association,
> so you just need to make sure it does that - see H.248.14 for a
> solution).
>
> There are however a couple of bad things here:
> 1. Only the statically provisioned list of backup MGCs can be
> contacted, and only in the order they were provisioned.
>
> [KJBII] This is bad because?
>

1. Provisioning in general is bad.
2. The backups cannot be changed dynamically which is problematic in
lots of cases. For example, if I need to change the list of backups due
to upgrades, failures, etc., there's no simple or dynamic way of doing
this. Another example could be that each (or some) of the backups
represent alternative interfaces for a single MGC. How do I now redirect
my MG to not contact any of these interfaces ? Can't be done.

and the list goes on.


>
> 2. The spec is silent on whether a backup MGC replicates the state of
> the primary or not. Consequently, you cannot assume that it does, and
> hence switching to the backup is something you don't want to do
> prematurely.
>
> [KJBII] Why is this the MGs concern?  The backup MGC is responsible
> for getting itself attuned to the current state of affairs on the MG.
> This can be done in any number of ways, some of which are more
> detrimental to existing connections than others.
>

It's a concern because a failure to receive a response may occur for any
number of reasons (as you note below), e.g. interface failure, network
problems, or MGC failure. If you knew, that some of the addresses belong
to the same MGC (which could be a cluster of boxes), then upon not
receiving a response, you could quickly move on to another interface
without any risk. In this way, interface failures and local network
problems that do not affect all interfaces are not catastrophic. As for
a backup MGC to audit an MG to figure out what is going, this is first
of all a time-consuming and resource-intensive task, and secondly it
will not allow for a transparent failover in all cases, let alone
restore the call state that existed on the failed MGC.

>
> 3. The switchover is not graceful, i.e. there has to be a failure
> before you start contacting the backup. In contrast, a more robust
> redundancy scheme would detect/suspect the failure earlier during
> retransmission and switch to one of the backups to prevent any loss of
> state. Furthermore, there should be a way of indicating that a backup
> is fully redundant and hence the switchover can be done fairly early
> without any risk.
>
> [KJBII] Hmmm.  How would the MG know that the retransmissions were due
> to MGC failure, as opposed to network congestion?  I believe that the
> MG will have to wait for the retransmissions to run their course, or
> to utilize a different method of determining that the MGC had failed
> that eliminates network congestion as a possibility.
>

Exactly. The MG will not be able to determine what the real problem is,
however in the event the problem only affects part of the MGC and
communication to a different interface is possible, allowing/requiring
the MG to move on quickly to the next interface is very helpful.

>
> >> - Another thing the MGC can do when it detects the that A1 is going
>
> >> to die is to send a Handoff to the interface A2 for each MG so that
>
> >> the connections are restablished in the new path.
> >
> > This is what it's forced to do, but the MG is not aware that the
> > handoff is to the same MGC. Consequently, it continues to send
> pending
> > notifications to the old IP address, as per RFC 3015 section 7.2.8
> > (and still in h248v2-04):
> >
> > "At the same time, as indicated in clause 9, transaction replies and
>
> > pending indications must be sent to the address from which the
> > corresponding requests originated."
> >
> > This forces the "new" MGC (which is not really new) to re-issue all
> > the notification requests, which, apart from being a substantial
> > overhead, can cause serious race conditions, especially with
> packages
> > such as bcas. Again, from experience, this is a point of contention,
>
> > whether or not it's the right behavior.
>
> [KJBII] Not true.  Any NEW event detections would go to the "new"
> MGC.  Remember, events in H.248 persist until a new events descriptor
> is sent to replace the old.  Therefore, even through a
> handoff/failover, the MG should continue to scan for events and report
> them to the controlling MGC -- the "new" MGC once the handoff/failover
> occurs.
>

Right, but what about old ones that are in the process of being
retransmitted and/or new ones being generated before the new control
association is up ? They should of course go to the new MGC as well, but
does the spec actually say that (it may be implied by the control
association, but if not already specified explicitly, it would be worth
doing so) ?


>
> >
> > If the MG were somehow aware that this is the same MGC, the
> signaling
> > path switchover between A1-A1 and A2-A2 would be faster and more
> > reliable.
> >
> > I think the MEGACO spec obviously did not consider multi-homed
> > MGs/MGCs, therefore we are trying to see if the existing rules
> "happen
> > to work" in this case. I have had a lot of arguments over it because
>
> > of different interpretations.
> >
>
> I agree (and actually, I'm surprised nobody has addressed it yet
> because it has been known for a long time and pops up on the mailing
> list from time time, but without much progress being made).
>
> -- Flemming
>
> [KJBII] There are many possibilities for redundancy -- multihoming is
> not the only one.  Further, I don't see how the rules don't work, or
> how we can optimize this particular case without penalizing the other
> possibilities.  The MG should not know, or care, that the MGC is
> multihomed.  The same goes for the MGC with respect to the MG.  If you
> change IP addresses, then you change control association, and that has
> consequences that have to be rectified by the MGC.
>

I disagree and based on this thread as well as similar ones in the past,
so do others it seems. As an aside, MGCP specified these things in great
detail, and I have yet to hear anybody complain that it is overly
restrictive in its support for multihoming and redundancy. On the
contrary. The same can easily be done for Megaco.

-- Flemming


>

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 21:19:48 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12331
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 21:19:48 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1M4829548;
	Thu, 24 Apr 2003 21:22:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1J2829335
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 21:19:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12226
	for <megaco@ietf.org>; Thu, 24 Apr 2003 21:15:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rqg-0003eL-00
	for megaco@ietf.org; Thu, 24 Apr 2003 21:17:58 -0400
Received: from motgate2.mot.com ([136.182.1.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rqf-0003eI-00
	for megaco@ietf.org; Thu, 24 Apr 2003 21:17:57 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100])
	by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h3P1IPmd024117
	for <megaco@ietf.org>; Thu, 24 Apr 2003 18:18:25 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA10039 for <megaco@ietf.org>; Thu, 24 Apr 2003 18:18:25 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN5HGG; Thu, 24 Apr 2003 20:18:25 -0500
Message-ID: <3EA88D01.5EA8AF1D@motorola.com>
Date: Thu, 24 Apr 2003 20:18:57 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Flemming Andreasen wrote:
> 
> Qiaobing Xie wrote:
> 
> > I disagree with the notion that MEGACO spec fails to address
> > multi-homing. Multi-homing is elegantly addressed by using SCTP
> > (specified in H.248 Annex H). One of the reasons for having SCTP in IETF
> > is to relieve other upper layer protocols, such as MEGACO, from the
> > complicated task of dealing with multi-homing.
> >
> > I'd call it a bad strategy if now some one would insist on using UDP and
> > duplicate the multi-homing handling complexity of SCTP inside MEGACO
> > before calling it adequately addressed.
> >
> 
> If SCTP support was an integral part of and mandatory in Megaco, then I'd
> agree with that, however it's not; TCP and UDP are.
> 

Then, is multi-homing support "an integral part of and mandatory in
Megaco"? 

It seems to me there are only two options: 1) if people feel that
multi-homing should be made "an integral part of and mandatory in
Megaco", then the solution could be to simply make SCTP "an integral
part of and mandatory in Megaco" and we are done. 2) if people feel that
multi-homing should be optional, then whenever/wherever one needs
multi-homing, he/she simply uses the "optional" SCTP transport and the
problem is solved. I don't see a case where more stuff needs to be built
into MEGACO. In other words, either way I see MEGACO spec as complete
and adequate.

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 21:20:52 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12378
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 21:20:52 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3P1Nin29622
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 21:23:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1Ni829619
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 21:23:44 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12351
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 21:20:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rvE-0003g7-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 21:22:40 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198rvD-0003g4-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 21:22:39 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1M4829548;
	Thu, 24 Apr 2003 21:22:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1J2829335
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 21:19:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12226
	for <megaco@ietf.org>; Thu, 24 Apr 2003 21:15:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rqg-0003eL-00
	for megaco@ietf.org; Thu, 24 Apr 2003 21:17:58 -0400
Received: from motgate2.mot.com ([136.182.1.10])
	by ietf-mx with esmtp (Exim 4.12)
	id 198rqf-0003eI-00
	for megaco@ietf.org; Thu, 24 Apr 2003 21:17:57 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100])
	by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h3P1IPmd024117
	for <megaco@ietf.org>; Thu, 24 Apr 2003 18:18:25 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA10039 for <megaco@ietf.org>; Thu, 24 Apr 2003 18:18:25 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN5HGG; Thu, 24 Apr 2003 20:18:25 -0500
Message-ID: <3EA88D01.5EA8AF1D@motorola.com>
Date: Thu, 24 Apr 2003 20:18:57 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Flemming Andreasen wrote:
> 
> Qiaobing Xie wrote:
> 
> > I disagree with the notion that MEGACO spec fails to address
> > multi-homing. Multi-homing is elegantly addressed by using SCTP
> > (specified in H.248 Annex H). One of the reasons for having SCTP in IETF
> > is to relieve other upper layer protocols, such as MEGACO, from the
> > complicated task of dealing with multi-homing.
> >
> > I'd call it a bad strategy if now some one would insist on using UDP and
> > duplicate the multi-homing handling complexity of SCTP inside MEGACO
> > before calling it adequately addressed.
> >
> 
> If SCTP support was an integral part of and mandatory in Megaco, then I'd
> agree with that, however it's not; TCP and UDP are.
> 

Then, is multi-homing support "an integral part of and mandatory in
Megaco"? 

It seems to me there are only two options: 1) if people feel that
multi-homing should be made "an integral part of and mandatory in
Megaco", then the solution could be to simply make SCTP "an integral
part of and mandatory in Megaco" and we are done. 2) if people feel that
multi-homing should be optional, then whenever/wherever one needs
multi-homing, he/she simply uses the "optional" SCTP transport and the
problem is solved. I don't see a case where more stuff needs to be built
into MEGACO. In other words, either way I see MEGACO spec as complete
and adequate.

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Thu Apr 24 23:22:49 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14079
	for <megaco-archive@lists.ietf.org>; Thu, 24 Apr 2003 23:22:49 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3Om805439;
	Thu, 24 Apr 2003 23:24:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3Lw805372
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 23:21:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14063
	for <megaco@ietf.org>; Thu, 24 Apr 2003 23:18:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198tlb-0004EK-00
	for megaco@ietf.org; Thu, 24 Apr 2003 23:20:51 -0400
Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198tlZ-0004EB-00
	for megaco@ietf.org; Thu, 24 Apr 2003 23:20:50 -0400
Received: (from root@localhost)
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h3P3N3f31165;
	Fri, 25 Apr 2003 08:53:03 +0530
Received: from euronymous ([132.147.166.61])
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h3P3N1t31157;
	Fri, 25 Apr 2003 08:53:01 +0530
Reply-To: <milton@hfcl.com>
From: "Milton" <milton@hfcl.com>
To: <megaco@ietf.org>
Cc: "'Kevin Boyle'" <kboyle@nortelnetworks.com>
Subject: RE: [Megaco] (no subject)
Date: Fri, 25 Apr 2003 08:50:01 +0530
Message-ID: <000201c30ad9$8f3fa600$3da69384@euronymous>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C30B07.A8F7E200"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C08E99424@zrtpd0jq.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Xmilter: rnd.hfcl.com
X-Virus-Scanned: by AMaViS perl-11
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C30B07.A8F7E200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [Megaco] (no subject)


        Hi Kevin and All,
        I want to apologize for saying " you people", may I replace that
with "we people" ?  I am sorry but probably I do not quite understand the
working process of IESG and ITU - in my opinion we should think about
finishing our job when we set our 'goals'. But frankly I like the 'openness'
of IETF where 'we common people' can participate in the processes and have
all the standards freely available. So in my opinion IETF should continue to
involve itself in the standardization process actively.
                                                                            
                                                                            
-Milton
  Dear All,

  We all have seen the mail from Kevin that says: "IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES". He also said ... I am quoting him: "Given that
the working group is in the process of winding down, I do not see any
benefit to anyone in continuing to allow the IETF to hold up standardization
when the ITU is prepared to consider and advance the work."

  Although his comments ring true but his conclusion is frustrating. First
and foremost question is why you people have decided to "WIND DOWN" the
working group?

  [KJBII] Closing a working group is decided by the IESG based on completion
of the goals set forth in the group charter, and the work produced by the
group. "We people" did not overtly decide to wind down the working group,
but the fact is that the WG has not produced any work of note in quite some
time.

  - If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

  [KJBII] IETF and ITU started to progress work on the same topic at the
same time.  Rather than end up with two competing standards, the two
organizations decided to join forces.  I believe that the resultant protocol
shows great success in that collaboration.  I believe we did see the best of
both worlds.  However, the IETF has problems with its processes --
self-acknowledged problems.  I believe these will need to be worked out
before the IETF is prepared to take on more work directly related to
H.248/Megaco.

  -       If you people think that you are done with Megaco then in my
opinion you
  are grossly wrong. A protocol is named so because it gives people a
"standardized and optimized" set of rules for "interworking". Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with "extensions" to the
"base protocol"  - standardizing packages give you that opportunity. But of
course, Kevin was right in saying that IETF is not "up and running" and not
working efficiently. I propose you people in IETF "MUST"(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.

  [KJBII] I do not believe package standardization has ever been a work item
on the charter of the working group.  Therefore, package standardization has
never been in the scope of the working group, other than the courtesy of
allowing the list to comment on packages.  Note that the procedures for
developing packages do not require this courtesy.  I don't believe anybody
said that "we" are "done with Megaco".  I, personally, have several
significant work items in the ITU that will make the protocol better for
everyone.  The ITU meetings are not secret affairs, and the working
documents are available to everyone on the list via anonymous FTP.  Comments
that are raised on the list are discussed at the ITU meetings.  Note that
the list will continue, even after the WG completes at some point in the
future.  Note that the H.248 working documents will also continue to be
available to all, as well.

  [KJBII] Your message uses the phrase "you people" quite a bit.  Are you
not a member of the group?  Are you not one of those involved?  Either way,
though, it is a matter of fact that the WG has not produced any work of note
in recent times, and that is one of the criterion looked at when deciding
whether or not it is worthwhile to continue a working group.



  -Milton

  _______________________________________________
  Megaco mailing list
  Megaco@ietf.org
  https://www1.ietf.org/mailman/listinfo/megaco


------=_NextPart_000_0003_01C30B07.A8F7E200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [Megaco] (no subject)</TITLE>

<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D000485902-25042003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hi =
Kevin and=20
All,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D000485902-25042003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I&nbsp;want=20
to apologize for saying " you people", may I replace that with "we =
people"=20
?&nbsp; I am sorry but probably I do not quite understand the working =
process of=20
IESG&nbsp;and ITU - in my opinion we should think about finishing our =
job when=20
we set our 'goals'. But frankly&nbsp;I like the 'openness' of IETF=20
where&nbsp;'we&nbsp;common people' can participate in the processes and =
have all=20
the standards freely available. So in my opinion IETF should continue=20
to&nbsp;involve itself in the standardization process=20
actively.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D000485902-25042003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
-Milton</SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>Dear All,</FONT> </P>
  <P><FONT size=3D2>We all have seen the mail from Kevin that says: =
"IETF IS NOT=20
  INTERESTED IN STANDARDIZING ANY PACKAGES". He also said ... I am =
quoting him:=20
  "Given that the working group is in the process of winding down, I do =
not see=20
  any benefit to anyone in continuing to allow the IETF to hold up=20
  standardization when the ITU is prepared to consider and advance the=20
  work."</FONT></P>
  <P><FONT size=3D2>Although his comments ring true but his conclusion =
is=20
  frustrating. First and foremost question is why you people have =
decided to=20
  "WIND DOWN" the working group?</FONT></P>
  <P><FONT size=3D2>[KJBII] Closing a working group is decided by the =
IESG based=20
  on completion of the goals set forth in the group charter, and the =
work=20
  produced by the group. "We people" did not overtly decide to wind down =
the=20
  working group, but the fact is that the WG has not produced any work =
of note=20
  in quite some time.</FONT></P>
  <P><FONT size=3D2>- If your decision is motivated by the fact that ITU =
is going=20
  to take care of the protocol then why did IETF join hands with ITU in =
the=20
  first place? If they (ITU and IETF) want to collaborate - then this is =
not the=20
  way to COLLABORATE. IETF and ITU have totally different working styles =
and=20
  philosophy - IETF is more democratic and open whereas ITU is rigorous =
in=20
  process. We thought we would see the best of the both =
worlds!!!!!</FONT></P>
  <P><FONT size=3D2>[KJBII] IETF and ITU started to progress work on the =
same=20
  topic at the same time.&nbsp; Rather than end up with two competing =
standards,=20
  the two organizations decided to join forces.&nbsp; I believe that the =

  resultant protocol shows great success in that collaboration.&nbsp; I =
believe=20
  we did see the best of both worlds.&nbsp; However, the IETF has =
problems with=20
  its processes -- self-acknowledged problems.&nbsp; I believe these =
will need=20
  to be worked out before the IETF is prepared to take on more work =
directly=20
  related to H.248/Megaco.</FONT></P>
  <P><FONT size=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you people =
think that=20
  you are done with Megaco then in my opinion you</FONT> <BR><FONT =
size=3D2>are=20
  grossly wrong. A protocol is named so because it gives people a =
"standardized=20
  and optimized" set of rules for "interworking". Does Megaco as a =
protocol=20
  satisfy this definition? Hardly so. Megaco base protocol gives you a =
framework=20
  - to make voice over packet network a reality, different standards are =
to be=20
  developed on the top of this framework. AND OFCOURSE IT IS NOT A GOOD =
IDEA TO=20
  HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS (LIKE MSF) COMING =
UP WITH=20
  THREE DIFFERENT STANDARDS. It should be the responsibility of these =
standard=20
  bodies to come up with "extensions" to the "base protocol"&nbsp; -=20
  standardizing packages give you that opportunity. But of course, Kevin =
was=20
  right in saying that IETF is not "up and running" and not working =
efficiently.=20
  I propose you people in IETF "MUST"(is to be interpreted as described =
in RFC=20
  2119) think again before winding up the working group and we should =
think=20
  about finishing our job.</FONT></P>
  <P><FONT size=3D2>[KJBII] I do not believe package standardization has =
ever been=20
  a work item on the charter of the working group.&nbsp; Therefore, =
package=20
  standardization has never been in the scope of the working group, =
other than=20
  the courtesy of allowing the list to comment on packages.&nbsp; Note =
that the=20
  procedures for developing packages do not require this courtesy.&nbsp; =
I don't=20
  believe anybody said that "we" are "done with Megaco".&nbsp; I, =
personally,=20
  have several significant work items in the ITU that will make the =
protocol=20
  better for everyone.&nbsp; The ITU meetings are not secret affairs, =
and the=20
  working documents are available to everyone on the list via anonymous=20
  FTP.&nbsp; Comments that are raised on the list are discussed at the =
ITU=20
  meetings.&nbsp; Note that the list will continue, even after the WG =
completes=20
  at some point in the future.&nbsp; Note that the H.248 working =
documents will=20
  also continue to be available to all, as well.</FONT></P>
  <P><FONT size=3D2>[KJBII] Your message uses the phrase "you people" =
quite a=20
  bit.&nbsp; Are you not a member of the group?&nbsp; Are you not one of =
those=20
  involved?&nbsp; Either way, though, it is a matter of fact that the WG =
has not=20
  produced any work of note in recent times, and that is one of the =
criterion=20
  looked at when deciding whether or not it is worthwhile to continue a =
working=20
  group.</FONT></P><BR>
  <P><FONT size=3D2>-Milton</FONT> </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0003_01C30B07.A8F7E200--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Thu Apr 24 23:23:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14097
	for <megaco-archive@odin.ietf.org>; Thu, 24 Apr 2003 23:23:55 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3P3QoK05528
	for megaco-archive@odin.ietf.org; Thu, 24 Apr 2003 23:26:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3Qo805525
	for <megaco-web-archive@optimus.ietf.org>; Thu, 24 Apr 2003 23:26:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14094
	for <megaco-web-archive@ietf.org>; Thu, 24 Apr 2003 23:23:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198tqJ-0004FJ-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 23:25:43 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 198tqI-0004FG-00
	for megaco-web-archive@ietf.org; Thu, 24 Apr 2003 23:25:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3Om805439;
	Thu, 24 Apr 2003 23:24:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P3Lw805372
	for <megaco@optimus.ietf.org>; Thu, 24 Apr 2003 23:21:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14063
	for <megaco@ietf.org>; Thu, 24 Apr 2003 23:18:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 198tlb-0004EK-00
	for megaco@ietf.org; Thu, 24 Apr 2003 23:20:51 -0400
Received: from [203.196.156.177] (helo=netserv.rnd.hfcl.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 198tlZ-0004EB-00
	for megaco@ietf.org; Thu, 24 Apr 2003 23:20:50 -0400
Received: (from root@localhost)
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) id h3P3N3f31165;
	Fri, 25 Apr 2003 08:53:03 +0530
Received: from euronymous ([132.147.166.61])
	by netserv.rnd.hfcl.com (8.11.6/8.11.2) with SMTP id h3P3N1t31157;
	Fri, 25 Apr 2003 08:53:01 +0530
Reply-To: <milton@hfcl.com>
From: "Milton" <milton@hfcl.com>
To: <megaco@ietf.org>
Cc: "'Kevin Boyle'" <kboyle@nortelnetworks.com>
Subject: RE: [Megaco] (no subject)
Date: Fri, 25 Apr 2003 08:50:01 +0530
Message-ID: <000201c30ad9$8f3fa600$3da69384@euronymous>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C30B07.A8F7E200"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <ABA227A15B80D511BD1A00508BF93A1C08E99424@zrtpd0jq.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Xmilter: rnd.hfcl.com
X-Virus-Scanned: by AMaViS perl-11
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C30B07.A8F7E200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

RE: [Megaco] (no subject)


        Hi Kevin and All,
        I want to apologize for saying " you people", may I replace that
with "we people" ?  I am sorry but probably I do not quite understand the
working process of IESG and ITU - in my opinion we should think about
finishing our job when we set our 'goals'. But frankly I like the 'openness'
of IETF where 'we common people' can participate in the processes and have
all the standards freely available. So in my opinion IETF should continue to
involve itself in the standardization process actively.
                                                                            
                                                                            
-Milton
  Dear All,

  We all have seen the mail from Kevin that says: "IETF IS NOT INTERESTED IN
STANDARDIZING ANY PACKAGES". He also said ... I am quoting him: "Given that
the working group is in the process of winding down, I do not see any
benefit to anyone in continuing to allow the IETF to hold up standardization
when the ITU is prepared to consider and advance the work."

  Although his comments ring true but his conclusion is frustrating. First
and foremost question is why you people have decided to "WIND DOWN" the
working group?

  [KJBII] Closing a working group is decided by the IESG based on completion
of the goals set forth in the group charter, and the work produced by the
group. "We people" did not overtly decide to wind down the working group,
but the fact is that the WG has not produced any work of note in quite some
time.

  - If your decision is motivated by the fact that ITU is going to take care
of the protocol then why did IETF join hands with ITU in the first place? If
they (ITU and IETF) want to collaborate - then this is not the way to
COLLABORATE. IETF and ITU have totally different working styles and
philosophy - IETF is more democratic and open whereas ITU is rigorous in
process. We thought we would see the best of the both worlds!!!!!

  [KJBII] IETF and ITU started to progress work on the same topic at the
same time.  Rather than end up with two competing standards, the two
organizations decided to join forces.  I believe that the resultant protocol
shows great success in that collaboration.  I believe we did see the best of
both worlds.  However, the IETF has problems with its processes --
self-acknowledged problems.  I believe these will need to be worked out
before the IETF is prepared to take on more work directly related to
H.248/Megaco.

  -       If you people think that you are done with Megaco then in my
opinion you
  are grossly wrong. A protocol is named so because it gives people a
"standardized and optimized" set of rules for "interworking". Does Megaco as
a protocol satisfy this definition? Hardly so. Megaco base protocol gives
you a framework - to make voice over packet network a reality, different
standards are to be developed on the top of this framework. AND OFCOURSE IT
IS NOT A GOOD IDEA TO HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS
(LIKE MSF) COMING UP WITH THREE DIFFERENT STANDARDS. It should be the
responsibility of these standard bodies to come up with "extensions" to the
"base protocol"  - standardizing packages give you that opportunity. But of
course, Kevin was right in saying that IETF is not "up and running" and not
working efficiently. I propose you people in IETF "MUST"(is to be
interpreted as described in RFC 2119) think again before winding up the
working group and we should think about finishing our job.

  [KJBII] I do not believe package standardization has ever been a work item
on the charter of the working group.  Therefore, package standardization has
never been in the scope of the working group, other than the courtesy of
allowing the list to comment on packages.  Note that the procedures for
developing packages do not require this courtesy.  I don't believe anybody
said that "we" are "done with Megaco".  I, personally, have several
significant work items in the ITU that will make the protocol better for
everyone.  The ITU meetings are not secret affairs, and the working
documents are available to everyone on the list via anonymous FTP.  Comments
that are raised on the list are discussed at the ITU meetings.  Note that
the list will continue, even after the WG completes at some point in the
future.  Note that the H.248 working documents will also continue to be
available to all, as well.

  [KJBII] Your message uses the phrase "you people" quite a bit.  Are you
not a member of the group?  Are you not one of those involved?  Either way,
though, it is a matter of fact that the WG has not produced any work of note
in recent times, and that is one of the criterion looked at when deciding
whether or not it is worthwhile to continue a working group.



  -Milton

  _______________________________________________
  Megaco mailing list
  Megaco@ietf.org
  https://www1.ietf.org/mailman/listinfo/megaco


------=_NextPart_000_0003_01C30B07.A8F7E200
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [Megaco] (no subject)</TITLE>

<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D000485902-25042003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hi =
Kevin and=20
All,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D000485902-25042003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
I&nbsp;want=20
to apologize for saying " you people", may I replace that with "we =
people"=20
?&nbsp; I am sorry but probably I do not quite understand the working =
process of=20
IESG&nbsp;and ITU - in my opinion we should think about finishing our =
job when=20
we set our 'goals'. But frankly&nbsp;I like the 'openness' of IETF=20
where&nbsp;'we&nbsp;common people' can participate in the processes and =
have all=20
the standards freely available. So in my opinion IETF should continue=20
to&nbsp;involve itself in the standardization process=20
actively.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D000485902-25042003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
-Milton</SPAN></FONT></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <P><FONT size=3D2>Dear All,</FONT> </P>
  <P><FONT size=3D2>We all have seen the mail from Kevin that says: =
"IETF IS NOT=20
  INTERESTED IN STANDARDIZING ANY PACKAGES". He also said ... I am =
quoting him:=20
  "Given that the working group is in the process of winding down, I do =
not see=20
  any benefit to anyone in continuing to allow the IETF to hold up=20
  standardization when the ITU is prepared to consider and advance the=20
  work."</FONT></P>
  <P><FONT size=3D2>Although his comments ring true but his conclusion =
is=20
  frustrating. First and foremost question is why you people have =
decided to=20
  "WIND DOWN" the working group?</FONT></P>
  <P><FONT size=3D2>[KJBII] Closing a working group is decided by the =
IESG based=20
  on completion of the goals set forth in the group charter, and the =
work=20
  produced by the group. "We people" did not overtly decide to wind down =
the=20
  working group, but the fact is that the WG has not produced any work =
of note=20
  in quite some time.</FONT></P>
  <P><FONT size=3D2>- If your decision is motivated by the fact that ITU =
is going=20
  to take care of the protocol then why did IETF join hands with ITU in =
the=20
  first place? If they (ITU and IETF) want to collaborate - then this is =
not the=20
  way to COLLABORATE. IETF and ITU have totally different working styles =
and=20
  philosophy - IETF is more democratic and open whereas ITU is rigorous =
in=20
  process. We thought we would see the best of the both =
worlds!!!!!</FONT></P>
  <P><FONT size=3D2>[KJBII] IETF and ITU started to progress work on the =
same=20
  topic at the same time.&nbsp; Rather than end up with two competing =
standards,=20
  the two organizations decided to join forces.&nbsp; I believe that the =

  resultant protocol shows great success in that collaboration.&nbsp; I =
believe=20
  we did see the best of both worlds.&nbsp; However, the IETF has =
problems with=20
  its processes -- self-acknowledged problems.&nbsp; I believe these =
will need=20
  to be worked out before the IETF is prepared to take on more work =
directly=20
  related to H.248/Megaco.</FONT></P>
  <P><FONT size=3D2>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you people =
think that=20
  you are done with Megaco then in my opinion you</FONT> <BR><FONT =
size=3D2>are=20
  grossly wrong. A protocol is named so because it gives people a =
"standardized=20
  and optimized" set of rules for "interworking". Does Megaco as a =
protocol=20
  satisfy this definition? Hardly so. Megaco base protocol gives you a =
framework=20
  - to make voice over packet network a reality, different standards are =
to be=20
  developed on the top of this framework. AND OFCOURSE IT IS NOT A GOOD =
IDEA TO=20
  HAVE THREE DIFFERENT ORGANIZATIONS OR ASSOCIATIONS (LIKE MSF) COMING =
UP WITH=20
  THREE DIFFERENT STANDARDS. It should be the responsibility of these =
standard=20
  bodies to come up with "extensions" to the "base protocol"&nbsp; -=20
  standardizing packages give you that opportunity. But of course, Kevin =
was=20
  right in saying that IETF is not "up and running" and not working =
efficiently.=20
  I propose you people in IETF "MUST"(is to be interpreted as described =
in RFC=20
  2119) think again before winding up the working group and we should =
think=20
  about finishing our job.</FONT></P>
  <P><FONT size=3D2>[KJBII] I do not believe package standardization has =
ever been=20
  a work item on the charter of the working group.&nbsp; Therefore, =
package=20
  standardization has never been in the scope of the working group, =
other than=20
  the courtesy of allowing the list to comment on packages.&nbsp; Note =
that the=20
  procedures for developing packages do not require this courtesy.&nbsp; =
I don't=20
  believe anybody said that "we" are "done with Megaco".&nbsp; I, =
personally,=20
  have several significant work items in the ITU that will make the =
protocol=20
  better for everyone.&nbsp; The ITU meetings are not secret affairs, =
and the=20
  working documents are available to everyone on the list via anonymous=20
  FTP.&nbsp; Comments that are raised on the list are discussed at the =
ITU=20
  meetings.&nbsp; Note that the list will continue, even after the WG =
completes=20
  at some point in the future.&nbsp; Note that the H.248 working =
documents will=20
  also continue to be available to all, as well.</FONT></P>
  <P><FONT size=3D2>[KJBII] Your message uses the phrase "you people" =
quite a=20
  bit.&nbsp; Are you not a member of the group?&nbsp; Are you not one of =
those=20
  involved?&nbsp; Either way, though, it is a matter of fact that the WG =
has not=20
  produced any work of note in recent times, and that is one of the =
criterion=20
  looked at when deciding whether or not it is worthwhile to continue a =
working=20
  group.</FONT></P><BR>
  <P><FONT size=3D2>-Milton</FONT> </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Megaco mailing list</FONT> <BR><FONT=20
  size=3D2>Megaco@ietf.org</FONT> <BR><FONT size=3D2><A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/megaco"=20
  =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/megaco</A></FONT> =

</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0003_01C30B07.A8F7E200--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 08:55:41 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07334
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 08:55:41 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCvd822814;
	Fri, 25 Apr 2003 08:57:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCqG822638
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 08:52:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07210
	for <megaco@ietf.org>; Fri, 25 Apr 2003 08:48:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1992fK-0000J2-00
	for megaco@ietf.org; Fri, 25 Apr 2003 08:50:58 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 1992fJ-0000Is-00
	for megaco@ietf.org; Fri, 25 Apr 2003 08:50:57 -0400
Received: from cisco.com (sjc-vpn4-236.cisco.com [10.21.80.236])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PCon08001916;
	Fri, 25 Apr 2003 05:50:50 -0700 (PDT)
Message-ID: <3EA92F29.93F0F95D@cisco.com>
Date: Fri, 25 Apr 2003 08:50:49 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

> Flemming Andreasen wrote:
> >
> > Qiaobing Xie wrote:
> >
> > > I disagree with the notion that MEGACO spec fails to address
> > > multi-homing. Multi-homing is elegantly addressed by using SCTP
> > > (specified in H.248 Annex H). One of the reasons for having SCTP in IETF
> > > is to relieve other upper layer protocols, such as MEGACO, from the
> > > complicated task of dealing with multi-homing.
> > >
> > > I'd call it a bad strategy if now some one would insist on using UDP and
> > > duplicate the multi-homing handling complexity of SCTP inside MEGACO
> > > before calling it adequately addressed.
> > >
> >
> > If SCTP support was an integral part of and mandatory in Megaco, then I'd
> > agree with that, however it's not; TCP and UDP are.
> >
>
> Then, is multi-homing support "an integral part of and mandatory in
> Megaco"?
>
> It seems to me there are only two options: 1) if people feel that
> multi-homing should be made "an integral part of and mandatory in
> Megaco", then the solution could be to simply make SCTP "an integral
> part of and mandatory in Megaco" and we are done. 2) if people feel that
> multi-homing should be optional, then whenever/wherever one needs
> multi-homing, he/she simply uses the "optional" SCTP transport and the
> problem is solved.

Those are indeed two options, and from a theoretical point of view, there is no
doubt this is the cleanest solution. Having said that, the original question was
whether Megaco has adequate built-in support for redundancy and failover. Some
claimed it did, however they have yet to show how it would actually work let
alone where it is specified, and you seem to agree that without SCTP, there are
indeed holes here.


> I don't see a case where more stuff needs to be built
> into MEGACO. In other words, either way I see MEGACO spec as complete
> and adequate.
>

So is it consensus that Megaco needs SCTP in order to properly support
multihoming/redundancy/failover, and there should be no further specification of
how that might be achieved using UDP/TCP instead ?

On a related note:    When the concept of a control association is clarified,
please make sure that the clarification explicitly covers SCTP operation as
well.

-- Flemming



>
> -Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 08:56:45 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07355
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 08:56:45 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PCxoB22991
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 08:59:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCxo822988
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 08:59:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07351
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 08:56:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1992md-0000MQ-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 08:58:31 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1992md-0000MN-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 08:58:31 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCvd822814;
	Fri, 25 Apr 2003 08:57:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PCqG822638
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 08:52:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07210
	for <megaco@ietf.org>; Fri, 25 Apr 2003 08:48:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1992fK-0000J2-00
	for megaco@ietf.org; Fri, 25 Apr 2003 08:50:58 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 1992fJ-0000Is-00
	for megaco@ietf.org; Fri, 25 Apr 2003 08:50:57 -0400
Received: from cisco.com (sjc-vpn4-236.cisco.com [10.21.80.236])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PCon08001916;
	Fri, 25 Apr 2003 05:50:50 -0700 (PDT)
Message-ID: <3EA92F29.93F0F95D@cisco.com>
Date: Fri, 25 Apr 2003 08:50:49 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

> Flemming Andreasen wrote:
> >
> > Qiaobing Xie wrote:
> >
> > > I disagree with the notion that MEGACO spec fails to address
> > > multi-homing. Multi-homing is elegantly addressed by using SCTP
> > > (specified in H.248 Annex H). One of the reasons for having SCTP in IETF
> > > is to relieve other upper layer protocols, such as MEGACO, from the
> > > complicated task of dealing with multi-homing.
> > >
> > > I'd call it a bad strategy if now some one would insist on using UDP and
> > > duplicate the multi-homing handling complexity of SCTP inside MEGACO
> > > before calling it adequately addressed.
> > >
> >
> > If SCTP support was an integral part of and mandatory in Megaco, then I'd
> > agree with that, however it's not; TCP and UDP are.
> >
>
> Then, is multi-homing support "an integral part of and mandatory in
> Megaco"?
>
> It seems to me there are only two options: 1) if people feel that
> multi-homing should be made "an integral part of and mandatory in
> Megaco", then the solution could be to simply make SCTP "an integral
> part of and mandatory in Megaco" and we are done. 2) if people feel that
> multi-homing should be optional, then whenever/wherever one needs
> multi-homing, he/she simply uses the "optional" SCTP transport and the
> problem is solved.

Those are indeed two options, and from a theoretical point of view, there is no
doubt this is the cleanest solution. Having said that, the original question was
whether Megaco has adequate built-in support for redundancy and failover. Some
claimed it did, however they have yet to show how it would actually work let
alone where it is specified, and you seem to agree that without SCTP, there are
indeed holes here.


> I don't see a case where more stuff needs to be built
> into MEGACO. In other words, either way I see MEGACO spec as complete
> and adequate.
>

So is it consensus that Megaco needs SCTP in order to properly support
multihoming/redundancy/failover, and there should be no further specification of
how that might be achieved using UDP/TCP instead ?

On a related note:    When the concept of a control association is clarified,
please make sure that the clarification explicitly covers SCTP operation as
well.

-- Flemming



>
> -Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 12:29:55 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13752
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 12:29:55 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGVx807741;
	Fri, 25 Apr 2003 12:31:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGQ9807548
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 12:26:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13589
	for <megaco@ietf.org>; Fri, 25 Apr 2003 12:22:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19960D-0001ou-00
	for megaco@ietf.org; Fri, 25 Apr 2003 12:24:45 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19960D-0001op-00
	for megaco@ietf.org; Fri, 25 Apr 2003 12:24:45 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042511244311:685 ;
          Fri, 25 Apr 2003 11:24:43 -0500 
Message-ID: <3EA962D7.1080902@tekelec.com>
Date: Fri, 25 Apr 2003 11:31:19 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 11:24:43 AM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 11:25:15 AM,
	Serialize complete at 04/25/2003 11:25:15 AM
Content-Type: multipart/alternative;
 boundary="------------070100010905040200050504"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------070100010905040200050504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Flemming Andreasen wrote:

>
>Qiaobing Xie wrote:
>
>>Flemming Andreasen wrote:
>>
>>>Qiaobing Xie wrote:
>>>
>>>>I disagree with the notion that MEGACO spec fails to address
>>>>multi-homing. Multi-homing is elegantly addressed by using SCTP
>>>>(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
>>>>is to relieve other upper layer protocols, such as MEGACO, from the
>>>>complicated task of dealing with multi-homing.
>>>>
>>>>I'd call it a bad strategy if now some one would insist on using UDP and
>>>>duplicate the multi-homing handling complexity of SCTP inside MEGACO
>>>>before calling it adequately addressed.
>>>>
>>>If SCTP support was an integral part of and mandatory in Megaco, then I'd
>>>agree with that, however it's not; TCP and UDP are.
>>>
>>Then, is multi-homing support "an integral part of and mandatory in
>>Megaco"?
>>
>>It seems to me there are only two options: 1) if people feel that
>>multi-homing should be made "an integral part of and mandatory in
>>Megaco", then the solution could be to simply make SCTP "an integral
>>part of and mandatory in Megaco" and we are done. 2) if people feel that
>>multi-homing should be optional, then whenever/wherever one needs
>>multi-homing, he/she simply uses the "optional" SCTP transport and the
>>problem is solved.
>>
>
>Those are indeed two options, and from a theoretical point of view, there is no
>doubt this is the cleanest solution. Having said that, the original question was
>whether Megaco has adequate built-in support for redundancy and failover. Some
>claimed it did, however they have yet to show how it would actually work let
>alone where it is specified, and you seem to agree that without SCTP, there are
>indeed holes here.
>
>
>>I don't see a case where more stuff needs to be built
>>into MEGACO. In other words, either way I see MEGACO spec as complete
>>and adequate.
>>
>
>So is it consensus that Megaco needs SCTP in order to properly support
>multihoming/redundancy/failover, and there should be no further specification of
>how that might be achieved using UDP/TCP instead ?
>
>On a related note:    When the concept of a control association is clarified,
>please make sure that the clarification explicitly covers SCTP operation as
>well.
>
>-- Flemming
>
And the number of FQDNs and IP addresses per MGC. Also clarify what 
happens if a DNS query returns more than 1 IP address for an MGC 
(assuming SCTP is not supported, is only the first one considered)?
This is important for the MEGACO MIB. The one that is currently in the 
works actually does specify a single IP address per MGC. If SCTP is 
supported, then there should be more ... But I wouldn't expect the MIB 
document to clarify what the model is, I think it should just reflect 
the model as per the main document.

Adrian

>
>
>
>>-Qiaobing
>>
>
>


--------------070100010905040200050504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
<br>
<br>
Flemming Andreasen wrote:<br>
<blockquote type="cite" cite="mid:3EA92F29.93F0F95D@cisco.com">
  <pre wrap=""><br>Qiaobing Xie wrote:<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">Flemming Andreasen wrote:<br></pre>
    <blockquote type="cite">
      <pre wrap="">Qiaobing Xie wrote:<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">I disagree with the notion that MEGACO spec fails to address<br>multi-homing. Multi-homing is elegantly addressed by using SCTP<br>(specified in H.248 Annex H). One of the reasons for having SCTP in IETF<br>is to relieve other upper layer protocols, such as MEGACO, from the<br>complicated task of dealing with multi-homing.<br><br>I'd call it a bad strategy if now some one would insist on using UDP and<br>duplicate the multi-homing handling complexity of SCTP inside MEGACO<br>before calling it adequately addressed.<br><br></pre>
        </blockquote>
        <pre wrap="">If SCTP support was an integral part of and mandatory in Megaco, then I'd<br>agree with that, however it's not; TCP and UDP are.<br><br></pre>
        </blockquote>
        <pre wrap="">Then, is multi-homing support "an integral part of and mandatory in<br>Megaco"?<br><br>It seems to me there are only two options: 1) if people feel that<br>multi-homing should be made "an integral part of and mandatory in<br>Megaco", then the solution could be to simply make SCTP "an integral<br>part of and mandatory in Megaco" and we are done. 2) if people feel that<br>multi-homing should be optional, then whenever/wherever one needs<br>multi-homing, he/she simply uses the "optional" SCTP transport and the<br>problem is solved.<br></pre>
        </blockquote>
        <pre wrap=""><!----><br>Those are indeed two options, and from a theoretical point of view, there is no<br>doubt this is the cleanest solution. Having said that, the original question was<br>whether Megaco has adequate built-in support for redundancy and failover. Some<br>claimed it did, however they have yet to show how it would actually work let<br>alone where it is specified, and you seem to agree that without SCTP, there are<br>indeed holes here.<br><br><br></pre>
        <blockquote type="cite">
          <pre wrap="">I don't see a case where more stuff needs to be built<br>into MEGACO. In other words, either way I see MEGACO spec as complete<br>and adequate.<br><br></pre>
          </blockquote>
          <pre wrap=""><!----><br>So is it consensus that Megaco needs SCTP in order to properly support<br>multihoming/redundancy/failover, and there should be no further specification of<br>how that might be achieved using UDP/TCP instead ?<br><br>On a related note:    When the concept of a control association is clarified,<br>please make sure that the clarification explicitly covers SCTP operation as<br>well.<br><br>-- Flemming<br></pre>
          </blockquote>
 And the number of FQDNs and IP addresses per MGC. Also clarify what happens 
if a DNS query returns more than 1 IP address for an MGC (assuming SCTP is 
not supported, is only the first one considered)?<br>
 This is important for the MEGACO MIB. The one that is currently in the works 
actually does specify a single IP address per MGC. If SCTP is supported, then
there should be more ... But I wouldn't expect the MIB document to clarify 
what the model is, I think it should just reflect the model as per the main 
document.<br>
          <br>
 Adrian<br>
          <br>
          <blockquote type="cite" cite="mid:3EA92F29.93F0F95D@cisco.com">
            <pre wrap=""><br><br><br></pre>
            <blockquote type="cite">
              <pre wrap="">-Qiaobing<br></pre>
              </blockquote>
              <pre wrap=""><!----><br><br></pre>
              </blockquote>
              <br>
              </body>
              </html>

--------------070100010905040200050504--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 12:31:00 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13816
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 12:31:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PGYBf07871
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 12:34:11 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGYB807868
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 12:34:11 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13779
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 12:30:29 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19967z-0001rc-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 12:32:47 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19967z-0001rY-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 12:32:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGVx807741;
	Fri, 25 Apr 2003 12:31:59 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PGQ9807548
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 12:26:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13589
	for <megaco@ietf.org>; Fri, 25 Apr 2003 12:22:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19960D-0001ou-00
	for megaco@ietf.org; Fri, 25 Apr 2003 12:24:45 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19960D-0001op-00
	for megaco@ietf.org; Fri, 25 Apr 2003 12:24:45 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042511244311:685 ;
          Fri, 25 Apr 2003 11:24:43 -0500 
Message-ID: <3EA962D7.1080902@tekelec.com>
Date: Fri, 25 Apr 2003 11:31:19 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 11:24:43 AM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 11:25:15 AM,
	Serialize complete at 04/25/2003 11:25:15 AM
Content-Type: multipart/alternative;
 boundary="------------070100010905040200050504"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------070100010905040200050504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Flemming Andreasen wrote:

>
>Qiaobing Xie wrote:
>
>>Flemming Andreasen wrote:
>>
>>>Qiaobing Xie wrote:
>>>
>>>>I disagree with the notion that MEGACO spec fails to address
>>>>multi-homing. Multi-homing is elegantly addressed by using SCTP
>>>>(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
>>>>is to relieve other upper layer protocols, such as MEGACO, from the
>>>>complicated task of dealing with multi-homing.
>>>>
>>>>I'd call it a bad strategy if now some one would insist on using UDP and
>>>>duplicate the multi-homing handling complexity of SCTP inside MEGACO
>>>>before calling it adequately addressed.
>>>>
>>>If SCTP support was an integral part of and mandatory in Megaco, then I'd
>>>agree with that, however it's not; TCP and UDP are.
>>>
>>Then, is multi-homing support "an integral part of and mandatory in
>>Megaco"?
>>
>>It seems to me there are only two options: 1) if people feel that
>>multi-homing should be made "an integral part of and mandatory in
>>Megaco", then the solution could be to simply make SCTP "an integral
>>part of and mandatory in Megaco" and we are done. 2) if people feel that
>>multi-homing should be optional, then whenever/wherever one needs
>>multi-homing, he/she simply uses the "optional" SCTP transport and the
>>problem is solved.
>>
>
>Those are indeed two options, and from a theoretical point of view, there is no
>doubt this is the cleanest solution. Having said that, the original question was
>whether Megaco has adequate built-in support for redundancy and failover. Some
>claimed it did, however they have yet to show how it would actually work let
>alone where it is specified, and you seem to agree that without SCTP, there are
>indeed holes here.
>
>
>>I don't see a case where more stuff needs to be built
>>into MEGACO. In other words, either way I see MEGACO spec as complete
>>and adequate.
>>
>
>So is it consensus that Megaco needs SCTP in order to properly support
>multihoming/redundancy/failover, and there should be no further specification of
>how that might be achieved using UDP/TCP instead ?
>
>On a related note:    When the concept of a control association is clarified,
>please make sure that the clarification explicitly covers SCTP operation as
>well.
>
>-- Flemming
>
And the number of FQDNs and IP addresses per MGC. Also clarify what 
happens if a DNS query returns more than 1 IP address for an MGC 
(assuming SCTP is not supported, is only the first one considered)?
This is important for the MEGACO MIB. The one that is currently in the 
works actually does specify a single IP address per MGC. If SCTP is 
supported, then there should be more ... But I wouldn't expect the MIB 
document to clarify what the model is, I think it should just reflect 
the model as per the main document.

Adrian

>
>
>
>>-Qiaobing
>>
>
>


--------------070100010905040200050504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
<br>
<br>
Flemming Andreasen wrote:<br>
<blockquote type="cite" cite="mid:3EA92F29.93F0F95D@cisco.com">
  <pre wrap=""><br>Qiaobing Xie wrote:<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">Flemming Andreasen wrote:<br></pre>
    <blockquote type="cite">
      <pre wrap="">Qiaobing Xie wrote:<br><br></pre>
      <blockquote type="cite">
        <pre wrap="">I disagree with the notion that MEGACO spec fails to address<br>multi-homing. Multi-homing is elegantly addressed by using SCTP<br>(specified in H.248 Annex H). One of the reasons for having SCTP in IETF<br>is to relieve other upper layer protocols, such as MEGACO, from the<br>complicated task of dealing with multi-homing.<br><br>I'd call it a bad strategy if now some one would insist on using UDP and<br>duplicate the multi-homing handling complexity of SCTP inside MEGACO<br>before calling it adequately addressed.<br><br></pre>
        </blockquote>
        <pre wrap="">If SCTP support was an integral part of and mandatory in Megaco, then I'd<br>agree with that, however it's not; TCP and UDP are.<br><br></pre>
        </blockquote>
        <pre wrap="">Then, is multi-homing support "an integral part of and mandatory in<br>Megaco"?<br><br>It seems to me there are only two options: 1) if people feel that<br>multi-homing should be made "an integral part of and mandatory in<br>Megaco", then the solution could be to simply make SCTP "an integral<br>part of and mandatory in Megaco" and we are done. 2) if people feel that<br>multi-homing should be optional, then whenever/wherever one needs<br>multi-homing, he/she simply uses the "optional" SCTP transport and the<br>problem is solved.<br></pre>
        </blockquote>
        <pre wrap=""><!----><br>Those are indeed two options, and from a theoretical point of view, there is no<br>doubt this is the cleanest solution. Having said that, the original question was<br>whether Megaco has adequate built-in support for redundancy and failover. Some<br>claimed it did, however they have yet to show how it would actually work let<br>alone where it is specified, and you seem to agree that without SCTP, there are<br>indeed holes here.<br><br><br></pre>
        <blockquote type="cite">
          <pre wrap="">I don't see a case where more stuff needs to be built<br>into MEGACO. In other words, either way I see MEGACO spec as complete<br>and adequate.<br><br></pre>
          </blockquote>
          <pre wrap=""><!----><br>So is it consensus that Megaco needs SCTP in order to properly support<br>multihoming/redundancy/failover, and there should be no further specification of<br>how that might be achieved using UDP/TCP instead ?<br><br>On a related note:    When the concept of a control association is clarified,<br>please make sure that the clarification explicitly covers SCTP operation as<br>well.<br><br>-- Flemming<br></pre>
          </blockquote>
 And the number of FQDNs and IP addresses per MGC. Also clarify what happens 
if a DNS query returns more than 1 IP address for an MGC (assuming SCTP is 
not supported, is only the first one considered)?<br>
 This is important for the MEGACO MIB. The one that is currently in the works 
actually does specify a single IP address per MGC. If SCTP is supported, then
there should be more ... But I wouldn't expect the MIB document to clarify 
what the model is, I think it should just reflect the model as per the main 
document.<br>
          <br>
 Adrian<br>
          <br>
          <blockquote type="cite" cite="mid:3EA92F29.93F0F95D@cisco.com">
            <pre wrap=""><br><br><br></pre>
            <blockquote type="cite">
              <pre wrap="">-Qiaobing<br></pre>
              </blockquote>
              <pre wrap=""><!----><br><br></pre>
              </blockquote>
              <br>
              </body>
              </html>

--------------070100010905040200050504--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 15:45:25 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20090
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 15:45:25 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJlY822756;
	Fri, 25 Apr 2003 15:47:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJg6822576
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 15:42:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19964
	for <megaco@ietf.org>; Fri, 25 Apr 2003 15:38:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19993m-00037y-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:40:38 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19993l-00037v-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:40:37 -0400
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h3PJf62i027900
	for <megaco@ietf.org>; Fri, 25 Apr 2003 12:41:06 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA26009 for <megaco@ietf.org>; Fri, 25 Apr 2003 12:40:09 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN6ALP; Fri, 25 Apr 2003 14:41:06 -0500
Message-ID: <3EA98F66.C6890B54@motorola.com>
Date: Fri, 25 Apr 2003 14:41:26 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Flemming Andreasen wrote:
...
> > It seems to me there are only two options: 1) if people feel that
> > multi-homing should be made "an integral part of and mandatory in
> > Megaco", then the solution could be to simply make SCTP "an integral
> > part of and mandatory in Megaco" and we are done. 2) if people feel that
> > multi-homing should be optional, then whenever/wherever one needs
> > multi-homing, he/she simply uses the "optional" SCTP transport and the
> > problem is solved.
> 
> Those are indeed two options, and from a theoretical point of view, there is no
> doubt this is the cleanest solution. Having said that, the original question was
> whether Megaco has adequate built-in support for redundancy and failover. Some
> claimed it did, however they have yet to show how it would actually work let
> alone where it is specified, and you seem to agree that without SCTP, there are
> indeed holes here.

SCTP is part of the solution. Therefore, if you take SCTP out of the
picture, of cause you will see (big) holes :-)

> 
> > I don't see a case where more stuff needs to be built
> > into MEGACO. In other words, either way I see MEGACO spec as complete
> > and adequate.
> >
> 
> So is it consensus that Megaco needs SCTP in order to properly support
> multihoming/redundancy/failover, 

SCTP only gives you multi-homing support (which you can view as
providing link level redundancy). For app-level redundancy/failover such
as clustering, active/standby, pooling support, SCTP will not help you.
Instead, RSERPOOL WG is currently working on a generic solution for this
type of app-level redundancy/failover support.

> and there should be no further specification of
> how that might be achieved using UDP/TCP instead ?

When SIGTRAN was started (at about the same time MEGACO did), people
asked similar question, and debated extensively over the following
options: a) re-design UDP/TCP to add multi-homing support; b) let each
upper layer protocol to build its own internal multi-homing support; and
c) to create a generic general transport that supports multi-homing. And
the consensus was option c) and the result is SCTP. MEGACO left SCTP
transport in an annex because SCTP was under development at the time
MEGACO was decided. In terms of stack availability, there are commercial
SCTP and MEGACO/SCTP stacks in the market.

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 15:46:36 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20118
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 15:46:36 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PJnom22827
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 15:49:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJno822824
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 15:49:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20110
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 15:45:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999BA-00039L-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 15:48:16 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1999BA-00039I-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 15:48:16 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJlY822756;
	Fri, 25 Apr 2003 15:47:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJg6822576
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 15:42:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19964
	for <megaco@ietf.org>; Fri, 25 Apr 2003 15:38:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19993m-00037y-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:40:38 -0400
Received: from motgate.mot.com ([129.188.136.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 19993l-00037v-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:40:37 -0400
Received: from mothost.mot.com (mothost.mot.com [129.188.137.101])
	by motgate.mot.com (Motorola/Motgate) with ESMTP id h3PJf62i027900
	for <megaco@ietf.org>; Fri, 25 Apr 2003 12:41:06 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA26009 for <megaco@ietf.org>; Fri, 25 Apr 2003 12:40:09 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN6ALP; Fri, 25 Apr 2003 14:41:06 -0500
Message-ID: <3EA98F66.C6890B54@motorola.com>
Date: Fri, 25 Apr 2003 14:41:26 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Flemming Andreasen wrote:
...
> > It seems to me there are only two options: 1) if people feel that
> > multi-homing should be made "an integral part of and mandatory in
> > Megaco", then the solution could be to simply make SCTP "an integral
> > part of and mandatory in Megaco" and we are done. 2) if people feel that
> > multi-homing should be optional, then whenever/wherever one needs
> > multi-homing, he/she simply uses the "optional" SCTP transport and the
> > problem is solved.
> 
> Those are indeed two options, and from a theoretical point of view, there is no
> doubt this is the cleanest solution. Having said that, the original question was
> whether Megaco has adequate built-in support for redundancy and failover. Some
> claimed it did, however they have yet to show how it would actually work let
> alone where it is specified, and you seem to agree that without SCTP, there are
> indeed holes here.

SCTP is part of the solution. Therefore, if you take SCTP out of the
picture, of cause you will see (big) holes :-)

> 
> > I don't see a case where more stuff needs to be built
> > into MEGACO. In other words, either way I see MEGACO spec as complete
> > and adequate.
> >
> 
> So is it consensus that Megaco needs SCTP in order to properly support
> multihoming/redundancy/failover, 

SCTP only gives you multi-homing support (which you can view as
providing link level redundancy). For app-level redundancy/failover such
as clustering, active/standby, pooling support, SCTP will not help you.
Instead, RSERPOOL WG is currently working on a generic solution for this
type of app-level redundancy/failover support.

> and there should be no further specification of
> how that might be achieved using UDP/TCP instead ?

When SIGTRAN was started (at about the same time MEGACO did), people
asked similar question, and debated extensively over the following
options: a) re-design UDP/TCP to add multi-homing support; b) let each
upper layer protocol to build its own internal multi-homing support; and
c) to create a generic general transport that supports multi-homing. And
the consensus was option c) and the result is SCTP. MEGACO left SCTP
transport in an annex because SCTP was under development at the time
MEGACO was decided. In terms of stack availability, there are commercial
SCTP and MEGACO/SCTP stacks in the market.

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 15:59:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20505
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 15:59:16 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PK0h823359;
	Fri, 25 Apr 2003 16:00:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJuC823191
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 15:56:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20332
	for <megaco@ietf.org>; Fri, 25 Apr 2003 15:52:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999HQ-0003Bc-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:54:44 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1999HQ-0003BI-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:54:44 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042514544250:1105 ;
          Fri, 25 Apr 2003 14:54:42 -0500 
Message-ID: <3EA9940F.4020300@tekelec.com>
Date: Fri, 25 Apr 2003 15:01:19 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>, megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 02:54:42 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 02:55:14 PM,
	Serialize complete at 04/25/2003 02:55:14 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

  Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported 
(either mandatory or optional), the MIB would need to allow an MG to 
have 2 or more IP addresses for the same MGC. So there you go, whether 
you like it or not, the MG is aware that the MGC is multi-homed. It has 
to be, since you cannot have one SCTP association to several machines, 
they wouldn't be able to handle the sequence numbers.

Next, consider an MG which supports all the transport protocols. It may 
work with MGCs that support only some of the protocols.
- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC 
with multiple IP addresses.
- If the MGC supports only UDP, then why does the MGC have to be modeled 
differently, i.e. as 2 MGCs, each with only one IP address?
This only forces the MGC to handoff to itself, which has some issues as 
I mentioned before.

I think the clean way to address this is as follows:
- Define the "MEGACO control association", a number of people agreed on 
this.
- In the main document, define the handoff/failover procedures in terms 
of the control association only (this separates them from the transport 
concepts). Clarify what happens to replies and event notifications on 
switchover, what happens when the MG is audited from outside the control 
association etc. (see the issues raised previously).
- For each transport protocol (because there is a section or annex 
anyway), detail how the control association works and is maintained, and 
here is where one or more IP addresses get involved.

In the UDP case, there is no real "complexity" for a uniform approach of 
multi-homing, the MG only needs to accept commands from either IP 
address, and to be safe always reply to the source address. Most of the 
MGs/MGCs can do this today, but the handoff gets in the way e.g. because 
subsequent event handling is not clear.

This layered approach seems to me quite elegant and natural. I don't 
think multihoming over UDP should be excluded just "because". So far, 
there are not many implementations of MEGACO over SCTP.

Adrian




Qiaobing Xie wrote:

>I disagree with the notion that MEGACO spec fails to address
>multi-homing. Multi-homing is elegantly addressed by using SCTP
>(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
>is to relieve other upper layer protocols, such as MEGACO, from the
>complicated task of dealing with multi-homing. 
>
>I'd call it a bad strategy if now some one would insist on using UDP and
>duplicate the multi-homing handling complexity of SCTP inside MEGACO
>before calling it adequately addressed.
>
>-Qiaobing
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 16:00:28 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20581
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 16:00:28 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PK3gw23518
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 16:03:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PK3g823515
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 16:03:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20532
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 15:59:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999Oa-0003EE-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:02:08 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1999Oa-0003EB-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:02:08 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PK0h823359;
	Fri, 25 Apr 2003 16:00:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJuC823191
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 15:56:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20332
	for <megaco@ietf.org>; Fri, 25 Apr 2003 15:52:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999HQ-0003Bc-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:54:44 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1999HQ-0003BI-00
	for megaco@ietf.org; Fri, 25 Apr 2003 15:54:44 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042514544250:1105 ;
          Fri, 25 Apr 2003 14:54:42 -0500 
Message-ID: <3EA9940F.4020300@tekelec.com>
Date: Fri, 25 Apr 2003 15:01:19 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>, megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 02:54:42 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 02:55:14 PM,
	Serialize complete at 04/25/2003 02:55:14 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

  Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported 
(either mandatory or optional), the MIB would need to allow an MG to 
have 2 or more IP addresses for the same MGC. So there you go, whether 
you like it or not, the MG is aware that the MGC is multi-homed. It has 
to be, since you cannot have one SCTP association to several machines, 
they wouldn't be able to handle the sequence numbers.

Next, consider an MG which supports all the transport protocols. It may 
work with MGCs that support only some of the protocols.
- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC 
with multiple IP addresses.
- If the MGC supports only UDP, then why does the MGC have to be modeled 
differently, i.e. as 2 MGCs, each with only one IP address?
This only forces the MGC to handoff to itself, which has some issues as 
I mentioned before.

I think the clean way to address this is as follows:
- Define the "MEGACO control association", a number of people agreed on 
this.
- In the main document, define the handoff/failover procedures in terms 
of the control association only (this separates them from the transport 
concepts). Clarify what happens to replies and event notifications on 
switchover, what happens when the MG is audited from outside the control 
association etc. (see the issues raised previously).
- For each transport protocol (because there is a section or annex 
anyway), detail how the control association works and is maintained, and 
here is where one or more IP addresses get involved.

In the UDP case, there is no real "complexity" for a uniform approach of 
multi-homing, the MG only needs to accept commands from either IP 
address, and to be safe always reply to the source address. Most of the 
MGs/MGCs can do this today, but the handoff gets in the way e.g. because 
subsequent event handling is not clear.

This layered approach seems to me quite elegant and natural. I don't 
think multihoming over UDP should be excluded just "because". So far, 
there are not many implementations of MEGACO over SCTP.

Adrian




Qiaobing Xie wrote:

>I disagree with the notion that MEGACO spec fails to address
>multi-homing. Multi-homing is elegantly addressed by using SCTP
>(specified in H.248 Annex H). One of the reasons for having SCTP in IETF
>is to relieve other upper layer protocols, such as MEGACO, from the
>complicated task of dealing with multi-homing. 
>
>I'd call it a bad strategy if now some one would insist on using UDP and
>duplicate the multi-homing handling complexity of SCTP inside MEGACO
>before calling it adequately addressed.
>
>-Qiaobing
>


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 16:19:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21203
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 16:19:30 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKFi824895;
	Fri, 25 Apr 2003 16:15:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKBR824751
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 16:11:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20872
	for <megaco@ietf.org>; Fri, 25 Apr 2003 16:07:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999WB-0003HT-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:09:59 -0400
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999WB-0003HQ-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:09:59 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h3PKASPP024381
	for <megaco@ietf.org>; Fri, 25 Apr 2003 13:10:28 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA04276 for <megaco@ietf.org>; Fri, 25 Apr 2003 13:10:28 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN6BT7; Fri, 25 Apr 2003 15:10:27 -0500
Message-ID: <3EA99663.6B23FD16@motorola.com>
Date: Fri, 25 Apr 2003 15:11:15 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA98EFF.8040103@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Adrian Soncodi wrote:
> 
> Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported
> (either mandatory or optional), the MIB would need to allow an MG to
> have 2 or more IP addresses for the same MGC. So there you go, whether
> you like it or not, the MG is aware that the MGC is multi-homed. It
> has to be, since you cannot have one SCTP association to several
> machines, they wouldn't be able to handle the sequence numbers.
> 
> Next, consider an MG which supports all the transport protocols. It
> may work with MGCs that support only some of the protocols.
> - If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC
> with multiple IP addresses.
> - If the MGC supports only UDP, then why does the MGC have to be
> modeled differently, i.e. as 2 MGCs, each with only one IP address?
> This only forces the MGC to handoff to itself, which has some issues
> as I mentioned before.

Here is an example that shows why you would prefer to have all this
multi-homing thing be transparent to (i.e., hidden away from) MEGACO.
This is the whole idea of having SCTP that relieves the upper layer from
worrying about how to deal with individual IP address(es). MIB should
definitely be built to be able to deal with the MEGACO over SCTP case.

....
> This layered approach seems to me quite elegant and natural. I don't
> think multihoming over UDP should be excluded just "because". So far,
> there are not many implementations of MEGACO over SCTP.

I hope this will change as people start to be more interested in
redundancy and their system availability. 

For some one who's thinking of deploying MEGACO and also worrying about
multi-homing for the sake of system availability, you seem to imply that
there are two choices here: a) to pick a MEGACO implementation that
supports SCTP, or b) to modify/re-work MEGACO spec to add an internal
UDP-based multi-homing and then wait for some one to implement the new
mechanism. I don't see how choice b) is in any way more available or
easier than a).

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 16:20:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21258
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 16:20:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PKNsh25273
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 16:23:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKNs825270
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 16:23:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21225
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 16:20:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999iB-0003Kp-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:22:23 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1999iA-0003Km-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:22:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKFi824895;
	Fri, 25 Apr 2003 16:15:44 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKBR824751
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 16:11:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20872
	for <megaco@ietf.org>; Fri, 25 Apr 2003 16:07:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999WB-0003HT-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:09:59 -0400
Received: from ftpbox.mot.com ([129.188.136.101])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999WB-0003HQ-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:09:59 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100])
	by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h3PKASPP024381
	for <megaco@ietf.org>; Fri, 25 Apr 2003 13:10:28 -0700 (MST)
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA04276 for <megaco@ietf.org>; Fri, 25 Apr 2003 13:10:28 -0700 (MST)]
Received: from motorola.com (d50-39f8.cig.mot.com [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN6BT7; Fri, 25 Apr 2003 15:10:27 -0500
Message-ID: <3EA99663.6B23FD16@motorola.com>
Date: Fri, 25 Apr 2003 15:11:15 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adrian Soncodi <adrian.soncodi@tekelec.com>
CC: megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA98EFF.8040103@tekelec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Adrian Soncodi wrote:
> 
> Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported
> (either mandatory or optional), the MIB would need to allow an MG to
> have 2 or more IP addresses for the same MGC. So there you go, whether
> you like it or not, the MG is aware that the MGC is multi-homed. It
> has to be, since you cannot have one SCTP association to several
> machines, they wouldn't be able to handle the sequence numbers.
> 
> Next, consider an MG which supports all the transport protocols. It
> may work with MGCs that support only some of the protocols.
> - If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC
> with multiple IP addresses.
> - If the MGC supports only UDP, then why does the MGC have to be
> modeled differently, i.e. as 2 MGCs, each with only one IP address?
> This only forces the MGC to handoff to itself, which has some issues
> as I mentioned before.

Here is an example that shows why you would prefer to have all this
multi-homing thing be transparent to (i.e., hidden away from) MEGACO.
This is the whole idea of having SCTP that relieves the upper layer from
worrying about how to deal with individual IP address(es). MIB should
definitely be built to be able to deal with the MEGACO over SCTP case.

....
> This layered approach seems to me quite elegant and natural. I don't
> think multihoming over UDP should be excluded just "because". So far,
> there are not many implementations of MEGACO over SCTP.

I hope this will change as people start to be more interested in
redundancy and their system availability. 

For some one who's thinking of deploying MEGACO and also worrying about
multi-homing for the sake of system availability, you seem to imply that
there are two choices here: a) to pick a MEGACO implementation that
supports SCTP, or b) to modify/re-work MEGACO spec to add an internal
UDP-based multi-homing and then wait for some one to implement the new
mechanism. I don't see how choice b) is in any way more available or
easier than a).

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 16:31:12 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21884
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 16:31:12 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKXu825843;
	Fri, 25 Apr 2003 16:33:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKT7825578
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 16:29:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21477
	for <megaco@ietf.org>; Fri, 25 Apr 2003 16:25:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999nH-0003My-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:27:39 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999nG-0003Mk-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:27:39 -0400
Received: from cisco.com (sjc-vpn4-450.cisco.com [10.21.81.194])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PKRQ08010579;
	Fri, 25 Apr 2003 13:27:27 -0700 (PDT)
Message-ID: <3EA99A2E.4DC6BD7D@cisco.com>
Date: Fri, 25 Apr 2003 16:27:26 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

> Flemming Andreasen wrote:
> ...
> > > It seems to me there are only two options: 1) if people feel that
> > > multi-homing should be made "an integral part of and mandatory in
> > > Megaco", then the solution could be to simply make SCTP "an integral
> > > part of and mandatory in Megaco" and we are done. 2) if people feel that
> > > multi-homing should be optional, then whenever/wherever one needs
> > > multi-homing, he/she simply uses the "optional" SCTP transport and the
> > > problem is solved.
> >
> > Those are indeed two options, and from a theoretical point of view, there is no
> > doubt this is the cleanest solution. Having said that, the original question was
> > whether Megaco has adequate built-in support for redundancy and failover. Some
> > claimed it did, however they have yet to show how it would actually work let
> > alone where it is specified, and you seem to agree that without SCTP, there are
> > indeed holes here.
>
> SCTP is part of the solution. Therefore, if you take SCTP out of the
> picture, of cause you will see (big) holes :-)

For sure SCTP can solve these problems, but having been involved in the early days of
Megaco, allow me to straighten out the facts a bit here: SCTP was never part of
Megaco, neither in design, nor specification. It always has been and to date remains
an optional add-on that came to the table later on. The lack of references to SCTP in
the Megaco spec makes that pretty evident too.


> >
> > > I don't see a case where more stuff needs to be built
> > > into MEGACO. In other words, either way I see MEGACO spec as complete
> > > and adequate.
> > >
> >
> > So is it consensus that Megaco needs SCTP in order to properly support
> > multihoming/redundancy/failover,
>
> SCTP only gives you multi-homing support (which you can view as
> providing link level redundancy). For app-level redundancy/failover such
> as clustering, active/standby, pooling support, SCTP will not help you.
> Instead, RSERPOOL WG is currently working on a generic solution for this
> type of app-level redundancy/failover support.
>

This is well-understood, however just like you can have multihoming support without
SCTP, you can have redundancy/failover support without RSERPOOL. Megaco actually
includes some support for this in the form of a statically provisioned list of backup
MGCs.


> > and there should be no further specification of
> > how that might be achieved using UDP/TCP instead ?
>
> When SIGTRAN was started (at about the same time MEGACO did), people
> asked similar question, and debated extensively over the following
> options: a) re-design UDP/TCP to add multi-homing support; b) let each
> upper layer protocol to build its own internal multi-homing support; and
> c) to create a generic general transport that supports multi-homing. And
> the consensus was option c) and the result is SCTP.

Sure, but please don't confuse the generic discussions about this problem that took
place in SIGTRAN with the specific discussions that took place in Megaco.


> MEGACO left SCTP
> transport in an annex because SCTP was under development at the time
> MEGACO was decided.

I'm not sure it's worth debating this issue, but suffice it to say that this is not
quite how things transpired. In any case, SCTP is there as an option today for those
that wish to use it. For those that don't, we've already concluded that
multihoming/redundancy/failover is not very well supported, and that there doesn't
seem to be much desire to change that. I personally think that's a bit of a shame, but
so be it.

-- Flemming


> In terms of stack availability, there are commercial
> SCTP and MEGACO/SCTP stacks in the market.
>
> -Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 16:32:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21966
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 16:32:19 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PKZYm26044
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 16:35:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKZY826041
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 16:35:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21950
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 16:31:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999tT-0003UM-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:34:03 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1999tS-0003UJ-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:34:02 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKXu825843;
	Fri, 25 Apr 2003 16:33:56 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKT7825578
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 16:29:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21477
	for <megaco@ietf.org>; Fri, 25 Apr 2003 16:25:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999nH-0003My-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:27:39 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237])
	by ietf-mx with esmtp (Exim 4.12)
	id 1999nG-0003Mk-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:27:39 -0400
Received: from cisco.com (sjc-vpn4-450.cisco.com [10.21.81.194])
	by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PKRQ08010579;
	Fri, 25 Apr 2003 13:27:27 -0700 (PDT)
Message-ID: <3EA99A2E.4DC6BD7D@cisco.com>
Date: Fri, 25 Apr 2003 16:27:26 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

> Flemming Andreasen wrote:
> ...
> > > It seems to me there are only two options: 1) if people feel that
> > > multi-homing should be made "an integral part of and mandatory in
> > > Megaco", then the solution could be to simply make SCTP "an integral
> > > part of and mandatory in Megaco" and we are done. 2) if people feel that
> > > multi-homing should be optional, then whenever/wherever one needs
> > > multi-homing, he/she simply uses the "optional" SCTP transport and the
> > > problem is solved.
> >
> > Those are indeed two options, and from a theoretical point of view, there is no
> > doubt this is the cleanest solution. Having said that, the original question was
> > whether Megaco has adequate built-in support for redundancy and failover. Some
> > claimed it did, however they have yet to show how it would actually work let
> > alone where it is specified, and you seem to agree that without SCTP, there are
> > indeed holes here.
>
> SCTP is part of the solution. Therefore, if you take SCTP out of the
> picture, of cause you will see (big) holes :-)

For sure SCTP can solve these problems, but having been involved in the early days of
Megaco, allow me to straighten out the facts a bit here: SCTP was never part of
Megaco, neither in design, nor specification. It always has been and to date remains
an optional add-on that came to the table later on. The lack of references to SCTP in
the Megaco spec makes that pretty evident too.


> >
> > > I don't see a case where more stuff needs to be built
> > > into MEGACO. In other words, either way I see MEGACO spec as complete
> > > and adequate.
> > >
> >
> > So is it consensus that Megaco needs SCTP in order to properly support
> > multihoming/redundancy/failover,
>
> SCTP only gives you multi-homing support (which you can view as
> providing link level redundancy). For app-level redundancy/failover such
> as clustering, active/standby, pooling support, SCTP will not help you.
> Instead, RSERPOOL WG is currently working on a generic solution for this
> type of app-level redundancy/failover support.
>

This is well-understood, however just like you can have multihoming support without
SCTP, you can have redundancy/failover support without RSERPOOL. Megaco actually
includes some support for this in the form of a statically provisioned list of backup
MGCs.


> > and there should be no further specification of
> > how that might be achieved using UDP/TCP instead ?
>
> When SIGTRAN was started (at about the same time MEGACO did), people
> asked similar question, and debated extensively over the following
> options: a) re-design UDP/TCP to add multi-homing support; b) let each
> upper layer protocol to build its own internal multi-homing support; and
> c) to create a generic general transport that supports multi-homing. And
> the consensus was option c) and the result is SCTP.

Sure, but please don't confuse the generic discussions about this problem that took
place in SIGTRAN with the specific discussions that took place in Megaco.


> MEGACO left SCTP
> transport in an annex because SCTP was under development at the time
> MEGACO was decided.

I'm not sure it's worth debating this issue, but suffice it to say that this is not
quite how things transpired. In any case, SCTP is there as an option today for those
that wish to use it. For those that don't, we've already concluded that
multihoming/redundancy/failover is not very well supported, and that there doesn't
seem to be much desire to change that. I personally think that's a bit of a shame, but
so be it.

-- Flemming


> In terms of stack availability, there are commercial
> SCTP and MEGACO/SCTP stacks in the market.
>
> -Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 16:46:32 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22989
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 16:46:32 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKnD827522;
	Fri, 25 Apr 2003 16:49:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKi8827314
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 16:44:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22472
	for <megaco@ietf.org>; Fri, 25 Apr 2003 16:40:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199A1n-0003Xo-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:42:39 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 199A1m-0003Xe-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:42:38 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042515423538:1251 ;
          Fri, 25 Apr 2003 15:42:35 -0500 
Message-ID: <3EA99F43.10006@tekelec.com>
Date: Fri, 25 Apr 2003 15:49:07 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>, megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA98EFF.8040103@tekelec.com> <3EA99663.6B23FD16@motorola.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 03:42:35 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 03:43:08 PM,
	Serialize complete at 04/25/2003 03:43:08 PM
Content-Type: multipart/alternative;
 boundary="------------050009090607030305060805"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------050009090607030305060805
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

>Adrian Soncodi wrote:
>
>>Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported
>>(either mandatory or optional), the MIB would need to allow an MG to
>>have 2 or more IP addresses for the same MGC. So there you go, whether
>>you like it or not, the MG is aware that the MGC is multi-homed. It
>>has to be, since you cannot have one SCTP association to several
>>machines, they wouldn't be able to handle the sequence numbers.
>>
>>Next, consider an MG which supports all the transport protocols. It
>>may work with MGCs that support only some of the protocols.
>>- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC
>>with multiple IP addresses.
>>- If the MGC supports only UDP, then why does the MGC have to be
>>modeled differently, i.e. as 2 MGCs, each with only one IP address?
>>This only forces the MGC to handoff to itself, which has some issues
>>as I mentioned before.
>>
>
>Here is an example that shows why you would prefer to have all this
>multi-homing thing be transparent to (i.e., hidden away from) MEGACO.
>This is the whole idea of having SCTP that relieves the upper layer from
>worrying about how to deal with individual IP address(es). MIB should
>definitely be built to be able to deal with the MEGACO over SCTP case.
>
>....
>
>>This layered approach seems to me quite elegant and natural. I don't
>>think multihoming over UDP should be excluded just "because". So far,
>>there are not many implementations of MEGACO over SCTP.
>>
>
>I hope this will change as people start to be more interested in
>redundancy and their system availability. 
>
>For some one who's thinking of deploying MEGACO and also worrying about
>multi-homing for the sake of system availability, you seem to imply that
>there are two choices here: a) to pick a MEGACO implementation that
>supports SCTP, or b) to modify/re-work MEGACO spec to add an internal
>UDP-based multi-homing and then wait for some one to implement the new
>mechanism. I don't see how choice b) is in any way more available or
>easier than a).
>
Because a) implies adapting a whole new stack in the system, while b) is 
just a few lines of code change, and many MGs have already done this. 
Furthermore, due to the fact that the spec is incomplete in this area, 
b) is not even a violation of the standard, it's probably just a very 
small extension/clarification. So a couple of sentences in the main spec 
could make this officially a valid solution, along with a), which we 
should obviously keep.

You seem to say "if you want multi-homing, it must be only over SCTP". 
Why? Someone could similarly say "if you want MEGACO, it must be over 
UDP". But we don't, we allow all 3 protocols, for flexibility.

Adrian

>
>-Qiaobing
>


--------------050009090607030305060805
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
<br>
<br>
Qiaobing Xie wrote:<br>
<blockquote type="cite" cite="mid:3EA99663.6B23FD16@motorola.com">
  <pre wrap="">Adrian Soncodi wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported<br>(either mandatory or optional), the MIB would need to allow an MG to<br>have 2 or more IP addresses for the same MGC. So there you go, whether<br>you like it or not, the MG is aware that the MGC is multi-homed. It<br>has to be, since you cannot have one SCTP association to several<br>machines, they wouldn't be able to handle the sequence numbers.<br><br>Next, consider an MG which supports all the transport protocols. It<br>may work with MGCs that support only some of the protocols.<br>- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC<br>with multiple IP addresses.<br>- If the MGC supports only UDP, then why does the MGC have to be<br>modeled differently, i.e. as 2 MGCs, each with only one IP address?<br>This only forces the MGC to handoff to itself, which has some issues<br>as I mentioned before.<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Here is an example that shows why you would prefer to have all this<br>multi-homing thing be transparent to (i.e., hidden away from) MEGACO.<br>This is the whole idea of having SCTP that relieves the upper layer from<br>worrying about how to deal with individual IP address(es). MIB should<br>definitely be built to be able to deal with the MEGACO over SCTP case.<br><br>....<br></pre>
    <blockquote type="cite">
      <pre wrap="">This layered approach seems to me quite elegant and natural. I don't<br>think multihoming over UDP should be excluded just "because". So far,<br>there are not many implementations of MEGACO over SCTP.<br></pre>
      </blockquote>
      <pre wrap=""><!----><br>I hope this will change as people start to be more interested in<br>redundancy and their system availability. <br><br>For some one who's thinking of deploying MEGACO and also worrying about<br>multi-homing for the sake of system availability, you seem to imply that<br>there are two choices here: a) to pick a MEGACO implementation that<br>supports SCTP, or b) to modify/re-work MEGACO spec to add an internal<br>UDP-based multi-homing and then wait for some one to implement the new<br>mechanism. I don't see how choice b) is in any way more available or<br>easier than a).<br></pre>
      </blockquote>
Because a) implies adapting a whole new stack in the system, while b) is
just a few lines of code change, and many MGs have already done this. Furthermore,
due to the fact that the spec is incomplete in this area, b) is not even
a violation of the standard, it's probably just a very small extension/clarification.
So a couple of sentences in the main spec could make this officially a valid
solution, along with a), which we should obviously keep. <br>
      <br>
You seem to say "if you want multi-homing, it must be only over SCTP". Why?
Someone could similarly say "if you want MEGACO, it must be over UDP". But
we don't, we allow all 3 protocols, for flexibility.<br>
      <br>
Adrian<br>
      <br>
      <blockquote type="cite" cite="mid:3EA99663.6B23FD16@motorola.com">
        <pre wrap=""><br>-Qiaobing<br><br></pre>
        </blockquote>
        <br>
        </body>
        </html>

--------------050009090607030305060805--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 16:47:43 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23069
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 16:47:42 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3PKowQ27616
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 16:50:58 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKow827613
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 16:50:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23047
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 16:47:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199A8O-0003ZK-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:49:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 199A8O-0003ZH-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 16:49:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKnD827522;
	Fri, 25 Apr 2003 16:49:13 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKi8827314
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 16:44:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22472
	for <megaco@ietf.org>; Fri, 25 Apr 2003 16:40:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199A1n-0003Xo-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:42:39 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 199A1m-0003Xe-00
	for megaco@ietf.org; Fri, 25 Apr 2003 16:42:38 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042515423538:1251 ;
          Fri, 25 Apr 2003 15:42:35 -0500 
Message-ID: <3EA99F43.10006@tekelec.com>
Date: Fri, 25 Apr 2003 15:49:07 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>, megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA98EFF.8040103@tekelec.com> <3EA99663.6B23FD16@motorola.com>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 03:42:35 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/25/2003 03:43:08 PM,
	Serialize complete at 04/25/2003 03:43:08 PM
Content-Type: multipart/alternative;
 boundary="------------050009090607030305060805"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------050009090607030305060805
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Qiaobing Xie wrote:

>Adrian Soncodi wrote:
>
>>Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported
>>(either mandatory or optional), the MIB would need to allow an MG to
>>have 2 or more IP addresses for the same MGC. So there you go, whether
>>you like it or not, the MG is aware that the MGC is multi-homed. It
>>has to be, since you cannot have one SCTP association to several
>>machines, they wouldn't be able to handle the sequence numbers.
>>
>>Next, consider an MG which supports all the transport protocols. It
>>may work with MGCs that support only some of the protocols.
>>- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC
>>with multiple IP addresses.
>>- If the MGC supports only UDP, then why does the MGC have to be
>>modeled differently, i.e. as 2 MGCs, each with only one IP address?
>>This only forces the MGC to handoff to itself, which has some issues
>>as I mentioned before.
>>
>
>Here is an example that shows why you would prefer to have all this
>multi-homing thing be transparent to (i.e., hidden away from) MEGACO.
>This is the whole idea of having SCTP that relieves the upper layer from
>worrying about how to deal with individual IP address(es). MIB should
>definitely be built to be able to deal with the MEGACO over SCTP case.
>
>....
>
>>This layered approach seems to me quite elegant and natural. I don't
>>think multihoming over UDP should be excluded just "because". So far,
>>there are not many implementations of MEGACO over SCTP.
>>
>
>I hope this will change as people start to be more interested in
>redundancy and their system availability. 
>
>For some one who's thinking of deploying MEGACO and also worrying about
>multi-homing for the sake of system availability, you seem to imply that
>there are two choices here: a) to pick a MEGACO implementation that
>supports SCTP, or b) to modify/re-work MEGACO spec to add an internal
>UDP-based multi-homing and then wait for some one to implement the new
>mechanism. I don't see how choice b) is in any way more available or
>easier than a).
>
Because a) implies adapting a whole new stack in the system, while b) is 
just a few lines of code change, and many MGs have already done this. 
Furthermore, due to the fact that the spec is incomplete in this area, 
b) is not even a violation of the standard, it's probably just a very 
small extension/clarification. So a couple of sentences in the main spec 
could make this officially a valid solution, along with a), which we 
should obviously keep.

You seem to say "if you want multi-homing, it must be only over SCTP". 
Why? Someone could similarly say "if you want MEGACO, it must be over 
UDP". But we don't, we allow all 3 protocols, for flexibility.

Adrian

>
>-Qiaobing
>


--------------050009090607030305060805
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
<br>
<br>
Qiaobing Xie wrote:<br>
<blockquote type="cite" cite="mid:3EA99663.6B23FD16@motorola.com">
  <pre wrap="">Adrian Soncodi wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">Consider the provisioning, i.e. the MEGACO MIB. If SCTP is supported<br>(either mandatory or optional), the MIB would need to allow an MG to<br>have 2 or more IP addresses for the same MGC. So there you go, whether<br>you like it or not, the MG is aware that the MGC is multi-homed. It<br>has to be, since you cannot have one SCTP association to several<br>machines, they wouldn't be able to handle the sequence numbers.<br><br>Next, consider an MG which supports all the transport protocols. It<br>may work with MGCs that support only some of the protocols.<br>- If a multi-homed MGC supports SCTP, then it can be modeled as 1 MGC<br>with multiple IP addresses.<br>- If the MGC supports only UDP, then why does the MGC have to be<br>modeled differently, i.e. as 2 MGCs, each with only one IP address?<br>This only forces the MGC to handoff to itself, which has some issues<br>as I mentioned before.<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Here is an example that shows why you would prefer to have all this<br>multi-homing thing be transparent to (i.e., hidden away from) MEGACO.<br>This is the whole idea of having SCTP that relieves the upper layer from<br>worrying about how to deal with individual IP address(es). MIB should<br>definitely be built to be able to deal with the MEGACO over SCTP case.<br><br>....<br></pre>
    <blockquote type="cite">
      <pre wrap="">This layered approach seems to me quite elegant and natural. I don't<br>think multihoming over UDP should be excluded just "because". So far,<br>there are not many implementations of MEGACO over SCTP.<br></pre>
      </blockquote>
      <pre wrap=""><!----><br>I hope this will change as people start to be more interested in<br>redundancy and their system availability. <br><br>For some one who's thinking of deploying MEGACO and also worrying about<br>multi-homing for the sake of system availability, you seem to imply that<br>there are two choices here: a) to pick a MEGACO implementation that<br>supports SCTP, or b) to modify/re-work MEGACO spec to add an internal<br>UDP-based multi-homing and then wait for some one to implement the new<br>mechanism. I don't see how choice b) is in any way more available or<br>easier than a).<br></pre>
      </blockquote>
Because a) implies adapting a whole new stack in the system, while b) is
just a few lines of code change, and many MGs have already done this. Furthermore,
due to the fact that the spec is incomplete in this area, b) is not even
a violation of the standard, it's probably just a very small extension/clarification.
So a couple of sentences in the main spec could make this officially a valid
solution, along with a), which we should obviously keep. <br>
      <br>
You seem to say "if you want multi-homing, it must be only over SCTP". Why?
Someone could similarly say "if you want MEGACO, it must be over UDP". But
we don't, we allow all 3 protocols, for flexibility.<br>
      <br>
Adrian<br>
      <br>
      <blockquote type="cite" cite="mid:3EA99663.6B23FD16@motorola.com">
        <pre wrap=""><br>-Qiaobing<br><br></pre>
        </blockquote>
        <br>
        </body>
        </html>

--------------050009090607030305060805--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 21:14:30 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28709
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 21:14:30 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q1HG812344;
	Fri, 25 Apr 2003 21:17:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q1B0812205
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 21:11:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28597
	for <megaco@ietf.org>; Fri, 25 Apr 2003 21:07:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199EBy-0004en-00
	for megaco@ietf.org; Fri, 25 Apr 2003 21:09:26 -0400
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 199EBx-0004ek-00
	for megaco@ietf.org; Fri, 25 Apr 2003 21:09:26 -0400
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3Q19tJD013181
	for <megaco@ietf.org>; Fri, 25 Apr 2003 18:09:55 -0700 (MST)
Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3Q19rs3022267
	for <megaco@ietf.org>; Fri, 25 Apr 2003 20:09:53 -0500
Received: from motorola.com (QUANTIX21 [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN629Q; Fri, 25 Apr 2003 20:09:52 -0500
Message-ID: <3EA9DC82.136119A3@motorola.com>
Date: Fri, 25 Apr 2003 20:10:26 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

(Try to respond to similar remarks from two mails)

Flemming Andreasen wrote:
...
> In any case, SCTP is there as an option today for those
> that wish to use it. For those that don't, we've already concluded that
> multihoming/redundancy/failover is not very well supported, and that there doesn't
> seem to be much desire to change that. I personally think that's a bit of a shame, but
> so be it.
...

Adrian Soncodi wrote:
...
> You seem to say "if you want multi-homing, it must be only over SCTP".
> Why? Someone could similarly say "if you want MEGACO, it must be over
> UDP". But we don't, we allow all 3 protocols, for flexibility.
>

I didn't mean to say "you must". I was under the impression that some of
us were saying that we had a technical issue to support multi-homing in
MEGACO, and my response was essentially "this is not an issue, there are
protocol specs existing in IETF to do just that, which is
MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
is not really about the lack of a solution, it's more about that some of
us just don't want to use the existing IETF solution (for whatever
non-tech reasons, or simply just don't wish to use it) and prefer to
define another solution in IETF. Well, if that is the case, I don't have
much else to say... 

Of cause, if there are tech issues/shortcomings/drawbacks/advantages
related to using SCTP for MEGACO multi-homing support, I'd be more than
glad to help answer.

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 21:15:37 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28763
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 21:15:37 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3Q1Ivh12400
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 21:18:57 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q1Iv812397
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 21:18:57 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28740
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 21:15:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199EJc-0004gq-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 21:17:20 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 199EJc-0004gn-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 21:17:20 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q1HG812344;
	Fri, 25 Apr 2003 21:17:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q1B0812205
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 21:11:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28597
	for <megaco@ietf.org>; Fri, 25 Apr 2003 21:07:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199EBy-0004en-00
	for megaco@ietf.org; Fri, 25 Apr 2003 21:09:26 -0400
Received: from motgate5.mot.com ([144.189.100.105])
	by ietf-mx with esmtp (Exim 4.12)
	id 199EBx-0004ek-00
	for megaco@ietf.org; Fri, 25 Apr 2003 21:09:26 -0400
Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242])
	by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3Q19tJD013181
	for <megaco@ietf.org>; Fri, 25 Apr 2003 18:09:55 -0700 (MST)
Received: from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100])
	by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3Q19rs3022267
	for <megaco@ietf.org>; Fri, 25 Apr 2003 20:09:53 -0500
Received: from motorola.com (QUANTIX21 [160.47.57.248]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59)
	id 2DAN629Q; Fri, 25 Apr 2003 20:09:52 -0500
Message-ID: <3EA9DC82.136119A3@motorola.com>
Date: Fri, 25 Apr 2003 20:10:26 -0500
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
X-Mailer: Mozilla 4.8 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

(Try to respond to similar remarks from two mails)

Flemming Andreasen wrote:
...
> In any case, SCTP is there as an option today for those
> that wish to use it. For those that don't, we've already concluded that
> multihoming/redundancy/failover is not very well supported, and that there doesn't
> seem to be much desire to change that. I personally think that's a bit of a shame, but
> so be it.
...

Adrian Soncodi wrote:
...
> You seem to say "if you want multi-homing, it must be only over SCTP".
> Why? Someone could similarly say "if you want MEGACO, it must be over
> UDP". But we don't, we allow all 3 protocols, for flexibility.
>

I didn't mean to say "you must". I was under the impression that some of
us were saying that we had a technical issue to support multi-homing in
MEGACO, and my response was essentially "this is not an issue, there are
protocol specs existing in IETF to do just that, which is
MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
is not really about the lack of a solution, it's more about that some of
us just don't want to use the existing IETF solution (for whatever
non-tech reasons, or simply just don't wish to use it) and prefer to
define another solution in IETF. Well, if that is the case, I don't have
much else to say... 

Of cause, if there are tech issues/shortcomings/drawbacks/advantages
related to using SCTP for MEGACO multi-homing support, I'd be more than
glad to help answer.

-Qiaobing
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Fri Apr 25 22:50:19 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00615
	for <megaco-archive@lists.ietf.org>; Fri, 25 Apr 2003 22:50:19 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2rC818153;
	Fri, 25 Apr 2003 22:53:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2ks817939
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 22:46:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00374
	for <megaco@ietf.org>; Fri, 25 Apr 2003 22:43:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199Fgj-00057b-00
	for megaco@ietf.org; Fri, 25 Apr 2003 22:45:17 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 199Fgj-00057Y-00
	for megaco@ietf.org; Fri, 25 Apr 2003 22:45:17 -0400
Received: from cisco.com (sjc-vpn4-450.cisco.com [10.21.81.194])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3Q2jAID005862;
	Fri, 25 Apr 2003 19:45:10 -0700 (PDT)
Message-ID: <3EA9F2B5.FEBAA43@cisco.com>
Date: Fri, 25 Apr 2003 22:45:09 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Qiaobing

Nobody is denying that SCTP is an existing spec that solves the multihoming problem and it
is quite understandable that you in particular advocate it. However, you seem to have lost
sight of the original question in this thread, which was about native Megaco protocol
support for redundancy and failover, and as part of that, support for multihoming. Initial
claims was that Megaco fully supports this, but we seem to have converged on the opinion
that it does not, unless you use SCTP, which is not part of the base Megaco protocol.
Furthermore, despite everything, the fact of the matter is that for various reasons, not
everybody will be implementing SCTP at least for now (NATs, firewalls and security do not
help SCTP here) and since UDP and TCP are the basic requirements, it would have been nice to
have better mechanisms for these; it can be done very easily (see MGCP for example).
Sometimes, it's good to be a bit pragmatic.

-- Flemming



Qiaobing Xie wrote:

> (Try to respond to similar remarks from two mails)
>
> Flemming Andreasen wrote:
> ...
> > In any case, SCTP is there as an option today for those
> > that wish to use it. For those that don't, we've already concluded that
> > multihoming/redundancy/failover is not very well supported, and that there doesn't
> > seem to be much desire to change that. I personally think that's a bit of a shame, but
> > so be it.
> ...
>
> Adrian Soncodi wrote:
> ...
> > You seem to say "if you want multi-homing, it must be only over SCTP".
> > Why? Someone could similarly say "if you want MEGACO, it must be over
> > UDP". But we don't, we allow all 3 protocols, for flexibility.
> >
>
> I didn't mean to say "you must". I was under the impression that some of
> us were saying that we had a technical issue to support multi-homing in
> MEGACO, and my response was essentially "this is not an issue, there are
> protocol specs existing in IETF to do just that, which is
> MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
> is not really about the lack of a solution, it's more about that some of
> us just don't want to use the existing IETF solution (for whatever
> non-tech reasons, or simply just don't wish to use it) and prefer to
> define another solution in IETF. Well, if that is the case, I don't have
> much else to say...
>
> Of cause, if there are tech issues/shortcomings/drawbacks/advantages
> related to using SCTP for MEGACO multi-homing support, I'd be more than
> glad to help answer.
>
> -Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Fri Apr 25 22:51:47 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00650
	for <megaco-archive@odin.ietf.org>; Fri, 25 Apr 2003 22:51:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3Q2t9J18301
	for megaco-archive@odin.ietf.org; Fri, 25 Apr 2003 22:55:09 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2t9818298
	for <megaco-web-archive@optimus.ietf.org>; Fri, 25 Apr 2003 22:55:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00636
	for <megaco-web-archive@ietf.org>; Fri, 25 Apr 2003 22:50:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199FoL-0005BU-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 22:53:09 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 199FoL-0005BR-00
	for megaco-web-archive@ietf.org; Fri, 25 Apr 2003 22:53:09 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2rC818153;
	Fri, 25 Apr 2003 22:53:12 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2ks817939
	for <megaco@optimus.ietf.org>; Fri, 25 Apr 2003 22:46:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00374
	for <megaco@ietf.org>; Fri, 25 Apr 2003 22:43:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 199Fgj-00057b-00
	for megaco@ietf.org; Fri, 25 Apr 2003 22:45:17 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by ietf-mx with esmtp (Exim 4.12)
	id 199Fgj-00057Y-00
	for megaco@ietf.org; Fri, 25 Apr 2003 22:45:17 -0400
Received: from cisco.com (sjc-vpn4-450.cisco.com [10.21.81.194])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3Q2jAID005862;
	Fri, 25 Apr 2003 19:45:10 -0700 (PDT)
Message-ID: <3EA9F2B5.FEBAA43@cisco.com>
Date: Fri, 25 Apr 2003 22:45:09 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Qiaobing Xie <Qiaobing.Xie@motorola.com>
CC: Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>,
        megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Qiaobing

Nobody is denying that SCTP is an existing spec that solves the multihoming problem and it
is quite understandable that you in particular advocate it. However, you seem to have lost
sight of the original question in this thread, which was about native Megaco protocol
support for redundancy and failover, and as part of that, support for multihoming. Initial
claims was that Megaco fully supports this, but we seem to have converged on the opinion
that it does not, unless you use SCTP, which is not part of the base Megaco protocol.
Furthermore, despite everything, the fact of the matter is that for various reasons, not
everybody will be implementing SCTP at least for now (NATs, firewalls and security do not
help SCTP here) and since UDP and TCP are the basic requirements, it would have been nice to
have better mechanisms for these; it can be done very easily (see MGCP for example).
Sometimes, it's good to be a bit pragmatic.

-- Flemming



Qiaobing Xie wrote:

> (Try to respond to similar remarks from two mails)
>
> Flemming Andreasen wrote:
> ...
> > In any case, SCTP is there as an option today for those
> > that wish to use it. For those that don't, we've already concluded that
> > multihoming/redundancy/failover is not very well supported, and that there doesn't
> > seem to be much desire to change that. I personally think that's a bit of a shame, but
> > so be it.
> ...
>
> Adrian Soncodi wrote:
> ...
> > You seem to say "if you want multi-homing, it must be only over SCTP".
> > Why? Someone could similarly say "if you want MEGACO, it must be over
> > UDP". But we don't, we allow all 3 protocols, for flexibility.
> >
>
> I didn't mean to say "you must". I was under the impression that some of
> us were saying that we had a technical issue to support multi-homing in
> MEGACO, and my response was essentially "this is not an issue, there are
> protocol specs existing in IETF to do just that, which is
> MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
> is not really about the lack of a solution, it's more about that some of
> us just don't want to use the existing IETF solution (for whatever
> non-tech reasons, or simply just don't wish to use it) and prefer to
> define another solution in IETF. Well, if that is the case, I don't have
> much else to say...
>
> Of cause, if there are tech issues/shortcomings/drawbacks/advantages
> related to using SCTP for MEGACO multi-homing support, I'd be more than
> glad to help answer.
>
> -Qiaobing

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 28 03:28:11 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22925
	for <megaco-archive@lists.ietf.org>; Mon, 28 Apr 2003 03:28:10 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7VY814768;
	Mon, 28 Apr 2003 03:31:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7ND814347
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 03:23:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22784
	for <megaco@ietf.org>; Mon, 28 Apr 2003 03:18:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2wA-00010o-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:30 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2w8-00010l-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:29 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3S7IV428360;
	Mon, 28 Apr 2003 17:18:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3S7Kp006685;
	Mon, 28 Apr 2003 17:20:51 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8NXLK3; Mon, 28 Apr 2003 17:20:49 +1000
Message-ID: <3EACB698.C183C2BE@ericsson.com.au>
Date: Mon, 28 Apr 2003 15:05:28 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: milton@hfcl.com
CC: megaco@ietf.org, "'Kevin Boyle'" <kboyle@nortelnetworks.com>
Subject: Re: [Megaco] (no subject)
References: <000201c30ad9$8f3fa600$3da69384@euronymous>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

G'Day,

I think the key term is "participation". People proposing work or initiating
work items are free to push this work in either the ITU or IETF for
ratification. Items from both ITU and IETF are discussed on the Megaco IETF
mailing list. If people have views then they have ample opportunity for these to
be aired in either the ITU or the IETF.

We had these IETF vs ITU discussion several years ago now and I think practice
has shown that the SG16 and Megaco relationship is working. I do think that the
issue of where elements of the CAS is solveable without reverting to the IETF is
better than the ITU and vice versa arguments. Track record has proven these to
be counter productive and a distraction from the real technical issues.

Regards, Christian


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 28 03:29:20 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22952
	for <megaco-archive@odin.ietf.org>; Mon, 28 Apr 2003 03:29:20 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3S7Xmp14830
	for megaco-archive@odin.ietf.org; Mon, 28 Apr 2003 03:33:48 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7Xl814827
	for <megaco-web-archive@optimus.ietf.org>; Mon, 28 Apr 2003 03:33:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22942
	for <megaco-web-archive@ietf.org>; Mon, 28 Apr 2003 03:28:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A36O-00013q-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 03:31:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A36O-00013l-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 03:31:04 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7VY814768;
	Mon, 28 Apr 2003 03:31:34 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7ND814347
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 03:23:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22784
	for <megaco@ietf.org>; Mon, 28 Apr 2003 03:18:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2wA-00010o-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:30 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2w8-00010l-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:29 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3S7IV428360;
	Mon, 28 Apr 2003 17:18:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3S7Kp006685;
	Mon, 28 Apr 2003 17:20:51 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8NXLK3; Mon, 28 Apr 2003 17:20:49 +1000
Message-ID: <3EACB698.C183C2BE@ericsson.com.au>
Date: Mon, 28 Apr 2003 15:05:28 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: milton@hfcl.com
CC: megaco@ietf.org, "'Kevin Boyle'" <kboyle@nortelnetworks.com>
Subject: Re: [Megaco] (no subject)
References: <000201c30ad9$8f3fa600$3da69384@euronymous>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

G'Day,

I think the key term is "participation". People proposing work or initiating
work items are free to push this work in either the ITU or IETF for
ratification. Items from both ITU and IETF are discussed on the Megaco IETF
mailing list. If people have views then they have ample opportunity for these to
be aired in either the ITU or the IETF.

We had these IETF vs ITU discussion several years ago now and I think practice
has shown that the SG16 and Megaco relationship is working. I do think that the
issue of where elements of the CAS is solveable without reverting to the IETF is
better than the ITU and vice versa arguments. Track record has proven these to
be counter productive and a distraction from the real technical issues.

Regards, Christian


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 28 03:33:59 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23025
	for <megaco-archive@lists.ietf.org>; Mon, 28 Apr 2003 03:33:59 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7bV815416;
	Mon, 28 Apr 2003 03:37:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7NO814352
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 03:23:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22792
	for <megaco@ietf.org>; Mon, 28 Apr 2003 03:18:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2wL-000116-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:41 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2wK-000113-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:40 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3S7IU428358;
	Mon, 28 Apr 2003 17:18:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3S7Kn006680;
	Mon, 28 Apr 2003 17:20:50 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8NXLKM; Mon, 28 Apr 2003 17:20:48 +1000
Message-ID: <3EACB388.FB7885D8@ericsson.com.au>
Date: Mon, 28 Apr 2003 14:52:24 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: klaha@hss.hns.com
CC: Aleksandr Ryabin <kengr@winphoria.com>, megaco@ietf.org,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Michael DiGioia <michaeldigioia@hotmail.com>, bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support
References: <OF0BAD0D76.DB0D008A-ON65256D11.00408581@hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello,

I think to move forward on this issue the editor's of the relevant drafts should
have further discussions on how to move this work forward and present a unified
approach to the list.

The main thing is that the work is progressed and that the information is
available to both those in the ITU and the IETF.

Regards,
Christian

klaha@hss.hns.com wrote:
> 
> Let me take this opportunity to present the understanding that Hughes has
> on this topic.
> 
> 1. It was 3 years back that Hughes first published the r2 draft. It had
> created a
> lot of interest on the list, so much so that it was made a formal MEGACO WG
> item.
> 
> 2. Hughes followed it up with the r1 package draft. This stirred a lot of
> reaction and
> proactive contribution from the list to make it into a generic CAS package
> draft
> addressing not only r1 but nearly all forms of North American CAS. This
> draft
> was later renamed to manyfolks CAS package draft and included the "bcas"
> package.
> 
> 3. There was a directive from the list to make r2 a derived package to
> bcas.
> Hughes entered into a dialogue with Nortel (one of the co-authors along
> with Hughes
> to the basic CAS package draft) to make certain modifications in bcas
> package
> so as to enable r2 a true derivative of bcas. It was generally agreed that
> there be
> yet an abstraction package "icas" which derives from "bcas" and "r2" then
> derives
> "icas". ( icas does in no way replace r2)
> 
> 4. The "icas" package never saw the light of the day at IETF. Hughes went
> ahead
> and resubmitted the "r2" draft aligned as close to the already expired
> "bcas" package
> as possible. The "bcas" package submission was also not refreshed.
> 
> 5. All of a sudden now we find that "bcas" and "icas" have found entries
> into ITU
> package standardization sector but not "r2". The "icas" package draft was
> also never floated
> to the list for any review.
> 
> 6. "icas" package submitted to ITU in its present form has flaws.
> 
> Given the above background, we clearly need a charter how to move forward
> on
> the CAS package drafts. Hughes generally agrees that the CAS package
> architecture
> should follow the hierarchy "bcas"-->"icas"-->"r2" (with some changes in
> the icas package
> in its present form).
> 
> It is to be noted that content-wise whatever is there in the latest r2
> package draft submitted to IETF
> is authentic and requires no modification. An alignment with icas package
> requires certain
> signals/events/properties to be moved out of r2 package and placed in icas.
> 
> We are willing to synch the CAS package drafts both at IETF and ITU but
> question is how?
> 
> -- Kushanava
> 
> Aleksandr Ryabin <kengr@winphoria.com>@ietf.org on 04/23/2003 04:34:50 AM
> 
> Sent by:    megaco-admin@ietf.org
> 
> To:    megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
> cc:    Michael DiGioia <michaeldigioia@hotmail.com>,
>        Christian.Groves@ericsson.com.au, bsteinka@telica.com
> 
> Subject:    RE: [Megaco] Megaco CAS support
> 
> I see the reason to push it through ITU, but we definitely would not want
> to
> see two, or more different packages doing the same thing published one
> through
> IETF and another trough ITU. Thus, since MEGACO is (also) published as
> IETF standard we should at least make every effort to avoid duplication of
> work.
> 
> Unfortunately not all of us have direct access (at least direct say) in ITU
> and
> thus at least keeping IETF community informed on progress of MEGACO/H.248
> related work would be very useful, as well as using this list for various
> discussions.
> In fact AVD-2345 contains the following statement regarding H.248.mf
> packages:
> "It was suggested that we send a liaison to the IESG and MEGACO proposing
> this move and asking if this presents a problem to either of them.  Mr
> Boyle
> will draft a liaison for our consideration.  If we do not receive an
> objection from
> them we will progress these with a goal of consent in May.  The liaison
> appears
> as TD-20a." Should then the r2 package also be included in same liaison?
> 
> As far as I remember "CAS packages published by Hughes" are new revisions
> of the drafts that were published a long time ago (at least for r2). This
> very fact
> that new revisions were published despite the CAS work moved to ITU
> indicates
> the lack of communication.
> 
> Can I suggest to put some wording on WG charter home page regarding
> each work "moved" to ITU (links to liaisons?) and maybe at least some kind
> of sense of ITU schedule for that work? I know there is wording already
> about
> IETF position related to packages, but still info would be very useful.
> At least a pointer to latest up to date "packages guide" (AVD-2294) might
> be
> sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph
> from
> AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)
> 
> In any case could you please outline an ITU schedule for CAS related
> packages?
> What is the verdict for CAS drafts published in IETF? Are they going to be
> folded
> into ITU work? I guess at least some of them (by Nortel) are? What about
> others?
> Is r2 package planned to be dropped/replaced with icas?
> Are there any additional ITU CAS related packages/documents not listed
> in original Christian's email?
> Are there any other CAS packages planned?
> 
> Thanks
>         Aleks
> 
> At 05:26 PM 4/22/2003, Kevin Boyle wrote:
> 
> With all due respect, the IETF had its chance to progress these (and many
> other) packages.  In the interests of the larger community, I have taken
> the packages to the ITU for standardization, since the IETF does not seem
> interested in standardizing any packages.
> 
> The work in the IETF is not "up and running".  The drafts published by
> Hughes were published after the CAS packages were submitted to the ITU.
> 
> Given that the working group is in the process of winding down, I do not
> see any benefit to anyone in continuing to allow the IETF to hold up
> standardization when the ITU is prepared to consider and advance the work.
> 
> Kevin
> 
> -----Original Message-----
> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
> Sent: Tuesday, April 22, 2003 5:01 PM
> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
> Cc: bsteinka@telica.com
> Subject: Re: [Megaco] Megaco CAS support
> 
> Christian,
> 
> I agree, CAS should be part of the IETF similar to the original MEGACO
> draft
> work that held both organizations in sync.
> 
> /mpd
> 
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you
> have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and
> IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> 
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> 
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 28 03:35:05 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23055
	for <megaco-archive@odin.ietf.org>; Mon, 28 Apr 2003 03:35:05 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3S7dXZ15873
	for megaco-archive@odin.ietf.org; Mon, 28 Apr 2003 03:39:33 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7dV815870
	for <megaco-web-archive@optimus.ietf.org>; Mon, 28 Apr 2003 03:39:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23040
	for <megaco-web-archive@ietf.org>; Mon, 28 Apr 2003 03:34:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A3Bw-00015n-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 03:36:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A3Bv-00015k-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 03:36:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7bV815416;
	Mon, 28 Apr 2003 03:37:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7NO814352
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 03:23:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22792
	for <megaco@ietf.org>; Mon, 28 Apr 2003 03:18:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2wL-000116-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:41 -0400
Received: from ish7.ericsson.com.au ([61.88.9.195])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A2wK-000113-00
	for megaco@ietf.org; Mon, 28 Apr 2003 03:20:40 -0400
Received: from brsf10.epa.ericsson.se ([61.88.9.226])
	by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h3S7IU428358;
	Mon, 28 Apr 2003 17:18:31 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.7+Sun/8.11.6) with ESMTP id h3S7Kn006680;
	Mon, 28 Apr 2003 17:20:50 +1000 (EST)
Received: from ericsson.com.au (E0050DA878EDF [146.11.233.201]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JB8NXLKM; Mon, 28 Apr 2003 17:20:48 +1000
Message-ID: <3EACB388.FB7885D8@ericsson.com.au>
Date: Mon, 28 Apr 2003 14:52:24 +1000
From: Christian Groves <Christian.Groves@ericsson.com.au>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: klaha@hss.hns.com
CC: Aleksandr Ryabin <kengr@winphoria.com>, megaco@ietf.org,
        Kevin Boyle <kboyle@nortelnetworks.com>,
        Michael DiGioia <michaeldigioia@hotmail.com>, bsteinka@telica.com
Subject: Re: [Megaco] Megaco CAS support
References: <OF0BAD0D76.DB0D008A-ON65256D11.00408581@hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hello,

I think to move forward on this issue the editor's of the relevant drafts should
have further discussions on how to move this work forward and present a unified
approach to the list.

The main thing is that the work is progressed and that the information is
available to both those in the ITU and the IETF.

Regards,
Christian

klaha@hss.hns.com wrote:
> 
> Let me take this opportunity to present the understanding that Hughes has
> on this topic.
> 
> 1. It was 3 years back that Hughes first published the r2 draft. It had
> created a
> lot of interest on the list, so much so that it was made a formal MEGACO WG
> item.
> 
> 2. Hughes followed it up with the r1 package draft. This stirred a lot of
> reaction and
> proactive contribution from the list to make it into a generic CAS package
> draft
> addressing not only r1 but nearly all forms of North American CAS. This
> draft
> was later renamed to manyfolks CAS package draft and included the "bcas"
> package.
> 
> 3. There was a directive from the list to make r2 a derived package to
> bcas.
> Hughes entered into a dialogue with Nortel (one of the co-authors along
> with Hughes
> to the basic CAS package draft) to make certain modifications in bcas
> package
> so as to enable r2 a true derivative of bcas. It was generally agreed that
> there be
> yet an abstraction package "icas" which derives from "bcas" and "r2" then
> derives
> "icas". ( icas does in no way replace r2)
> 
> 4. The "icas" package never saw the light of the day at IETF. Hughes went
> ahead
> and resubmitted the "r2" draft aligned as close to the already expired
> "bcas" package
> as possible. The "bcas" package submission was also not refreshed.
> 
> 5. All of a sudden now we find that "bcas" and "icas" have found entries
> into ITU
> package standardization sector but not "r2". The "icas" package draft was
> also never floated
> to the list for any review.
> 
> 6. "icas" package submitted to ITU in its present form has flaws.
> 
> Given the above background, we clearly need a charter how to move forward
> on
> the CAS package drafts. Hughes generally agrees that the CAS package
> architecture
> should follow the hierarchy "bcas"-->"icas"-->"r2" (with some changes in
> the icas package
> in its present form).
> 
> It is to be noted that content-wise whatever is there in the latest r2
> package draft submitted to IETF
> is authentic and requires no modification. An alignment with icas package
> requires certain
> signals/events/properties to be moved out of r2 package and placed in icas.
> 
> We are willing to synch the CAS package drafts both at IETF and ITU but
> question is how?
> 
> -- Kushanava
> 
> Aleksandr Ryabin <kengr@winphoria.com>@ietf.org on 04/23/2003 04:34:50 AM
> 
> Sent by:    megaco-admin@ietf.org
> 
> To:    megaco@ietf.org, "Kevin Boyle" <kboyle@nortelnetworks.com>
> cc:    Michael DiGioia <michaeldigioia@hotmail.com>,
>        Christian.Groves@ericsson.com.au, bsteinka@telica.com
> 
> Subject:    RE: [Megaco] Megaco CAS support
> 
> I see the reason to push it through ITU, but we definitely would not want
> to
> see two, or more different packages doing the same thing published one
> through
> IETF and another trough ITU. Thus, since MEGACO is (also) published as
> IETF standard we should at least make every effort to avoid duplication of
> work.
> 
> Unfortunately not all of us have direct access (at least direct say) in ITU
> and
> thus at least keeping IETF community informed on progress of MEGACO/H.248
> related work would be very useful, as well as using this list for various
> discussions.
> In fact AVD-2345 contains the following statement regarding H.248.mf
> packages:
> "It was suggested that we send a liaison to the IESG and MEGACO proposing
> this move and asking if this presents a problem to either of them.  Mr
> Boyle
> will draft a liaison for our consideration.  If we do not receive an
> objection from
> them we will progress these with a goal of consent in May.  The liaison
> appears
> as TD-20a." Should then the r2 package also be included in same liaison?
> 
> As far as I remember "CAS packages published by Hughes" are new revisions
> of the drafts that were published a long time ago (at least for r2). This
> very fact
> that new revisions were published despite the CAS work moved to ITU
> indicates
> the lack of communication.
> 
> Can I suggest to put some wording on WG charter home page regarding
> each work "moved" to ITU (links to liaisons?) and maybe at least some kind
> of sense of ITU schedule for that work? I know there is wording already
> about
> IETF position related to packages, but still info would be very useful.
> At least a pointer to latest up to date "packages guide" (AVD-2294) might
> be
> sufficient and H.248 related parts from 3.1.6 "Document Status" paragraph
> from
> AVD-2345. (BTW AVD-2294 missing info on this very CAS work as part of ITU)
> 
> In any case could you please outline an ITU schedule for CAS related
> packages?
> What is the verdict for CAS drafts published in IETF? Are they going to be
> folded
> into ITU work? I guess at least some of them (by Nortel) are? What about
> others?
> Is r2 package planned to be dropped/replaced with icas?
> Are there any additional ITU CAS related packages/documents not listed
> in original Christian's email?
> Are there any other CAS packages planned?
> 
> Thanks
>         Aleks
> 
> At 05:26 PM 4/22/2003, Kevin Boyle wrote:
> 
> With all due respect, the IETF had its chance to progress these (and many
> other) packages.  In the interests of the larger community, I have taken
> the packages to the ITU for standardization, since the IETF does not seem
> interested in standardizing any packages.
> 
> The work in the IETF is not "up and running".  The drafts published by
> Hughes were published after the CAS packages were submitted to the ITU.
> 
> Given that the working group is in the process of winding down, I do not
> see any benefit to anyone in continuing to allow the IETF to hold up
> standardization when the ITU is prepared to consider and advance the work.
> 
> Kevin
> 
> -----Original Message-----
> From: Michael DiGioia [mailto:michaeldigioia@hotmail.com]
> Sent: Tuesday, April 22, 2003 5:01 PM
> To: kengr@winphoria.com; Christian.Groves@ericsson.com.au; megaco@ietf.org
> Cc: bsteinka@telica.com
> Subject: Re: [Megaco] Megaco CAS support
> 
> Christian,
> 
> I agree, CAS should be part of the IETF similar to the original MEGACO
> draft
> work that held both organizations in sync.
> 
> /mpd
> 
> >From: Aleksandr Ryabin <kengr@winphoria.com>
> >To: Christian Groves <Christian.Groves@ericsson.com.au>,
> >megaco@ietf.org
> >CC: Brad Steinka <bsteinka@telica.com>
> >Subject: Re: [Megaco] Megaco CAS support
> >Date: Tue, 22 Apr 2003 10:30:01 -0400
> >
> >Hi Christian,
> >
> >Then why are these brand new revisions of drafts were just recently
> >submitted?
> >
> >http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-03.txt
> >http://www.ietf.org/internet-drafts/draft-laha-megaco-cas-mntc-00.txt
> >
> >More over a quick look through reveals that some of the package items
> >in
> >icas
> >(ITU) the same as in r2 (IETF) up to the extent of exactly the same
> >wording.
> >
> >Same AVD-2316 ITU doc mentions "CAS Blocking" package in summary which
> >does not seem to be defined in the document and also "conflicts" with
> >above IETF "CAS Maintenance Package".
> >
> >There is also reference to r2 package in AVD-2316 nowhere found in ITU.
> >
> >Also basic CAS packages draft still available at:
> >http://www.ietf.org/internet-drafts/draft-manyfolks-megaco-caspackage-0
> >2.txt
> >but it is slightly different (outdated?) from AVD-2315 ITU version you
> have
> >specified.
> >
> >The recent submission of the above drafts had lead me to believe that
> >CAS work is still quite "up and running" in IETF. This is all very
> >confusing. When was it decided to move the work to ITU? Could someone
> >point me out to some references (in IETF) of that please?
> >
> >My two cents on this topic: CAS is not an isolated package and in my
> >opinion
> >it would be much more productive to keep it on both channels (ITU and
> IETF)
> >and in sync, similar to some other items done so far in H.248/MEGACO.
> >What other folks think about it?
> >
> >Also in any case can the authors of ITU and IETF CAS related packages
> >work together to come up with some kind of game plan and post it to the
> >list to avoid any further confusion and inconsistencies?
> >
> >Thanks!
> >         Aleks
> >
> >At 07:54 PM 4/21/2003, Christian Groves wrote:
> >>G'Day Brad and Karl,
> >>
> >>I believe the intention is to move the CAS work into the ITU. The
> >>contributions
> >>containing the latest drafts can be found at:
> >>ftp://standard.pictel.com/avc-site/0302_San/
> >>
> >>AVD-2312        MF Tone Generation and Detection Packages
> >>AVD-2315        Basic CAS Packages
> >>AVD-2316        International CAS Packages
> >>AVD-2317        Enhanced Analog Line Packages
> >>
> >>Regards, Christian
> >>
> >>Brad Steinka wrote:
> >> >
> >> > There were several RFC draft document that described various
> >> > packages
> >>to
> >> > support CAS, R1, R2, BCAS, etc.
> >> > Most of these drafts have expired.
> >> >
> >> > Can anyone tell me what the latest RFCs are that support CAS calls
> >> > and
> >>where
> >> > they are in the standards process?
> >> >
> >> > Thanks
> >> >
> 
> >> > Director - Software Engineering
> >> > 734 Forest Street, Building G, Suite 100
> >> > Marlboro, Ma.   01752
> >> > Tel:  508-480-0909  x154
> >> > Email: bsteinka@telica.com <mailto:bsteinka@telica.com>
> >> > Web:   www.telica.com <http://www.telica.com>
> >> >
> >> > _______________________________________________
> >> > Megaco mailing list
> >> > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco
> >>_______________________________________________
> >>Megaco mailing list
> >>Megaco@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/megaco
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> 
> _________________________________________________________________
> MSN 8 with e-mail virus protection service: 2 months FREE*
> http://join.msn.com/?page=features/virus
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 28 05:02:16 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24559
	for <megaco-archive@lists.ietf.org>; Mon, 28 Apr 2003 05:02:16 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S962822372;
	Mon, 28 Apr 2003 05:06:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S8v0821899
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 04:57:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24381
	for <megaco@ietf.org>; Mon, 28 Apr 2003 04:52:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4Ot-0001VU-00
	for megaco@ietf.org; Mon, 28 Apr 2003 04:54:15 -0400
Received: from [194.224.48.69] (helo=sess01.rdp.asi.alcatel.es)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4Os-0001VL-00
	for megaco@ietf.org; Mon, 28 Apr 2003 04:54:14 -0400
Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1])
	by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h3S8sHS15007;
	Mon, 28 Apr 2003 10:54:17 +0200 (MEST)
Received: from alcatel.es (sers5021 [159.23.115.21])
	by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id KAA26640;
	Mon, 28 Apr 2003 10:54:28 +0200 (MET DST)
Message-ID: <3EACEC44.96FF416A@alcatel.es>
Date: Mon, 28 Apr 2003 10:54:28 +0200
From: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>
Organization: ALCATEL
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Qiaobing Xie <Qiaobing.Xie@motorola.com>,
        Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>, megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------C683F96B128B90D20EEE3924"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------C683F96B128B90D20EEE3924
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I agree with Flemming that Megaco should be based on UDP and TCP.
SCTP is not widely deployed and can lead to problems of interoperability.
I would leave it as optional.

For me the control association is clearly defined and it is 1 association = 1 IP address.
Why? Because the assocation is done through a ServiceChange Restart message which involves
an IP address (in the MGC ID)  and not a domain name. If the DNS returns more than
one IP address for a given name the MG must choose one of them.

What I feel is that the gap is in the definition of the secondary MGCs and its provisionning.
I think there should be a way in which the MGC could inform the MGs about existing secondaries
MGCs. Now this can only be done using a  HandOff method but sometimes this message cannot
be sent by the primary MGC (e.g. network failure, crash of the MGC ...).
So it would be useful to add a new method in the ServiceChange to send this information and add

a new parameter indicating what type of relationship there is between primary and secondary
(e.g. mirror, backup, independent, third party.....)
So in case a MGC is multihomed it could inform the MG at startup that a MGC exists which is a
secondary mirror MGC (which corresponds to the same MGC but with another IP address).
This process can be independent on the actual procedures done by the operators to declare
secondary MGCs.

When a problem arises the MG can act in two ways:
1) If the new MGC is a mirror (maybe other types can be included here) it can resend the
transactions
which have failed in the old one.
2) If the new MGC is not a mirror it should try to establish a connection with a ServiceChange
as defined
in the megaco protocol. Then the MGC is in charge of recovering the state of the MG ASAP and
the service.

In this way not too much work has to be added and we can accomplish a solution.

Regards
Fernando


Flemming Andreasen wrote:

> Qiaobing
>
> Nobody is denying that SCTP is an existing spec that solves the multihoming problem and it
> is quite understandable that you in particular advocate it. However, you seem to have lost
> sight of the original question in this thread, which was about native Megaco protocol
> support for redundancy and failover, and as part of that, support for multihoming. Initial
> claims was that Megaco fully supports this, but we seem to have converged on the opinion
> that it does not, unless you use SCTP, which is not part of the base Megaco protocol.
> Furthermore, despite everything, the fact of the matter is that for various reasons, not
> everybody will be implementing SCTP at least for now (NATs, firewalls and security do not
> help SCTP here) and since UDP and TCP are the basic requirements, it would have been nice to
> have better mechanisms for these; it can be done very easily (see MGCP for example).
> Sometimes, it's good to be a bit pragmatic.
>
> -- Flemming
>
> Qiaobing Xie wrote:
>
> > (Try to respond to similar remarks from two mails)
> >
> > Flemming Andreasen wrote:
> > ...
> > > In any case, SCTP is there as an option today for those
> > > that wish to use it. For those that don't, we've already concluded that
> > > multihoming/redundancy/failover is not very well supported, and that there doesn't
> > > seem to be much desire to change that. I personally think that's a bit of a shame, but
> > > so be it.
> > ...
> >
> > Adrian Soncodi wrote:
> > ...
> > > You seem to say "if you want multi-homing, it must be only over SCTP".
> > > Why? Someone could similarly say "if you want MEGACO, it must be over
> > > UDP". But we don't, we allow all 3 protocols, for flexibility.
> > >
> >
> > I didn't mean to say "you must". I was under the impression that some of
> > us were saying that we had a technical issue to support multi-homing in
> > MEGACO, and my response was essentially "this is not an issue, there are
> > protocol specs existing in IETF to do just that, which is
> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
> > is not really about the lack of a solution, it's more about that some of
> > us just don't want to use the existing IETF solution (for whatever
> > non-tech reasons, or simply just don't wish to use it) and prefer to
> > define another solution in IETF. Well, if that is the case, I don't have
> > much else to say...
> >
> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages
> > related to using SCTP for MEGACO multi-homing support, I'd be more than
> > glad to help answer.
> >
> > -Qiaobing

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



--------------C683F96B128B90D20EEE3924
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>I agree with Flemming that Megaco should be based on UDP and TCP.
<br>SCTP is not widely deployed and can lead to problems of interoperability.
<br>I would leave it as optional.
<p>For me the control association is clearly defined and it is 1 association
= 1 IP address.
<br>Why? Because the assocation is done through a ServiceChange Restart
message which involves
<br>an IP address (in the MGC ID)&nbsp; and not a domain name. If the DNS
returns more than
<br>one IP address for a given name the MG must choose one of them.
<p>What I feel is that the gap is in the definition of the secondary MGCs
and its provisionning.
<br>I think there should be a way in which the MGC could inform the MGs
about existing secondaries
<br>MGCs. Now this can only be done using a&nbsp; HandOff method but sometimes
this message cannot
<br>be sent by the primary MGC (e.g. network failure, crash of the MGC
...).
<br>So it would be useful to add a new method in the ServiceChange to send
this information and add
<br>a new parameter indicating what type of relationship there is between
primary and secondary
<br>(e.g. mirror, backup, independent, third party.....)
<br>So in case a MGC is multihomed it could inform the MG at startup that
a MGC exists which is a
<br>secondary mirror MGC (which corresponds to the same MGC but with another
IP address).
<br>This process can be independent on the actual procedures done by the
operators to declare
<br>secondary MGCs.
<p>When a problem arises the MG can act in two ways:
<br>1) If the new MGC&nbsp;is a mirror (maybe other types can be included
here) it can resend the transactions
<br>which have failed in the old one.
<br>2)&nbsp;If the new MGC is not a mirror it should try to establish a
connection with a ServiceChange as defined
<br>in the megaco protocol. Then the MGC is in charge of recovering the
state of the MG ASAP&nbsp;and the service.
<p>In this way not too much work has to be added and we can accomplish
a solution.
<p>Regards
<br>Fernando
<br>&nbsp;
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>Qiaobing
<p>Nobody is denying that SCTP is an existing spec that solves the multihoming
problem and it
<br>is quite understandable that you in particular advocate it. However,
you seem to have lost
<br>sight of the original question in this thread, which was about native
Megaco protocol
<br>support for redundancy and failover, and as part of that, support for
multihoming. Initial
<br>claims was that Megaco fully supports this, but we seem to have converged
on the opinion
<br>that it does not, unless you use SCTP, which is not part of the base
Megaco protocol.
<br>Furthermore, despite everything, the fact of the matter is that for
various reasons, not
<br>everybody will be implementing SCTP at least for now (NATs, firewalls
and security do not
<br>help SCTP here) and since UDP and TCP are the basic requirements, it
would have been nice to
<br>have better mechanisms for these; it can be done very easily (see MGCP
for example).
<br>Sometimes, it's good to be a bit pragmatic.
<p>-- Flemming
<p>Qiaobing Xie wrote:
<p>> (Try to respond to similar remarks from two mails)
<br>>
<br>> Flemming Andreasen wrote:
<br>> ...
<br>> > In any case, SCTP is there as an option today for those
<br>> > that wish to use it. For those that don't, we've already concluded
that
<br>> > multihoming/redundancy/failover is not very well supported, and
that there doesn't
<br>> > seem to be much desire to change that. I personally think that's
a bit of a shame, but
<br>> > so be it.
<br>> ...
<br>>
<br>> Adrian Soncodi wrote:
<br>> ...
<br>> > You seem to say "if you want multi-homing, it must be only over
SCTP".
<br>> > Why? Someone could similarly say "if you want MEGACO, it must be
over
<br>> > UDP". But we don't, we allow all 3 protocols, for flexibility.
<br>> >
<br>>
<br>> I didn't mean to say "you must". I was under the impression that
some of
<br>> us were saying that we had a technical issue to support multi-homing
in
<br>> MEGACO, and my response was essentially "this is not an issue, there
are
<br>> protocol specs existing in IETF to do just that, which is
<br>> MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is,
it
<br>> is not really about the lack of a solution, it's more about that
some of
<br>> us just don't want to use the existing IETF solution (for whatever
<br>> non-tech reasons, or simply just don't wish to use it) and prefer
to
<br>> define another solution in IETF. Well, if that is the case, I don't
have
<br>> much else to say...
<br>>
<br>> Of cause, if there are tech issues/shortcomings/drawbacks/advantages
<br>> related to using SCTP for MEGACO multi-homing support, I'd be more
than
<br>> glad to help answer.
<br>>
<br>> -Qiaobing</blockquote>

<pre>--&nbsp;
Fernando Vallejo Lazaro
Phone:&nbsp; +34 91 330 5614
SW&nbsp; Wireline ASD-Madrid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ALCATEL</pre>
&nbsp;</html>

--------------C683F96B128B90D20EEE3924--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 28 05:03:21 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24614
	for <megaco-archive@odin.ietf.org>; Mon, 28 Apr 2003 05:03:21 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3S97na23324
	for megaco-archive@odin.ietf.org; Mon, 28 Apr 2003 05:07:49 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S97n823321
	for <megaco-web-archive@optimus.ietf.org>; Mon, 28 Apr 2003 05:07:49 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24575
	for <megaco-web-archive@ietf.org>; Mon, 28 Apr 2003 05:02:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4ZM-0001Xi-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 05:05:04 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4ZL-0001Xf-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 05:05:03 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S962822372;
	Mon, 28 Apr 2003 05:06:02 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S8v0821899
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 04:57:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24381
	for <megaco@ietf.org>; Mon, 28 Apr 2003 04:52:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4Ot-0001VU-00
	for megaco@ietf.org; Mon, 28 Apr 2003 04:54:15 -0400
Received: from [194.224.48.69] (helo=sess01.rdp.asi.alcatel.es)
	by ietf-mx with esmtp (Exim 4.12)
	id 19A4Os-0001VL-00
	for megaco@ietf.org; Mon, 28 Apr 2003 04:54:14 -0400
Received: from sers002.rpi.ses.alcatel.es (localhost [127.0.0.1])
	by sess01.rdp.asi.alcatel.es (8.11.2/8.11.2) with ESMTP id h3S8sHS15007;
	Mon, 28 Apr 2003 10:54:17 +0200 (MEST)
Received: from alcatel.es (sers5021 [159.23.115.21])
	by sers002.rpi.ses.alcatel.es (8.8.8+Sun/8.8.8) with ESMTP id KAA26640;
	Mon, 28 Apr 2003 10:54:28 +0200 (MET DST)
Message-ID: <3EACEC44.96FF416A@alcatel.es>
Date: Mon, 28 Apr 2003 10:54:28 +0200
From: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>
Organization: ALCATEL
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen <fandreas@cisco.com>
CC: Qiaobing Xie <Qiaobing.Xie@motorola.com>,
        Adrian Soncodi <adrian.soncodi@tekelec.com>,
        Kevin Boyle <kboyle@nortelnetworks.com>, megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------C683F96B128B90D20EEE3924"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>


--------------C683F96B128B90D20EEE3924
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I agree with Flemming that Megaco should be based on UDP and TCP.
SCTP is not widely deployed and can lead to problems of interoperability.
I would leave it as optional.

For me the control association is clearly defined and it is 1 association = 1 IP address.
Why? Because the assocation is done through a ServiceChange Restart message which involves
an IP address (in the MGC ID)  and not a domain name. If the DNS returns more than
one IP address for a given name the MG must choose one of them.

What I feel is that the gap is in the definition of the secondary MGCs and its provisionning.
I think there should be a way in which the MGC could inform the MGs about existing secondaries
MGCs. Now this can only be done using a  HandOff method but sometimes this message cannot
be sent by the primary MGC (e.g. network failure, crash of the MGC ...).
So it would be useful to add a new method in the ServiceChange to send this information and add

a new parameter indicating what type of relationship there is between primary and secondary
(e.g. mirror, backup, independent, third party.....)
So in case a MGC is multihomed it could inform the MG at startup that a MGC exists which is a
secondary mirror MGC (which corresponds to the same MGC but with another IP address).
This process can be independent on the actual procedures done by the operators to declare
secondary MGCs.

When a problem arises the MG can act in two ways:
1) If the new MGC is a mirror (maybe other types can be included here) it can resend the
transactions
which have failed in the old one.
2) If the new MGC is not a mirror it should try to establish a connection with a ServiceChange
as defined
in the megaco protocol. Then the MGC is in charge of recovering the state of the MG ASAP and
the service.

In this way not too much work has to be added and we can accomplish a solution.

Regards
Fernando


Flemming Andreasen wrote:

> Qiaobing
>
> Nobody is denying that SCTP is an existing spec that solves the multihoming problem and it
> is quite understandable that you in particular advocate it. However, you seem to have lost
> sight of the original question in this thread, which was about native Megaco protocol
> support for redundancy and failover, and as part of that, support for multihoming. Initial
> claims was that Megaco fully supports this, but we seem to have converged on the opinion
> that it does not, unless you use SCTP, which is not part of the base Megaco protocol.
> Furthermore, despite everything, the fact of the matter is that for various reasons, not
> everybody will be implementing SCTP at least for now (NATs, firewalls and security do not
> help SCTP here) and since UDP and TCP are the basic requirements, it would have been nice to
> have better mechanisms for these; it can be done very easily (see MGCP for example).
> Sometimes, it's good to be a bit pragmatic.
>
> -- Flemming
>
> Qiaobing Xie wrote:
>
> > (Try to respond to similar remarks from two mails)
> >
> > Flemming Andreasen wrote:
> > ...
> > > In any case, SCTP is there as an option today for those
> > > that wish to use it. For those that don't, we've already concluded that
> > > multihoming/redundancy/failover is not very well supported, and that there doesn't
> > > seem to be much desire to change that. I personally think that's a bit of a shame, but
> > > so be it.
> > ...
> >
> > Adrian Soncodi wrote:
> > ...
> > > You seem to say "if you want multi-homing, it must be only over SCTP".
> > > Why? Someone could similarly say "if you want MEGACO, it must be over
> > > UDP". But we don't, we allow all 3 protocols, for flexibility.
> > >
> >
> > I didn't mean to say "you must". I was under the impression that some of
> > us were saying that we had a technical issue to support multi-homing in
> > MEGACO, and my response was essentially "this is not an issue, there are
> > protocol specs existing in IETF to do just that, which is
> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
> > is not really about the lack of a solution, it's more about that some of
> > us just don't want to use the existing IETF solution (for whatever
> > non-tech reasons, or simply just don't wish to use it) and prefer to
> > define another solution in IETF. Well, if that is the case, I don't have
> > much else to say...
> >
> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages
> > related to using SCTP for MEGACO multi-homing support, I'd be more than
> > glad to help answer.
> >
> > -Qiaobing

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



--------------C683F96B128B90D20EEE3924
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>I agree with Flemming that Megaco should be based on UDP and TCP.
<br>SCTP is not widely deployed and can lead to problems of interoperability.
<br>I would leave it as optional.
<p>For me the control association is clearly defined and it is 1 association
= 1 IP address.
<br>Why? Because the assocation is done through a ServiceChange Restart
message which involves
<br>an IP address (in the MGC ID)&nbsp; and not a domain name. If the DNS
returns more than
<br>one IP address for a given name the MG must choose one of them.
<p>What I feel is that the gap is in the definition of the secondary MGCs
and its provisionning.
<br>I think there should be a way in which the MGC could inform the MGs
about existing secondaries
<br>MGCs. Now this can only be done using a&nbsp; HandOff method but sometimes
this message cannot
<br>be sent by the primary MGC (e.g. network failure, crash of the MGC
...).
<br>So it would be useful to add a new method in the ServiceChange to send
this information and add
<br>a new parameter indicating what type of relationship there is between
primary and secondary
<br>(e.g. mirror, backup, independent, third party.....)
<br>So in case a MGC is multihomed it could inform the MG at startup that
a MGC exists which is a
<br>secondary mirror MGC (which corresponds to the same MGC but with another
IP address).
<br>This process can be independent on the actual procedures done by the
operators to declare
<br>secondary MGCs.
<p>When a problem arises the MG can act in two ways:
<br>1) If the new MGC&nbsp;is a mirror (maybe other types can be included
here) it can resend the transactions
<br>which have failed in the old one.
<br>2)&nbsp;If the new MGC is not a mirror it should try to establish a
connection with a ServiceChange as defined
<br>in the megaco protocol. Then the MGC is in charge of recovering the
state of the MG ASAP&nbsp;and the service.
<p>In this way not too much work has to be added and we can accomplish
a solution.
<p>Regards
<br>Fernando
<br>&nbsp;
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>Qiaobing
<p>Nobody is denying that SCTP is an existing spec that solves the multihoming
problem and it
<br>is quite understandable that you in particular advocate it. However,
you seem to have lost
<br>sight of the original question in this thread, which was about native
Megaco protocol
<br>support for redundancy and failover, and as part of that, support for
multihoming. Initial
<br>claims was that Megaco fully supports this, but we seem to have converged
on the opinion
<br>that it does not, unless you use SCTP, which is not part of the base
Megaco protocol.
<br>Furthermore, despite everything, the fact of the matter is that for
various reasons, not
<br>everybody will be implementing SCTP at least for now (NATs, firewalls
and security do not
<br>help SCTP here) and since UDP and TCP are the basic requirements, it
would have been nice to
<br>have better mechanisms for these; it can be done very easily (see MGCP
for example).
<br>Sometimes, it's good to be a bit pragmatic.
<p>-- Flemming
<p>Qiaobing Xie wrote:
<p>> (Try to respond to similar remarks from two mails)
<br>>
<br>> Flemming Andreasen wrote:
<br>> ...
<br>> > In any case, SCTP is there as an option today for those
<br>> > that wish to use it. For those that don't, we've already concluded
that
<br>> > multihoming/redundancy/failover is not very well supported, and
that there doesn't
<br>> > seem to be much desire to change that. I personally think that's
a bit of a shame, but
<br>> > so be it.
<br>> ...
<br>>
<br>> Adrian Soncodi wrote:
<br>> ...
<br>> > You seem to say "if you want multi-homing, it must be only over
SCTP".
<br>> > Why? Someone could similarly say "if you want MEGACO, it must be
over
<br>> > UDP". But we don't, we allow all 3 protocols, for flexibility.
<br>> >
<br>>
<br>> I didn't mean to say "you must". I was under the impression that
some of
<br>> us were saying that we had a technical issue to support multi-homing
in
<br>> MEGACO, and my response was essentially "this is not an issue, there
are
<br>> protocol specs existing in IETF to do just that, which is
<br>> MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is,
it
<br>> is not really about the lack of a solution, it's more about that
some of
<br>> us just don't want to use the existing IETF solution (for whatever
<br>> non-tech reasons, or simply just don't wish to use it) and prefer
to
<br>> define another solution in IETF. Well, if that is the case, I don't
have
<br>> much else to say...
<br>>
<br>> Of cause, if there are tech issues/shortcomings/drawbacks/advantages
<br>> related to using SCTP for MEGACO multi-homing support, I'd be more
than
<br>> glad to help answer.
<br>>
<br>> -Qiaobing</blockquote>

<pre>--&nbsp;
Fernando Vallejo Lazaro
Phone:&nbsp; +34 91 330 5614
SW&nbsp; Wireline ASD-Madrid
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ALCATEL</pre>
&nbsp;</html>

--------------C683F96B128B90D20EEE3924--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Mon Apr 28 18:36:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17625
	for <megaco-archive@lists.ietf.org>; Mon, 28 Apr 2003 18:36:31 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMeo821735;
	Mon, 28 Apr 2003 18:40:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMbW821484
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 18:37:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17549
	for <megaco@ietf.org>; Mon, 28 Apr 2003 18:32:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AHCf-0005sX-00
	for megaco@ietf.org; Mon, 28 Apr 2003 18:34:29 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AHCf-0005sF-00
	for megaco@ietf.org; Mon, 28 Apr 2003 18:34:29 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042817343093:3753 ;
          Mon, 28 Apr 2003 17:34:30 -0500 
Message-ID: <3EADAE09.1010600@tekelec.com>
Date: Mon, 28 Apr 2003 17:41:13 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>
CC: megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/28/2003 05:34:30 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/28/2003 05:35:05 PM,
	Serialize complete at 04/28/2003 05:35:05 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Fernando Vallejo Lazaro wrote:

> Hi,
>
> I agree with Flemming that Megaco should be based on UDP and TCP.
> SCTP is not widely deployed and can lead to problems of interoperability.
> I would leave it as optional.
>
> For me the control association is clearly defined and it is 1 
> association = 1 IP address.
> Why? Because the assocation is done through a ServiceChange Restart 
> message which involves
> an IP address (in the MGC ID)  and not a domain name. If the DNS 
> returns more than
> one IP address for a given name the MG must choose one of them.
>
This is how one would be tempted to interpret the spec today, although 
it is not explicitly stated. But as I have mentioned in a previous 
e-mail, this is not adequate for SCTP, where one would like to know that 
the 2 IP addresses are on the same machine, to be able to use them 
within a single SCTP association.

Also, the following quote from section 7.2.8 seems to indicate more than 
1 IP address is possible:

  "The ServiceChangeAddress provides an address to be used within the 
Context of the association currently being negotiated ..."

Since this is in the reply to ServiceChange, it looks like it can 
actually be a different IP address (which then must be interpreted in 
the context of the current association ...). Otherwise, why would the 
MGC return the same IP address as the destination IP address of the 
ServiceChange message? The MG already knows that one!

> What I feel is that the gap is in the definition of the secondary MGCs 
> and its provisionning.
> I think there should be a way in which the MGC could inform the MGs 
> about existing secondaries
> MGCs. Now this can only be done using a  HandOff method but sometimes 
> this message cannot
> be sent by the primary MGC (e.g. network failure, crash of the MGC ...).
> So it would be useful to add a new method in the ServiceChange to send 
> this information and add
> a new parameter indicating what type of relationship there is between 
> primary and secondary
> (e.g. mirror, backup, independent, third party.....)
> So in case a MGC is multihomed it could inform the MG at startup that 
> a MGC exists which is a
> secondary mirror MGC (which corresponds to the same MGC but with 
> another IP address).
> This process can be independent on the actual procedures done by the 
> operators to declare
> secondary MGCs.
>
I'm not sure a "mirror MGC" is the same MGC with another IP address. 
Some people would interpret "mirrored" as different machines, with some 
state synchronization between them...

Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP 
addresses, and if each IP address is a different MGC, then it becomes 
quite cumbersome to signal which one is paired with which one. I think 
it would be simpler and more clear to allow an MG to be provisioned with 
more than one IP address per MGC. Then you would immediately know the 
MGC is multi-homed. This works more elegantly with SCTP, and also with 
DNS, which can return several IP addresses for an FQDN.

Adrian

> When a problem arises the MG can act in two ways:
> 1) If the new MGC is a mirror (maybe other types can be included here) 
> it can resend the transactions
> which have failed in the old one.
> 2) If the new MGC is not a mirror it should try to establish a 
> connection with a ServiceChange as defined
> in the megaco protocol. Then the MGC is in charge of recovering the 
> state of the MG ASAP and the service.
>
> In this way not too much work has to be added and we can accomplish a 
> solution.
>
> Regards
> Fernando
>  
>
> Flemming Andreasen wrote:
>
>> Qiaobing
>>
>> Nobody is denying that SCTP is an existing spec that solves the 
>> multihoming problem and it
>> is quite understandable that you in particular advocate it. However, 
>> you seem to have lost
>> sight of the original question in this thread, which was about native 
>> Megaco protocol
>> support for redundancy and failover, and as part of that, support for 
>> multihoming. Initial
>> claims was that Megaco fully supports this, but we seem to have 
>> converged on the opinion
>> that it does not, unless you use SCTP, which is not part of the base 
>> Megaco protocol.
>> Furthermore, despite everything, the fact of the matter is that for 
>> various reasons, not
>> everybody will be implementing SCTP at least for now (NATs, firewalls 
>> and security do not
>> help SCTP here) and since UDP and TCP are the basic requirements, it 
>> would have been nice to
>> have better mechanisms for these; it can be done very easily (see 
>> MGCP for example).
>> Sometimes, it's good to be a bit pragmatic.
>>
>> -- Flemming
>>
>> Qiaobing Xie wrote:
>>
>> > (Try to respond to similar remarks from two mails)
>> >
>> > Flemming Andreasen wrote:
>> > ...
>> > > In any case, SCTP is there as an option today for those
>> > > that wish to use it. For those that don't, we've already 
>> concluded that
>> > > multihoming/redundancy/failover is not very well supported, and 
>> that there doesn't
>> > > seem to be much desire to change that. I personally think that's 
>> a bit of a shame, but
>> > > so be it.
>> > ...
>> >
>> > Adrian Soncodi wrote:
>> > ...
>> > > You seem to say "if you want multi-homing, it must be only over 
>> SCTP".
>> > > Why? Someone could similarly say "if you want MEGACO, it must be 
>> over
>> > > UDP". But we don't, we allow all 3 protocols, for flexibility.
>> > >
>> >
>> > I didn't mean to say "you must". I was under the impression that 
>> some of
>> > us were saying that we had a technical issue to support 
>> multi-homing in
>> > MEGACO, and my response was essentially "this is not an issue, 
>> there are
>> > protocol specs existing in IETF to do just that, which is
>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
>> > is not really about the lack of a solution, it's more about that 
>> some of
>> > us just don't want to use the existing IETF solution (for whatever
>> > non-tech reasons, or simply just don't wish to use it) and prefer to
>> > define another solution in IETF. Well, if that is the case, I don't 
>> have
>> > much else to say...
>> >
>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages
>> > related to using SCTP for MEGACO multi-homing support, I'd be more 
>> than
>> > glad to help answer.
>> >
>> > -Qiaobing
>>
>-- 
>Fernando Vallejo Lazaro
>Phone:  +34 91 330 5614
>SW  Wireline ASD-Madrid
>       ALCATEL
>
>  



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Mon Apr 28 18:38:31 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17667
	for <megaco-archive@odin.ietf.org>; Mon, 28 Apr 2003 18:38:30 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3SMhGf21802
	for megaco-archive@odin.ietf.org; Mon, 28 Apr 2003 18:43:16 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMhG821799
	for <megaco-web-archive@optimus.ietf.org>; Mon, 28 Apr 2003 18:43:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17648
	for <megaco-web-archive@ietf.org>; Mon, 28 Apr 2003 18:37:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AHHt-0005tZ-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 18:39:53 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AHHY-0005tQ-00
	for megaco-web-archive@ietf.org; Mon, 28 Apr 2003 18:39:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMeo821735;
	Mon, 28 Apr 2003 18:40:50 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SMbW821484
	for <megaco@optimus.ietf.org>; Mon, 28 Apr 2003 18:37:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17549
	for <megaco@ietf.org>; Mon, 28 Apr 2003 18:32:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AHCf-0005sX-00
	for megaco@ietf.org; Mon, 28 Apr 2003 18:34:29 -0400
Received: from [192.153.124.130] (helo=ntserv10.tx.tekelec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AHCf-0005sF-00
	for megaco@ietf.org; Mon, 28 Apr 2003 18:34:29 -0400
Received: from tekelec.com ([172.25.11.41])
          by ntserv10.tx.tekelec.com (Lotus Domino Release 5.0.12)
          with ESMTP id 2003042817343093:3753 ;
          Mon, 28 Apr 2003 17:34:30 -0500 
Message-ID: <3EADAE09.1010600@tekelec.com>
Date: Mon, 28 Apr 2003 17:41:13 -0500
From: Adrian Soncodi <adrian.soncodi@tekelec.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Fernando Vallejo Lazaro <Fernando.Vallejo_Lazaro@alcatel.es>
CC: megaco@ietf.org
Subject: Re: [Megaco] Support for redundant MG failover
References: <ABA227A15B80D511BD1A00508BF93A1C08E99751@zrtpd0jq.us.nortel.com> <3EA83F74.9070100@tekelec.com> <3EA86D8F.40730808@motorola.com> <3EA87EFA.A9940931@cisco.com> <3EA88D01.5EA8AF1D@motorola.com> <3EA92F29.93F0F95D@cisco.com> <3EA98F66.C6890B54@motorola.com> <3EA99A2E.4DC6BD7D@cisco.com> <3EA9DC82.136119A3@motorola.com> <3EA9F2B5.FEBAA43@cisco.com> <3EACEC44.96FF416A@alcatel.es>
X-MIMETrack: Itemize by SMTP Server on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/28/2003 05:34:30 PM,
	Serialize by Router on NTServ10/Richardson/TEKELEC(Release 5.0.12  |February
 13, 2003) at 04/28/2003 05:35:05 PM,
	Serialize complete at 04/28/2003 05:35:05 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Fernando Vallejo Lazaro wrote:

> Hi,
>
> I agree with Flemming that Megaco should be based on UDP and TCP.
> SCTP is not widely deployed and can lead to problems of interoperability.
> I would leave it as optional.
>
> For me the control association is clearly defined and it is 1 
> association = 1 IP address.
> Why? Because the assocation is done through a ServiceChange Restart 
> message which involves
> an IP address (in the MGC ID)  and not a domain name. If the DNS 
> returns more than
> one IP address for a given name the MG must choose one of them.
>
This is how one would be tempted to interpret the spec today, although 
it is not explicitly stated. But as I have mentioned in a previous 
e-mail, this is not adequate for SCTP, where one would like to know that 
the 2 IP addresses are on the same machine, to be able to use them 
within a single SCTP association.

Also, the following quote from section 7.2.8 seems to indicate more than 
1 IP address is possible:

  "The ServiceChangeAddress provides an address to be used within the 
Context of the association currently being negotiated ..."

Since this is in the reply to ServiceChange, it looks like it can 
actually be a different IP address (which then must be interpreted in 
the context of the current association ...). Otherwise, why would the 
MGC return the same IP address as the destination IP address of the 
ServiceChange message? The MG already knows that one!

> What I feel is that the gap is in the definition of the secondary MGCs 
> and its provisionning.
> I think there should be a way in which the MGC could inform the MGs 
> about existing secondaries
> MGCs. Now this can only be done using a  HandOff method but sometimes 
> this message cannot
> be sent by the primary MGC (e.g. network failure, crash of the MGC ...).
> So it would be useful to add a new method in the ServiceChange to send 
> this information and add
> a new parameter indicating what type of relationship there is between 
> primary and secondary
> (e.g. mirror, backup, independent, third party.....)
> So in case a MGC is multihomed it could inform the MG at startup that 
> a MGC exists which is a
> secondary mirror MGC (which corresponds to the same MGC but with 
> another IP address).
> This process can be independent on the actual procedures done by the 
> operators to declare
> secondary MGCs.
>
I'm not sure a "mirror MGC" is the same MGC with another IP address. 
Some people would interpret "mirrored" as different machines, with some 
state synchronization between them...

Anyway, considering 2 or more multi-homed MGCs, i.e. 4 or more IP 
addresses, and if each IP address is a different MGC, then it becomes 
quite cumbersome to signal which one is paired with which one. I think 
it would be simpler and more clear to allow an MG to be provisioned with 
more than one IP address per MGC. Then you would immediately know the 
MGC is multi-homed. This works more elegantly with SCTP, and also with 
DNS, which can return several IP addresses for an FQDN.

Adrian

> When a problem arises the MG can act in two ways:
> 1) If the new MGC is a mirror (maybe other types can be included here) 
> it can resend the transactions
> which have failed in the old one.
> 2) If the new MGC is not a mirror it should try to establish a 
> connection with a ServiceChange as defined
> in the megaco protocol. Then the MGC is in charge of recovering the 
> state of the MG ASAP and the service.
>
> In this way not too much work has to be added and we can accomplish a 
> solution.
>
> Regards
> Fernando
>  
>
> Flemming Andreasen wrote:
>
>> Qiaobing
>>
>> Nobody is denying that SCTP is an existing spec that solves the 
>> multihoming problem and it
>> is quite understandable that you in particular advocate it. However, 
>> you seem to have lost
>> sight of the original question in this thread, which was about native 
>> Megaco protocol
>> support for redundancy and failover, and as part of that, support for 
>> multihoming. Initial
>> claims was that Megaco fully supports this, but we seem to have 
>> converged on the opinion
>> that it does not, unless you use SCTP, which is not part of the base 
>> Megaco protocol.
>> Furthermore, despite everything, the fact of the matter is that for 
>> various reasons, not
>> everybody will be implementing SCTP at least for now (NATs, firewalls 
>> and security do not
>> help SCTP here) and since UDP and TCP are the basic requirements, it 
>> would have been nice to
>> have better mechanisms for these; it can be done very easily (see 
>> MGCP for example).
>> Sometimes, it's good to be a bit pragmatic.
>>
>> -- Flemming
>>
>> Qiaobing Xie wrote:
>>
>> > (Try to respond to similar remarks from two mails)
>> >
>> > Flemming Andreasen wrote:
>> > ...
>> > > In any case, SCTP is there as an option today for those
>> > > that wish to use it. For those that don't, we've already 
>> concluded that
>> > > multihoming/redundancy/failover is not very well supported, and 
>> that there doesn't
>> > > seem to be much desire to change that. I personally think that's 
>> a bit of a shame, but
>> > > so be it.
>> > ...
>> >
>> > Adrian Soncodi wrote:
>> > ...
>> > > You seem to say "if you want multi-homing, it must be only over 
>> SCTP".
>> > > Why? Someone could similarly say "if you want MEGACO, it must be 
>> over
>> > > UDP". But we don't, we allow all 3 protocols, for flexibility.
>> > >
>> >
>> > I didn't mean to say "you must". I was under the impression that 
>> some of
>> > us were saying that we had a technical issue to support 
>> multi-homing in
>> > MEGACO, and my response was essentially "this is not an issue, 
>> there are
>> > protocol specs existing in IETF to do just that, which is
>> > MEGACO/H.248-Annex-H plus SCTP." Now, I think what I am hearing is, it
>> > is not really about the lack of a solution, it's more about that 
>> some of
>> > us just don't want to use the existing IETF solution (for whatever
>> > non-tech reasons, or simply just don't wish to use it) and prefer to
>> > define another solution in IETF. Well, if that is the case, I don't 
>> have
>> > much else to say...
>> >
>> > Of cause, if there are tech issues/shortcomings/drawbacks/advantages
>> > related to using SCTP for MEGACO multi-homing support, I'd be more 
>> than
>> > glad to help answer.
>> >
>> > -Qiaobing
>>
>-- 
>Fernando Vallejo Lazaro
>Phone:  +34 91 330 5614
>SW  Wireline ASD-Madrid
>       ALCATEL
>
>  



_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 29 00:18:10 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24285
	for <megaco-archive@lists.ietf.org>; Tue, 29 Apr 2003 00:18:10 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T4MM815302;
	Tue, 29 Apr 2003 00:22:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T4JE815224
	for <megaco@optimus.ietf.org>; Tue, 29 Apr 2003 00:19:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24223
	for <Megaco@ietf.org>; Tue, 29 Apr 2003 00:13:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AMXE-0007bu-00
	for Megaco@ietf.org; Tue, 29 Apr 2003 00:16:04 -0400
Received: from auds951.usa.alcatel.com ([143.209.238.80])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AMXE-0007bq-00
	for Megaco@ietf.org; Tue, 29 Apr 2003 00:16:04 -0400
Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h3T4G7U2004219
	for <Megaco@ietf.org>; Mon, 28 Apr 2003 23:16:08 -0500 (CDT)
Received: from axsppc20 by axes-mach01.axes-mach01.usa.alcatel.com (8.9.3+Sun/SMI-SVR4)
	id IAA02085; Tue, 29 Apr 2003 08:44:56 -0500 (GMT)
Message-ID: <042001c30e06$f254eb30$4601ff0a@axsppc20>
From: "mahaveer" <mahaveer@axes-mach01.usa.alcatel.com>
To: <Megaco@ietf.org>
Date: Tue, 29 Apr 2003 09:52:23 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_041D_01C30E35.08A19A90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [Megaco] Unsubscribe
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_041D_01C30E35.08A19A90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


MAHAVEER. K. RAJANNAVAR

Axes Technologies (I) Pvt. Ltd.
Blue Chip Software Technologies Park
9/7,Hosur Road
Bangalore - 560 029
Ph : 91-80-553 9232/33
Extn : 1239
    =20


------=_NextPart_000_041D_01C30E35.08A19A90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>MAHAVEER. K. RAJANNAVAR</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Axes Technologies (I) Pvt. Ltd.<BR>Blue =
Chip=20
Software Technologies Park<BR>9/7,Hosur Road<BR>Bangalore - 560 =
029<BR>Ph :=20
91-80-553 9232/33<BR>Extn : 1239<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_041D_01C30E35.08A19A90--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 29 00:19:14 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24308
	for <megaco-archive@odin.ietf.org>; Tue, 29 Apr 2003 00:19:14 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3T4O6w15364
	for megaco-archive@odin.ietf.org; Tue, 29 Apr 2003 00:24:06 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T4O6815361
	for <megaco-web-archive@optimus.ietf.org>; Tue, 29 Apr 2003 00:24:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24305
	for <megaco-web-archive@ietf.org>; Tue, 29 Apr 2003 00:18:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AMbw-0007d3-00
	for megaco-web-archive@ietf.org; Tue, 29 Apr 2003 00:20:56 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AMbw-0007d0-00
	for megaco-web-archive@ietf.org; Tue, 29 Apr 2003 00:20:56 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T4MM815302;
	Tue, 29 Apr 2003 00:22:22 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T4JE815224
	for <megaco@optimus.ietf.org>; Tue, 29 Apr 2003 00:19:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24223
	for <Megaco@ietf.org>; Tue, 29 Apr 2003 00:13:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AMXE-0007bu-00
	for Megaco@ietf.org; Tue, 29 Apr 2003 00:16:04 -0400
Received: from auds951.usa.alcatel.com ([143.209.238.80])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AMXE-0007bq-00
	for Megaco@ietf.org; Tue, 29 Apr 2003 00:16:04 -0400
Received: from axes-mach01.axes-mach01.usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h3T4G7U2004219
	for <Megaco@ietf.org>; Mon, 28 Apr 2003 23:16:08 -0500 (CDT)
Received: from axsppc20 by axes-mach01.axes-mach01.usa.alcatel.com (8.9.3+Sun/SMI-SVR4)
	id IAA02085; Tue, 29 Apr 2003 08:44:56 -0500 (GMT)
Message-ID: <042001c30e06$f254eb30$4601ff0a@axsppc20>
From: "mahaveer" <mahaveer@axes-mach01.usa.alcatel.com>
To: <Megaco@ietf.org>
Date: Tue, 29 Apr 2003 09:52:23 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_041D_01C30E35.08A19A90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [Megaco] Unsubscribe
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_041D_01C30E35.08A19A90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


MAHAVEER. K. RAJANNAVAR

Axes Technologies (I) Pvt. Ltd.
Blue Chip Software Technologies Park
9/7,Hosur Road
Bangalore - 560 029
Ph : 91-80-553 9232/33
Extn : 1239
    =20


------=_NextPart_000_041D_01C30E35.08A19A90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>MAHAVEER. K. RAJANNAVAR</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Axes Technologies (I) Pvt. Ltd.<BR>Blue =
Chip=20
Software Technologies Park<BR>9/7,Hosur Road<BR>Bangalore - 560 =
029<BR>Ph :=20
91-80-553 9232/33<BR>Extn : 1239<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_041D_01C30E35.08A19A90--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Tue Apr 29 18:46:34 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15503
	for <megaco-archive@lists.ietf.org>; Tue, 29 Apr 2003 18:46:34 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TMog801422;
	Tue, 29 Apr 2003 18:50:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TMkm801258
	for <megaco@optimus.ietf.org>; Tue, 29 Apr 2003 18:46:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15181
	for <megaco@ietf.org>; Tue, 29 Apr 2003 18:41:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Adoh-00015K-00
	for megaco@ietf.org; Tue, 29 Apr 2003 18:43:15 -0400
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Adoh-00014x-00
	for megaco@ietf.org; Tue, 29 Apr 2003 18:43:15 -0400
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TMhLH07740
	for <megaco@ietf.org>; Tue, 29 Apr 2003 18:43:21 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA17626; Tue, 29 Apr 2003 18:43:20 -0400 (EDT)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA17622; Tue, 29 Apr 2003 18:43:19 -0400 (EDT)
Message-ID: <3EAEFF21.5030500@bell-labs.com>
Date: Tue, 29 Apr 2003 18:39:29 -0400
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Small MDMF bug and questions in AVD-2313 (and draft-boyle-megaco-alerting-03.txt)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


In section 7.5 of AVD-2313, the following example is used 3 times:

 > 
Signals{andisp/dwa{ddb=802301083035313831363135020A3931393535353030303007084A6F686E20446F65D5,pattern=1}}

I believe there is a small bug in the example's MDMF.

Referencing GR-30-CORE,

> R2-60 [56]The message length word in MDMF shall contain the 8-bit binary
> representation of the number of words in the message following it,
> excluding the checksum word. For MDMF, the message length shall
> be equal to the total number of parameter type words, parameter
> length words, and parameter data words.

I believe the example calls for a MDMF length word of 20 (hex)
not 23 (hex) and the string should start ddb=8020...




Also, regarding the ddb parameter, AVD-2313 says:

> The Display Data Block contains the message data to be sent to the set. 
> Binary encoding is the binary data itself, while text encoding shall carry 
> the data as a hex string.  For example, in North America for basic Caller ID, 
> this would be the SDMF or MDMF construct. 


This tells us two things the "ddb" parameter might be, but doesn't 
strictly restrict the possibilities.

Is this limited to CND, CNAM, and CIDCW uses of SDMF & MDMF as
defined by Telcordia?  If not, how does a MG distinguish between
these, other uses of SDMF & MDMF, or things that aren't SDMF or MDMF?


Similar questions could be asked of the "db" parameter of "andisp/data",
which references ADSI, etc., but not SDMF or MDMF.  I have no idea
how "Short Message Service", or "Advice of Charge" are encoded.
(Document references?)  Are they SDMF or MDMF?  Can an MG distinguish
them from something else?  Is this field limited in any way?


Also, regarding the "andisp/dwa" signal:

> 7.3.1	Display with Alerting
> SignalID: dwa (0x0004)
> Sends the display info to the CPE display, if the set is so equipped. 
> This signal indicates that the data must be applied during alerting -- 
> either power ringing, or call waiting. Therefore, this signal implies 
> alerting, which will be appropriately applied to the CPE by the gateway, 
> based upon the on-hook/off-hook status of the line.

I suggest stating that the implied alerting happens even when the
MG is not "equipped" to send display info.

-troy






_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Tue Apr 29 18:47:39 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15559
	for <megaco-archive@odin.ietf.org>; Tue, 29 Apr 2003 18:47:39 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3TMqrw01558
	for megaco-archive@odin.ietf.org; Tue, 29 Apr 2003 18:52:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TMqr801555
	for <megaco-web-archive@optimus.ietf.org>; Tue, 29 Apr 2003 18:52:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15549
	for <megaco-web-archive@ietf.org>; Tue, 29 Apr 2003 18:47:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AduZ-0001Af-00
	for megaco-web-archive@ietf.org; Tue, 29 Apr 2003 18:49:20 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AduZ-0001Ab-00
	for megaco-web-archive@ietf.org; Tue, 29 Apr 2003 18:49:19 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TMog801422;
	Tue, 29 Apr 2003 18:50:42 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TMkm801258
	for <megaco@optimus.ietf.org>; Tue, 29 Apr 2003 18:46:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15181
	for <megaco@ietf.org>; Tue, 29 Apr 2003 18:41:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Adoh-00015K-00
	for megaco@ietf.org; Tue, 29 Apr 2003 18:43:15 -0400
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Adoh-00014x-00
	for megaco@ietf.org; Tue, 29 Apr 2003 18:43:15 -0400
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TMhLH07740
	for <megaco@ietf.org>; Tue, 29 Apr 2003 18:43:21 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA17626; Tue, 29 Apr 2003 18:43:20 -0400 (EDT)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id SAA17622; Tue, 29 Apr 2003 18:43:19 -0400 (EDT)
Message-ID: <3EAEFF21.5030500@bell-labs.com>
Date: Tue, 29 Apr 2003 18:39:29 -0400
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] Small MDMF bug and questions in AVD-2313 (and draft-boyle-megaco-alerting-03.txt)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


In section 7.5 of AVD-2313, the following example is used 3 times:

 > 
Signals{andisp/dwa{ddb=802301083035313831363135020A3931393535353030303007084A6F686E20446F65D5,pattern=1}}

I believe there is a small bug in the example's MDMF.

Referencing GR-30-CORE,

> R2-60 [56]The message length word in MDMF shall contain the 8-bit binary
> representation of the number of words in the message following it,
> excluding the checksum word. For MDMF, the message length shall
> be equal to the total number of parameter type words, parameter
> length words, and parameter data words.

I believe the example calls for a MDMF length word of 20 (hex)
not 23 (hex) and the string should start ddb=8020...




Also, regarding the ddb parameter, AVD-2313 says:

> The Display Data Block contains the message data to be sent to the set. 
> Binary encoding is the binary data itself, while text encoding shall carry 
> the data as a hex string.  For example, in North America for basic Caller ID, 
> this would be the SDMF or MDMF construct. 


This tells us two things the "ddb" parameter might be, but doesn't 
strictly restrict the possibilities.

Is this limited to CND, CNAM, and CIDCW uses of SDMF & MDMF as
defined by Telcordia?  If not, how does a MG distinguish between
these, other uses of SDMF & MDMF, or things that aren't SDMF or MDMF?


Similar questions could be asked of the "db" parameter of "andisp/data",
which references ADSI, etc., but not SDMF or MDMF.  I have no idea
how "Short Message Service", or "Advice of Charge" are encoded.
(Document references?)  Are they SDMF or MDMF?  Can an MG distinguish
them from something else?  Is this field limited in any way?


Also, regarding the "andisp/dwa" signal:

> 7.3.1	Display with Alerting
> SignalID: dwa (0x0004)
> Sends the display info to the CPE display, if the set is so equipped. 
> This signal indicates that the data must be applied during alerting -- 
> either power ringing, or call waiting. Therefore, this signal implies 
> alerting, which will be appropriately applied to the CPE by the gateway, 
> based upon the on-hook/off-hook status of the line.

I suggest stating that the implied alerting happens even when the
MG is not "equipped" to send display info.

-troy






_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 30 06:33:56 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27834
	for <megaco-archive@lists.ietf.org>; Wed, 30 Apr 2003 06:33:56 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAcq803949;
	Wed, 30 Apr 2003 06:38:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAZI802800
	for <megaco@optimus.ietf.org>; Wed, 30 Apr 2003 06:35:18 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27574;
	Wed, 30 Apr 2003 06:29:17 -0400 (EDT)
Message-Id: <200304301029.GAA27574@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: megaco@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 30 Apr 2003 06:29:16 -0400
Subject: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

	Title		: Megaco MIB
	Author(s)	: B. Pitchandi, I. Akramovich, C. Brown, M. Holdrege
	Filename	: draft-ietf-megaco-mib-05.txt
	Pages		: 35
	Date		: 2003-4-29
	
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for use by the MEGACO/H.248 protocol operating on Media Gateways and Media Gateway Controllers. These objects can be used to manage the network containing Media Gateways and Media Gateway Controllers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-megaco-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-megaco-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-29164435.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-megaco-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-29164435.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 30 06:35:01 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27874
	for <megaco-archive@odin.ietf.org>; Wed, 30 Apr 2003 06:35:01 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UAeVL04262
	for megaco-archive@odin.ietf.org; Wed, 30 Apr 2003 06:40:31 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAeV804259
	for <megaco-web-archive@optimus.ietf.org>; Wed, 30 Apr 2003 06:40:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27861
	for <megaco-web-archive@ietf.org>; Wed, 30 Apr 2003 06:34:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Aox9-0005rW-00
	for megaco-web-archive@ietf.org; Wed, 30 Apr 2003 06:36:43 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Aox8-0005rT-00
	for megaco-web-archive@ietf.org; Wed, 30 Apr 2003 06:36:42 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAcq803949;
	Wed, 30 Apr 2003 06:38:52 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UAZI802800
	for <megaco@optimus.ietf.org>; Wed, 30 Apr 2003 06:35:18 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27574;
	Wed, 30 Apr 2003 06:29:17 -0400 (EDT)
Message-Id: <200304301029.GAA27574@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: megaco@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 30 Apr 2003 06:29:16 -0400
Subject: [Megaco] I-D ACTION:draft-ietf-megaco-mib-05.txt
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

	Title		: Megaco MIB
	Author(s)	: B. Pitchandi, I. Akramovich, C. Brown, M. Holdrege
	Filename	: draft-ietf-megaco-mib-05.txt
	Pages		: 35
	Date		: 2003-4-29
	
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for use by the MEGACO/H.248 protocol operating on Media Gateways and Media Gateway Controllers. These objects can be used to manage the network containing Media Gateways and Media Gateway Controllers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-mib-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-megaco-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-megaco-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-4-29164435.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-mib-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-megaco-mib-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-4-29164435.I-D@ietf.org>

--OtherAccess--

--NextPart--


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco



From megaco-admin@ietf.org  Wed Apr 30 14:04:02 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15246
	for <megaco-archive@lists.ietf.org>; Wed, 30 Apr 2003 14:04:02 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UI8O827138;
	Wed, 30 Apr 2003 14:08:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UI6C825823
	for <megaco@optimus.ietf.org>; Wed, 30 Apr 2003 14:06:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15078
	for <megaco@ietf.org>; Wed, 30 Apr 2003 14:00:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvuI-00026q-00
	for megaco@ietf.org; Wed, 30 Apr 2003 14:02:15 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvuI-00026n-00
	for megaco@ietf.org; Wed, 30 Apr 2003 14:02:14 -0400
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UI2Lg28472
	for <megaco@ietf.org>; Wed, 30 Apr 2003 14:02:21 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA26299; Wed, 30 Apr 2003 14:02:18 -0400 (EDT)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA26295; Wed, 30 Apr 2003 14:02:18 -0400 (EDT)
Message-ID: <3EB00EC3.6020702@bell-labs.com>
Date: Wed, 30 Apr 2003 13:58:27 -0400
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] more problems with AVD-2313 (and draft-boyle-megaco-alerting-03.txt)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Consider the following two parameters.

> ParameterID: ddb (0x0001)
> Type: String
> Possible values: See description
> Description: The Display Data Block contains the message data 
> to be sent to the set. Binary encoding is the binary data itself, 
> while text encoding shall carry the data as a hex string.


> ParameterID: db (0x0001)
> Type: String
> Possible values: See description
> Description: The Data Block contains the message data to be 
> sent to the set. Binary encoding is the binary data itself, 
> while text encoding shall carry the data as a hex string.  


The descriptions of the encondings (and the examples in the document)
conflict with the meaning of "Type: String" as defined
in H.248.1 v1 and v2 which state in Annex A that a "String"
is encoded as an IA5String or UTF8String, and in Annex B that
a "String" MUST use the quotedString form.

In my opinion, the intent of the sections in Annex A and B
that specify the encodings of VALUEs was to create encoding
rules that would allow the translation of VALUEs between
ASN.1 and text forms knowing only the Type (String, etc.) and
not requiring detailed package knowledge.
(At least that was my intent when I helped write those sections.)

This means that packages MUST NOT specify things like it's
a String and in text form it will contain *this* and in
binary form it will contain *that*.  Simply say it's a
String containing *this*; H.248.1 specifies how to
encode for the text and ASN.1 cases.


The parameters in question could remain type "String" (containing
the Hex encoding of binary data), but that would require quotes
in the examples and, more significantly, lead to a silly
ASN.1 encoding of the hex string within IA5String form.

A better match is the type "Octet String" which is defined for ASN.1
in Annex A, but unfortunately ommited in Annex B.  I guess it would
require a (modification/clarification/IG entry?) to Annex B describing
how the "Octet String" Types are encoded for the text form (hex encoding).

Note that Annex B does define Hexadecimal octet coding, but it
1) doesn't tell us where it might be used, and
2) specifies LSB first (!?!).

-troy




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco


From mailnull@www1.ietf.org  Wed Apr 30 14:05:09 2003
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15281
	for <megaco-archive@odin.ietf.org>; Wed, 30 Apr 2003 14:05:09 -0400 (EDT)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id h3UIAle27643
	for megaco-archive@odin.ietf.org; Wed, 30 Apr 2003 14:10:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UIAl827640
	for <megaco-web-archive@optimus.ietf.org>; Wed, 30 Apr 2003 14:10:47 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15262
	for <megaco-web-archive@ietf.org>; Wed, 30 Apr 2003 14:04:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19Avyj-000291-00
	for megaco-web-archive@ietf.org; Wed, 30 Apr 2003 14:06:49 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 19Avyi-00028y-00
	for megaco-web-archive@ietf.org; Wed, 30 Apr 2003 14:06:48 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UI8O827138;
	Wed, 30 Apr 2003 14:08:24 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UI6C825823
	for <megaco@optimus.ietf.org>; Wed, 30 Apr 2003 14:06:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15078
	for <megaco@ietf.org>; Wed, 30 Apr 2003 14:00:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvuI-00026q-00
	for megaco@ietf.org; Wed, 30 Apr 2003 14:02:15 -0400
Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 19AvuI-00026n-00
	for megaco@ietf.org; Wed, 30 Apr 2003 14:02:14 -0400
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3])
	by ihemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UI2Lg28472
	for <megaco@ietf.org>; Wed, 30 Apr 2003 14:02:21 -0400 (EDT)
Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA26299; Wed, 30 Apr 2003 14:02:18 -0400 (EDT)
Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2)
	id OAA26295; Wed, 30 Apr 2003 14:02:18 -0400 (EDT)
Message-ID: <3EB00EC3.6020702@bell-labs.com>
Date: Wed, 30 Apr 2003 13:58:27 -0400
From: Troy Cauble <troy@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MEGACO list <megaco@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Megaco] more problems with AVD-2313 (and draft-boyle-megaco-alerting-03.txt)
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Id: Media Gateway Control <megaco.ietf.org>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/megaco>,
	<mailto:megaco-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Consider the following two parameters.

> ParameterID: ddb (0x0001)
> Type: String
> Possible values: See description
> Description: The Display Data Block contains the message data 
> to be sent to the set. Binary encoding is the binary data itself, 
> while text encoding shall carry the data as a hex string.


> ParameterID: db (0x0001)
> Type: String
> Possible values: See description
> Description: The Data Block contains the message data to be 
> sent to the set. Binary encoding is the binary data itself, 
> while text encoding shall carry the data as a hex string.  


The descriptions of the encondings (and the examples in the document)
conflict with the meaning of "Type: String" as defined
in H.248.1 v1 and v2 which state in Annex A that a "String"
is encoded as an IA5String or UTF8String, and in Annex B that
a "String" MUST use the quotedString form.

In my opinion, the intent of the sections in Annex A and B
that specify the encodings of VALUEs was to create encoding
rules that would allow the translation of VALUEs between
ASN.1 and text forms knowing only the Type (String, etc.) and
not requiring detailed package knowledge.
(At least that was my intent when I helped write those sections.)

This means that packages MUST NOT specify things like it's
a String and in text form it will contain *this* and in
binary form it will contain *that*.  Simply say it's a
String containing *this*; H.248.1 specifies how to
encode for the text and ASN.1 cases.


The parameters in question could remain type "String" (containing
the Hex encoding of binary data), but that would require quotes
in the examples and, more significantly, lead to a silly
ASN.1 encoding of the hex string within IA5String form.

A better match is the type "Octet String" which is defined for ASN.1
in Annex A, but unfortunately ommited in Annex B.  I guess it would
require a (modification/clarification/IG entry?) to Annex B describing
how the "Octet String" Types are encoded for the text form (hex encoding).

Note that Annex B does define Hexadecimal octet coding, but it
1) doesn't tell us where it might be used, and
2) specifies LSB first (!?!).

-troy




_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco