From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Jul 2 23:41:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14459 for ; Sun, 2 Jul 2000 23:41:08 -0400 (EDT) Received: from standards (47.234.32.16:2785) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A570@standards.nortelnetworks.com>; 2 Jul 2000 23:30:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4511 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 2 Jul 2000 23:30:30 -0400 Received: from mail.in.huawei.com (203.197.168.165:4106) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A56F@standards.nortelnetworks.com>; 2 Jul 2000 23:20:28 -0400 Received: from richietemp (RICHIE [10.118.147.98]) by mail.in.huawei.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N87GN75V; Mon, 3 Jul 2000 09:10:05 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01BFE4CD.00710A20" 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 Message-ID: <001b01bfe49e$f2c621e0$6293760a@richietemp> Date: Mon, 3 Jul 2000 08:59:31 +0530 Reply-To: Richie Sender: "Media Gateway Control (megaco)" From: Richie Subject: Command Ids and Descriptor IDs in the ASN.1 descriptions? To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0018_01BFE4CD.00710A20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbCB0aGUgbGlzdDoNCg0KSW4gQS4xIHN5bnRheCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBI LjI0OCBwcm90b2NvbCBzeW50YXguDQoNCkFmdGVyIGRlY29kaW5nIEJFUiwgaG93IHdpbGwgd2Ug a25vdyB3aGF0IGNvbW1hbmQgdHlwZSBvZiBJRCBpdCBpcz8NCg0KQWxzbyBob3cgd2lsbCB3ZSBr bm93IHdoYXQgZGVzY3JpcHRvciBzZXF1ZW5jZSBpcyBwcmVzZW50IGluIGVhY2ggY29tbWFuZCwg aS5lLiBEZXNjcmlwdG9yDQpJZCBvZiBUeXBlID8NCg0KVGh1cyANCkFtbVJlcXVlc3QgOjo9IFNF UVVFTkNFDQp7DQogICAgdGVybWluYXRpb25JRCAgICBUZXJtaW5hdGlvbklETGlzdCwNCiAgICBk ZXNjcmlwdG9ycyAgICBTRVFVRU5DRSBPRiBhbW1EZXNjcmlwdG9yLA0KICAgIC4uLg0KfQ0KDQpz aG91bGQgYmU6DQoNCkFtbVJlcXVlc3QgOjo9IFNFUVVFTkNFDQp7DQogICAgY29tbWFuZCAgICAg ICAgICAgICAgY29tbWFuZFR5ZXANCiAgICB0ZXJtaW5hdGlvbklEICAgICAgICBUZXJtaW5hdGlv bklETGlzdCwNCiAgICBkZXNjcmlwdG9ycyAgICAgICAgICBTRVFVRU5DRSBPRiBhbW1EZXNjcmlw dG9yLA0KICAgIC4uLg0KfQ0KDQp0aGUgc2FtZSBhcyBkZXNjcmlwdG9ycy4NCg0KDQoNCg0K ------=_NextPart_000_0018_01BFE4CD.00710A20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSwgYWxsIHRoZSBsaXN0 OjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPkluIEEuMSBzeW50YXggc3BlY2lmaWNhdGlvbiBvZiB0aGUgSC4yNDgg cHJvdG9jb2wgDQpzeW50YXguPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPkFmdGVyIGRlY29kaW5nIEJFUiwgaG93IHdpbGwgd2Uga25vdyB3aGF0IGNv bW1hbmQgdHlwZSBvZiBJRCANCml0IGlzPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj5BbHNvIGhvdyB3aWxsIHdlIGtub3cgd2hhdCBkZXNjcmlwdG9y IHNlcXVlbmNlIGlzIHByZXNlbnQgaW4gDQplYWNoIGNvbW1hbmQsIGkuZS4gRGVzY3JpcHRvcjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPklkIG9mIFR5cGUgPzwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaHVzIDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkFtbVJlcXVlc3QgOjo9IFNFUVVFTkNFPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+ezwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3Rlcm1pbmF0aW9uSUQmbmJzcDsmbmJzcDsmbmJzcDsgDQpUZXJt aW5hdGlvbklETGlzdCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJz cDsmbmJzcDsgZGVzY3JpcHRvcnMmbmJzcDsmbmJzcDsmbmJzcDsgU0VRVUVOQ0UgT0YgDQphbW1E ZXNjcmlwdG9yLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZu YnNwOyAuLi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj59PC9GT05UPjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnNob3VsZCBiZTo8L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIHNp emU9Mj5BbW1SZXF1ZXN0IDo6PSBTRVFVRU5DRTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPns8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyANCmNvbW1hbmQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb21tYW5kVHllcDwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGVybWluYXRpb25JRCZuYnNwOyZuYnNwOyZuYnNw OyANCiZuYnNwOyZuYnNwOyZuYnNwOyBUZXJtaW5hdGlvbklETGlzdCw8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgDQpkZXNjcmlwdG9ycyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NFUVVF TkNFIA0KT0YgYW1tRGVzY3JpcHRvciw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4m bmJzcDsmbmJzcDsmbmJzcDsgLi4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+fTwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPnRoZSBzYW1lIGFzIGRlc2NyaXB0 b3JzLjwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_0018_01BFE4CD.00710A20-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 03:03:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27533 for ; Mon, 3 Jul 2000 03:03:50 -0400 (EDT) Received: from standards (47.234.32.16:4804) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A5C1@standards.nortelnetworks.com>; Mon, 3 Jul 2000 2:53:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4611 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 02:53:30 -0400 Received: from paris.packetizer.local (rdu162-228-022.nc.rr.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A5BA@standards.nortelnetworks.com>; Mon, 3 Jul 2000 2:43:29 -0400 Received: from berlin (berlin.packetizer.local [192.168.1.4]) by paris.packetizer.local (8.9.3/8.9.3) with SMTP id CAA15959; Mon, 3 Jul 2000 02:53:16 -0400 References: <001b01bfe49e$f2c621e0$6293760a@richietemp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0652_01BFE493.14C54020" 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 Message-ID: <072501bfe4bb$5e45c030$0401a8c0@berlin> Date: Mon, 3 Jul 2000 02:04:54 -0400 Reply-To: "Paul E. Jones" Sender: "Media Gateway Control (megaco)" From: "Paul E. Jones" Subject: Re: Command Ids and Descriptor IDs in the ASN.1 descriptions? X-To: Richie To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0652_01BFE493.14C54020 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Richie, When encoding/decoding H.248 message, I believe you should start at the = root of the ASN.1 message structures: MegacoMessage. So, this message = to which you refer would be encoded as: MegacoMessage { mess { version =3D ##, mID =3D (address) messageBody { transactions { transactionRequest { transactionId =3D ## actions { contextID =3D commandRequests { command { addReq { ... AmmRequest parameters .... } } } } } } } } } Note, of course, that this is far from complete, but shows you generally = where the AmmRequest will be placed. Perhaps somebody else will jump in = and correct me, but I believe all ASN.1 BER encoded H.248 messages are = encoded with MegacoMessage as the root of the message. Paul ----- Original Message -----=20 From: Richie=20 To: MEGACO@STANDARDS.NORTELNETWORKS.COM=20 Sent: Sunday, July 02, 2000 11:29 PM Subject: Command Ids and Descriptor IDs in the ASN.1 descriptions? Hi, all the list: =20 In A.1 syntax specification of the H.248 protocol syntax. After decoding BER, how will we know what command type of ID it is? Also how will we know what descriptor sequence is present in each = command, i.e. Descriptor Id of Type ? Thus=20 AmmRequest ::=3D SEQUENCE { terminationID TerminationIDList, descriptors SEQUENCE OF ammDescriptor, ... } should be: AmmRequest ::=3D SEQUENCE { command commandTyep terminationID TerminationIDList, descriptors SEQUENCE OF ammDescriptor, ... } the same as descriptors. ------=_NextPart_000_0652_01BFE493.14C54020 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Richie,
 
When encoding/decoding H.248 message, I = believe you=20 should start at the root of the ASN.1 message structures: = MegacoMessage. =20 So, this message to which you refer would be encoded as:
 
MegacoMessage
{
   =20 mess {
   =20     version =3D ##,
   =20     mID    =3D = (address)
   =20     messageBody {
   =20         transactions {
   =20             = transactionRequest=20 {
   =20             =    =20 transactionId =3D ##
   =20             =    =20 actions {
   =20             =    =20     contextID =3D <id>
   =20             =    =20     commandRequests {
   =20             =    =20         command {
   =20             =    =20             addReq=20 {
   =20             =    =20             =     ...=20 AmmRequest parameters ....
   =20             =    =20             = }
   =20             =    =20         }
   =20             =    =20     }
   =20             =    =20 }
   =20             = }
   =20         }
   =20     }
   =20 }
}
 
Note, of course, that this is far from = complete,=20 but shows you generally where the AmmRequest will be placed.  = Perhaps=20 somebody else will jump in and correct me, but I believe all ASN.1 BER = encoded=20 H.248 messages are encoded with MegacoMessage as the root of the=20 message.
 
Paul
 
----- Original Message -----
From:=20 Richie=20
To: MEGACO@STANDARDS.NORTELNETWOR= KS.COM=20
Sent: Sunday, July 02, 2000 = 11:29=20 PM
Subject: Command Ids and = Descriptor IDs=20 in the ASN.1 descriptions?

Hi, all the list:
 
In A.1 syntax specification of the H.248 protocol=20 syntax.
 
After decoding BER, how will we know what command = type of ID=20 it is?
 
Also how will we know what descriptor sequence is = present in=20 each command, i.e. Descriptor
Id of Type ?
 
Thus
AmmRequest ::=3D SEQUENCE
{
    terminationID   =20 TerminationIDList,
    descriptors    = SEQUENCE OF=20 ammDescriptor,
    ...
}
 
should be:
 
AmmRequest ::=3D SEQUENCE
{
   =20 = command           =    commandTyep
    terminationID   =20     TerminationIDList,
   =20 = descriptors          SE= QUENCE=20 OF ammDescriptor,
    ...
}
 
the same as descriptors.
 
 
 
 
------=_NextPart_000_0652_01BFE493.14C54020-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 04:53:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27959 for ; Mon, 3 Jul 2000 04:53:34 -0400 (EDT) Received: from standards (47.234.32.16:2638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A5F1@standards.nortelnetworks.com>; Mon, 3 Jul 2000 4:43:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4679 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 04:43:10 -0400 Received: from mars.hss.co.in (202.54.26.197:55183) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A5F0@standards.nortelnetworks.com>; Mon, 3 Jul 2000 4:43:09 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e638sMv28718 for ; Mon, 3 Jul 2000 14:24:23 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256911.002FFBD9 ; Mon, 3 Jul 2000 14:14:06 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256911.002FFAFA.00@sandesh.hss.hns.com> Date: Mon, 3 Jul 2000 14:18:40 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Group property. To: MEGACO@STANDARDS.NORTELNETWORKS.COM HI all, If ReserveGroup is true, then the MG is requested to reserve resource so that MG can decode or encode the media streams accroding to any of the alternatives. for example, If MG reserve resources two groups of properties one for g.711 and other for G.723.1. If any change in payload occurs, does the MG switches between the alternative by itself. Or MGC triggers this switching after receiving the payloadtransition event from MG? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 05:08:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28091 for ; Mon, 3 Jul 2000 05:08:11 -0400 (EDT) Received: from standards (47.234.32.16:2638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A624@standards.nortelnetworks.com>; Mon, 3 Jul 2000 4:57:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4748 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 04:57:52 -0400 Received: from mars.hss.co.in (202.54.26.197:55373) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A623@standards.nortelnetworks.com>; Mon, 3 Jul 2000 4:57:51 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e63994v29055 for ; Mon, 3 Jul 2000 14:39:05 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256911.0031576A ; Mon, 3 Jul 2000 14:28:56 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256911.00315731.00@sandesh.hss.hns.com> Date: Mon, 3 Jul 2000 14:33:32 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Statistics for physical termination. To: MEGACO@STANDARDS.NORTELNETWORKS.COM HI all, If a physical termination realizes TDM circuit package and in turn network package, if this termination is subtracted from Context, the statistics should include octets sent/received. This definition may be trivial in case of TDM circuit where the "number of octet sent or received is equal to the duration of the Termination, in seconds, multiplied by the sampling frequency". How these statistics are calculated for other types of physical termination? as the protocol presently doesnot provide algorithm for calculating the same? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 05:30:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28227 for ; Mon, 3 Jul 2000 05:30:53 -0400 (EDT) Received: from standards (47.234.32.16:1329) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A63F@standards.nortelnetworks.com>; Mon, 3 Jul 2000 5:20:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4782 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 05:20:44 -0400 Received: from mars.hss.co.in (202.54.26.197:55605) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A63E@standards.nortelnetworks.com>; Mon, 3 Jul 2000 5:20:42 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e639Vdv29495 for ; Mon, 3 Jul 2000 15:01:41 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256911.003367C5 ; Mon, 3 Jul 2000 14:51:29 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256911.0033664B.00@sandesh.hss.hns.com> Date: Mon, 3 Jul 2000 14:56:02 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Package extention To: MEGACO@STANDARDS.NORTELNETWORKS.COM Can a package extends more than one package?? -madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 06:57:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28779 for ; Mon, 3 Jul 2000 06:57:17 -0400 (EDT) Received: from standards (47.234.32.16:1037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A69A@standards.nortelnetworks.com>; Mon, 3 Jul 2000 6:46:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4887 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 06:46:57 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A699@standards.nortelnetworks.com>; Mon, 3 Jul 2000 6:46:57 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA18898 for ; Mon, 3 Jul 2000 06:56:42 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA18894 for ; Mon, 3 Jul 2000 06:56:41 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA00937; Mon, 3 Jul 2000 12:56:40 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA00932; Mon, 3 Jul 2000 12:56:39 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <001b01bfe49e$f2c621e0$6293760a@richietemp> <072501bfe4bb$5e45c030$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39607108.DD2701A4@lucent.com> Date: Mon, 3 Jul 2000 12:55:04 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Command Ids and Descriptor IDs in the ASN.1 descriptions? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Paul, Jumping in here, not to correct you but to agree with you: every H.248 message is formatted as MegacoMessage. Cheers, John -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 07:03:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28887 for ; Mon, 3 Jul 2000 07:03:19 -0400 (EDT) Received: from standards (47.234.32.16:1037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A6C3@standards.nortelnetworks.com>; Mon, 3 Jul 2000 6:53:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4943 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 06:53:00 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A6C2@standards.nortelnetworks.com>; Mon, 3 Jul 2000 6:53:00 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA21402 for ; Mon, 3 Jul 2000 07:02:45 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA21391 for ; Mon, 3 Jul 2000 07:02:44 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA01710; Mon, 3 Jul 2000 13:02:42 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA01705; Mon, 3 Jul 2000 13:02:42 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com> <395BCA81.4830907@americasm10.nt.com> <395C47CF.D1C0F9AE@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39607273.4AF3BAF0@lucent.com> Date: Mon, 3 Jul 2000 13:01:07 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Packages extension queries. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, My understanding of the package extension mechanism is the same as that of Tom, Mike and Christian. One addition: if B and C both extend A, and B and C (independently) define a property x1, then B/x1 and C/x1 are different properties (as Christian indicated). So a change to B/x1 does not result in C/x1 changing as well. I don't completely that the package hierarchy is ill-defined per se in such a situation. It could be the case that B and C define regional extensions to an international package, and that my GW is a multi-region device. Cheers, John Christian Groves wrote: > > G'Day Michael and Tom, > > Please see my comments below marked CHG. > > Cheers, Christian > > Michael Brown wrote: > > > > Comments inline. > > > > Michael > > > > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > > > > > > > > > > > -----Original Message----- > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > Sent: Thursday, June 29, 2000 1:36 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Packages extension queries. > > > > > > There are two packages A and B. Package B extends A, > > > Say, properties a1 and a2 are in package A and x1 in package B. > > > > > > 1) If a termination realizes package B, does it mean that it > > > also realizes > > > package A? > > > [PTT] > > > Yes. > > > > > > 2) Can property of package A be addressed as B/a1? If 1) is > > > true, is it that > > > only A/a1 is possible? > > > [PTT] > > > This was discussed in Red Bank when we finalized our package > > > schema, but I can't remember the conclusion. Christian, John, > > > or Michael, do you remember? > > > > > > > I remember that the answer (consensus) was that the preferable way to > > refer to a1 is as B/a1. One could use A/a1, because there really is > > only one property defined where both names refer to it. > > [CHG] That's what I understand. > > > > > > > > > Lets there be third package C, which also extends A. and it > > > also defines a > > > property x1 > > > 3) Can a termination realize packages B and C ? > > > > > > > Well, I would say that the answer is yes that a termination COULD > > realize both, but my feeling is that this situation would be due to a > > poor definition of the packages hierarchy. Given your hypothetical > > description rather than a real example where this would appear to be a > > desirable approach, I would think that C should extend B rather than > > A. > > [CHG] I'm not sure of the question or the response but to me even if two > packages B & C extend A with a property x1 then the two instances of x1 > are uniquely identified by the package name B&C. The two instances of x1 > could be completely different functions but (unfortunately) have the > same name. > > > > > > > > > - > > > ---------------------------------------------------------------------------------------------------------------- > > > > > > Lets there be a third package C, which also extends A. and it > > > also defines a > > > property c1 > > > A termination realizes both package B and C. > > > 4) what will be value of A/a1 which is referred by both B/a1 > > > and C/a1. > > > If B/a1 value is changed is it that the value of C/a1 is also > > > changed? > > > > > > > Based on my previous two responses, C/a1 would be changed, but this > > situation is one that to me would indicate that the package hierarchy > > has not been properly defined. I don't think this should ever happen. > > [CHG] I think A/al, B/al and C/al will all change because they are the > same property. > > > > > > > > > > > > -Madhubabu > > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 07:59:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29919 for ; Mon, 3 Jul 2000 07:59:39 -0400 (EDT) Received: from standards (47.234.32.16:1037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A742@standards.nortelnetworks.com>; Mon, 3 Jul 2000 7:49:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5102 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 07:49:06 -0400 Received: from mars.hss.co.in (202.54.26.197:57194) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A73F@standards.nortelnetworks.com>; Mon, 3 Jul 2000 7:49:04 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e63C05v02652; Mon, 3 Jul 2000 17:30:07 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256911.0040FAE4 ; Mon, 3 Jul 2000 17:19:45 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256911.0040F89D.00@sandesh.hss.hns.com> Date: Mon, 3 Jul 2000 17:24:18 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: Tonegen Package X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Tom list, Why are we going for two different possiblities for specifying items in a package. One which uniquely identify a given item as pkg_name/idem_id. and the other only with item_id (assuming this item_id is unique.) why are we not going for fully specified items with package identifiers and make grammar consistent for doing the same? -Madhubabu Tom-PT Taylor on 06/28/2000 01:19:50 AM Please respond to Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: Tonegen Package > -----Original Message----- > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > Sent: Tuesday, June 27, 2000 10:24 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Tonegen Package > > Tom-PT Taylor wrote: > > Can someone show a real world scenario and syntax on how > tonegen package is used? > > Sorry I meant an example of tonegen and cg being used together. > I think your example 2 could have been done w/o using tonegen. > [PTT] I can't think of a realistic example using the specific tones in cg. Assuming that some new package provides "stutter dial tone" (toneId sdt) which indicates a waiting message, then one could imagine a Signals descriptor like Signals { tonegen/pt {tl = { sdt, dt}, ind = 10} } The assumption is that the durations of the respective tones are provisioned. Again, I don't see this as realistic -- a signal list would work better. > > > > [PTT] > Two cases: > > Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a > PBX trunk), with 10 ms gaps between the individual tones. > > Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2}, > ind=10} } > > Case 2: Play ringing tone for a maximum of 3 minutes. > Notify the MGC if the tone terminates abnormally or by timeout. (No > notification is needed if the tone is interrupted by an event or > replacement.) If any signals remain active when the signal completion > event is recognized, allow them to continue. > > Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, > or} }, > Events = 666 { g/sc{ka} } > > Maybe it is just me but this look pretty challenging and time > consuming to parse. > How would one knows that tl, ind, sy, nc and ka represent > package parameter name > versus Megaco token name? [PTT] Per the syntax for signals, your parser should be primed to look for sy, nc, ka, and one or two others, because these are defined in Annex B. Anything else is package dependent. It's exactly as you say, but you may be able to stick all the toneIDs into a single working database, since the package they come from is irrelevant so long as the other party also supports that package. > One would have to make sure that it is not a Megaco token > name first. > Then search through all package databases that extend tonegen > package. > > > tonegen package: signal type = Brief and duration = > Provisioned. > cg package : signal type = Timeout and duration = > Provisioned > > Does cg package (cg) override tonegen signal type, etc? > So in general does extension package overide package that it > extends? [PTT] Leaving aside the thought that defining cg as an extension of tonegen may have been wasted effort, we have two possibilities: you are using signal tonegen/pt, or you are using a signal in the cg package. These are different signals, and may therefore be of different types. If you are using tonegen/pt with a toneID from cg, then the fact that cg supports TO signals is irrelevant. > Is there any restriction that "tl" can only contain tone from > one package or multiple > packages as long as these packages extend tonegen? [PTT] Not so long as we ensure that toneIDs are unique across all packages. > > Do you know where I can find all the packages defined so far. > > One would have to build some kind of tree to keep track of > these package extension. > It would be a nightmare if one is looking at binary values of > these package > parameter Ids in hex. [PTT] I published a list a little while back, but can't find the message at the moment. It's about time I set up the IANA tabulations. > Thanks > Chuong > > > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 3 09:56:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02065 for ; Mon, 3 Jul 2000 09:56:44 -0400 (EDT) Received: from standards (47.234.32.16:4730) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A787@standards.nortelnetworks.com>; Mon, 3 Jul 2000 9:46:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5187 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jul 2000 09:46:21 -0400 Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7A782@standards.nortelnetworks.com>; Mon, 3 Jul 2000 9:36:21 -0400 Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id IAA21481 for ; Mon, 3 Jul 2000 08:43:50 -0500 (CDT) Received: from (relay2-alt.usa.alcatel.com [143.209.167.22]) by fw7 via smap (V2.1) id xma021451; Mon, 3 Jul 00 08:42:57 -0500 Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id IAA27486 for ; Mon, 3 Jul 2000 08:46:43 -0500 (CDT) Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id IAA10492 for ; Mon, 3 Jul 2000 08:44:59 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA23304 for ; Mon, 3 Jul 2000 08:44:58 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com> <395BCA81.4830907@americasm10.nt.com> <395C47CF.D1C0F9AE@ericsson.com> <39607273.4AF3BAF0@lucent.com> Content-Type: multipart/alternative; boundary="------------129BA3EBAFE26F08CC068EF7" Message-ID: <396098D8.F081CB0B@usa.alcatel.com> Date: Mon, 3 Jul 2000 08:44:56 -0500 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Re: Packages extension queries. To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------129BA3EBAFE26F08CC068EF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom This go back to the discussion we have earlier. In this case how do we do Signals{tonegen/pt{tl={x1,x1}, ind=100}} The Standard has to spell out that itemId/parameterId has to be unique in all packages that extend each other. Thanks Chuong John Segers wrote: > Hi, > > My understanding of the package extension mechanism is the same as that > of Tom, Mike and Christian. One addition: if B and C both extend A, and > B and C (independently) define a property x1, then B/x1 and C/x1 are > different properties (as Christian indicated). So a change to B/x1 does > not result in C/x1 changing as well. > > I don't completely that the package hierarchy is ill-defined per se in > such a situation. It could be the case that B and C define regional > extensions to an international package, and that my GW is a multi-region > device. > > Cheers, > > John > > Christian Groves wrote: > > > > G'Day Michael and Tom, > > > > Please see my comments below marked CHG. > > > > Cheers, Christian > > > > Michael Brown wrote: > > > > > > Comments inline. > > > > > > Michael > > > > > > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > > Sent: Thursday, June 29, 2000 1:36 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Packages extension queries. > > > > > > > > There are two packages A and B. Package B extends A, > > > > Say, properties a1 and a2 are in package A and x1 in package B. > > > > > > > > 1) If a termination realizes package B, does it mean that it > > > > also realizes > > > > package A? > > > > [PTT] > > > > Yes. > > > > > > > > 2) Can property of package A be addressed as B/a1? If 1) is > > > > true, is it that > > > > only A/a1 is possible? > > > > [PTT] > > > > This was discussed in Red Bank when we finalized our package > > > > schema, but I can't remember the conclusion. Christian, John, > > > > or Michael, do you remember? > > > > > > > > > > I remember that the answer (consensus) was that the preferable way to > > > refer to a1 is as B/a1. One could use A/a1, because there really is > > > only one property defined where both names refer to it. > > > > [CHG] That's what I understand. > > > > > > > > > > > > > Lets there be third package C, which also extends A. and it > > > > also defines a > > > > property x1 > > > > 3) Can a termination realize packages B and C ? > > > > > > > > > > Well, I would say that the answer is yes that a termination COULD > > > realize both, but my feeling is that this situation would be due to a > > > poor definition of the packages hierarchy. Given your hypothetical > > > description rather than a real example where this would appear to be a > > > desirable approach, I would think that C should extend B rather than > > > A. > > > > [CHG] I'm not sure of the question or the response but to me even if two > > packages B & C extend A with a property x1 then the two instances of x1 > > are uniquely identified by the package name B&C. The two instances of x1 > > could be completely different functions but (unfortunately) have the > > same name. > > > > > > > > > > > > > - > > > > ---------------------------------------------------------------------------------------------------------------- > > > > > > > > Lets there be a third package C, which also extends A. and it > > > > also defines a > > > > property c1 > > > > A termination realizes both package B and C. > > > > 4) what will be value of A/a1 which is referred by both B/a1 > > > > and C/a1. > > > > If B/a1 value is changed is it that the value of C/a1 is also > > > > changed? > > > > > > > > > > Based on my previous two responses, C/a1 would be changed, but this > > > situation is one that to me would indicate that the package hierarchy > > > has not been properly defined. I don't think this should ever happen. > > > > [CHG] I think A/al, B/al and C/al will all change because they are the > > same property. > > > > > > > > > > > > > > > > > -Madhubabu > > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------129BA3EBAFE26F08CC068EF7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tom

This go back to the discussion we have earlier.
In this case how do we do

Signals{tonegen/pt{tl={x1,x1}, ind=100}}

The Standard has to spell out that itemId/parameterId has to be unique in all packages that
extend each other.

Thanks
Chuong

John Segers wrote:

Hi,

My understanding of the package extension mechanism is the same as that
of Tom, Mike and Christian.  One addition: if B and C both extend A, and
B and C (independently) define a property x1, then B/x1 and C/x1 are
different properties (as Christian indicated).  So a change to B/x1 does
not result in C/x1 changing as well.

I don't completely that the package hierarchy is ill-defined per se in
such a situation.  It could be the case that B and C define regional
extensions to an international package, and that my GW is a multi-region
device.

Cheers,

John

Christian Groves wrote:
>
> G'Day Michael and Tom,
>
> Please see my comments below marked CHG.
>
> Cheers, Christian
>
> Michael Brown wrote:
> >
> > Comments inline.
> >
> > Michael
> >
> > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
> >
> > >
> > >
> > >      -----Original Message-----
> > >      From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> > >      Sent:   Thursday, June 29, 2000 1:36 AM
> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >      Subject:        Packages extension queries.
> > >
> > >      There are two packages A and B. Package B extends A,
> > >      Say, properties a1 and a2 are in package A and x1 in package B.
> > >
> > >      1) If a termination realizes package B, does it mean that it
> > >      also realizes
> > >      package A?
> > >      [PTT]
> > >      Yes.
> > >
> > >      2) Can property of package A be addressed as B/a1? If 1) is
> > >      true, is it that
> > >      only A/a1 is possible?
> > >      [PTT]
> > >      This was discussed in Red Bank when we finalized our package
> > >      schema, but I can't remember the conclusion.  Christian, John,
> > >      or Michael, do you remember?
> > >
> >
> > I remember that the answer (consensus) was that the preferable way to
> > refer to a1 is as B/a1. One could use A/a1, because there really is
> > only one property defined where both names refer to it.
>
> [CHG] That's what I understand.
>
> >
> > >
> > >      Lets there be third package C, which also extends A. and it
> > >      also defines a
> > >      property x1
> > >      3) Can a termination realize packages B and C ?
> > >
> >
> > Well, I would say that the answer is yes that a termination COULD
> > realize both, but my feeling is that this situation would be due to a
> > poor definition of  the packages hierarchy. Given your hypothetical
> > description rather than a real example where this would appear to be a
> > desirable approach, I would think that C should extend B rather than
> > A.
>
> [CHG] I'm not sure of the question or the response but to me even if two
> packages B & C extend A with a property x1 then the two instances of x1
> are uniquely identified by the package name B&C. The two instances of x1
> could be completely different functions but (unfortunately) have the
> same name.
>
> >
> > >
> > >      -
> > >      ----------------------------------------------------------------------------------------------------------------
> > >
> > >      Lets there be a third package C, which also extends A. and it
> > >      also defines a
> > >      property c1
> > >      A termination realizes both package B and C.
> > >      4) what will be value of A/a1 which is referred by both B/a1
> > >      and C/a1.
> > >      If B/a1 value is changed is it that the value of C/a1 is also
> > >      changed?
> > >
> >
> > Based on my previous two responses, C/a1 would be changed, but this
> > situation is one that to me would indicate that the package hierarchy
> > has not been properly defined. I don't think this should ever happen.
>
> [CHG] I think A/al, B/al and C/al will all change because they are the
> same property.
>
> >
> > >
> > >
> > >      -Madhubabu
> > >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 303
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------129BA3EBAFE26F08CC068EF7-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 4 22:26:36 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03166 for ; Tue, 4 Jul 2000 22:26:36 -0400 (EDT) Received: from standards (47.234.32.16:1354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AC38@standards.nortelnetworks.com>; Tue, 4 Jul 2000 22:15:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6799 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jul 2000 22:15:53 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AC37@standards.nortelnetworks.com>; Tue, 4 Jul 2000 22:15:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA23672; Tue, 4 Jul 2000 22:25:39 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA19489; Tue, 4 Jul 2000 22:25:41 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jul 2000 22:25:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01162822@whq-msgusr-02.fore.com> Date: Tue, 4 Jul 2000 22:25:38 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Package extention X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM At first, I was inclined to say, "sure, why not" However, I'm worried about implementation difficulty. If it's hard to do, I think the utility is small. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, July 03, 2000 5:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Package extention > > > Can a package extends more than one package?? > -madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 4 22:26:36 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03169 for ; Tue, 4 Jul 2000 22:26:36 -0400 (EDT) Received: from standards (47.234.32.16:1354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AC3F@standards.nortelnetworks.com>; Tue, 4 Jul 2000 22:16:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6807 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jul 2000 22:16:21 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AC3E@standards.nortelnetworks.com>; Tue, 4 Jul 2000 22:16:20 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA23696; Tue, 4 Jul 2000 22:26:08 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA19533; Tue, 4 Jul 2000 22:26:09 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jul 2000 22:26:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0116282B@whq-msgusr-02.fore.com> Date: Tue, 4 Jul 2000 22:26:09 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Signal descriptor returned in response. X-To: Hemant Kumar To: MEGACO@STANDARDS.NORTELNETWORKS.COM This kind of problem is age-old, and is almost always settled by returning "current" state, whatever it is, regardless of what asynchrony exists. Sending back what was received is close to useless. So, I think the MG should return what is currently being "played" and what remains to be played (in the case of a signal list). Brian > -----Original Message----- > From: Hemant Kumar [mailto:hkumar@globespan.net] > Sent: Friday, June 30, 2000 6:08 AM > To: Rosen, Brian; MEGACO@standards.nortelnetworks.com > Subject: Signal descriptor returned in response. > > > Hi Everyone, > I think that in response to audit of signal > descriptor, the signals > and signal lists in the previous descriptor should be > returned. As Brian had > pointed out in his earlier mail (on June 16) the MG might not > be in sync > with the MGC. There is always the possiblity of completion of > signal (or/and > signal lists) play by the time the message containing the > "active" signal > (or/and signal lists)reaches the MGC (especially for brief signals). > Therefore sending active signals (or/and signal lists)only in > the audit > response would be of little value (The MGC can never be sure > of whether the > signals(or/and signal lists) that have been received are > actually playing or > not) > > Regards, > Hemant Kumar > > ----- Original Message ----- > From: Rosen, Brian > To: > Sent: Friday, June 30, 2000 3:27 AM > Subject: Re: signal descriptor returned in response. > > > > I thought I had sent an answer to this, > > > > I believe you get "live" information, which would be > > the signals playing at the time, not was last sent. > > If there were no signals, you get an empty descriptor. > > > > For a signal list, I think it's not specified whether > > you get only those active, or yet to be played items, > > or whether you get the original list. I'd like to see > > what is current and yet to go, but that may be hard to > > implement. > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Wednesday, June 28, 2000 12:56 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: signal descriptor returned in response. > > > > > > > > > (Reposting) > > > Hi all, > > > > > > When signal Descriptor is specified in Audit descriptor, > > > what is the response expected from MG? > > > The Signal descriptor earlier sent by MGC? OR > > > The list of signals that are presently active on the termination? > > > -Madhu Babu > > > Hughes Software Systems. > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 03:45:42 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18339 for ; Wed, 5 Jul 2000 03:45:42 -0400 (EDT) Received: from standards (47.234.32.16:2494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7ACE7@standards.nortelnetworks.com>; Wed, 5 Jul 2000 3:35:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7018 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 03:35:19 -0400 Received: from ws9.cdotb.ernet.in (202.41.72.121:3523) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7ACE4@standards.nortelnetworks.com>; Wed, 5 Jul 2000 3:25:15 -0400 Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id NAA17413 for ; Wed, 5 Jul 2000 13:01:14 +0500 (GMT+0500) Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/13Apr00-1149AM) id MAA0000009962; Wed, 5 Jul 2000 12:57:51 +0500 (GMT+0500) X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3962E4E5.3259A443@cdotb.ernet.in> Date: Wed, 5 Jul 2000 13:03:57 +0530 Reply-To: Titty Thomas Sender: "Media Gateway Control (megaco)" From: Titty Thomas Organization: Centre for Development of Telematics Subject: mid clarification ? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, The megaco draft says mid can be either domainAddress / domainName / mtpAddress / deviceName. domainAddress can be either IP v4 address / IPv6address And I think domainName is like this - abc@xyz.com. Am I correct?. Can anyone give examples for mtpAddress and deviceName? Thanks in advance, Titty Thomas From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 03:49:04 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18403 for ; Wed, 5 Jul 2000 03:49:04 -0400 (EDT) Received: from standards (47.234.32.16:2494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AD00@standards.nortelnetworks.com>; Wed, 5 Jul 2000 3:38:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7053 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 03:38:43 -0400 Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7ACFF@standards.nortelnetworks.com>; Wed, 5 Jul 2000 3:38:42 -0400 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA11830 for ; Wed, 5 Jul 2000 03:48:33 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA11823 for ; Wed, 5 Jul 2000 03:48:32 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA28029; Wed, 5 Jul 2000 09:08:03 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA28017; Wed, 5 Jul 2000 09:08:02 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01162822@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3962DE72.86CEA28A@lucent.com> Date: Wed, 5 Jul 2000 09:06:26 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Package extention To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Madhu, Brian, I don't think that we should allow this. You run into problems if a package C extends A and B, and A and B contain properties that have the same name. What property does C/x refer to if A and B both have a property x? John "Rosen, Brian" wrote: > > At first, I was inclined to say, "sure, why not" > However, I'm worried about implementation difficulty. > > If it's hard to do, I think the utility is small. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, July 03, 2000 5:26 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Package extention > > > > > > Can a package extends more than one package?? > > -madhubabu > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 05:36:01 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19072 for ; Wed, 5 Jul 2000 05:36:01 -0400 (EDT) Received: from standards (47.234.32.16:1502) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AD2D@standards.nortelnetworks.com>; Wed, 5 Jul 2000 5:25:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7109 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 05:25:32 -0400 Received: from ws9.cdotb.ernet.in (202.41.72.121:4098) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AD2C@standards.nortelnetworks.com>; Wed, 5 Jul 2000 5:15:24 -0400 Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id OAA16857 for ; Wed, 5 Jul 2000 14:50:56 +0500 (GMT+0500) Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/13Apr00-1149AM) id OAA0000011202; Wed, 5 Jul 2000 14:48:34 +0500 (GMT+0500) X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6784CE@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3962FEDA.BABAEE2E@cdotb.ernet.in> Date: Wed, 5 Jul 2000 14:54:42 +0530 Reply-To: Titty Thomas Sender: "Media Gateway Control (megaco)" From: Titty Thomas Organization: Centre for Development of Telematics Subject: Re: MG Service Change w.r.t. TCP as transport To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, see the queries below, Thanks Titty Thomas "Rosen, Brian" wrote: > > Q1: Is MG allowed to include ServiceChangeAddress parameter > > in case of TCP > > as a transport? > Yes, but it would be pretty unusual. > > > Q2: If answer to Q1 is yes, then is MGC supposed to establish > > connection > > back to MG on > > the changed address? > No, I think the MG would have to do that. > [TT] Consider the scenario where MG sends a service change request with the service change address included. Q.1) In this case when will MGC start accepting the transaction requests through the new TCP connection?. Q.2) Is it after MGC has sent replies for all transaction requests (including the service change request) it has received through the old connection?. Q.3) When will MG establish the new TCP connection with the MGC.? Is it after it has got the reply for the servicechange request it has sent? Q.4) If the answer to Q.2 is true, then what is the error MGC should return if MG sends a request before it has got a reply to servicechange request? > > > > > If Q1 and Q2 hold, then MG needs to has to implement a TCP Server. I > > remember the discussion > > along the line of MG implementing Server and MGC initiating > > connection did > > not reach any > > conclusion. > I don't think the MG needs a TCP server > > Brian > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 07:38:26 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20233 for ; Wed, 5 Jul 2000 07:38:26 -0400 (EDT) Received: from standards (47.234.32.16:3258) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AD8C@standards.nortelnetworks.com>; Wed, 5 Jul 2000 7:28:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7240 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 07:28:01 -0400 Received: from ficon-tech.com (12.10.198.190:3044) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AD8B@standards.nortelnetworks.com>; Wed, 5 Jul 2000 7:27:56 -0400 Received: from ficon-tech.com (vsalota.india.ficon-tech.com [172.25.1.107]) by ficon-tech.com (8.9.3/8.9.3) with ESMTP id RAA38222; Wed, 5 Jul 2000 17:06:23 +0530 (IST) (envelope-from vsalota@ficon-tech.com) X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B0B@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39631D3C.93D1CB7F@ficon-tech.com> Date: Wed, 5 Jul 2000 17:04:21 +0530 Reply-To: Vikas Salota Sender: "Media Gateway Control (megaco)" From: Vikas Salota Subject: Re: Tonegen Package X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Sorry for the late comments. Please see embedded comments. Tom-PT Taylor wrote: > Sorry to take so long to answer this. If you check out the ABNF, you see > that signal parameter syntax reduces to > > NAME parmValue > > As a result, the toneIDs themselves are NOT prefixed by package name. The > square bracket syntax denotes a sublist (from the alternativeValue > production). I think that's wrong: the package defines the parameter as a > list, not a sub-list. Thus curly brackets should be used, and the > interpretation is "list of values" rather than "list of alternatives" > because the package definition says so. Vikas> I don't think it's a good idea to overload the alternatives list to be interpreted as "list of values" for this particular case. If we have a requirement for an ordered list (as in this case), why not define an ordered list on the similar lines which can be probably be demarcated using '(', ')' pair. This may have significant implications on the existing definitions of the packages having list type elements. We'll have to reclassify them in the light of new type list being defined. Even if this particular case of Tonegen Pkg looks like a special case and not many lists of these type are expected, shouldn't it be sub-list that is "overloaded" as "list of values" rather than the alternatives list which is choosing a value from a list of values. > > > The fact that toneIDs are not prefixed by package name leads to potential > ambiguity. Either toneIDs have to be unique, which may implying an IANA > registration process, or else we indicate which package the toneIDs come > from by using the package name for the toneIDs instead of tonegen to prefix > the pt signal. The latter mechanism would restrict the playing of tones in > one signal to a single package, so I think we have to go with unique > toneIDs. Therefore the correct syntax for your example is Vikas> Why can't we allow the toneId be qualified with a package name in Tone id list. Grammer already supports it. Moreover having a package name with the toneId would greatly simplify the lookup for any toneId in the list. Otherwise the ToneId would have to be looked for in all the defined packages or atleast among the packages extending ToneGen directly/indirectly(assuming that the toneId would always be from such a package). This puts an extra requirement of a special handling of toneIds in the tone Id list and a need to keep information (per package) about what all packages extend the given package (which was not needed till now). > > > Signals { tonegen/pt {tl = {rt, cw}, ind = 100} } > > The example is really not very appealing -- one would have to assume that > the durations of rt and cw are provisioned. (Note that tonegen is > characterized as BR by default.) > > The fact that we define toneIDs in packages implies that they come in > closely related sets, which must be supported on an all-or-nothing basis. > > Further comments below. > > > -----Original Message----- > > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM] > > Sent: Saturday, June 17, 2000 1:12 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Tonegen Package > > > > Hi > > > > Can soneone help me w/the syntax involving tonegen Package and cg package? > > > > > > Say I want to use tonegen/pt with tl (tone id list) of cg/rt and cg/cw > > (just as an example) > > > > Signals { tonegen/pt {tl = [cg/rt, cg/cw], ind = 100} } > > > > Does this look right? > > > > Can someone show a real world scenario and syntax on how tonegen package > > is used? > [PTT] > Two cases: > > Case 1: DTMF outpulsing of the digits "5551212" (e.g. on a PBX > trunk), with 10 ms gaps between the individual tones. > > Signals { tonegen/pt {tl = {d5, d5, d5, d1, d2, d1, d2}, ind=10} > } > > Case 2: Play ringing tone for a maximum of 3 minutes. Notify the > MGC if the tone terminates abnormally or by timeout. (No notification is > needed if the tone is interrupted by an event or replacement.) If any > signals remain active when the signal completion event is recognized, allow > them to continue. > > Signals { tonegen/pt {tl = {rg}, ind=0, sy=to, nc= {to, or} }, > Events = 666 { g/sc{ka} } > > > In the description of tonegen, "interdigit" time delay was given as the > > definition for "ind". > > What does "interdigit time delay" really mean here? > > Later in Section E.3.3 "ind" is defined as inter signal duration which > > seems to make > > some sense of how "ind" is supposed to be used. > [PTT] > The "interdigit" is in quotes in the description because the tones > aren't necessarily digits. However, as you can see, the most natural use of > the "list of tones" feature is for digit outpulsing. > > > --- > > Since Call Progress Tones Generator (cg) Package extends tonegen package, > > it does not really mean that you have to use the following syntax to use > > cg: > > Signals {tonegen/pt {tl = cg/dt}} > > > > One can just do Signals{cg/dt} > [PTT] > Sorry, no. "dt" is not a signal, merely a possible value of a > signal parameter. > > > ---- > > E.7.3 under "Additional Values" > > "dt (0x0030) is defined as a tone id for playtone" > > > > Does this imply one can do the following? > > Signals {tonegen/pt {tl = dt}} > > > > In E.3.3 "tl" is defined as a list of tone ids. > > Is tone id "dt" or "cg/dt"? > [PTT] > Answered above. The ABNF for signal parameter value forces us to > use "dt". > > > Thanks > > Chuong > > > > -- > > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 07:50:37 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20463 for ; Wed, 5 Jul 2000 07:50:36 -0400 (EDT) Received: from standards (47.234.32.16:3258) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7ADAF@standards.nortelnetworks.com>; Wed, 5 Jul 2000 7:40:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7286 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 07:40:16 -0400 Received: from mailcity.com (209.1.236.7:38179) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7ADAE@standards.nortelnetworks.com>; Wed, 5 Jul 2000 7:40:16 -0400 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Jul 5 04:49:45 2000 Mime-Version: 1.0 X-Sent-Mail: off X-Mailer: MailCity Service X-Sender-Ip: 216.6.88.34 Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 5 Jul 2000 04:49:45 -0700 Reply-To: hussainmf@mailcity.com Sender: "Media Gateway Control (megaco)" From: Hussain F Mohammad Organization: MailCity (http://www.mailcity.lycos.com:80) Subject: Empty Local descriptor in Media Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Can anyone helpme in identifying a typical call scenario,in which a local (remote) descriptor is empty in media descriptor? TIA. -MFH Send FREE Greetings for Father's Day--or any day! Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 09:45:42 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02556 for ; Wed, 5 Jul 2000 09:45:42 -0400 (EDT) Received: from standards (47.234.32.16:2488) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AE07@standards.nortelnetworks.com>; Wed, 5 Jul 2000 9:35:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7384 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 09:35:05 -0400 Received: from mars.hss.co.in (202.54.26.197:33849) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AE00@standards.nortelnetworks.com>; Wed, 5 Jul 2000 9:25:01 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e65Da3c02310 for ; Wed, 5 Jul 2000 08:36:08 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256913.0049C49F ; Wed, 5 Jul 2000 18:55:44 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256913.0049B479.00@sandesh.hss.hns.com> Date: Wed, 5 Jul 2000 17:19:06 +0530 Reply-To: knayar@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kapil Nayar Subject: ACodec (Media Stream Property) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Reference : draft-...-merged-01....Annexure C TAGS FOR ....C.1 General Media ....ACodec (Audio Codec Type) Can somebody point me to the location (where I can find ACodec) in ITU-T Rec.Q.765 refered to in the MEGACO draft. Kapil From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 10:25:29 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05320 for ; Wed, 5 Jul 2000 10:25:29 -0400 (EDT) Received: from standards (47.234.32.16:2488) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AE5B@standards.nortelnetworks.com>; Wed, 5 Jul 2000 10:15:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7478 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 10:15:01 -0400 Received: from cat01s2.catenanet.com (CAT01FW.Catenanet.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AE47@standards.nortelnetworks.com>; Wed, 5 Jul 2000 10:05:01 -0400 Received: by CAT01S2 with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jul 2000 10:14:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <310508EDF557D31188FA0050DA0A3752264657@CAT01S2> Date: Wed, 5 Jul 2000 10:14:45 -0400 Reply-To: John Donak Sender: "Media Gateway Control (megaco)" From: John Donak Subject: Support for Pay Telephones To: MEGACO@STANDARDS.NORTELNETWORKS.COM I could not find a package that supports Pay Telephones (Positive Coin Check, Negative Coin Check, Postivive Coin Control, Negative Coin Control, Coin Ground). Does one exist? I would assume that this needs to be supported. John John Donak Catena Networks Voice: (613) 270-1006 x581 Email: jdonak@catena.com Fax: (613) 270-1085 URL: www.catena.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 14:36:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13720 for ; Wed, 5 Jul 2000 14:36:37 -0400 (EDT) Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B008@standards.nortelnetworks.com>; Wed, 5 Jul 2000 14:26:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8015 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 14:26:20 -0400 Received: from qhars002.nortel.com (47.101.112.102:36474) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7AFFE@standards.nortelnetworks.com>; Wed, 5 Jul 2000 14:16:20 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 5 Jul 2000 19:25:56 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Wed, 5 Jul 2000 14:25:16 -0400 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JSNBG23; Wed, 5 Jul 2000 14:25:15 -0400 Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JPMF69T; Wed, 5 Jul 2000 14:25:15 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01162822@whq-msgusr-02.fore.com> <3962DE72.86CEA28A@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39637EB7.5906E47D@americasm10.nt.com> Date: Wed, 5 Jul 2000 14:30:15 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Package extention To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit While I'm not sure I agree that this shouldn't be allowed, I agree that it should be discouraged. I suppose as long as packages are worked as part of IETF or ITU, this type of restriction could be "enforced". Multiple inheritance is an extremely messy arrangement... easy to get into problems (as John has pointed out) and generally doesn't add value to justify the potential complexity. Michael John Segers wrote: > Madhu, Brian, > > I don't think that we should allow this. You run into problems if a > package C extends A and B, and A and B contain properties that have the > same name. What property does C/x refer to if A and B both have a > property x? > > John > > "Rosen, Brian" wrote: > > > > At first, I was inclined to say, "sure, why not" > > However, I'm worried about implementation difficulty. > > > > If it's hard to do, I think the utility is small. > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Monday, July 03, 2000 5:26 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Package extention > > > > > > > > > Can a package extends more than one package?? > > > -madhubabu > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 14:47:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14088 for ; Wed, 5 Jul 2000 14:47:12 -0400 (EDT) Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B070@standards.nortelnetworks.com>; Wed, 5 Jul 2000 14:36:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8163 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 14:36:34 -0400 Received: from qhars002.nortel.com (47.101.112.102:37055) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B06F@standards.nortelnetworks.com>; Wed, 5 Jul 2000 14:36:33 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 5 Jul 2000 19:41:50 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 5 Jul 2000 14:41:32 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 14:35:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE6AF.CCA868FC" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C3835@zcard00q.ca.nortel.com> Date: Wed, 5 Jul 2000 14:35:19 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Package extention X-cc: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFE6AF.CCA868FC Content-Type: text/plain; charset="iso-8859-1" Original intent of the Extends mechanism when we designed it was to extend only one Package. The issues John raises below were considered, and value did not seem to warrant inherent extra confusion, risk of misinterpretation, additional design complexity, etc. Like multiple inheritance, its kinda cool, but not a good idea here IMHO. Keep it simple. Currently the answer is "no, cannot extend more than one package". If the text does not say this, it should be clarified in later version, implementation notes, or elsewhere. -- Peter -----Original Message----- From: John Segers [mailto:jsegers@LUCENT.COM] Sent: Wednesday, July 05, 2000 03:06 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Package extention Madhu, Brian, I don't think that we should allow this. You run into problems if a package C extends A and B, and A and B contain properties that have the same name. What property does C/x refer to if A and B both have a property x? John "Rosen, Brian" wrote: > > At first, I was inclined to say, "sure, why not" > However, I'm worried about implementation difficulty. > > If it's hard to do, I think the utility is small. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, July 03, 2000 5:26 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Package extention > > > > > > Can a package extends more than one package?? > > -madhubabu > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 ------_=_NextPart_001_01BFE6AF.CCA868FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Package extention

Original intent of the Extends mechanism when we = designed it was to extend only one Package.  The issues John = raises below were considered, and value did not seem to warrant = inherent extra confusion, risk of misinterpretation, additional design = complexity, etc.  Like multiple inheritance, its kinda cool, but = not a good idea here IMHO.  Keep it simple. 

Currently the answer is "no, cannot extend more = than one package".  If the text does not say this, it should = be clarified in later version, implementation notes, or = elsewhere. 

-- Peter

-----Original Message-----
From: John Segers [mailto:jsegers@LUCENT.COM]=
Sent: Wednesday, July 05, 2000 03:06
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Package extention


Madhu, Brian,

I don't think that we should allow this.  You = run into problems if a
package C extends A and B, and A and B contain = properties that have the
same name.  What property does C/x refer to if = A and B both have a
property x?

John

"Rosen, Brian" wrote:
>
> At first, I was inclined to say, "sure, = why not"
> However, I'm worried about implementation = difficulty.
>
> If it's hard to do, I think the utility is = small.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM]=
> > Sent: Monday, July 03, 2000 5:26 AM
> > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Package extention
> >
> >
> > Can a package extends more than one = package??
> > -madhubabu
> >

--
John = Segers           =             =            email: = jsegers@lucent.com
Lucent = Technologies          =             =             =       Room HE 303
Dept. Forward Looking = Work           &n= bsp;          phone: +31 = 35 687 4724
P.O. Box 18, 1270 AA  = Huizen           =            fax: +31 = 35 687 5954

------_=_NextPart_001_01BFE6AF.CCA868FC-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 5 15:52:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15603 for ; Wed, 5 Jul 2000 15:52:33 -0400 (EDT) Received: from standards (47.234.32.16:1900) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B0F1@standards.nortelnetworks.com>; Wed, 5 Jul 2000 15:42:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8324 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jul 2000 15:42:11 -0400 Received: from qhars002.nortel.com (47.101.112.102:39162) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B0E6@standards.nortelnetworks.com>; Wed, 5 Jul 2000 15:32:06 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 5 Jul 2000 20:39:01 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Wed, 5 Jul 2000 13:34:08 -0500 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JSNBGJ5; Wed, 5 Jul 2000 14:33:35 -0400 Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JPMF60L; Wed, 5 Jul 2000 14:33:34 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com> <395BCA81.4830907@americasm10.nt.com> <395C47CF.D1C0F9AE@ericsson.com> <39607273.4AF3BAF0@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396380AA.EA672A12@americasm10.nt.com> Date: Wed, 5 Jul 2000 14:38:34 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Packages extension queries. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Ooops... My comment about ill defined package hierarchy was based on a misread on my part. John and Christian have set the record straight. Sorry for the confusion. Michael John Segers wrote: > Hi, > > My understanding of the package extension mechanism is the same as that > of Tom, Mike and Christian. One addition: if B and C both extend A, and > B and C (independently) define a property x1, then B/x1 and C/x1 are > different properties (as Christian indicated). So a change to B/x1 does > not result in C/x1 changing as well. > > I don't completely that the package hierarchy is ill-defined per se in > such a situation. It could be the case that B and C define regional > extensions to an international package, and that my GW is a multi-region > device. > > Cheers, > > John > > Christian Groves wrote: > > > > G'Day Michael and Tom, > > > > Please see my comments below marked CHG. > > > > Cheers, Christian > > > > Michael Brown wrote: > > > > > > Comments inline. > > > > > > Michael > > > > > > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > > Sent: Thursday, June 29, 2000 1:36 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Packages extension queries. > > > > > > > > There are two packages A and B. Package B extends A, > > > > Say, properties a1 and a2 are in package A and x1 in package B. > > > > > > > > 1) If a termination realizes package B, does it mean that it > > > > also realizes > > > > package A? > > > > [PTT] > > > > Yes. > > > > > > > > 2) Can property of package A be addressed as B/a1? If 1) is > > > > true, is it that > > > > only A/a1 is possible? > > > > [PTT] > > > > This was discussed in Red Bank when we finalized our package > > > > schema, but I can't remember the conclusion. Christian, John, > > > > or Michael, do you remember? > > > > > > > > > > I remember that the answer (consensus) was that the preferable way to > > > refer to a1 is as B/a1. One could use A/a1, because there really is > > > only one property defined where both names refer to it. > > > > [CHG] That's what I understand. > > > > > > > > > > > > > Lets there be third package C, which also extends A. and it > > > > also defines a > > > > property x1 > > > > 3) Can a termination realize packages B and C ? > > > > > > > > > > Well, I would say that the answer is yes that a termination COULD > > > realize both, but my feeling is that this situation would be due to a > > > poor definition of the packages hierarchy. Given your hypothetical > > > description rather than a real example where this would appear to be a > > > desirable approach, I would think that C should extend B rather than > > > A. > > > > [CHG] I'm not sure of the question or the response but to me even if two > > packages B & C extend A with a property x1 then the two instances of x1 > > are uniquely identified by the package name B&C. The two instances of x1 > > could be completely different functions but (unfortunately) have the > > same name. > > > > > > > > > > > > > - > > > > ---------------------------------------------------------------------------------------------------------------- > > > > > > > > Lets there be a third package C, which also extends A. and it > > > > also defines a > > > > property c1 > > > > A termination realizes both package B and C. > > > > 4) what will be value of A/a1 which is referred by both B/a1 > > > > and C/a1. > > > > If B/a1 value is changed is it that the value of C/a1 is also > > > > changed? > > > > > > > > > > Based on my previous two responses, C/a1 would be changed, but this > > > situation is one that to me would indicate that the package hierarchy > > > has not been properly defined. I don't think this should ever happen. > > > > [CHG] I think A/al, B/al and C/al will all change because they are the > > same property. > > > > > > > > > > > > > > > > > -Madhubabu > > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 00:10:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24581 for ; Thu, 6 Jul 2000 00:10:43 -0400 (EDT) Received: from standards (47.234.32.16:1187) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B2BA@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:00:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8896 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 00:00:05 -0400 Received: from suraksha.wipsys.soft.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B2B1@standards.nortelnetworks.com>; Wed, 5 Jul 2000 23:50:02 -0400 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id JAA28421; Thu, 6 Jul 2000 09:26:47 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma028411; Thu, 6 Jul 00 09:26:31 +0530 Received: from wipro.com ([192.168.162.126]) by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAABB0; Thu, 6 Jul 2000 09:26:01 +0530 X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B2B@zcard00g.ca.nortel.com> <395BCA81.4830907@americasm10.nt.com> <395C47CF.D1C0F9AE@ericsson.com> <39607273.4AF3BAF0@lucent.com> <396380AA.EA672A12@americasm10.nt.com> Content-Type: multipart/mixed; boundary="------------46D82D056D3811991C905066" Message-ID: <39640252.9F70D34D@wipro.com> Date: Thu, 6 Jul 2000 09:21:47 +0530 Reply-To: Panditha Govindraj Sender: "Media Gateway Control (megaco)" From: Panditha Govindraj Organization: Wipro Technologies Subject: Re: Packages extension queries. X-To: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------46D82D056D3811991C905066 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, Can some body give some design suggestions about Megaco Parser , Which can really be efficient, Can we use lex yacc Govind Michael Brown wrote: > Ooops... My comment about ill defined package hierarchy was based on a misread on my part. John and Christian have set the > record straight. Sorry for the confusion. > > Michael > > John Segers wrote: > > > Hi, > > > > My understanding of the package extension mechanism is the same as that > > of Tom, Mike and Christian. One addition: if B and C both extend A, and > > B and C (independently) define a property x1, then B/x1 and C/x1 are > > different properties (as Christian indicated). So a change to B/x1 does > > not result in C/x1 changing as well. > > > > I don't completely that the package hierarchy is ill-defined per se in > > such a situation. It could be the case that B and C define regional > > extensions to an international package, and that my GW is a multi-region > > device. > > > > Cheers, > > > > John > > > > Christian Groves wrote: > > > > > > G'Day Michael and Tom, > > > > > > Please see my comments below marked CHG. > > > > > > Cheers, Christian > > > > > > Michael Brown wrote: > > > > > > > > Comments inline. > > > > > > > > Michael > > > > > > > > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > > > Sent: Thursday, June 29, 2000 1:36 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Packages extension queries. > > > > > > > > > > There are two packages A and B. Package B extends A, > > > > > Say, properties a1 and a2 are in package A and x1 in package B. > > > > > > > > > > 1) If a termination realizes package B, does it mean that it > > > > > also realizes > > > > > package A? > > > > > [PTT] > > > > > Yes. > > > > > > > > > > 2) Can property of package A be addressed as B/a1? If 1) is > > > > > true, is it that > > > > > only A/a1 is possible? > > > > > [PTT] > > > > > This was discussed in Red Bank when we finalized our package > > > > > schema, but I can't remember the conclusion. Christian, John, > > > > > or Michael, do you remember? > > > > > > > > > > > > > I remember that the answer (consensus) was that the preferable way to > > > > refer to a1 is as B/a1. One could use A/a1, because there really is > > > > only one property defined where both names refer to it. > > > > > > [CHG] That's what I understand. > > > > > > > > > > > > > > > > > Lets there be third package C, which also extends A. and it > > > > > also defines a > > > > > property x1 > > > > > 3) Can a termination realize packages B and C ? > > > > > > > > > > > > > Well, I would say that the answer is yes that a termination COULD > > > > realize both, but my feeling is that this situation would be due to a > > > > poor definition of the packages hierarchy. Given your hypothetical > > > > description rather than a real example where this would appear to be a > > > > desirable approach, I would think that C should extend B rather than > > > > A. > > > > > > [CHG] I'm not sure of the question or the response but to me even if two > > > packages B & C extend A with a property x1 then the two instances of x1 > > > are uniquely identified by the package name B&C. The two instances of x1 > > > could be completely different functions but (unfortunately) have the > > > same name. > > > > > > > > > > > > > > > > > - > > > > > ---------------------------------------------------------------------------------------------------------------- > > > > > > > > > > Lets there be a third package C, which also extends A. and it > > > > > also defines a > > > > > property c1 > > > > > A termination realizes both package B and C. > > > > > 4) what will be value of A/a1 which is referred by both B/a1 > > > > > and C/a1. > > > > > If B/a1 value is changed is it that the value of C/a1 is also > > > > > changed? > > > > > > > > > > > > > Based on my previous two responses, C/a1 would be changed, but this > > > > situation is one that to me would indicate that the package hierarchy > > > > has not been properly defined. I don't think this should ever happen. > > > > > > [CHG] I think A/al, B/al and C/al will all change because they are the > > > same property. > > > > > > > > > > > > > > > > > > > > > > -Madhubabu > > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 --------------46D82D056D3811991C905066 Content-Type: text/x-vcard; charset=us-ascii; name="govinda.rajp.vcf" Content-Description: Card for govindaraj Content-Disposition: attachment; filename="govinda.rajp.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Panditha;Govindaraj tel;pager:----------------------- tel;cell:----------------------- tel;fax:0091-44-2301532 tel;home:---------------------- tel;work:0091-44-2301530 x-mozilla-html:TRUE url:http://www.wipro.com org:Wipro ;Global R & D version:2.1 email;internet:govinda.rajp@wipro.com title:Senior Engineer Software note:We make a living by what we get, but we make a life by what we give. adr;quoted-printable:;;111 Anna Salai=0D=0AGuindy=0D=0A;Chennai;Tamil Nadu;600032;India fn:Govindaraj end:vcard --------------46D82D056D3811991C905066-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 00:15:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24612 for ; Thu, 6 Jul 2000 00:15:38 -0400 (EDT) Received: from standards (47.234.32.16:1187) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B2DD@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:05:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8950 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 00:05:24 -0400 Received: from ficon-tech.com (12.10.198.190:3298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B2DC@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:05:22 -0400 Received: from ficon-tech.com (vsalota.india.ficon-tech.com [172.25.1.107]) by ficon-tech.com (8.9.3/8.9.3) with ESMTP id JAA55312; Thu, 6 Jul 2000 09:43:56 +0530 (IST) (envelope-from vsalota@ficon-tech.com) X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <8E2783FA4E0CD411888D0000F8CD15D33C3835@zcard00q.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39640705.D0C50F18@ficon-tech.com> Date: Thu, 6 Jul 2000 09:41:49 +0530 Reply-To: Vikas Salota Sender: "Media Gateway Control (megaco)" From: Vikas Salota Subject: Re: Package extention X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think the desciprion about the package extension in Sec 12.1.1 already has the relevant text where it hints that a package can extend only one package at a time. I quote "Extends (Optional): A package may extend an existing package......." with regards Vikas Salota Peter Blatherwick wrote: > Original intent of the Extends mechanism when we designed it was to extend only one Package. The issues John raises below were considered, and value did not seem to warrant inherent extra confusion, risk of misinterpretation, additional design complexity, etc. Like multiple inheritance, its kinda cool, but not a good idea here IMHO. Keep it simple. > > Currently the answer is "no, cannot extend more than one package". If the text does not say this, it should be clarified in later version, implementation notes, or elsewhere. > > -- Peter > > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, July 05, 2000 03:06 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Package extention > > Madhu, Brian, > > I don't think that we should allow this. You run into problems if a > package C extends A and B, and A and B contain properties that have the > same name. What property does C/x refer to if A and B both have a > property x? > > John > > "Rosen, Brian" wrote: > > > > At first, I was inclined to say, "sure, why not" > > However, I'm worried about implementation difficulty. > > > > If it's hard to do, I think the utility is small. > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Monday, July 03, 2000 5:26 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Package extention > > > > > > > > > Can a package extends more than one package?? > > > -madhubabu > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 00:55:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25282 for ; Thu, 6 Jul 2000 00:55:19 -0400 (EDT) Received: from standards (47.234.32.16:4004) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B30D@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:45:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9010 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 00:45:03 -0400 Received: from ficon-tech.com (12.10.198.190:1516) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B30C@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:45:00 -0400 Received: from ficon-tech.com (vsalota.india.ficon-tech.com [172.25.1.107]) by ficon-tech.com (8.9.3/8.9.3) with ESMTP id KAA58773; Thu, 6 Jul 2000 10:13:33 +0530 (IST) (envelope-from vsalota@ficon-tech.com) X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6784CE@whq-msgusr-02.fore.com> <3962FEDA.BABAEE2E@cdotb.ernet.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39640DF6.238CF4CD@ficon-tech.com> Date: Thu, 6 Jul 2000 10:11:26 +0530 Reply-To: Vikas Salota Sender: "Media Gateway Control (megaco)" From: Vikas Salota Subject: Re: MG Service Change w.r.t. TCP as transport X-To: Titty Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Please see inline comments with VS. Titty Thomas wrote: > Hi, > > see the queries below, > > Thanks > > Titty Thomas > > "Rosen, Brian" wrote: > > > > Q1: Is MG allowed to include ServiceChangeAddress parameter > > > in case of TCP > > > as a transport? > > Yes, but it would be pretty unusual. > > > > > Q2: If answer to Q1 is yes, then is MGC supposed to establish > > > connection > > > back to MG on > > > the changed address? > > No, I think the MG would have to do that. > > > > [TT] Consider the scenario where MG sends a service change request with > the service change address included. > > Q.1) In this case when will MGC start accepting the transaction > requests through the new TCP connection?. VS> In case of a TCP connection, its the responsibility of MG to establish connection on the new address. MGC simply waits for messages on the established connections (as soon as they are established by MG) and responds back on the same connection. > > > Q.2) Is it after MGC has sent replies for all transaction requests > (including the service change request) it has > > received through the old connection?. VS> See above comment. > > > Q.3) When will MG establish the new TCP connection with the > MGC.? Is it after it has got the reply for the > > servicechange request it has sent? VS> MG establishes a new TCP connection with MGC on the new address after receiving a successful reply to the service changes request it sent. Moreover its the responsibility of MG to close the previous TCP connection with MGC. > > > Q.4) If the answer to Q.2 is true, then what is the error > MGC should return if MG sends a request > > before it has got a reply to servicechange request? VS> Although its not usual for MG to send messages to MGC when its expecting a new connection, Its not an error for MG to do so. MGC should reply to messages received on the "old" TCP connection even after it had sent a successful ServiceChange reply for a different address. For that matter should continue to do so until the connection is closed by MG. > > > > > > > > > > If Q1 and Q2 hold, then MG needs to has to implement a TCP Server. I > > > remember the discussion > > > along the line of MG implementing Server and MGC initiating > > > connection did > > > not reach any > > > conclusion. > > I don't think the MG needs a TCP server > > > > Brian > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 01:05:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25532 for ; Thu, 6 Jul 2000 01:05:08 -0400 (EDT) Received: from standards (47.234.32.16:4004) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B330@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:54:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9055 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 00:54:52 -0400 Received: from ficon-tech.com (12.10.198.190:1954) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B32F@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:54:49 -0400 Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by ficon-tech.com (8.9.3/8.9.3) with SMTP id KAA60495 for ; Thu, 6 Jul 2000 10:33:36 +0530 (IST) (envelope-from hemantag@globespan.net) 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 Message-ID: <00a901bfe707$9d7c0040$830119ac@india.ficontech.com> Date: Thu, 6 Jul 2000 10:34:05 +0530 Reply-To: Hemant Agrawal Sender: "Media Gateway Control (megaco)" From: Hemant Agrawal Organization: GlobeSpan.net Subject: topology descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, I have not received any response for my queries, so I am posting it again. An early response will be highly appreciated. Thanks Hemant > Hi all, > I have a couple of questions regarding the processing of context > properties. > > 1. When do we proces the topology descriptor in a Action Request ? > (a) Before processing any command in that action request or > (b) After processing all the commands in the action request. > > If it is in the end, then what should the audit of context properties > return? > (a) the context properties after applying the topology descriptor or > (b) previous context properties? > > > 2. How do we return a failure in applying the topology descriptor ? > If a topology descriptor fails, then should the > further processing of commands in the action request be stopped? > > Thanks & regards, > Hemant Agrawal > > ________________________________________ > Hemant Agrawal > GlobeSpan Inc > Tel: +91 575 4544028 ext 121 > E-mail:hemantag@globespan.net > Web: http://www.globespan.net > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 01:10:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26375 for ; Thu, 6 Jul 2000 01:10:50 -0400 (EDT) Received: from standards (47.234.32.16:4004) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B34C@standards.nortelnetworks.com>; Thu, 6 Jul 2000 1:00:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9051 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 01:00:33 -0400 Received: from mars.hss.co.in (202.54.26.197:33399) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B32B@standards.nortelnetworks.com>; Thu, 6 Jul 2000 0:50:31 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e664vHg01431; Wed, 5 Jul 2000 23:57:19 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256914.001A4909 ; Thu, 6 Jul 2000 10:17:06 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=vYLTt4WjghOL8bcxSKtR1SbH7zWez7bV8OOiEA9OYCjSi2jUBcm3htZu" Content-Disposition: inline Message-ID: <65256914.001A48A9.00@sandesh.hss.hns.com> Date: Thu, 6 Jul 2000 10:17:04 +0530 Reply-To: rpatil@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Rajendra Patil Subject: Re: Packages extension queries. X-To: Panditha Govindraj To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=vYLTt4WjghOL8bcxSKtR1SbH7zWez7bV8OOiEA9OYCjSi2jUBcm3htZu Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Lex-Yacc code may not be MT safe. May be you can try reguler expressions lib. Check regcmp/regex functions available in libgen.h Hope this helps Regards/ Rajendra Panditha Govindraj on 07/06/2000 09:21:47 AM Please respond to Panditha Govindraj To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: Subject: Re: Packages extension queries. Hi All, Can some body give some design suggestions about Megaco Parser , Which can really be efficient, Can we use lex yacc Govind --0__=vYLTt4WjghOL8bcxSKtR1SbH7zWez7bV8OOiEA9OYCjSi2jUBcm3htZu Content-type: application/octet-stream; name="govinda.rajp.vcf" Content-Disposition: attachment; filename="govinda.rajp.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQNCm46UGFuZGl0aGE7R292aW5kYXJhag0KdGVsO3BhZ2VyOi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQp0ZWw7Y2VsbDotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KdGVsO2ZheDow MDkxLTQ0LTIzMDE1MzINCnRlbDtob21lOi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnRlbDt3b3Jr OjAwOTEtNDQtMjMwMTUzMA0KeC1tb3ppbGxhLWh0bWw6VFJVRQ0KdXJsOmh0dHA6Ly93d3cud2lw cm8uY29tDQpvcmc6V2lwcm8gO0dsb2JhbCBSICYgRA0KdmVyc2lvbjoyLjENCmVtYWlsO2ludGVy bmV0OmdvdmluZGEucmFqcEB3aXByby5jb20NCnRpdGxlOlNlbmlvciBFbmdpbmVlciBTb2Z0d2Fy ZQ0Kbm90ZTpXZSBtYWtlIGEgbGl2aW5nIGJ5IHdoYXQgd2UgZ2V0LCBidXQgd2UgbWFrZSBhIGxp ZmUgYnkgd2hhdCB3ZSBnaXZlLg0KYWRyO3F1b3RlZC1wcmludGFibGU6OzsxMTEgQW5uYSBTYWxh aT0wRD0wQUd1aW5keT0wRD0wQTtDaGVubmFpO1RhbWlsIE5hZHU7NjAwMDMyO0luZGlhDQpmbjpH b3ZpbmRhcmFqDQplbmQ6dmNhcmQNCg0K --0__=vYLTt4WjghOL8bcxSKtR1SbH7zWez7bV8OOiEA9OYCjSi2jUBcm3htZu-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 03:12:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08986 for ; Thu, 6 Jul 2000 03:12:43 -0400 (EDT) Received: from standards (47.234.32.16:4440) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B3A6@standards.nortelnetworks.com>; Thu, 6 Jul 2000 3:02:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9205 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 03:02:13 -0400 Received: from mars.hss.co.in (202.54.26.197:34544) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B3A2@standards.nortelnetworks.com>; Thu, 6 Jul 2000 2:52:12 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6673Ug03635 for ; Thu, 6 Jul 2000 02:03:32 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256914.0025D7D0 ; Thu, 6 Jul 2000 12:23:20 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256914.0025D6EE.00@sandesh.hss.hns.com> Date: Thu, 6 Jul 2000 12:32:39 +0530 Reply-To: svkumar@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Shiv Kumar Subject: Duplicate Token To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, A small correction in the abbreviated tokens list. The token "EB" is used for both EmbedToken and EventBufferToken. Pls correct it. BTW, can we have a text message containing both the abbreviated tokens and their longer versions ? i.e. is this kind of msg allowed.... MEGACO/1 [123.123.123.4]:55555 T = 50007 { Context = - {AuditValue = A5556{ Audit {M, DM, E, SG, PG, SA }} } } Is it necessary that the name of the tokens shall be Case Senstive. For example, should " AuditValue" be treated same as "auditvalue". Please do clarify. Regards, Shiv From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 06:32:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10834 for ; Thu, 6 Jul 2000 06:32:48 -0400 (EDT) Received: from standards (47.234.32.16:2245) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B5EA@standards.nortelnetworks.com>; Thu, 6 Jul 2000 6:22:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9936 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 06:22:25 -0400 Received: from suraksha.wipsys.soft.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7B5E9@standards.nortelnetworks.com>; Thu, 6 Jul 2000 6:22:23 -0400 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id PAA07878; Thu, 6 Jul 2000 15:59:14 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma007863; Thu, 6 Jul 00 15:58:55 +0530 Received: from wipro.com ([192.168.162.126]) by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA3983 for ; Thu, 6 Jul 2000 15:58:25 +0530 X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F241A8F16DE493712688434B" Message-ID: <39645E48.83517B39@wipro.com> Date: Thu, 6 Jul 2000 15:54:09 +0530 Reply-To: Panditha Govindraj Sender: "Media Gateway Control (megaco)" From: Panditha Govindraj Organization: Wipro Technologies Subject: subscribe megaco To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------F241A8F16DE493712688434B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe megaco --------------F241A8F16DE493712688434B Content-Type: text/x-vcard; charset=us-ascii; name="govinda.rajp.vcf" Content-Description: Card for govindaraj Content-Disposition: attachment; filename="govinda.rajp.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Panditha;Govindaraj tel;pager:----------------------- tel;cell:----------------------- tel;fax:0091-44-2301532 tel;home:---------------------- tel;work:0091-44-2301530 x-mozilla-html:TRUE url:http://www.wipro.com org:Wipro ;Global R & D version:2.1 email;internet:govinda.rajp@wipro.com title:Senior Engineer Software note:We make a living by what we get, but we make a life by what we give. adr;quoted-printable:;;111 Anna Salai=0D=0AGuindy=0D=0A;Chennai;Tamil Nadu;600032;India fn:Govindaraj end:vcard --------------F241A8F16DE493712688434B-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 21:03:50 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28350 for ; Thu, 6 Jul 2000 21:03:50 -0400 (EDT) Received: from standards (47.234.32.16:4281) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BA5D@standards.nortelnetworks.com>; Thu, 6 Jul 2000 20:53:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0970 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 20:53:12 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BA5C@standards.nortelnetworks.com>; Thu, 6 Jul 2000 20:53:11 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA11941; Thu, 6 Jul 2000 21:03:04 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA10693; Thu, 6 Jul 2000 21:03:07 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 21:02:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01162943@whq-msgusr-02.fore.com> Date: Thu, 6 Jul 2000 21:03:05 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Packages extension queries. X-To: Panditha Govindraj To: MEGACO@STANDARDS.NORTELNETWORKS.COM Some folks are indeed using a yacc/lex based parser. Others are constructing an LL(1) parser. I wouldn't be surprised if there were others out there. Yacc/Lex is likely to be easy, but is also likely to be pretty big (code size). LL(1) is likely to be pretty small and efficient. I doubt that parsing is going to be a big deal, although I suspect when we talk about binary vs text, that issue will come up. If you are good at parser construction, I'd probably suggest looking at something like LL(1). If you aren't, yacc/lex (or the GNU equivalents) are likely to work best for you -- YMMV. Brian > -----Original Message----- > From: Panditha Govindraj [mailto:govinda.rajp@WIPRO.COM] > Sent: Wednesday, July 05, 2000 11:52 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Packages extension queries. > > > Hi All, > > Can some body give some design suggestions about Megaco > Parser , Which can really be efficient, > > Can we use lex yacc > > Govind > > > Michael Brown wrote: > > > Ooops... My comment about ill defined package hierarchy was > based on a misread on my part. John and Christian have set the > > record straight. Sorry for the confusion. > > > > Michael > > > > John Segers wrote: > > > > > Hi, > > > > > > My understanding of the package extension mechanism is > the same as that > > > of Tom, Mike and Christian. One addition: if B and C > both extend A, and > > > B and C (independently) define a property x1, then B/x1 > and C/x1 are > > > different properties (as Christian indicated). So a > change to B/x1 does > > > not result in C/x1 changing as well. > > > > > > I don't completely that the package hierarchy is > ill-defined per se in > > > such a situation. It could be the case that B and C > define regional > > > extensions to an international package, and that my GW is > a multi-region > > > device. > > > > > > Cheers, > > > > > > John > > > > > > Christian Groves wrote: > > > > > > > > G'Day Michael and Tom, > > > > > > > > Please see my comments below marked CHG. > > > > > > > > Cheers, Christian > > > > > > > > Michael Brown wrote: > > > > > > > > > > Comments inline. > > > > > > > > > > Michael > > > > > > > > > > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote: > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > > > > > > Sent: Thursday, June 29, 2000 1:36 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Packages extension queries. > > > > > > > > > > > > There are two packages A and B. Package B extends A, > > > > > > Say, properties a1 and a2 are in package A and > x1 in package B. > > > > > > > > > > > > 1) If a termination realizes package B, does > it mean that it > > > > > > also realizes > > > > > > package A? > > > > > > [PTT] > > > > > > Yes. > > > > > > > > > > > > 2) Can property of package A be addressed as > B/a1? If 1) is > > > > > > true, is it that > > > > > > only A/a1 is possible? > > > > > > [PTT] > > > > > > This was discussed in Red Bank when we > finalized our package > > > > > > schema, but I can't remember the conclusion. > Christian, John, > > > > > > or Michael, do you remember? > > > > > > > > > > > > > > > > I remember that the answer (consensus) was that the > preferable way to > > > > > refer to a1 is as B/a1. One could use A/a1, because > there really is > > > > > only one property defined where both names refer to it. > > > > > > > > [CHG] That's what I understand. > > > > > > > > > > > > > > > > > > > > > Lets there be third package C, which also > extends A. and it > > > > > > also defines a > > > > > > property x1 > > > > > > 3) Can a termination realize packages B and C ? > > > > > > > > > > > > > > > > Well, I would say that the answer is yes that a > termination COULD > > > > > realize both, but my feeling is that this situation > would be due to a > > > > > poor definition of the packages hierarchy. Given > your hypothetical > > > > > description rather than a real example where this > would appear to be a > > > > > desirable approach, I would think that C should > extend B rather than > > > > > A. > > > > > > > > [CHG] I'm not sure of the question or the response but > to me even if two > > > > packages B & C extend A with a property x1 then the two > instances of x1 > > > > are uniquely identified by the package name B&C. The > two instances of x1 > > > > could be completely different functions but > (unfortunately) have the > > > > same name. > > > > > > > > > > > > > > > > > > > > > - > > > > > > > -------------------------------------------------------------- > -------------------------------------------------- > > > > > > > > > > > > Lets there be a third package C, which also > extends A. and it > > > > > > also defines a > > > > > > property c1 > > > > > > A termination realizes both package B and C. > > > > > > 4) what will be value of A/a1 which is > referred by both B/a1 > > > > > > and C/a1. > > > > > > If B/a1 value is changed is it that the value > of C/a1 is also > > > > > > changed? > > > > > > > > > > > > > > > > Based on my previous two responses, C/a1 would be > changed, but this > > > > > situation is one that to me would indicate that the > package hierarchy > > > > > has not been properly defined. I don't think this > should ever happen. > > > > > > > > [CHG] I think A/al, B/al and C/al will all change > because they are the > > > > same property. > > > > > > > > > > > > > > > > > > > > > > > > > > > -Madhubabu > > > > > > > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 21:09:52 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28352 for ; Thu, 6 Jul 2000 21:03:50 -0400 (EDT) Received: from standards (47.234.32.16:4281) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BA68@standards.nortelnetworks.com>; Thu, 6 Jul 2000 20:53:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0984 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 20:53:21 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BA67@standards.nortelnetworks.com>; Thu, 6 Jul 2000 20:53:21 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA11959; Thu, 6 Jul 2000 21:03:14 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id VAA10719; Thu, 6 Jul 2000 21:03:17 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jul 2000 21:03:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01162944@whq-msgusr-02.fore.com> Date: Thu, 6 Jul 2000 21:03:07 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Duplicate Token X-To: svkumar@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Wow, a real bug! Something crept into the syntax that I never noticed (or forgot) For some reason, Event=123{al/hu{Event{al/hd}} got changed to Event=123{al/hu{Embed{Event{al/hd))) thus necessitating EmbedToken I can't see why this was done, but assuming there is a good reason, the best idea I have is to make Emergency "EMG" and then make Embed "EM" I thought we agreed tokens were NOT case sensitive Yes you can mix long and short tokens. I'd recommend that: parsers always accept either generators have an internal switch (some kind of debug thing) that can be set to long or short The latter is a good reason to have a real message generator rather than using literal strings in your code == just a suggestion. Brian > -----Original Message----- > From: Shiv Kumar [mailto:svkumar@HSS.HNS.COM] > Sent: Thursday, July 06, 2000 3:03 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Duplicate Token > > > Hi, > > A small correction in the abbreviated tokens list. > > The token "EB" is used for both EmbedToken and EventBufferToken. > Pls correct it. > > BTW, can we have a text message containing both the > abbreviated tokens > and their longer versions ? > > i.e. is this kind of msg allowed.... > > MEGACO/1 [123.123.123.4]:55555 > T = 50007 { > Context = - {AuditValue = A5556{ > Audit {M, DM, E, SG, PG, SA }} > } > } > > Is it necessary that the name of the tokens shall be Case > Senstive. For example, > should " AuditValue" > be treated same as "auditvalue". Please do clarify. > > > Regards, > Shiv > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 21:46:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29906 for ; Thu, 6 Jul 2000 21:46:01 -0400 (EDT) Received: from standards (47.234.32.16:1952) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BAAC@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:35:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1074 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 21:35:44 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BAAA@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:25:44 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e671Zdb16549 for ; Fri, 7 Jul 2000 03:35:39 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA04477 for ; Fri, 7 Jul 2000 03:35:38 +0200 (MET DST) Received: from ericsson.com (mc2dh148.epa.ericsson.se [146.11.87.148]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA28082 for ; Fri, 7 Jul 2000 03:35:35 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3962E4E5.3259A443@cdotb.ernet.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396533E4.C81CD99@ericsson.com> Date: Fri, 7 Jul 2000 11:35:32 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: mid clarification ? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day, An mtpAddress is an addressing concept from SS7 signalling networks for the MTP part under ISUP. The format of the mtpAddress is given in the encoding sections and consists of a pointcode and network indicator. Cheers, Christian Titty Thomas wrote: > > Hi, > > The megaco draft says > > mid can be either domainAddress / domainName / mtpAddress / > deviceName. > > domainAddress can be either IP v4 address / IPv6address > > And I think domainName is like this - abc@xyz.com. Am I correct?. > > Can anyone give examples for mtpAddress and deviceName? > > Thanks in advance, > > Titty Thomas From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 21:53:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00023 for ; Thu, 6 Jul 2000 21:53:36 -0400 (EDT) Received: from standards (47.234.32.16:1952) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BACF@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:43:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1075 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 21:43:22 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BAAB@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:33:21 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e671hDb17490 for ; Fri, 7 Jul 2000 03:43:17 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA04536 for ; Fri, 7 Jul 2000 03:43:13 +0200 (MET DST) Received: from ericsson.com (mc2dh148.epa.ericsson.se [146.11.87.148]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA28086 for ; Fri, 7 Jul 2000 03:43:10 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <65256913.0049B479.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396535AC.C34A1186@ericsson.com> Date: Fri, 7 Jul 2000 11:43:08 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: ACodec (Media Stream Property) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Kapil, The ACodec type can be found in the Q.765.5 in sect 11.1.7 http://www.itu.int/itudoc/itu-t/com11/reports/rep5/r244.html Cheers, Christian Kapil Nayar wrote: > > Reference : draft-...-merged-01....Annexure C TAGS FOR ....C.1 General Media > ....ACodec (Audio Codec Type) > > Can somebody point me to the location (where I can find ACodec) in ITU-T > Rec.Q.765 refered to in the MEGACO draft. > > Kapil From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 21:56:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00046 for ; Thu, 6 Jul 2000 21:56:46 -0400 (EDT) Received: from standards (47.234.32.16:1952) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BAF0@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:46:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1103 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 21:46:27 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BAC1@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:36:27 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e671kNb17789 for ; Fri, 7 Jul 2000 03:46:23 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA04576 for ; Fri, 7 Jul 2000 03:46:22 +0200 (MET DST) Received: from ericsson.com (mc2dh148.epa.ericsson.se [146.11.87.148]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA28090 for ; Fri, 7 Jul 2000 03:46:20 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <00a901bfe707$9d7c0040$830119ac@india.ficontech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39653669.524326DD@ericsson.com> Date: Fri, 7 Jul 2000 11:46:17 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: topology descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Hemant, Processing is before commands in the action request. I would assume the topology descriptor follows the same behaviour as a failed command in a sequence of commands. Cheers, Christian Hemant Agrawal wrote: > > Hi all, > I have not received any response for my queries, so I am posting it > again. > An early response will be highly appreciated. > > Thanks > Hemant > > > Hi all, > > I have a couple of questions regarding the processing of context > > properties. > > > > 1. When do we proces the topology descriptor in a Action Request ? > > (a) Before processing any command in that action request or > > (b) After processing all the commands in the action request. > > > > If it is in the end, then what should the audit of context properties > > return? > > (a) the context properties after applying the topology descriptor or > > (b) previous context properties? > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > If a topology descriptor fails, then should the > > further processing of commands in the action request be stopped? > > > > Thanks & regards, > > Hemant Agrawal > > > > ________________________________________ > > Hemant Agrawal > > GlobeSpan Inc > > Tel: +91 575 4544028 ext 121 > > E-mail:hemantag@globespan.net > > Web: http://www.globespan.net > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 6 22:03:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00177 for ; Thu, 6 Jul 2000 22:03:00 -0400 (EDT) Received: from standards (47.234.32.16:1952) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BB19@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:52:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1120 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jul 2000 21:52:45 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BACE@standards.nortelnetworks.com>; Thu, 6 Jul 2000 21:42:45 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e671qeb18609 for ; Fri, 7 Jul 2000 03:52:40 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA04615 for ; Fri, 7 Jul 2000 03:52:39 +0200 (MET DST) Received: from ericsson.com (mc2dh148.epa.ericsson.se [146.11.87.148]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA28095 for ; Fri, 7 Jul 2000 03:52:37 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396537E2.9E902B20@ericsson.com> Date: Fri, 7 Jul 2000 11:52:34 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: 7 or 8 bit encoding?? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, Could someone confirm the type of encoding we are using for the text version of Megaco. In Annex B ABNF is mentions that it is compliant to RFC2234 which in turn talks about being encoded in 7bit US-ASCII. However the SDP part of the text encoding talks about being compliant to SDP RFC2327 which in turn mention the text below: 6. SDP Specification SDP session descriptions are entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attributes names use only the US-ASCII subset of UTF-8, but textual fields and attribute values may use the full ISO 10646 character set. It seems a mess to me if we are using 7bit encoding and 8 bit encoding in the same encoding. I hope someone can confirm that we are using UTF-8 encoding for H248 text description because the protocol doesn't really state this. Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 00:30:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03051 for ; Fri, 7 Jul 2000 00:30:21 -0400 (EDT) Received: from standards (47.234.32.16:3783) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BB87@standards.nortelnetworks.com>; Fri, 7 Jul 2000 0:19:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1364 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 00:19:54 -0400 Received: from ficon-tech.com (12.10.198.190:4967) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BB86@standards.nortelnetworks.com>; Fri, 7 Jul 2000 0:19:51 -0400 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.9.3) with ESMTP id JAA22424; Fri, 7 Jul 2000 09:58:23 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <00a901bfe707$9d7c0040$830119ac@india.ficontech.com> <39653669.524326DD@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39655C54.4A8AF18A@ficon-tech.com> Date: Fri, 7 Jul 2000 09:58:05 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Globespan Inc. Subject: Re: topology descriptor X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Christian, and all, Consider a transaction request containing the topology descriptor (involving two terminations TermA and TermB) followed by two Add command requests adding TermA and TermB into a new context. Now, would the processing of Topology Descriptor before that of the commands make sense. IMHO, first the context should get created, then the terminations should be added to the context and then finally the topology should be set between the terminations as required. The requirement of delaying the processing of Topology descriptor becomes even more relevant when a choose termination ($) is specified in it. In this case, when the topology descriptor is taken up for processing, the termination is not known. Topology can be set only after a subsequent add command specifying the choose termination and its descriptors has been processed. Regards, Shalini Philip. Christian Groves wrote: > G'Day Hemant, > > Processing is before commands in the action request. I would assume the > topology descriptor follows the same behaviour as a failed command in a > sequence of commands. > > Cheers, Christian > > Hemant Agrawal wrote: > > > > Hi all, > > I have not received any response for my queries, so I am posting it > > again. > > An early response will be highly appreciated. > > > > Thanks > > Hemant > > > > > Hi all, > > > I have a couple of questions regarding the processing of context > > > properties. > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > (a) Before processing any command in that action request or > > > (b) After processing all the commands in the action request. > > > > > > If it is in the end, then what should the audit of context properties > > > return? > > > (a) the context properties after applying the topology descriptor or > > > (b) previous context properties? > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > If a topology descriptor fails, then should the > > > further processing of commands in the action request be stopped? > > > > > > Thanks & regards, > > > Hemant Agrawal > > > > > > ________________________________________ > > > Hemant Agrawal > > > GlobeSpan Inc > > > Tel: +91 575 4544028 ext 121 > > > E-mail:hemantag@globespan.net > > > Web: http://www.globespan.net > > > -- Regards, Shalini Philip Globespan Inc. E-Mail : mailto:sphilip@globespan.net Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 01:08:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03716 for ; Fri, 7 Jul 2000 01:08:03 -0400 (EDT) Received: from standards (47.234.32.16:1251) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BBA7@standards.nortelnetworks.com>; Fri, 7 Jul 2000 0:57:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1402 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 00:57:40 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BBA3@standards.nortelnetworks.com>; Fri, 7 Jul 2000 0:47:40 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e674vZb13670 for ; Fri, 7 Jul 2000 06:57:36 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id GAA07043 for ; Fri, 7 Jul 2000 06:57:35 +0200 (MET DST) Received: from ericsson.com (mc2dh148.epa.ericsson.se [146.11.87.148]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id GAA28225 for ; Fri, 7 Jul 2000 06:57:33 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <00a901bfe707$9d7c0040$830119ac@india.ficontech.com> <39653669.524326DD@ericsson.com> <39655BFD.259B07F5@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39656335.78F380A6@ericsson.com> Date: Fri, 7 Jul 2000 14:57:25 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: topology descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Shalini, The point of the topology is that a context doesn't get created with a star connection between Ta and Tb first and then gets modified. The context gets created according to how the topology modifies it. ie. You must know how the topology is modifed before you can add the termination. Cheers, Christian Shalini Philip wrote: > > Hello Christian, and all, > > Consider a transaction request containing the topology descriptor (involving > two terminations TermA and TermB) followed by two Add command requests adding > TermA and TermB into a new context. Now, would the processing of Topology > Descriptor before that of the commands make sense. IMHO, first the context should > get created, then the terminations should be added to the context and then finally > the topology should be set between the terminations as required. > > The requirement of delaying the processing of Topology descriptor becomes even > more relevant when a choose termination ($) is specified in it. In this case, when > the topology descriptor is taken up for processing, the termination is not known. > Topology can be set only after a subsequent add command specifying the choose > termination and its descriptors has been processed. > > Regards, > Shalini Philip. > > Christian Groves wrote: > > > G'Day Hemant, > > > > Processing is before commands in the action request. I would assume the > > topology descriptor follows the same behaviour as a failed command in a > > sequence of commands. > > > > Cheers, Christian > > > > Hemant Agrawal wrote: > > > > > > Hi all, > > > I have not received any response for my queries, so I am posting it > > > again. > > > An early response will be highly appreciated. > > > > > > Thanks > > > Hemant > > > > > > > Hi all, > > > > I have a couple of questions regarding the processing of context > > > > properties. > > > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > > (a) Before processing any command in that action request or > > > > (b) After processing all the commands in the action request. > > > > > > > > If it is in the end, then what should the audit of context properties > > > > return? > > > > (a) the context properties after applying the topology descriptor or > > > > (b) previous context properties? > > > > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > > If a topology descriptor fails, then should the > > > > further processing of commands in the action request be stopped? > > > > > > > > Thanks & regards, > > > > Hemant Agrawal > > > > > > > > ________________________________________ > > > > Hemant Agrawal > > > > GlobeSpan Inc > > > > Tel: +91 575 4544028 ext 121 > > > > E-mail:hemantag@globespan.net > > > > Web: http://www.globespan.net > > > > > > -- > Regards, > > Shalini Philip > Globespan Inc. > E-Mail : mailto:sphilip@globespan.net > Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 01:23:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05864 for ; Fri, 7 Jul 2000 01:23:21 -0400 (EDT) Received: from standards (47.234.32.16:1251) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BBD5@standards.nortelnetworks.com>; Fri, 7 Jul 2000 1:13:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1465 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 01:13:05 -0400 Received: from ficon-tech.com (12.10.198.190:3768) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BBD4@standards.nortelnetworks.com>; Fri, 7 Jul 2000 1:13:03 -0400 Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by ficon-tech.com (8.9.3/8.9.3) with SMTP id KAA28299; Fri, 7 Jul 2000 10:51:36 +0530 (IST) (envelope-from hemantag@globespan.net) References: <00a901bfe707$9d7c0040$830119ac@india.ficontech.com> <39653669.524326DD@ericsson.com> <39655BFD.259B07F5@ficon-tech.com> <39656335.78F380A6@ericsson.com> 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 Message-ID: <011901bfe7d3$4a61c3a0$830119ac@india.ficontech.com> Date: Fri, 7 Jul 2000 10:52:00 +0530 Reply-To: Hemant Agrawal Sender: "Media Gateway Control (megaco)" From: Hemant Agrawal Organization: GlobeSpan.net Subject: Re: topology descriptor X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Christian, Thanks for your reply, I doubt if we can report the failure in topology descriptor processing as a failed command, because the command reply does not have the topology token. Another possibility is to report it as an Action level error. But still we do not have any error code to give the reason as Topology Application Failure. Thanks Hemant > > Christian Groves wrote: > > > > > G'Day Hemant, > > > > > > Processing is before commands in the action request. I would assume the > > > topology descriptor follows the same behaviour as a failed command in a > > > sequence of commands. > > > > > > Cheers, Christian > > > > > > Hemant Agrawal wrote: > > > > > > > > Hi all, > > > > I have not received any response for my queries, so I am posting it > > > > again. > > > > An early response will be highly appreciated. > > > > > > > > Thanks > > > > Hemant > > > > > > > > > Hi all, > > > > > I have a couple of questions regarding the processing of context > > > > > properties. > > > > > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > > > (a) Before processing any command in that action request or > > > > > (b) After processing all the commands in the action request. > > > > > > > > > > If it is in the end, then what should the audit of context properties > > > > > return? > > > > > (a) the context properties after applying the topology descriptor or > > > > > (b) previous context properties? > > > > > > > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > > > If a topology descriptor fails, then should the > > > > > further processing of commands in the action request be stopped? > > > > > > > > > > Thanks & regards, > > > > > Hemant Agrawal > > > > > > > > > > ________________________________________ > > > > > Hemant Agrawal > > > > > GlobeSpan Inc > > > > > Tel: +91 575 4544028 ext 121 > > > > > E-mail:hemantag@globespan.net > > > > > Web: http://www.globespan.net > > > > > > > > > -- > > Regards, > > > > Shalini Philip > > Globespan Inc. > > E-Mail : mailto:sphilip@globespan.net > > Web : http://www.globespan.net > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 01:42:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08733 for ; Fri, 7 Jul 2000 01:41:59 -0400 (EDT) Received: from standards (47.234.32.16:3963) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BBFE@standards.nortelnetworks.com>; Fri, 7 Jul 2000 1:31:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1519 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 01:31:42 -0400 Received: from ficon-tech.com (12.10.198.190:4299) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BBFD@standards.nortelnetworks.com>; Fri, 7 Jul 2000 1:31:39 -0400 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.9.3) with ESMTP id LAA29539; Fri, 7 Jul 2000 11:10:00 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <00a901bfe707$9d7c0040$830119ac@india.ficontech.com> <39653669.524326DD@ericsson.com> <39655BFD.259B07F5@ficon-tech.com> <39656335.78F380A6@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39656D1C.CAD47610@ficon-tech.com> Date: Fri, 7 Jul 2000 11:09:41 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Globespan Inc. Subject: Re: topology descriptor X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Christian and others, Thanks for your prompt reply. I fully agree with your views on Topology. The topology descriptor should be processed at the beginning and should be applied to the terminations already part of the specified context and on the rest of the terminations as and when they are added to the context. Another question remains about the processing of Audit Context Properties. Consider a situation where both Context properties and audit context properties are present in the same action. I think the context audit should return the latest context properties (taking into account the context properties specified in the same action). Now if there is an unresolved termination ($) in the context properties, then the context audit should return the context properties after resolving the termination. For this the processing of context audit will have to wait till the Add command adding the termination to the context is processed. Regards, Shalini Philip. Christian Groves wrote: > G'Day Shalini, > > The point of the topology is that a context doesn't get created with a > star connection between Ta and Tb first and then gets modified. The > context gets created according to how the topology modifies it. ie. You > must know how the topology is modifed before you can add the > termination. > > Cheers, Christian > > Shalini Philip wrote: > > > > Hello Christian, and all, > > > > Consider a transaction request containing the topology descriptor (involving > > two terminations TermA and TermB) followed by two Add command requests adding > > TermA and TermB into a new context. Now, would the processing of Topology > > Descriptor before that of the commands make sense. IMHO, first the context should > > get created, then the terminations should be added to the context and then finally > > the topology should be set between the terminations as required. > > > > The requirement of delaying the processing of Topology descriptor becomes even > > more relevant when a choose termination ($) is specified in it. In this case, when > > the topology descriptor is taken up for processing, the termination is not known. > > Topology can be set only after a subsequent add command specifying the choose > > termination and its descriptors has been processed. > > > > Regards, > > Shalini Philip. > > > > Christian Groves wrote: > > > > > G'Day Hemant, > > > > > > Processing is before commands in the action request. I would assume the > > > topology descriptor follows the same behaviour as a failed command in a > > > sequence of commands. > > > > > > Cheers, Christian > > > > > > Hemant Agrawal wrote: > > > > > > > > Hi all, > > > > I have not received any response for my queries, so I am posting it > > > > again. > > > > An early response will be highly appreciated. > > > > > > > > Thanks > > > > Hemant > > > > > > > > > Hi all, > > > > > I have a couple of questions regarding the processing of context > > > > > properties. > > > > > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > > > (a) Before processing any command in that action request or > > > > > (b) After processing all the commands in the action request. > > > > > > > > > > If it is in the end, then what should the audit of context properties > > > > > return? > > > > > (a) the context properties after applying the topology descriptor or > > > > > (b) previous context properties? > > > > > > > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > > > If a topology descriptor fails, then should the > > > > > further processing of commands in the action request be stopped? > > > > > > > > > > Thanks & regards, > > > > > Hemant Agrawal > > > > > > > > > > ________________________________________ > > > > > Hemant Agrawal > > > > > GlobeSpan Inc > > > > > Tel: +91 575 4544028 ext 121 > > > > > E-mail:hemantag@globespan.net > > > > > Web: http://www.globespan.net > > > > > > > > > -- > > Regards, > > > > Shalini Philip > > Globespan Inc. > > E-Mail : mailto:sphilip@globespan.net > > Web : http://www.globespan.net -- Regards, Shalini Philip Globespan Inc. E-Mail : mailto:sphilip@globespan.net Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 01:58:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08848 for ; Fri, 7 Jul 2000 01:58:26 -0400 (EDT) Received: from standards (47.234.32.16:3963) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BC44@standards.nortelnetworks.com>; Fri, 7 Jul 2000 1:48:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1609 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 01:48:09 -0400 Received: from mars.hss.co.in (202.54.26.197:43181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BC42@standards.nortelnetworks.com>; Fri, 7 Jul 2000 1:48:07 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e675xVg19482 for ; Fri, 7 Jul 2000 00:59:32 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256915.001FFC03 ; Fri, 7 Jul 2000 11:19:21 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256915.001FFB36.00@sandesh.hss.hns.com> Date: Fri, 7 Jul 2000 11:23:57 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: Package extention To: MEGACO@STANDARDS.NORTELNETWORKS.COM Lets make that explicit by stating "a package may extend only one existing package". - Vikas Salota on 07/06/2000 09:41:49 AM Please respond to Vikas Salota To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: Package extention I think the desciprion about the package extension in Sec 12.1.1 already has the relevant text where it hints that a package can extend only one package at a time. I quote "Extends (Optional): A package may extend an existing package......." with regards Vikas Salota Peter Blatherwick wrote: > Original intent of the Extends mechanism when we designed it was to extend only one Package. The issues John raises below were considered, and value did not seem to warrant inherent extra confusion, risk of misinterpretation, additional design complexity, etc. Like multiple inheritance, its kinda cool, but not a good idea here IMHO. Keep it simple. > > Currently the answer is "no, cannot extend more than one package". If the text does not say this, it should be clarified in later version, implementation notes, or elsewhere. > > -- Peter > > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, July 05, 2000 03:06 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Package extention > > Madhu, Brian, > > I don't think that we should allow this. You run into problems if a > package C extends A and B, and A and B contain properties that have the > same name. What property does C/x refer to if A and B both have a > property x? > > John > > "Rosen, Brian" wrote: > > > > At first, I was inclined to say, "sure, why not" > > However, I'm worried about implementation difficulty. > > > > If it's hard to do, I think the utility is small. > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Monday, July 03, 2000 5:26 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Package extention > > > > > > > > > Can a package extends more than one package?? > > > -madhubabu > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 02:28:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15818 for ; Fri, 7 Jul 2000 02:28:04 -0400 (EDT) Received: from standards (47.234.32.16:3763) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BC70@standards.nortelnetworks.com>; Fri, 7 Jul 2000 2:17:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1667 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 02:17:39 -0400 Received: from mars.hss.co.in (202.54.26.197:43469) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BC6F@standards.nortelnetworks.com>; Fri, 7 Jul 2000 2:17:37 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e676T1g20042 for ; Fri, 7 Jul 2000 01:29:03 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256915.0022AFF1 ; Fri, 7 Jul 2000 11:48:52 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256915.0022AF5D.00@sandesh.hss.hns.com> Date: Fri, 7 Jul 2000 11:53:10 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: topology descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, This means that topology descriptor should be reexecuted every time there is change in the number of terminations in the context? and it is not executed at the instant when it is received. When a new topology descriptor is specfiied does it mean that together with the earlier topology rules, the new rules are executed in order if there is a change in the number of terminations in the context. This means that topology descriptor always adds new rules and assume to retain the earlier rules. -Madhubabu Christian Groves on 07/07/2000 10:27:25 AM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: topology descriptor G'Day Shalini, The point of the topology is that a context doesn't get created with a star connection between Ta and Tb first and then gets modified. The context gets created according to how the topology modifies it. ie. You must know how the topology is modifed before you can add the termination. Cheers, Christian Shalini Philip wrote: > > Hello Christian, and all, > > Consider a transaction request containing the topology descriptor (involving > two terminations TermA and TermB) followed by two Add command requests adding > TermA and TermB into a new context. Now, would the processing of Topology > Descriptor before that of the commands make sense. IMHO, first the context should > get created, then the terminations should be added to the context and then finally > the topology should be set between the terminations as required. > > The requirement of delaying the processing of Topology descriptor becomes even > more relevant when a choose termination ($) is specified in it. In this case, when > the topology descriptor is taken up for processing, the termination is not known. > Topology can be set only after a subsequent add command specifying the choose > termination and its descriptors has been processed. > > Regards, > Shalini Philip. > > Christian Groves wrote: > > > G'Day Hemant, > > > > Processing is before commands in the action request. I would assume the > > topology descriptor follows the same behaviour as a failed command in a > > sequence of commands. > > > > Cheers, Christian > > > > Hemant Agrawal wrote: > > > > > > Hi all, > > > I have not received any response for my queries, so I am posting it > > > again. > > > An early response will be highly appreciated. > > > > > > Thanks > > > Hemant > > > > > > > Hi all, > > > > I have a couple of questions regarding the processing of context > > > > properties. > > > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > > (a) Before processing any command in that action request or > > > > (b) After processing all the commands in the action request. > > > > > > > > If it is in the end, then what should the audit of context properties > > > > return? > > > > (a) the context properties after applying the topology descriptor or > > > > (b) previous context properties? > > > > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > > If a topology descriptor fails, then should the > > > > further processing of commands in the action request be stopped? > > > > > > > > Thanks & regards, > > > > Hemant Agrawal > > > > > > > > ________________________________________ > > > > Hemant Agrawal > > > > GlobeSpan Inc > > > > Tel: +91 575 4544028 ext 121 > > > > E-mail:hemantag@globespan.net > > > > Web: http://www.globespan.net > > > > > > -- > Regards, > > Shalini Philip > Globespan Inc. > E-Mail : mailto:sphilip@globespan.net > Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 7 09:00:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24288 for ; Fri, 7 Jul 2000 09:00:12 -0400 (EDT) Received: from standards (47.234.32.16:4222) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BEDE@standards.nortelnetworks.com>; Fri, 7 Jul 2000 8:48:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2492 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jul 2000 08:48:20 -0400 Received: from mars.hss.co.in (202.54.26.197:48197) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7BED4@standards.nortelnetworks.com>; Fri, 7 Jul 2000 8:48:18 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e67Cxhg27646 for ; Fri, 7 Jul 2000 07:59:44 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256915.00466F09 ; Fri, 7 Jul 2000 18:19:19 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256915.00466E36.01@sandesh.hss.hns.com> Date: Fri, 7 Jul 2000 18:19:17 +0530 Reply-To: smahajan@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sunil Mahajan Subject: Conformance Test Specifications for M3UA X-To: SIGTRAN-TEST@STANDARDS.NORTELNETWORKS.COM, SIGTRAN@STANDARDS.NORTELNETWORKS.COM X-cc: sjindal@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi All, We have submitted an internet draft on test specification for M3UA (v02) protocol and the same will be available on IETF draft site in a day or two. The draft submitted presents an exhaustive list/description of tests which can be used as conformance test by any implementation or the flows can be used as implementor's guide. Comments on the draft are welcome. Regards, Sunil Mahajan HSS VoIP Group p.s. if anybody need a text copy of the draft before it appears on the IETF site we can mail it to you From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 08:49:05 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05466 for ; Sat, 8 Jul 2000 08:49:05 -0400 (EDT) Received: from standards (47.234.32.16:4280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C304@standards.nortelnetworks.com>; Sat, 8 Jul 2000 8:37:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3822 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 08:37:53 -0400 Received: from mars.hss.co.in (202.54.26.197:52411) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C303@standards.nortelnetworks.com>; Sat, 8 Jul 2000 8:37:51 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e68CnJg05166 for ; Sat, 8 Jul 2000 07:49:21 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256916.00458101 ; Sat, 8 Jul 2000 18:09:10 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256916.00457F9C.00@sandesh.hss.hns.com> Date: Sat, 8 Jul 2000 18:13:13 +0530 Reply-To: prjain@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Prashant Jain Subject: Significance of T-MAX for Retransmissions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, As per section D.1.5, T-MAX is obtained by subtracting maximum network propagation delay from the LONG TIMER value. And the significance of T-MAX is derived from the fact that the maximum delay of retransmissions for any transaction should always be bounded by T-MAX expalined in the same section. Moreover, as per section D.1.3, for each Retry of Transaction, the Retransmission Timer value is bounded and the suggested value is given to be 4 seconds. Now the query is what are we achieving by using two upper bounds for the same motive since T-MAX provides a cummulative bound for all the retransmissions and the same can be estimated by multiplying the number of retries with the upper bound value for each retry. Please do clarify. Prashant Jain VOIP Group, Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 09:25:06 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05750 for ; Sat, 8 Jul 2000 09:25:06 -0400 (EDT) Received: from standards (47.234.32.16:4280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C37E@standards.nortelnetworks.com>; Sat, 8 Jul 2000 9:14:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3980 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 09:14:41 -0400 Received: from mars.hss.co.in (202.54.26.197:52470) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C37D@standards.nortelnetworks.com>; Sat, 8 Jul 2000 9:14:39 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e68DQ6g05288 for ; Sat, 8 Jul 2000 08:26:08 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256916.0048DADF ; Sat, 8 Jul 2000 18:45:46 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256916.0048DAAA.00@sandesh.hss.hns.com> Date: Sat, 8 Jul 2000 18:50:21 +0530 Reply-To: prjain@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Prashant Jain Subject: Behavior of Transaction Pending To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, As per the protocol, receiving entity shall generate a transaction pending response to the Sending entity on receiving a duplicate request while the execution of the duplicate request is in progress. On receiving a transaction pending, the sender shall switch to a longer timer value. In this scenario, the retransmission timer shall never expire if transaction pending responses are being regularly generated by the receiving entity and reaches the sender before its retransmission timer expires. Shouldn't the protocol allow a upper bound on the number of pending responses one can generate and after that the sender should conclude the receiving entity as dead. Regards, Prashant Jain VOIP Group, Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 09:30:56 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05800 for ; Sat, 8 Jul 2000 09:30:56 -0400 (EDT) Received: from standards (47.234.32.16:4280) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C39D@standards.nortelnetworks.com>; Sat, 8 Jul 2000 9:20:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4019 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 09:20:35 -0400 Received: from mars.hss.co.in (202.54.26.197:52479) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C39C@standards.nortelnetworks.com>; Sat, 8 Jul 2000 9:20:33 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e68DW1g05310 for ; Sat, 8 Jul 2000 08:32:02 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256916.00496887 ; Sat, 8 Jul 2000 18:51:48 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256916.0049670A.00@sandesh.hss.hns.com> Date: Sat, 8 Jul 2000 18:56:25 +0530 Reply-To: prjain@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Prashant Jain Subject: Context Request Response in a Transaction Reply To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, MEGACO Protocol allows a sender to send a Transaction Request which only contains a CONTEXT Request (Topology Descriptior etc) but not any command information. Now, what should be sent in the corresponding transaction reply. Should the receiver returns the same information in the reply. The ABNF grammar seems to be inconsistent in this regard. Regards, Prashant Jain VOIP Group, Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jul 8 22:21:28 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11756 for ; Sat, 8 Jul 2000 22:21:28 -0400 (EDT) Received: from standards (47.234.32.16:4941) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C4FC@standards.nortelnetworks.com>; Sat, 8 Jul 2000 22:10:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4460 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Jul 2000 22:10:52 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C4FB@standards.nortelnetworks.com>; Sat, 8 Jul 2000 22:10:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA21276; Sat, 8 Jul 2000 22:20:52 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA28622; Sat, 8 Jul 2000 22:20:53 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Sat, 8 Jul 2000 22:20:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6784FD@whq-msgusr-02.fore.com> Date: Sat, 8 Jul 2000 22:20:52 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: 7 or 8 bit encoding?? X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd support UTF-8 encoding. I'd put a line to that effect near the reference to RFC2234. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Thursday, July 06, 2000 9:53 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: 7 or 8 bit encoding?? > > > G'Day all, > > Could someone confirm the type of encoding we are using for the text > version of Megaco. > > In Annex B ABNF is mentions that it is compliant to RFC2234 which in > turn talks about being encoded in 7bit US-ASCII. > > However the SDP part of the text encoding talks about being > compliant to > SDP RFC2327 which in turn mention the text below: > 6. SDP Specification > > SDP session descriptions are entirely textual using the ISO 10646 > character set in UTF-8 encoding. SDP field names and > attributes names > use only the US-ASCII subset of UTF-8, but textual fields and > attribute values may use the full ISO 10646 character set. > > It seems a mess to me if we are using 7bit encoding and 8 bit encoding > in the same encoding. I hope someone can confirm that we are > using UTF-8 > encoding for H248 text description because the protocol doesn't really > state this. > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 02:42:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29561 for ; Mon, 10 Jul 2000 02:42:29 -0400 (EDT) Received: from standards (47.234.32.16:4494) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C748@standards.nortelnetworks.com>; Mon, 10 Jul 2000 2:31:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5175 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 02:31:33 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C747@standards.nortelnetworks.com>; Mon, 10 Jul 2000 2:21:33 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6A6UjT12045; Mon, 10 Jul 2000 08:31:32 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA03048; Mon, 10 Jul 2000 08:30:45 +0200 (MET DST) Received: from ericsson.com (ki-110.kiedt.ericsson.se [147.214.100.110]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA02118; Mon, 10 Jul 2000 08:30:38 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <65256915.0022AF5D.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39696D80.61E81AAD@ericsson.com> Date: Mon, 10 Jul 2000 16:30:24 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: topology descriptor X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day, Please see my comments [CHG] Cheers, Christian Madhu Babu wrote: > > Hi, > This means that topology descriptor should be reexecuted every time > there is change in the number of terminations in the context? and it is not > executed at the instant when it is received. [CHG] Topology is executed when it is received. If you add another termination without specifying the topologyDescriptor that termination will be added in the normal "*" connection. > > When a new topology descriptor is specfiied does it mean that together > with the earlier topology rules, the new rules are executed in order if there is > a change in the number of terminations in the context. > > This means that topology descriptor always adds new rules and assume to > retain the earlier rules. > -Madhubabu > > Christian Groves on 07/07/2000 10:27:25 AM > > Please respond to Christian Groves > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Madhu B Babu/HSS) > > Subject: Re: topology descriptor > > G'Day Shalini, > > The point of the topology is that a context doesn't get created with a > star connection between Ta and Tb first and then gets modified. The > context gets created according to how the topology modifies it. ie. You > must know how the topology is modifed before you can add the > termination. > > Cheers, Christian > > Shalini Philip wrote: > > > > Hello Christian, and all, > > > > Consider a transaction request containing the topology descriptor > (involving > > two terminations TermA and TermB) followed by two Add command requests adding > > TermA and TermB into a new context. Now, would the processing of Topology > > Descriptor before that of the commands make sense. IMHO, first the context > should > > get created, then the terminations should be added to the context and then > finally > > the topology should be set between the terminations as required. > > > > The requirement of delaying the processing of Topology descriptor becomes even > > more relevant when a choose termination ($) is specified in it. In this case, > when > > the topology descriptor is taken up for processing, the termination is not > known. > > Topology can be set only after a subsequent add command specifying the choose > > termination and its descriptors has been processed. > > > > Regards, > > Shalini Philip. > > > > Christian Groves wrote: > > > > > G'Day Hemant, > > > > > > Processing is before commands in the action request. I would assume the > > > topology descriptor follows the same behaviour as a failed command in a > > > sequence of commands. > > > > > > Cheers, Christian > > > > > > Hemant Agrawal wrote: > > > > > > > > Hi all, > > > > I have not received any response for my queries, so I am posting > it > > > > again. > > > > An early response will be highly appreciated. > > > > > > > > Thanks > > > > Hemant > > > > > > > > > Hi all, > > > > > I have a couple of questions regarding the processing of context > > > > > properties. > > > > > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > > > (a) Before processing any command in that action request or > > > > > (b) After processing all the commands in the action request. > > > > > > > > > > If it is in the end, then what should the audit of context properties > > > > > return? > > > > > (a) the context properties after applying the topology descriptor or > > > > > (b) previous context properties? > > > > > > > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > > > If a topology descriptor fails, then should the > > > > > further processing of commands in the action request be stopped? > > > > > > > > > > Thanks & regards, > > > > > Hemant Agrawal > > > > > > > > > > ________________________________________ > > > > > Hemant Agrawal > > > > > GlobeSpan Inc > > > > > Tel: +91 575 4544028 ext 121 > > > > > E-mail:hemantag@globespan.net > > > > > Web: http://www.globespan.net > > > > > > > > > -- > > Regards, > > > > Shalini Philip > > Globespan Inc. > > E-Mail : mailto:sphilip@globespan.net > > Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 09:28:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08107 for ; Mon, 10 Jul 2000 09:28:29 -0400 (EDT) Received: from standards (47.234.32.16:1259) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C847@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:17:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5510 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 09:17:46 -0400 Received: from qhars002.nortel.com (47.101.112.102:65325) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C846@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:17:46 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 10 Jul 2000 14:27:19 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 10 Jul 2000 08:24:12 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 08:26:38 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B48@zcard00g.ca.nortel.com> Date: Mon, 10 Jul 2000 08:26:40 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Proposed New Megaco Work Item: draft-brown-supplpkgs-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Please state any objections to making draft-brown-supplpkgs-00.txt a Megaco work item. If I do not see any by Thursday I shall make it so. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 09:32:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08349 for ; Mon, 10 Jul 2000 09:32:12 -0400 (EDT) Received: from standards (47.234.32.16:1259) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C862@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:21:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5545 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 09:21:26 -0400 Received: from qhars002.nortel.com (47.101.112.102:33029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C861@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:21:26 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 10 Jul 2000 14:30:49 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 10 Jul 2000 09:30:36 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 09:24:22 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B47@zcard00g.ca.nortel.com> Date: Mon, 10 Jul 2000 09:24:21 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: R2 Package Last Call To: MEGACO@STANDARDS.NORTELNETWORKS.COM I hereby invoke WG Last Call on draft-ietf-megaco-r2package-01.txt with a view to making it a Standards Track RFC. I also request that any objections to making the HSS R1 package an official work item of the Megaco WG be stated. If none appear by Thursday, I will make that package a WG work item. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 09:36:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08518 for ; Mon, 10 Jul 2000 09:36:57 -0400 (EDT) Received: from standards (47.234.32.16:1259) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C87B@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:26:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5579 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 09:26:19 -0400 Received: from qhars002.nortel.com (47.101.112.102:33587) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C87A@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:26:19 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 10 Jul 2000 14:32:18 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 10 Jul 2000 08:29:41 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 08:32:08 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B4A@zcard00g.ca.nortel.com> Date: Mon, 10 Jul 2000 08:32:09 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: FW: Last Call On H.248 Annexes G Through K To: MEGACO@STANDARDS.NORTELNETWORKS.COM Resend. > -----Original Message----- > From: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Monday, July 10, 2000 8:58 AM > To: megaco > Subject: Last Call On H.248 Annexes G Through K > > I have submitted H.248 Annexes G through K as I-Ds. I declare WG Last > Call on them, effective as soon as they appear. These are the "White > Document" versions, which are the ones being submitted to ITU-T members > for their equivalent of last call before decision in November. Each > document is named similarly to the following: > draft-ietf-megaco-h248g-00.txt. > > I propose to take these through the full process so we can publish them as > Proposed Standard RFCs. Any Last Call comments will be fed back to SG 16 > for input to their decision meeting. > > I will be issuing Annex F shortly -- it just became available. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 09:43:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08757 for ; Mon, 10 Jul 2000 09:43:45 -0400 (EDT) Received: from standards (47.234.32.16:1259) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C892@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:33:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5610 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 09:33:10 -0400 Received: from qhars002.nortel.com (47.101.112.102:34538) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C891@standards.nortelnetworks.com>; Mon, 10 Jul 2000 9:33:10 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 10 Jul 2000 14:39:58 +0100 Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Mon, 10 Jul 2000 09:39:26 -0400 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3NY4DSSG; Mon, 10 Jul 2000 09:39:22 -0400 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L5HL96Y6; Mon, 10 Jul 2000 09:39:20 -0400 X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256906.0035C627.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3969D29B.D53A7E9B@americasm01.nt.com> Date: Mon, 10 Jul 2000 09:41:47 -0400 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Occurance of propertyParm X-To: rezhirpavai@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Here is my late response to your question due to being in a vocation. Good point, my understanding is the second option and you should be able to include more than one propertyParm as long as pkgdName appears only once. otherwise, it would be meaningless to setting a package parameter on then off in the same descriptor. Implementors guide is a good place for this comment. Abdallah Rayhan rezhirpavai@HSS.HNS.COM wrote: > Abdallah Rayhan, list > > localControlDescriptor can have more than one occurance of localParm. > It is specified in the ABNF grammer that only one occurance, each of streamMode, > propertyParm, reservedValueMode, reservedGroupMode should occur > for each localControlDescriptor. > > Does propertyParm as a whole have only one occurance or is it that multiple > propertyParm can occur within each localControlDescriptor, and the pkgdName > within the propertyParm should be unique. If the second option is true then it > should be > specified in the grammer explicitly as specified for sigOther within > sigParameter > in signalDescriptor. If the first option is true then in ASN.1 notation, it is > not right to > quote the propertyParms as "SEQUENCE OF PropertyParm" within > LocalControlDescriptor. > > Regards, > R. Ezhirpavai From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 12:44:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16588 for ; Mon, 10 Jul 2000 12:44:30 -0400 (EDT) Received: from standards (47.234.32.16:3287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C965@standards.nortelnetworks.com>; Mon, 10 Jul 2000 12:33:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5908 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 12:33:39 -0400 Received: from mars.hss.co.in (202.54.26.197:63147) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C964@standards.nortelnetworks.com>; Mon, 10 Jul 2000 12:30:52 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6AGfjg26280; Mon, 10 Jul 2000 11:41:47 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256918.005AC6BF ; Mon, 10 Jul 2000 22:01:31 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256918.005AC546.00@sandesh.hss.hns.com> Date: Mon, 10 Jul 2000 22:06:07 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: topology descriptor X-cc: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM HI Christian, Agreed. What is the behaviour if one of the termination moved from the context on which the topology descriptor was earlier sent? during this transition if audit of topology descriptor is received by MG, what should be the topology descriptor sent at that instant. -Madhubabu Christian Groves on 07/10/2000 12:00:24 PM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: topology descriptor G'Day, Please see my comments [CHG] Cheers, Christian Madhu Babu wrote: > > Hi, > This means that topology descriptor should be reexecuted every time > there is change in the number of terminations in the context? and it is not > executed at the instant when it is received. [CHG] Topology is executed when it is received. If you add another termination without specifying the topologyDescriptor that termination will be added in the normal "*" connection. > > When a new topology descriptor is specfiied does it mean that together > with the earlier topology rules, the new rules are executed in order if there is > a change in the number of terminations in the context. > > This means that topology descriptor always adds new rules and assume to > retain the earlier rules. > -Madhubabu > > Christian Groves on 07/07/2000 10:27:25 AM > > Please respond to Christian Groves > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Madhu B Babu/HSS) > > Subject: Re: topology descriptor > > G'Day Shalini, > > The point of the topology is that a context doesn't get created with a > star connection between Ta and Tb first and then gets modified. The > context gets created according to how the topology modifies it. ie. You > must know how the topology is modifed before you can add the > termination. > > Cheers, Christian > > Shalini Philip wrote: > > > > Hello Christian, and all, > > > > Consider a transaction request containing the topology descriptor > (involving > > two terminations TermA and TermB) followed by two Add command requests adding > > TermA and TermB into a new context. Now, would the processing of Topology > > Descriptor before that of the commands make sense. IMHO, first the context > should > > get created, then the terminations should be added to the context and then > finally > > the topology should be set between the terminations as required. > > > > The requirement of delaying the processing of Topology descriptor becomes even > > more relevant when a choose termination ($) is specified in it. In this case, > when > > the topology descriptor is taken up for processing, the termination is not > known. > > Topology can be set only after a subsequent add command specifying the choose > > termination and its descriptors has been processed. > > > > Regards, > > Shalini Philip. > > > > Christian Groves wrote: > > > > > G'Day Hemant, > > > > > > Processing is before commands in the action request. I would assume the > > > topology descriptor follows the same behaviour as a failed command in a > > > sequence of commands. > > > > > > Cheers, Christian > > > > > > Hemant Agrawal wrote: > > > > > > > > Hi all, > > > > I have not received any response for my queries, so I am posting > it > > > > again. > > > > An early response will be highly appreciated. > > > > > > > > Thanks > > > > Hemant > > > > > > > > > Hi all, > > > > > I have a couple of questions regarding the processing of context > > > > > properties. > > > > > > > > > > 1. When do we proces the topology descriptor in a Action Request ? > > > > > (a) Before processing any command in that action request or > > > > > (b) After processing all the commands in the action request. > > > > > > > > > > If it is in the end, then what should the audit of context properties > > > > > return? > > > > > (a) the context properties after applying the topology descriptor or > > > > > (b) previous context properties? > > > > > > > > > > > > > > > 2. How do we return a failure in applying the topology descriptor ? > > > > > If a topology descriptor fails, then should the > > > > > further processing of commands in the action request be stopped? > > > > > > > > > > Thanks & regards, > > > > > Hemant Agrawal > > > > > > > > > > ________________________________________ > > > > > Hemant Agrawal > > > > > GlobeSpan Inc > > > > > Tel: +91 575 4544028 ext 121 > > > > > E-mail:hemantag@globespan.net > > > > > Web: http://www.globespan.net > > > > > > > > > -- > > Regards, > > > > Shalini Philip > > Globespan Inc. > > E-Mail : mailto:sphilip@globespan.net > > Web : http://www.globespan.net From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 13:27:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18538 for ; Mon, 10 Jul 2000 13:27:28 -0400 (EDT) Received: from standards (47.234.32.16:4906) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C98B@standards.nortelnetworks.com>; Mon, 10 Jul 2000 13:16:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5954 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 13:16:54 -0400 Received: from sheffield.cnchost.com (sheffield.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7C98A@standards.nortelnetworks.com>; Mon, 10 Jul 2000 13:16:54 -0400 Received: from MATT.ascend.com (ts006d33.lap-ca.concentric.net [64.1.209.45]) by sheffield.cnchost.com id NAA21667; Mon, 10 Jul 2000 13:26:48 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000710093808.00b92a00@pop3.ipverse.com> Date: Mon, 10 Jul 2000 10:26:56 -0700 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: R2 Package Last Call X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <28560036253BD41191A10000F8BCBD11480B47@zcard00g.ca.nortel. com> Just curious, but are there any implementations of this package? Has anyone tried transmitting a real R2 stream from a real public switch (not a simulator) up to an MGC? In other words, has anyone actually tested this package to see if it works? Or is it just theory at this point? There are a lot of sensitivities with R2 and it's multitude of variants to make any alterations of it's architecture suspect. It would be nice to understand this better before we make a Proposed Standard out of it. I apologize for the interruption if this has already been done. I'm also concerned that some of the values of variant parameters may not fit in the fields. Caller-ID is one such parameter that varies country by country. Has anyone done the research to make sure they will fit OK? At 09:24 AM 7/10/00 -0400, Tom-PT Taylor wrote: >I hereby invoke WG Last Call on > >draft-ietf-megaco-r2package-01.txt > >with a view to making it a Standards Track RFC. > >I also request that any objections to making the HSS R1 package an official >work item of the Megaco WG be stated. If none appear by Thursday, I will >make that package a WG work item. > >Tom Taylor >Lead Standards Developer >Phone and FAX: +1 613 736 0961 >E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 15:37:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25617 for ; Mon, 10 Jul 2000 15:37:24 -0400 (EDT) Received: from standards (47.234.32.16:3797) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CA35@standards.nortelnetworks.com>; Mon, 10 Jul 2000 15:26:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6173 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 15:26:49 -0400 Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CA32@standards.nortelnetworks.com>; Mon, 10 Jul 2000 15:16:48 -0400 Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11562 for ; Mon, 10 Jul 2000 12:26:55 -0700 (PDT) Received: from 8x8.com (symph228.8x8.com [207.82.37.228]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id MAA04401; Mon, 10 Jul 2000 12:26:54 -0700 (PDT) X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396A22BE.29D17B12@8x8.com> Date: Mon, 10 Jul 2000 12:23:42 -0700 Reply-To: petithug@NETERGYNET.COM Sender: "Media Gateway Control (megaco)" From: Marc Petit-Huguenin Organization: Netergy Networks - Advanced Telephony Solutions Subject: User Interface MGCP package X-cc: Andy Huckridge To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, We have just released an Internet Draft which defines a new MGCP package for supporting the User Interface aspects of IP feature phones. We look forward to your comments for improving and validating this package. This document is accessible at http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt or alternatively at http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt Andy Huckridge Marc Petit-Huguenin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 17:16:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28878 for ; Mon, 10 Jul 2000 17:16:42 -0400 (EDT) Received: from standards (47.234.32.16:2638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CA70@standards.nortelnetworks.com>; Mon, 10 Jul 2000 17:05:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6255 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 17:05:56 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CA6C@standards.nortelnetworks.com>; Mon, 10 Jul 2000 16:55:55 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6AL5xT04737; Mon, 10 Jul 2000 23:05:59 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id XAA27378; Mon, 10 Jul 2000 23:05:59 +0200 (MET DST) Received: from ericsson.com (ki-160.kiedt.ericsson.se [147.214.100.160]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id XAA03284; Mon, 10 Jul 2000 23:05:53 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B4A@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396A05D7.5BFA382B@ericsson.com> Date: Tue, 11 Jul 2000 03:20:23 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: FW: Last Call On H.248 Annexes G Through K X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, I agree with taking these through the standards process. I have a few comments to Annex K "Announcement Package" which we'll probably be putting in also as a contribution to SG16 on but haven't had the chance to specify text. The main points: o There probably should be some text in the procedures section stating that a transaction reply for a command thats affect the announcement signal should be received by the MGC before it sends "additional data" to the announcement. As nothing guarantees in sequence delivery of transactions this is needed to ensure that the announcment played with the right sequence of data. o Some introductory text mentioning that "announcements" could be realised by the MG as different sorts of messaging ie. text on a display, audio announcement etc. This package is generic enough for it. o Number of Cycles has value 0 added to it which means that the announcement keeps repeating until explicitely stopped. There's currently no capability for it. o Announcement Completed Event is largely superflous as we now in the core protocol have the capacity to say when a signal has been completed. o Would like to add direction a as parameter to the signals "x-announcement play". Cheers, Christian Tom-PT Taylor wrote: > > Resend. > > > -----Original Message----- > > From: Taylor, Tom-PT [NORSE:B901:EXCH] > > Sent: Monday, July 10, 2000 8:58 AM > > To: megaco > > Subject: Last Call On H.248 Annexes G Through K > > > > I have submitted H.248 Annexes G through K as I-Ds. I declare WG Last > > Call on them, effective as soon as they appear. These are the "White > > Document" versions, which are the ones being submitted to ITU-T members > > for their equivalent of last call before decision in November. Each > > document is named similarly to the following: > > draft-ietf-megaco-h248g-00.txt. > > > > I propose to take these through the full process so we can publish them as > > Proposed Standard RFCs. Any Last Call comments will be fed back to SG 16 > > for input to their decision meeting. > > > > I will be issuing Annex F shortly -- it just became available. > > > > Tom Taylor > > Lead Standards Developer > > Phone and FAX: +1 613 736 0961 > > E-mail: taylor@nortelnetworks.com > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 17:24:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28880 for ; Mon, 10 Jul 2000 17:16:43 -0400 (EDT) Received: from standards (47.234.32.16:2638) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CA79@standards.nortelnetworks.com>; Mon, 10 Jul 2000 17:06:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6256 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 17:06:08 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CA6D@standards.nortelnetworks.com>; Mon, 10 Jul 2000 16:56:08 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6AL6BT04760; Mon, 10 Jul 2000 23:06:11 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id XAA27384; Mon, 10 Jul 2000 23:06:10 +0200 (MET DST) Received: from ericsson.com (ki-160.kiedt.ericsson.se [147.214.100.160]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id XAA03288; Mon, 10 Jul 2000 23:06:06 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B47@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396A063A.406BEBBD@ericsson.com> Date: Tue, 11 Jul 2000 03:22:02 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: R2 Package Last Call X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, What's the reference to the HSS R1 package that we are meant to be agreeing to? Cheers, Christian Tom-PT Taylor wrote: > > I hereby invoke WG Last Call on > > draft-ietf-megaco-r2package-01.txt > > with a view to making it a Standards Track RFC. > > I also request that any objections to making the HSS R1 package an official > work item of the Megaco WG be stated. If none appear by Thursday, I will > make that package a WG work item. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 20:11:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02264 for ; Mon, 10 Jul 2000 20:11:16 -0400 (EDT) Received: from standards (47.234.32.16:3788) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CB25@standards.nortelnetworks.com>; Mon, 10 Jul 2000 20:00:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6503 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 20:00:44 -0400 Received: from nuplanet.bitscout.com (gnatplanet.bitscout.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CB22@standards.nortelnetworks.com>; Mon, 10 Jul 2000 19:50:44 -0400 Received: from wrkplanet ([10.173.17.30]) by nuplanet.bitscout.com (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with ESMTP id TAA00793; Mon, 10 Jul 2000 19:53:44 -0400 X-Sender: jsteer@10.173.17.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.20000710195937.047d9740@10.173.17.1> Date: Mon, 10 Jul 2000 20:00:12 -0400 Reply-To: Jon Steer Sender: "Media Gateway Control (megaco)" From: Jon Steer Subject: Re: User Interface MGCP package X-To: petithug@NETERGYNET.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <396A22BE.29D17B12@8x8.com> At 12:23 PM 7/10/00 -0700, Marc Petit-Huguenin wrote: Hi, Will Netergy be claiming any IP on this package? regards, jon >Hi all, > >We have just released an Internet Draft which defines a new MGCP package >for supporting the User Interface aspects of IP feature phones. >We look forward to your comments for improving and validating this >package. >This document is accessible at >http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt >or alternatively at >http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt > >Andy Huckridge >Marc Petit-Huguenin Jon Steer -- CTO http://www.tsemantics.com/ T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064 phone:(603)889-1185 x203 video: (603)889-1125 fax: (603)-883-9365 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 23:10:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06333 for ; Mon, 10 Jul 2000 23:10:38 -0400 (EDT) Received: from standards (47.234.32.16:1306) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CB81@standards.nortelnetworks.com>; Mon, 10 Jul 2000 23:00:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6622 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 23:00:05 -0400 Received: from zorro.bxsoft.com.pl (Budimex2.pol.pl) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CB80@standards.nortelnetworks.com>; Mon, 10 Jul 2000 22:50:04 -0400 Received: from djdswk (ri-1tnt21.efortress.com [204.164.170.21]) by zorro.bxsoft.com.pl (8.9.0/10.9.2) with ESMTP id FAA19589; Tue, 11 Jul 2000 05:16:37 +0200 X-Mailer: QUALCOMM Windows Eudora Light Version 4.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200007110316.FAA19589@zorro.bxsoft.com.pl> Date: Mon, 10 Jul 2000 21:29:35 -0500 Reply-To: Branch Jason Sender: "Media Gateway Control (megaco)" From: Branch Jason Subject: Make it Easy #6044 X-To: cards19s@zorro.bxsoft.com.pl To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA06333 FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e -commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:ggmerch@operamail.com?subject=INFO-PLEASE to receive our FREE e-mail information package without obligations. ********************************************************* Remove at mailto:maiqx@188mail.com?subject=remove ********************************************************* From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 10 23:45:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07102 for ; Mon, 10 Jul 2000 23:45:55 -0400 (EDT) Received: from standards (47.234.32.16:3809) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CBA9@standards.nortelnetworks.com>; Mon, 10 Jul 2000 23:35:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6674 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jul 2000 23:35:24 -0400 Received: from mars.hss.co.in (202.54.26.197:64603) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CBA8@standards.nortelnetworks.com>; Mon, 10 Jul 2000 23:35:22 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6B3kmg28942; Mon, 10 Jul 2000 22:46:49 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256919.0013D126 ; Tue, 11 Jul 2000 09:06:27 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256919.0013CFFE.00@sandesh.hss.hns.com> Date: Tue, 11 Jul 2000 09:06:23 +0530 Reply-To: smahajan@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sunil Mahajan Subject: Re: R2 Package Last Call X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM hi Christian, it is "draft-hss-megaco-r1package-00.txt" regards, Sunil Mahajan VoIP Group Hughes Software Systems Christian Groves on 07/10/2000 10:52:02 PM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sunil Mahajan/HSS) Subject: Re: R2 Package Last Call G'Day Tom, What's the reference to the HSS R1 package that we are meant to be agreeing to? Cheers, Christian Tom-PT Taylor wrote: > > I hereby invoke WG Last Call on > > draft-ietf-megaco-r2package-01.txt > > with a view to making it a Standards Track RFC. > > I also request that any objections to making the HSS R1 package an official > work item of the Megaco WG be stated. If none appear by Thursday, I will > make that package a WG work item. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 03:01:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21322 for ; Tue, 11 Jul 2000 03:01:01 -0400 (EDT) Received: from standards (47.234.32.16:1417) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CC60@standards.nortelnetworks.com>; Tue, 11 Jul 2000 2:50:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6918 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 02:50:12 -0400 Received: from mars.hss.co.in (202.54.26.197:35120) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CC5F@standards.nortelnetworks.com>; Tue, 11 Jul 2000 2:50:10 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6B71hg04830 for ; Tue, 11 Jul 2000 02:01:45 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256919.0025AD20 ; Tue, 11 Jul 2000 12:21:31 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256919.0025AB64.00@sandesh.hss.hns.com> Date: Tue, 11 Jul 2000 12:26:06 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Re: R2 Package Last Call To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Matt, List please see responses embedded.........[HSS] There is a need for base R1/R2 signaling package which can be extended to support any country variant using package extension concept, so we feel that these proposed packages can be frozen and as implementations start using them extensions can be defined. In case anybody sees any basic/important stuff missing from these drafts, we can work on that. regards, Kushanava Laha VoIP Team, Hughes Software Systems Matt Holdrege on 07/10/2000 10:56:56 PM Please respond to Matt Holdrege To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sunil Mahajan/HSS) Subject: Re: R2 Package Last Call Just curious, but are there any implementations of this package? Has anyone tried transmitting a real R2 stream from a real public switch (not a simulator) up to an MGC? In other words, has anyone actually tested this package to see if it works? Or is it just theory at this point? [HSS] Both the R1 and R2 packages have been implemented by HSS as per the proposed package drafts. Testing with protocol simulators (AM8E) have been done satisfactorily for some of the variants. Testing with real life switch is on the way and we will share the results with the list as soon as the testing goes through. We are targetting few of the country variants for initial testing by extending the base package definition for these variants. There are a lot of sensitivities with R2 and it's multitude of variants to make any alterations of it's architecture suspect. It would be nice to understand this better before we make a Proposed Standard out of it. I apologize for the interruption if this has already been done. I'm also concerned that some of the values of variant parameters may not fit in the fields. Caller-ID is one such parameter that varies country by country. Has anyone done the research to make sure they will fit OK? [HSS] The packages have been deviced in such a way that all protocol timing sensitive issues while interfacing with a PSTN switch have been taken care in the MG, keeping the MGC transparent. In this way all latency related problems introduced in MG-MGC communication which may affect the time critical signals on the CAS signaling path have been best managed at MG. The R2 package though define the ITU-T flavour of R2 line and register signaling, is flexible enough to be extended by country specific packages that implement the country variations. The extended packages may introduce non-ITU-T CAS signals in the form of additional signals and events. They may also introduce new values for the signal/event parameters that satisfies the country specific requirements in keeping with package extension philosophy. In fact we are in the process of submitting a few of the country specific extensions as well to supplement the concept. At 09:24 AM 7/10/00 -0400, Tom-PT Taylor wrote: >I hereby invoke WG Last Call on > >draft-ietf-megaco-r2package-01.txt > >with a view to making it a Standards Track RFC. > >I also request that any objections to making the HSS R1 package an official >work item of the Megaco WG be stated. If none appear by Thursday, I will >make that package a WG work item. > >Tom Taylor >Lead Standards Developer >Phone and FAX: +1 613 736 0961 >E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 05:30:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22741 for ; Tue, 11 Jul 2000 05:30:22 -0400 (EDT) Received: from standards (47.234.32.16:3413) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CCCC@standards.nortelnetworks.com>; Tue, 11 Jul 2000 5:19:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7045 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 05:19:41 -0400 Received: from qhars002.nortel.com (47.101.112.102:37297) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CCB9@standards.nortelnetworks.com>; Tue, 11 Jul 2000 5:09:41 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Tue, 11 Jul 2000 10:15:54 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Tue, 11 Jul 2000 05:06:01 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Tue, 11 Jul 2000 02:12:20 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA09717 for ; Tue, 11 Jul 2000 09:11:59 +0300 (IDT) Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id JAA05140; Tue, 11 Jul 2000 09:11:59 +0300 (IDT) Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id JAA07917 for ; Tue, 11 Jul 2000 09:11:58 +0300 (IDT) X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <396ABAAC.EC5D3806@tmx100.elex.co.il> Date: Tue, 11 Jul 2000 09:11:57 +0300 Reply-To: "Prozan, Rakefet" Sender: "Media Gateway Control (megaco)" From: "Prozan, Rakefet" Organization: Telrad Ltd. Subject: NotifyRequest To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello everyone, Can Mg send in the same transaction more than one Notifyrequest? (I'm not talking about a wildcarded Notifyrequest). Does it make sense? If so,can somebody give me an example on how will the transaction looks like? many thanks, Rakefet Prozan, Team Manager, S/W Development Nortel SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il -- """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 06:44:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24347 for ; Tue, 11 Jul 2000 06:44:36 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD71@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:33:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7281 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 06:33:12 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD61@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:23:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23785; Tue, 11 Jul 2000 06:32:54 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007111032.GAA23785@ietf.org> Date: Tue, 11 Jul 2000 06:32:54 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-h248h-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 : H.248 Annex H (Pre-Decision White Document) Author(s) : A. Heidermark Filename : draft-ietf-megaco-h248h-00.txt Pages : 4 Date : 10-Jul-00 This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex H, which is scheduled for decision in Geneva in November 2000. H.248 Annex H describes procedures for transport of the Megaco protocol over SCTP [4]. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248h-00.txt 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-h248h-00.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-h248h-00.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: <20000710151732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-h248h-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-h248h-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151732.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 06:44:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24349 for ; Tue, 11 Jul 2000 06:44:37 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD76@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:33:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7282 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 06:33:12 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD60@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:23:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23828; Tue, 11 Jul 2000 06:33:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007111033.GAA23828@ietf.org> Date: Tue, 11 Jul 2000 06:33:08 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-h248k-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 : H.248 Annex K (Pre-Decision White Document) Author(s) : S. Rengasami Filename : draft-ietf-megaco-h248k-00.txt Pages : 4 Date : 10-Jul-00 This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex K, which is scheduled for decision in Geneva in November 2000. H.248 Annex K provides the Generic Announcement package. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248k-00.txt 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-h248k-00.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-h248k-00.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: <20000710152526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-h248k-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-h248k-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710152526.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 06:44:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24357 for ; Tue, 11 Jul 2000 06:44:37 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD7C@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:33:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7283 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 06:33:13 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD62@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:23:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23771; Tue, 11 Jul 2000 06:32:49 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007111032.GAA23771@ietf.org> Date: Tue, 11 Jul 2000 06:32:49 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-h248g-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 : H.248 Annex G (Pre-Decision White Document) Author(s) : M. Brown, P. Blatherwick Filename : draft-ietf-megaco-h248g-00.txt Pages : 14 Date : 10-Jul-00 This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex G, which is scheduled for decision in Geneva in November 2000. H.248 Annex G provides packages for 'User Interface Elements and Actions'. Specifically, the packages in Annex G include: - Display - Key - Keypad - Label key - Function key - Indicator - Soft key - Ancillary input This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt 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-h248g-00.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-h248g-00.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: <20000710151718.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-h248g-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-h248g-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151718.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 06:44:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24373 for ; Tue, 11 Jul 2000 06:44:37 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD88@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:33:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7285 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 06:33:14 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD64@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:23:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23814; Tue, 11 Jul 2000 06:33:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007111033.GAA23814@ietf.org> Date: Tue, 11 Jul 2000 06:33:03 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-h248j-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 : H.248 Annex J (Pre-Decision White Document) Author(s) : S. Rengasami, Z. Bilalis Filename : draft-ietf-megaco-h248j-00.txt Pages : 5 Date : 10-Jul-00 This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex J, which is scheduled for decision in Geneva in November 2000. H.248 Annex J provides the Dynamic Tone Generation package. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248j-00.txt 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-h248j-00.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-h248j-00.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: <20000710151755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-h248j-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-h248j-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151755.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 06:54:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24366 for ; Tue, 11 Jul 2000 06:44:37 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD82@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:33:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7284 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 06:33:13 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CD63@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:23:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23800; Tue, 11 Jul 2000 06:32:59 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007111032.GAA23800@ietf.org> Date: Tue, 11 Jul 2000 06:32:59 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-h248i-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 : H.248 Annex I (Pre-Decision White Document) Author(s) : A. Heidermark Filename : draft-ietf-megaco-h248i-00.txt Pages : 5 Date : 10-Jul-00 This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex I, which is scheduled for decision in Geneva in November 2000. H.248 Annex H describes procedures for transport of the Megaco protocol over ATM. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248i-00.txt 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-h248i-00.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-h248i-00.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: <20000710151744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-h248i-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-h248i-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151744.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 07:06:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25161 for ; Tue, 11 Jul 2000 07:06:09 -0400 (EDT) Received: from standards (47.234.32.16:1053) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CDE9@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:55:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7458 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 06:55:37 -0400 Received: from qhars002.nortel.com (47.101.112.102:51585) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CDE8@standards.nortelnetworks.com>; Tue, 11 Jul 2000 6:55:37 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Tue, 11 Jul 2000 12:02:35 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Tue, 11 Jul 2000 07:02:16 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Tue, 11 Jul 2000 07:01:48 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA20784; Tue, 11 Jul 2000 14:01:25 +0300 (IDT) Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id OAA18070; Tue, 11 Jul 2000 14:01:24 +0300 (IDT) Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id OAA08212; Tue, 11 Jul 2000 14:01:24 +0300 (IDT) X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 References: <706A42E526E9D311924C00B0D01AC60B08367A@mail.itn.ipcell.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <396AFE83.51C6CF8B@tmx100.elex.co.il> Date: Tue, 11 Jul 2000 14:01:23 +0300 Reply-To: "Prozan, Rakefet" Sender: "Media Gateway Control (megaco)" From: "Prozan, Rakefet" Organization: Telrad Ltd. Subject: Re: NotifyRequest X-To: Mehul Shah To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I was asked to clarify the question,so this is what I ment: An Action consists of a series of Commands and a Transaction consists of one or more Actions,therefore can it be possible for an MG to send more than one Notify Commands in one Action(in Null Context)? Rakefet Prozan, Team Manager, S/W Development Nortel SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! Mehul Shah wrote: > > hi, > your question is not clear. > Could you please clarify it in detail > thanks > mehul > > > -----Original Message----- > > From: Media Gateway Control (megaco) > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > Prozan, Rakefet > > Sent: Tuesday, July 11, 2000 1:12 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: NotifyRequest > > > > > > Hello everyone, > > > > Can Mg send in the same transaction more than one Notifyrequest? > > (I'm not talking about a wildcarded Notifyrequest). > > Does it make sense? If so,can somebody give me an example on how will > > the transaction looks like? > > > > many thanks, > > Rakefet Prozan, > > Team Manager, S/W Development > > Nortel SBU > > Telrad Networks > > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > > > > > > > -- > > > > """ > > -(o o)- > > +---------------------------------oOO--(_)--OOo--------------+ > > > > .oooO Oooo. > > -------------------------------( )---------( )------------ > > \ ( ) / > > \_) (_/ > > > > Have fun !!! > > -- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 10:54:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02853 for ; Tue, 11 Jul 2000 10:54:05 -0400 (EDT) Received: from standards (47.234.32.16:2084) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CF15@standards.nortelnetworks.com>; Tue, 11 Jul 2000 10:43:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7835 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 10:43:13 -0400 Received: from qhars002.nortel.com (47.101.112.102:47978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CEFB@standards.nortelnetworks.com>; Tue, 11 Jul 2000 10:33:12 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 11 Jul 2000 15:37:40 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Tue, 11 Jul 2000 10:35:00 -0400 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JSNBY94; Tue, 11 Jul 2000 10:34:52 -0400 Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JPMGGDK; Tue, 11 Jul 2000 10:34:51 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <65256919.0025AB64.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396B31B8.DEC49E2@americasm10.nt.com> Date: Tue, 11 Jul 2000 10:39:52 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: R2 Package Last Call To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think that there is a definite problem with going last call on this package. Sorry for not having brought this back up to the attention of the list sooner, but I figured that discussion of proposed packages was somewhat on the back burner and was a bit surprised by the Last Call announcement. At any rate, the issue I have is with the way the packages for R1 and R2 as proposed are defined architecturally. That is, when you take the two packages side by side it is immediately apparent that there is very significant overlap in the packages (signals and events). Based on the philosophy of creating packages as a hierarchical tree structure where common functions are represented at the higher level and variant specific functions are represented as extension packages, there needs to be a base package representing those common functions and extension packages as appropriate to reflect signaling and regional/market variants. This is the basis of a proposal that I presented in Adelaide for PSTN trunking, to support robbed bit signaling. The proposal describes a high level package which reflects the common functions as seen in the R1 and R2 proposals. It is described in section 4 of the I-D, draft-brown-megaco-supplpkgs-00.txt. I think this is the approach that we need to use in creating these packages to avoid a proliferation of packages that contain definitions for the same signals and events over and over again. Given that, I believe that Last Call on the R1 package is premature. Michael Brown Kushanava Laha wrote: > Hi Matt, List > > please see responses embedded.........[HSS] > > There is a need for base R1/R2 signaling package which can be extended to > support any country variant using package extension concept, so we feel that > these proposed packages can be frozen and as implementations start using them > extensions can be defined. > > In case anybody sees any basic/important stuff missing from these drafts, > we can work on that. > > regards, > Kushanava Laha > VoIP Team, > Hughes Software Systems > > Matt Holdrege on 07/10/2000 10:56:56 PM > > Please respond to Matt Holdrege > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sunil Mahajan/HSS) > > Subject: Re: R2 Package Last Call > > Just curious, but are there any implementations of this package? Has anyone > tried transmitting a real R2 stream from a real public switch (not a > simulator) up to an MGC? In other words, has anyone actually tested this > package to see if it works? Or is it just theory at this point? > > [HSS] Both the R1 and R2 packages have been implemented by HSS as per the > proposed package drafts. Testing with protocol simulators (AM8E) have been > done satisfactorily for some of the variants. Testing with real life switch > is on the way and we will share the results with the list as soon as the > testing goes through. > We are targetting few of the country variants for initial testing by > extending the base package definition for these variants. > > There are a lot of sensitivities with R2 and it's multitude of variants to > make any alterations of it's architecture suspect. It would be nice to > understand this better before we make a Proposed Standard out of it. I > apologize for the interruption if this has already been done. > > I'm also concerned that some of the values of variant parameters may not > fit in the fields. Caller-ID is one such parameter that varies country by > country. Has anyone done the research to make sure they will fit OK? > > [HSS] The packages have been deviced in such a way that all protocol timing > sensitive issues while interfacing with a PSTN switch have been taken > care in the MG, keeping the MGC transparent. In this way all latency > related problems introduced in MG-MGC communication which may affect the > time critical signals on the CAS signaling path have been best managed at MG. > The R2 package though define the ITU-T flavour of R2 line and register > signaling, > is flexible enough to be extended by country specific packages that implement > the country variations. The extended packages may introduce non-ITU-T CAS > signals > in the form of additional signals and events. They may also introduce new values > for the signal/event parameters that satisfies the country specific requirements > in keeping with package extension philosophy. > > In fact we are in the process of submitting a few of the country specific > extensions as well to supplement the concept. > > At 09:24 AM 7/10/00 -0400, Tom-PT Taylor wrote: > >I hereby invoke WG Last Call on > > > >draft-ietf-megaco-r2package-01.txt > > > >with a view to making it a Standards Track RFC. > > > >I also request that any objections to making the HSS R1 package an official > >work item of the Megaco WG be stated. If none appear by Thursday, I will > >make that package a WG work item. > > > >Tom Taylor > >Lead Standards Developer > >Phone and FAX: +1 613 736 0961 > >E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 11:35:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04817 for ; Tue, 11 Jul 2000 11:35:13 -0400 (EDT) Received: from standards (47.234.32.16:3804) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CF4F@standards.nortelnetworks.com>; Tue, 11 Jul 2000 11:24:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 11:24:22 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CF4E@standards.nortelnetworks.com>; Tue, 11 Jul 2000 11:24:21 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13455; Tue, 11 Jul 2000 11:34:28 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15069; Tue, 11 Jul 2000 11:34:28 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3VHKVN1J>; Tue, 11 Jul 2000 11:34:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678527@whq-msgusr-02.fore.com> Date: Tue, 11 Jul 2000 11:34:23 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: NotifyRequest X-To: "Prozan, Rakefet" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sure. First of all, the original question covered more than the "in Null Context" that your clarification covered. Obviously, you could have two actions, with separate contexts, each of which had an Events Descriptor which asked for a Notify. Transaction=1122 { Context=1 {Add=A{Events=111{al/hd}}}, Context=2 {Add=B{Events=222{al/hd}}}} With the restriction of null context, you could ask "why would you want to?", but it would be perfectly legal to use Transaction=1123 {Context=- {Modify=A{Events=333{al/hd}}}, Context=- {Modify=B{Events=444{al/hd}}}} but you could say Transaction=1124 {Context=- {Modify=A{Events=555{al/hu}}, {Modify=B{Events=666{al/hd}}}} Does that answer your question? Brian > -----Original Message----- > From: Prozan, Rakefet [mailto:rakefet.prozan@telrad.co.il] > Sent: Tuesday, July 11, 2000 7:01 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: NotifyRequest > > > Hi, > I was asked to clarify the question,so this is what I ment: > An Action consists of a series of Commands and a Transaction > consists of > one or more > Actions,therefore can it be possible for an MG to send more than one > Notify Commands > in one Action(in Null Context)? > > Rakefet Prozan, > Team Manager, S/W Development > Nortel SBU > Telrad Networks > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > > """ > -(o o)- > +---------------------------------oOO--(_)--OOo--------------+ > > .oooO Oooo. > -------------------------------( )---------( )------------ > \ ( ) / > \_) (_/ > > Have fun !!! > > > > > Mehul Shah wrote: > > > > hi, > > your question is not clear. > > Could you please clarify it in detail > > thanks > > mehul > > > > > -----Original Message----- > > > From: Media Gateway Control (megaco) > > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > > Prozan, Rakefet > > > Sent: Tuesday, July 11, 2000 1:12 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: NotifyRequest > > > > > > > > > Hello everyone, > > > > > > Can Mg send in the same transaction more than one > Notifyrequest? > > > (I'm not talking about a wildcarded Notifyrequest). > > > Does it make sense? If so,can somebody give me an example > on how will > > > the transaction looks like? > > > > > > many thanks, > > > Rakefet Prozan, > > > Team Manager, S/W Development > > > Nortel SBU > > > Telrad Networks > > > ESN 828-3043 > Email:rakefet.prozan@telrad.co.il > > > > > > > > > > > > -- > > > > > > """ > > > -(o o)- > > > +---------------------------------oOO--(_)--OOo--------------+ > > > > > > .oooO Oooo. > > > -------------------------------( )---------( )------------ > > > \ ( ) / > > > \_) (_/ > > > > > > Have fun !!! > > > > > -- > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 12:01:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05999 for ; Tue, 11 Jul 2000 12:01:09 -0400 (EDT) Received: from standards (47.234.32.16:4799) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CF72@standards.nortelnetworks.com>; Tue, 11 Jul 2000 11:50:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0058 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 11:50:26 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CF71@standards.nortelnetworks.com>; Tue, 11 Jul 2000 11:50:26 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15963 for ; Tue, 11 Jul 2000 12:00:32 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21917 for ; Tue, 11 Jul 2000 12:00:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3VH23MZ4>; Tue, 11 Jul 2000 12:00:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67852A@whq-msgusr-02.fore.com> Date: Tue, 11 Jul 2000 12:00:22 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Parameters in Local Control To: MEGACO@STANDARDS.NORTELNETWORKS.COM In the text, section 7.1.7, it states: A new setting of the LocalControl Descriptor completely replaces the previous setting of that descriptor in the MG. Thus to retain information from the previous setting the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify command) with the unwanted information stripped out. Suppose you implemented a couple packages that defined a dozen or so properties. Do you have to repeat the values of each of these properties in every modify of LocalControl? I think this paragraph is a remnant of an earlier concept, and with LocalControl defined as it is now, this statement is in error, and the actual desired behavior is that values are kept until modified. Consider that LocalControl presently has only the Mode property, the ReserveGroup and ReserveValue properties and properties of a termination. This means there is nothing in LocalControl that is not a property with a value (as opposed to, say a flag). Thus keeping old values is very feasible, and I believe, what is desired. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 12:30:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07692 for ; Tue, 11 Jul 2000 12:30:07 -0400 (EDT) Received: from standards (47.234.32.16:4799) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CFA1@standards.nortelnetworks.com>; Tue, 11 Jul 2000 12:19:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0123 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 12:19:20 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CFA0@standards.nortelnetworks.com>; Tue, 11 Jul 2000 12:19:19 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA28105 for ; Tue, 11 Jul 2000 09:29:29 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA29582 for ; Tue, 11 Jul 2000 09:29:29 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id LAA08587; Tue, 11 Jul 2000 11:29:13 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id LAA17883; Tue, 11 Jul 2000 11:29:13 -0500 (CDT) X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200007111032.GAA23800@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200007111629.LAA17883@agevole.cig.mot.com> Date: Tue, 11 Jul 2000 11:31:25 -0500 Reply-To: Qiaobing Xie Sender: "Media Gateway Control (megaco)" From: Qiaobing Xie Subject: Re: I-D ACTION:draft-ietf-megaco-h248i-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Internet-Drafts@IETF.ORG wrote: > > 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 : H.248 Annex I (Pre-Decision White Document) > Author(s) : A. Heidermark > Filename : draft-ietf-megaco-h248i-00.txt > Pages : 5 > Date : 10-Jul-00 > > This document reproduces the content of the ITU-T Study Group 16 > White Document draft of H.248 Annex I, which is scheduled for > decision in Geneva in November 2000. H.248 Annex H describes ^^^^^^^ This should say "Annex I" -------// > procedures for transport of the Megaco protocol over ATM. > This document is submitted for IETF comment prior to ITU-T decision, > in accordance with procedures currently being negotiated between > ITU-T Study Group and ISOC on behalf of the IETF. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248i-00.txt > > 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-h248i-00.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-h248i-00.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. > > ------------------------------------------------------------------------ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 12:42:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08530 for ; Tue, 11 Jul 2000 12:42:13 -0400 (EDT) Received: from standards (47.234.32.16:4799) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CFD4@standards.nortelnetworks.com>; Tue, 11 Jul 2000 12:31:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0153 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 12:31:29 -0400 Received: from smtp.email.msn.com (cpimssmtpu01.email.msn.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7CFB7@standards.nortelnetworks.com>; Tue, 11 Jul 2000 12:21:28 -0400 Received: from computer - 63.14.53.20 by email.msn.com with Microsoft SMTPSVC; Tue, 11 Jul 2000 09:30:42 -0700 References: <65256919.0025AB64.00@sandesh.hss.hns.com> 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 Message-ID: <001701bfeb55$89328440$14350e3f@computer> Date: Tue, 11 Jul 2000 10:30:58 -0600 Reply-To: rahnkp Sender: "Media Gateway Control (megaco)" From: rahnkp Subject: Re: R2 Package Last Call X-To: klaha@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Please PLEASE Please Take me off these lists. I feel as if I'm being spammed!!!!! ----- Original Message ----- From: Kushanava Laha To: Sent: Tuesday, July 11, 2000 12:56 AM Subject: Re: R2 Package Last Call > Hi Matt, List > > please see responses embedded.........[HSS] > > There is a need for base R1/R2 signaling package which can be extended to > support any country variant using package extension concept, so we feel that > these proposed packages can be frozen and as implementations start using them > extensions can be defined. > > In case anybody sees any basic/important stuff missing from these drafts, > we can work on that. > > regards, > Kushanava Laha > VoIP Team, > Hughes Software Systems > > > > > Matt Holdrege on 07/10/2000 10:56:56 PM > > Please respond to Matt Holdrege > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sunil Mahajan/HSS) > > Subject: Re: R2 Package Last Call > > > > > Just curious, but are there any implementations of this package? Has anyone > tried transmitting a real R2 stream from a real public switch (not a > simulator) up to an MGC? In other words, has anyone actually tested this > package to see if it works? Or is it just theory at this point? > > [HSS] Both the R1 and R2 packages have been implemented by HSS as per the > proposed package drafts. Testing with protocol simulators (AM8E) have been > done satisfactorily for some of the variants. Testing with real life switch > is on the way and we will share the results with the list as soon as the > testing goes through. > We are targetting few of the country variants for initial testing by > extending the base package definition for these variants. > > There are a lot of sensitivities with R2 and it's multitude of variants to > make any alterations of it's architecture suspect. It would be nice to > understand this better before we make a Proposed Standard out of it. I > apologize for the interruption if this has already been done. > > I'm also concerned that some of the values of variant parameters may not > fit in the fields. Caller-ID is one such parameter that varies country by > country. Has anyone done the research to make sure they will fit OK? > > [HSS] The packages have been deviced in such a way that all protocol timing > sensitive issues while interfacing with a PSTN switch have been taken > care in the MG, keeping the MGC transparent. In this way all latency > related problems introduced in MG-MGC communication which may affect the > time critical signals on the CAS signaling path have been best managed at MG. > The R2 package though define the ITU-T flavour of R2 line and register > signaling, > is flexible enough to be extended by country specific packages that implement > the country variations. The extended packages may introduce non-ITU-T CAS > signals > in the form of additional signals and events. They may also introduce new values > for the signal/event parameters that satisfies the country specific requirements > in keeping with package extension philosophy. > > In fact we are in the process of submitting a few of the country specific > extensions as well to supplement the concept. > > > At 09:24 AM 7/10/00 -0400, Tom-PT Taylor wrote: > >I hereby invoke WG Last Call on > > > >draft-ietf-megaco-r2package-01.txt > > > >with a view to making it a Standards Track RFC. > > > >I also request that any objections to making the HSS R1 package an official > >work item of the Megaco WG be stated. If none appear by Thursday, I will > >make that package a WG work item. > > > >Tom Taylor > >Lead Standards Developer > >Phone and FAX: +1 613 736 0961 > >E-mail: taylor@nortelnetworks.com > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 11 18:52:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22552 for ; Tue, 11 Jul 2000 18:52:34 -0400 (EDT) Received: from standards (47.234.32.16:1068) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D161@standards.nortelnetworks.com>; Tue, 11 Jul 2000 18:41:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0698 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jul 2000 18:41:40 -0400 Received: from warspite.cnchost.com (warspite.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D160@standards.nortelnetworks.com>; Tue, 11 Jul 2000 18:41:40 -0400 Received: from MATT.ascend.com (w066.z208037018.sjc-ca.dsl.cnc.net [208.37.18.66]) by warspite.cnchost.com id SAA29721; Tue, 11 Jul 2000 18:51:48 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000711150614.00c23310@pop3.ipverse.com> Date: Tue, 11 Jul 2000 15:52:05 -0700 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: R2 Package Last Call X-To: klaha@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <65256919.0025AB64.00@sandesh.hss.hns.com> At 12:26 PM 7/11/00 +0530, Kushanava Laha wrote: >[HSS] The packages have been deviced in such a way that all protocol timing >sensitive issues while interfacing with a PSTN switch have been taken >care in the MG, keeping the MGC transparent. In this way all latency >related problems introduced in MG-MGC communication which may affect the >time critical signals on the CAS signaling path have been best managed at MG. It's true that the MG must respond to the time critical tones. But you still have to get some info from the MGC to process the call and that is where the timing of using MEGACO with this package could get hairy. Another case is Protocol State Machine malfunction in the Failure message. What happens when an MGC wishes to convey that information to a switch or vice versa? Could it be a problem to have open-ended strings in these messages? Shouldn't we set some bounds? Also, could native descriptors be used instead to give some bounding? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 01:04:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29589 for ; Wed, 12 Jul 2000 01:04:53 -0400 (EDT) Received: from standards (47.234.32.16:2075) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D29A@standards.nortelnetworks.com>; Wed, 12 Jul 2000 0:53:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1130 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 00:53:24 -0400 Received: from suraksha.wipsys.soft.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D299@standards.nortelnetworks.com>; Wed, 12 Jul 2000 0:53:22 -0400 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id KAA26006; Wed, 12 Jul 2000 10:28:04 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma026001; Wed, 12 Jul 00 10:27:48 +0530 Received: from wipro.com ([192.168.162.126]) by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA2AAD for ; Wed, 12 Jul 2000 10:27:10 +0530 X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000711150614.00c23310@pop3.ipverse.com> Content-Type: multipart/mixed; boundary="------------6FE4182597AB5649C556F585" Message-ID: <396BF916.ED0B7034@wipro.com> Date: Wed, 12 Jul 2000 10:20:31 +0530 Reply-To: Panditha Govindraj Sender: "Media Gateway Control (megaco)" From: Panditha Govindraj Organization: Wipro Technologies Subject: Modification of Gateway To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------6FE4182597AB5649C556F585 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What does Modification of Gateway Out side the Context mean , When does this scenario Occur. --------------6FE4182597AB5649C556F585 Content-Type: text/x-vcard; charset=us-ascii; name="govinda.rajp.vcf" Content-Description: Card for govindaraj Content-Disposition: attachment; filename="govinda.rajp.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Panditha;Govindaraj tel;pager:----------------------- tel;cell:----------------------- tel;fax:0091-44-2301532 tel;home:---------------------- tel;work:0091-44-2301530 x-mozilla-html:TRUE url:http://www.wipro.com org:Wipro ;Global R & D version:2.1 email;internet:govinda.rajp@wipro.com title:Senior Engineer Software note:We make a living by what we get, but we make a life by what we give. adr;quoted-printable:;;111 Anna Salai=0D=0AGuindy=0D=0A;Chennai;Tamil Nadu;600032;India fn:Govindaraj end:vcard --------------6FE4182597AB5649C556F585-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 01:09:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29591 for ; Wed, 12 Jul 2000 01:04:53 -0400 (EDT) Received: from standards (47.234.32.16:2075) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D2A7@standards.nortelnetworks.com>; Wed, 12 Jul 2000 0:53:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1147 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 00:53:59 -0400 Received: from suraksha.wipsys.soft.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D2A6@standards.nortelnetworks.com>; Wed, 12 Jul 2000 0:53:57 -0400 Received: by suraksha.wipsys.soft.net (8.8.8+Sun/SMI-SVR4) id KAA26138; Wed, 12 Jul 2000 10:31:04 +0530 (IST) Received: from cdcvwall(192.168.160.23) by suraksha via smap (V2.0) id xma026133; Wed, 12 Jul 00 10:30:47 +0530 Received: from wipro.com ([192.168.162.126]) by bhairavi.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA2D30 for ; Wed, 12 Jul 2000 10:30:10 +0530 X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000711150614.00c23310@pop3.ipverse.com> <396BF916.ED0B7034@wipro.com> Content-Type: multipart/mixed; boundary="------------C70AA66E5AC61935D799EEE7" Message-ID: <396BF9C9.FE2BA74F@wipro.com> Date: Wed, 12 Jul 2000 10:23:30 +0530 Reply-To: Panditha Govindraj Sender: "Media Gateway Control (megaco)" From: Panditha Govindraj Organization: Wipro Technologies Subject: Re: Modification of Gateway To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------C70AA66E5AC61935D799EEE7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I correct my doubt Modification of Termination outside of Context govindaraj wrote: > What does Modification of Gateway Out side the Context mean , When does this > scenario Occur. > > ------------------------------------------------------------------------ > Name: govinda.rajp.vcf > govinda.rajp.vcf Type: VCard (text/x-vcard) > Encoding: 7bit > Description: Card for govindaraj --------------C70AA66E5AC61935D799EEE7 Content-Type: text/x-vcard; charset=us-ascii; name="govinda.rajp.vcf" Content-Description: Card for govindaraj Content-Disposition: attachment; filename="govinda.rajp.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Panditha;Govindaraj tel;pager:----------------------- tel;cell:----------------------- tel;fax:0091-44-2301532 tel;home:---------------------- tel;work:0091-44-2301530 x-mozilla-html:TRUE url:http://www.wipro.com org:Wipro ;Global R & D version:2.1 email;internet:govinda.rajp@wipro.com title:Senior Engineer Software note:We make a living by what we get, but we make a life by what we give. adr;quoted-printable:;;111 Anna Salai=0D=0AGuindy=0D=0A;Chennai;Tamil Nadu;600032;India fn:Govindaraj end:vcard --------------C70AA66E5AC61935D799EEE7-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 02:01:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07299 for ; Wed, 12 Jul 2000 02:01:11 -0400 (EDT) Received: from standards (47.234.32.16:4059) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D315@standards.nortelnetworks.com>; Wed, 12 Jul 2000 1:50:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1292 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 01:50:19 -0400 Received: from web5105.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D312@standards.nortelnetworks.com>; Wed, 12 Jul 2000 1:40:19 -0400 Received: from [208.220.245.72] by web5105.mail.yahoo.com; Tue, 11 Jul 2000 22:50:31 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000712055031.13366.qmail@web5105.mail.yahoo.com> Date: Tue, 11 Jul 2000 22:50:31 -0700 Reply-To: Jack Wu Sender: "Media Gateway Control (megaco)" From: Jack Wu Subject: Questions about signalList Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, I've scrutinized the ietf-draft-merge-01, in my opion the ASN.1 representaion should be SeqSigList ::= SEQUENCE { id INTEGER(0..65535), signalList SEQUENCE OF Signal, signalListType SignalType } other than SeqSigList ::= SEQUENCE { id INTEGER(0..65535), signalList SEQUENCE OF Signal, } the ABNF representation should be signalList = SignalListToken EQUAL signalList Id LBRKT signalListType, SignalListParm *(COMMA signalListParm) RBRKT instead of signalList = SignalListToken EQUAL signalList Id LBRKT SignalListParm *(COMMA signalListParm) RBRKT I think it is an editorial error. Regars, Richie Wu __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 03:20:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13059 for ; Wed, 12 Jul 2000 03:20:33 -0400 (EDT) Received: from standards (47.234.32.16:1702) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D35E@standards.nortelnetworks.com>; Wed, 12 Jul 2000 3:09:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1382 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 03:09:34 -0400 Received: from hd2.dot.net.in (hd2.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D357@standards.nortelnetworks.com>; Wed, 12 Jul 2000 2:58:59 -0400 Received: from hyd.chiplogic.com ([203.197.20.108]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id MAA06021 for ; Wed, 12 Jul 2000 12:36:15 +0530 (IST) Received: from chiplogic.com ([192.168.2.63]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id MAA29533 for ; Wed, 12 Jul 2000 12:34:45 +0530 X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396C19A9.13005F70@chiplogic.com> Date: Wed, 12 Jul 2000 12:39:29 +0530 Reply-To: chennu Sender: "Media Gateway Control (megaco)" From: chennu Organization: Chiplogic India (P) Ltd. Subject: Re: Modification of Gateway To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Govindraj, Modification of the Termination outside of Context means when the termination is in the Null context . For eg. adding event to the termination to look for an off-hook event Regards, Chandra sekhar. Panditha Govindraj wrote: > I correct my doubt > > Modification of Termination outside of Context > > govindaraj wrote: > > > What does Modification of Gateway Out side the Context mean , When does this > > scenario Occur. > > > > ------------------------------------------------------------------------ > > Name: govinda.rajp.vcf > > govinda.rajp.vcf Type: VCard (text/x-vcard) > > Encoding: 7bit > > Description: Card for govindaraj From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 03:39:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13274 for ; Wed, 12 Jul 2000 03:39:50 -0400 (EDT) Received: from standards (47.234.32.16:3171) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D387@standards.nortelnetworks.com>; Wed, 12 Jul 2000 3:29:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1442 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 03:29:04 -0400 Received: from qhars002.nortel.com (47.101.112.102:63266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D386@standards.nortelnetworks.com>; Wed, 12 Jul 2000 3:29:04 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Wed, 12 Jul 2000 08:38:25 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Wed, 12 Jul 2000 03:38:15 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Wed, 12 Jul 2000 03:38:01 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA22288; Wed, 12 Jul 2000 10:37:29 +0300 (IDT) Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id KAA21614; Wed, 12 Jul 2000 10:37:29 +0300 (IDT) Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id KAA10294; Wed, 12 Jul 2000 10:37:28 +0300 (IDT) X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678527@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <396C2036.33BDFC0@tmx100.elex.co.il> Date: Wed, 12 Jul 2000 10:37:26 +0300 Reply-To: "Prozan, Rakefet" Sender: "Media Gateway Control (megaco)" From: "Prozan, Rakefet" Organization: Telrad Ltd. Subject: Re: NotifyRequest X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > Sure. First of all, the original question covered more than > the "in Null Context" that your clarification covered. Obviously, > you could have two actions, with separate contexts, each of which > had an Events Descriptor which asked for a Notify. > > Transaction=1122 { Context=1 {Add=A{Events=111{al/hd}}}, > Context=2 {Add=B{Events=222{al/hd}}}} > > With the restriction of null context, you could ask "why would you > want to?", but it would be perfectly legal to use > Transaction=1123 {Context=- {Modify=A{Events=333{al/hd}}}, > Context=- {Modify=B{Events=444{al/hd}}}} > > but you could say > Transaction=1124 {Context=- {Modify=A{Events=555{al/hu}}, > {Modify=B{Events=666{al/hd}}}} > > Does that answer your question? > > Brian > > -----Original Message----- > > From: Prozan, Rakefet [mailto:rakefet.prozan@telrad.co.il] > > Sent: Tuesday, July 11, 2000 7:01 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: NotifyRequest > > > > > > Hi, > > I was asked to clarify the question,so this is what I ment: > > An Action consists of a series of Commands and a Transaction > > consists of > > one or more > > Actions,therefore can it be possible for an MG to send more than one > > Notify Commands > > in one Action(in Null Context)? > > > > Rakefet Prozan, > > Team Manager, S/W Development > > Nortel SBU > > Telrad Networks > > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > > > > > """ > > -(o o)- > > +---------------------------------oOO--(_)--OOo--------------+ > > > > .oooO Oooo. > > -------------------------------( )---------( )------------ > > \ ( ) / > > \_) (_/ > > > > Have fun !!! > > > > > > > > > > Mehul Shah wrote: > > > > > > hi, > > > your question is not clear. > > > Could you please clarify it in detail > > > thanks > > > mehul > > > > > > > -----Original Message----- > > > > From: Media Gateway Control (megaco) > > > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of > > > > Prozan, Rakefet > > > > Sent: Tuesday, July 11, 2000 1:12 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: NotifyRequest > > > > > > > > > > > > Hello everyone, > > > > > > > > Can Mg send in the same transaction more than one > > Notifyrequest? > > > > (I'm not talking about a wildcarded Notifyrequest). > > > > Does it make sense? If so,can somebody give me an example > > on how will > > > > the transaction looks like? > > > > > > > > many thanks, > > > > Rakefet Prozan, > > > > Team Manager, S/W Development > > > > Nortel SBU > > > > Telrad Networks > > > > ESN 828-3043 > > Email:rakefet.prozan@telrad.co.il > > > > > > > > > > > > > > > > -- > > > > > > > > """ > > > > -(o o)- > > > > +---------------------------------oOO--(_)--OOo--------------+ > > > > > > > > .oooO Oooo. > > > > -------------------------------( )---------( )------------ > > > > \ ( ) / > > > > \_) (_/ > > > > > > > > Have fun !!! > > > > > > > > -- > > Hi, The given examples are quite obvious according to the protocol, but the question is if it makes sense for an MG to send the following transaction: Transaction=1150 {Context=- {Notify {ObservedEvents = 2222{19990729T00000:al/of}}}, {Notify {ObservedEvents = 2222{19990729T00001:al/of}}}} thanks, -- Rakefet Prozan, Team Manager, S/W Development Nortel SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 04:13:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13632 for ; Wed, 12 Jul 2000 04:13:55 -0400 (EDT) Received: from standards (47.234.32.16:3171) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D3C7@standards.nortelnetworks.com>; Wed, 12 Jul 2000 4:03:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1519 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 04:03:19 -0400 Received: from web5103.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D3C2@standards.nortelnetworks.com>; Wed, 12 Jul 2000 3:53:18 -0400 Received: from [208.220.245.72] by web5103.mail.yahoo.com; Wed, 12 Jul 2000 01:03:30 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000712080330.24943.qmail@web5103.mail.yahoo.com> Date: Wed, 12 Jul 2000 01:03:30 -0700 Reply-To: Jack Wu Sender: "Media Gateway Control (megaco)" From: Jack Wu Subject: Question about the Signal List Type To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, Actually, the "signal list type" shoud not be inserted in to the descriptor because the MGC does not care for what kind of the signal list, it is only a sequential lists of signal which will be played by the MG, it is MG's resposibility to determine the signal list type according to the rules specified by the H.248. Since it is not related both of MG and MGC, it should be not transported by the Descriptor. It is only a policy guides the MG how to determin a signal list type. Regars, Jack __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 08:48:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19873 for ; Wed, 12 Jul 2000 08:48:58 -0400 (EDT) Received: from standards (47.234.32.16:3543) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D532@standards.nortelnetworks.com>; Wed, 12 Jul 2000 8:38:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1970 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 08:38:12 -0400 Received: from mars.hss.co.in (202.54.26.197:50331) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D50C@standards.nortelnetworks.com>; Wed, 12 Jul 2000 8:28:09 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6CCd2g00756; Wed, 12 Jul 2000 07:39:07 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525691A.00448E53 ; Wed, 12 Jul 2000 17:58:48 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525691A.00448DDE.00@sandesh.hss.hns.com> Date: Wed, 12 Jul 2000 18:03:31 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Re: R2 Package Last Call X-To: Matt Holdrege To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Matt, Please find my comments embedded................[kL] regards, Kushanava Laha, VoIP Team, Hughes Software systems Matt Holdrege on 07/12/2000 04:22:05 AM To: Kushanava Laha/HSS@HSS cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: R2 Package Last Call At 12:26 PM 7/11/00 +0530, Kushanava Laha wrote: >[HSS] The packages have been deviced in such a way that all protocol timing >sensitive issues while interfacing with a PSTN switch have been taken >care in the MG, keeping the MGC transparent. In this way all latency >related problems introduced in MG-MGC communication which may affect the >time critical signals on the CAS signaling path have been best managed at MG. It's true that the MG must respond to the time critical tones. But you still have to get some info from the MGC to process the call and that is where the timing of using MEGACO with this package could get hairy. >> [kL] If you are referring to the time critical tones involved in address/ register signaling - both the R1 and R2 packages gives the flexibility to the MG. In case of R1 the MGC sends the digits enbloc to the MGC as the "Address" signal without bothering about the digit duration or the interdigit duration. It is the MG which is provisioned with these timing information. And it is the MG which runs the statemachine for attaching the pre and post-ambles (ST and KP signals) and running the timers. The state machines for the line signaling (e.g. running the debounce timers, timers associated with Delay-dial and start-dial and interpretation of the bit patterns) are also run at MG. For R2 again the "time critical tones" are encapsulated in one single signal/event in the package which is once again the "Address" signal/event. However in case of R2 (unlike R1) the "Address" signal/event now has additional parameters that help the MG/MGC to partition conveniently the detailed information that is exchanged between the MG and the PSTN switch during the course of compelled signaling. At the line signaling end, such a timing issue did crop up while handling the Release Guard sequence....However this also has also been conveniently packaged in the "Clear" event/signal which not only does not distinguish between "Clear-back" and "Clear-forward" signals (leaves the interpreation to MG which actually maintains the direction of the call as a part of maintaing the state machine functionality) but also leaves the statemachine for the release guard sequence to the MG (the "icrgtim" and ogrgtim" parameters only specifies the release guard timeout, if the MGC wishes to override). The MGC-MG interface is therefore kept unaware of the time sensitive issues. A time sensitive signal from the PSTN side shall never time out because of delay incurred on the MG-MGC link as the handling is done at MG. Only relevant information that needs to be really conveyed to the Call Control has been packaged. However we would really appreciate if you can point out at signal or parameter level any discrepancy you may find in the package, which we may have overlooked. Another case is Protocol State Machine malfunction in the Failure message. What happens when an MGC wishes to convey that information to a switch or vice versa? >>[kL] I doubt whether either the R1 and R2 protocol gives the provision to indicate protocol state machine failures from one end-point to the other either through line or address signaling. Hence what is MG supposed to do with the "State Machine Failure" message, if at all incorporated in the packages? Could it be a problem to have open-ended strings in these messages? Shouldn't we set some bounds? Also, could native descriptors be used instead to give some bounding? >>[kL]I fail to understand the scope of open-ended strings in the packages. If the mode through which digits are reported to MGC, is what is being referred to the packages do talk about a string. The bound field is not needed as Megaco does impose an upper restriction on the number of characters in a string. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 09:09:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20856 for ; Wed, 12 Jul 2000 09:09:58 -0400 (EDT) Received: from standards (47.234.32.16:1471) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D552@standards.nortelnetworks.com>; Wed, 12 Jul 2000 8:59:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2062 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 08:59:06 -0400 Received: from qhars002.nortel.com (47.101.112.102:39715) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D551@standards.nortelnetworks.com>; Wed, 12 Jul 2000 8:59:01 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 12 Jul 2000 14:09:01 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Wed, 12 Jul 2000 08:06:06 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id <3JSNCC1B>; Wed, 12 Jul 2000 09:08:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEC02.49F4C150" Message-ID: Date: Wed, 12 Jul 2000 09:08:36 -0400 Reply-To: Sophia Scoggins Sender: "Media Gateway Control (megaco)" From: Sophia Scoggins Subject: FW: A few more details To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFEC02.49F4C150 Content-Type: text/plain; charset="iso-8859-1" I believe this topic should be on the Megaco list. Sorry for whoever received duplicate email. Regards, Sophia -----Original Message----- From: Scoggins, Sophia [NC1:3T18:EXCH] Sent: Wednesday, July 12, 2000 8:58 AM To: megaco-interop@fore.com Subject: RE: A few more details Brian, In order to interop for the ATM bearer, we have to reach agreement on the ATM package. Have you modified the ATM package yet? We (Mike Brown and myself) have sent some suggestions on the ATM package that you drafted. We would like to have the media independent packetpipe package included. Regards, Sophia -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Saturday, July 08, 2000 10:00 PM To: Scoggins, Sophia [NC1:3T18:EXCH]; megaco-interop@fore.com Subject: RE: A few more details Marconi, as host, is planning to pay for most of the cost. For planning purposes, we are using an estimate of two participants per implementation. I've told people that plan to bring more that we may charge for extras, but that would only be if the actual costs exceed my budget. We will have a better idea of the costs in a week or two. I'll plan to arrange an ATM network. We should have plenty of IP addresses, but I'll check with the UNH people. How long we will need is really an unknown. If things go well, we can get through the four scenarios in a couple of hours of minor twiddling. The first couple might take 6-8 hours, or more. At the moment, I think 2 full days will give everyone an opportunity to test against at least 4 implementations, which I would consider excellent for the first run. Some might only get two or three, others might have more opportunities. We have the room for Thursday, whether we want people to plan to stay all day is up to participants. I was assuming that the evenings would be used for either serious code rewriting (if necessary), but more likely, ad-hoc testing of interesting things that come up during the formal test periods. Brian -----Original Message----- From: Sophia Scoggins [mailto:scoggins@nortelnetworks.com] Sent: Friday, July 07, 2000 2:49 PM To: megaco-interop@fore.com Subject: RE: A few more details Brian, As we discussed before, each participant should pay for their share of cost. When you might have the fee ready? We plan to have about 10 people for 2 MG and 1 MGC. If additional cost is needed, please let me know, so that I can put it into budget. We would like to have an ATM switch, if there is any other MG ready to test VToA over the real ATM switch. You probably should ask the number of IP address needed from each MG/MGC unless you have planty. We would also like to know what airport to fly to and the possible hotels (with traveling distance to the testing site). We will also need the address and contacts for shipping equipment when it is close to the testing date. Do you believe that 2 days are sufficient? Do you want to keep Thursday open? Regards, Sophia -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] Sent: Tuesday, June 27, 2000 11:17 AM To: megaco-interop@fore.com Subject: A few more details The announcement covered most of the important items. Here are some more things to think about. There will be a web page up soon to sign up to attend. We would appreciate you letting us know as soon as possible if you are planning to come, and what you will be bringing to test (MG, MGC, both, more than one of each,...) I'll probably have a checkbox for "not really sure yet" so we can have an upper estimate of how many to plan for. You can plan to arrive any time on Monday, but we want your equipment set up, and integrated into the network by Tuesday morning, so plan to arrive early enough to get through those steps. The basic plan is to pair MGs and MGCs and let you try to get through the test profiles, and any other profiles participants may wish to try. In general, we will have time slots to do this, and you change partners for the next time slot. We may be pretty loose about the slots until we see how it is going. If necessary, we will have only one slot for the first day. We may also do scheduling dynamically -- as various pairs finish, we may assign new partners as they do. All depends on how well the testing goes. I'm planning to leave nothing scheduled for Tuesday evening, expecting that ad-hoc problem solving will occur. We will have plenty of pizza and caffeine laden beverages for that evening. We will want to start new pairs Wednesday morning, with a goal of getting as many pairs tried before the end of the day as possible. Some people will plan to leave Wednesday night, but please don't plan to leave the lab until after 5:00. At around 4:00 or so on Tuesday and Wednesday, we will all get together and discuss what we have learned. We will publish a meeting report detailing what we discover. There will be NO attribution - the goal is to find issues with the protocol, and for participants to find out how their implementation works with others. There WILL be an NDA. It will be as simple as I can get it, and it will come out in two weeks, if I can possibly manage that, so your legal folks can have lots of time to look it over. It just deals with not releasing anything that is confidential, and disclaims liability. I know that many feel that NDAs are not necessary, but others really want one. There will be a high bandwidth LAN (10/100 Ethernet) with good Internet connectivity. If we need an ATM network, we can have one- please let me know if you will need an ATM connection, and what interface you want. If you need a leased line back to your lab, let me know, and we will facilitate getting the connections in (your expense for the line!) You need to bring whatever would connect to your MG (phones, T1 simulator, PBX, Class 5 switch,...) Let me know if this is problematic & we'll try to help. I've been worrying about intra-pair communications. Many boxes will be set up, made to work, and not physically moved. That means partners will not be physically next to one another. Network connections will work, no problem, but it's harder to talk, and huddle around a screen dump. One idea is for everyone to download Netmeeting, bring a camera, and headsets. We can set up multimedia conferences across the room! Any other ideas are welcome. Other than getting out an update of the test profile document, what else do we need to get settled? Marconi, as host, will provide continental breakfast, lunch and and pizza with coffee/soda available throughout the day. We just may have t-shirts (anyone got any logo ideas?). We are planning an average of two people per MG/MGC. If you need to bring a crowd, you may get asked to defray some expenses. Please don't plan to come unless you have something to test, but don't hesitate to come if you have anything that might "talk" to another end -- plenty of implementations will be barely working, rough code. Brian ------_=_NextPart_001_01BFEC02.49F4C150 Content-Type: text/html; charset="iso-8859-1" RE: A few more details
I believe this topic should be on the Megaco list. Sorry for whoever received duplicate email.
 
 
Regards, Sophia
-----Original Message-----
From: Scoggins, Sophia [NC1:3T18:EXCH]
Sent: Wednesday, July 12, 2000 8:58 AM
To: megaco-interop@fore.com
Subject: RE: A few more details

Brian,
 

In order to interop for the ATM bearer, we have to reach agreement on the ATM package. Have you modified the ATM package yet? We (Mike Brown and myself) have sent some suggestions on the ATM package that you drafted. We would like to have the media independent packetpipe package included.
 
 
Regards, Sophia
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Saturday, July 08, 2000 10:00 PM
To: Scoggins, Sophia [NC1:3T18:EXCH]; megaco-interop@fore.com
Subject: RE: A few more details

Marconi, as host, is planning to pay for most of the cost.  For planning purposes, we are using an estimate of
two participants per implementation.  I've told people that plan to bring more that we may charge for extras, but
that would only be if the actual costs exceed my budget.
 
We will have a better idea of the costs in a week or two.
 
I'll plan to arrange an ATM network. 
 
We should have plenty of IP addresses, but I'll check with the UNH people.
 
How long we will need is really an unknown.  If things go well, we can get through the four scenarios in
a couple of hours of minor twiddling.  The first couple might take 6-8 hours, or more.  At the moment,
I think 2 full days will give everyone an opportunity to test against at least 4 implementations, which I
would consider excellent for the first run.  Some might only get two or three, others might have more
opportunities.
 
We have the room for Thursday, whether we want people to plan to stay all day is up to participants.
I was assuming that the evenings would be used for either serious code rewriting (if necessary), but
more likely, ad-hoc testing of interesting things that come up during the formal test periods.
 
Brian
-----Original Message-----
From: Sophia Scoggins [mailto:scoggins@nortelnetworks.com]
Sent: Friday, July 07, 2000 2:49 PM
To: megaco-interop@fore.com
Subject: RE: A few more details

Brian,


As we discussed before, each participant should pay for their share of cost. When you might have the fee ready? We plan to have about 10 people for 2 MG and 1 MGC. If additional cost is needed, please let me know, so that I can put it into budget. We would like to have an ATM switch, if there is any other MG ready to test VToA over the real ATM switch.

You probably should ask the number of IP address needed from each MG/MGC unless you have planty.

We would also like to know what airport to fly to and the possible hotels (with traveling distance to the testing site). We will also need the address and contacts for shipping equipment when it is close to the testing date.

Do you believe that 2 days are sufficient? Do you want to keep Thursday open?


Regards, Sophia


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, June 27, 2000 11:17 AM
To: megaco-interop@fore.com
Subject: A few more details


The announcement covered most of the important items. 
Here are some more things to think about.

There will be a web page up soon to sign up to attend. 
We would appreciate you letting us know as soon as possible
if you are planning to come, and what you will be bringing to
test (MG, MGC, both, more than one of each,...)  I'll probably
have a checkbox for "not really sure yet" so we can have an
upper estimate of how many to plan for.

You can plan to arrive any time on Monday, but we want your
equipment set up, and integrated into the network by
Tuesday morning, so plan to arrive early enough to get through
those steps.

The basic plan is to pair MGs and MGCs and let you try to get
through the test profiles, and any other profiles participants
may wish to try.  In general, we will have time slots to do this,
and you change partners for the next time slot.  We may be pretty
loose about the slots until we see how it is going.  If necessary,
we will have only one slot for the first day.  We may also
do scheduling dynamically -- as various pairs finish, we may assign
new partners as they do.  All depends on how well the testing goes.

I'm planning to leave nothing scheduled for Tuesday evening, expecting
that ad-hoc problem solving will occur.  We will have plenty of pizza
and caffeine laden beverages for that evening.  We will want to start
new pairs Wednesday morning, with a goal of getting as many pairs
tried before the end of the day as possible.  Some people will
plan to leave Wednesday night, but please don't plan to leave the
lab until after 5:00.  At around 4:00 or so on Tuesday and Wednesday,
we will all get together and discuss what we have learned.  We will
publish a meeting report detailing what we discover.  There will be
NO attribution - the goal is to find issues with the protocol, and
for participants to find out how their implementation works with others.

There WILL be an NDA.  It will be as simple as I can get it, and it will
come out in two weeks, if I can possibly manage that, so your legal
folks can have lots of time to look it over.  It just deals with not
releasing anything that is confidential, and disclaims liability.
I know that many feel that NDAs are not necessary, but others really
want one.

There will be a high bandwidth LAN (10/100 Ethernet) with good
Internet connectivity.  If we need an ATM network, we can have
one- please let me know if you will need an ATM connection, and
what interface you want.  If you need a leased line back to your
lab, let me know, and we will facilitate getting the connections
in (your expense for the line!)  You need to bring whatever would
connect to your MG (phones, T1 simulator, PBX, Class 5 switch,...)
Let me know if this is problematic & we'll try to help.

I've been worrying about intra-pair communications.  Many boxes
will be set up, made to work, and not physically moved.  That means
partners will not be physically next to one another.  Network
connections will work, no problem, but it's harder to talk,
and huddle around a screen dump.  One idea is for everyone to download
Netmeeting, bring a camera, and headsets.  We can set up
multimedia conferences across the room!  Any other ideas are welcome.

Other than getting out an update of the test profile document,
what else do we need to get settled?

Marconi, as host, will provide continental breakfast, lunch and
and pizza with coffee/soda available throughout the day. 
We just may have t-shirts (anyone got any logo ideas?).

We are planning an average of two people per MG/MGC.  If you need
to bring a crowd,  you may get asked to defray some expenses. 

Please don't plan to come unless you have something to test,
but don't hesitate to come if you have anything that might "talk"
to another end -- plenty of implementations will be barely working,
rough code.

Brian

------_=_NextPart_001_01BFEC02.49F4C150-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 09:25:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21337 for ; Wed, 12 Jul 2000 09:24:59 -0400 (EDT) Received: from standards (47.234.32.16:1471) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D57D@standards.nortelnetworks.com>; Wed, 12 Jul 2000 9:14:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2120 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 09:14:07 -0400 Received: from mars.hss.co.in (202.54.26.197:50830) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D57C@standards.nortelnetworks.com>; Wed, 12 Jul 2000 9:14:05 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6CDPgg01494 for ; Wed, 12 Jul 2000 08:25:44 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525691A.0048D495 ; Wed, 12 Jul 2000 18:45:30 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=CI8vHZDYWeIs8dnMpi9SC3mWePFy4rJz3sv2le9y9efPPqg0TLVufSxc" Content-Disposition: inline Message-ID: <6525691A.0048D39E.00@sandesh.hss.hns.com> Date: Wed, 12 Jul 2000 18:50:08 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: Re: R2 Package Last call To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=CI8vHZDYWeIs8dnMpi9SC3mWePFy4rJz3sv2le9y9efPPqg0TLVufSxc Content-type: text/plain; charset=us-ascii Content-Disposition: inline (Embedded image moved to file: pic04527.pcx) Kushanava Laha /HSS ---------------------------------------------------------------------------------------- From: Kushanava Laha@HSS on 12/07/2000 06:50 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: Subject: Re: R2 Package Last call Hi Michael, The common functions that you are referring to are very limited in number....It is limited only to seizure, seizure acknowledge (which is achieved by a combination of delay-dial and start-dial at signaling level in MG) and answer. Even the release signals in the packages cannot be abstracted at a common level, because as indicated by a difference in the signal parameters, what they achieve at signaling level is very different in the two signaling systems. The most interesting point is the difference in which address digits are send. Both the packages define an "address" parameter, but their scopes are different as because the signaling systems are different. One is compelled and the other is non-compelled. In R1 package, address limits to sending the digits flatly. Whereas R2 package extensively covers all possible information as parameters that may be required by MG during the compelling sequence. Further R2 package defines "blocking", unblocking", "Network congestion" , "subscriber line status", "dual seizure" etc as signals/events which are exploitation of the capabilities supported by the R2 signaling system and not possible in R1. In fact we had done a detailed analysis of exploiting the package inheritance concept before deciding on two different packages as we were left only with a very few options for commonality. And I feel the options would be further limited while considering other signaling systems. The concept of dedicating a package to a signaling system therefore makes more sense to me than breaking a signaling system into multiple packages. Further an attempt to filter a common base trunk signaling package runs a danger of landing into a package that has disjoint bits and pieces of each signaling system. This essentially means that a MG intending to implement only one signaling system, in its attempt to support the common package has to support fragments from other signaling systems - which is not at all desirable. regards, Kushanava Laha, VoIP Team, Hughes Software Systems. Michael Brown wrote : >>I think that there is a definite problem with going last call on this package. Sorry >>for not having brought this back up to the attention of the list sooner, but I >>figured that discussion of proposed packages was somewhat on the back burner and was >>a bit surprised by the Last Call announcement. >>At any rate, the issue I have is with the way the packages for R1 and R2 as proposed >>are defined architecturally. That is, when you take the two packages side by side it >>is immediately apparent that there is very significant overlap in the packages >>(signals and events). Based on the philosophy of creating packages as a hierarchical >>tree structure where common functions are represented at the higher level and >>variant specific functions are represented as extension packages, there needs to be >>a base package representing those common functions and extension packages as >>appropriate to reflect signaling and regional/market variants. >>This is the basis of a proposal that I presented in Adelaide for PSTN trunking, to >>support robbed bit signaling. The proposal describes a high level package which >>reflects the common functions as seen in the R1 and R2 proposals. It is described in >>section 4 of the I-D, draft-brown-megaco-supplpkgs-00.txt. >>I think this is the approach that we need to use in creating these packages to avoid >>a proliferation of packages that contain definitions for the same signals and events >>over and over again. >>Given that, I believe that Last Call on the R1 package is premature. >>Michael Brown **Cheers** ------------------------------------------------------------------------------- Be the change that you want to see in the world --0__=CI8vHZDYWeIs8dnMpi9SC3mWePFy4rJz3sv2le9y9efPPqg0TLVufSxc Content-type: application/octet-stream; name="pic04527.pcx" Content-Disposition: attachment; filename="pic04527.pcx" Content-Transfer-Encoding: base64 CgUBCAAAAAAfAB8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABIAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADKDgAByw7FDsMODsoOwwAByg7FDsIODskOAQAQwwAByQ7EDsIODskOwgDD EMMAAcgOxA7CDsgOAQDGEMMAAccOww7CDsgOwgDIEMMAAcYOww4Oxw4BAMsQwwABxQ7CDg7HDsIA yxAAFMMAAcQOwg7GDgEAwxDDAMYQAMMUwwABww4Oxg7CAMIQAMMRAMQQAMYUwwABwg7FDgEAwxAA xBEAwxACwwDFFMMAAMUOxAAQAMQRAMcQAMUUFAABxA4BAMMRAAHEEQDHEADFFMIADsQOwgDHEQEA whDCAMQQAMUUAAEOww4BAMgRAMIQABQAwxAAxRTCAMIOww7CAMkRwwDCFMMAxhQAAcIOwg4BAMYR wwDCEcMAyBQUwgDCDg7CDsIAxREAwwQAEQDCBADHFBQAAcIODg4BAMURAMQEAQDCBMIAxxTCAMMO Dg7CAMURAMcEAMQUBgDDFAABww4OAQDGEQDHBADEFAAExADDDsIOxADFEcMAAcMEAMQUAMMEAAHD DsIOwg4BwwDGEQDEBADDFADCBMIAxA7CDsQOAcMAwxEAxgTDAMMEAAHEDsIOxg4BwwARAMsEwgDE DsIODsgOAcMAywQAAcQOwg4Oyg4BwwDIBMIAxQ7CDg7MDgHDAMYEAAHFDsIODs4OAcMAwwTCAMUO ww4O0A4BwwAEAAHFDsMODtEODgHDAMYOww4O0Q7DDgABxg7DDg4MAAAAgICAgAAAgIAAAIAAAICA AACAgACAgIBAAEBAAID/AECAQAD/gEAA////wMDA/wAA//8AAP8AAP//AAD//wD///+AAP+AgP// gID//wCA/4BAwNzApsrwBAQEBAQPBA4EBA4ZBA4kBCMEDw4PDxkkGg4EGhkZGiMkGiMuGjgPGmKt JC45JDhOJGytJGy3Ly45LzhDL0JOL0JYL2ytL3e3OmyiOne3OnfCREJORE1ORE1YRFdjRHe3RIG3 RIHCQJgoTyMETzgET1dYT2JtT2KDT2yNT4GiT4G3T4HCT4u3T4vCOXshT6A5T6BDT6s5WmJjWmx4 WmyDWneYWoGYWoHCWovCWqA5WqtDWqtOZGJjZGxtZGyDZHeNZIGNZIGYZIuiZIutZIvCZJa3ZJbC ZKBOZKDMZKtOZKvhZLVYb3d4b3eDb4GNb4uib5aib5a3b5bMb6C3b6DCb6tYb6tjb6vXb7VYb7Vj b7XXb7XheoGDepatepbMeqDCeqvXeqvherVYerVjerVterXXerXhhIuNhIuYhJaihKC3hKDChKvX hKvhhLXXhLXhhL9thL94hL/hj4uNj4uYj5aYj5aij6C3j6DMj6vCj6vMj6vhj7XXj7Xhj794j7+D mk0kmpaYmpaimqCYmqCimqCtmqC3mqvMmrXXmr/Xmr/hmr/spKCipKutpLXCpLXMpL/XpL/hpMqN pMqYpMrhpMrspNTsr2xOr6utr7W3r7/Cr8qYr8rhr8rsr9SYr9Thr9TsulcuundYur/CusrCusrs utThutTsxFckxGIkxGI5xGw5xHdOxIFjxIttxKsZxL/CxMrMxNTXxNThxNTsz1ckz2Ikz2Iuz2wu z3dDz4FYz5Z4z8rXz9TMz9TXz9/hz9/sz9/3z+ns2lcZ2mIk2mIu2mwk2mwu2mw52nc52rWi2tTX 2t/h2unh2un35Hcu5Hc55IFD5IFO5ItD5N/h5Ons5On35PTs74FD/5RS778E79RD7+ns7/T3+r8E +r8Z+soP+sok --0__=CI8vHZDYWeIs8dnMpi9SC3mWePFy4rJz3sv2le9y9efPPqg0TLVufSxc-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 12:17:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00347 for ; Wed, 12 Jul 2000 12:17:54 -0400 (EDT) Received: from standards (47.234.32.16:3831) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D6AD@standards.nortelnetworks.com>; Wed, 12 Jul 2000 12:07:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2528 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 12:07:03 -0400 Received: from qhars002.nortel.com (47.101.112.102:62482) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D6AA@standards.nortelnetworks.com>; Wed, 12 Jul 2000 11:57:02 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 12 Jul 2000 17:03:59 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Wed, 12 Jul 2000 12:01:38 -0400 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JSNCDGA; Wed, 12 Jul 2000 12:00:38 -0400 Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JPMGNP0; Wed, 12 Jul 2000 12:00:37 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000711150614.00c23310@pop3.ipverse.com> <396BF916.ED0B7034@wipro.com> <396BF9C9.FE2BA74F@wipro.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396C9758.6BAFD92@americasm10.nt.com> Date: Wed, 12 Jul 2000 12:05:44 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Modification of Gateway To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit A quick example would be to modify an idle line physical termination to look for an off hook event. Michael govinda.rajp@WIPRO.COM wrote: > I correct my doubt > > Modification of Termination outside of Context > > govindaraj wrote: > > > What does Modification of Gateway Out side the Context mean , When does this > > scenario Occur. > > > > ------------------------------------------------------------------------ > > Name: govinda.rajp.vcf > > govinda.rajp.vcf Type: VCard (text/x-vcard) > > Encoding: 7bit > > Description: Card for govindaraj From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 14:53:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08677 for ; Wed, 12 Jul 2000 14:53:42 -0400 (EDT) Received: from standards (47.234.32.16:2309) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D791@standards.nortelnetworks.com>; Wed, 12 Jul 2000 14:42:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2804 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 14:42:49 -0400 Received: from qhars002.nortel.com (47.101.112.102:40620) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D781@standards.nortelnetworks.com>; Wed, 12 Jul 2000 14:32:48 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 12 Jul 2000 19:40:50 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Wed, 12 Jul 2000 14:38:02 -0400 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JSNC1AN; Wed, 12 Jul 2000 14:37:58 -0400 Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3JPMGN8N; Wed, 12 Jul 2000 14:37:57 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Brown, Michael [NC1:3T19:EXCH]" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <396A22BE.29D17B12@8x8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396CBC38.C7289B79@americasm10.nt.com> Date: Wed, 12 Jul 2000 14:43:04 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: User Interface MGCP package To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, Not sure if you were aware of the Megaco/H.248 Annex G document which is now at Last Call in this WG. It defines a set of packages similar to what you are proposing. It can be obtained from I-D web site at http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt It might desirable to make use of these packages rather than create a new one. Michael Brown Marc Petit-Huguenin wrote: > Hi all, > > We have just released an Internet Draft which defines a new MGCP package > for supporting the User Interface aspects of IP feature phones. > We look forward to your comments for improving and validating this > package. > This document is accessible at > http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt > or alternatively at > http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt > > Andy Huckridge > Marc Petit-Huguenin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 15:51:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11190 for ; Wed, 12 Jul 2000 15:51:06 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D7FE@standards.nortelnetworks.com>; Wed, 12 Jul 2000 15:40:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2974 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 15:40:20 -0400 Received: from qhars002.nortel.com (47.101.112.102:43216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D7FD@standards.nortelnetworks.com>; Wed, 12 Jul 2000 15:40:15 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 12 Jul 2000 20:50:24 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 12 Jul 2000 15:33:49 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jul 2000 15:26:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEC37.0336C260" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C3851@zcard00q.ca.nortel.com> Date: Wed, 12 Jul 2000 15:25:49 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: User Interface MGCP package X-To: "petithug@NETERGYNET.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFEC37.0336C260 Content-Type: text/plain; charset="iso-8859-1" I feel I must be somewhat blunt here. This work replicates many aspects of the H.248 Annex G: User Interface Elements and Actions Packages, currently in Standards Track Last Call under IETF Megaco WG and in White Document form for ITU SG-16 Decision, well agreed in both standards bodies. Yet, the MGCP-based proposal is not in direction of an open standard and is much less developed in terms of user interface widget coverage and level of detail. Why would anyone undertake to replicate work that is already near completion in open standards? Why would IETF Megaco WG in particular (or ITU SG-16 for that matter) want to know about work going on to perpetuate a non-standardized proposal (MGCP) which is now divergent from the real international open standards direction (Megaco/H.248)? Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt. For master/slave style IP Phone control under open standards see Megaco IP Phone Media Gateway Application Profile at http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt. -- Peter Blatherwick -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM] Sent: Monday, July 10, 2000 15:24 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: User Interface MGCP package Hi all, We have just released an Internet Draft which defines a new MGCP package for supporting the User Interface aspects of IP feature phones. We look forward to your comments for improving and validating this package. This document is accessible at http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt or alternatively at http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt Andy Huckridge Marc Petit-Huguenin ------_=_NextPart_001_01BFEC37.0336C260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: User Interface MGCP package

I feel I must be somewhat blunt here. 

This work replicates many aspects of the H.248 Annex = G: User Interface Elements and Actions Packages, currently in Standards = Track Last Call under IETF Megaco WG and in White Document form for ITU = SG-16 Decision, well agreed in both standards bodies.  Yet, the = MGCP-based proposal is not in direction of an open standard and is much = less developed in terms of user interface widget coverage and level of = detail. 

Why would anyone undertake to replicate work that is = already near completion in open standards? 

Why would IETF Megaco WG in particular (or ITU SG-16 = for that matter) want to know about work going on to perpetuate a = non-standardized proposal (MGCP) which is now divergent from the real = international open standards direction (Megaco/H.248)?  =

Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-= h248g-00.txt.  For master/slave style IP Phone control under = open standards see Megaco IP Phone Media Gateway Application Profile at = http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-02.txt.

-- Peter Blatherwick


-----Original Message-----
From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM]
Sent: Monday, July 10, 2000 15:24
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: User Interface MGCP package


Hi all,

We have just released an Internet Draft which defines = a new MGCP package
for supporting the User Interface aspects of IP = feature phones.
We look forward to your comments for improving and = validating this
package.
This document is accessible at
http://www.ietf.org/internet-drafts/draft-petithugueni= n-mgcp-ui-pkg-00.txt
or alternatively at
http://www.netergynet.com/protocols/draft-petithugueni= n-mgcp-ui-pkg-00.txt

Andy Huckridge
Marc Petit-Huguenin

------_=_NextPart_001_01BFEC37.0336C260-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 16:22:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12575 for ; Wed, 12 Jul 2000 16:22:09 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D8A1@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:11:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3197 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 16:11:21 -0400 Received: from mail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D8A0@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:11:20 -0400 Received: from nerve (internal.vsys.com [63.93.241.17]) by mail.vsys.com (8.9.3+3.2W/8.9.3) with SMTP id OAA22388; Wed, 12 Jul 2000 14:21:25 -0600 (MDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01BFEC0D.1C2B8F50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Wed, 12 Jul 2000 14:26:04 -0600 Reply-To: Bob Wise Sender: "Media Gateway Control (megaco)" From: Bob Wise Subject: Re: User Interface MGCP package X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <8E2783FA4E0CD411888D0000F8CD15D33C3851@zcard00q.ca.nortel.com> This is a multi-part message in MIME format. ------=_NextPart_000_009F_01BFEC0D.1C2B8F50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: User Interface MGCP packageTo claim that an MGCP effort is not in the direction of an open standard is, bluntly, not true. MGCP is an IETF standard, and is now maintained by the Device Control Working Group of the International Softswitch Consortium. You can go to www.softswitch.org for more information. Conversations exclusively about MGCP should probably be held on the list maintained there, not on this list. You can download RFC 2705 from the ISC homepage or from many of the RFC repositories. CableLabs has taken MGCP to ITU SG-9, so it appears that MGCP has a chance of becoming an ITU protocol, too. It is seems that MGCP and Megaco/H.248 will both live on indefinitely as open standards. -Bob ------------------------- Bob Wise Chief Architect Vsys, Inc. "The Softswitch Company" www.vsys.com -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Peter Blatherwick Sent: Wednesday, July 12, 2000 1:26 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: User Interface MGCP package I feel I must be somewhat blunt here. This work replicates many aspects of the H.248 Annex G: User Interface Elements and Actions Packages, currently in Standards Track Last Call under IETF Megaco WG and in White Document form for ITU SG-16 Decision, well agreed in both standards bodies. Yet, the MGCP-based proposal is not in direction of an open standard and is much less developed in terms of user interface widget coverage and level of detail. Why would anyone undertake to replicate work that is already near completion in open standards? Why would IETF Megaco WG in particular (or ITU SG-16 for that matter) want to know about work going on to perpetuate a non-standardized proposal (MGCP) which is now divergent from the real international open standards direction (Megaco/H.248)? Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt. For master/slave style IP Phone control under open standards see Megaco IP Phone Media Gateway Application Profile at http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt. -- Peter Blatherwick -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM] Sent: Monday, July 10, 2000 15:24 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: User Interface MGCP package Hi all, We have just released an Internet Draft which defines a new MGCP package for supporting the User Interface aspects of IP feature phones. We look forward to your comments for improving and validating this package. This document is accessible at http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt or alternatively at http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt Andy Huckridge Marc Petit-Huguenin ------=_NextPart_000_009F_01BFEC0D.1C2B8F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: User Interface MGCP package
To=20 claim that an MGCP effort is not in the direction of an open standard = is,=20 bluntly,
not=20 true.
 
MGCP is an IETF standard, and = is now=20 maintained by the Device Control Working Group
of the International Softswitch = Consortium.=20 You can go to www.softswitch.org for=20 more
information.  Conversations exclusively = about MGCP=20 should probably be held on the
list=20 maintained there, not on this list.
 
You=20 can download RFC 2705 from the ISC homepage or from many of the RFC=20 repositories.
 
CableLabs has taken MGCP to ITU SG-9, so it = appears=20 that MGCP has a chance of
becoming an ITU protocol, = too.
 
It=20 is seems that MGCP and Megaco/H.248 will both live on indefinitely = as open=20 standards.
 
-Bob

-------------------------
Bob Wise
Chief=20 Architect
Vsys, Inc.
"The Softswitch=20 Company"
www.vsys.com
 

-----Original Message-----
From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of = Peter=20 Blatherwick
Sent: Wednesday, July 12, 2000 1:26 = PM
To:=20 MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: User = Interface MGCP=20 package

I feel I must be somewhat blunt here.  =

This work replicates many aspects of the H.248 Annex = G: User=20 Interface Elements and Actions Packages, currently in Standards Track = Last=20 Call under IETF Megaco WG and in White Document form for ITU SG-16 = Decision,=20 well agreed in both standards bodies.  Yet, the MGCP-based = proposal is=20 not in direction of an open standard and is much less developed in = terms of=20 user interface widget coverage and level of detail. 

Why would anyone undertake to replicate work that is = already=20 near completion in open standards? 

Why would IETF Megaco WG in particular (or ITU SG-16 = for that=20 matter) want to know about work going on to perpetuate a = non-standardized=20 proposal (MGCP) which is now divergent from the real international = open=20 standards direction (Megaco/H.248)? 

Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-h24= 8g-00.txt. =20 For master/slave style IP Phone control under open standards see = Megaco IP=20 Phone Media Gateway Application Profile at http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipp= hone-02.txt.=20

-- Peter Blatherwick


-----Original Message-----
From: Marc=20 Petit-Huguenin [mailto:petithug@NETERGYNET.COM]=20
Sent: Monday, July 10, 2000 15:24
To:=20 MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: = User=20 Interface MGCP package


Hi all,

We have just released an Internet Draft which = defines a new=20 MGCP package
for supporting the User = Interface aspects=20 of IP feature phones.
We look forward to = your comments=20 for improving and validating this
package.=20
This document is accessible at
http://www.ietf.org/internet-drafts/draft-petithuguenin-m= gcp-ui-pkg-00.txt=20
or alternatively at
http://www.netergynet.com/protocols/draft-petithuguenin-m= gcp-ui-pkg-00.txt=20

Andy Huckridge
Marc=20 Petit-Huguenin

------=_NextPart_000_009F_01BFEC0D.1C2B8F50-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 16:28:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12864 for ; Wed, 12 Jul 2000 16:28:12 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D8EB@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:16:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3297 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 16:16:56 -0400 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D8EA@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:16:55 -0400 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id QAA00175; Wed, 12 Jul 2000 16:27:09 -0400 (EDT) Message-ID: <200007122027.QAA00175@newdev.harvard.edu> Date: Wed, 12 Jul 2000 16:27:09 -0400 Reply-To: Scott Bradner Sender: "Media Gateway Control (megaco)" From: Scott Bradner Subject: Re: User Interface MGCP package X-To: rmwise@VSYS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM > MGCP is an IETF standard, this is *not* true - MGCP is published as an Informational RFC - that is *not* a standard of any kind Scott From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 17:03:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14855 for ; Wed, 12 Jul 2000 17:03:08 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D972@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:52:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3474 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 16:52:26 -0400 Received: from mail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D971@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:52:25 -0400 Received: from nerve (internal.vsys.com [63.93.241.17]) by mail.vsys.com (8.9.3+3.2W/8.9.3) with SMTP id PAA22784; Wed, 12 Jul 2000 15:02:36 -0600 (MDT) 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.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Wed, 12 Jul 2000 15:07:14 -0600 Reply-To: Bob Wise Sender: "Media Gateway Control (megaco)" From: Bob Wise Subject: Re: User Interface MGCP package X-To: Scott Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200007122027.QAA00175@newdev.harvard.edu> Content-Transfer-Encoding: 7bit A thousand apologies. The "Informational RFC" is maintained by the ISC on behalf of the IETF. The vendors involved in implementing MGCP and conducting interoperability events treat this RFC as a standard. Work continues to maintain and enhance the RFC. Anyone is welcome to participate in its continued evolution. -Bob ------------------------- Bob Wise Chief Architect Vsys, Inc. "The Softswitch Company" www.vsys.com -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Wednesday, July 12, 2000 2:27 PM To: rmwise@VSYS.COM Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: User Interface MGCP package > MGCP is an IETF standard, this is *not* true - MGCP is published as an Informational RFC - that is *not* a standard of any kind Scott From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 17:16:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15186 for ; Wed, 12 Jul 2000 17:16:00 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D9BE@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:05:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3511 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 17:05:08 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D98D@standards.nortelnetworks.com>; Wed, 12 Jul 2000 16:55:07 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA04226; Wed, 12 Jul 2000 14:05:04 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <8E2783FA4E0CD411888D0000F8CD15D33C3851@zcard00q.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------4796961A7538AF30EDD2B074" Message-ID: <396CDE5F.99CB7561@cisco.com> Date: Wed, 12 Jul 2000 17:08:48 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: User Interface MGCP package X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------4796961A7538AF30EDD2B074 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please, let's not get into these types of counter-productive discussions again. We are all entitled to our individual opinions and strategies in this space, but this mailing list is neither the place to promote them nor argue about them. As far as the ip-phone package is concerned, I recall very clearly that we agreed *not to* make this Standards Track in Adelaide, so I don't know where you get the "standards" label from ? Maybe we should rename it to "draft-blatherwick-..." to make that clear ? -- Flemming Peter Blatherwick wrote: > > > I feel I must be somewhat blunt here. > > This work replicates many aspects of the H.248 Annex G: User Interface > Elements and Actions Packages, currently in Standards Track Last Call > under IETF Megaco WG and in White Document form for ITU SG-16 > Decision, well agreed in both standards bodies. Yet, the MGCP-based > proposal is not in direction of an open standard and is much less > developed in terms of user interface widget coverage and level of > detail. > > Why would anyone undertake to replicate work that is already near > completion in open standards? > > Why would IETF Megaco WG in particular (or ITU SG-16 for that matter) > want to know about work going on to perpetuate a non-standardized > proposal (MGCP) which is now divergent from the real international > open standards direction (Megaco/H.248)? > > Instead, for user interface packages please see > http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt. > For master/slave style IP Phone control under open standards see > Megaco IP Phone Media Gateway Application Profile at > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt. > > -- Peter Blatherwick > > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM] > Sent: Monday, July 10, 2000 15:24 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: User Interface MGCP package > > Hi all, > > We have just released an Internet Draft which defines a new MGCP > package > for supporting the User Interface aspects of IP feature phones. > We look forward to your comments for improving and validating this > package. > This document is accessible at > > ttp://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt > > or alternatively at > > ttp://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt > > Andy Huckridge > Marc Petit-Huguenin -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 --------------4796961A7538AF30EDD2B074 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please, let's not get into these types of counter-productive discussions again. We are all entitled to our individual opinions and strategies in this space, but this mailing list is neither the place to promote them nor argue about them.
 

As far as the ip-phone package is concerned, I recall very clearly that we agreed *not to* make this Standards Track in Adelaide, so I don't know where you get the "standards" label from ? Maybe we should rename it to "draft-blatherwick-..." to make that clear  ?
 

-- Flemming
 
 

Peter Blatherwick wrote:

 

I feel I must be somewhat blunt here.

This work replicates many aspects of the H.248 Annex G: User Interface Elements and Actions Packages, currently in Standards Track Last Call under IETF Megaco WG and in White Document form for ITU SG-16 Decision, well agreed in both standards bodies.  Yet, the MGCP-based proposal is not in direction of an open standard and is much less developed in terms of user interface widget coverage and level of detail.

Why would anyone undertake to replicate work that is already near completion in open standards?

Why would IETF Megaco WG in particular (or ITU SG-16 for that matter) want to know about work going on to perpetuate a non-standardized proposal (MGCP) which is now divergent from the real international open standards direction (Megaco/H.248)?

Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt.  For master/slave style IP Phone control under open standards see Megaco IP Phone Media Gateway Application Profile at http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt.

-- Peter Blatherwick

-----Original Message-----
From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM]
Sent: Monday, July 10, 2000 15:24
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: User Interface MGCP package

Hi all,

We have just released an Internet Draft which defines a new MGCP package
for supporting the User Interface aspects of IP feature phones.
We look forward to your comments for improving and validating this
package.
This document is accessible at
http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt
or alternatively at
http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt

Andy Huckridge
Marc Petit-Huguenin

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839
  --------------4796961A7538AF30EDD2B074-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 17:19:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15298 for ; Wed, 12 Jul 2000 17:19:33 -0400 (EDT) Received: from standards (47.234.32.16:1846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D9D8@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:08:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3608 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 17:08:55 -0400 Received: from newdev.harvard.edu (newdev.eecs.harvard.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7D9D7@standards.nortelnetworks.com>; Wed, 12 Jul 2000 17:08:54 -0400 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id RAA00419; Wed, 12 Jul 2000 17:19:09 -0400 (EDT) Message-ID: <200007122119.RAA00419@newdev.harvard.edu> Date: Wed, 12 Jul 2000 17:19:09 -0400 Reply-To: Scott Bradner Sender: "Media Gateway Control (megaco)" From: Scott Bradner Subject: Re: User Interface MGCP package X-To: rmwise@vsys.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM > The vendors involved in implementing MGCP and conducting interoperability > events treat this RFC as a standard. they may do so if the wish but in no way has the IETF said that it is a standard (and I hope that your note here is not an indication of a systematic misrepresentation) Scott From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 18:23:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17087 for ; Wed, 12 Jul 2000 18:23:25 -0400 (EDT) Received: from standards (47.234.32.16:2601) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DA4A@standards.nortelnetworks.com>; Wed, 12 Jul 2000 18:12:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3758 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 18:12:41 -0400 Received: from mail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DA49@standards.nortelnetworks.com>; Wed, 12 Jul 2000 18:12:40 -0400 Received: from nerve (internal.vsys.com [63.93.241.17]) by mail.vsys.com (8.9.3+3.2W/8.9.3) with SMTP id QAA23274; Wed, 12 Jul 2000 16:22:52 -0600 (MDT) 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.2911.0) Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Wed, 12 Jul 2000 16:27:30 -0600 Reply-To: Bob Wise Sender: "Media Gateway Control (megaco)" From: Bob Wise Subject: Re: User Interface MGCP package X-To: Scott Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200007122119.RAA00419@newdev.harvard.edu> Content-Transfer-Encoding: 7bit The representation of MGCP as a standard is systematic. An IETF document (an information RFC) is thought of and used as a standard, so that fact that it has not been offically declared a standard is practically irrelevant. -Bob ------------------------- Bob Wise Chief Architect Vsys, Inc. "The Softswitch Company" www.vsys.com -----Original Message----- From: Scott Bradner [mailto:sob@harvard.edu] Sent: Wednesday, July 12, 2000 3:19 PM To: rmwise@vsys.com; sob@harvard.edu Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: RE: User Interface MGCP package > The vendors involved in implementing MGCP and conducting interoperability > events treat this RFC as a standard. they may do so if the wish but in no way has the IETF said that it is a standard (and I hope that your note here is not an indication of a systematic misrepresentation) Scot From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 12 18:35:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17336 for ; Wed, 12 Jul 2000 18:35:39 -0400 (EDT) Received: from standards (47.234.32.16:2601) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DA7A@standards.nortelnetworks.com>; Wed, 12 Jul 2000 18:24:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3821 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jul 2000 18:24:58 -0400 Received: from marlborough.cnchost.com (marlborough.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DA79@standards.nortelnetworks.com>; Wed, 12 Jul 2000 18:24:58 -0400 Received: from MATT.ascend.com (w066.z208037018.sjc-ca.dsl.cnc.net [208.37.18.66]) by marlborough.cnchost.com id SAA06136; Wed, 12 Jul 2000 18:35:09 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000712153208.00c4b380@pop3.ipverse.com> Date: Wed, 12 Jul 2000 15:35:38 -0700 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: R2 Package Last Call X-To: klaha@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <6525691A.00448DDE.00@sandesh.hss.hns.com> Please see my comments below... At 06:03 PM 7/12/00 +0530, klaha@hss.hns.com wrote: >Hi Matt, > Please find my comments embedded................[kL] > >regards, >Kushanava Laha, >VoIP Team, >Hughes Software systems > > > > > >Matt Holdrege on 07/12/2000 04:22:05 AM > >To: Kushanava Laha/HSS@HSS >cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > >Subject: Re: R2 Package Last Call > > > > >At 12:26 PM 7/11/00 +0530, Kushanava Laha wrote: > >[HSS] The packages have been deviced in such a way that all protocol timing > >sensitive issues while interfacing with a PSTN switch have been taken > >care in the MG, keeping the MGC transparent. In this way all latency > >related problems introduced in MG-MGC communication which may affect the > >time critical signals on the CAS signaling path have been best managed > at MG. > >It's true that the MG must respond to the time critical tones. But you >still have to get some info from the MGC to process the call and that is >where the timing of using MEGACO with this package could get hairy. > > >> [kL] If you are referring to the time critical tones involved in address/ >register signaling - both the R1 and R2 packages gives the flexibility to the >MG. In case of R1 the MGC sends the digits enbloc to the MGC as the "Address" >signal without bothering about the digit duration or the interdigit duration. >It is the MG which is provisioned with these timing information. And it is the >MG >which runs the statemachine for attaching the pre and post-ambles (ST and KP >signals) >and running the timers. The state machines for the line signaling (e.g. >running the debounce timers, timers associated with Delay-dial and start-dial >and interpretation of the bit patterns) are also run at MG. For R2 again the >"time critical tones" are encapsulated in one single signal/event in the >package which is once again the "Address" signal/event. However in case of >R2 (unlike R1) the "Address" signal/event now has additional parameters that >help the MG/MGC to partition conveniently the detailed information that is >exchanged between the MG and the PSTN switch during the course of compelled >signaling. At the line signaling end, such a timing issue did crop up while >handling the Release Guard sequence....However this also has also been >conveniently >packaged in the "Clear" event/signal which not only does not distinguish >between "Clear-back" and "Clear-forward" signals (leaves the interpreation >to MG >which actually maintains the direction of the call as a part of maintaing the >state machine functionality) but also leaves the statemachine for the release >guard sequence to the MG (the "icrgtim" and ogrgtim" parameters only specifies >the >release guard timeout, if the MGC wishes to override). >The MGC-MG interface is therefore kept unaware of the time sensitive issues. >A time sensitive signal from the PSTN side shall never time out because of >delay >incurred on the MG-MGC link as the handling is done at MG. Only relevant >information >that needs to be really conveyed to the Call Control has been packaged. >However we would really appreciate if you can point out at signal or parameter >level any discrepancy you may find in the package, which we may have >overlooked. Wow. The above missive contains some very useful information that should be in the draft. In fact, I would remove the R2 tutorial since anyone can read the ITU spec and put the above information in with the proper phrasing. >Another case is Protocol State Machine malfunction in the Failure message. >What >happens when an MGC wishes to convey that information to a switch or vice >versa? > > >>[kL] I doubt whether either the R1 and R2 protocol gives the provision to >indicate >protocol state machine failures from one end-point to the other either through >line or address signaling. Hence what is MG supposed to do with the "State >Machine >Failure" message, if at all incorporated in the packages? I don't understand. If it is not used, then why is it in your draft? >Could it be a problem to have open-ended strings in these messages? >Shouldn't we set some bounds? Also, could native descriptors be used >instead to give some bounding? > > >>[kL]I fail to understand the scope of open-ended strings in the packages. >If the mode through which digits are reported to MGC, is what is being >referred >to >the packages do talk about a string. The bound field is not needed as Megaco >does impose an upper restriction on the number of characters in a string. For performance reasons bounding is a good idea in general. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 00:20:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24545 for ; Thu, 13 Jul 2000 00:20:15 -0400 (EDT) Received: from standards (47.234.32.16:2980) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DB96@standards.nortelnetworks.com>; Thu, 13 Jul 2000 0:08:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4196 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 00:08:17 -0400 Received: from qhars002.nortel.com (47.101.112.102:55986) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DB95@standards.nortelnetworks.com>; Thu, 13 Jul 2000 0:08:16 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 13 Jul 2000 05:15:01 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Thu, 13 Jul 2000 00:13:48 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 13 Jul 2000 00:13:48 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B53@zcard00g.ca.nortel.com> Date: Thu, 13 Jul 2000 00:13:46 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: 48th IETF Agenda To: MEGACO@STANDARDS.NORTELNETWORKS.COM It's time to start thinking about the meeting agenda. We have been tentatively scheduled for Thursday 1530-1730. The lineup for that slot is as follows: APP webdav WWW Distributed Authoring and Versioning WG INT ipfc IP Over Fibre Channel WG OPS opsarea Operation and Management Area Open Meeting RTG nbvpn Network-Based VPNs BOF SEC xmldsig XML Digital Signatures WG TSV megaco Media Gateway Control WG TSV rohc Robust Header Compression WG Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 02:45:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08876 for ; Thu, 13 Jul 2000 02:45:44 -0400 (EDT) Received: from standards (47.234.32.16:3157) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DC0C@standards.nortelnetworks.com>; Thu, 13 Jul 2000 2:35:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4351 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 02:35:01 -0400 Received: from mars.hss.co.in (202.54.26.197:56372) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DC07@standards.nortelnetworks.com>; Thu, 13 Jul 2000 2:25:00 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6D6adg10993 for ; Thu, 13 Jul 2000 01:36:40 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525691B.00235FB8 ; Thu, 13 Jul 2000 11:56:22 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525691B.00235D9C.00@sandesh.hss.hns.com> Date: Thu, 13 Jul 2000 12:00:59 +0530 Reply-To: klaha@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kushanava Laha Subject: R2 package - last call To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Matt, The "Failure" message in the packages is an event and not a signal. No one prevents from sending a solicited Failure to MGC from MG in case of R1 or R2 state machine malfunction at MG. It is upto the MGC to decide then what is to be done on occurence of such an event. MGC may wish to release the call. The drafts DO NOT talk of a failure as a signal from MGC to MG as a result of state machine malfunction or any other error condition at MGC as MG is NOT the entitiy to decide and act on MGC signaling procedure failures. Regarding the issue of bounding, even the digitmap completion event in section E.6 of the Megaco protocol document defines a "dialstring" as "a string of digit map symbols (possibly empty) returned as a quoted string" and assumes the bound imposed by the protocol on the number of characters in a "string". I admit that bounding is required for performance reasons and it is there, implicitly. regards, Kushanava Laha Matt wrote: >Another case is Protocol State Machine malfunction in the Failure message. >What >happens when an MGC wishes to convey that information to a switch or vice >versa? > > >>[kL] I doubt whether either the R1 and R2 protocol gives the provision to >indicate >protocol state machine failures from one end-point to the other either through >line or address signaling. Hence what is MG supposed to do with the "State >Machine >Failure" message, if at all incorporated in the packages? I don't understand. If it is not used, then why is it in your draft? >Could it be a problem to have open-ended strings in these messages? >Shouldn't we set some bounds? Also, could native descriptors be used >instead to give some bounding? > > >>[kL]I fail to understand the scope of open-ended strings in the packages. >If the mode through which digits are reported to MGC, is what is being >referred >to >the packages do talk about a string. The bound field is not needed as Megaco >does impose an upper restriction on the number of characters in a string. For performance reasons bounding is a good idea in general. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 15:31:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06661 for ; Thu, 13 Jul 2000 15:31:45 -0400 (EDT) Received: from standards (47.234.32.16:4874) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DF50@standards.nortelnetworks.com>; Thu, 13 Jul 2000 15:20:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5468 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 15:20:55 -0400 Received: from tnint06.telogy.com (mail.telogy.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DF4F@standards.nortelnetworks.com>; Thu, 13 Jul 2000 15:20:55 -0400 Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id <34MJYRTB>; Thu, 13 Jul 2000 15:31:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <61891BA043DED21180920090273F173801164B7B@TNINT06> Date: Thu, 13 Jul 2000 15:30:50 -0400 Reply-To: Shankara Ramamurthy Sender: "Media Gateway Control (megaco)" From: Shankara Ramamurthy To: MEGACO@STANDARDS.NORTELNETWORKS.COM In the Call flow example provided in Appendix A of the protocol, Step 3 mentions a special Voice Activity Detection (VAD) algorithm (VAD=X-NNVAD). Is there a list of encodings for various well-known VAD schemes? If so I would like to know where I can locate this list. Thanks -Shankara From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 15:33:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06723 for ; Thu, 13 Jul 2000 15:33:56 -0400 (EDT) Received: from standards (47.234.32.16:4874) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DF69@standards.nortelnetworks.com>; Thu, 13 Jul 2000 15:22:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5501 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 15:22:44 -0400 Received: from tnint06.telogy.com (mail.telogy.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DF68@standards.nortelnetworks.com>; Thu, 13 Jul 2000 15:22:42 -0400 Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id <34MJYRTM>; Thu, 13 Jul 2000 15:32:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <61891BA043DED21180920090273F173801164B7C@TNINT06> Date: Thu, 13 Jul 2000 15:32:31 -0400 Reply-To: Shankara Ramamurthy Sender: "Media Gateway Control (megaco)" From: Shankara Ramamurthy Subject: Voice Activity Detection (VAD) schemes To: MEGACO@STANDARDS.NORTELNETWORKS.COM > In the Call flow example provided in Appendix A of the protocol, Step 3 > mentions a special Voice Activity Detection (VAD) algorithm (VAD=X-NNVAD). > Is there a list of encodings for various well-known VAD schemes? If so I > would like to know where I can locate this list. > > Thanks > > -Shankara From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 16:48:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22574 for ; Thu, 13 Jul 2000 16:48:54 -0400 (EDT) Received: from standards (47.234.32.16:2136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DFBC@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:38:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5609 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 16:38:00 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DFB9@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:28:00 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6DKcEM20230; Thu, 13 Jul 2000 22:38:15 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id WAA19668; Thu, 13 Jul 2000 22:38:14 +0200 (MET DST) Received: from ericsson.com (ki-120.kiedt.ericsson.se [147.214.100.120]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id WAA07836; Thu, 13 Jul 2000 22:38:09 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF67852A@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396C33AE.4166C66D@ericsson.com> Date: Wed, 12 Jul 2000 19:00:30 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Parameters in Local Control X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Why would we have a distinction in behaviour between Local Control, Local and Remote? They will all have property=value constructs and have properties defined by packages. We also have a concept to "delete" properties which needs to be maintained for Local Control. I wasn't particularly keen on having to re-send properties to keep them but that's what we decided to do so I feel that to be consistent in behaviour that we should keep things as is. Cheers, Christian "Rosen, Brian" wrote: > > In the text, section 7.1.7, it states: > A new setting of the LocalControl Descriptor completely replaces the > previous setting of that descriptor in the MG. Thus to retain > information from the previous setting the MGC must include that > information in the new setting. If the MGC wishes to delete some > information from the existing descriptor, it merely resends the > descriptor (in a Modify command) with the unwanted information > stripped out. > > Suppose you implemented a couple packages that defined a dozen or > so properties. Do you have to repeat the values of each of these > properties in every modify of LocalControl? > > I think this paragraph is a remnant of an earlier concept, and with > LocalControl defined as it is now, this statement is in error, and > the actual desired behavior is that values are kept until modified. > Consider that LocalControl presently has only the Mode property, > the ReserveGroup and ReserveValue properties and properties of > a termination. > This means there is nothing in LocalControl that is not a property > with a value (as opposed to, say a flag). Thus keeping old values > is very feasible, and I believe, what is desired. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 17:04:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22582 for ; Thu, 13 Jul 2000 16:48:54 -0400 (EDT) Received: from standards (47.234.32.16:2136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DFC1@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:38:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5610 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 16:38:09 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7DFBA@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:28:08 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6DKcMM20234; Thu, 13 Jul 2000 22:38:22 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id WAA19672; Thu, 13 Jul 2000 22:38:22 +0200 (MET DST) Received: from ericsson.com (ki-120.kiedt.ericsson.se [147.214.100.120]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id WAA07840; Thu, 13 Jul 2000 22:38:17 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <20000712055031.13366.qmail@web5105.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396C3532.AD7D9937@ericsson.com> Date: Wed, 12 Jul 2000 19:06:58 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Questions about signalList Descriptor X-To: Jack Wu To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Jack, It is not an editorial error. There are rules in H248 that define the behaviour of a signallist given that individual signals in the list have certain signal types. Cheers, Christian Jack Wu wrote: > > Hi, > > I've scrutinized the ietf-draft-merge-01, in my opion > the ASN.1 representaion should be > > SeqSigList ::= SEQUENCE > { > id INTEGER(0..65535), > signalList SEQUENCE OF Signal, > signalListType SignalType > } > > other than > SeqSigList ::= SEQUENCE > { > id INTEGER(0..65535), > signalList SEQUENCE OF Signal, > } > > the ABNF representation should be > > signalList = SignalListToken EQUAL signalList Id > LBRKT > signalListType, SignalListParm > *(COMMA signalListParm) RBRKT > > instead of > > signalList = SignalListToken EQUAL signalList Id > LBRKT > SignalListParm *(COMMA > signalListParm) RBRKT > > I think it is an editorial error. > > Regars, > > Richie Wu > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 17:07:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00800 for ; Thu, 13 Jul 2000 17:07:11 -0400 (EDT) Received: from standards (47.234.32.16:2136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E032@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:56:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5774 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 16:56:26 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E031@standards.nortelnetworks.com>; Thu, 13 Jul 2000 16:56:25 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA28679; Thu, 13 Jul 2000 17:06:39 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA28269; Thu, 13 Jul 2000 17:06:42 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3VHKV9SK>; Thu, 13 Jul 2000 17:06:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678549@whq-msgusr-02.fore.com> Date: Thu, 13 Jul 2000 17:06:40 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Parameters in Local Control X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM If the ONLY thing you can put in a descriptor is a property=value construct, then I think you don't need, and don't want to have to, repeat values. That would apply to local and remote too. All of our examples, to date, do not assume that you have to repeat old values. I don't think there is any concept of "deleting" properties. What kind of properties were you thinking of? Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Wednesday, July 12, 2000 5:01 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Parameters in Local Control > > > G'Day Brian, > > Why would we have a distinction in behaviour between Local Control, > Local and Remote? They will all have property=value > constructs and have > properties defined by packages. We also have a concept to "delete" > properties which needs to be maintained for Local Control. > > I wasn't particularly keen on having to re-send properties to > keep them > but that's what we decided to do so I feel that to be consistent in > behaviour that we should keep things as is. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > In the text, section 7.1.7, it states: > > A new setting of the LocalControl Descriptor completely replaces the > > previous setting of that descriptor in the MG. Thus to retain > > information from the previous setting the MGC must include that > > information in the new setting. If the MGC wishes to delete some > > information from the existing descriptor, it merely resends the > > descriptor (in a Modify command) with the unwanted information > > stripped out. > > > > Suppose you implemented a couple packages that defined a dozen or > > so properties. Do you have to repeat the values of each of these > > properties in every modify of LocalControl? > > > > I think this paragraph is a remnant of an earlier concept, and with > > LocalControl defined as it is now, this statement is in error, and > > the actual desired behavior is that values are kept until modified. > > Consider that LocalControl presently has only the Mode property, > > the ReserveGroup and ReserveValue properties and properties of > > a termination. > > This means there is nothing in LocalControl that is not a property > > with a value (as opposed to, say a flag). Thus keeping old values > > is very feasible, and I believe, what is desired. > > > > Brian > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 17:41:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13644 for ; Thu, 13 Jul 2000 17:41:14 -0400 (EDT) Received: from standards (47.234.32.16:2136) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E096@standards.nortelnetworks.com>; Thu, 13 Jul 2000 17:30:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5899 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 17:30:24 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E091@standards.nortelnetworks.com>; Thu, 13 Jul 2000 17:20:23 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id OAA02010; Thu, 13 Jul 2000 14:30:21 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <8E2783FA4E0CD411888D0000F8CD15D33C3857@zcard00q.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------3AE97CB08B6D9FF021A297F4" Message-ID: <396E35CD.A4537892@cisco.com> Date: Thu, 13 Jul 2000 17:34:05 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: User Interface MGCP package X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------3AE97CB08B6D9FF021A297F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There was quite a lot of list discussion in April as well as in the Adelaide meeting about the appropriateness of having a profile supporting only a subset of the mandatory requirements defined by the Megaco protocol. I thought we all agreed, that profiles are not allowed to do that, at least not if they want official Megaco blessing. Now, the ipphone-02 package violates that, so I don't see how it can be a working group item. Can somebody please clarify this ? Thanks Flemming Peter Blatherwick wrote: > Flemming, all:Correct. As I understood it, Megaco IP Phone MG was > agreed to go forward as Informational RFC once final details are > complete, not Standards Track, since it is an application of > Megaco/H.248 and derives from work outside of IETF. My wording was > unclear on this. Meant to say "based on open standards" -- not to > imply it is itself an open standard in IETF. (I note however that > considerable re-work and 2 draft iterations has happened as a result > of Megaco list discussion. Work is carried out on behalf of TIA > TR-41.3.4 working group on VoIP Telephones, as an option for phone > control, other options being SIP or H.323.) As far as WG status, this > has been accepted as a WG work item since 00 version first posted June > last year. Was draft-blatherwick- before that. Sorry for any > confusion there. -- Peter Blatherwick > > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Wednesday, July 12, 2000 17:09 > To: Blatherwick, Peter [CAR:AT14:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: User Interface MGCP package > > Please, let's not get into these types of counter-productive > discussions again. We are all entitled to our individual > opinions and strategies in this space, but this mailing list > is neither the place to promote them nor argue about them. > > > As far as the ip-phone package is concerned, I recall very > clearly that we agreed *not to* make this Standards Track in > Adelaide, so I don't know where you get the "standards" > label from ? Maybe we should rename it to > "draft-blatherwick-..." to make that clear ? > > > -- Flemming > > > > Peter Blatherwick wrote: > > > > > > > I feel I must be somewhat blunt here. > > > > This work replicates many aspects of the H.248 Annex G: > > User Interface Elements and Actions Packages, currently in > > Standards Track Last Call under IETF Megaco WG and in > > White Document form for ITU SG-16 Decision, well agreed in > > both standards bodies. Yet, the MGCP-based proposal is > > not in direction of an open standard and is much less > > developed in terms of user interface widget coverage and > > level of detail. > > > > Why would anyone undertake to replicate work that is > > already near completion in open standards? > > > > Why would IETF Megaco WG in particular (or ITU SG-16 for > > that matter) want to know about work going on to > > perpetuate a non-standardized proposal (MGCP) which is now > > divergent from the real international open standards > > direction (Megaco/H.248)? > > > > Instead, for user interface packages please see > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt. > > For master/slave style IP Phone control under open > > standards see Megaco IP Phone Media Gateway Application > > Profile at > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt. > > > > -- Peter Blatherwick > > > > -----Original Message----- > > From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM] > > > > Sent: Monday, July 10, 2000 15:24 > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: User Interface MGCP package > > > > Hi all, > > > > We have just released an Internet Draft which defines a > > new MGCP package > > for supporting the User Interface aspects of IP feature > > phones. > > We look forward to your comments for improving and > > validating this > > package. > > This document is accessible at > > > > ttp://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt > > > > or alternatively at > > > > ttp://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt > > > > Andy Huckridge > > Marc Petit-Huguenin > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 > > -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 --------------3AE97CB08B6D9FF021A297F4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit There was quite a lot of list discussion in April as well as in the Adelaide meeting about the appropriateness of having a profile supporting only a subset of the mandatory requirements defined by the Megaco protocol. I thought we all agreed, that profiles are not allowed to do that, at least not if they want official Megaco blessing. Now, the ipphone-02 package violates that, so I don't see how it can be a working group item. Can somebody please clarify this ?
 

Thanks

        Flemming
 

Peter Blatherwick wrote:

 Flemming, all:Correct.  As I understood it, Megaco IP Phone MG was agreed to go forward as Informational RFC once final details are complete, not Standards Track, since it is an application of Megaco/H.248 and derives from work outside of IETF.  My wording was unclear on this.  Meant to say "based on open standards" -- not to imply it is itself an open standard in IETF.  (I note however that considerable re-work and 2 draft iterations has happened as a result of Megaco list discussion.  Work is carried out on behalf of TIA TR-41.3.4 working group on VoIP Telephones, as an option for phone control, other options being SIP or H.323.) As far as WG status, this has been accepted as a WG work item since 00 version first posted June last year.  Was draft-blatherwick- before that. Sorry for any confusion there. -- Peter Blatherwick
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Wednesday, July 12, 2000 17:09
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: User Interface MGCP package
 
Please, let's not get into these types of counter-productive discussions again. We are all entitled to our individual opinions and strategies in this space, but this mailing list is neither the place to promote them nor argue about them.
 

As far as the ip-phone package is concerned, I recall very clearly that we agreed *not to* make this Standards Track in Adelaide, so I don't know where you get the "standards" label from ? Maybe we should rename it to "draft-blatherwick-..." to make that clear  ?
 

-- Flemming
 
 

Peter Blatherwick wrote:

 

I feel I must be somewhat blunt here.

This work replicates many aspects of the H.248 Annex G: User Interface Elements and Actions Packages, currently in Standards Track Last Call under IETF Megaco WG and in White Document form for ITU SG-16 Decision, well agreed in both standards bodies.  Yet, the MGCP-based proposal is not in direction of an open standard and is much less developed in terms of user interface widget coverage and level of detail.

Why would anyone undertake to replicate work that is already near completion in open standards?

Why would IETF Megaco WG in particular (or ITU SG-16 for that matter) want to know about work going on to perpetuate a non-standardized proposal (MGCP) which is now divergent from the real international open standards direction (Megaco/H.248)?

Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt.  For master/slave style IP Phone control under open standards see Megaco IP Phone Media Gateway Application Profile at http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt.

-- Peter Blatherwick

-----Original Message-----
From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM]
Sent: Monday, July 10, 2000 15:24
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: User Interface MGCP package

Hi all,

We have just released an Internet Draft which defines a new MGCP package
for supporting the User Interface aspects of IP feature phones.
We look forward to your comments for improving and validating this
package.
This document is accessible at
http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt
or alternatively at
http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt

Andy Huckridge
Marc Petit-Huguenin

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839
 

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839
  --------------3AE97CB08B6D9FF021A297F4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 18:25:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28411 for ; Thu, 13 Jul 2000 18:25:43 -0400 (EDT) Received: from standards (47.234.32.16:2608) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E0EE@standards.nortelnetworks.com>; Thu, 13 Jul 2000 18:15:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6021 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 18:15:01 -0400 Received: from motgate3.mot.com (144.189.100.103:57880) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E0ED@standards.nortelnetworks.com>; Thu, 13 Jul 2000 18:15:00 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA25346 for ; Thu, 13 Jul 2000 15:23:53 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA02239 for ; Thu, 13 Jul 2000 15:25:06 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id RAA07278; Thu, 13 Jul 2000 17:24:23 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id RAA18995; Thu, 13 Jul 2000 17:24:23 -0500 (CDT) X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200007132224.RAA18995@agevole.cig.mot.com> Date: Thu, 13 Jul 2000 17:26:46 -0500 Reply-To: Qiaobing Xie Sender: "Media Gateway Control (megaco)" From: Qiaobing Xie Subject: Minor correction on Annex H draft (draft-ietf-megaco-h248h-00.txt) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit >3. Overview > > Megaco protocol messages may be transmitted over the Simple Control ^^ Stream --/ > Transmission Protocol (SCTP) [4]. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 20:23:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02520 for ; Thu, 13 Jul 2000 20:23:02 -0400 (EDT) Received: from standards (47.234.32.16:2563) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E187@standards.nortelnetworks.com>; Thu, 13 Jul 2000 20:12:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6222 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 20:12:19 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E186@standards.nortelnetworks.com>; Thu, 13 Jul 2000 20:02:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29460; Thu, 13 Jul 2000 20:12:34 -0400 (EDT) Message-ID: <200007140012.UAA29460@ietf.org> Date: Thu, 13 Jul 2000 20:12:34 -0400 Reply-To: iesg@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: Megaco Protocol (With erratta folded in) to Proposed Standard To: MEGACO@STANDARDS.NORTELNETWORKS.COM The IESG has received a request from the Media Gateway Control Working Group to consider Megaco Protocol (With erratta folded in) as a Proposed Standard. This document will render obsolete the RFCs derived from draft-ietf-megaco-protocol-08.txt and draft-ietf-megaco-errata-03.txt, providing the equivalent content in a single merged document. It would also fulfil the IETF intent to publish the decided content of ITU-T Recommendation H.248 as a Proposed Standard RFC. Since this document is the combination of two other documents that have been through IETF last call only newly discovered major issues should be brought up at this time. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 27, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-megaco-merged-01.txt From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 13 20:28:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03859 for ; Thu, 13 Jul 2000 20:28:02 -0400 (EDT) Received: from standards (47.234.32.16:2563) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E19B@standards.nortelnetworks.com>; Thu, 13 Jul 2000 20:17:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6249 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jul 2000 20:17:25 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E19A@standards.nortelnetworks.com>; Thu, 13 Jul 2000 20:17:24 -0400 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA16882; Thu, 13 Jul 2000 17:27:54 -0700 (PDT) Received: from bfoster-nt (bfoster-dsl3.cisco.com [10.19.86.12]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ADK24025; Thu, 13 Jul 2000 17:27:41 -0700 (PDT) X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.2.0.58.20000713165956.024497d0@mira-sjc5-1.cisco.com> Date: Thu, 13 Jul 2000 17:25:16 -0700 Reply-To: Bill Foster Sender: "Media Gateway Control (megaco)" From: Bill Foster Subject: R1 Package X-To: Tom-PT Taylor , Kushanava Laha To: MEGACO@STANDARDS.NORTELNETWORKS.COM A couple of questions/comments to Tom and also Kushanava. 1. Given the request for last call on the R2 package and request to make the R1 package a work-group item: Is the intent for to cover CAS in general within the work group? 2. Is the R1 expected to be the basis for other North American CAS (MF wink start, immediate start, DTMF wink start, Immediate start, FGC, FGD) - or only ITU Q.3xx? 3. draft-hss-megaco-r1package-00.txt indicates that the MG adds and strips the KP and ST without the MGC having to worry about it. In the case of FGD MF - the MGC has to supply the KP and ST on sending (could be ST' or ST'' or ST''' - all of which have a different meaning) - similar on receipt - the MGC has to receive those (can't strip them and throw them away) - so if the intent is to use this R1 package as the basis for North American CAS, this is a problem. If a completely separate package (or packages) can be presented - then OK. 4. Using a digit map for MF CAS is unnecessary and inconvenient. Digit strings are already delimited by the ST. It's easier and more convenient to simply accumulate the digits and report the digit string when the ST arrives. ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 03:19:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18906 for ; Fri, 14 Jul 2000 03:19:49 -0400 (EDT) Received: from standards (47.234.32.16:4209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E2E0@standards.nortelnetworks.com>; Fri, 14 Jul 2000 3:08:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6693 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 03:08:53 -0400 Received: from web5101.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E2DA@standards.nortelnetworks.com>; Fri, 14 Jul 2000 2:58:52 -0400 Received: from [208.220.245.72] by web5101.mail.yahoo.com; Fri, 14 Jul 2000 00:09:10 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20000714070910.21889.qmail@web5101.mail.yahoo.com> Date: Fri, 14 Jul 2000 00:09:10 -0700 Reply-To: Jack Wu Sender: "Media Gateway Control (megaco)" From: Jack Wu Subject: A question concern with EventBuffer Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, I am confused by the EventBuffer Descriptor of H.248. In the 7.2 Command Application Programming Interface section, the EventBuffer only be allowed as an retrun descriptor of commands other than parameter, viz. the EventBuffer descriptor can never be a parameter of a command, while in the rules of Annex A and B ASN.1 and ABNF the EventBuffer descriptor can be as both return and parameter. This is a conflict situation. I want to know which is cerrect. Regards, Jack __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 04:07:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29309 for ; Fri, 14 Jul 2000 04:07:45 -0400 (EDT) Received: from standards (47.234.32.16:1734) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E308@standards.nortelnetworks.com>; Fri, 14 Jul 2000 3:57:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6753 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 03:57:05 -0400 Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E307@standards.nortelnetworks.com>; Fri, 14 Jul 2000 3:57:04 -0400 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA26653 for ; Fri, 14 Jul 2000 10:06:47 +0200 (MET DST) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA22360 for ; Fri, 14 Jul 2000 10:06:55 +0200 (MET DST) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id <3WHCA5TF>; Fri, 14 Jul 2000 10:07:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Message-ID: <1BAFEBDF4429D311BA4C0008C70DB9D2809600@MCHH245E> Date: Fri, 14 Jul 2000 10:02:03 +0200 Reply-To: Ruppelt Christian Sender: "Media Gateway Control (megaco)" From: Ruppelt Christian Subject: Type of Service To: MEGACO@STANDARDS.NORTELNETWORKS.COM In MGCP LocalConnectionOptions the parameter "Type of Service" is defined (the parameter encodes the 8-bit type of service value parameter of the IP header) which is used to control QoS. Do we have an equivalent in megaco? regards Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 09:05:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18940 for ; Fri, 14 Jul 2000 09:05:24 -0400 (EDT) Received: from standards (47.234.32.16:1519) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E40E@standards.nortelnetworks.com>; Fri, 14 Jul 2000 8:54:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7096 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 08:54:36 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E40C@standards.nortelnetworks.com>; Fri, 14 Jul 2000 8:44:36 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6ECsrM15019; Fri, 14 Jul 2000 14:54:53 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id OAA08818; Fri, 14 Jul 2000 14:54:52 +0200 (MET DST) Received: from ericsson.com (ki-154.kiedt.ericsson.se [147.214.100.154]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id OAA08891; Fri, 14 Jul 2000 14:54:44 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF678549@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396F0D79.174833A3@ericsson.com> Date: Fri, 14 Jul 2000 22:54:17 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Parameters in Local Control X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, I'm a little confused by this. In Megaco we settled on the following behaviour: "A new setting of a Local or Remote Descriptor completely replaces the previous setting of that descriptor in the MG. Thus to retain information from the previous setting the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify command) with the unwanted information stripped out." I believe that properties=values are applicable for local and remote. So to date we do assume that you have to repeat old values. The issue is that we need to be able to remove a property after we have set it to a value otherwise in every single property we need a value to turn the property off. For example: You have a stream with media flowing. If you audited_value then no modem would appear. You then put a modem property on a line. If you audited_value then a modem property would appear., You then turn the modem property off because you want to remove it (remove the associated physical resource from the stream). Do an audit and it still appears. I thought that you wouldn't want to see anything as you removed the modem. Another example: You have a stream with media flowing but with no reference to an echo canceller. You add the echo canceller property and turn it ON. You turn the echo canceller OFF but you still want it inlinked in the call but not operating, turning the property to off would allow this behaviour. You then want to outlink the echo canceller. Removing the property would allow this. So I believe you need to be able to: o Assign a property a value. o Turn this property off. o Remove this property. I don't think we should start playing with this behaviour now. Cheers, Christian PS: I'll be on holiday for a week so I probably won't get a chance to reply in a hurry "Rosen, Brian" wrote: > > If the ONLY thing you can put in a descriptor is > a property=value construct, then I think you don't need, > and don't want to have to, repeat values. That would apply > to local and remote too. > > All of our examples, to date, do not assume that you have > to repeat old values. > > I don't think there is any concept of "deleting" properties. > What kind of properties were you thinking of? > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > Sent: Wednesday, July 12, 2000 5:01 AM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Parameters in Local Control > > > > > > G'Day Brian, > > > > Why would we have a distinction in behaviour between Local Control, > > Local and Remote? They will all have property=value > > constructs and have > > properties defined by packages. We also have a concept to "delete" > > properties which needs to be maintained for Local Control. > > > > I wasn't particularly keen on having to re-send properties to > > keep them > > but that's what we decided to do so I feel that to be consistent in > > behaviour that we should keep things as is. > > > > Cheers, Christian > > > > "Rosen, Brian" wrote: > > > > > > In the text, section 7.1.7, it states: > > > A new setting of the LocalControl Descriptor completely replaces the > > > previous setting of that descriptor in the MG. Thus to retain > > > information from the previous setting the MGC must include that > > > information in the new setting. If the MGC wishes to delete some > > > information from the existing descriptor, it merely resends the > > > descriptor (in a Modify command) with the unwanted information > > > stripped out. > > > > > > Suppose you implemented a couple packages that defined a dozen or > > > so properties. Do you have to repeat the values of each of these > > > properties in every modify of LocalControl? > > > > > > I think this paragraph is a remnant of an earlier concept, and with > > > LocalControl defined as it is now, this statement is in error, and > > > the actual desired behavior is that values are kept until modified. > > > Consider that LocalControl presently has only the Mode property, > > > the ReserveGroup and ReserveValue properties and properties of > > > a termination. > > > This means there is nothing in LocalControl that is not a property > > > with a value (as opposed to, say a flag). Thus keeping old values > > > is very feasible, and I believe, what is desired. > > > > > > Brian > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 09:10:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20008 for ; Fri, 14 Jul 2000 09:10:38 -0400 (EDT) Received: from standards (47.234.32.16:1519) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E425@standards.nortelnetworks.com>; Fri, 14 Jul 2000 8:59:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7097 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 08:59:50 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E40D@standards.nortelnetworks.com>; Fri, 14 Jul 2000 8:49:50 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA18492; Fri, 14 Jul 2000 06:00:06 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480B48@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <396F0FB6.A646F24@cisco.com> Date: Fri, 14 Jul 2000 09:03:50 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Proposed New Megaco Work Item: draft-brown-supplpkgs-00.txt X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom It would probably be better to rephrase this into describing the problem you want the package to address and make that a work item. There's obviously different ways of supporting CAS, and I see what's in here as just one proposal that we shouldn't necessarily get locked in on. I have the same comments on making the R1 package a work item, and additionally a question about what the overlap between the R1 package and the brown-supplementary package is. -- Flemming Tom-PT Taylor wrote: > Please state any objections to making draft-brown-supplpkgs-00.txt a Megaco > work item. If I do not see any by Thursday I shall make it so. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 09:23:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23329 for ; Fri, 14 Jul 2000 09:23:07 -0400 (EDT) Received: from standards (47.234.32.16:1519) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E476@standards.nortelnetworks.com>; Fri, 14 Jul 2000 9:12:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7233 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 09:12:16 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E475@standards.nortelnetworks.com>; Fri, 14 Jul 2000 9:12:16 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03757; Fri, 14 Jul 2000 09:22:29 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00226; Fri, 14 Jul 2000 09:22:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3XL1FWTC>; Fri, 14 Jul 2000 09:22:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678553@whq-msgusr-02.fore.com> Date: Fri, 14 Jul 2000 09:22:30 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Parameters in Local Control X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM G'Day Christian I do understand how we originally decided on the behavior of repeating values, but I believe that the way the protocol has evolved, the assumptions made are no longer valid, and we have changed the way we use LocalControl and TerminationState. The way we created all the current packages, and the way we construct examples, we are not using the "repeat all values" paradigm. We are using the "change it when you need to change it" paradigm. I'm not sure what package you refer to in your first example. Modems have their own descriptor, which we are not (yet) discussing in this thread, and I'm not aware of a package that handles modems yet. The second example, Echo Control, could refer to the TDM package Annex E, section 13. There is no description of having the first setting of 'ec' put echo cancellation on line, or lack of it putting echo cancel off line, and I would say that if that is your interpretation, you need to verify your assumptions with others, and we need to change the document to reflect it. Being really carefull here, in general, there is no way to MODIFY local and remote except by replacement -- that is, if you send a modified SDP it does replace the prior value completely, and I would expect that Annex B equivalents would behave the same way. Generally speaking, because both ends of the flow have to change, this is appropriate. Termination State, however, should behave like LocalControl. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Friday, July 14, 2000 8:54 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Parameters in Local Control > > > G'Day Brian, > > I'm a little confused by this. In Megaco we settled on the following > behaviour: > "A new setting of a Local or Remote Descriptor completely replaces the > previous setting of that descriptor in the MG. Thus to retain > information from the previous setting the MGC must include that > information in the new setting. If the MGC wishes to delete some > information from the existing descriptor, it merely resends the > descriptor (in a Modify command) with the unwanted > information stripped > out." > > I believe that properties=values are applicable for local and > remote. So > to date we do assume that you have to repeat old values. The issue is > that we need to be able to remove a property after we have set it to a > value otherwise in every single property we need a value to turn the > property off. > > For example: > You have a stream with media flowing. > If you audited_value then no modem would appear. > You then put a modem property on a line. > If you audited_value then a modem property would appear., > You then turn the modem property off because you want to remove it > (remove the associated physical resource from the stream). > Do an audit and it still appears. I thought that you wouldn't want to > see anything as you removed the modem. > > Another example: > You have a stream with media flowing but with no reference to an echo > canceller. > You add the echo canceller property and turn it ON. > You turn the echo canceller OFF but you still want it inlinked in the > call but not operating, turning the property to off would allow this > behaviour. > You then want to outlink the echo canceller. Removing the > property would > allow this. > > So I believe you need to be able to: > o Assign a property a value. > o Turn this property off. > o Remove this property. > I don't think we should start playing with this behaviour now. > > Cheers, Christian > > PS: I'll be on holiday for a week so I probably won't get a chance to > reply in a hurry > "Rosen, Brian" wrote: > > > > If the ONLY thing you can put in a descriptor is > > a property=value construct, then I think you don't need, > > and don't want to have to, repeat values. That would apply > > to local and remote too. > > > > All of our examples, to date, do not assume that you have > > to repeat old values. > > > > I don't think there is any concept of "deleting" properties. > > What kind of properties were you thinking of? > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > Sent: Wednesday, July 12, 2000 5:01 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Parameters in Local Control > > > > > > > > > G'Day Brian, > > > > > > Why would we have a distinction in behaviour between > Local Control, > > > Local and Remote? They will all have property=value > > > constructs and have > > > properties defined by packages. We also have a concept to "delete" > > > properties which needs to be maintained for Local Control. > > > > > > I wasn't particularly keen on having to re-send properties to > > > keep them > > > but that's what we decided to do so I feel that to be > consistent in > > > behaviour that we should keep things as is. > > > > > > Cheers, Christian > > > > > > "Rosen, Brian" wrote: > > > > > > > > In the text, section 7.1.7, it states: > > > > A new setting of the LocalControl Descriptor completely > replaces the > > > > previous setting of that descriptor in the MG. Thus > to retain > > > > information from the previous setting the MGC must > include that > > > > information in the new setting. If the MGC wishes > to delete some > > > > information from the existing descriptor, it merely > resends the > > > > descriptor (in a Modify command) with the unwanted > information > > > > stripped out. > > > > > > > > Suppose you implemented a couple packages that defined > a dozen or > > > > so properties. Do you have to repeat the values of > each of these > > > > properties in every modify of LocalControl? > > > > > > > > I think this paragraph is a remnant of an earlier > concept, and with > > > > LocalControl defined as it is now, this statement is in > error, and > > > > the actual desired behavior is that values are kept > until modified. > > > > Consider that LocalControl presently has only the Mode property, > > > > the ReserveGroup and ReserveValue properties and properties of > > > > a termination. > > > > This means there is nothing in LocalControl that is not > a property > > > > with a value (as opposed to, say a flag). Thus keeping > old values > > > > is very feasible, and I believe, what is desired. > > > > > > > > Brian > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 10:01:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03842 for ; Fri, 14 Jul 2000 10:01:17 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E49C@standards.nortelnetworks.com>; Fri, 14 Jul 2000 9:50:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7284 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 09:50:17 -0400 Received: from qhars002.nortel.com (47.101.112.102:38012) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E49B@standards.nortelnetworks.com>; Fri, 14 Jul 2000 9:50:17 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 14 Jul 2000 14:59:46 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 09:58:40 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jul 2000 09:58:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFED9B.9B89572A" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C385B@zcard00q.ca.nortel.com> Date: Fri, 14 Jul 2000 09:58:22 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: User Interface MGCP package X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFED9B.9B89572A Content-Type: text/plain; charset="iso-8859-1" Flemming , list: The 02 version of the Megaco IP Phone spec includes a *for discussion* description off the subset approach. However, top of section 6.4 is an Editor's Note that states this as being for discussion only, and why we see this as a good thing and allowed for in the Requirements. Decisions on specific rules for Profile definition in Megaco/H.248 in general was deferred pending completion of version 1 of the spec and gaining some real life experience, as also stated in the Editor's Note. During the Adelaide meeting I presented Megaco IP Phone status, including agreement to remove this subset approach from the next iteration of the IP Phone draft. We have not yet posted this, however we all agreed this aspect is gone. From the Adelaide presentation ("Megaco IP Phone Application Profile - Status Update", 30.3.00): " * Protocol subset profile - Proposal: remove subset aspect in this version, consider subsetting "later", when specific rules for profile definition are described " This was agreed at the meeting. Hope that helps. -- Peter Blatherwick -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Thursday, July 13, 2000 17:34 To: Blatherwick, Peter [CAR:AT14:EXCH] Cc: megaco@standards.nortelnetworks.com Subject: Re: User Interface MGCP package There was quite a lot of list discussion in April as well as in the Adelaide meeting about the appropriateness of having a profile supporting only a subset of the mandatory requirements defined by the Megaco protocol. I thought we all agreed, that profiles are not allowed to do that, at least not if they want official Megaco blessing. Now, the ipphone-02 package violates that, so I don't see how it can be a working group item. Can somebody please clarify this ? Thanks Flemming Peter Blatherwick wrote: Flemming, all:Correct. As I understood it, Megaco IP Phone MG was agreed to go forward as Informational RFC once final details are complete, not Standards Track, since it is an application of Megaco/H.248 and derives from work outside of IETF. My wording was unclear on this. Meant to say "based on open standards" -- not to imply it is itself an open standard in IETF. (I note however that considerable re-work and 2 draft iterations has happened as a result of Megaco list discussion. Work is carried out on behalf of TIA TR-41.3.4 working group on VoIP Telephones, as an option for phone control, other options being SIP or H.323.) As far as WG status, this has been accepted as a WG work item since 00 version first posted June last year. Was draft-blatherwick- before that. Sorry for any confusion there. -- Peter Blatherwick -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Wednesday, July 12, 2000 17:09 To: Blatherwick, Peter [CAR:AT14:EXCH] Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: User Interface MGCP package Please, let's not get into these types of counter-productive discussions again. We are all entitled to our individual opinions and strategies in this space, but this mailing list is neither the place to promote them nor argue about them. As far as the ip-phone package is concerned, I recall very clearly that we agreed *not to* make this Standards Track in Adelaide, so I don't know where you get the "standards" label from ? Maybe we should rename it to "draft-blatherwick-..." to make that clear ? -- Flemming Peter Blatherwick wrote: I feel I must be somewhat blunt here. This work replicates many aspects of the H.248 Annex G: User Interface Elements and Actions Packages, currently in Standards Track Last Call under IETF Megaco WG and in White Document form for ITU SG-16 Decision, well agreed in both standards bodies. Yet, the MGCP-based proposal is not in direction of an open standard and is much less developed in terms of user interface widget coverage and level of detail. Why would anyone undertake to replicate work that is already near completion in open standards? Why would IETF Megaco WG in particular (or ITU SG-16 for that matter) want to know about work going on to perpetuate a non-standardized proposal (MGCP) which is now divergent from the real international open standards direction (Megaco/H.248)? Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248g-00.txt. For master/slave style IP Phone control under open standards see Megaco IP Phone Media Gateway Application Profile at http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt. -- Peter Blatherwick -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM] Sent: Monday, July 10, 2000 15:24 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: User Interface MGCP package Hi all, We have just released an Internet Draft which defines a new MGCP package for supporting the User Interface aspects of IP feature phones. We look forward to your comments for improving and validating this package. This document is accessible at http://www.ietf.org/internet-drafts/draft-petithuguenin-mgcp-ui-pkg-00.txt or alternatively at http://www.netergynet.com/protocols/draft-petithuguenin-mgcp-ui-pkg-00.txt Andy Huckridge Marc Petit-Huguenin -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 ------_=_NextPart_001_01BFED9B.9B89572A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: User Interface MGCP package

Flemming , list:

The 02 version of the Megaco IP Phone spec includes a = *for discussion* description off the subset approach.  However, = top of section 6.4 is an Editor's Note that states this as being for = discussion only, and why we see this as a good thing and allowed for in = the Requirements.  Decisions on specific rules for Profile = definition in Megaco/H.248 in general was deferred pending completion = of version 1 of the spec and gaining some real life experience, as also = stated in the Editor's Note. 

During the Adelaide meeting I presented Megaco IP = Phone status, including agreement to remove this subset approach from = the next iteration of the IP Phone draft.  We have not yet posted = this, however we all agreed this aspect is gone. 

From the Adelaide presentation ("Megaco IP Phone = Application Profile - Status Update", 30.3.00):   =
"
  * Protocol subset profile
     - Proposal: remove subset = aspect in this version, consider subsetting "later",
       when specific = rules for profile definition are described
"
This was agreed at the meeting. 

Hope that helps. 

-- Peter Blatherwick

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]=
Sent: Thursday, July 13, 2000 17:34
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: megaco@standards.nortelnetworks.com
Subject: Re: User Interface MGCP package


There was quite a lot of list discussion in April as = well as in the Adelaide meeting about the appropriateness of having a = profile supporting only a subset of the mandatory requirements defined = by the Megaco protocol. I thought we all agreed, that profiles are not = allowed to do that, at least not if they want official Megaco blessing. = Now, the ipphone-02 package violates that, so I don't see how it can be = a working group item. Can somebody please clarify this ?

 
Thanks
        Flemming =
 
Peter Blatherwick wrote:
 Flemming, all:Correct.  As I understood = it, Megaco IP Phone MG was agreed to go forward as Informational RFC = once final details are complete, not Standards Track, since it is an = application of Megaco/H.248 and derives from work outside of = IETF.  My wording was unclear on this.  Meant to say = "based on open standards" -- not to imply it is itself an = open standard in IETF.  (I note however that considerable re-work = and 2 draft iterations has happened as a result of Megaco list = discussion.  Work is carried out on behalf of TIA TR-41.3.4 = working group on VoIP Telephones, as an option for phone control, other = options being SIP or H.323.) As far as WG status, this has been = accepted as a WG work item since 00 version first posted June last = year.  Was draft-blatherwick- before that. Sorry for any confusion = there. -- Peter Blatherwick

-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com] =
Sent: Wednesday, July 12, 2000 17:09
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: User Interface MGCP package
 
Please, let's not get into these types of = counter-productive discussions again. We are all entitled to our = individual opinions and strategies in this space, but this mailing list = is neither the place to promote them nor argue about them.

 
As far as the ip-phone package is concerned, I = recall very clearly that we agreed *not to* make this Standards Track = in Adelaide, so I don't know where you get the "standards" = label from ? Maybe we should rename it to = "draft-blatherwick-..." to make that clear  ? =

 
-- Flemming
 
 
Peter Blatherwick wrote:
 
I feel I must be somewhat blunt here.
This work replicates many aspects of the H.248 Annex = G: User Interface Elements and Actions Packages, currently in Standards = Track Last Call under IETF Megaco WG and in White Document form for ITU = SG-16 Decision, well agreed in both standards bodies.  Yet, the = MGCP-based proposal is not in direction of an open standard and is much = less developed in terms of user interface widget coverage and level of = detail.

Why would anyone undertake to replicate work that is = already near completion in open standards?
Why would IETF Megaco WG in particular (or ITU SG-16 = for that matter) want to know about work going on to perpetuate a = non-standardized proposal (MGCP) which is now divergent from the real = international open standards direction (Megaco/H.248)?

Instead, for user interface packages please see http://www.ietf.org/internet-drafts/draft-ietf-megaco-= h248g-00.txt.  For master/slave style IP Phone control under = open standards see Megaco IP Phone Media Gateway Application Profile at = http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-02.txt.

-- Peter Blatherwick
-----Original Message-----
From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM]
Sent: Monday, July 10, 2000 15:24
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: User Interface MGCP package
Hi all,
We have just released an Internet Draft which = defines a new MGCP package
for supporting the User Interface aspects of IP = feature phones.
We look forward to your comments for improving and = validating this
package.
This document is accessible at
http://www.ietf.org/internet-drafts/draft-petithugueni= n-mgcp-ui-pkg-00.txt
or alternatively at
http://www.netergynet.com/protocols/draft-petithugueni= n-mgcp-ui-pkg-00.txt
Andy Huckridge
Marc Petit-Huguenin
--
Flemming = Andreasen          &nb= sp;     Phone: +1 732 452 1667
Cisco = Systems           = ;          = Fax:   +1 240 359 5839
 
--
Flemming = Andreasen          &nb= sp;     Phone: +1 732 452 1667
Cisco = Systems           = ;          = Fax:   +1 240 359 5839
 

------_=_NextPart_001_01BFED9B.9B89572A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 10:49:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17247 for ; Fri, 14 Jul 2000 10:49:09 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E530@standards.nortelnetworks.com>; Fri, 14 Jul 2000 10:38:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7477 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 10:38:08 -0400 Received: from qhars002.nortel.com (47.101.112.102:43130) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E52F@standards.nortelnetworks.com>; Fri, 14 Jul 2000 10:38:07 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 14 Jul 2000 15:43:36 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 14 Jul 2000 09:39:23 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id <37KR2V3S>; Fri, 14 Jul 2000 09:42:03 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B69@zcard00g.ca.nortel.com> Date: Fri, 14 Jul 2000 09:42:10 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Last Call: IPPhone Profile To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is the third time this week I've sent this. I'm starting to wonder if the list is hinting a lack of consensus before I even get the word out. I hereby invoke WG Last Call on draft-ietf-megaco-ipphone-02.txt with a view to making it an Informational RFC, in accordance with discussion in Adelaide. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 11:57:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11768 for ; Fri, 14 Jul 2000 11:57:22 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E5A8@standards.nortelnetworks.com>; Fri, 14 Jul 2000 11:46:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7630 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 11:46:25 -0400 Received: from qhars002.nortel.com (47.101.112.102:51512) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E5A7@standards.nortelnetworks.com>; Fri, 14 Jul 2000 11:46:25 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 14 Jul 2000 16:54:26 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 11:51:51 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jul 2000 11:51:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDAB.6C335B1E" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C385D@zcard00q.ca.nortel.com> Date: Fri, 14 Jul 2000 11:51:36 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Last Call: IPPhone Profile X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFEDAB.6C335B1E Content-Type: text/plain; charset="iso-8859-1" Tom: I have not seen any previous messages on last call on this (although for sure I'm anxious to finish the process). There is some confusion. The current Megaco IP Phone draft (02) is *NOT* what we (the authors) would consider the last call version. Needs to be updated for removal of subsetting profile (issue earlier yesterday and today), and tidy up of other minor issues. We will try to get this updated version (03) out next week. I realize this means we will have slipped the posting deadline for the upcoming meeting. I would hope that last call can be set against 03 version post-meeting. Does this work process-wise? We would of course be more than happy to hear any comments on 02 version in the mean time. -- Peter Blatherwick -----Original Message----- From: Taylor, Tom-PT [NORSE:B901:EXCH] Sent: Friday, July 14, 2000 10:42 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Last Call: IPPhone Profile This is the third time this week I've sent this. I'm starting to wonder if the list is hinting a lack of consensus before I even get the word out. I hereby invoke WG Last Call on draft-ietf-megaco-ipphone-02.txt with a view to making it an Informational RFC, in accordance with discussion in Adelaide. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com ------_=_NextPart_001_01BFEDAB.6C335B1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last Call: IPPhone Profile

Tom:

I have not seen any previous messages on last call on = this (although for sure I'm anxious to finish the process).  There = is some confusion. 

The current Megaco IP Phone draft (02) is *NOT* what = we (the authors) would consider the last call version.  Needs to = be updated for removal of subsetting profile (issue earlier yesterday = and today), and tidy up of other minor issues.  We will try to get = this updated version (03) out next week.  I realize this means we = will have slipped the posting deadline for the upcoming meeting.  =

I would hope that last call can be set against 03 = version post-meeting.  Does this work process-wise? 

We would of course be more than happy to hear any = comments on 02 version in the mean time. 

-- Peter Blatherwick

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Friday, July 14, 2000 10:42
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Last Call: IPPhone Profile


This is the third time this week I've sent = this.  I'm starting to wonder if
the list is hinting a lack of consensus before I = even get the word out.

 I hereby invoke WG Last Call on = draft-ietf-megaco-ipphone-02.txt with a
view to making it an Informational RFC, in = accordance with discussion in
Adelaide.

Tom Taylor
Lead Standards Developer
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com

------_=_NextPart_001_01BFEDAB.6C335B1E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 12:07:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14180 for ; Fri, 14 Jul 2000 12:07:04 -0400 (EDT) Received: from standards (47.234.32.16:3522) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E5BD@standards.nortelnetworks.com>; Fri, 14 Jul 2000 11:56:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7659 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 11:56:12 -0400 Received: from qhars002.nortel.com (47.101.112.102:52301) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E5BC@standards.nortelnetworks.com>; Fri, 14 Jul 2000 11:56:11 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 14 Jul 2000 17:06:13 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 11:59:17 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jul 2000 11:59:17 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B71@zcard00g.ca.nortel.com> Date: Fri, 14 Jul 2000 11:59:14 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Last Call: IPPhone Profile X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM OK, Last Call is rescinded pending recycling of the draft. I just thought it was time to get this moving. > -----Original Message----- > From: Blatherwick, Peter [CAR:AT14:EXCH] > Sent: Friday, July 14, 2000 11:52 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH]; > MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: Last Call: IPPhone Profile > > Tom: > > I have not seen any previous messages on last call on this (although for > sure I'm anxious to finish the process). There is some confusion. > > The current Megaco IP Phone draft (02) is *NOT* what we (the authors) > would consider the last call version. Needs to be updated for removal of > subsetting profile (issue earlier yesterday and today), and tidy up of > other minor issues. We will try to get this updated version (03) out next > week. I realize this means we will have slipped the posting deadline for > the upcoming meeting. > > I would hope that last call can be set against 03 version post-meeting. > Does this work process-wise? > > We would of course be more than happy to hear any comments on 02 version > in the mean time. > > -- Peter Blatherwick > > -----Original Message----- > From: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Friday, July 14, 2000 10:42 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Last Call: IPPhone Profile > > > This is the third time this week I've sent this. I'm starting to wonder > if > the list is hinting a lack of consensus before I even get the word out. > > I hereby invoke WG Last Call on draft-ietf-megaco-ipphone-02.txt with a > view to making it an Informational RFC, in accordance with discussion in > Adelaide. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:20:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19029 for ; Fri, 14 Jul 2000 15:20:10 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E72C@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:09:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8170 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:09:20 -0400 Received: from qhars002.nortel.com (47.101.112.102:63023) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E72B@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:09:19 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 14 Jul 2000 20:18:51 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 15:17:35 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jul 2000 15:17:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDC8.2A3069E2" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C3860@zcard00q.ca.nortel.com> Date: Fri, 14 Jul 2000 15:17:17 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: User Interface MGCP package X-To: Bob Wise , Scott Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFEDC8.2A3069E2 Content-Type: text/plain; charset="iso-8859-1" Bob wrote (12/07/00 17:07): >The "Informational RFC" is maintained by the ISC on behalf of the IETF. >The vendors involved in implementing MGCP and conducting interoperability >events treat this RFC as a standard. and later in same thread (12/07/00 18:28): >The representation of MGCP as a standard is systematic. ... One thing I'd like to get back to here. Is the MGCP I-RFC actually maintained by ISC "on behalf of" IETF. Is there a formal relationship on this? I was not aware of one. As I understand it IETF / IESG direction is clearly that Megaco/H.248 is the standard, and MGCP was a *proposal* for that standard not fully accepted by either Megaco WG or ITU-T SG-16 (although of course many, many important aspects remain). -- Peter Blatherwick ------_=_NextPart_001_01BFEDC8.2A3069E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: User Interface MGCP package

Bob wrote (12/07/00 17:07):
  >The "Informational RFC" is = maintained by the ISC on behalf of the IETF.
  >The vendors involved in implementing MGCP = and conducting interoperability
  >events treat this RFC as a = standard.
and later in same thread (12/07/00 18:28):
  >The representation of MGCP as a standard = is systematic.
  ...

One thing I'd like to get back to here.  Is the = MGCP I-RFC actually maintained by ISC "on behalf of" = IETF.  Is there a formal relationship on this?  I was not = aware of one. 

As I understand it IETF / IESG direction is clearly = that Megaco/H.248 is the standard, and MGCP was a *proposal* for that = standard not fully accepted by either Megaco WG or ITU-T SG-16 = (although of course many, many important aspects remain).  =

-- Peter Blatherwick

------_=_NextPart_001_01BFEDC8.2A3069E2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 15:29:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21654 for ; Fri, 14 Jul 2000 15:29:21 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E777@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:18:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8271 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:18:28 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E776@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:18:27 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03797; Fri, 14 Jul 2000 15:28:44 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03324; Fri, 14 Jul 2000 15:28:47 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3VHKWJGV>; Fri, 14 Jul 2000 15:28:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDC9.B156BF88" Message-ID: <4FBEA8857476D311A03300204840E1CF67855D@whq-msgusr-02.fore.com> Date: Fri, 14 Jul 2000 15:28:44 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: User Interface MGCP package X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFEDC9.B156BF88 Content-Type: text/plain; charset="iso-8859-1" There is no formal relationship. The ISC role is self proclaimed, but it's working. There is no obligation on the IETF to do anything further with MGCP. The ISC hopes that the IETF will be gracious enough to publish any updates to RFC2705 as informational RFCs, but understands that the IETF is under no obligation whatsoever to do so. Brian -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Friday, July 14, 2000 3:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: User Interface MGCP package Bob wrote (12/07/00 17:07): >The "Informational RFC" is maintained by the ISC on behalf of the IETF. >The vendors involved in implementing MGCP and conducting interoperability >events treat this RFC as a standard. and later in same thread (12/07/00 18:28): >The representation of MGCP as a standard is systematic. ... One thing I'd like to get back to here. Is the MGCP I-RFC actually maintained by ISC "on behalf of" IETF. Is there a formal relationship on this? I was not aware of one. As I understand it IETF / IESG direction is clearly that Megaco/H.248 is the standard, and MGCP was a *proposal* for that standard not fully accepted by either Megaco WG or ITU-T SG-16 (although of course many, many important aspects remain). -- Peter Blatherwick ------_=_NextPart_001_01BFEDC9.B156BF88 Content-Type: text/html; charset="iso-8859-1" RE: User Interface MGCP package
There is no formal relationship.  The ISC role is self proclaimed, but it's working.
There is no obligation on the IETF to do anything further with MGCP.  The ISC hopes that
the IETF will be gracious enough to publish any updates to RFC2705 as informational RFCs,
but understands that the IETF is under no obligation whatsoever to do so.
 
Brian
-----Original Message-----
From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM]
Sent: Friday, July 14, 2000 3:17 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: User Interface MGCP package

Bob wrote (12/07/00 17:07):
  >The "Informational RFC" is maintained by the ISC on behalf of the IETF.
  >The vendors involved in implementing MGCP and conducting interoperability
  >events treat this RFC as a standard.
and later in same thread (12/07/00 18:28):
  >The representation of MGCP as a standard is systematic.
  ...

One thing I'd like to get back to here.  Is the MGCP I-RFC actually maintained by ISC "on behalf of" IETF.  Is there a formal relationship on this?  I was not aware of one. 

As I understand it IETF / IESG direction is clearly that Megaco/H.248 is the standard, and MGCP was a *proposal* for that standard not fully accepted by either Megaco WG or ITU-T SG-16 (although of course many, many important aspects remain). 

-- Peter Blatherwick

------_=_NextPart_001_01BFEDC9.B156BF88-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 16:10:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03143 for ; Fri, 14 Jul 2000 16:10:22 -0400 (EDT) Received: from standards (47.234.32.16:2748) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E87A@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:59:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8618 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 15:59:29 -0400 Received: from qhars002.nortel.com (47.101.112.102:64541) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7E879@standards.nortelnetworks.com>; Fri, 14 Jul 2000 15:59:28 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 14 Jul 2000 21:08:15 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Fri, 14 Jul 2000 16:07:10 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jul 2000 16:07:11 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <28560036253BD41191A10000F8BCBD11480B79@zcard00g.ca.nortel.com> Date: Fri, 14 Jul 2000 16:07:09 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed New Megaco Work Item: draft-brown-supplpkgs-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think you're right -- I've had similar comments from others. We can discuss this in Pittsburgh before we give it final shape. > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@cisco.com] > Sent: Friday, July 14, 2000 9:04 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed New Megaco Work Item: > draft-brown-supplpkgs-00.txt > > Tom > > It would probably be better to rephrase this into describing the problem > you > want the package to address and make that a work item. There's obviously > different ways of supporting CAS, and I see what's in here as just one > proposal > that we shouldn't necessarily get locked in on. > > I have the same comments on making the R1 package a work item, and > additionally > a question about what the overlap between the R1 package and the > brown-supplementary package is. > > -- Flemming > > > Tom-PT Taylor wrote: > > > Please state any objections to making draft-brown-supplpkgs-00.txt a > Megaco > > work item. If I do not see any by Thursday I shall make it so. > > > > Tom Taylor > > Lead Standards Developer > > Phone and FAX: +1 613 736 0961 > > E-mail: taylor@nortelnetworks.com > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 > > Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 22:08:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15080 for ; Fri, 14 Jul 2000 22:08:56 -0400 (EDT) Received: from standards (47.234.32.16:3583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EAAE@standards.nortelnetworks.com>; Fri, 14 Jul 2000 21:57:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9331 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 21:57:57 -0400 Received: from mail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EAAD@standards.nortelnetworks.com>; Fri, 14 Jul 2000 21:57:56 -0400 Received: from bobpc (2Cust73.tnt18.tpa2.da.uu.net [63.20.143.201]) by mail.vsys.com (8.9.3+3.2W/8.9.3) with SMTP id UAA00453; Fri, 14 Jul 2000 20:07:49 -0600 (MDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01BFEDCF.603B3790" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: Date: Fri, 14 Jul 2000 20:09:11 -0600 Reply-To: Bob Wise Sender: "Media Gateway Control (megaco)" From: Bob Wise Subject: Re: User Interface MGCP package X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <8E2783FA4E0CD411888D0000F8CD15D33C3860@zcard00q.ca.nortel.com> This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BFEDCF.603B3790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: User Interface MGCP package The ISC/IETF relationship may not be a formal one, but if you are attempting to implement MGCP in any "standard" way (quotes used on purpose - please - no more emails!) you do have two options - ISC Device Control Working Group, and CableLabs. I mention this to emphasize that 0) MGCP is alive and well 1) There are other fora for MGCP discussions 2) This isn't the right place 3) Clearly there is some interest about MGCP on this list, and it needs somewhere to go -Bob ----------- Bob Wise Chief Architect Vsys, Inc. - "The Softswitch Company" www.vsys.com -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Peter Blatherwick Sent: Friday, July 14, 2000 1:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: User Interface MGCP package Bob wrote (12/07/00 17:07): >The "Informational RFC" is maintained by the ISC on behalf of the IETF. >The vendors involved in implementing MGCP and conducting interoperability >events treat this RFC as a standard. and later in same thread (12/07/00 18:28): >The representation of MGCP as a standard is systematic. ... One thing I'd like to get back to here. Is the MGCP I-RFC actually maintained by ISC "on behalf of" IETF. Is there a formal relationship on this? I was not aware of one. As I understand it IETF / IESG direction is clearly that Megaco/H.248 is the standard, and MGCP was a *proposal* for that standard not fully accepted by either Megaco WG or ITU-T SG-16 (although of course many, many important aspects remain). -- Peter Blatherwick ------=_NextPart_000_0003_01BFEDCF.603B3790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: User Interface MGCP package
 
The=20 ISC/IETF relationship may not be a formal one, but if you are=20 attempting
to=20 implement MGCP in any "standard" way (quotes used on purpose - please -=20 no
more=20 emails!) you do have two options - ISC Device Control Working=20 Group,
and=20 CableLabs.
 
I=20 mention this to emphasize that
0)=20 MGCP is alive and well
1)=20 There are other fora for MGCP discussions
2)=20 This isn't the right place
3)=20 Clearly there is some interest about MGCP on this list, and it needs = somewhere=20 to go
 
-Bob
 

-----------
Bob Wise
Chief Architect
Vsys, = Inc. - "The=20 Softswitch Company"
www.vsys.com

-----Original Message-----
From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of = Peter=20 Blatherwick
Sent: Friday, July 14, 2000 1:17 = PM
To:=20 MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: User = Interface MGCP=20 package

Bob wrote (12/07/00 17:07):
 =20 >The "Informational RFC" is maintained by the ISC on behalf of the=20 IETF.
  >The vendors involved in = implementing=20 MGCP and conducting interoperability
  = >events=20 treat this RFC as a standard.
and later in = same thread=20 (12/07/00 18:28):
  >The = representation of=20 MGCP as a standard is systematic.
  = ...=20

One thing I'd like to get back to here.  Is the = MGCP=20 I-RFC actually maintained by ISC "on behalf of" IETF.  Is there a = formal=20 relationship on this?  I was not aware of one. 

As I understand it IETF / IESG direction is clearly = that=20 Megaco/H.248 is the standard, and MGCP was a *proposal* for that = standard not=20 fully accepted by either Megaco WG or ITU-T SG-16 (although of course = many,=20 many important aspects remain). 

-- Peter Blatherwick =

------=_NextPart_000_0003_01BFEDCF.603B3790-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 14 22:46:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15082 for ; Fri, 14 Jul 2000 22:08:56 -0400 (EDT) Received: from standards (47.234.32.16:3583) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EAB4@standards.nortelnetworks.com>; Fri, 14 Jul 2000 21:58:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9337 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jul 2000 21:58:00 -0400 Received: from mail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7EAB3@standards.nortelnetworks.com>; Fri, 14 Jul 2000 21:57:59 -0400 Received: from bobpc (2Cust73.tnt18.tpa2.da.uu.net [63.20.143.201]) by mail.vsys.com (8.9.3+3.2W/8.9.3) with SMTP id UAA00458 for ; Fri, 14 Jul 2000 20:08:08 -0600 (MDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BFEDCF.6B8F9B90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: Date: Fri, 14 Jul 2000 20:09:30 -0600 Reply-To: Bob Wise Sender: "Media Gateway Control (megaco)" From: Bob Wise Subject: Interop Event To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <8E2783FA4E0CD411888D0000F8CD15D33C3860@zcard00q.ca.nortel.com> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BFEDCF.6B8F9B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: User Interface MGCP package I don't know what the T&Cs are around the interop event, but I'm wondering if anyone at the interop event is going to testing ASN.1 -Bob ----------- Bob Wise Chief Architect Vsys, Inc. - "The Softswitch Company" www.vsys.com ------=_NextPart_000_0007_01BFEDCF.6B8F9B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: User Interface MGCP package
 
I=20 don't know what the T&Cs are around the interop event, but I'm=20 wondering
if=20 anyone at the interop event is going to testing = ASN.1
 
-Bob
 

-----------
Bob Wise
Chief Architect
Vsys, = Inc. - "The=20 Softswitch Company"
www.vsys.com

------=_NextPart_000_0007_01BFEDCF.6B8F9B90-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 18 05:05:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14095 for ; Tue, 18 Jul 2000 05:05:41 -0400 (EDT) Received: from standards (47.234.32.16:4055) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F631@standards.nortelnetworks.com>; Tue, 18 Jul 2000 4:52:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13362 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jul 2000 04:52:56 -0400 Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7F62D@standards.nortelnetworks.com>; Tue, 18 Jul 2000 4:52:55 -0400 Received: from oleane (dyn-1-1-161.Vin.dialup.oleane.fr [195.25.4.161]) by smtp1.cluster.oleane.net with SMTP id LAA02776; Tue, 18 Jul 2000 11:02:23 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01BFF0A7.E194E720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <013401bff097$20cd0be0$0401a8c0@oleane.com> Date: Tue, 18 Jul 2000 11:04:02 +0200 Reply-To: mg263-8 Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: mg263-8 Subject: Implementing H.323 To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0131_01BFF0A7.E194E720 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Implementing H.323": the VoIP deployment scenario International conference, Paris, 10-13 October http://www.upperside.fr/bah323.htm =20 ------=_NextPart_000_0131_01BFF0A7.E194E720 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
"Implementing H.323": the VoIP = deployment scenario
International conference, Paris, 10-13 = October
http://www.upperside.fr/bah32= 3.htm
 
 
------=_NextPart_000_0131_01BFF0A7.E194E720-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 06:45:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26468 for ; Wed, 19 Jul 2000 06:45:52 -0400 (EDT) Received: from standards (47.234.32.16:4024) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FA78@standards.nortelnetworks.com>; Wed, 19 Jul 2000 6:34:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14836 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 06:34:34 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FA76@standards.nortelnetworks.com>; Wed, 19 Jul 2000 6:24:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21257; Wed, 19 Jul 2000 06:35:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007191035.GAA21257@ietf.org> Date: Wed, 19 Jul 2000 06:35:07 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-h248f-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --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 : H.248 Annex F (Pre-Decision White Document) Author(s) : G. Hellstrom Filename : draft-ietf-megaco-h248f-00.txt Pages : 51 Date : 18-Jul-00 This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex F, which is scheduled for decision in Geneva in November 2000. H.248 Annex F provides packages for faxsimile, text conversation, and call discrimination. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-h248f-00.txt 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-h248f-00.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-h248f-00.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: <20000718135826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-h248f-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-h248f-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718135826.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 20:29:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21117 for ; Wed, 19 Jul 2000 20:29:30 -0400 (EDT) Received: from standards (47.234.32.16:3706) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FD69@standards.nortelnetworks.com>; Wed, 19 Jul 2000 20:18:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15848 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 20:18:27 -0400 Received: from MAIL.IMANDISUPPPORT.COM (216.34.93.238:5573) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FD66@standards.nortelnetworks.com>; Wed, 19 Jul 2000 20:08:26 -0400 Received: from IIS2.IMANDI.COM by MAIL.IMANDISUPPPORT.COM via smtpd (for h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) with SMTP; 20 Jul 2000 00:19:02 UT Received: from mail pickup service by iis2.imandi.com with Microsoft SMTPSVC; Wed, 19 Jul 2000 17:18:58 -0700 Message-ID: 33c35f0c00040100 Date: Wed, 19 Jul 2000 17:18:58 -0700 Reply-To: munishbansal@yahoo.com Sender: "Media Gateway Control (megaco)" From: Munish Bansal Subject: I saw this site and thought of you! To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message has been sent to you by Munish Bansal. If you don't know this person, please contact us at rewards@imandi.com. ---------------------------------------------------------------------- Hello! imandi.com is now paying people up to $25,000 to refer friends and family. So guess what? I'm referring you! To find out more, go to http://www.imandi.com/go/run.dll?Rewards&ref=munishb. At imandi.com, finding something as difficult as the right contractor, the perfect maid or a rare collectible is as easy as typing in what you want. They have hundreds of services and products for your home, your life, your business. Just log on, type in what you want... and BOOM -- they connect you with the right people to meet your exact needs and get them competing for your business. To introduce people to their new site, imandi.com is giving away up to $10 million to get people to refer their friends. Click on the link below to find out more: http://www.imandi.com/go/run.dll?Rewards&ref=munishb. (This link will identify me as the person who referred you. When you sign up, you'll get your own link to send to your friends.) At imandi.com you say goodbye to playing phone tag, squinting at classifieds and confusing yellow page ads and wondering if you paid too much. I think it's exciting to pass on new and exciting things to friends (and make money while doing it!). Hope you'll check it out! Regards, Munish Bansal ---------------------------------------------------------------------- imandi.com's Anti-spam Policy strictly forbids sending unsolicited email. If this email is not from someone you know, please contact us at rewards@imandi.com. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 19 23:34:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26719 for ; Wed, 19 Jul 2000 23:34:41 -0400 (EDT) Received: from standards (47.234.32.16:2872) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FE99@standards.nortelnetworks.com>; Wed, 19 Jul 2000 23:23:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16262 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jul 2000 23:23:43 -0400 Received: from qhars002.nortel.com (47.101.112.102:42531) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7FE98@standards.nortelnetworks.com>; Wed, 19 Jul 2000 23:23:43 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 20 Jul 2000 04:34:18 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Wed, 19 Jul 2000 23:33:54 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 19 Jul 2000 23:33:54 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480B8F@zcard00g.ca.nortel.com> Date: Wed, 19 Jul 2000 23:33:52 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: WG Last Call: draft-ietf-megaco-h248f-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM This note is to announce WG Last Call on H.248 Annex F, which deals with packages for FAX and text conversation. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 08:35:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08351 for ; Thu, 20 Jul 2000 08:35:53 -0400 (EDT) Received: from standards (47.234.32.16:2502) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8008D@standards.nortelnetworks.com>; Thu, 20 Jul 2000 8:23:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16863 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 08:23:17 -0400 Received: from mars.hss.co.in (202.54.26.197:64606) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80083@standards.nortelnetworks.com>; Thu, 20 Jul 2000 8:23:12 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6KCZAv28662 for ; Thu, 20 Jul 2000 07:35:12 -0500 (GMT) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256922.00442E96 ; Thu, 20 Jul 2000 17:54:43 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256922.00442E29.01@sandesh.hss.hns.com> Date: Thu, 20 Jul 2000 17:54:41 +0530 Reply-To: smahajan@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sunil Mahajan Subject: Conformance Test Specifications for M2UA X-To: SIGTRAN-TEST@STANDARDS.NORTELNETWORKS.COM, SIGTRAN@STANDARDS.NORTELNETWORKS.COM X-cc: sjindal@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi All, We have submitted an internet draft on test specification for M2UA (v03) protocol and the same will be available on IETF draft site in a day or two. The draft submitted presents an exhaustive list/description of tests which can be used as conformance test by any implementation or the flows can be used as implementor's guide. Comments on the draft are welcome. Regards, Sunil Mahajan HSS VoIP Group p.s. if anybody need a text copy of the draft before it appears on the IETF site we can mail it to you From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 12:36:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14906 for ; Thu, 20 Jul 2000 12:36:16 -0400 (EDT) Received: from standards (47.234.32.16:4618) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8017A@standards.nortelnetworks.com>; Thu, 20 Jul 2000 12:25:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17156 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 12:25:00 -0400 Received: from qhars002.nortel.com (47.101.112.102:32832) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80179@standards.nortelnetworks.com>; Thu, 20 Jul 2000 12:25:00 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Thu, 20 Jul 2000 17:32:08 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Thu, 20 Jul 2000 12:31:26 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 20 Jul 2000 12:31:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF257.F5214CA0" Message-ID: Date: Thu, 20 Jul 2000 10:36:57 -0400 Reply-To: Sophia Scoggins Sender: "Media Gateway Control (megaco)" From: Sophia Scoggins Subject: SDP inconsistency in Megaco X-To: atmsdp@eng.fore.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFF257.F5214CA0 Content-Type: text/plain; charset="iso-8859-1" In RFC 2327 the 's', 'o', and 't' are required. In Megaco, these three descriptors are optional from MGC --> MG. The questions are: -- Why Megaco wants this exception? (I personally does not want these descriptors. They offer no value to VTOA. But not compliant to another RFC just adds on difficulty in interworking with other protocols. I would rather the original RFC 2327 authors change them, then we create inconsistency. Of course, this generates backward compatibility issue. But looking forward, it is better this RFC gets updated or all the applications agree/aware of the inconsistency.) -- Should these descriptors in the direction of MG --> MGC be compliant to RFC 2327 or consistant to the way they are in the direction of MGC-->MG? -- For MGC --> MGC, they are based on other protocols, and are likely to be compliant to RFC 2327. Should the MGC add on those descriptors and remove them before passing them down to the MG? -- If BICC decides to compliant to Megaco (as it is today), then for BICC and SIP interworking, should the IWF add on these descriptors? Other questions are for ajesh: -- what is a MG going to do with the vci/vpi/vpci of the remote MG? Do they offer any value? If not, they should not be in the SDP discription. Regards, Sophia ------_=_NextPart_001_01BFF257.F5214CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SDP inconsistency in Megaco

In RFC 2327 the 's', 'o', and 't' are = required. In Megaco, these three descriptors are optional from MGC = --> MG. The questions are:

-- Why Megaco wants this exception? (I = personally does not want these descriptors. They offer no value to = VTOA. But not compliant to another RFC just adds on difficulty in = interworking with other protocols. I would rather the original RFC 2327 = authors change them, then we create inconsistency. Of course, this = generates backward compatibility issue. But looking forward, it is = better this RFC gets updated or all the applications agree/aware of the = inconsistency.)

-- Should these descriptors in the = direction of MG --> MGC be compliant to RFC 2327 or consistant to = the way they are in the direction of MGC-->MG?

-- For MGC --> MGC, they are based = on other protocols, and are likely to be compliant to RFC 2327. Should = the MGC add on those descriptors and remove them before passing them = down to the MG?

-- If BICC decides to compliant to = Megaco (as it is today), then for BICC and SIP interworking, should the = IWF add on these descriptors?

Other questions are for ajesh:

-- what is a MG going to do with the = vci/vpi/vpci of the remote MG? Do they offer any value? If not, they = should not be in the SDP discription.


Regards, Sophia



------_=_NextPart_001_01BFF257.F5214CA0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 15:38:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18582 for ; Thu, 20 Jul 2000 15:38:00 -0400 (EDT) Received: from standards (47.234.32.16:2840) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB801FA@standards.nortelnetworks.com>; Thu, 20 Jul 2000 15:26:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17313 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 15:26:56 -0400 Received: from mailcity.com (fes-qin.whowhere.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB801F7@standards.nortelnetworks.com>; Thu, 20 Jul 2000 15:16:55 -0400 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Jul 20 12:27:08 2000 Mime-Version: 1.0 X-Sent-Mail: off X-Expiredinmiddle: true X-Mailer: MailCity Service X-Sender-Ip: 216.6.88.34 Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 20 Jul 2000 12:27:08 -0700 Reply-To: hussainmf@lycos.com Sender: "Media Gateway Control (megaco)" From: Hussain F Mohammad Organization: Lycos Communications (http://comm.lycos.com:80) Subject: Signal descriptor returned in response. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit It seems that nearly most of the time it may happen that MGC while auditing signal descriptor receive empty signal descriptor...unless auditing the same as soon as the command with signal descriptor is sent to MG. -MFH >>This kind of problem is age-old, and is almost always >>settled by returning "current" state, whatever it is, >>regardless of what asynchrony exists. >>Sending back what was received is close to useless. >>So, I think the MG should return what is currently >>being "played" and what remains to be played (in the case >>of a signal list). >>Brian > -----Original Message----- > From: Hemant Kumar [mailto:hkumar@globespan.net] > Sent: Friday, June 30, 2000 6:08 AM > To: Rosen, Brian; MEGACO@standards.nortelnetworks.com > Subject: Signal descriptor returned in response. > > > Hi Everyone, > I think that in response to audit of signal > descriptor, the signals > and signal lists in the previous descriptor should be > returned. As Brian had > pointed out in his earlier mail (on June 16) the MG might not > be in sync > with the MGC. There is always the possiblity of completion of > signal (or/and > signal lists) play by the time the message containing the > "active" signal > (or/and signal lists)reaches the MGC (especially for brief signals). > Therefore sending active signals (or/and signal lists)only in > the audit > response would be of little value (The MGC can never be sure > of whether the > signals(or/and signal lists) that have been received are > actually playing or > not) > > Regards, > Hemant Kumar > > ----- Original Message ----- > From: Rosen, Brian > To: > Sent: Friday, June 30, 2000 3:27 AM > Subject: Re: signal descriptor returned in response. > > > > I thought I had sent an answer to this, > > > > I believe you get "live" information, which would be > > the signals playing at the time, not was last sent. > > If there were no signals, you get an empty descriptor. > > > > For a signal list, I think it's not specified whether > > you get only those active, or yet to be played items, > > or whether you get the original list. I'd like to see > > what is current and yet to go, but that may be hard to > > implement. > > > > Brian > Get your FREE Email and Voicemail at Lycos Communications - http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 16:02:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01111 for ; Thu, 20 Jul 2000 16:02:56 -0400 (EDT) Received: from standards (47.234.32.16:4351) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8021D@standards.nortelnetworks.com>; Thu, 20 Jul 2000 15:51:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17360 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 15:51:49 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8021C@standards.nortelnetworks.com>; Thu, 20 Jul 2000 15:51:49 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22091; Thu, 20 Jul 2000 16:02:20 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27018; Thu, 20 Jul 2000 16:02:24 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 16:02:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6785A5@whq-msgusr-02.fore.com> Date: Thu, 20 Jul 2000 16:02:21 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Signal descriptor returned in response. X-To: "hussainmf@lycos.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Possibly, but so what? Actually, signals last a while in computer time, so it may be that if you audit "frequently" you will see, for example, ringing signals. Of course, it's not clear to me why you would audit frequently. Brian > -----Original Message----- > From: Hussain F Mohammad [mailto:hussainmf@lycos.com] > Sent: Thursday, July 20, 2000 3:27 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Signal descriptor returned in response. > > > It seems that nearly most of the time it may happen that MGC > while auditing > signal descriptor receive empty signal descriptor...unless > auditing the same as > soon as the command with signal descriptor is sent to MG. > > -MFH > > >>This kind of problem is age-old, and is almost always > >>settled by returning "current" state, whatever it is, > >>regardless of what asynchrony exists. > > >>Sending back what was received is close to useless. > > >>So, I think the MG should return what is currently > >>being "played" and what remains to be played (in the case > >>of a signal list). > > >>Brian > > > -----Original Message----- > > From: Hemant Kumar [mailto:hkumar@globespan.net] > > Sent: Friday, June 30, 2000 6:08 AM > > To: Rosen, Brian; MEGACO@standards.nortelnetworks.com > > Subject: Signal descriptor returned in response. > > > > > > Hi Everyone, > > I think that in response to audit of signal > > descriptor, the signals > > and signal lists in the previous descriptor should be > > returned. As Brian had > > pointed out in his earlier mail (on June 16) the MG might not > > be in sync > > with the MGC. There is always the possiblity of completion of > > signal (or/and > > signal lists) play by the time the message containing the > > "active" signal > > (or/and signal lists)reaches the MGC (especially for brief signals). > > Therefore sending active signals (or/and signal lists)only in > > the audit > > response would be of little value (The MGC can never be sure > > of whether the > > signals(or/and signal lists) that have been received are > > actually playing or > > not) > > > > Regards, > > Hemant Kumar > > > > ----- Original Message ----- > > From: Rosen, Brian > > To: > > Sent: Friday, June 30, 2000 3:27 AM > > Subject: Re: signal descriptor returned in response. > > > > > > > I thought I had sent an answer to this, > > > > > > I believe you get "live" information, which would be > > > the signals playing at the time, not was last sent. > > > If there were no signals, you get an empty descriptor. > > > > > > For a signal list, I think it's not specified whether > > > you get only those active, or yet to be played items, > > > or whether you get the original list. I'd like to see > > > what is current and yet to go, but that may be hard to > > > implement. > > > > > > Brian > > > > > Get your FREE Email and Voicemail at Lycos Communications - http://comm.lycos.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 20:52:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09815 for ; Thu, 20 Jul 2000 20:52:05 -0400 (EDT) Received: from standards (47.234.32.16:2101) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8028E@standards.nortelnetworks.com>; Thu, 20 Jul 2000 20:40:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17502 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 20:40:59 -0400 Received: from zero.bora.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80289@standards.nortelnetworks.com>; Thu, 20 Jul 2000 20:30:58 -0400 Received: from LocalHost ([211.170.54.4]) by zero.bora.net (8.9.3/8.9.3) with SMTP id JAA09218 for ; Fri, 21 Jul 2000 09:41:29 +0900 (KST) MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Message-ID: <000201bff2ac$a1b8c200$0436aad3@xener.com> Date: Fri, 21 Jul 2000 09:43:03 +0900 Reply-To: =?ks_c_5601-1987?B?sejA58f1?= Sender: "Media Gateway Control (megaco)" From: =?ks_c_5601-1987?B?sejA58f1?= Subject: R2 Package supporting for MGCP To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA09815 Hi, all. The IETF Megaco WG in particular (or ITU SG-16 for that matter) released some packages such as R2 and R1. Curruntly, I work with MGCP. So, I have a question whether the proposed R2 packages from IETF Megaco WG can work on the MGCP. Thanks in advance. ========================================== Kim, Jae-Hyuk XENER.COM.,Inc Tel: +82-2-525-1493 (ext. 202) jayhkim@xener.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 21:11:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16005 for ; Thu, 20 Jul 2000 21:10:59 -0400 (EDT) Received: from standards (47.234.32.16:3523) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB802A7@standards.nortelnetworks.com>; Thu, 20 Jul 2000 20:59:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17540 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 20:59:56 -0400 Received: from turin.trillium.com (38.187.146.197:2679) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB802A6@standards.nortelnetworks.com>; Thu, 20 Jul 2000 20:59:56 -0400 Received: from aiglos.trillium.com (smtp.trillium.com) by turin.trillium.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 20 Jul 2000 18:25:10 -0700 Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id SAA19735; Thu, 20 Jul 2000 18:10:31 -0700 (PDT) Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 18:05:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5DAFF3D2@aega.trillium.com> Date: Thu, 20 Jul 2000 18:05:47 -0700 Reply-To: Naren Tulpule Sender: "Media Gateway Control (megaco)" From: Naren Tulpule Subject: AuditItem X-cc: "Brian.Rosen@marconi.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, In the Megaco ABNF, auditReturnParameter is a choice between descriptors (for media, modem etc) and "auditItem". AuditItem is a choice between descriptor tokens (MediaToken, ModemToken etc). 1. When is auditItem needed in auditReturnParameter? (To advertise "yes, I have some mux?") 2. To distinguish auditItem more easily from the descriptors, can we change the ABNF to prefix it with AuditToken? (In fact in ASN.1 it is an (empty) auditDescriptor, can we replace auditItem with auditDescriptor in auditReturnParameter?) -- Naren. Narendra C. Tulpule SMTS, Trillium Digital Systems Inc 12100 Wilshire Bl #1800 LA CA 90025 Ph: +1-310-442-9222 Fax: +1-310-442-1162 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 20 21:48:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00954 for ; Thu, 20 Jul 2000 21:48:32 -0400 (EDT) Received: from standards (47.234.32.16:1143) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB802DF@standards.nortelnetworks.com>; Thu, 20 Jul 2000 21:37:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17613 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jul 2000 21:37:27 -0400 Received: from qhars002.nortel.com (47.101.112.102:50705) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB802DC@standards.nortelnetworks.com>; Thu, 20 Jul 2000 21:37:27 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Fri, 21 Jul 2000 02:43:10 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Thu, 20 Jul 2000 21:40:32 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 20 Jul 2000 21:40:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF2B4.A793F570" Message-ID: <28560036253BD41191A10000F8BCBD11480B93@zcard00g.ca.nortel.com> Date: Thu, 20 Jul 2000 21:40:30 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: AuditItem X-To: Naren Tulpule To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFF2B4.A793F570 Content-Type: text/plain The ability to return AuditItem was one of the changes added in draft-ietf-megaco-errata-0x.txt, to allow the MG to indicate that a particular descriptor is empty. See the reference to corrections to section 7.1 of the protocol document. We can't do anything about the ABNF naming convention at this point -- it's not a bug. As a matter of interest, our two protocol documents (-megaco-protocol-08 and -megaco-errata-03) are fifth and sixth on the RFC Editor's queue. It will be nip and tuck whether they get obsoleted by draft-ietf-megaco-merged-01.txt before they are ever assigned RFC numbers. > -----Original Message----- > From: Naren Tulpule [SMTP:naren@TRILLIUM.COM] > Sent: Thursday, July 20, 2000 9:06 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: AuditItem > > Hi, > In the Megaco ABNF, auditReturnParameter is a choice between descriptors > (for media, modem etc) and "auditItem". AuditItem is a choice between > descriptor tokens (MediaToken, ModemToken etc). > > 1. When is auditItem needed in auditReturnParameter? (To advertise "yes, I > have some mux?") > > 2. To distinguish auditItem more easily from the descriptors, can we > change > the ABNF to prefix it with AuditToken? > (In fact in ASN.1 it is an (empty) auditDescriptor, can we replace > auditItem > with auditDescriptor in auditReturnParameter?) > > -- Naren. > Narendra C. Tulpule > SMTS, Trillium Digital Systems Inc > 12100 Wilshire Bl #1800 LA CA 90025 > Ph: +1-310-442-9222 > Fax: +1-310-442-1162 ------_=_NextPart_001_01BFF2B4.A793F570 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: AuditItem

The ability to = return AuditItem was one of the changes added in = draft-ietf-megaco-errata-0x.txt, to allow the MG to indicate that a = particular descriptor is empty.  See the reference to corrections = to section 7.1 of the protocol document.

We can't do anything = about the ABNF naming convention at this point -- it's not a = bug.

As a matter of = interest, our two protocol documents (-megaco-protocol-08 and = -megaco-errata-03) are fifth and sixth on the RFC Editor's queue.  = It will be nip and tuck whether they get obsoleted by = draft-ietf-megaco-merged-01.txt before they are ever assigned RFC = numbers.

    -----Original Message-----
    From:   Naren Tulpule [SMTP:naren@TRILLIUM.COM]
    Sent:   Thursday, July 20, 2000 9:06 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = AuditItem

    Hi,
      In the Megaco ABNF, = auditReturnParameter is a choice between descriptors
    (for media, modem etc) and = "auditItem". AuditItem is a choice between
    descriptor tokens (MediaToken, = ModemToken etc).

    1. When is auditItem needed in = auditReturnParameter? (To advertise "yes, I
    have some mux?")

    2. To distinguish auditItem more = easily from the descriptors, can we change
    the ABNF to prefix it with = AuditToken?
    (In fact in ASN.1 it is an (empty) = auditDescriptor, can we replace auditItem
    with auditDescriptor in = auditReturnParameter?)

    -- Naren.
    Narendra C. Tulpule
    SMTS, Trillium Digital Systems = Inc
    12100 Wilshire Bl #1800 LA CA = 90025
    Ph:  +1-310-442-9222
    Fax: +1-310-442-1162

------_=_NextPart_001_01BFF2B4.A793F570-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 09:06:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07001 for ; Fri, 21 Jul 2000 09:06:15 -0400 (EDT) Received: from standards (47.234.32.16:1578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80469@standards.nortelnetworks.com>; Fri, 21 Jul 2000 8:44:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18112 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 08:44:59 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80468@standards.nortelnetworks.com>; Fri, 21 Jul 2000 8:44:58 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04298; Fri, 21 Jul 2000 08:55:36 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA09424; Fri, 21 Jul 2000 08:55:28 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3VHKXT1S>; Fri, 21 Jul 2000 08:55:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ks_c_5601-1987" Message-ID: <4FBEA8857476D311A03300204840E1CF6785AB@whq-msgusr-02.fore.com> Date: Fri, 21 Jul 2000 08:55:18 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: R2 Package supporting for MGCP X-To: ??? To: MEGACO@STANDARDS.NORTELNETWORKS.COM No, but there is effort elsewhere on MGCP (International Softswitch Consortium). There is some effort to keep the megaco and MGCP packages aligned. Brian > -----Original Message----- > From: jayhkim@XENER.COM [mailto:jayhkim@XENER.COM] > Sent: Thursday, July 20, 2000 8:43 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: R2 Package supporting for MGCP > > > Hi, all. > > The IETF Megaco WG in particular (or ITU SG-16 for that > matter) released some packages such as R2 and R1. > > Curruntly, I work with MGCP. So, I have a question whether > the proposed R2 packages from IETF Megaco WG can work on the MGCP. > > Thanks in advance. > > ========================================== > Kim, Jae-Hyuk > XENER.COM.,Inc > Tel: +82-2-525-1493 (ext. 202) > jayhkim@xener.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 21 09:49:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13391 for ; Fri, 21 Jul 2000 09:49:17 -0400 (EDT) Received: from standards (47.234.32.16:1578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8050F@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:38:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18314 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jul 2000 09:38:22 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80505@standards.nortelnetworks.com>; Fri, 21 Jul 2000 9:28:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12580; Fri, 21 Jul 2000 09:39:01 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200007211339.JAA12580@ietf.org> Date: Fri, 21 Jul 2000 09:39:01 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-megaco-test-profile-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interoperability Test Profile Author(s) : B. Rosen Filename : draft-rosen-megaco-test-profile-00.txt Pages : 6 Date : 20-Jul-00 This document describes a profile for use in interoperability testing of the Megaco/H.248 protocol and a set of scenarios to try increasingly difficult mechanisms in the protocol. To support early phase testing, it is useful to define a simple, easy to implement set of characteristics that allow initial implementations to get very basic functions working. By implementing this profile, testing a variety of MGs against a variety of MGCs is possible. The test scenarios describe high-level behavior expected by the MGs and MGCs, but not explicit message sequences. Also included is a set of test messages that may be used to verify early stage MG/MGC functionality. They could be used to test parsers, and they can be used to assure that implementations have base functionality prior to testing with devices that may not produce the same messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-megaco-test-profile-00.txt 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-rosen-megaco-test-profile-00.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-rosen-megaco-test-profile-00.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: <20000720141633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-megaco-test-profile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-megaco-test-profile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141633.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 05:14:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20324 for ; Mon, 24 Jul 2000 05:14:10 -0400 (EDT) Received: from standards (47.234.32.16:3312) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80CE5@standards.nortelnetworks.com>; Mon, 24 Jul 2000 5:02:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21001 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 05:02:45 -0400 Received: from ws9.cdotb.ernet.in (202.41.72.121:1246) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80CE4@standards.nortelnetworks.com>; Mon, 24 Jul 2000 4:52:38 -0400 Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id OAA05204 for ; Mon, 24 Jul 2000 14:28:32 +0500 (GMT+0500) Received: from cdotb.ernet.i by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/13Apr00-1149AM) id OAA0000004706; Mon, 24 Jul 2000 14:26:29 +0500 (GMT+0500) X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397BA40C.DFB2FB4B@cdotb.ernet.i> Date: Mon, 24 Jul 2000 07:33:56 +0530 Reply-To: Priya A Sender: "Media Gateway Control (megaco)" From: Priya A Subject: PICS for Megaco To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Is there any standard Protocol Implementation Conformance Statement (PICS), available for Megaco Protocol ? If not are there any plans for making one? Regards, Priya A From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 09:25:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23965 for ; Mon, 24 Jul 2000 09:25:24 -0400 (EDT) Received: from standards (47.234.32.16:4666) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80D5D@standards.nortelnetworks.com>; Mon, 24 Jul 2000 9:13:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21155 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 09:13:51 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80D5C@standards.nortelnetworks.com>; Mon, 24 Jul 2000 9:13:50 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13924; Mon, 24 Jul 2000 09:24:38 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20105; Mon, 24 Jul 2000 09:24:38 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Jul 2000 09:24:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6785D9@whq-msgusr-02.fore.com> Date: Mon, 24 Jul 2000 09:24:31 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: PICS for Megaco X-To: Priya A To: MEGACO@STANDARDS.NORTELNETWORKS.COM No, and, at least at IETF, I can confidently predict, no. Brian > -----Original Message----- > From: Priya A [mailto:priya@CDOTB.ERNET.I.CDOTB.ERNET.IN] > Sent: Sunday, July 23, 2000 10:04 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: PICS for Megaco > > > Hi, > > Is there any standard Protocol Implementation Conformance > Statement (PICS), > available for Megaco Protocol ? If not are there any plans for making > one? > > Regards, > Priya A > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 09:51:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28912 for ; Mon, 24 Jul 2000 09:51:43 -0400 (EDT) Received: from standards (47.234.32.16:2061) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80D8A@standards.nortelnetworks.com>; Mon, 24 Jul 2000 9:40:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21216 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 09:40:19 -0400 Received: from mars.hss.co.in (202.54.26.197:45122) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80D89@standards.nortelnetworks.com>; Mon, 24 Jul 2000 9:40:17 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e6ODqNq28773 for ; Mon, 24 Jul 2000 19:22:26 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256926.004B3C86 ; Mon, 24 Jul 2000 19:11:46 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256926.004B3A98.00@sandesh.hss.hns.com> Date: Mon, 24 Jul 2000 19:11:41 +0530 Reply-To: smahajan@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sunil Mahajan Subject: Re: PICS for Megaco To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Priya, There is one available at ETSI TIPHON site as draft submission for H.248. http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg6/DTS06017/V0.1.0/DTS06017V0.1.0.doc cheers, sunil mahajan "Rosen, Brian" on 07/24/2000 06:54:31 PM Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sunil Mahajan/HSS) Subject: Re: PICS for Megaco No, and, at least at IETF, I can confidently predict, no. Brian > -----Original Message----- > From: Priya A [mailto:priya@CDOTB.ERNET.I.CDOTB.ERNET.IN] > Sent: Sunday, July 23, 2000 10:04 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: PICS for Megaco > > > Hi, > > Is there any standard Protocol Implementation Conformance > Statement (PICS), > available for Megaco Protocol ? If not are there any plans for making > one? > > Regards, > Priya A > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 12:14:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08424 for ; Mon, 24 Jul 2000 12:14:08 -0400 (EDT) Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80E76@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:02:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21455 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 12:02:27 -0400 Received: from hotmail.com (f194.law7.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80E42@standards.nortelnetworks.com>; Mon, 24 Jul 2000 11:52:26 -0400 Received: (qmail 1049 invoked by uid 0); 24 Jul 2000 16:03:16 -0000 Received: from 63.95.216.30 by www.hotmail.com with HTTP; Mon, 24 Jul 2000 09:03:16 PDT X-Originating-IP: [63.95.216.30] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000724160316.1048.qmail@hotmail.com> Date: Mon, 24 Jul 2000 09:03:16 PDT Reply-To: Kelly Houston Sender: "Media Gateway Control (megaco)" From: Kelly Houston Subject: State Machines for MGCP and MEGACO To: MEGACO@STANDARDS.NORTELNETWORKS.COM Does anyone know of a standardized state machine for MGCP and MEGACO implementations? This would help promote greater interoperability. Regards. Kelly Houston ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 12:42:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18126 for ; Mon, 24 Jul 2000 12:42:11 -0400 (EDT) Received: from standards (47.234.32.16:4046) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80F05@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:30:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21632 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 12:30:35 -0400 Received: from cflc.net (merlin.cflc.lib.fl.us) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80ECE@standards.nortelnetworks.com>; Mon, 24 Jul 2000 12:20:34 -0400 Received: from localhost (jwagner@localhost) by cflc.net (8.9.3/8.9.3) with ESMTP id MAA11017 for ; Mon, 24 Jul 2000 12:28:37 -0400 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 24 Jul 2000 12:28:37 -0400 Reply-To: Jennilee Wagner Sender: "Media Gateway Control (megaco)" From: Jennilee Wagner Subject: megaco stack availability To: MEGACO@STANDARDS.NORTELNETWORKS.COM Are there any commercially available megaco stacks yet? If so, has anyone done feature and performance evaluations? Thanks in advance. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 17:28:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12752 for ; Mon, 24 Jul 2000 17:28:41 -0400 (EDT) Received: from standards (47.234.32.16:4292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80FDB@standards.nortelnetworks.com>; Mon, 24 Jul 2000 17:17:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21991 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 17:17:24 -0400 Received: from qhars002.nortel.com (47.101.112.102:44037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB80FD9@standards.nortelnetworks.com>; Mon, 24 Jul 2000 17:17:23 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 24 Jul 2000 22:24:34 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 24 Jul 2000 17:00:05 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 24 Jul 2000 16:34:43 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BA8@zcard00g.ca.nortel.com> Date: Mon, 24 Jul 2000 16:34:38 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Megaco Agenda in Pittsburgh X-To: "agenda@ietf.org" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Here is the outline of a tentative agenda for Pittsburgh. If people have specific issues to bring up, let me know. 1. Agenda bashing 5 min. 2. Status report -- work in 15 min progress 3. Status report -- interop 5 min. 4. CAS package issues 20 min 5. Base protocol issues 50 min 6. SDPng requirements 10 min 6. IETF/ITU operating 10 min agreement I'll pick out some key topics for item 5 in the next few days. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 24 23:51:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17778 for ; Mon, 24 Jul 2000 23:51:55 -0400 (EDT) Received: from standards (47.234.32.16:4746) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81160@standards.nortelnetworks.com>; Mon, 24 Jul 2000 23:40:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22483 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 23:40:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8114D@standards.nortelnetworks.com>; Mon, 24 Jul 2000 23:30:09 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6P3evQ26967; Tue, 25 Jul 2000 05:40:57 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id FAA14388; Tue, 25 Jul 2000 05:40:56 +0200 (MET DST) Received: from ericsson.com (mcdh112.epa.ericsson.se [146.11.81.112]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA23695; Tue, 25 Jul 2000 05:40:53 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397CF830.17223F50@ericsson.com> Date: Tue, 25 Jul 2000 12:15:12 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Interop Event X-To: Bob Wise To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Bob, We'll have an ASN.1 and ABNF version at the interop. Cheers, Christian Bob Wise wrote: > > > I don't know what the T&Cs are around the interop event, but I'm > wondering > if anyone at the interop event is going to testing ASN.1 > > -Bob > > > ----------- > Bob Wise > Chief Architect > Vsys, Inc. - "The Softswitch Company" > www.vsys.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 00:19:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17780 for ; Mon, 24 Jul 2000 23:51:55 -0400 (EDT) Received: from standards (47.234.32.16:4746) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81167@standards.nortelnetworks.com>; Mon, 24 Jul 2000 23:40:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22484 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jul 2000 23:40:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8114E@standards.nortelnetworks.com>; Mon, 24 Jul 2000 23:30:11 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6P3f2Q26983 for ; Tue, 25 Jul 2000 05:41:02 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id FAA14392 for ; Tue, 25 Jul 2000 05:41:02 +0200 (MET DST) Received: from ericsson.com (mcdh112.epa.ericsson.se [146.11.81.112]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA23699 for ; Tue, 25 Jul 2000 05:40:59 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480BA8@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397CF8F7.E581F566@ericsson.com> Date: Tue, 25 Jul 2000 12:18:31 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Megaco Agenda in Pittsburgh To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, Do you have a list of what drafts will be presented? Cheers, Christian Tom-PT Taylor wrote: > > Here is the outline of a tentative agenda for Pittsburgh. If people have > specific issues to bring up, let me know. > > 1. Agenda bashing 5 min. > 2. Status report -- work in 15 min > progress > 3. Status report -- interop 5 min. > 4. CAS package issues 20 min > 5. Base protocol issues 50 min > 6. SDPng requirements 10 min > 6. IETF/ITU operating 10 min > agreement > > I'll pick out some key topics for item 5 in the next few days. > > Tom Taylor > Lead Standards Developer > Phone and FAX: +1 613 736 0961 > E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 10:39:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08793 for ; Tue, 25 Jul 2000 10:39:38 -0400 (EDT) Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB813F3@standards.nortelnetworks.com>; Tue, 25 Jul 2000 10:28:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23376 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 10:28:05 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB813F2@standards.nortelnetworks.com>; Tue, 25 Jul 2000 10:28:04 -0400 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA18885; Tue, 25 Jul 2000 07:31:01 -0700 (PDT) Received: from bfoster-nt (bfoster-dsl3.cisco.com [10.19.86.12]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AED23324; Tue, 25 Jul 2000 07:30:44 -0700 (PDT) X-Sender: bfoster@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.2.0.58.20000725072718.00ce63a0@mira-sjc5-1.cisco.com> Date: Tue, 25 Jul 2000 07:28:28 -0700 Reply-To: Bill Foster Sender: "Media Gateway Control (megaco)" From: Bill Foster Subject: Re: R2 Package supporting for MGCP X-To: "Rosen, Brian" X-cc: jayhkim@XENER.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF6785AB@whq-msgusr-02.fore. com> I think the hope is to have an R1 Megaco package that aligns with the packages in http://www.softswitch.org/Working_Groups/device_control/draft-mgcp-cas-packages.pdf (and covers all North American CAS as well) and come up with an MGCP R2 package that aligns with the proposed Megaco R2 package. You can contact myself for the MGCP side of things. At 08:55 AM 7/21/00 -0400, Rosen, Brian wrote: >No, but there is effort elsewhere on MGCP (International Softswitch >Consortium). There is >some effort to keep the megaco and MGCP packages aligned. > >Brian > > > -----Original Message----- > > From: jayhkim@XENER.COM [mailto:jayhkim@XENER.COM] > > Sent: Thursday, July 20, 2000 8:43 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: R2 Package supporting for MGCP > > > > > > Hi, all. > > > > The IETF Megaco WG in particular (or ITU SG-16 for that > > matter) released some packages such as R2 and R1. > > > > Curruntly, I work with MGCP. So, I have a question whether > > the proposed R2 packages from IETF Megaco WG can work on the MGCP. > > > > Thanks in advance. > > > > ========================================== > > Kim, Jae-Hyuk > > XENER.COM.,Inc > > Tel: +82-2-525-1493 (ext. 202) > > jayhkim@xener.com > > ----------------------------- Bill Foster Phone: (408) 527-8791 Page: (800) 365-4578 Fax: (781) 998-6492 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 14:20:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20988 for ; Tue, 25 Jul 2000 14:20:27 -0400 (EDT) Received: from standards (47.234.32.16:1569) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81555@standards.nortelnetworks.com>; Tue, 25 Jul 2000 14:09:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23830 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 14:08:59 -0400 Received: from rwcxch02.clarent.com (208.205.112.15:2030) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81541@standards.nortelnetworks.com>; Tue, 25 Jul 2000 13:58:59 -0400 Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 11:09:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <6374EFC78443D41197DD00508B5C35DD3F028E@rwcxch02.clarent.com> Date: Tue, 25 Jul 2000 11:09:46 -0700 Reply-To: Jean-Francois Mule Sender: "Media Gateway Control (megaco)" From: Jean-Francois Mule Subject: IPfax package comments re: WG Last Call: draft-ietf-megaco-h248f- 00.txt X-To: "sgunnar.hellstrom@omnitor.se" , "gparsons@nortelnetworks.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 1. Editorial comment on 10.4.1 Pages Transferred: How does this relate to fax pages retransmitted? are those included in this counter? if yes, a quick note in the text would be benefitial. 2. Comments about the IPFax package (section 11 of the I-D): - the i-d should clearly point to the reference where the session attributes for t38 are defined (use the term "session attribute" or at least "attribute" which is not used once in the text; at least point to IANA); - an informative section with the possible value attributes allowed for t38 fax in the descriptors would be appreciated ((a=:; = value1 | value2); the informative example in 11.5.4. is somewhat eluding to it; could you give the same info given to IANA to register those SDP names (name, type of name, possible values, explanation)? - if those definitions have been included in a t.38 annex (annex d for e.g.), it is critical for implementers to have access to those defs. Otherwise, the informative example is using attributes coming from nowhere > a=T38FaxRateManagement:transferredTCF > a=T38UdpEC:t38UDPFEC Jean-Francois -------------------------------------------------------------- Jean-Francois Mule' Clarent Corporation T: +1 650 481-2835 jfm@clarent.com > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Wednesday, July 19, 2000 8:34 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: WG Last Call: draft-ietf-megaco-h248f-00.txt > > > This note is to announce WG Last Call on H.248 Annex F, which > deals with > packages for FAX and text conversation. > > Tom Taylor > Lead Standards Developer From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 14:27:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22785 for ; Tue, 25 Jul 2000 14:27:25 -0400 (EDT) Received: from standards (47.234.32.16:1569) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8156F@standards.nortelnetworks.com>; Tue, 25 Jul 2000 14:16:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23886 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 14:16:02 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8156E@standards.nortelnetworks.com>; Tue, 25 Jul 2000 14:15:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03867 for ; Tue, 25 Jul 2000 14:26:48 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13288 for ; Tue, 25 Jul 2000 14:26:49 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 14:26:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6785ED@whq-msgusr-02.fore.com> Date: Tue, 25 Jul 2000 14:26:48 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Web page with Sign-Up form for the First Megaco Interop Event Ava ilable X-To: "megaco-interop@fore.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM A small website with a sign-up form for the first Megaco/H.248 Interop event is now available. Please see: http://megaco-interop.tripod.com (Sorry for the banner ads) If you have an implementation of Megaco/H.248 underway, I hope you will plan to join us in Durham, NH August 28-31. I'm currently expecting at least 15 MGs and MGCs from around 10 organizations, but I get inquiries every week from folks I haven't heard from. There will be plenty of rough code at the event, so don't worry if yours is not ready for prime time. The event is cosponsored by The Multiservice Switching Forum, The International Softswitch Consortium and the University of New Hampshire's Interoperability Lab. Marconi is the host. So, click, sign-up and come join us! Brian ------------ Brian Rosen, Office of the CTO Marconi, plc 1000 FORE Drive, Warrendale, PA 15086 (724) 742-6826 mailto:brian.rosen@marconi.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 17:03:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06440 for ; Tue, 25 Jul 2000 17:03:35 -0400 (EDT) Received: from standards (47.234.32.16:3343) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB816B6@standards.nortelnetworks.com>; Tue, 25 Jul 2000 16:52:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24330 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 16:52:16 -0400 Received: from qhars002.nortel.com (47.101.112.102:58580) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB816B3@standards.nortelnetworks.com>; Tue, 25 Jul 2000 16:42:16 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Tue, 25 Jul 2000 21:45:23 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Tue, 25 Jul 2000 14:31:05 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 25 Jul 2000 14:31:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF66E.DA82BDA0" Message-ID: <456E6DB7180ED3118A670000F8BDCA29021BB1AC@zcard00p.ca.nortel.com> Date: Tue, 25 Jul 2000 14:30:56 -0500 Reply-To: Glenn Parsons Sender: "Media Gateway Control (megaco)" From: Glenn Parsons Subject: Re: IPfax package comments re: WG Last Call: draft-ietf-megaco-h2 48f- 00.txt X-cc: Jean-Francois Mule , James Rafferty , Gunnar Hellstrom To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFF66E.DA82BDA0 Content-Type: text/plain > 1. Editorial comment on 10.4.1 Pages Transferred: > How does this relate to fax pages retransmitted? are those included in > this counter? if yes, a quick note in the text would be benefitial. > > 2. Comments about the IPFax package (section 11 of the I-D): > - the i-d should clearly point to the reference where the session > attributes for t38 are defined (use the term "session attribute" or at > least "attribute" which is not used once in the text; at least point to > IANA); > They are defined in T.38. Annex E is on H.248 and Annex D is on SIP/SDP. Perhaps the authors thought that was obvious (or that it would be included in the references section :-) > - an informative section with the possible value attributes allowed for > t38 fax in the descriptors would be appreciated > ((a=:; = value1 | value2); the > informative example in 11.5.4. is somewhat eluding to it; could you give > the same info given to IANA to register those SDP names (name, type of > name, possible values, explanation)? > Are you looking for the info included in the IANA liaison from ITU-T SG8 at: ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/February00/ > - if those definitions have been included in a t.38 annex (annex d for > e.g.), it is critical for implementers to have access to those defs. > Otherwise, the informative example is using attributes coming from > nowhere > > a=T38FaxRateManagement:transferredTCF > > a=T38UdpEC:t38UDPFEC > This is in the T.38 Rec. It is published as T.38 Amendment 2: http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html You can see the draft at the previous URL. Cheers, Glenn. ------_=_NextPart_001_01BFF66E.DA82BDA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IPfax package comments re: WG Last Call: = draft-ietf-megaco-h248f- 00.txt

    1. Editorial comment on 10.4.1 Pages = Transferred:
    How does this relate to fax pages = retransmitted?  are those included in
    this counter?  if yes, a quick = note in the text would be benefitial.

    2.  Comments about the IPFax = package (section 11 of the I-D):
    - the i-d should clearly point to = the reference where the session
    attributes for t38 are defined (use = the term "session attribute" or at
    least "attribute" which is = not used once in the text;  at least point to
    IANA);

They are defined in = T.38.  Annex E is on H.248 and Annex D is on SIP/SDP.  = Perhaps the authors thought that was obvious (or that it would be = included in the references section :-)

    - an informative section with the = possible value attributes allowed for
    t38 fax in the descriptors would be = appreciated
    ((a=3D<T38attribute>:<value>;  = <value>  =3D value1 | value2);  the
    informative example in 11.5.4. is = somewhat eluding to it; could you give
    the same info given to IANA to = register those SDP names (name, type of
    name, possible values, = explanation)?

Are you looking for the info = included in the IANA liaison from ITU-T SG8 at:
ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/Feb= ruary00/

    - if those definitions have been = included in a t.38 annex (annex d for
    e.g.), it is critical for = implementers to have access to those defs.
    Otherwise, the informative example = is using attributes coming from
    nowhere
    >     = a=3DT38FaxRateManagement:transferredTCF
    >     = a=3DT38UdpEC:t38UDPFEC

This is in the T.38 = Rec.  It is published as T.38 Amendment 2:
http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html= =20

You can see the draft at the = previous URL.

Cheers,
Glenn.

------_=_NextPart_001_01BFF66E.DA82BDA0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 18:26:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00724 for ; Tue, 25 Jul 2000 18:26:34 -0400 (EDT) Received: from standards (47.234.32.16:2738) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81723@standards.nortelnetworks.com>; Tue, 25 Jul 2000 18:15:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24471 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 18:15:17 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8171E@standards.nortelnetworks.com>; Tue, 25 Jul 2000 18:05:16 -0400 Received: from cisco.com (sj-dial-2-156.cisco.com [10.19.226.157]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA25379 for ; Tue, 25 Jul 2000 15:16:08 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397E1290.E1CCE6F9@cisco.com> Date: Tue, 25 Jul 2000 18:20:00 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Auditing of ephemerals To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Once upon a time, we had quite a lot of discussion about how to audit ephemerals at startup time. We even had a suggestion in the Base Root Package aimed specifically at solving this, however it was removed later on and I can't remember if we ever came up with an alternative, hence my question: How does an MGC figure out what ephemerals an MG supports ? -- Flemming -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 19:28:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21193 for ; Tue, 25 Jul 2000 19:28:45 -0400 (EDT) Received: from standards (47.234.32.16:4629) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8175D@standards.nortelnetworks.com>; Tue, 25 Jul 2000 19:17:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24552 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 19:17:25 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8175C@standards.nortelnetworks.com>; Tue, 25 Jul 2000 19:17:25 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA24395 for ; Tue, 25 Jul 2000 19:28:17 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA12345 for ; Tue, 25 Jul 2000 19:28:17 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 19:28:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6785F9@whq-msgusr-02.fore.com> Date: Tue, 25 Jul 2000 19:28:16 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Web page with Sign-Up form for the First Megaco Interop Event Ava ilable X-To: "megaco-interop@fore.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Thanks to Jon Steer of T!Semantics, I have moved the Megaco-Interop website to: http://www.tsemantics.com/megaco-interop It has no pesky banner ads, and should be faster. The tripod site will stay up in case someone does not get this message, but please use the above URL for your sign-ups. Thanks Brian -----Original Message----- From: Rosen, Brian To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 7/25/00 2:26 PM Subject: Web page with Sign-Up form for the First Megaco Interop Event Ava ilable A small website with a sign-up form for the first Megaco/H.248 Interop event is now available. Please see: http://megaco-interop.tripod.com (Sorry for the banner ads) If you have an implementation of Megaco/H.248 underway, I hope you will plan to join us in Durham, NH August 28-31. I'm currently expecting at least 15 MGs and MGCs from around 10 organizations, but I get inquiries every week from folks I haven't heard from. There will be plenty of rough code at the event, so don't worry if yours is not ready for prime time. The event is cosponsored by The Multiservice Switching Forum, The International Softswitch Consortium and the University of New Hampshire's Interoperability Lab. Marconi is the host. So, click, sign-up and come join us! Brian ------------ Brian Rosen, Office of the CTO Marconi, plc 1000 FORE Drive, Warrendale, PA 15086 (724) 742-6826 mailto:brian.rosen@marconi.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 20:14:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02010 for ; Tue, 25 Jul 2000 20:14:35 -0400 (EDT) Received: from standards (47.234.32.16:2610) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81780@standards.nortelnetworks.com>; Tue, 25 Jul 2000 20:03:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24598 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 20:03:16 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8177F@standards.nortelnetworks.com>; Tue, 25 Jul 2000 20:03:16 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA26398; Tue, 25 Jul 2000 20:14:07 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA16619; Tue, 25 Jul 2000 20:14:08 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 20:14:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6785FA@whq-msgusr-02.fore.com> Date: Tue, 25 Jul 2000 20:14:06 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Auditing of ephemerals X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM You audit packages. For example, if the MG implements RTP, then it implements the RTP package. Same with ATM. You audit packages of the whole gateway, of course. Brian -----Original Message----- From: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 7/25/00 6:20 PM Subject: Auditing of ephemerals Once upon a time, we had quite a lot of discussion about how to audit ephemerals at startup time. We even had a suggestion in the Base Root Package aimed specifically at solving this, however it was removed later on and I can't remember if we ever came up with an alternative, hence my question: How does an MGC figure out what ephemerals an MG supports ? -- Flemming -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jul 25 23:34:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26072 for ; Tue, 25 Jul 2000 23:34:42 -0400 (EDT) Received: from standards (47.234.32.16:3338) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81880@standards.nortelnetworks.com>; Tue, 25 Jul 2000 23:23:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24922 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jul 2000 23:23:26 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81876@standards.nortelnetworks.com>; Tue, 25 Jul 2000 23:13:25 -0400 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id UAA18588; Tue, 25 Jul 2000 20:24:18 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6785FA@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397E5ACA.E6DA7435@cisco.com> Date: Tue, 25 Jul 2000 23:28:10 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: Auditing of ephemerals X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > You audit packages. For example, if the MG implements RTP, then > it implements the RTP package. Same with ATM. You audit packages of > the whole gateway, of course. > That doesn't sound particularly foolproof - who's to say I want to implement *the* RTP package or *the* ATM package, etc. Nevertheless, it still leaves me with a couple of questions: 1. How do I figure out the naming scheme used for these ephemeral terminations, e.g. "rtp/{1,2,3,4}" ? 2. If I have more than one type of ephemeral termination supported, how do I figure out which one support what packages (without instantiating one of course). -- Flemming > > Brian > > -----Original Message----- > From: Flemming Andreasen > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Sent: 7/25/00 6:20 PM > Subject: Auditing of ephemerals > > Once upon a time, we had quite a lot of discussion about how to audit > ephemerals at startup time. We even had a suggestion in the Base Root > Package aimed specifically at solving this, however it was removed later > on and I can't remember if we ever came up with an alternative, hence my > question: > > How does an MGC figure out what ephemerals an MG supports ? > > -- Flemming > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 26 02:15:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28037 for ; Wed, 26 Jul 2000 02:15:38 -0400 (EDT) Received: from standards (47.234.32.16:4071) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8190C@standards.nortelnetworks.com>; Wed, 26 Jul 2000 2:04:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25104 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 02:04:14 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81907@standards.nortelnetworks.com>; Wed, 26 Jul 2000 1:54:13 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6Q655Q29236; Wed, 26 Jul 2000 08:05:05 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA16031; Wed, 26 Jul 2000 08:05:04 +0200 (MET DST) Received: from ericsson.com (mcdh112.epa.ericsson.se [146.11.81.112]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA25359; Wed, 26 Jul 2000 08:05:01 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6785FA@whq-msgusr-02.fore.com> <397E5ACA.E6DA7435@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397E7F8B.8D08F76D@ericsson.com> Date: Wed, 26 Jul 2000 16:04:59 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Auditing of ephemerals X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Flemming, By auditing rtp/* and asking for a wildcard response it will give you the packages and properties for that class of termination without the need for instantiating each of the euphemeral terminations. Naming schemes can be provisioned to a certain extent and then auditing can give you the characteristics of named terminations. Cheers, Christian Flemming Andreasen wrote: > > "Rosen, Brian" wrote: > > > You audit packages. For example, if the MG implements RTP, then > > it implements the RTP package. Same with ATM. You audit packages of > > the whole gateway, of course. > > > > That doesn't sound particularly foolproof - who's to say I want to implement > *the* RTP package or *the* ATM package, etc. Nevertheless, it still leaves > me with a couple of questions: > > 1. How do I figure out the naming scheme used for these ephemeral > terminations, e.g. "rtp/{1,2,3,4}" ? > 2. If I have more than one type of ephemeral termination supported, how do I > figure out which one support what packages (without instantiating one of > course). > > -- Flemming > > > > > Brian > > > > -----Original Message----- > > From: Flemming Andreasen > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Sent: 7/25/00 6:20 PM > > Subject: Auditing of ephemerals > > > > Once upon a time, we had quite a lot of discussion about how to audit > > ephemerals at startup time. We even had a suggestion in the Base Root > > Package aimed specifically at solving this, however it was removed later > > on and I can't remember if we ever came up with an alternative, hence my > > question: > > > > How does an MGC figure out what ephemerals an MG supports ? > > > > -- Flemming > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 26 05:40:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18230 for ; Wed, 26 Jul 2000 05:40:14 -0400 (EDT) Received: from standards (47.234.32.16:2158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB819E8@standards.nortelnetworks.com>; Wed, 26 Jul 2000 5:28:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25393 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 05:28:50 -0400 Received: from ws9.cdotb.ernet.in (202.41.72.121:3572) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB819E1@standards.nortelnetworks.com>; Wed, 26 Jul 2000 5:18:47 -0400 Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id OAA09244 for ; Wed, 26 Jul 2000 14:53:10 +0500 (GMT+0500) Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/13Apr00-1149AM) id OAA0000001982; Wed, 26 Jul 2000 14:51:33 +0500 (GMT+0500) X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397F34C9.8ED5E98D@cdotb.ernet.in> Date: Wed, 26 Jul 2000 14:58:17 -0400 Reply-To: rprakash@cdotb.ernet.in Sender: "Media Gateway Control (megaco)" From: Prakash R Organization: C-DOT (Center for Development of Telematics) Subject: Configuration information of MG in MGC X-cc: Priya A , Titty Thomas , Alarmel Mangai , Hariharasubramanian R To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit This query is regarding the configuration information of MG which the MGC is supposed to be aware. 1) What minimal configuration information should the MGC know about MG and vice-versa before they can start interworking? 2) Since the termination ID can be a string, how does one ensure that a MG and a MGC from different vendors agree upon the terminationIDs? (eg., If the MG calls terminations as tdm/1/1, tdm/2/23..etc, and the MGC from another vendor calls the as termA, termB... or uses simple integers, how will interwork?) Shouldn't a recommendation freeze the way terminationIDs are used? Will there be some profile documents which will specify how to refer to TDM terminations, RTP terminations etc? -- Prakash R Co-ordinating Engineer, Internet Telephony Group =========================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256 =========================================================================== From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 26 08:07:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21891 for ; Wed, 26 Jul 2000 08:07:49 -0400 (EDT) Received: from standards (47.234.32.16:3926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81AC0@standards.nortelnetworks.com>; Wed, 26 Jul 2000 7:56:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25699 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 07:56:20 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81ABF@standards.nortelnetworks.com>; Wed, 26 Jul 2000 7:56:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21372; Wed, 26 Jul 2000 08:07:13 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00926; Wed, 26 Jul 2000 08:07:13 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 08:07:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6785FF@whq-msgusr-02.fore.com> Date: Wed, 26 Jul 2000 08:07:13 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Auditing of ephemerals X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't agree with this answer. First of all, I don't think it is possible to do a wildcard audit of RTP/* unless there are some terminations that match (instantiated) Second, there is no requirement that rtp ephemerals are named RTP/* I think the answer is what I said, you audit packages. If there are more than one "rtp" package, so what, if your MGC implements a package that does some kind of rtp, then you can create rtp ephemerals. I'm not sure how you ever get into trouble here, because while I can see extending rtp (or atm), I can't see replacing it, and then having an MG implement two kinds of rtp. If they did, there would have to be something in SDP, or a parameter in LocalControl or TerminationState which told the gateway which one to create. Brian -----Original Message----- From: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 7/26/00 2:04 AM Subject: Re: Auditing of ephemerals G'Day Flemming, By auditing rtp/* and asking for a wildcard response it will give you the packages and properties for that class of termination without the need for instantiating each of the euphemeral terminations. Naming schemes can be provisioned to a certain extent and then auditing can give you the characteristics of named terminations. Cheers, Christian Flemming Andreasen wrote: > > "Rosen, Brian" wrote: > > > You audit packages. For example, if the MG implements RTP, then > > it implements the RTP package. Same with ATM. You audit packages of > > the whole gateway, of course. > > > > That doesn't sound particularly foolproof - who's to say I want to implement > *the* RTP package or *the* ATM package, etc. Nevertheless, it still leaves > me with a couple of questions: > > 1. How do I figure out the naming scheme used for these ephemeral > terminations, e.g. "rtp/{1,2,3,4}" ? > 2. If I have more than one type of ephemeral termination supported, how do I > figure out which one support what packages (without instantiating one of > course). > > -- Flemming > > > > > Brian > > > > -----Original Message----- > > From: Flemming Andreasen > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Sent: 7/25/00 6:20 PM > > Subject: Auditing of ephemerals > > > > Once upon a time, we had quite a lot of discussion about how to audit > > ephemerals at startup time. We even had a suggestion in the Base Root > > Package aimed specifically at solving this, however it was removed later > > on and I can't remember if we ever came up with an alternative, hence my > > question: > > > > How does an MGC figure out what ephemerals an MG supports ? > > > > -- Flemming > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jul 26 08:27:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26490 for ; Wed, 26 Jul 2000 08:27:29 -0400 (EDT) Received: from standards (47.234.32.16:3926) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81AFD@standards.nortelnetworks.com>; Wed, 26 Jul 2000 8:16:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25779 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jul 2000 08:16:09 -0400 Received: from rwcxch02.clarent.com (208.205.112.15:3297) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB81AFC@standards.nortelnetworks.com>; Wed, 26 Jul 2000 8:16:09 -0400 Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 05:27:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <6374EFC78443D41197DD00508B5C35DD3F0291@rwcxch02.clarent.com> Date: Wed, 26 Jul 2000 05:26:59 -0700 Reply-To: Jean-Francois Mule Sender: "Media Gateway Control (megaco)" From: Jean-Francois Mule Subject: Re: IPfax package comments re: WG Last Call: draft-ietf-megaco-h2 48f-00.txt X-To: "gparsons@nortelnetworks.com" X-cc: "jrafferty@worldnet.att.net" , "gunnar.hellstrom@omnitor.se" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Glen, Thank you for the clarifications and for the pointers to the public ITU draft docs. See comments below. --- Glenn Parsons wrote: > They are defined in T.38. Annex E is on H.248 and Annex D is on > SIP/SDP. Perhaps the authors thought that was obvious (or > that it would be included in the references section :-) > ... > This is in the T.38 Rec. It is published as T.38 Amendment 2: > http://www.itu.int/itudoc/itu-t/rec/t/t_38am2.html 2.1. Since both ITU-T references (T.38 Amendment 2 or the TD t.38 annex D) are not published, can it be referenced in the I-D or rfc? If yes, would this annex be publicly available to megaco implementers? 2.2. A way to simplify and solve this would be to include the relevant parts of annex D or the iana registered SDP attributes in an informative annex of draft-ietf-megaco-h248f-00.txt (... with a notice about the published ref specs...). --- end of comments Jean-Francois Mule' Clarent Corp From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 27 01:52:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18035 for ; Thu, 27 Jul 2000 01:52:16 -0400 (EDT) Received: from standards (47.234.32.16:3002) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8215F@standards.nortelnetworks.com>; Thu, 27 Jul 2000 1:40:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27932 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 01:40:32 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82154@standards.nortelnetworks.com>; Thu, 27 Jul 2000 1:30:27 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6R5fOQ06355 for ; Thu, 27 Jul 2000 07:41:24 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA16616 for ; Thu, 27 Jul 2000 07:41:24 +0200 (MET DST) Received: from ericsson.com (mcdh112.epa.ericsson.se [146.11.81.112]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA26928 for ; Thu, 27 Jul 2000 07:41:21 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6785FF@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397FCB7C.6438DCBC@ericsson.com> Date: Thu, 27 Jul 2000 15:41:16 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Auditing of ephemerals To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Firstly I agree that there's no requirement that ephemerals are named RTP/* is was just an example. You'd know the naming pattern before you did an audit. Secondly I don't see what stops you doing a wildcard audit (particularly an audit capability) on non instantiated ephemerals. If you use ContextID ALL, wildcard the termination and ask for wildcard response then you should be able to get whats wanted. The spec doesn't disallow this. You have to be able to do an auditvalue to see the value of the packages that relate to the ephemeral. Cheers, Christian "Rosen, Brian" wrote: > > I don't agree with this answer. > > First of all, I don't think it is possible to do a wildcard audit > of RTP/* unless there are some terminations that match (instantiated) > > Second, there is no requirement that rtp ephemerals are named RTP/* > > I think the answer is what I said, you audit packages. > If there are more than one "rtp" package, so what, if your MGC > implements a package that does some kind of rtp, then you can create > rtp ephemerals. > > I'm not sure how you ever get into trouble here, because while I > can see extending rtp (or atm), I can't see replacing it, and then > having an MG implement two kinds of rtp. If they did, there would > have to be something in SDP, or a parameter in LocalControl or > TerminationState which told the gateway which one to create. > > Brian > > -----Original Message----- > From: Christian Groves > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Sent: 7/26/00 2:04 AM > Subject: Re: Auditing of ephemerals > > G'Day Flemming, > > By auditing rtp/* and asking for a wildcard response it will give you > the packages and properties for that class of termination without the > need for instantiating each of the euphemeral terminations. > > Naming schemes can be provisioned to a certain extent and then auditing > can give you the characteristics of named terminations. > > Cheers, Christian > > Flemming Andreasen wrote: > > > > "Rosen, Brian" wrote: > > > > > You audit packages. For example, if the MG implements RTP, then > > > it implements the RTP package. Same with ATM. You audit packages > of > > > the whole gateway, of course. > > > > > > > That doesn't sound particularly foolproof - who's to say I want to > implement > > *the* RTP package or *the* ATM package, etc. Nevertheless, it still > leaves > > me with a couple of questions: > > > > 1. How do I figure out the naming scheme used for these ephemeral > > terminations, e.g. "rtp/{1,2,3,4}" ? > > 2. If I have more than one type of ephemeral termination supported, > how do I > > figure out which one support what packages (without instantiating one > of > > course). > > > > -- Flemming > > > > > > > > Brian > > > > > > -----Original Message----- > > > From: Flemming Andreasen > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Sent: 7/25/00 6:20 PM > > > Subject: Auditing of ephemerals > > > > > > Once upon a time, we had quite a lot of discussion about how to > audit > > > ephemerals at startup time. We even had a suggestion in the Base > Root > > > Package aimed specifically at solving this, however it was removed > later > > > on and I can't remember if we ever came up with an alternative, > hence my > > > question: > > > > > > How does an MGC figure out what ephemerals an MG supports ? > > > > > > -- Flemming > > > > > > -- > > > Flemming Andreasen Phone: +1 732 452 1667 > > > Cisco Systems Fax: +1 240 359 5839 > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 27 11:30:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19074 for ; Thu, 27 Jul 2000 11:30:00 -0400 (EDT) Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB823D5@standards.nortelnetworks.com>; Thu, 27 Jul 2000 11:18:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28677 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 11:18:16 -0400 Received: from mail.storm.ca (storm.ca) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8239C@standards.nortelnetworks.com>; Thu, 27 Jul 2000 11:08:15 -0400 Received: from henrykpc (gw-ss8networks.storm.ca [209.87.234.122]) by mail.storm.ca (8.9.3+Sun/8.9.3) with SMTP id LAA00090 for ; Thu, 27 Jul 2000 11:19:09 -0400 (EDT) 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Thu, 27 Jul 2000 11:17:43 -0400 Reply-To: Henryk Kijak Sender: "Media Gateway Control (megaco)" From: Henryk Kijak Subject: MEGACO MIB To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit What is a current status of MEGACO MIB? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 27 12:02:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24416 for ; Thu, 27 Jul 2000 12:02:26 -0400 (EDT) Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8240F@standards.nortelnetworks.com>; Thu, 27 Jul 2000 11:50:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28817 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 11:50:41 -0400 Received: from csa.iisc.ernet.in by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82407@standards.nortelnetworks.com>; Thu, 27 Jul 2000 11:40:39 -0400 Received: from helios.csa.iisc.ernet.in (IDENT:prasanna@helios.csa.iisc.ernet.in [144.16.67.46]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA22578 for ; Thu, 27 Jul 2000 21:21:55 +0530 Received: from localhost (prasanna@localhost) by helios.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id VAA10768 for ; Thu, 27 Jul 2000 21:21:34 +0530 X-Authentication-Warning: helios.csa.iisc.ernet.in: prasanna owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 27 Jul 2000 21:21:34 +0530 Reply-To: Gaitonde Anandprasanna Sender: "Media Gateway Control (megaco)" From: Gaitonde Anandprasanna Subject: MGCP To: MEGACO@STANDARDS.NORTELNETWORKS.COM I wanted to know if MGCP can interact with RSVP to make resource reservations in a IP network so that we can transfer a call coming from telephone to Media Gateway throught the IP network and still offer the call QoS guarantees. Please send me some info. Thanks Sincerely prasanna _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-\_|; Thu, 27 Jul 2000 12:38:15 -0400 (EDT) Received: from standards (47.234.32.16:1416) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8249D@standards.nortelnetworks.com>; Thu, 27 Jul 2000 12:26:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29009 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 12:26:37 -0400 Received: from qhars002.nortel.com (47.101.112.102:50954) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8249A@standards.nortelnetworks.com>; Thu, 27 Jul 2000 12:16:36 -0400 Received: from zrtps06s.us.nortel.com (actually 47.140.48.50) by qhars002.nortel.com; Thu, 27 Jul 2000 17:26:02 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Thu, 27 Jul 2000 12:22:58 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Thu, 27 Jul 2000 12:22:34 -0400 Received: from cpm.elex.co.il (cpm.elex.co.il [141.226.9.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA17303 for ; Thu, 27 Jul 2000 19:21:39 +0300 (IDT) Received: from Dan by cpm.elex.co.il (8.8.8+Sun/SMI-SVR4) id TAA06302; Thu, 27 Jul 2000 19:21:39 +0300 (IDT) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Orig: Message-ID: <000201bff7ee$9d12df00$4609e28d@elex.co.il> Date: Thu, 27 Jul 2000 19:17:58 +0200 Reply-To: "Davidson, Dan" Sender: "Media Gateway Control (megaco)" From: "Davidson, Dan" Subject: Fax/Modem & MGCP To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello everyone, Is there any agreement as how Fax and Modem calls should be supported in MGCP ? If yes, is there a document describing it ? thanks, Dan From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jul 27 16:43:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29914 for ; Thu, 27 Jul 2000 16:43:27 -0400 (EDT) Received: from standards (47.234.32.16:4978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82614@standards.nortelnetworks.com>; Thu, 27 Jul 2000 16:31:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0256 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jul 2000 16:31:51 -0400 Received: from repulse.cnchost.com (repulse.concentric.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82613@standards.nortelnetworks.com>; Thu, 27 Jul 2000 16:31:50 -0400 Received: from MATT.ascend.com (ts009d05.lap-ca.concentric.net [64.1.209.161]) by repulse.cnchost.com id QAA17007; Thu, 27 Jul 2000 16:42:46 -0400 (EDT) [ConcentricHost SMTP Relay 1.8] Errors-To: X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000727133545.00cfc570@pop3.ipverse.com> Date: Thu, 27 Jul 2000 13:38:01 -0700 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: MEGACO MIB X-To: Henryk Kijak To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 11:17 AM 7/27/00 -0400, Henryk Kijak wrote: >What is a current status of MEGACO MIB? Back when we started, long ago, it seemed that we would soon have implementations of MEGACO and would learn more about what we needed to support in the MIB. But MEGACO has taken much longer to standardize than we thought. Since there have been no real implementations we have had zero input into the MIB. But now that a bakeoff is scheduled and folks are seriously writing code, we will hopefully soon get more details on what other objects need to be added to the MIB. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 28 08:53:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09503 for ; Fri, 28 Jul 2000 08:53:23 -0400 (EDT) Received: from standards (47.234.32.16:1065) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB829B1@standards.nortelnetworks.com>; Fri, 28 Jul 2000 8:41:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1449 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 08:41:33 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8299C@standards.nortelnetworks.com>; Fri, 28 Jul 2000 8:31:32 -0400 Received: from cisco.com (sj-dial-2-219.cisco.com [10.19.226.220]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA24050; Fri, 28 Jul 2000 05:42:28 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6785FF@whq-msgusr-02.fore.com> <397FCB7C.6438DCBC@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39806364.2B19915C@cisco.com> Date: Thu, 27 Jul 2000 12:29:24 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Auditing of ephemerals X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian Groves wrote: > G'Day Brian, > > Firstly I agree that there's no requirement that ephemerals are named > RTP/* is was just an example. You'd know the naming pattern before you > did an audit. > Actually, part of the point is that you do *not* know the naming pattern, but want to learn it. Seems there's no way to do that so we will have to provision it. > > Secondly I don't see what stops you doing a wildcard audit (particularly > an audit capability) on non instantiated ephemerals. How can you audit something that doesn't exist ? > If you use > ContextID ALL, wildcard the termination and ask for wildcard response > then you should be able to get whats wanted. The spec doesn't disallow > this. I think it does. The command is to be tried on all terminations matching the wildcard, so what do you do when there are no instantiations of some ephemeral termination type - I would expect nothing. > You have to be able to do an auditvalue to see the value of the > packages that relate to the ephemeral. On an instantiated ephemeral - yes, but on an non-existent ephemeral ? > > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I don't agree with this answer. > > > > First of all, I don't think it is possible to do a wildcard audit > > of RTP/* unless there are some terminations that match (instantiated) > > > > Second, there is no requirement that rtp ephemerals are named RTP/* > > > > I think the answer is what I said, you audit packages. > > If there are more than one "rtp" package, so what, if your MGC > > implements a package that does some kind of rtp, then you can create > > rtp ephemerals. > > > > I'm not sure how you ever get into trouble here, because while I > > can see extending rtp (or atm), I can't see replacing it, and then > > having an MG implement two kinds of rtp. If they did, there would > > have to be something in SDP, or a parameter in LocalControl or > > TerminationState which told the gateway which one to create. > > > > Brian > > > > -----Original Message----- > > From: Christian Groves > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Sent: 7/26/00 2:04 AM > > Subject: Re: Auditing of ephemerals > > > > G'Day Flemming, > > > > By auditing rtp/* and asking for a wildcard response it will give you > > the packages and properties for that class of termination without the > > need for instantiating each of the euphemeral terminations. > > > > Naming schemes can be provisioned to a certain extent and then auditing > > can give you the characteristics of named terminations. > > > > Cheers, Christian > > > > Flemming Andreasen wrote: > > > > > > "Rosen, Brian" wrote: > > > > > > > You audit packages. For example, if the MG implements RTP, then > > > > it implements the RTP package. Same with ATM. You audit packages > > of > > > > the whole gateway, of course. > > > > > > > > > > That doesn't sound particularly foolproof - who's to say I want to > > implement > > > *the* RTP package or *the* ATM package, etc. Nevertheless, it still > > leaves > > > me with a couple of questions: > > > > > > 1. How do I figure out the naming scheme used for these ephemeral > > > terminations, e.g. "rtp/{1,2,3,4}" ? > > > 2. If I have more than one type of ephemeral termination supported, > > how do I > > > figure out which one support what packages (without instantiating one > > of > > > course). > > > > > > -- Flemming > > > > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Sent: 7/25/00 6:20 PM > > > > Subject: Auditing of ephemerals > > > > > > > > Once upon a time, we had quite a lot of discussion about how to > > audit > > > > ephemerals at startup time. We even had a suggestion in the Base > > Root > > > > Package aimed specifically at solving this, however it was removed > > later > > > > on and I can't remember if we ever came up with an alternative, > > hence my > > > > question: > > > > > > > > How does an MGC figure out what ephemerals an MG supports ? > > > > > > > > -- Flemming > > > > > > > > -- > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > Cisco Systems Fax: +1 240 359 5839 > > > > > > -- > > > Flemming Andreasen Phone: +1 732 452 1667 > > > Cisco Systems Fax: +1 240 359 5839 -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 28 09:06:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12488 for ; Fri, 28 Jul 2000 09:06:49 -0400 (EDT) Received: from standards (47.234.32.16:1065) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB829E6@standards.nortelnetworks.com>; Fri, 28 Jul 2000 8:55:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1546 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 08:55:10 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB829E5@standards.nortelnetworks.com>; Fri, 28 Jul 2000 8:55:09 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03192; Fri, 28 Jul 2000 09:06:08 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15031; Fri, 28 Jul 2000 09:06:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jul 2000 09:06:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF678627@whq-msgusr-02.fore.com> Date: Fri, 28 Jul 2000 09:06:04 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Auditing of ephemerals X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Firstly I agree that there's no requirement that ephemerals > are named > > RTP/* is was just an example. You'd know the naming pattern > before you > > did an audit. > > > > Actually, part of the point is that you do *not* know the > naming pattern, but > want to learn it. Seems there's no way to do that so we will have to > provision it. Yes, well there was a big mess about learning naming patterns. I had a suggestion, which was not accepted, no alternative was offered, and so there is no way to learn the naming pattern of any set of terminations. I think provisioning it is a very bad idea, but you have no alternative. Sigh. > > > > > Secondly I don't see what stops you doing a wildcard audit > (particularly > > an audit capability) on non instantiated ephemerals. > > How can you audit something that doesn't exist ? I agree, you can't > > > If you use > > ContextID ALL, wildcard the termination and ask for > wildcard response > > then you should be able to get whats wanted. The spec > doesn't disallow > > this. > > I think it does. The command is to be tried on all > terminations matching the > wildcard, so what do you do when there are no instantiations of some > ephemeral termination type - I would expect nothing. As would I > > > > You have to be able to do an auditvalue to see the value of the > > packages that relate to the ephemeral. > > On an instantiated ephemeral - yes, but on an non-existent ephemeral ? > > > > > > > Cheers, Christian > > > > "Rosen, Brian" wrote: > > > > > > I don't agree with this answer. > > > > > > First of all, I don't think it is possible to do a wildcard audit > > > of RTP/* unless there are some terminations that match > (instantiated) > > > > > > Second, there is no requirement that rtp ephemerals are > named RTP/* > > > > > > I think the answer is what I said, you audit packages. > > > If there are more than one "rtp" package, so what, if your MGC > > > implements a package that does some kind of rtp, then you > can create > > > rtp ephemerals. > > > > > > I'm not sure how you ever get into trouble here, because while I > > > can see extending rtp (or atm), I can't see replacing it, and then > > > having an MG implement two kinds of rtp. If they did, there would > > > have to be something in SDP, or a parameter in LocalControl or > > > TerminationState which told the gateway which one to create. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Christian Groves > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Sent: 7/26/00 2:04 AM > > > Subject: Re: Auditing of ephemerals > > > > > > G'Day Flemming, > > > > > > By auditing rtp/* and asking for a wildcard response it > will give you > > > the packages and properties for that class of termination > without the > > > need for instantiating each of the euphemeral terminations. > > > > > > Naming schemes can be provisioned to a certain extent and > then auditing > > > can give you the characteristics of named terminations. > > > > > > Cheers, Christian > > > > > > Flemming Andreasen wrote: > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > You audit packages. For example, if the MG > implements RTP, then > > > > > it implements the RTP package. Same with ATM. You > audit packages > > > of > > > > > the whole gateway, of course. > > > > > > > > > > > > > That doesn't sound particularly foolproof - who's to > say I want to > > > implement > > > > *the* RTP package or *the* ATM package, etc. > Nevertheless, it still > > > leaves > > > > me with a couple of questions: > > > > > > > > 1. How do I figure out the naming scheme used for these > ephemeral > > > > terminations, e.g. "rtp/{1,2,3,4}" ? > > > > 2. If I have more than one type of ephemeral > termination supported, > > > how do I > > > > figure out which one support what packages (without > instantiating one > > > of > > > > course). > > > > > > > > -- Flemming > > > > > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Flemming Andreasen > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Sent: 7/25/00 6:20 PM > > > > > Subject: Auditing of ephemerals > > > > > > > > > > Once upon a time, we had quite a lot of discussion > about how to > > > audit > > > > > ephemerals at startup time. We even had a suggestion > in the Base > > > Root > > > > > Package aimed specifically at solving this, however > it was removed > > > later > > > > > on and I can't remember if we ever came up with an > alternative, > > > hence my > > > > > question: > > > > > > > > > > How does an MGC figure out what ephemerals an MG supports ? > > > > > > > > > > -- Flemming > > > > > > > > > > -- > > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > > Cisco Systems Fax: +1 240 359 5839 > > > > > > > > -- > > > > Flemming Andreasen Phone: +1 732 452 1667 > > > > Cisco Systems Fax: +1 240 359 5839 > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 28 19:31:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20763 for ; Fri, 28 Jul 2000 19:31:44 -0400 (EDT) Received: from standards (47.234.32.16:2578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82FFB@standards.nortelnetworks.com>; Fri, 28 Jul 2000 19:20:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3636 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 19:20:12 -0400 Received: from qhars002.nortel.com (47.101.112.102:51692) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB82FFA@standards.nortelnetworks.com>; Fri, 28 Jul 2000 19:20:12 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Sat, 29 Jul 2000 00:30:44 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 28 Jul 2000 18:30:21 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 28 Jul 2000 18:28:20 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD11480BBB@zcard00g.ca.nortel.com> Date: Fri, 28 Jul 2000 18:28:22 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Auditing of Ephemerals To: MEGACO@STANDARDS.NORTELNETWORKS.COM It's time to resubmit the name pattern package for action by Megaco -- it was SG 16 that rejected it. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jul 28 20:14:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01440 for ; Fri, 28 Jul 2000 20:14:40 -0400 (EDT) Received: from standards (47.234.32.16:2578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83036@standards.nortelnetworks.com>; Fri, 28 Jul 2000 20:03:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3713 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jul 2000 20:03:11 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83035@standards.nortelnetworks.com>; Fri, 28 Jul 2000 20:03:10 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA18878; Fri, 28 Jul 2000 20:14:12 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA28989; Fri, 28 Jul 2000 20:14:13 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jul 2000 20:14:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF67863C@whq-msgusr-02.fore.com> Date: Fri, 28 Jul 2000 20:14:11 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Auditing of Ephemerals X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'll have a draft in as soon as the I-D editor's queue opens up again! Brian -----Original Message----- From: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 7/28/00 7:28 PM Subject: Auditing of Ephemerals It's time to resubmit the name pattern package for action by Megaco -- it was SG 16 that rejected it. Tom Taylor Lead Standards Developer Phone and FAX: +1 613 736 0961 E-mail: taylor@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jul 29 15:35:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08309 for ; Sat, 29 Jul 2000 15:35:33 -0400 (EDT) Received: from standards (47.234.32.16:1433) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB833AD@standards.nortelnetworks.com>; Sat, 29 Jul 2000 15:22:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4872 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 29 Jul 2000 15:22:15 -0400 Received: from altavistausa.com (async-88.ts2.pouch.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB8338D@standards.nortelnetworks.com>; Sat, 29 Jul 2000 15:12:10 -0400 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-ID: <662.403500.7459@altavistausa.com> Date: Sat, 29 Jul 2000 15:22:15 -0400 Reply-To: callback123@ALTAVISTAUSA.COM Sender: "Media Gateway Control (megaco)" From: callback123@ALTAVISTAUSA.COM Subject: From Lorraine,as promised,I can lower your bill To: MEGACO@STANDARDS.NORTELNETWORKS.COM Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 31 15:02:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25921 for ; Mon, 31 Jul 2000 15:02:17 -0400 (EDT) Received: from standards (47.234.32.16:2386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83A30@standards.nortelnetworks.com>; Mon, 31 Jul 2000 14:50:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0676 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 14:50:23 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83A2D@standards.nortelnetworks.com>; Mon, 31 Jul 2000 14:40:22 -0400 Received: from chsharp-tecra.cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id LAA13002 for ; Mon, 31 Jul 2000 11:51:32 -0700 (PDT) X-Sender: chsharp@localhost.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20000731144559.00b0b7e0@localhost.cisco.com> Date: Mon, 31 Jul 2000 14:50:39 -0400 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Comment on Last Call for G-K To: MEGACO@STANDARDS.NORTELNETWORKS.COM This comment applies to all I-Ds. The titles for these drafts should be changed to describe what is in them. For example, Annex I should be titled "H.248 Annex I - Megaco Transport over ATM" Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 31 21:57:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02775 for ; Mon, 31 Jul 2000 21:56:59 -0400 (EDT) Received: from standards (47.234.32.16:1359) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83B80@standards.nortelnetworks.com>; Mon, 31 Jul 2000 21:45:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1111 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 21:45:17 -0400 Received: from qhars002.nortel.com (47.101.112.102:59981) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83B7F@standards.nortelnetworks.com>; Mon, 31 Jul 2000 21:45:16 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 1 Aug 2000 02:55:19 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 31 Jul 2000 21:50:26 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 31 Jul 2000 21:50:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFB5A.D7824350" Message-ID: <8E2783FA4E0CD411888D0000F8CD15D33C38CD@zcard00q.ca.nortel.com> Date: Mon, 31 Jul 2000 21:50:17 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Nit on draft-ietf-megaco-h248g-00.txt X-cc: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM 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_01BFFB5A.D7824350 Content-Type: text/plain; charset="iso-8859-1" Just noticed a nit on draft-ietf-megaco-h248g-00.txt. The Keypad Package still contains descriptive text saying it supports dtmf touch feedback, an update which I believe was not accepted at ITU Osaka. Editorial slip-up. Proposed change to section 4.3, descriptive text: delete sentence "Keypad entry can be directed to provide audio and/or display feedback ... display." Same change should be forwarded to ITU text as an editorial correction. -- Peter Blatherwick ------_=_NextPart_001_01BFFB5A.D7824350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nit on draft-ietf-megaco-h248g-00.txt

Just noticed a nit on = draft-ietf-megaco-h248g-00.txt.  The Keypad Package still contains = descriptive text saying it supports dtmf touch feedback, an update = which I believe was not accepted at ITU Osaka.  Editorial = slip-up. 

Proposed change to section 4.3, descriptive = text: delete sentence "Keypad = entry can be directed to provide audio and/or display feedback ... = display." 

Same change should be forwarded to ITU text as = an editorial correction. 

-- Peter Blatherwick

------_=_NextPart_001_01BFFB5A.D7824350-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jul 31 23:01:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12883 for ; Mon, 31 Jul 2000 23:01:53 -0400 (EDT) Received: from standards (47.234.32.16:1049) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83BBE@standards.nortelnetworks.com>; Mon, 31 Jul 2000 22:50:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1189 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jul 2000 22:50:07 -0400 Received: from pusren01.risti.telkom.co.id by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB83BBC@standards.nortelnetworks.com>; Mon, 31 Jul 2000 22:40:05 -0400 Received: from sign73 ([10.14.3.87]) by pusren01.risti.telkom.co.id (8.9.1/8.9.1) with SMTP id JAA03233 for ; Tue, 1 Aug 2000 09:59:14 +0700 (JVT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01BFFC03.345A5560" 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 Message-ID: <001b01bffbc8$8995f380$57030e0a@telkom.go.id> Date: Tue, 1 Aug 2000 21:55:28 +0700 Reply-To: Tubagus Syamsudin Sender: "Media Gateway Control (megaco)" From: Tubagus Syamsudin Subject: Interworking Problem To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0018_01BFFC03.345A5560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, I was learning VoIP technology, but for implementation, i still confuse = for some following problems : 1. If we have H.323 based network, and we want to combine with the = Megaco. How can H.323 accommodate that? 2. What's the advantage of point 1 (combination of Megaco-H.323) compare = with H.323 total solution. 3. How is the flow of call set-up from point 1. 4. Can Megaco used as stand alone protocol in the VoIP network, cause we = know that Megaco has handset, DTMF, and RTP packages, address = translation and routing function that can handle until end user.=20 5. If we have Megaco based network, and we want to use SIP as a call = set-up protocol, how to combine SIP protocol as part of Megaco. Is that = combination will become the specific package or there is another = mechanism in MGCP that accommodate that issue? 6. Do you have a comparation between : a. Combination H.323 and Megaco b. Combination SIP and Megaco c. H.323 total solution Which one is technically the best ? Your kind explanation on the questions above would be highly = appreciated. Your answers are very important for me. Thank you very much for your cooperation and attention. We look forward = to hearing from you soon. Best regards Bagus. ------=_NextPart_000_0018_01BFFC03.345A5560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear All,

I was learning VoIP technology, but for implementation,  i = still=20 confuse for some following problems :

1. If we have H.323 based network, and we want to combine with the = Megaco.=20 How can H.323 accommodate that?

2. What's the advantage of point 1 (combination of Megaco-H.323) = compare with=20 H.323 total solution.

3. How is the flow of call set-up from point 1.

4. Can Megaco used as stand alone protocol in the VoIP network, cause = we know=20 that Megaco has handset, DTMF, and RTP packages, address translation and = routing=20 function that can handle until end user.

5. If we have Megaco based network, and we want to use SIP as a call = set-up=20 protocol, how to combine SIP protocol as part of Megaco. Is that = combination=20 will become the specific package or there is another mechanism in MGCP = that=20 accommodate that issue?

6. Do you have a comparation between :

a. Combination H.323 and Megaco

b. Combination SIP and Megaco

c. H.323 total solution

Which one is technically the best ?

 

Your kind explanation on the questions above would be highly=20 appreciated. Your answers are very important for = me.

Thank you very much for your cooperation and attention. We look = forward to=20 hearing from you soon.

Best regards

Bagus.

 

------=_NextPart_000_0018_01BFFC03.345A5560--