Context Id in reply for failed Add

"B Venkat S.R Swamy" <b.swamy@flextronicssoftware.com>

______________________________________________=
_
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.=
org/mailman/listinfo/megaco
A question has arisen during interop testing regarding the valid 
options for representing an integer using the text encoding defined 
by H.248.  

Briefly put, for those productions which include a terminal symbol 
=

representing an integer, such as UINT32 or UINT16, the ABNF seems to 
pretty clearly indicate the integer must be coded using radix 10:

   UINT16               =3D 1*5=
(DIGIT)  ; %x0-FFFF

   UINT32               =3D 1*1=
0(DIGIT) ; %x0-FFFFFFFF

   DIGIT                =3D=
 %x30-39         ; 0-9

So, is it correct to assume that in all packages, any  

parameter value that is defined to be an "integer" must 

be coded radix 10 unless clearly specified as otherwise?

For example, in the Shared Risk Package, the specification for 

the Shared risk group Identity Request (shrisk/srgi), states 

		 Type:		 Sub-list of type Integer

Is it correct to conclude that the integers in the list be coded 

radix 10, or could radix 16 be used (if the value is preceded by "=
0x")?

[SG]
IMO, the integers should not be represented in hexadecimal format i=
f it is not specifically mentioned in the standard documents.
For specific package related query, the section 5.5.1.3 of H.248.22=
 specifies follows:
   "That is,
    the shrisk/srgi decimal integer is treated as a four =
byte binary number within the MG and MGC.
    This way different bytes or groups of bits may be use=
d to address different types of resources in the
    MG. For example: the first two bytes could be used to=
 identify DSP resources while the last two
    bytes could identify interface boards on the MG. When=
 sent over the GCP link, the binary number
    is, however, expressed as a decimal number integer.&q=
uot;
So the value must be represented in decimal integer format.
[/SG]

Secondly, regarding the rules for coding integers using radix 16, 

the ABNF in H.248 says the following: 

B.2   ABNF specification

...

   ; Integer, Double, and Unsigned Integer:  Decimal values c=
an be

   ; encoded using characters 0-9.  Hexadecimal values must b=
e prefixed

   ; with '0x' and can use characters 0-9,a-f,A-F.  An octal =
format is

   ; not supported.  Negative integers start with '-' and MUS=
T be

   ; Decimal.  The SafeChar form of VALUE MUST be used.

Some productions clearly require that radix 16 is required with 

leading "0x", e.g. 

   SecurityParmIndex    =3D "0x" 8(HEXDIG)
=

   SequenceNum          =3D "0x"=
; 8(HEXDIG)

   AuthData             =3D "0x=
" 24*64(HEXDIG)

other places the use of the "0x" appears to be implied (?)
   hex4                 =3D=
 1*4HEXDIG

   mtpAddress           =3D MTPToken LBRK=
T 4*8 (HEXDIG) RBRKT

   HEXDIG               =3D ( D=
IGIT / "A" / "B" / "C" / "D" / =
"E" / "F" )

or maybe not?  When hex4 is encoded as a text string should (must;=
may) it 

start with "0x"?; does this production intend to allow a nake=
d radix 16 

value to be coded?

[SG]
The ABNF provides the "0x" prefix where it is required.

The 0x must be used in SecurityParmIndex, SequenceNum, AuthData but=
 in the MID part (IPv6 address and MTP address), the 0x must not be use=
d.

MID part should be treated as the text string which is printable fo=
rmat of IPv6 or MTP address.

Printable format of IPV6 addresses does not contain "0x".=

[/SG]

Cherry Cheers,

Gerald

_______________________________________________

Megaco mailing list

Megaco@ietf.org

http=
s://www1.ietf.org/mailman/listinfo/megaco

***********************  FSS-Restricted   ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software <=
br>
Systems Limited (FSS) and is intended solely for the use of the  

individual to whom it is addressed. It may contain  privileged or 

confidential information and should not be circulated or used for 

any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 

If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
=

the contents of this message.  FSS  accepts no  responsibility  for
=

loss or damage arising from the use of  the information transmitted
=

by this email including damage from virus."=

--0__=EABBFBB6DFD55CC48f9e8a93df938690918cEABBFBB6DFD55CC4
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <00__=EABBFBB6DFD55CC4@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAAQAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQABAA
QAgtAB8IHEiwoMEHBxIeOIhQoUOHDCNKnPhQ4cSLGDNqNFgR4sGKFxNuHEmSYEAAADs=

--0__=EABBFBB6DFD55CC48f9e8a93df938690918cEABBFBB6DFD55CC4
Content-type: image/gif; 
	name="pic23637.gif"
Content-Disposition: inline; filename="pic23637.gif"
Content-ID: <10__=EABBFBB6DFD55CC4@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==

--0__=EABBFBB6DFD55CC48f9e8a93df938690918cEABBFBB6DFD55CC4
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <20__=EABBFBB6DFD55CC4@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBB6DFD55CC48f9e8a93df938690918cEABBFBB6DFD55CC4--

--===============1115739619==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1115739619==--

From megaco-bounces@ietf.org Thu Mar 02 12:49:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FErvM-0006Kw-GJ; Thu, 02 Mar 2006 12:49:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FErvL-0006Kr-61
	for megaco@ietf.org; Thu, 02 Mar 2006 12:49:11 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErvJ-000069-Nw
	for megaco@ietf.org; Thu, 02 Mar 2006 12:49:11 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k22Hn7o03381
	for ; Thu, 2 Mar 2006 12:49:07 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Properties in Base Root Package!!
Date: Thu, 2 Mar 2006 12:49:03 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407078AE0@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Properties in Base Root Package!!
Thread-Index: AcY9waie8LJomuTRSmOne4oAPqWLZwAXyLGA
From: "Kevin Boyle" 
To: "Christian Groves" ,
	"B Venkat S.R Swamy" 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

I have to agree with Christian: every MG will have a limit to the number
of contexts.  There has to be data associated with the context, like the
topology, the priority and emergency status and the list of terminations
in the context.  These things take up space in the datastore.
Therefore, it is *impossible* that an MG could have an infinite number
of contexts.

I believe that if the MG can, in fact, support a number of contexts
equal to the address range, that it return the maximum value of the
address range.  For H.248, this is 0xFFFFFFFD or 4294967293.

Kevin 

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@nteczone.com] 
Sent: Thursday, March 02, 2006 1:20 AM
To: B Venkat S.R Swamy
Cc: megaco@ietf.org
Subject: Re: [Megaco] Properties in Base Root Package!!

Hello,

I think you'll find that there probably wasn't alot of thought behind
specifying 'double' and its been hanging around pre-H.248.1v1. There is
no such thing as an "infinite" number of contexts support. Anyone that
can design a MG that can support an infinite number of contexts will be
a rich person!!! However I would be weary buying a MG from someone who
says this. Needless to say if they design it H.248 won't be able to
address any more terminations than 0xFFFFFFFD.

Regards, Christian

B Venkat S.R Swamy wrote:

> Hi
>
> Although you are right that maximum theoretical number of simultaneous

> contexts any gateway can handle is 0xFFFFFFFD, but BaseRoot package 
> allows MG or MGC to specify maximum number to simultaneous context to 
> be 8byte number(double).
> I believe it was intentionally specified as double although the 
> Context ID is only 4byte Unsigned Integer.
>
> Therefore even specifying 0xFFFFFFFE or 0xFFFFFFFF would mean a 
> infinite number of contexts support at MG end.
>
> regards
> B Venkat S.R Swamy
> Senior Technical Leader
> Flextronics Software Systems
> Phone: +91-124- 4176213
> Fax: +91-124-4300247
> web: www.flextronicssoftware.com
> Inactive hide details for Christian Groves 
> Christian Groves 
> 
>
>
>                         *Christian Groves
>                         *
>
>                         03/02/2006 06:25 AM
>
> 	
>
> To
> 	
> Mudit Gupta 
>
> cc
> 	
> B Venkat S.R Swamy/HSS@HSS, megaco@ietf.org
>
> Subject
> 	
> Re: [Megaco] Properties in Base Root Package!!
>
> 	
>
>
> Hello Mudit,
>
> You have a limit on how you address Contexts e.g.
>
> ;The values 0x0, 0xFFFFFFFE and 0xFFFFFFFF are reserved.
> ;'-' is used for NULL context. '*' is ALL. '$' is CHOOSE.
> ContextID = (UINT32 / "*" / "-" / "$")
>
> So I would suggest the maximum theoretical number of contexts any 
> gateway could handle is 0xFFFFFFFD.
>
> Regards, Christian
>
> Mudit Gupta wrote:
>
> > Hi
> >
> > Suppose, if I don't want to put any limit on the max number of 
> > contexts, of course there will be system limitation always, but I 
> > don't want to force it. As, I don't have any limit on number of 
> > contexts then the MG should also reply with the same. As the zero
> > ("0") is not being used, we can use it for this purpose as there are

> > lots of instances where NULL/ZERO is used to describe infinite.
> >
> > Regards,
> >
> > Mudit
> >
> > --------------------------------------------------------------------
> > ----
> >
> > *From:* B Venkat S.R Swamy [mailto:b.swamy@flextronicssoftware.com]
> > *Sent:* Wednesday, March 01, 2006 3:08 PM
> > *To:* Mudit Gupta
> > *Cc:* megaco@ietf.org
> > *Subject:* Re: [Megaco] Properties in Base Root Package!!
> >
> > Hi
> >
> > Any real systems will always be bounded by some resource contraints 
> > and IMO MG should return some finite large value(limited to Double 
> > for "MaxNumberOfContexts" and integer for
> > "MaxTerminationsPerContext") as configured either by MGC or locally 
> > provisioned.
> >
> >
> > regards
> > B Venkat S.R Swamy
> > Senior Technical Leader
> > Flextronics Software Systems
> > Phone: +91-124- 4176213
> > Fax: +91-124-4300247
> > web: www.flextronicssoftware.com
> > Inactive hide details for "Mudit Gupta" "Mudit

> > Gupta" 
> >
> > *"Mudit Gupta" *
> >
> > 03/01/2006 01:23 PM
> >
> >
> >
> > To
> >
> >
> >
> >
> > 
> >
> > cc
> >
> >
> >
> > Subject
> >
> >
> >
> >
> > [Megaco] Properties in Base Root Package!!
> >
> >
> >
> >
> > Hi All
> >
> > My query is about the properties defined in base root package. There

> > are total 8 properties, out of these there are two properties called

> > "MaxNumberOfContexts" and "MaxTerminationsPerContext". My query is 
> > if I don't want to put any limit on these values then what values 
> > should be returned by the MG if the MGC/CA does audit on the ROOT 
> > termination for Media descriptor.
> >
> > I think value "0" (zero) can be returned as if any of these 
> > properties has zero value literally then this MG is of no use 
> > (what's the use of MG supporting zero contexts?) and that's why we 
> > can interpret zero value as no-limit.
> >
> > Please, provide me your feedbacks and what you think should be 
> > returned in this case or if you think that there should be limit 
> > always then also reply me back.
> >
> > Regards,
> > Mudit _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> > *********************** FSS-Restricted ***********************
> >
> > *********************** FSS-Restricted ***********************
> > "DISCLAIMER: This message is proprietary to Flextronics Software 
> > Systems Limited (FSS) and is intended solely for the use of the 
> > individual to whom it is addressed. It may contain privileged or 
> > confidential information and should not be circulated or used for 
> > any purpose other than for what it is intended. If you have received

> > this message in error, please notify the originator immediately.
> > If you are not the intended recipient, you are notified that you are

> > strictly prohibited from using, copying, altering, or disclosing the

> > contents of this message. FSS accepts no responsibility for loss or 
> > damage arising from the use of the information transmitted by this 
> > email including damage from virus."
> >
> >---------------------------------------------------------------------
> >---
> >
> >_______________________________________________
> >Megaco mailing list
> >Megaco@ietf.org
> >https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
>
>
>
>
> *********************** FSS-Restricted ***********************
> "DISCLAIMER: This message is proprietary to Flextronics Software 
> Systems Limited (FSS) and is intended solely for the use of the 
> individual to whom it is addressed. It may contain privileged or 
> confidential information and should not be circulated or used for any 
> purpose other than for what it is intended. If you have received this 
> message in error, please notify the originator immediately.
> If you are not the intended recipient, you are notified that you are 
> strictly prohibited from using, copying, altering, or disclosing the 
> contents of this message. FSS accepts no responsibility for loss or 
> damage arising from the use of the information transmitted by this 
> email including damage from virus."
>

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

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

From megaco-bounces@ietf.org Thu Mar 02 12:56:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FEs2R-0001iB-50; Thu, 02 Mar 2006 12:56:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FEs2P-0001gn-L9
	for megaco@ietf.org; Thu, 02 Mar 2006 12:56:29 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEs2P-0000Pa-Bc
	for megaco@ietf.org; Thu, 02 Mar 2006 12:56:29 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k22HuQo05851
	for ; Thu, 2 Mar 2006 12:56:27 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Megaco Text Encoding Question
Date: Thu, 2 Mar 2006 12:56:13 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407078B09@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Megaco Text Encoding Question
Thread-Index: AcY9lDGXqr60DU+PSTi+CqyO8GBS6gAXsxPAAAvJFSA=
From: "Kevin Boyle" 
To: "Kamitses, Jerry" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Comments inline. [KJBII]

Kevin 

-----Original Message-----
From: Kamitses, Jerry [mailto:jkamitses@sonusnet.com] 
Sent: Thursday, March 02, 2006 7:44 AM
To: megaco@ietf.org
Subject: [Megaco] Megaco Text Encoding Question

A question has arisen during interop testing regarding the valid options
for representing an integer using the text encoding defined by H.248.  

Briefly put, for those productions which include a terminal symbol
representing an integer, such as UINT32 or UINT16, the ABNF seems to
pretty clearly indicate the integer must be coded using radix 10:
   UINT16               = 1*5(DIGIT)  ; %x0-FFFF
   UINT32               = 1*10(DIGIT) ; %x0-FFFFFFFF
   DIGIT                = %x30-39         ; 0-9

So, is it correct to assume that in all packages, any parameter value
that is defined to be an "integer" must be coded radix 10 unless clearly
specified as otherwise?

[KJBII] Yes.

For example, in the Shared Risk Package, the specification for the
Shared risk group Identity Request (shrisk/srgi), states 
	Type:	Sub-list of type Integer

Is it correct to conclude that the integers in the list be coded radix
10, or could radix 16 be used (if the value is preceded by "0x")?

[KJBII] These should be coded base 10, as is required in the package.

Secondly, regarding the rules for coding integers using radix 16, 
the ABNF in H.248 says the following: 

B.2   ABNF specification
...
   ; Integer, Double, and Unsigned Integer:  Decimal values can be
   ; encoded using characters 0-9.  Hexadecimal values must be prefixed
   ; with '0x' and can use characters 0-9,a-f,A-F.  An octal format is
   ; not supported.  Negative integers start with '-' and MUST be
   ; Decimal.  The SafeChar form of VALUE MUST be used.

Some productions clearly require that radix 16 is required with 
leading "0x", e.g. 
   SecurityParmIndex    = "0x" 8(HEXDIG)
   SequenceNum          = "0x" 8(HEXDIG)
   AuthData             = "0x" 24*64(HEXDIG)

other places the use of the "0x" appears to be implied (?)
   hex4                 = 1*4HEXDIG
   mtpAddress           = MTPToken LBRKT 4*8 (HEXDIG) RBRKT
   HEXDIG               = ( DIGIT / "A" / "B" / "C" / "D" / "E" / "F" )

or maybe not?  When hex4 is encoded as a text string should (must;may)
it 
start with "0x"?; does this production intend to allow a naked radix 16 
value to be coded?

[KJBII] Specifically defined productions must be coded as specified.  In
this instance, hex4 does NOT use "0x". In usage for integer encoding,
however, if the package defines that the property or parameter takes
values in hex format those must be encoded using "0x".

Cherry Cheers,
Gerald

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

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

From megaco-bounces@ietf.org Thu Mar 02 22:45:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FF1Dv-0002id-QA; Thu, 02 Mar 2006 22:44:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FF1Du-0002f2-Rq
	for megaco@ietf.org; Thu, 02 Mar 2006 22:44:58 -0500
Received: from usnwksmtp02e.usa.siemens.com ([12.46.135.31]
	helo=usnwk220srv.usa.siemens.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF1Dr-0000BG-5Z
	for megaco@ietf.org; Thu, 02 Mar 2006 22:44:58 -0500
Received: from usnwk206a.ww017.siemens.net ([155.45.111.74]) by 172.16.1.36
	with trend_isnt_name_B; Thu, 02 Mar 2006 19:47:22 -0800
Received: from USNWK100MSX.ww017.siemens.net ([155.45.111.54]) by
	usnwk206a.ww017.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 2 Mar 2006 19:44:51 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 2 Mar 2006 19:44:50 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Service Change format
Thread-Index: AcY+dNMZ+ewoSCEDS2yjBDQQZ2pwcg==
From: "Wainwright, John \(Com US\)" 
To: 
X-OriginalArrivalTime: 03 Mar 2006 03:44:51.0959 (UTC)
	FILETIME=[D3F19070:01C63E74]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: [Megaco] Service Change format
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0449528783=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0449528783==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C63E74.D3822FCC"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C63E74.D3822FCC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The ABNF spec for serviceChangeDescriptor is described as follows
serviceChangeDescriptor =3D ServicesToken LBRKT serviceChangeParm =
*(COMMA

serviceChangeParm) RBRKT

; each parameter at-most-once, except auditItem

; at most one of either serviceChangeAddress or serviceChangeMgcId but

; not both

; serviceChangeMethod and serviceChangeReason are REQUIRED

Does this last line imply that whenever we have  "...SERVICES{ x,y,z }"
we must always have the serviceChangeMethod and the serviceChangeReason
parameters in the brackets?

Examples, including the call flows if the standard document, do not show
both parameters which seems to contradict the description above ?

Thanks

John=20

------_=_NextPart_001_01C63E74.D3822FCC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The ABNF spec for serviceChangeDescriptor is =
described=20
as follows

serviceChangeDescriptor =3D ServicesToken =
LBRKT=20
serviceChangeParm *(COMMA
serviceChangeParm) RBRKT
; each parameter at-most-once, except=20
auditItem
; at most one of either =
serviceChangeAddress or=20
serviceChangeMgcId but
; not both
; serviceChangeMethod and =
serviceChangeReason are=20
REQUIRED
Does this last line imply that whenever we =
have =20
"...SERVICES{ x,y,z }" we must always have the serviceChangeMethod =
and the=20
serviceChangeReason parameters in the brackets?
Examples, including the call flows if the =
standard=20
document, do not show both parameters which seems to contradict=20
the description above ?
Thanks
John 

------_=_NextPart_001_01C63E74.D3822FCC--

--===============0449528783==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0449528783==--

From megaco-bounces@ietf.org Fri Mar 03 00:50:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FF3BA-0001Ry-3L; Fri, 03 Mar 2006 00:50:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FF3B9-0001Rn-JL
	for megaco@ietf.org; Fri, 03 Mar 2006 00:50:15 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF3B8-0004ax-Bf
	for megaco@ietf.org; Fri, 03 Mar 2006 00:50:15 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k235oCc11081
	for ; Fri, 3 Mar 2006 00:50:12 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Service Change format
Date: Fri, 3 Mar 2006 00:49:59 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4070D0E58@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Service Change format
Thread-Index: AcY+dNMZ+ewoSCEDS2yjBDQQZ2pwcgAEWSlg
From: "Kevin Boyle" 
To: "Wainwright, John \(Com US\)" ,

X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Yes, Method and Reason are mandatory.

Kevin

________________________________

	From: Wainwright, John (Com US)
[mailto:john.wainwright@siemens.com] 
	Sent: Thursday, March 02, 2006 10:45 PM
	To: megaco@ietf.org
	Subject: [Megaco] Service Change format

	The ABNF spec for serviceChangeDescriptor is described as
follows
	serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm
*(COMMA

	serviceChangeParm) RBRKT

	; each parameter at-most-once, except auditItem

	; at most one of either serviceChangeAddress or
serviceChangeMgcId but

	; not both

	; serviceChangeMethod and serviceChangeReason are REQUIRED

	Does this last line imply that whenever we have  "...SERVICES{
x,y,z }" we must always have the serviceChangeMethod and the
serviceChangeReason parameters in the brackets?

	Examples, including the call flows if the standard document, do
not show both parameters which seems to contradict the description above
?

	Thanks

	John 

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

From megaco-bounces@ietf.org Fri Mar 03 00:57:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FF3IU-00085n-HD; Fri, 03 Mar 2006 00:57:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FF3IT-000835-DX
	for megaco@ietf.org; Fri, 03 Mar 2006 00:57:49 -0500
Received: from spark.hss.co.in ([203.145.155.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF3IR-00053Y-7u
	for megaco@ietf.org; Fri, 03 Mar 2006 00:57:49 -0500
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k235owwr008895;
	Fri, 3 Mar 2006 11:21:04 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k235vsG02713;
	Fri, 3 Mar 2006 11:27:57 +0530 (IST)
In-Reply-To: 
Subject: Re: [Megaco] Service Change format
To: "Wainwright, John \(Com US\)" 
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: 
From: Sudhanshu Garg 
Date: Fri, 3 Mar 2006 11:28:48 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 03/03/2006 11:26:54 AM
MIME-Version: 1.0
X-Spam-Score: 1.7 (+)
X-Scan-Signature: a492040269d440726bfd84680622cee7
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0438969991=="
Errors-To: megaco-bounces@ietf.org

--===============0438969991==
Content-type: multipart/related; 
	Boundary="0__=EABBFBB5DF8EFDDC8f9e8a93df938690918cEABBFBB5DF8EFDDC"
Content-Disposition: inline

--0__=EABBFBB5DF8EFDDC8f9e8a93df938690918cEABBFBB5DF8EFDDC
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

Hi John,

Service change method and service change reason are mandatory in servic=
echange descriptor (Text as well ASN format).

They are not part of the servicechange reply descriptor.

So in the services{x,y,z} they must be present for the service change r=
equest and absent for service change reply.

These were made mandatory long back in Implementor's guide October 2001=
.

IMO, it should be corrected in the example call flows also.

Regards,

Sudhanshu.

Technical Leader

Flextronics Software Systems

Phone:  +91-124-4176301 extn 5109

Fax: +91-124-4300247

web: www.flextronicssoftware.com

"Wainwri=
ght, John \(Com US\)" <john.wainwright@siemens.com>

=

"Wainwright, John \(Com US\)" <joh=
n.wainwright@siemens.com> 
03/03/2006 09:14 AM

=

To 

<megaco@ietf.org>

cc 

Subject 

[Megaco] Service Change format

<=
/td>

The ABNF spec for servic=
eChangeDescriptor is described as follows
serviceChangeDescriptor =3D ServicesToken LBR=
KT serviceChangeParm *(COMMA
serviceChangeParm) RBRKT
; each parameter at-most-once, except auditIt=
em
; at most one of either serviceChangeAddress =
or serviceChangeMgcId but
; not both
; serviceChangeMethod and serviceChangeReason=
 are REQUIRED
Does this last line i=
mply that whenever we have  "...SERVICES{ x,y,z }" we must al=
ways have the serviceChangeMethod and the serviceChangeReason parameter=
s in the brackets?
Examples, including t=
he call flows if the standard document, do not show both parameters whi=
ch seems to contradict the description above ?
Thanks
John _____=
__________________________________________

Megaco mailing list

Megaco@ietf.org

http=
s://www1.ietf.org/mailman/listinfo/megaco

***********************  FSS-Restricted   ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software <=
br>
Systems Limited (FSS) and is intended solely for the use of the  

individual to whom it is addressed. It may contain  privileged or 

confidential information and should not be circulated or used for 

any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 

If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
=

the contents of this message.  FSS  accepts no  responsibility  for
=

loss or damage arising from the use of  the information transmitted
=

by this email including damage from virus."=

--0__=EABBFBB5DF8EFDDC8f9e8a93df938690918cEABBFBB5DF8EFDDC
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <00__=EABBFBB5DF8EFDDC@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAAQAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQABAA
QAgtAB8IHEiwoMEHBxIeOIhQoUOHDCNKnPhQ4cSLGDNqNFgR4sGKFxNuHEmSYEAAADs=

--0__=EABBFBB5DF8EFDDC8f9e8a93df938690918cEABBFBB5DF8EFDDC
Content-type: image/gif; 
	name="pic26705.gif"
Content-Disposition: inline; filename="pic26705.gif"
Content-ID: <10__=EABBFBB5DF8EFDDC@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==

--0__=EABBFBB5DF8EFDDC8f9e8a93df938690918cEABBFBB5DF8EFDDC
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <20__=EABBFBB5DF8EFDDC@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBB5DF8EFDDC8f9e8a93df938690918cEABBFBB5DF8EFDDC--

--===============0438969991==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0438969991==--

From crystallite@planetdirect.com Fri Mar 03 14:55:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FFGND-0002oT-Nk
	for megaco-archive@lists.ietf.org; Fri, 03 Mar 2006 14:55:35 -0500
Received: from 20150224138.user.veloxzone.com.br ([201.50.224.138])
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1FFGNA-0002eL-0L
	for megaco-archive@lists.ietf.org; Fri, 03 Mar 2006 14:55:35 -0500
Received: from arsenide.barbell.com (eventual [125.222.240.99]) by imperial.com (hideous) with expensive id 732158660612 for ; Sat, 04 Mar 2006 00:55:47 -0500
Date: Fri, 03 Mar 2006 23:38:23 -0500
From: Lowell Lovett 
X-Mailer: homeward 8.226.8270872
Reply-To: Isiah Stiles 
X-Priority: 3 (Normal)
Message-ID: <91928154921962203552343@planetdirect.com>
To: megaco-archive@lists.ietf.org
Subject: Your Order canceled, contact us
In-Reply-To: <10744894542723716811@planetdirect.com>
References: <1354780491652444946960544@planetdirect.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------=9296307717817"
Content-Transfer-Encoding: 8bit
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228

--------=9296307717817
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 8bit

Improve Sexual Performance.  Help eliminate stress, fatigue and depression.  

Human Growth Hormone bestseller.Soma bestseller.

        Soma bestseller.

Ambien bestseller.   

http://ca.geocities.com/rene12077derrek96812/ 

All rivers run into the sea, yet the sea is not full.Baseball is ninety percent mental. The other half if physical

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

We are a puny and fickle folk. Avarice, hesitation, and following are our diseases.Failure will never overtake me if my determination to succeed is strong enough.

--------=9296307717817--

From megaco-bounces@ietf.org Sat Mar 04 10:09:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FFYOJ-00040q-BR; Sat, 04 Mar 2006 10:09:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FFYOH-00040l-Sc
	for megaco@ietf.org; Sat, 04 Mar 2006 10:09:53 -0500
Received: from mailrelay2.alcatel.de ([194.113.59.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFYOF-0002og-EG
	for megaco@ietf.org; Sat, 04 Mar 2006 10:09:53 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr
	[155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP
	id k24F9nRa023391; Sat, 4 Mar 2006 16:09:50 +0100
In-Reply-To: <4406A205.9080301@nteczone.com>
To: Christian Groves 
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: 
From: Albrecht.Schwarz@alcatel.de
Date: Sat, 4 Mar 2006 16:09:47 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 03/04/2006 16:09:49
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org
Subject: [Megaco] Re: Question to H.248 gm Package (used by ES 283 018)
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Thanks Christian for that pointer!

The Annex B ABNF syntax is so allowing to extend a single value towards
'lists' or a 'range'. Is there sth similar for H.248 using binary encoding?

Albrecht

                      Christian Groves                                                                                                 
                                        cc:                                                                                 
                                                   Subject: Re: Question to H.248 gm Package (used by ES 283 018)                      
                      02.03.2006 08:43                                                                                                 
                      Please respond to                                                                                                
                      Christian Groves                                                                                                 

Hello All,

H.248 allows you to specify ranges for parameter values natively. No
packages tricks required.
e.g.
H.248.1 Annex B ABNF Syntax
    parmValue            = (EQUAL alternativeValue / INEQUAL VALUE)

    alternativeValue        = (VALUE
                    / LSBRKT VALUE *(COMMA VALUE) RSBRKT
                        ; sublist (i.e. A AND B AND ...)
                    / LBRKT VALUE *(COMMA VALUE) RBRKT
                        ; alternatives (i.e. A OR B OR ...)
                    / LSBRKT VALUE COLON VALUE RSBRKT)
                        ; range

Regards, Christian

neal wrote:

>Hi Albrecht,
>   using higher 16 bits and low 16 bits of this 32 bits integer separately
>or define 2 properties for ranges?
>
>Neal
>----- Original Message -----
>From: "Albrecht Schwarz" 
>To: 
>Sent: Wednesday, March 01, 2006 6:53 PM
>Subject: Question to H.248 gm Package (used by ES 283 018)
>
>
>
>
>>Question:
>>How shall be the "Remote Source Port Range" property of the Gate
>>
>>
>Management
>
>
>>Package encoded?
>>The type of property gm/spr is "Integer", but the property is supporting
>>"value ranges".
>>
>>Present definition permits only filtering on individual ports, but not
>>ranges IMHO.
>>
>>Albrecht
>>
>>-------------------------------------------------------------------
>>Mail archive for TISPAN_WG3  can be browsed at the following url :
>>         http://list.etsi.org/TISPAN_WG3.html
>>-------------------------------------------------------------------
>>
>>
>
>-------------------------------------------------------------------
>Mail archive for TISPAN_WG3  can be browsed at the following url :
>         http://list.etsi.org/TISPAN_WG3.html
>-------------------------------------------------------------------
>
>
>
>
>
>

-------------------------------------------------------------------
Mail archive for TISPAN_WG3  can be browsed at the following url :
         http://list.etsi.org/TISPAN_WG3.html
-------------------------------------------------------------------

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

From megaco-bounces@ietf.org Mon Mar 06 01:43:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FG9Qv-0002kB-Nu; Mon, 06 Mar 2006 01:43:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FG9Qt-0002k1-Vt
	for megaco@ietf.org; Mon, 06 Mar 2006 01:43:03 -0500
Received: from [70.86.207.172] (helo=quantum.websiteactive.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG9Qq-0001VG-Ku
	for megaco@ietf.org; Mon, 06 Mar 2006 01:43:03 -0500
Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]
	helo=[127.0.0.1])
	by quantum.websiteactive.com with esmtpa (Exim 4.52)
	id 1FG9Qn-00031W-Cj; Mon, 06 Mar 2006 17:42:58 +1100
Message-ID: <440BD9E8.6000705@nteczone.com>
Date: Mon, 06 Mar 2006 17:42:48 +1100
From: Christian Groves 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Albrecht.Schwarz@alcatel.de
Subject: Re: [Megaco] Re: Question to H.248 gm Package (used by ES 283 018)
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - quantum.websiteactive.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Cc: TISPAN_WG3@LIST.ETSI.ORG, megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Hello Albrecht,

Yes there is:

PropertyParm ::= SEQUENCE
{
name PkgdName,
value SEQUENCE OF OCTET STRING,
extraInfo CHOICE
{
relation Relation,
range BOOLEAN,
sublist BOOLEAN
} OPTIONAL,
�
}

Regards, Christian

Albrecht.Schwarz@alcatel.de wrote:

>Thanks Christian for that pointer!
>
>The Annex B ABNF syntax is so allowing to extend a single value towards
>'lists' or a 'range'. Is there sth similar for H.248 using binary encoding?
>
>Albrecht
>
>
>
>                                                                                                                                       
>                      Christian Groves                                                                                                 
>                                            ECZONE.COM>                  cc:                                                                                 
>                                                   Subject: Re: Question to H.248 gm Package (used by ES 283 018)                      
>                      02.03.2006 08:43                                                                                                 
>                      Please respond to                                                                                                
>                      Christian Groves                                                                                                 
>                                                                                                                                       
>
>
>
>
>Hello All,
>
>H.248 allows you to specify ranges for parameter values natively. No
>packages tricks required.
>e.g.
>H.248.1 Annex B ABNF Syntax
>    parmValue            = (EQUAL alternativeValue / INEQUAL VALUE)
>
>    alternativeValue        = (VALUE
>                    / LSBRKT VALUE *(COMMA VALUE) RSBRKT
>                        ; sublist (i.e. A AND B AND ...)
>                    / LBRKT VALUE *(COMMA VALUE) RBRKT
>                        ; alternatives (i.e. A OR B OR ...)
>                    / LSBRKT VALUE COLON VALUE RSBRKT)
>                        ; range
>
>Regards, Christian
>
>neal wrote:
>
>  
>
>>Hi Albrecht,
>>  using higher 16 bits and low 16 bits of this 32 bits integer separately
>>or define 2 properties for ranges?
>>
>>Neal
>>----- Original Message -----
>>From: "Albrecht Schwarz" 
>>To: 
>>Sent: Wednesday, March 01, 2006 6:53 PM
>>Subject: Question to H.248 gm Package (used by ES 283 018)
>>
>>
>>
>>
>>    
>>
>>>Question:
>>>How shall be the "Remote Source Port Range" property of the Gate
>>>
>>>
>>>      
>>>
>>Management
>>
>>
>>    
>>
>>>Package encoded?
>>>The type of property gm/spr is "Integer", but the property is supporting
>>>"value ranges".
>>>
>>>Present definition permits only filtering on individual ports, but not
>>>ranges IMHO.
>>>
>>>Albrecht
>>>
>>>-------------------------------------------------------------------
>>>Mail archive for TISPAN_WG3  can be browsed at the following url :
>>>        http://list.etsi.org/TISPAN_WG3.html
>>>-------------------------------------------------------------------
>>>
>>>
>>>      
>>>
>>-------------------------------------------------------------------
>>Mail archive for TISPAN_WG3  can be browsed at the following url :
>>        http://list.etsi.org/TISPAN_WG3.html
>>-------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>    
>>
>
>-------------------------------------------------------------------
>Mail archive for TISPAN_WG3  can be browsed at the following url :
>         http://list.etsi.org/TISPAN_WG3.html
>-------------------------------------------------------------------
>
>
>
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>  
>

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

From megaco-bounces@ietf.org Tue Mar 07 06:41:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGaZ6-0005Cl-RN; Tue, 07 Mar 2006 06:41:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaZ4-0005Cd-Nd
	for megaco@ietf.org; Tue, 07 Mar 2006 06:41:18 -0500
Received: from web8509.mail.in.yahoo.com ([202.43.219.171])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGaZ2-0007ag-US
	for megaco@ietf.org; Tue, 07 Mar 2006 06:41:18 -0500
Received: (qmail 73017 invoked by uid 60001); 7 Mar 2006 11:41:15 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=mgQiCUMyO3PcbTQhuk+PWQGx+aC1PskIr9KFWzvb9SXke+fDRTqBZd5D8gYyP5ySg7bJdGyBkzAr5hoyEQ5kR+ssn5deur4CMOwJ/oUyebxeQslifvp+7ZAUogi/UctZFD6PcUs1mmvPkpEbLNfND6yPMEFChuEPiRQ2xLNM8Uc=
	; 
Message-ID: <20060307114115.73015.qmail@web8509.mail.in.yahoo.com>
Received: from [59.145.142.226] by web8509.mail.in.yahoo.com via HTTP;
	Tue, 07 Mar 2006 11:41:15 GMT
Date: Tue, 7 Mar 2006 11:41:15 +0000 (GMT)
From: sree bharadwaj 
To: megaco@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: [Megaco] where can i get MEGACO Pcaps(Packets)
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0867886320=="
Errors-To: megaco-bounces@ietf.org

--===============0867886320==
Content-Type: multipart/alternative; boundary="0-124220966-1141731675=:71262"
Content-Transfer-Encoding: 8bit

--0-124220966-1141731675=:71262
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

  I need MEGACO/H.248 pcaps( I want to know the message format) and  contents of the MEGACO/H.248 packet.
  I know the MEGACO messages are in ASN format and ASN compiler can be used to decode it.

  thanks

  Shree

---------------------------------
 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
--0-124220966-1141731675=:71262
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

  I need MEGACO/H.248 pcaps( I want to know the message format) and  contents of the MEGACO/H.248 packet.
  I know the MEGACO messages are in ASN format and ASN compiler can be used to decode it.

  thanks

  Shree

Jiyo cricket on Yahoo! India cricket

Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
--0-124220966-1141731675=:71262--

--===============0867886320==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0867886320==--

From megaco-bounces@ietf.org Wed Mar 08 23:25:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHCif-0001VW-ED; Wed, 08 Mar 2006 23:25:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCiK-0001Sf-PO
	for megaco@ietf.org; Wed, 08 Mar 2006 23:25:24 -0500
Received: from spark.hss.co.in ([203.145.155.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHCiI-0002EQ-K5
	for megaco@ietf.org; Wed, 08 Mar 2006 23:25:24 -0500
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k294IZwr008318;
	Thu, 9 Mar 2006 09:48:40 +0530 (IST)
Received: from sandesh.hss.hns.com (sandesh [10.203.142.21])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k294QCG01783;
	Thu, 9 Mar 2006 09:56:15 +0530 (IST)
In-Reply-To: <20060307114115.73015.qmail@web8509.mail.in.yahoo.com>
Subject: Re: [Megaco] where can i get MEGACO Pcaps(Packets)
To: sree bharadwaj 
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: 
From: "B Venkat S.R Swamy" 
Date: Thu, 9 Mar 2006 09:57:09 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 09/03/2006 09:55:11 AM
MIME-Version: 1.0
X-Spam-Score: 1.9 (+)
X-Scan-Signature: a492040269d440726bfd84680622cee7
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1020002588=="
Errors-To: megaco-bounces@ietf.org

--===============1020002588==
Content-type: multipart/related; 
	Boundary="0__=EABBFBBFDF8B94A08f9e8a93df938690918cEABBFBBFDF8B94A0"
Content-Disposition: inline

--0__=EABBFBBFDF8B94A08f9e8a93df938690918cEABBFBBFDF8B94A0
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

Hi

Would recommend you to refer the ITU-T H248 recommendations(H248.1 V3) =
 to know the message format. The call flows are mentioned at the end of=
 this document.

If you do not have the access to ITU-T documents, you can also refer ol=
d IETF documents RFC 3525 and other megaco call flows drafts for messag=
e format.

Also note that Megaco messages can be encoded in both Binary(ASN) and T=
ext(ABNF) format.

regards

B Venkat S.R Swamy     

Senior Technical Leader

Flextronics Software Systems

Phone:  +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

sree bharadwaj <sree_30b@yahoo.co.in>

=

sree bharadwaj <sree_30b@yahoo.co.in> 
03/07/2006 05:11 PM

=

To 

megaco@ietf.org

cc 

Subject 

[Megaco] where can i get MEGACO Pcaps(Packets)<=
/td>

<=
/td>

Hi,

I need MEGACO/H.248 pcaps( I want to know the message =
format) and  contents of the MEGACO/H.248 packet.

I know the MEGACO messages are in ASN format and ASN c=
ompiler can be used to decode it.

thanks

Shree
Jiyo c=
ricket on Yahoo! India cricket

Yahoo! Messenger Mobile St=
ay in touch with your buddies all the time._________________=
______________________________

Megaco mailing list

Megaco@ietf.org

http=
s://www1.ietf.org/mailman/listinfo/megaco

***********************  FSS-Restricted   ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software <=
br>
Systems Limited (FSS) and is intended solely for the use of the  

individual to whom it is addressed. It may contain  privileged or 

confidential information and should not be circulated or used for 

any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 

If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
=

the contents of this message.  FSS  accepts no  responsibility  for
=

loss or damage arising from the use of  the information transmitted
=

by this email including damage from virus."=

--0__=EABBFBBFDF8B94A08f9e8a93df938690918cEABBFBBFDF8B94A0
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <00__=EABBFBBFDF8B94A0@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAAQAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQABAA
QAgtAB8IHEiwoMEHBxIeOIhQoUOHDCNKnPhQ4cSLGDNqNFgR4sGKFxNuHEmSYEAAADs=

--0__=EABBFBBFDF8B94A08f9e8a93df938690918cEABBFBBFDF8B94A0
Content-type: image/gif; 
	name="pic24421.gif"
Content-Disposition: inline; filename="pic24421.gif"
Content-ID: <10__=EABBFBBFDF8B94A0@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==

--0__=EABBFBBFDF8B94A08f9e8a93df938690918cEABBFBBFDF8B94A0
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <20__=EABBFBBFDF8B94A0@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8B94A08f9e8a93df938690918cEABBFBBFDF8B94A0--

--===============1020002588==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1020002588==--

From megaco-bounces@ietf.org Thu Mar 09 00:36:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHDom-0006TK-BJ; Thu, 09 Mar 2006 00:36:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDok-0006OT-Vr
	for megaco@ietf.org; Thu, 09 Mar 2006 00:36:06 -0500
Received: from web8505.mail.in.yahoo.com ([202.43.219.167])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHDoi-0003oe-8b
	for megaco@ietf.org; Thu, 09 Mar 2006 00:36:06 -0500
Received: (qmail 67848 invoked by uid 60001); 9 Mar 2006 05:35:56 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=rYPdk+6gQYzwTeWQ/KCg4JRJG630czSPY/7P5K1/DnGJocH1iXXaxoDU4ntUPbE8tDKeMTYlTGqyoz2rTvXc4rhOaaL/kTkV1WZQSypod/bSSX8Wvyhad6Y5mm/KUZ+pf0Zicj1Qq6bgOdMKLYBggH+1BNq1TiU+fgz+3t3ZWoM=
	; 
Message-ID: <20060309053556.67845.qmail@web8505.mail.in.yahoo.com>
Received: from [59.145.142.226] by web8505.mail.in.yahoo.com via HTTP;
	Thu, 09 Mar 2006 05:35:56 GMT
Date: Thu, 9 Mar 2006 05:35:56 +0000 (GMT)
From: sree bharadwaj 
Subject: Re: [Megaco] where can i get MEGACO Pcaps(Packets)
To: "B Venkat S.R Swamy" 
In-Reply-To: 
MIME-Version: 1.0
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1585301317=="
Errors-To: megaco-bounces@ietf.org

--===============1585301317==
Content-Type: multipart/related; boundary="0-1430490842-1141882556=:61928"
Content-Transfer-Encoding: 8bit

--0-1430490842-1141882556=:61928
Content-Type: multipart/alternative; boundary="0-1652467317-1141882556=:61928"

--0-1652467317-1141882556=:61928
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,
  I got to know the message format but I need the capture files. I am not able to find the capture files anywhere.
  i know that the port used by MEGACO/H.248 is 2944,2945 Is there any other port that the H.248/MEGACO uses.
  Is it possible for me to capture the MEGACO pcaps using ethereal but for that i need to know the H.248 application.
  like for eg: video streaming i can capture RTSP .. in the same way is it possible to capture H.248 by running any application.

  Thanks in advance

  Shreelakshmi

"B Venkat S.R Swamy"  wrote:
    Hi

Would recommend you to refer the ITU-T H248 recommendations(H248.1 V3) to know the message format. The call flows are mentioned at the end of this document.
If you do not have the access to ITU-T documents, you can also refer old IETF documents RFC 3525 and other megaco call flows drafts for message format.

Also note that Megaco messages can be encoded in both Binary(ASN) and Text(ABNF) format.

regards
B Venkat S.R Swamy 
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
" src="http://in.f85.mail.yahoo.com/ym/Upload?Data=upl1722443042" width=16>sree bharadwaj 

                sree bharadwaj    03/07/2006 05:11 PM

  To

megaco@ietf.org    
  cc

  Subject

[Megaco] where can i get MEGACO Pcaps(Packets)          
Hi,

I need MEGACO/H.248 pcaps( I want to know the message format) and contents of the MEGACO/H.248 packet.
I know the MEGACO messages are in ASN format and ASN compiler can be used to decode it.

thanks

Shree     
---------------------------------
  Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time._______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the 
individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."

---------------------------------
 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
--0-1652467317-1141882556=:61928
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,
  I got to know the message format but I need the capture files. I am not able to find the capture files anywhere.
  i know that the port used by MEGACO/H.248 is 2944,2945 Is there any other port that the H.248/MEGACO uses.
  Is it possible for me to capture the MEGACO pcaps using ethereal but for that i need to know the H.248 application.
  like for eg: video streaming i can capture RTSP .. in the same way is it possible to capture H.248 by running any application.

  Thanks in advance

  Shreelakshmi

"B Venkat S.R Swamy" <b.swamy@flextronicssoftware.com> wrote:
    Hi

Would recommend you to refer the ITU-T H248 recommendations(H248.1 V3) to know the message format. The call flows are mentioned at the end of this
 document.
If you do not have the access to ITU-T documents, you can also refer old IETF documents RFC 3525 and other megaco call flows drafts for message format.

Also note that Megaco messages can be encoded in both Binary(ASN) and Text(ABNF) format.

regards
B Venkat S.R Swamy 
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
sree bharadwaj <sree_30b@yahoo.co.in>

                sree bharadwaj <sree_30b@yahoo.co.in>
   03/07/2006 05:11 PM           
  To   
megaco@ietf.org

  cc   

  Subject   
[Megaco] where can i get MEGACO Pcaps(Packets)

Hi,

I need MEGACO/H.248 pcaps( I want to know the message format) and contents of the MEGACO/H.248 packet.
I know the MEGACO messages are in ASN format and ASN compiler can be used to decode
 it.

thanks

Shree     
  Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time._______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to
 Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the 
individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."

Jiyo cricket on Yahoo! India cricket

Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
--0-1652467317-1141882556=:61928--
--0-1430490842-1141882556=:61928
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Id: <132079133000001@web8505.mail.in.yahoo.com>

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/
AP//AAAA//8A/wD//////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEAQAgKAB8IHEiw4IOA
AAA7

--0-1430490842-1141882556=:61928--

--===============1585301317==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1585301317==--

From megaco-bounces@ietf.org Thu Mar 09 00:45:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHDxh-0001Pz-Ph; Thu, 09 Mar 2006 00:45:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHDxf-0001IC-Mn
	for megaco@ietf.org; Thu, 09 Mar 2006 00:45:19 -0500
Received: from spark.hss.co.in ([203.145.155.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHDxe-0003yk-0z
	for megaco@ietf.org; Thu, 09 Mar 2006 00:45:19 -0500
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k295cawr019720;
	Thu, 9 Mar 2006 11:08:37 +0530 (IST)
Received: from sandesh.hss.hns.com (sandesh [10.203.142.21])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k295kDG12521;
	Thu, 9 Mar 2006 11:16:16 +0530 (IST)
In-Reply-To: <20060309053556.67845.qmail@web8505.mail.in.yahoo.com>
Subject: Re: [Megaco] where can i get MEGACO Pcaps(Packets)
To: sree bharadwaj 
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: 
From: "B Venkat S.R Swamy" 
Date: Thu, 9 Mar 2006 11:17:09 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 09/03/2006 11:15:12 AM
MIME-Version: 1.0
X-Spam-Score: 1.9 (+)
X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1959036496=="
Errors-To: megaco-bounces@ietf.org

--===============1959036496==
Content-type: multipart/related; 
	Boundary="0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB"
Content-Disposition: inline

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

Hi

As far as the ports are concerned, 2944 and 2945 are default ports as r=
ecommended by protocol, however application can define their own transp=
ort addresses

which are known to both MG and MGC through non-protocol means.

To capture H248 messages, you need to run both the MG and MGC applicati=
on. 

regards

B Venkat S.R Swamy     

Senior Technical Leader

Flextronics Software Systems

Phone:  +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

sree bharadwaj <sree_30b@yahoo.co.in>

=

sree bharadwaj <sree_30b@yahoo.co.in> 
03/09/2006 11:05 AM

=

To 

B Venkat S.R Swamy/HSS@HSS

cc 

megaco@ietf.org

Subject 

Re: [Megaco] where can i get MEGACO Pcaps(Packets)

<=
/td>

Hi,

I got to know the message format but I need the captur=
e files. I am not able to find the capture files anywhere.

i know that the port used by MEGACO/H.248 is 2944,2945=
 Is there any other port that the H.248/MEGACO uses.

Is it possible for me to capture the MEGACO pcaps usin=
g ethereal but for that i need to know the H.248 application.
like for eg: video streaming i can capture RTSP .. in =
the same way is it possible to capture H.248 by running any application=
.

Thanks in advance

Shreelakshmi

"B Venkat S.R Swamy" <b.swamy@flextronicssoftware.com><=
/font> wrote:

Hi

Would recommend you to refer the ITU-T H248 recommendations(H248.1 V3) =
to know the message format. The call flows are mentioned at the end of =
this document.

If you do not have the access to ITU-T documents, you can also refer ol=
d IETF documents RFC 3525 and other megaco call flows drafts for messag=
e format.

Also note that Megaco messages can be encoded in both Binary(ASN) and T=
ext(ABNF) format.

regards

B Venkat S.R Swamy 

Senior Technical Leader

Flextronics Software Systems

Phone: +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

sree bharadwaj <sree_30b@yahoo.co.in>
=

=

sree bharadwaj <sree_30b@yahoo.co.in> 

03/07/2006 05:11 PM

=

To 

megaco@ietf.org

cc 

Subject 

[Megaco] where can i get MEGACO Pcaps(Packets)

=

<=
td width=3D"85%">

Hi,

I need MEGACO/H.248 pcaps( I want to know the message format) and conte=
nts of the MEGACO/H.248 packet.

I know the MEGACO messages are in ASN format and ASN compiler can be us=
ed to decode it.

thanks

Shree 

Jiyo cric=
ket on Yahoo! India cricket

Yahoo! Messenger Mobile St=
ay in touch with your buddies all the time.=
_______________________________________________

Megaco mailing list

Megaco@ietf.org
https://www1.ietf.org/mail=
man/listinfo/megaco

*********************** FSS-Restricted ***********************

"DISCLAIMER: This message is proprietary! to Flextronics Software =

Systems Limited (FSS) and is intended solely for the use of the 

individual to whom it is addressed. It may contain privileged or 

confidential information and should not be circulated or used for 

any purpose other than for what it is intended. If you have received 
this message in error, please notify the originator immediately. 

If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing

the contents of this message. FSS accepts no responsibility for

loss or damage arising from the use of the information transmitted

by this email including damage from virus."

Jiyo c=
ricket on Yahoo! India cricket

Yahoo! Messenger Mobile St=
ay in touch with your buddies all the time.

***********************  FSS-Restricted   ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software <=
br>
Systems Limited (FSS) and is intended solely for the use of the  

individual to whom it is addressed. It may contain  privileged or 

confidential information and should not be circulated or used for 

any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 

If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
=

the contents of this message.  FSS  accepts no  responsibility  for
=

loss or damage arising from the use of  the information transmitted
=

by this email including damage from virus."=

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <00__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAAQAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQABAA
QAgtAB8IHEiwoMEHBxIeOIhQoUOHDCNKnPhQ4cSLGDNqNFgR4sGKFxNuHEmSYEAAADs=

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="pic30715.gif"
Content-Disposition: inline; filename="pic30715.gif"
Content-ID: <10__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <20__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C4264768.gif"
Content-Disposition: inline; filename="C4264768.gif"
Content-ID: <30__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C5593150.gif"
Content-Disposition: inline; filename="C5593150.gif"
Content-ID: <40__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C5273427.gif"
Content-Disposition: inline; filename="C5273427.gif"
Content-ID: <50__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C1947075.gif"
Content-Disposition: inline; filename="C1947075.gif"
Content-ID: <60__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C8634988.gif"
Content-Disposition: inline; filename="C8634988.gif"
Content-ID: <70__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C2455294.gif"
Content-Disposition: inline; filename="C2455294.gif"
Content-ID: <80__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C7686952.gif"
Content-Disposition: inline; filename="C7686952.gif"
Content-ID: <90__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB
Content-type: image/gif; 
	name="C4273580.gif"
Content-Disposition: inline; filename="C4273580.gif"
Content-ID: <100__=EABBFBBFDF8CA8AB@flextronicssoftware.com>
Content-transfer-encoding: base64

R0lGODlhEAABAPcAAAAAAL8AAAC/AL+/AAAAv78AvwC/v8DAwICAgP8AAAD/AP//AAAA//8A/wD/
/////wCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAA8ALAAAAAAQAAEA
QAgKAB8IHEiw4IOAAAA7

--0__=EABBFBBFDF8CA8AB8f9e8a93df938690918cEABBFBBFDF8CA8AB--

--===============1959036496==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1959036496==--

From megaco-bounces@ietf.org Thu Mar 09 03:08:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHGCM-0005oh-IY; Thu, 09 Mar 2006 03:08:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHGCK-0005oM-TP
	for megaco@ietf.org; Thu, 09 Mar 2006 03:08:36 -0500
Received: from ilsmtp01.ecitele.com ([147.234.1.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHGCJ-00005v-AB
	for megaco@ietf.org; Thu, 09 Mar 2006 03:08:36 -0500
From: Shimshon.Lapushner@ecitele.com
To: megaco@ietf.org
Message-ID: 
Date: Thu, 9 Mar 2006 10:08:32 +0200
X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 |
	December 22, 2004) at 03/09/2006 10:15:58
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Subject: [Megaco] Shimshon Lapushner/ECI Telecom is out of the office.
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

I will be out of the office starting  08/03/2006 and will not return until
20/03/2006.

I could be reached by Mobile: +972 54 578-8113

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

From megaco-bounces@ietf.org Thu Mar 09 09:48:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHMRX-0004jB-If; Thu, 09 Mar 2006 09:48:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLvK-0002xo-LD
	for megaco@ietf.org; Thu, 09 Mar 2006 09:15:26 -0500
Received: from web26707.mail.ukl.yahoo.com ([217.146.176.70])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHLvI-0003GU-UI
	for megaco@ietf.org; Thu, 09 Mar 2006 09:15:26 -0500
Received: (qmail 52638 invoked by uid 60001); 9 Mar 2006 14:15:24 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=JjlkxYcBP+l9VJAHFxh8PhsH6qKTLss9jHAXMymOeMfsAFGskOe5gVedzi8ss/ELx8iPMiQGmRnRsHwDJeMlE/jQqS8+/yf/HmbKNUJTxzUYAlyaS8nm5nb4G6qdxoixxQnGrWUFLcX+rVvFn7J0AmSh3Waw6W+uSdevki1tZuQ=
	; 
Message-ID: <20060309141524.52636.qmail@web26707.mail.ukl.yahoo.com>
Received: from [81.255.107.242] by web26707.mail.ukl.yahoo.com via HTTP;
	Thu, 09 Mar 2006 15:15:24 CET
Date: Thu, 9 Mar 2006 15:15:24 +0100 (CET)
From: Xavier Ameziane 
To: megaco@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
X-Mailman-Approved-At: Thu, 09 Mar 2006 09:48:42 -0500
Subject: [Megaco] I am looking for H248 traffic
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1090573772=="
Errors-To: megaco-bounces@ietf.org

--===============1090573772==
Content-Type: multipart/alternative; boundary="0-1462922965-1141913724=:51856"
Content-Transfer-Encoding: 8bit

--0-1462922965-1141913724=:51856
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello

  I am currently looking for some H248 traffic but I can't find it.
  Can someone help me by sending me some ?

  Thanks in advance

  Xavier

---------------------------------
 Nouveau : t�l�phonez moins cher avec Yahoo! Messenger ! D�couvez les tarifs exceptionnels pour appeler la France et l'international.T�l�chargez la version beta.
--0-1462922965-1141913724=:51856
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello

  I am currently looking for some H248 traffic but I can't find it.
  Can someone help me by sending me some ?

  Thanks in advance

  Xavier

 Nouveau : t�l�phonez moins cher avec Yahoo! Messenger ! D�couvez les tarifs exceptionnels pour appeler la France et l'international.
T�l�chargez la version beta.
--0-1462922965-1141913724=:51856--

--===============1090573772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1090573772==--

From megaco-bounces@ietf.org Thu Mar 09 23:05:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHYt1-00072S-2T; Thu, 09 Mar 2006 23:05:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHYt0-0005Lo-B4
	for megaco@ietf.org; Thu, 09 Mar 2006 23:05:54 -0500
Received: from spark.hss.co.in ([203.145.155.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHYrF-0006he-MB
	for megaco@ietf.org; Thu, 09 Mar 2006 23:04:07 -0500
Received: from ultra.hss.co.in (ultra [192.168.100.5])
	by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id k2A3tRwr026242
	for ; Fri, 10 Mar 2006 09:25:36 +0530 (IST)
Received: from sandesh.hss.hns.com (sandesh [10.203.142.21])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k2A437G08319
	for ; Fri, 10 Mar 2006 09:33:09 +0530 (IST)
To: megaco@ietf.org
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: 
From: "B Venkat S.R Swamy" 
Date: Fri, 10 Mar 2006 09:34:04 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 10/03/2006 09:32:04 AM
MIME-Version: 1.0
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Subject: [Megaco] Megaco Queries 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1076604772=="
Errors-To: megaco-bounces@ietf.org

--===============1076604772==
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

Hi

Following are some clarifications that we need from Megaco Maillist:

1)Reporting "Designed to be extended only" Packages in Audit Reply: 

Needed a clarification to be sure that we do not face any interop problems, 

on whether packages mentioned as "Designed to be extended only" 

can be reported in Audit Value/AuditCapabilities reply or not. 

For example TONEDET-2 and TONEGEN-2 are designed to be 

extended only packages and hence should not be used directly.

As per the protocol it is clearly mentioned that MG shall not publish the packages when reporting packages as per the section 12.1.1 H248.1 V3

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

Designed to be extended only (Optional): Yes
This indicates that the package has been expressly designed to be extended by others, not to be directly referenced. 
For example, the package may not have any function on its own or be nonsensical on its own. The MG shall not publish this PackageID when reporting packages.

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

2) MG behaviour on Version or Profile Negotiation failure for UDP transport
Scenario:
1> MG only supports V2 and sends Registration message to MGC with ServiceChange request, containing version ServiceChange version as 2, 
2> MGC only supports lower version and hence replies with version 1,
3> Since MG does not comply with lower version, Version negotiation fails and should disconnect the transport connection with MGC.

Query:
For UDP transport, how MGC comes to know about failure of registration procedure at MG end, 
Is it correct for MG to send ServiceChange with method=FORCED to disconnect the association. This is not clearly stated in the protocol.
 or
 MGC will only come to know when MG stops responding to subsequent messages from MGC.

regards

B Venkat S.R Swamy     

Senior Technical Leader

Flextronics Software Systems

Phone:  +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

***********************  FSS-Restricted   ***********************  

"DISCLAIMER: This message is proprietary to Flextronics Software 

Systems Limited (FSS) and is intended solely for the use of the  

individual to whom it is addressed. It may contain  privileged or 

confidential information and should not be circulated or used for 

any purpose other than for what it is intended. If you have received 

this message in  error, please notify the originator immediately. 

If you are not the intended recipient, you are notified that you are

strictly  prohibited  from  using, copying, altering, or disclosing

the contents of this message.  FSS  accepts no  responsibility  for

loss or damage arising from the use of  the information transmitted

by this email including damage from virus."

--===============1076604772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1076604772==--

From megaco-bounces@ietf.org Mon Mar 13 08:07:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FImlx-00036Y-8k; Mon, 13 Mar 2006 08:07:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlvr-0000zT-Px
	for megaco@ietf.org; Mon, 13 Mar 2006 07:13:51 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIlvq-00048Z-Ee
	for megaco@ietf.org; Mon, 13 Mar 2006 07:13:51 -0500
Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1])
	by localhost.ccpu.com (Postfix) with ESMTP id 1B3DA3469B8
	for ; Mon, 13 Mar 2006 04:13:50 -0800 (PST)
Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203])
	by smtp.ccpu.com (Postfix) with ESMTP id 0F1E734670B
	for ; Mon, 13 Mar 2006 04:13:50 -0800 (PST)
Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by
	sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 13 Mar 2006 04:13:49 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Mar 2006 17:43:44 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <22F058C3ED9D784E90CE473F2A9847F048D35D@in-exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: query about type in the Annex K
Thread-Index: AcZGl5LnyljemDP7SM65b4G4jeggjg==
From: "Ganesh Kumar" 
To: 
X-OriginalArrivalTime: 13 Mar 2006 12:13:49.0203 (UTC)
	FILETIME=[95B0B630:01C64697]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
X-Mailman-Approved-At: Mon, 13 Mar 2006 08:07:39 -0500
Subject: [Megaco] query about type in the Annex K
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0996830764=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0996830764==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64697.93850E01"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64697.93850E01
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

            I have one query in Annex K of H.248/MEGACO, type of signal
is given Enumeration of Packages. In ASN encoding, what is means whether
the Enumeration or any thing else.

            Please clarify this query.

=20

Regards,

Ganesh

------_=_NextPart_001_01C64697.93850E01
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

; Mon, 13 Mar 2006 04:13:50 -0800 (PST)
Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203])
	by smtp.ccpu.com (Postfix) with ESMTP id 0F1E734670B
	for ; Mon, 13 Mar 2006 04:13:50 -0800 (PST)
Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by
	sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 13 Mar 2006 04:13:49 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Mar 2006 17:43:44 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <22F058C3ED9D784E90CE473F2A9847F048D35D@in-exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: query about type in the Annex K
Thread-Index: AcZGl5LnyljemDP7SM65b4G4jeggjg==
From: "Ganesh Kumar" 
To: 
X-OriginalArrivalTime: 13 Mar 2006 12:13:49.0203 (UTC)
	FILETIME=[95B0B630:01C64697]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
X-Mailman-Approved-At: Mon, 13 Mar 2006 08:07:39 -0500
Subject: [Megaco] query about type in the Annex K
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0996830764=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0996830764==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64697.93850E01"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64697.93850E01
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

            I have one query in Annex K of H.248/MEGACO, type of signal
is given Enumeration of Packages. In ASN encoding, what is means whether
the Enumeration or any thing else.

            Please clarify this query.

=20

Regards,

Ganesh

------_=_NextPart_001_01C64697.93850E01
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

         =
   I
have one query in Annex K of H.248/MEGACO, type of signal is given =
Enumeration
of Packages. In ASN encoding, what is means whether the Enumeration or =
any
thing else.

         =
   Please
clarify this query.

Regards,

Ganesh

------_=_NextPart_001_01C64697.93850E01--

--===============0996830764==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0996830764==--

From megaco-bounces@ietf.org Mon Mar 13 08:07:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FImlw-00036J-UL; Mon, 13 Mar 2006 08:07:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlv0-0000Qv-Nv
	for megaco@ietf.org; Mon, 13 Mar 2006 07:12:58 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIluz-00044o-4Z
	for megaco@ietf.org; Mon, 13 Mar 2006 07:12:58 -0500
Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1])
	by localhost.ccpu.com (Postfix) with ESMTP id 261F53469C4
	for ; Mon, 13 Mar 2006 04:12:53 -0800 (PST)
Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203])
	by smtp.ccpu.com (Postfix) with ESMTP id 9E61C3469B8
	for ; Mon, 13 Mar 2006 04:12:51 -0800 (PST)
Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by
	sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 13 Mar 2006 04:12:50 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Mar 2006 17:42:46 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <22F058C3ED9D784E90CE473F2A9847F048D35C@in-exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: query about String type in ASN encoding/decoding
Thread-Index: AcZGl3A/ZeE3DAfDSbuu0w/YyTpWew==
From: "Ganesh Kumar" 
To: 
X-OriginalArrivalTime: 13 Mar 2006 12:12:50.0546 (UTC)
	FILETIME=[72BA5D20:01C64697]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
X-Mailman-Approved-At: Mon, 13 Mar 2006 08:07:39 -0500
Subject: [Megaco] query about String type in ASN encoding/decoding
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0651674653=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0651674653==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64697.70D89E0D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64697.70D89E0D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

            I have one query in Annex K of H.248/MEGACO, type of the
signal is mentioned as String. In ASN encoding it means IA5String or
Octet String.

            Please somebody clarify this query.

=20

Regards,

Ganesh

------_=_NextPart_001_01C64697.70D89E0D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

         =
   I
have one query in Annex K of H.248/MEGACO, type of the signal is =
mentioned as
String. In ASN encoding it means IA5String or Octet =
String.

         =
   Please
somebody clarify this query.

Regards,

Ganesh

------_=_NextPart_001_01C64697.70D89E0D--

--===============0651674653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0651674653==--

=
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,

         =
   I
have one query in Annex K of H.248/MEGACO, type of signal is given =
Enumeration
of Packages. In ASN encoding, what is means whether the Enumeration or =
any
thing else.

         =
   Please
clarify this query.

Regards,

Ganesh

------_=_NextPart_001_01C64697.93850E01--

--===============0996830764==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0996830764==--

From megaco-bounces@ietf.org Mon Mar 13 08:07:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FImlw-00036J-UL; Mon, 13 Mar 2006 08:07:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIlv0-0000Qv-Nv
	for megaco@ietf.org; Mon, 13 Mar 2006 07:12:58 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIluz-00044o-4Z
	for megaco@ietf.org; Mon, 13 Mar 2006 07:12:58 -0500
Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1])
	by localhost.ccpu.com (Postfix) with ESMTP id 261F53469C4
	for ; Mon, 13 Mar 2006 04:12:53 -0800 (PST)
Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203])
	by smtp.ccpu.com (Postfix) with ESMTP id 9E61C3469B8
	for ; Mon, 13 Mar 2006 04:12:51 -0800 (PST)
Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by
	sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 13 Mar 2006 04:12:50 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Mar 2006 17:42:46 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <22F058C3ED9D784E90CE473F2A9847F048D35C@in-exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: query about String type in ASN encoding/decoding
Thread-Index: AcZGl3A/ZeE3DAfDSbuu0w/YyTpWew==
From: "Ganesh Kumar" 
To: 
X-OriginalArrivalTime: 13 Mar 2006 12:12:50.0546 (UTC)
	FILETIME=[72BA5D20:01C64697]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
X-Mailman-Approved-At: Mon, 13 Mar 2006 08:07:39 -0500
Subject: [Megaco] query about String type in ASN encoding/decoding
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0651674653=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0651674653==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64697.70D89E0D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64697.70D89E0D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

            I have one query in Annex K of H.248/MEGACO, type of the
signal is mentioned as String. In ASN encoding it means IA5String or
Octet String.

            Please somebody clarify this query.

=20

Regards,

Ganesh

------_=_NextPart_001_01C64697.70D89E0D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

         =
   I
have one query in Annex K of H.248/MEGACO, type of the signal is =
mentioned as
String. In ASN encoding it means IA5String or Octet =
String.

         =
   Please
somebody clarify this query.

Regards,

Ganesh

------_=_NextPart_001_01C64697.70D89E0D--

--===============0651674653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0651674653==--

From megaco-bounces@ietf.org Mon Mar 13 11:34:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIpzx-0001Yq-6F; Mon, 13 Mar 2006 11:34:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIpzv-0001YQ-KG
	for megaco@ietf.org; Mon, 13 Mar 2006 11:34:19 -0500
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIpzu-00040P-6p
	for megaco@ietf.org; Mon, 13 Mar 2006 11:34:19 -0500
Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1])
	by localhost.ccpu.com (Postfix) with ESMTP id 9C0EF3469DC
	for ; Mon, 13 Mar 2006 08:34:17 -0800 (PST)
Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203])
	by smtp.ccpu.com (Postfix) with ESMTP id 8EDD63469C7
	for ; Mon, 13 Mar 2006 08:34:17 -0800 (PST)
Received: from IN-EXCHANGE.ccin.ccpu.com ([172.25.0.16]) by
	sd-exchange.ccsd.ccpu.com with Microsoft SMTPSVC(6.0.3790.1830);
	Mon, 13 Mar 2006 08:34:16 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 13 Mar 2006 22:04:13 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Message-ID: <22F058C3ED9D784E90CE473F2A9847F048D3BD@in-exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: query about the type of the signals in Annex K
Thread-Index: AcZGu/Y0hPJvaDR5R4ea0IcFvZvtaA==
From: "Deepak Pokharna" 
To: 
X-OriginalArrivalTime: 13 Mar 2006 16:34:16.0689 (UTC)
	FILETIME=[F865D610:01C646BB]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Cc: Ganesh Kumar 
Subject: [Megaco] query about the type of the signals in Annex K
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0239605544=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0239605544==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C646BB.F691ACC5"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C646BB.F691ACC5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

            I have some queries in type of the signals in Annex K.

=20

      K.3 Signals

K3.1 Fixed - Announcement play

=20

Parameters:

1. Announcement name

ParameterID: an (0x0001)

Type: enumeration of announcements.

=20

            Here in the case of ASN encoding "enumeration of
announcements" means what (whether enum or integer)?

=20

      2. Announcement Variant

ParameterID: av (0x0003)

Type: string.

           =20

                        Here in the case of ASN encoding "String" means
IA5String or Octet String?

=20

=20

            Please, somebody clarify my doubts.

=20

Regards,

Deepak

------_=_NextPart_001_01C646BB.F691ACC5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

         =

I have some queries in type of the signals in Annex =
K.

      K.3 =
Signals

K3.1 Fixed - =
Announcement
play

Parameters:

1. Announcement =
name

ParameterID:
an (0x0001)

Type:
enumeration of announcements.

Here in the case of ASN encoding “enumeration of =
announcements”
means what (whether enum or integer)?

      2. =
Announcement
Variant

ParameterID:
av (0x0003)

Type:
string.

         =

         =
            &=
nbsp; 
Here in the case of ASN encoding “String” means IA5String or =
Octet
String?

         =

Please, somebody clarify my doubts.

Regards,

Deepak

------_=_NextPart_001_01C646BB.F691ACC5--

--===============0239605544==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0239605544==--

From megaco-bounces@ietf.org Mon Mar 13 18:29:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIwTm-0007qZ-Qg; Mon, 13 Mar 2006 18:29:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwTl-0007qM-6e
	for megaco@ietf.org; Mon, 13 Mar 2006 18:29:33 -0500
Received: from quantum.websiteactive.com ([70.86.207.162])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIwTh-0001ZH-V3
	for megaco@ietf.org; Mon, 13 Mar 2006 18:29:33 -0500
Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]
	helo=[127.0.0.1])
	by quantum.websiteactive.com with esmtpa (Exim 4.52)
	id 1FIwTc-0002DR-S1; Tue, 14 Mar 2006 10:29:25 +1100
Message-ID: <4416004B.7010407@nteczone.com>
Date: Tue, 14 Mar 2006 10:29:15 +1100
From: Christian Groves 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ganesh Kumar 
Subject: Re: [Megaco] query about String type in ASN encoding/decoding
References: <22F058C3ED9D784E90CE473F2A9847F048D35C@in-exchange>
In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F048D35C@in-exchange>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - quantum.websiteactive.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Hello Ganesh,

Please use H.248.7 its more up to date than Annex K.

There's a table at the top of H.248.1 Annex A.2 that explains the encodings.

Christian

Ganesh Kumar wrote:

> Hi,
>
>  
>
>             I have one query in Annex K of H.248/MEGACO, type of the 
> signal is mentioned as String. In ASN encoding it means IA5String or 
> Octet String.
>
>             Please somebody clarify this query.
>
>  
>
> Regards,
>
> Ganesh
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>  
>

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

From megaco-bounces@ietf.org Mon Mar 13 22:21:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJ06A-0002aU-Tt; Mon, 13 Mar 2006 22:21:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ068-0002aF-NM
	for Megaco@ietf.org; Mon, 13 Mar 2006 22:21:24 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]
	helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJ067-00013Q-B4
	for Megaco@ietf.org; Mon, 13 Mar 2006 22:21:24 -0500
Received: from zcarhxs1.corp.nortel.com
	(zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2E3LKH13755
	for ; Mon, 13 Mar 2006 22:21:21 -0500 (EST)
Received: from [127.0.0.1] ([47.130.17.21] RDNS failed) by
	zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 13 Mar 2006 22:21:20 -0500
Message-ID: <441636AC.6030608@nortel.com>
Date: Mon, 13 Mar 2006 22:21:16 -0500
From: "Tom-PT Taylor" 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Megaco@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Mar 2006 03:21:20.0689 (UTC)
	FILETIME=[5D4E1A10:01C64716]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: 
Subject: [Megaco] Megaco WG closing, but list remains
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

It has been fun being Chair, though I haven't particularly earned my pay 
in the last few years. Anyway, the IESG is finally closing down the 
Working Group. The list will remain active.

I think I'll write an I-D describing Megaco MIB requirements. Maybe I'll 
do better as a contributor than as a motivator.

BYE

Tom Taylor

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

From megaco-bounces@ietf.org Tue Mar 14 11:35:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJCUR-0001S9-6o; Tue, 14 Mar 2006 11:35:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJCUP-0001S4-K2
	for megaco@ietf.org; Tue, 14 Mar 2006 11:35:17 -0500
Received: from xproxy.gmail.com ([66.249.82.194])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJCUO-0006Yr-Cd
	for megaco@ietf.org; Tue, 14 Mar 2006 11:35:17 -0500
Received: by xproxy.gmail.com with SMTP id t12so1006370wxc
	for ; Tue, 14 Mar 2006 08:35:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=bdkIe+0PhQKK3KyfthMSC4L+pAVSCzhjhdPjnDmVfXaMDaCpIjj2KIWWldj7oHdJwdxVyK1Q4OTwckKw0edvXp7+89+kxbYPuKCqM9KLJlhrmTO3S8RjkaegEZd/SUP21RSea1tVUbXp18KPtHxQfwtb2a1gtO9Jca+S68ksFG4=
Received: by 10.70.23.8 with SMTP id 8mr7476wxw;
	Tue, 14 Mar 2006 08:35:16 -0800 (PST)
Received: by 10.70.15.12 with HTTP; Tue, 14 Mar 2006 08:35:16 -0800 (PST)
Message-ID: 
Date: Tue, 14 Mar 2006 11:35:16 -0500
From: "Ron Ho" 
To: megaco@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Subject: [Megaco] Megaco use in SBC
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1783092928=="
Errors-To: megaco-bounces@ietf.org

--===============1783092928==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3466_24290556.1142354116043"

------=_Part_3466_24290556.1142354116043
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi All,

I am confused about how Megaco is to be used in session border controller
setting. Session border controller sits between two IP networks. It does no=
t
work in the traditional gateway sense where one side is always PSTN and the
other IP. Since there is no PSTN, there is no precreated physical
termination and no termination belongs to NULL context. Ephemeral
termination is created only upon receiving the add command. How does the GW
register its ephemeral termination? Or does it need to? I assume that the
only termination to register is root. Am I right?

When an ephemeral termination is subtracted, it will be destroyed
automatically in a normal gateway. Could it be moved to the null context
instead in IP-IP GW? Does it make sense to precreate ephemeral termination
and store them in null context just like physicl termination?

Is there any literture covering Megaco in SBC environment?

Your help is much appreciated.

Thanks,
Ron

------=_Part_3466_24290556.1142354116043
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi All,

I am confused about how Megaco is to be used in session border
controller setting. Session border controller sits between two IP
networks. It does not work in the traditional gateway sense where one
side is always PSTN and the other IP. Since there is no PSTN, there is
no precreated physical termination and no termination belongs to NULL
context. Ephemeral termination is created only upon receiving the add
command. How does the GW register its ephemeral termination? Or does it
need to? I assume that the only termination to register is root. Am I
right?

When an ephemeral termination is subtracted, it will be destroyed
automatically in a normal gateway. Could it be moved to the null
context instead in IP-IP GW? Does it make sense to precreate ephemeral
termination and store them in null context just like physicl
termination?

Is there any literture covering Megaco in SBC environment?

Your help is much appreciated.

Thanks,

Ron

------=_Part_3466_24290556.1142354116043--

--===============1783092928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1783092928==--

From megaco-bounces@ietf.org Tue Mar 14 12:23:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJDEy-0000st-Mo; Tue, 14 Mar 2006 12:23:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJDEx-0000so-8d
	for megaco@ietf.org; Tue, 14 Mar 2006 12:23:23 -0500
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJDEs-0008AK-UJ
	for megaco@ietf.org; Tue, 14 Mar 2006 12:23:23 -0500
Received: from zcarhxs1.corp.nortel.com
	(zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2EHNG820352; Tue, 14 Mar 2006 12:23:16 -0500 (EST)
Received: from [127.0.0.1] ([47.130.17.21] RDNS failed) by
	zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 14 Mar 2006 12:23:15 -0500
Message-ID: <4416FBFF.80207@nortel.com>
Date: Tue, 14 Mar 2006 12:23:11 -0500
From: "Tom-PT Taylor" 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ron Ho 
Subject: Re: [Megaco] Megaco use in SBC
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Mar 2006 17:23:15.0974 (UTC)
	FILETIME=[FAC2E260:01C6478B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Have a look at the ETSI Gate Control Package, now part of the ETSI 
TISPAN Ia interface definition. References:

http://portal.etsi.org/docbox/TISPAN/Open/NGN-R1%20LATEST%20DRAFTS/03039v105.pdf

and

H.248.37

Ron Ho wrote:
> Hi All,
> 
> I am confused about how Megaco is to be used in session border 
> controller setting. Session border controller sits between two IP 
> networks. It does not work in the traditional gateway sense where one 
> side is always PSTN and the other IP. Since there is no PSTN, there is 
> no precreated physical termination and no termination belongs to NULL 
> context. Ephemeral termination is created only upon receiving the add 
> command. How does the GW register its ephemeral termination? Or does it 
> need to? I assume that the only termination to register is root. Am I right?
> 
> When an ephemeral termination is subtracted, it will be destroyed 
> automatically in a normal gateway. Could it be moved to the null context 
> instead in IP-IP GW? Does it make sense to precreate ephemeral 
> termination and store them in null context just like physicl termination?
> 
> Is there any literture covering Megaco in SBC environment?
> 
> Your help is much appreciated.
> 
> Thanks,
> Ron
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

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

From megaco-bounces@ietf.org Tue Mar 14 15:09:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJFpj-0001s2-Uf; Tue, 14 Mar 2006 15:09:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJFpi-0001rx-By
	for megaco@ietf.org; Tue, 14 Mar 2006 15:09:30 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJFph-00042b-0E
	for megaco@ietf.org; Tue, 14 Mar 2006 15:09:30 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	k2EK59e20295
	for ; Tue, 14 Mar 2006 15:05:09 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Megaco use in SBC
Date: Tue, 14 Mar 2006 15:09:30 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4074196B8@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Megaco use in SBC
Thread-Index: AcZHhXzZcMnbTGXZTjqiE1pzGUiC4AAHRINg
From: "Kevin Boyle" 
To: "Ron Ho" , 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Note that there are other IP-IP gateway definitions besides SBCs.  In
this case, yes, all terminations could be ephemerals, and all
terminations would be created and destroyed as defined in H.248.1.

It does not make sense to store ephemeral terminations in NULL as that
would be a violation of H.248.  I do not see why this would be
necessary.  When a termination is created, it exists as long as it is in
a context.  It seems to me that in a function like an SBC, this is
exactly what you would want: the context with the terminations exists as
long as there is a session, and is destroyed when the session completes.

Kevin

________________________________

	From: Ron Ho [mailto:ron.ho.megaco@gmail.com] 
	Sent: Tuesday, March 14, 2006 11:35 AM
	To: megaco@ietf.org
	Subject: [Megaco] Megaco use in SBC

	Hi All,

	I am confused about how Megaco is to be used in session border
controller setting. Session border controller sits between two IP
networks. It does not work in the traditional gateway sense where one
side is always PSTN and the other IP. Since there is no PSTN, there is
no precreated physical termination and no termination belongs to NULL
context. Ephemeral termination is created only upon receiving the add
command. How does the GW register its ephemeral termination? Or does it
need to? I assume that the only termination to register is root. Am I
right?

	When an ephemeral termination is subtracted, it will be
destroyed automatically in a normal gateway. Could it be moved to the
null context instead in IP-IP GW? Does it make sense to precreate
ephemeral termination and store them in null context just like physicl
termination?

	Is there any literture covering Megaco in SBC environment?

	Your help is much appreciated.

	Thanks,
	Ron

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

From megaco-bounces@ietf.org Tue Mar 14 15:23:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJG3N-00086f-EA; Tue, 14 Mar 2006 15:23:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJG3M-00086a-Ro
	for megaco@ietf.org; Tue, 14 Mar 2006 15:23:36 -0500
Received: from togw.navtelcom.com ([199.166.16.39])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJG3M-0004TF-IM
	for megaco@ietf.org; Tue, 14 Mar 2006 15:23:36 -0500
Received: from no.name.available by [199.166.16.39]
	via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with SMTP;
	Tue, 14 Mar 2006 15:36:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Megaco] Megaco use in SBC
Date: Tue, 14 Mar 2006 15:23:40 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Megaco use in SBC
Thread-Index: AcZHhXzZcMnbTGXZTjqiE1pzGUiC4AAHRINgAABw+BA=
From: "Nenad Milidrag" 
To: "Kevin Boyle" , "Ron Ho" ,

X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Hi All,

I am sorry for interrupting but to me this scenario does not fit quite
well in what I know about Megaco/H.248.  I would appreciate if somebody
could explain.

Usually, physical termination, that was previously registered with
controller (MGC or Call agent), will go off-hook dial the number get add
command from controller and ephemeral termination will be created.  If
there is no physical termination how is going off-hook?  Who is going to
be dialed?  How is call initiated?
Is there a document that talks about this or perhaps call-flow example?

Thank you,

Nenad=20

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]=20
Sent: Tuesday, March 14, 2006 3:10 PM
To: Ron Ho; megaco@ietf.org
Subject: RE: [Megaco] Megaco use in SBC

Note that there are other IP-IP gateway definitions besides SBCs.  In
this case, yes, all terminations could be ephemerals, and all
terminations would be created and destroyed as defined in H.248.1.
=20
It does not make sense to store ephemeral terminations in NULL as that
would be a violation of H.248.  I do not see why this would be
necessary.  When a termination is created, it exists as long as it is in
a context.  It seems to me that in a function like an SBC, this is
exactly what you would want: the context with the terminations exists as
long as there is a session, and is destroyed when the session completes.
=20
Kevin

________________________________

	From: Ron Ho [mailto:ron.ho.megaco@gmail.com]=20
	Sent: Tuesday, March 14, 2006 11:35 AM
	To: megaco@ietf.org
	Subject: [Megaco] Megaco use in SBC
=09
=09
	Hi All,
=09
	I am confused about how Megaco is to be used in session border
controller setting. Session border controller sits between two IP
networks. It does not work in the traditional gateway sense where one
side is always PSTN and the other IP. Since there is no PSTN, there is
no precreated physical termination and no termination belongs to NULL
context. Ephemeral termination is created only upon receiving the add
command. How does the GW register its ephemeral termination? Or does it
need to? I assume that the only termination to register is root. Am I
right?
=09
	When an ephemeral termination is subtracted, it will be
destroyed automatically in a normal gateway. Could it be moved to the
null context instead in IP-IP GW? Does it make sense to precreate
ephemeral termination and store them in null context just like physicl
termination?
=09
	Is there any literture covering Megaco in SBC environment?
=09
	Your help is much appreciated.
=09
	Thanks,
	Ron
=09

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

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

From megaco-bounces@ietf.org Tue Mar 14 15:35:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJGEN-00051q-Mq; Tue, 14 Mar 2006 15:34:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJGEL-00051l-Np
	for megaco@ietf.org; Tue, 14 Mar 2006 15:34:57 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]
	helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJGEL-0004bk-CH
	for megaco@ietf.org; Tue, 14 Mar 2006 15:34:57 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2EKYsO08722
	for ; Tue, 14 Mar 2006 15:34:54 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Megaco use in SBC
Date: Tue, 14 Mar 2006 15:34:57 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40741977C@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Megaco use in SBC
Thread-Index: AcZHhXzZcMnbTGXZTjqiE1pzGUiC4AAHRINgAABw+BAAAGVskA==
From: "Kevin Boyle" 
To: "Nenad Milidrag" ,
	"Ron Ho" , 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

This is not a scenario where there is an analog device controlling the
initiation and addressing of a flow.  For the SBC case, the scenario is
a network boundary where a flow has to cross from one IP domain to
another IP domain.  In this instance there is no "offhook", it is just
the connection of a stream between two IP addresses.

Note that H.248 does not require physical terminations to function.
There are many scenarios where physical terminations are not necessary.
While the simple telephone call is a common use-case for H.248, the
protocol was defined with many multimedia applications in mind.

Kevin

-----Original Message-----
From: Nenad Milidrag [mailto:nenad.milidrag@navtelcom.com] 
Sent: Tuesday, March 14, 2006 3:24 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Ron Ho; megaco@ietf.org
Subject: RE: [Megaco] Megaco use in SBC

Hi All,

I am sorry for interrupting but to me this scenario does not fit quite
well in what I know about Megaco/H.248.  I would appreciate if somebody
could explain.

Usually, physical termination, that was previously registered with
controller (MGC or Call agent), will go off-hook dial the number get add
command from controller and ephemeral termination will be created.  If
there is no physical termination how is going off-hook?  Who is going to
be dialed?  How is call initiated?
Is there a document that talks about this or perhaps call-flow example?

Thank you,

Nenad 

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Tuesday, March 14, 2006 3:10 PM
To: Ron Ho; megaco@ietf.org
Subject: RE: [Megaco] Megaco use in SBC

Note that there are other IP-IP gateway definitions besides SBCs.  In
this case, yes, all terminations could be ephemerals, and all
terminations would be created and destroyed as defined in H.248.1.

It does not make sense to store ephemeral terminations in NULL as that
would be a violation of H.248.  I do not see why this would be
necessary.  When a termination is created, it exists as long as it is in
a context.  It seems to me that in a function like an SBC, this is
exactly what you would want: the context with the terminations exists as
long as there is a session, and is destroyed when the session completes.

Kevin

________________________________

	From: Ron Ho [mailto:ron.ho.megaco@gmail.com] 
	Sent: Tuesday, March 14, 2006 11:35 AM
	To: megaco@ietf.org
	Subject: [Megaco] Megaco use in SBC

	Hi All,

	I am confused about how Megaco is to be used in session border
controller setting. Session border controller sits between two IP
networks. It does not work in the traditional gateway sense where one
side is always PSTN and the other IP. Since there is no PSTN, there is
no precreated physical termination and no termination belongs to NULL
context. Ephemeral termination is created only upon receiving the add
command. How does the GW register its ephemeral termination? Or does it
need to? I assume that the only termination to register is root. Am I
right?

	When an ephemeral termination is subtracted, it will be
destroyed automatically in a normal gateway. Could it be moved to the
null context instead in IP-IP GW? Does it make sense to precreate
ephemeral termination and store them in null context just like physicl
termination?

	Is there any literture covering Megaco in SBC environment?

	Your help is much appreciated.

	Thanks,
	Ron

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

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

From megaco-bounces@ietf.org Wed Mar 15 03:25:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJRK2-0008S5-D5; Wed, 15 Mar 2006 03:25:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRK1-0008P9-Sp
	for megaco@ietf.org; Wed, 15 Mar 2006 03:25:33 -0500
Received: from mailrelay2.alcatel.de ([194.113.59.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJRK1-0008NR-Ci
	for megaco@ietf.org; Wed, 15 Mar 2006 03:25:33 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr
	[155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP
	id k2F8PU3g006298; Wed, 15 Mar 2006 09:25:30 +0100
In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA40741977C@zrtphxm2>
Subject: RE: [Megaco] Megaco use in SBC
To: "Nenad Milidrag" ,
	"Ron Ho" 
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: 
From: Albrecht.Schwarz@alcatel.de
Date: Wed, 15 Mar 2006 09:25:28 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 03/15/2006 09:25:29
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Ron, Nenad:

1) Eph-to-Eph (aka Packet-to-Packet)
These are H.248 connection models already used in 3G PLMNs.
See e.g. 3GPP 29.232 "H.248 Mc Profile", covers AAl2-to-AAL2, AAL2-to-IP,
IP-to-IP besides the TDM-to-X connection models.
Applied for instance in 3GPP R4 CS CN.

Another Eph-to-Eph model is part of 29.332 H.248 Mn Profile (e.g., for
interworking between 3GPP CS CN and IMS).

2) SBC embedding in NGN architectures
E.g., there are already decomposed SBCs (according H.248 MGC-MG model) with
H.248 interfaces in following NGN architectures:
* ETSI TISPAN NGN R1
* MSF NGN R2
* MSF NGN R3

Please have a look in the overall docs how to see the correspondent flows
on call/session control level.

Regards,
Albrecht

PS
The association of H.248 with connection model physical-to-X is too
shortsighted. Y-to-X with all permutations is inherent part of the protocol
architecture and of use in real networks.

                      "Kevin Boyle"                                                                                                
                      , "Ron Ho"                  
                      om>                      ,                                         
                                               cc:                                                                                 
                      14.03.2006 21:34         Subject: RE: [Megaco] Megaco use in SBC                                             

This is not a scenario where there is an analog device controlling the
initiation and addressing of a flow.  For the SBC case, the scenario is
a network boundary where a flow has to cross from one IP domain to
another IP domain.  In this instance there is no "offhook", it is just
the connection of a stream between two IP addresses.

Note that H.248 does not require physical terminations to function.
There are many scenarios where physical terminations are not necessary.
While the simple telephone call is a common use-case for H.248, the
protocol was defined with many multimedia applications in mind.

Kevin

-----Original Message-----
From: Nenad Milidrag [mailto:nenad.milidrag@navtelcom.com]
Sent: Tuesday, March 14, 2006 3:24 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; Ron Ho; megaco@ietf.org
Subject: RE: [Megaco] Megaco use in SBC

Hi All,

I am sorry for interrupting but to me this scenario does not fit quite
well in what I know about Megaco/H.248.  I would appreciate if somebody
could explain.

Usually, physical termination, that was previously registered with
controller (MGC or Call agent), will go off-hook dial the number get add
command from controller and ephemeral termination will be created.  If
there is no physical termination how is going off-hook?  Who is going to
be dialed?  How is call initiated?
Is there a document that talks about this or perhaps call-flow example?

Thank you,

Nenad

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Tuesday, March 14, 2006 3:10 PM
To: Ron Ho; megaco@ietf.org
Subject: RE: [Megaco] Megaco use in SBC

Note that there are other IP-IP gateway definitions besides SBCs.  In
this case, yes, all terminations could be ephemerals, and all
terminations would be created and destroyed as defined in H.248.1.

It does not make sense to store ephemeral terminations in NULL as that
would be a violation of H.248.  I do not see why this would be
necessary.  When a termination is created, it exists as long as it is in
a context.  It seems to me that in a function like an SBC, this is
exactly what you would want: the context with the terminations exists as
long as there is a session, and is destroyed when the session completes.

Kevin

________________________________

             From: Ron Ho [mailto:ron.ho.megaco@gmail.com]
             Sent: Tuesday, March 14, 2006 11:35 AM
             To: megaco@ietf.org
             Subject: [Megaco] Megaco use in SBC

             Hi All,

             I am confused about how Megaco is to be used in session border
controller setting. Session border controller sits between two IP
networks. It does not work in the traditional gateway sense where one
side is always PSTN and the other IP. Since there is no PSTN, there is
no precreated physical termination and no termination belongs to NULL
context. Ephemeral termination is created only upon receiving the add
command. How does the GW register its ephemeral termination? Or does it
need to? I assume that the only termination to register is root. Am I
right?

             When an ephemeral termination is subtracted, it will be
destroyed automatically in a normal gateway. Could it be moved to the
null context instead in IP-IP GW? Does it make sense to precreate
ephemeral termination and store them in null context just like physicl
termination?

             Is there any literture covering Megaco in SBC environment?

             Your help is much appreciated.

             Thanks,
             Ron

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

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

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

From megaco-bounces@ietf.org Thu Mar 16 11:00:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJutc-00071I-Cb; Thu, 16 Mar 2006 11:00:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJutb-00071A-GE
	for megaco@ietf.org; Thu, 16 Mar 2006 11:00:15 -0500
Received: from web54205.mail.yahoo.com ([206.190.39.247])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJuta-0006kU-4l
	for megaco@ietf.org; Thu, 16 Mar 2006 11:00:15 -0500
Received: (qmail 25008 invoked by uid 60001); 16 Mar 2006 16:00:09 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=NatATuE01hCaNOoSu/6+INMFQO+7nTXMckXj1fenGFtQe+9joUTZvf6i61TSI7TfQmtsDuR05L5ldhb0PoipTTO1b+t6B6aNav0HKdaDs27S69vJgjou22w6ZhJoBWmN0Nj1eIXjXInmAaxKrfYcUR0nKeA6buypTKbSauue0+o=
	; 
Message-ID: <20060316160008.24997.qmail@web54205.mail.yahoo.com>
Received: from [194.237.142.13] by web54205.mail.yahoo.com via HTTP;
	Fri, 17 Mar 2006 00:00:08 CST
Date: Fri, 17 Mar 2006 00:00:08 +0800 (CST)
From: Tonny Kung 
To: "megaco@ietf.org" 
MIME-Version: 1.0
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Megaco] Question regarding H.248.23 andisp package
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mail2tonny-megaco@yahoo.com.hk
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1208296585=="
Errors-To: megaco-bounces@ietf.org

--===============1208296585==
Content-Type: multipart/alternative; boundary="0-1360329508-1142524808=:24503"
Content-Transfer-Encoding: 8bit

--0-1360329508-1142524808=:24503
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit

Hi all,

I have some questions regarding the use of andisp/dwa package, hoping someone could clarify it:

1) In section 6.3.1.1.2, the description for the pattern parameter for andisp/dwa stated that "The default is no pattern......" and later stated the default value for the pattern parameter is "1". How should we interpret this?

2) andisp/dwa is stated for both on-hook and off-hook delivery. And in case of off-hook, then call waiting alert will be generated. As a result the subscriber will hear a "beep" sound (normally). But since the "cw" signal is of type "Brief", then how would the subsequent "beep" be generated? I suppose the MGC should send down "alert/cw" for ever subsequent "beep"?

Best Regards,
Tonny

_______________________________________
 YM - ���u�T��
 �N��A�S���W���A�A���B�ͤ��i�H�d�U�T�����A�A���A�W���ɴN��ߧY�ݨ�A���󻡸ܳ��N�����C
 http://messenger.yahoo.com.hk
--0-1360329508-1142524808=:24503
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 8bit

Hi all,

I have some questions regarding the use of andisp/dwa package, hoping someone could clarify it:

1) In section 6.3.1.1.2, the description for the pattern parameter for andisp/dwa stated that "The default is no pattern......" and later stated the default value for the pattern parameter is "1". How should we interpret this?

2) andisp/dwa is stated for both on-hook and off-hook delivery. And in case of off-hook, then call waiting alert will be generated. As a result the subscriber will hear a "beep" sound (normally). But since the "cw" signal is of type "Brief", then how would the subsequent "beep" be generated? I suppose the MGC should send down "alert/cw" for ever subsequent "beep"?

Best Regards,
Tonny
_______________________________________
 YM - ���u�T��
 �N��A�S���W���A�A���B�ͤ��i�H�d�U�T�����A�A���A�W���ɴN��ߧY�ݨ�A���󻡸ܳ��N�����C
 http://messenger.yahoo.com.hk
--0-1360329508-1142524808=:24503--

--===============1208296585==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1208296585==--

From megaco-bounces@ietf.org Thu Mar 16 12:42:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJwUt-00033Y-BD; Thu, 16 Mar 2006 12:42:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJwUs-00033T-Ds
	for megaco@ietf.org; Thu, 16 Mar 2006 12:42:50 -0500
Received: from mx2.alcatel.com ([192.75.23.74] helo=smtp2.ca.alcatel.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJwUq-00024U-3z
	for megaco@ietf.org; Thu, 16 Mar 2006 12:42:50 -0500
Received: from [138.120.52.80] (orac.ca.alcatel.com [138.120.52.80])
	by smtp2.ca.alcatel.com (ALCANET) with ESMTP id k2GHglWg021529
	for ; Thu, 16 Mar 2006 11:42:47 -0600
Message-ID: <4419A397.8070202@alcatel.com>
Date: Thu, 16 Mar 2006 12:42:47 -0500
From: Jason Walton 
User-Agent: Mozilla Thunderbird  (X11/20050322)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.51 on 138.120.252.79
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: [Megaco] Encoding packageIDs in ASN.1 messages.
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

II was looking at the example messages provided from the H.248 Erlang
encoding/decoding performance comparison
(http://www.erlang.org/project/megaco/encoding_comparison-v4/encoded_messages). 

Specifically, I was looking at ber/msg08a.bin.  The text version of the
message (pretty/msg08a.txt) contains an events descriptor, containing
events "al/on" and "dd/ce", and a signals descriptor, containing the
signal "cg/rt".

When I look at the BER encoded message (with a program using asn1c, an
open source C-based ASN.1 compiler), however, I'm seeing events with
pkgdName 0x0009/0x0004, 0x0004/0x0004, and a signal with pkgdName
0x0005/0x0031.  In all cases, the second half of the pkgdName is what I
would expect it to be, but the (with the exception of al/on) the
pacakgeID looks wrong to me.

Take the "dd/ce" to start with.  The packageID for dd is 0x0006.  The
packageID in the BER encoded message is 0x0004, which is tonedet (dd
extends tonedet).  According to RFC 3525 6.2.3, I should be able to
refer to events in a base package using the extended package name (so I
should be able to reference dd/tl or tonedet/tl, for example), but it
makes no reference of doing the reverse; accessing an event defined in
one package using the name of the base package.

The Signal "cg/rt" is right out; 0x0005 is the package ID for dg, not
cg, and dg doesn't define an event 0x0031.  The only common link I can
find between these two packages is that they both extend tonegen.

What's going on here?  Is the Erlang Megaco stack horribly broken, or
(more likely) am I just completely missing something here?

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

From megaco-bounces@ietf.org Thu Mar 16 14:23:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJy4c-0003bK-TL; Thu, 16 Mar 2006 14:23:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJy4b-0003Zd-NY
	for megaco@ietf.org; Thu, 16 Mar 2006 14:23:49 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJy4a-0005iN-CS
	for megaco@ietf.org; Thu, 16 Mar 2006 14:23:49 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2GJNiu11862
	for ; Thu, 16 Mar 2006 14:23:44 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Encoding packageIDs in ASN.1 messages.
Date: Thu, 16 Mar 2006 14:23:41 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4074C1F7E@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Encoding packageIDs in ASN.1 messages.
Thread-Index: AcZJITUhntrbdr3zSaKcBJJQ+qQzFwADUZLQ
From: "Kevin Boyle" 
To: "Jason Walton" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

The package IDs recorded by IANA at
http://www.iana.org/assignments/megaco-h248 are definitive.  Anything
else that says otherwise is in error.

You are correct that extension packages can refer to base package
elements, but not the other way around.  It appears that the Erlang
stack was miscoded.

Kevin 

-----Original Message-----
From: Jason Walton [mailto:jason.walton@alcatel.com] 
Sent: Thursday, March 16, 2006 12:43 PM
To: megaco@ietf.org
Subject: [Megaco] Encoding packageIDs in ASN.1 messages.

II was looking at the example messages provided from the H.248 Erlang
encoding/decoding performance comparison
(http://www.erlang.org/project/megaco/encoding_comparison-v4/encoded_mes
sages). 

Specifically, I was looking at ber/msg08a.bin.  The text version of the
message (pretty/msg08a.txt) contains an events descriptor, containing
events "al/on" and "dd/ce", and a signals descriptor, containing the
signal "cg/rt".

When I look at the BER encoded message (with a program using asn1c, an
open source C-based ASN.1 compiler), however, I'm seeing events with
pkgdName 0x0009/0x0004, 0x0004/0x0004, and a signal with pkgdName
0x0005/0x0031.  In all cases, the second half of the pkgdName is what I
would expect it to be, but the (with the exception of al/on) the
pacakgeID looks wrong to me.

Take the "dd/ce" to start with.  The packageID for dd is 0x0006.  The
packageID in the BER encoded message is 0x0004, which is tonedet (dd
extends tonedet).  According to RFC 3525 6.2.3, I should be able to
refer to events in a base package using the extended package name (so I
should be able to reference dd/tl or tonedet/tl, for example), but it
makes no reference of doing the reverse; accessing an event defined in
one package using the name of the base package.

The Signal "cg/rt" is right out; 0x0005 is the package ID for dg, not
cg, and dg doesn't define an event 0x0031.  The only common link I can
find between these two packages is that they both extend tonegen.

What's going on here?  Is the Erlang Megaco stack horribly broken, or
(more likely) am I just completely missing something here?

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

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

From megaco-bounces@ietf.org Thu Mar 16 14:44:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJyOH-00059w-EZ; Thu, 16 Mar 2006 14:44:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJyOF-00059r-RC
	for megaco@ietf.org; Thu, 16 Mar 2006 14:44:07 -0500
Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]
	helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FJyOE-00062O-Gy
	for megaco@ietf.org; Thu, 16 Mar 2006 14:44:07 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2GJi4e00096
	for ; Thu, 16 Mar 2006 14:44:04 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Question regarding H.248.23 andisp package
Date: Thu, 16 Mar 2006 14:44:04 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4074C1FF5@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Question regarding H.248.23 andisp package
Thread-Index: AcZJE872+Nloil3lTWSEiSNWFF+dWgACVsyg
From: "Kevin Boyle" 
To: , 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Comments inline. [KJBII]

Kevin

________________________________

	From: Tonny Kung [mailto:mail2tonny-megaco@yahoo.com.hk] 
	Sent: Thursday, March 16, 2006 11:00 AM
	To: megaco@ietf.org
	Subject: [Megaco] Question regarding H.248.23 andisp package

	Hi all,

	I have some questions regarding the use of andisp/dwa package,
hoping someone could clarify it:

	1) In section 6.3.1.1.2, the description for the pattern
parameter for andisp/dwa stated that "The default is no pattern......"
and later stated the default value for the pattern parameter is "1". How
should we interpret this?
	[KJBII] It appears to me that you are referring to the
in-progress Amendment to H.248.23 (that may, in fact, become a
revision).  The default was added after the original text was written.
As editor, I will correct this and make the parameter optional, so that
the package will continue to be backwards compatible to the original
definition. Note that the text you reference has NOT been approved, and
so is currently not standard.  The current definition of this package is
in H.248.23 (7/2003) Corrigendum 1 (8/2004).

	2) andisp/dwa is stated for both on-hook and off-hook delivery.
And in case of off-hook, then call waiting alert will be generated. As a
result the subscriber will hear a "beep" sound (normally). But since the
"cw" signal is of type "Brief", then how would the subsequent "beep" be
generated? I suppose the MGC should send down "alert/cw" for ever
subsequent "beep"?
	[KJBII] Successive playout of call wait tones are separate
invocations of that tone.  There are scenarios in which some instances
require retransmission of the data on the second (or other subsequent)
call wait tone.  In some other scenarios this does not happen.  This,
plus the fact that there is a significant time between the call wait
tones, makes it fairly plain that the MGC must send alert/cw or
andisp/dwa  for each individual tone invocation. 

	Best Regards,
	Tonny

	_______________________________________
	YM - �x��ӍϢ
	������]���ϾW����������Կ�������ӍϢ�o�㣬�����ϾW�r����������
�����κ��fԒ������ʧ��
	http://messenger.yahoo.com.hk

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

From megaco-bounces@ietf.org Fri Mar 17 03:51:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKAg7-0000EO-Te; Fri, 17 Mar 2006 03:51:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKAg6-0000EG-ID
	for megaco@ietf.org; Fri, 17 Mar 2006 03:51:22 -0500
Received: from web54210.mail.yahoo.com ([206.190.39.252])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKAg5-0006Ft-38
	for megaco@ietf.org; Fri, 17 Mar 2006 03:51:22 -0500
Received: (qmail 50114 invoked by uid 60001); 17 Mar 2006 08:51:17 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.hk;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=lLKUxuNwRtbn59mX8YYudrrNEWfxtNjgnmDrqhE8FyG+A49dffGgMCCG8r+VycTArDbyM+ReVia3jClXuNVSSzZgbaXtKj7JXYl0WkxcR+noTeB1hRS7bRXvfqDpSp0BtFbbEXkQexAn/1SZTfVJF7jL2EdS+L5QITuilHccx14=
	; 
Message-ID: <20060317085117.50112.qmail@web54210.mail.yahoo.com>
Received: from [194.237.142.11] by web54210.mail.yahoo.com via HTTP;
	Fri, 17 Mar 2006 16:51:17 CST
Date: Fri, 17 Mar 2006 16:51:17 +0800 (CST)
From: Tonny Kung 
Subject: =?big5?q?=A6^=C2=D0=A1G=20RE:=20[Megaco]=20Question=20regarding=20H.248.2?=
	=?big5?q?3=20andisp=20package?=
To: Kevin Boyle , mail2tonny-megaco@yahoo.com.hk,
	megaco@ietf.org
In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4074C1FF5@zrtphxm2>
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mail2tonny-megaco@yahoo.com.hk
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1223323987=="
Errors-To: megaco-bounces@ietf.org

--===============1223323987==
Content-Type: multipart/alternative; boundary="0-923785102-1142585477=:47719"
Content-Transfer-Encoding: 8bit

--0-923785102-1142585477=:47719
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit

Hi Kevin,

Thanks for the clarification.

Just that you know, H.248.23 (01/05) is currently stated as "In force" in the ITU-T webpage. Anyhow, if you are going to correct the text, that will be very helpful.

Could you also clarify the following statement?
"The default is no pattern which indicates that the data transmission should not be associated with any signalling."

Does that mean if no pattern parameter is specified, then the CLIP delivery will be the same as using "andisp/data"?

Best Regards,
Tonny

Kevin Boyle  ���G     Comments inline. [KJBII]

 Kevin

---------------------------------
   From: Tonny Kung    [mailto:mail2tonny-megaco@yahoo.com.hk] 
Sent: Thursday, March 16,    2006 11:00 AM
To: megaco@ietf.org
Subject: [Megaco]    Question regarding H.248.23 andisp package

Hi all,

I have some questions regarding the use of    andisp/dwa package, hoping someone could clarify it:

1) In section    6.3.1.1.2, the description for the pattern parameter for andisp/dwa stated    that "The default is no pattern......" and later stated the default value for    the pattern parameter is "1". How should we interpret this?
[KJBII] It appears    to me that you are referring to the in-progress Amendment to H.248.23    (that may, in fact, become a revision).  The default was added after the    original text was written.  As editor, I will correct this and make    the parameter optional, so that the package will continue to be backwards    compatible to the original definition. Note that the text you reference has    NOT been approved, and so is currently not standard.  The current    definition of this package is in H.248.23 (7/2003) Corrigendum 1    (8/2004).

2) andisp/dwa is stated for both on-hook and    off-hook delivery. And in case of off-hook, then call waiting alert will be    generated. As a result the subscriber will hear a "beep" sound (normally). But    since the "cw" signal is of type "Brief", then how would the subsequent "beep"    be generated? I suppose the MGC should send down "alert/cw" for ever    subsequent "beep"?
[KJBII] Successive playout of call wait tones are separate    invocations of that tone.  There are scenarios in which some    instances require retransmission of the data on the second (or other    subsequent) call wait tone.  In some other scenarios this does not    happen.  This, plus the fact that there is a significant time between the    call wait tones, makes it fairly plain that the MGC must send alert/cw or    andisp/dwa  for each individual tone    invocation. 

Best Regards,
Tonny

_______________________________________
 YM - ���u�T��
 �N��A�S���W���A�A���B�ͤ��i�H�d�U�T�����A�A���A�W���ɴN��ߧY�ݨ�A���󻡸ܳ��N�����C
 http://messenger.yahoo.com.hk
--0-923785102-1142585477=:47719
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 8bit

Hi Kevin,

Thanks for the clarification.

Just that you know, H.248.23 (01/05) is currently stated as "In force" in the ITU-T webpage. Anyhow, if you are going to correct the text, that will be very helpful.

Could you also clarify the following statement?
"The default is no pattern which indicates that the data transmission should not be associated with any signalling."

Does that mean if no pattern parameter is specified, then the CLIP delivery will be the same as using "andisp/data"?

Best Regards,
Tonny

Kevin Boyle <kboyle@nortel.com> ���G
     Comments inline. [KJBII]

 Kevin

   From: Tonny Kung    [mailto:mail2tonny-megaco@yahoo.com.hk] 
Sent: Thursday, March 16,    2006 11:00 AM
To: megaco@ietf.org
Subject: [Megaco]    Question regarding H.248.23 andisp package

Hi all,

I have some questions regarding the use of    andisp/dwa package, hoping someone could clarify it:

1) In section   
 6.3.1.1.2, the description for the pattern parameter for andisp/dwa stated    that "The default is no pattern......" and later stated the default value for    the pattern parameter is "1". How should we interpret this?
[KJBII] It appears    to me that you are referring to the in-progress Amendment to H.248.23    (that may, in fact, become a revision).  The default was added after the    original text was written.  As editor, I will correct this and make    the parameter optional, so that the package will continue to be backwards    compatible to the original definition. Note that the text you reference has    NOT been approved, and so is currently not standard.  The current    definition of this package is in H.248.23 (7/2003) Corrigendum 1    (8/2004).

2) andisp/dwa is stated for both on-hook and    off-hook delivery. And in case of off-hook, then call waiting alert
 will be    generated. As a result the subscriber will hear a "beep" sound (normally). But    since the "cw" signal is of type "Brief", then how would the subsequent "beep"    be generated? I suppose the MGC should send down "alert/cw" for ever    subsequent "beep"?
[KJBII] Successive playout of call wait tones are separate    invocations of that tone.  There are scenarios in which some    instances require retransmission of the data on the second (or other    subsequent) call wait tone.  In some other scenarios this does not    happen.  This, plus the fact that there is a significant time between the    call wait tones, makes it fairly plain that the MGC must send alert/cw or    andisp/dwa  for each individual tone    invocation. 

Best Regards,
Tonny

_______________________________________
 YM - ���u�T��

 �N��A�S���W���A�A���B�ͤ��i�H�d�U�T�����A�A���A�W���ɴN��ߧY�ݨ�A���󻡸ܳ��N�����C
 http://messenger.yahoo.com.hk
--0-923785102-1142585477=:47719--

--===============1223323987==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1223323987==--

From megaco-bounces@ietf.org Fri Mar 17 10:26:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKGq3-0005P2-Kx; Fri, 17 Mar 2006 10:26:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKGq2-0005Ox-Af
	for megaco@ietf.org; Fri, 17 Mar 2006 10:26:02 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKGq1-0002Kp-00
	for megaco@ietf.org; Fri, 17 Mar 2006 10:26:02 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2HFPwp27729
	for ; Fri, 17 Mar 2006 10:25:58 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: ??: RE: [Megaco] Question regarding H.248.23 andisp package
Date: Fri, 17 Mar 2006 10:25:31 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40751DF0D@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ??: RE: [Megaco] Question regarding H.248.23 andisp package
Thread-Index: AcZJn/dApL8PxIphQImwNpxm9IMaBwANrUYA
From: "Kevin Boyle" 
To: , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

You are correct about the document in force.  I had forgotten that we
revised H.248.23 near the end of 2004 -- and hadn't added it to my
repository of documents.  I will still ensure that the conflict is
corrected.

Yes, if the pattern parameter is omitted, there is no alerting.  There
could be some better wording there as well.  I will ensure that also
gets clarified.

Kevin

________________________________

	From: Tonny Kung [mailto:mail2tonny-megaco@yahoo.com.hk] 
	Sent: Friday, March 17, 2006 3:51 AM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; mail2tonny-megaco@yahoo.com.
hk; megaco@ietf.org
	Subject: ??: RE: [Megaco] Question regarding H.248.23 andisp
package

	Hi Kevin,

	Thanks for the clarification.

	Just that you know, H.248.23 (01/05) is currently stated as "In
force" in the ITU-T webpage. Anyhow, if you are going to correct the
text, that will be very helpful.

	Could you also clarify the following statement?
	"The default is no pattern which indicates that the data
transmission should not be associated with any signalling."

	Does that mean if no pattern parameter is specified, then the
CLIP delivery will be the same as using "andisp/data"?

	Best Regards,
	Tonny

	Kevin Boyle  �f�� 

		Comments inline. [KJBII]

		Kevin

________________________________

			From: Tonny Kung
[mailto:mail2tonny-megaco@yahoo.com.hk] 
			Sent: Thursday, March 16, 2006 11:00 AM
			To: megaco@ietf.org
			Subject: [Megaco] Question regarding H.248.23
andisp package

			Hi all,

			I have some questions regarding the use of
andisp/dwa package, hoping someone could clarify it:

			1) In section ! 6.3.1.1.2, the description for
the pattern parameter for andisp/dwa stated that "The default is no
pattern......" and later stated the default value for the pattern
parameter is "1". How should we interpret this?
			[KJBII] It appears to me that you are referring
to the in-progress Amendment to H.248.23 (that may, in fact, become a
revision).  The default was added after the original text was written.
As editor, I will correct this and make the parameter optional, so that
the package will continue to be backwards compatible to the original
definition. Note that the text you reference has NOT been approved, and
so is currently not standard.  The current definition of this package is
in H.248.23 (7/2003) Corrigendum 1 (8/2004).

			2) andisp/dwa is stated for both on-hook and
off-hook delivery. And in case of off-hook, then call waiting! alert
will be generated. As a result the subscriber will hear a "beep" sound
(normally). But since the "cw" signal is of type "Brief", then how would
the subsequent "beep" be generated? I suppose the MGC should send down
"alert/cw" for ever subsequent "beep"?
			[KJBII] Successive playout of call wait tones
are separate invocations of that tone.  There are scenarios in which
some instances require retransmission of the data on the second (or
other subsequent) call wait tone.  In some other scenarios this does not
happen.  This, plus the fact that there is a significant time between
the call wait tones, makes it fairly plain that the MGC must send
alert/cw or andisp/dwa  for each individual tone invocation. 

			Best Regards,
			Tonny

	_______________________________________
	YM - �x��Ӎ? ?br> ������]���ϾW����������Կ�������ӍϢ�o�㣬��
���ϾW�r���������������κ��fԒ������ʧ��
	http://messenger.yahoo.com.hk

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

From megaco-bounces@ietf.org Fri Mar 17 11:10:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHWl-0006tz-6W; Fri, 17 Mar 2006 11:10:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHWk-0006nb-3s
	for megaco@ietf.org; Fri, 17 Mar 2006 11:10:10 -0500
Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHWi-0003tv-6V
	for megaco@ietf.org; Fri, 17 Mar 2006 11:10:09 -0500
Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan
	Messaging Security Suite; Fri, 17 Mar 2006 18:12:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: ??: RE: [Megaco] Question regarding H.248.23 andisp package
Date: Fri, 17 Mar 2006 18:11:24 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ??: RE: [Megaco] Question regarding H.248.23 andisp package
Thread-Index: AcZJn/dApL8PxIphQImwNpxm9IMaBwANrUYAAAGi2oA=
From: "Nurit Shenhar" 
To: "Kevin Boyle" , ,

X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0359092187=="
Errors-To: megaco-bounces@ietf.org

--===============0359092187==
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

S2V2aW4NCg0KSXQgbWlnaHQgYmUgdG9vIGxhdGUgYXQgdGhpcyBzdGFnZSB0byBjb21tZW50LCBi
dXQgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2h5IHRoZSBwYXR0ZXJuIHBhcmFtZXRlciB3
YXMgbWFkZSBvcHRpb25hbC4gSWYgd2UgZG8gbm90IHdhbnQgdG8gYWxlcnQsIHRoZXJlIGlzIHRo
ZSBkYXRhIHNpZ25hbC4NCg0KTnVyaXQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IEtldmluIEJveWxlIFttYWlsdG86a2JveWxlQG5vcnRlbC5jb21dIA0KU2VudDogRnJpZGF5
LCBNYXJjaCAxNywgMjAwNiA1OjI2IFBNDQpUbzogbWFpbDJ0b25ueS1tZWdhY29AeWFob28uY29t
LmhrOyBtZWdhY29AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiA/PzogUkU6IFtNZWdhY29dIFF1ZXN0
aW9uIHJlZ2FyZGluZyBILjI0OC4yMyBhbmRpc3AgcGFja2FnZQ0KDQpZb3UgYXJlIGNvcnJlY3Qg
YWJvdXQgdGhlIGRvY3VtZW50IGluIGZvcmNlLiAgSSBoYWQgZm9yZ290dGVuIHRoYXQgd2UNCnJl
dmlzZWQgSC4yNDguMjMgbmVhciB0aGUgZW5kIG9mIDIwMDQgLS0gYW5kIGhhZG4ndCBhZGRlZCBp
dCB0byBteQ0KcmVwb3NpdG9yeSBvZiBkb2N1bWVudHMuICBJIHdpbGwgc3RpbGwgZW5zdXJlIHRo
YXQgdGhlIGNvbmZsaWN0IGlzDQpjb3JyZWN0ZWQuDQogDQpZZXMsIGlmIHRoZSBwYXR0ZXJuIHBh
cmFtZXRlciBpcyBvbWl0dGVkLCB0aGVyZSBpcyBubyBhbGVydGluZy4gIFRoZXJlDQpjb3VsZCBi
ZSBzb21lIGJldHRlciB3b3JkaW5nIHRoZXJlIGFzIHdlbGwuICBJIHdpbGwgZW5zdXJlIHRoYXQg
YWxzbw0KZ2V0cyBjbGFyaWZpZWQuDQogDQpLZXZpbg0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCglGcm9tOiBUb25ueSBLdW5nIFttYWlsdG86bWFpbDJ0b25ueS1tZWdh
Y29AeWFob28uY29tLmhrXSANCglTZW50OiBGcmlkYXksIE1hcmNoIDE3LCAyMDA2IDM6NTEgQU0N
CglUbzogQm95bGUsIEtldmluIFtOQ1JUUDozWjQwOkVYQ0hdOyBtYWlsMnRvbm55LW1lZ2Fjb0B5
YWhvby5jb20uDQpoazsgbWVnYWNvQGlldGYub3JnDQoJU3ViamVjdDogPz86IFJFOiBbTWVnYWNv
XSBRdWVzdGlvbiByZWdhcmRpbmcgSC4yNDguMjMgYW5kaXNwDQpwYWNrYWdlDQoJDQoJDQoJSGkg
S2V2aW4sDQoJDQoJVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCgkNCglKdXN0IHRoYXQg
eW91IGtub3csIEguMjQ4LjIzICgwMS8wNSkgaXMgY3VycmVudGx5IHN0YXRlZCBhcyAiSW4NCmZv
cmNlIiBpbiB0aGUgSVRVLVQgd2VicGFnZS4gQW55aG93LCBpZiB5b3UgYXJlIGdvaW5nIHRvIGNv
cnJlY3QgdGhlDQp0ZXh0LCB0aGF0IHdpbGwgYmUgdmVyeSBoZWxwZnVsLg0KCQ0KCUNvdWxkIHlv
dSBhbHNvIGNsYXJpZnkgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ/DQoJIlRoZSBkZWZhdWx0IGlz
IG5vIHBhdHRlcm4gd2hpY2ggaW5kaWNhdGVzIHRoYXQgdGhlIGRhdGENCnRyYW5zbWlzc2lvbiBz
aG91bGQgbm90IGJlIGFzc29jaWF0ZWQgd2l0aCBhbnkgc2lnbmFsbGluZy4iDQoJDQoJRG9lcyB0
aGF0IG1lYW4gaWYgbm8gcGF0dGVybiBwYXJhbWV0ZXIgaXMgc3BlY2lmaWVkLCB0aGVuIHRoZQ0K
Q0xJUCBkZWxpdmVyeSB3aWxsIGJlIHRoZSBzYW1lIGFzIHVzaW5nICJhbmRpc3AvZGF0YSI/DQoJ
DQoJQmVzdCBSZWdhcmRzLA0KCVRvbm55DQoJDQoJDQoJS2V2aW4gQm95bGUgPGtib3lsZUBub3J0
ZWwuY29tPiDDlWbCo8K6IA0KDQoJCUNvbW1lbnRzIGlubGluZS4gW0tKQklJXQ0KCQkgDQoJCUtl
dmluDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCQkJRnJvbTogVG9u
bnkgS3VuZw0KW21haWx0bzptYWlsMnRvbm55LW1lZ2Fjb0B5YWhvby5jb20uaGtdIA0KCQkJU2Vu
dDogVGh1cnNkYXksIE1hcmNoIDE2LCAyMDA2IDExOjAwIEFNDQoJCQlUbzogbWVnYWNvQGlldGYu
b3JnDQoJCQlTdWJqZWN0OiBbTWVnYWNvXSBRdWVzdGlvbiByZWdhcmRpbmcgSC4yNDguMjMNCmFu
ZGlzcCBwYWNrYWdlDQoJCQkNCgkJCQ0KCQkJSGkgYWxsLA0KCQkJDQoJCQlJIGhhdmUgc29tZSBx
dWVzdGlvbnMgcmVnYXJkaW5nIHRoZSB1c2Ugb2YNCmFuZGlzcC9kd2EgcGFja2FnZSwgaG9waW5n
IHNvbWVvbmUgY291bGQgY2xhcmlmeSBpdDoNCgkJCQ0KCQkJMSkgSW4gc2VjdGlvbiAhIDYuMy4x
LjEuMiwgdGhlIGRlc2NyaXB0aW9uIGZvcg0KdGhlIHBhdHRlcm4gcGFyYW1ldGVyIGZvciBhbmRp
c3AvZHdhIHN0YXRlZCB0aGF0ICJUaGUgZGVmYXVsdCBpcyBubw0KcGF0dGVybi4uLi4uLiIgYW5k
IGxhdGVyIHN0YXRlZCB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgdGhlIHBhdHRlcm4NCnBhcmFtZXRl
ciBpcyAiMSIuIEhvdyBzaG91bGQgd2UgaW50ZXJwcmV0IHRoaXM/DQoJCQlbS0pCSUldIEl0IGFw
cGVhcnMgdG8gbWUgdGhhdCB5b3UgYXJlIHJlZmVycmluZw0KdG8gdGhlIGluLXByb2dyZXNzIEFt
ZW5kbWVudCB0byBILjI0OC4yMyAodGhhdCBtYXksIGluIGZhY3QsIGJlY29tZSBhDQpyZXZpc2lv
bikuICBUaGUgZGVmYXVsdCB3YXMgYWRkZWQgYWZ0ZXIgdGhlIG9yaWdpbmFsIHRleHQgd2FzIHdy
aXR0ZW4uDQpBcyBlZGl0b3IsIEkgd2lsbCBjb3JyZWN0IHRoaXMgYW5kIG1ha2UgdGhlIHBhcmFt
ZXRlciBvcHRpb25hbCwgc28gdGhhdA0KdGhlIHBhY2thZ2Ugd2lsbCBjb250aW51ZSB0byBiZSBi
YWNrd2FyZHMgY29tcGF0aWJsZSB0byB0aGUgb3JpZ2luYWwNCmRlZmluaXRpb24uIE5vdGUgdGhh
dCB0aGUgdGV4dCB5b3UgcmVmZXJlbmNlIGhhcyBOT1QgYmVlbiBhcHByb3ZlZCwgYW5kDQpzbyBp
cyBjdXJyZW50bHkgbm90IHN0YW5kYXJkLiAgVGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGlz
IHBhY2thZ2UgaXMNCmluIEguMjQ4LjIzICg3LzIwMDMpIENvcnJpZ2VuZHVtIDEgKDgvMjAwNCku
DQoJCQkNCgkJCTIpIGFuZGlzcC9kd2EgaXMgc3RhdGVkIGZvciBib3RoIG9uLWhvb2sgYW5kDQpv
ZmYtaG9vayBkZWxpdmVyeS4gQW5kIGluIGNhc2Ugb2Ygb2ZmLWhvb2ssIHRoZW4gY2FsbCB3YWl0
aW5nISBhbGVydA0Kd2lsbCBiZSBnZW5lcmF0ZWQuIEFzIGEgcmVzdWx0IHRoZSBzdWJzY3JpYmVy
IHdpbGwgaGVhciBhICJiZWVwIiBzb3VuZA0KKG5vcm1hbGx5KS4gQnV0IHNpbmNlIHRoZSAiY3ci
IHNpZ25hbCBpcyBvZiB0eXBlICJCcmllZiIsIHRoZW4gaG93IHdvdWxkDQp0aGUgc3Vic2VxdWVu
dCAiYmVlcCIgYmUgZ2VuZXJhdGVkPyBJIHN1cHBvc2UgdGhlIE1HQyBzaG91bGQgc2VuZCBkb3du
DQoiYWxlcnQvY3ciIGZvciBldmVyIHN1YnNlcXVlbnQgImJlZXAiPw0KCQkJW0tKQklJXSBTdWNj
ZXNzaXZlIHBsYXlvdXQgb2YgY2FsbCB3YWl0IHRvbmVzDQphcmUgc2VwYXJhdGUgaW52b2NhdGlv
bnMgb2YgdGhhdCB0b25lLiAgVGhlcmUgYXJlIHNjZW5hcmlvcyBpbiB3aGljaA0Kc29tZSBpbnN0
YW5jZXMgcmVxdWlyZSByZXRyYW5zbWlzc2lvbiBvZiB0aGUgZGF0YSBvbiB0aGUgc2Vjb25kIChv
cg0Kb3RoZXIgc3Vic2VxdWVudCkgY2FsbCB3YWl0IHRvbmUuICBJbiBzb21lIG90aGVyIHNjZW5h
cmlvcyB0aGlzIGRvZXMgbm90DQpoYXBwZW4uICBUaGlzLCBwbHVzIHRoZSBmYWN0IHRoYXQgdGhl
cmUgaXMgYSBzaWduaWZpY2FudCB0aW1lIGJldHdlZW4NCnRoZSBjYWxsIHdhaXQgdG9uZXMsIG1h
a2VzIGl0IGZhaXJseSBwbGFpbiB0aGF0IHRoZSBNR0MgbXVzdCBzZW5kDQphbGVydC9jdyBvciBh
bmRpc3AvZHdhICBmb3IgZWFjaCBpbmRpdmlkdWFsIHRvbmUgaW52b2NhdGlvbi4gDQoJCQkNCgkJ
CUJlc3QgUmVnYXJkcywNCgkJCVRvbm55DQoJCQkNCgkJCQ0KDQoNCglfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCglZTSAtIMOreMK+4oKsw5PCjT8gP2JyPiDCvsONw4vD
o8OEw6PigLpdw5PDkMOJw4/CvlfCo8Ksw4TDo8K1w4TDhcOzw5PDkcOIw5TCv8OJw5LDlMOBw7TD
j8OCw5PCjcOPwqLCvW/DhMOjwqPCrMKu4oCdDQrDhMOjw4nDj8K+V+KAonLCvsONw4TDnMOBwqLC
vMK0wr/CtMK1wr3Co8Ksw4jDjsK6w47DlWbDlOKAmcK2wrzGksOTw5fDn8OKwqfCocKjDQoJaHR0
cDovL21lc3Nlbmdlci55YWhvby5jb20uaGsNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpNZWdhY28gbWFpbGluZyBsaXN0DQpNZWdhY29AaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lZ2Fjbw0K

--===============0359092187==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0359092187==--

From megaco-bounces@ietf.org Fri Mar 17 11:36:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKHw2-00059H-IW; Fri, 17 Mar 2006 11:36:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FKHw0-00059C-Um
	for megaco@ietf.org; Fri, 17 Mar 2006 11:36:16 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKHvz-0004uB-IG
	for megaco@ietf.org; Fri, 17 Mar 2006 11:36:16 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2HGaDp05472
	for ; Fri, 17 Mar 2006 11:36:13 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: ??: RE: [Megaco] Question regarding H.248.23 andisp package
Date: Fri, 17 Mar 2006 11:36:17 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40751E0D1@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ??: RE: [Megaco] Question regarding H.248.23 andisp package
Thread-Index: AcZJn/dApL8PxIphQImwNpxm9IMaBwANrUYAAAGi2oAAANEmoA==
From: "Kevin Boyle" 
To: "Nurit Shenhar" , , 

X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

It was made optional at the time to define a behavior when the parameter
was omitted.  This was one of the earlier packages defined, and the
collective experience in what was good and not-so-good in package design
was pretty small.  Given it to do all over again, I would have made this
a mandatory parameter.  However, given that the package was originally
defined six years ago, it will be difficult to change this now.

That being said, I will solicit the opinions of the delegates at the
Q3/16 meeting next month.

Kevin 

-----Original Message-----
From: Nurit Shenhar [mailto:NuritS@audiocodes.com] 
Sent: Friday, March 17, 2006 11:11 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; mail2tonny-megaco@yahoo.com.hk;
megaco@ietf.org
Subject: RE: ??: RE: [Megaco] Question regarding H.248.23 andisp package

Kevin

It might be too late at this stage to comment, but I am not sure I
understand why the pattern parameter was made optional. If we do not
want to alert, there is the data signal.

Nurit

-----Original Message-----
From: Kevin Boyle [mailto:kboyle@nortel.com]
Sent: Friday, March 17, 2006 5:26 PM
To: mail2tonny-megaco@yahoo.com.hk; megaco@ietf.org
Subject: RE: ??: RE: [Megaco] Question regarding H.248.23 andisp package

You are correct about the document in force.  I had forgotten that we
revised H.248.23 near the end of 2004 -- and hadn't added it to my
repository of documents.  I will still ensure that the conflict is
corrected.

Yes, if the pattern parameter is omitted, there is no alerting.  There
could be some better wording there as well.  I will ensure that also
gets clarified.

Kevin

________________________________

	From: Tonny Kung [mailto:mail2tonny-megaco@yahoo.com.hk] 
	Sent: Friday, March 17, 2006 3:51 AM
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; mail2tonny-megaco@yahoo.com.
hk; megaco@ietf.org
	Subject: ??: RE: [Megaco] Question regarding H.248.23 andisp
package

	Hi Kevin,

	Thanks for the clarification.

	Just that you know, H.248.23 (01/05) is currently stated as "In
force" in the ITU-T webpage. Anyhow, if you are going to correct the
text, that will be very helpful.

	Could you also clarify the following statement?
	"The default is no pattern which indicates that the data
transmission should not be associated with any signalling."

	Does that mean if no pattern parameter is specified, then the
CLIP delivery will be the same as using "andisp/data"?

	Best Regards,
	Tonny

	Kevin Boyle  Õf£º 

		Comments inline. [KJBII]

		Kevin

________________________________

			From: Tonny Kung
[mailto:mail2tonny-megaco@yahoo.com.hk] 
			Sent: Thursday, March 16, 2006 11:00 AM
			To: megaco@ietf.org
			Subject: [Megaco] Question regarding H.248.23
andisp package

			Hi all,

			I have some questions regarding the use of
andisp/dwa package, hoping someone could clarify it:

			1) In section ! 6.3.1.1.2, the description for
the pattern parameter for andisp/dwa stated that "The default is no
pattern......" and later stated the default value for the pattern
parameter is "1". How should we interpret this?
			[KJBII] It appears to me that you are referring
to the in-progress Amendment to H.248.23 (that may, in fact, become a
revision).  The default was added after the original text was written.
As editor, I will correct this and make the parameter optional, so that
the package will continue to be backwards compatible to the original
definition. Note that the text you reference has NOT been approved, and
so is currently not standard.  The current definition of this package is
in H.248.23 (7/2003) Corrigendum 1 (8/2004).

			2) andisp/dwa is stated for both on-hook and
off-hook delivery. And in case of off-hook, then call waiting! alert
will be generated. As a result the subscriber will hear a "beep" sound
(normally). But since the "cw" signal is of type "Brief", then how would
the subsequent "beep" be generated? I suppose the MGC should send down
"alert/cw" for ever subsequent "beep"?
			[KJBII] Successive playout of call wait tones
are separate invocations of that tone.  There are scenarios in which
some instances require retransmission of the data on the second (or
other subsequent) call wait tone.  In some other scenarios this does not
happen.  This, plus the fact that there is a significant time between
the call wait tones, makes it fairly plain that the MGC must send
alert/cw or andisp/dwa  for each individual tone invocation. 

			Best Regards,
			Tonny

	_______________________________________
	YM - ëx¾€Ó? ?br> ¾ÍËãÄã›]ÓÐÉÏ¾W£¬ÄãµÄÅóÓÑÈÔ¿ÉÒÔÁôÏÂÓÏ¢½oÄã£¬®”
ÄãÉÏ¾W•r¾ÍÄÜÁ¢¼´¿´µ½£¬ÈÎºÎÕfÔ’¶¼ƒÓ×ßÊ§¡£
	http://messenger.yahoo.com.hk

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

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

From megaco-bounces@ietf.org Fri Mar 24 10:32:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMoGg-0007Gx-Oy; Fri, 24 Mar 2006 10:32:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoGf-0007Gm-Kq
	for megaco@ietf.org; Fri, 24 Mar 2006 10:32:01 -0500
Received: from mailrelay2.alcatel.de ([194.113.59.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoGe-0004dM-73
	for megaco@ietf.org; Fri, 24 Mar 2006 10:32:01 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr
	[155.132.182.205])
	by mailrelay2.alcatel.de (8.12.10/8.12.10/ICT TSC MAIL 2005) with ESMTP
	id k2OFMQ3g004966; Fri, 24 Mar 2006 16:22:26 +0100
To: linyangbo@huawei.com
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: 
From: Albrecht.Schwarz@alcatel.de
Date: Fri, 24 Mar 2006 16:22:25 +0100
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 03/24/2006 16:22:26
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: megaco@ietf.org, itu-sg16@external.cisco.com
Subject: [Megaco] COM16-D275: H.248.CCC connection capability control
	Package proposal
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Hi YangboLin,

some thoughts in advance.

Your package proposal has similar aspects as the ETSI TISPAN discussion=
 on
the H.248 Connection Model in Profile ES 283 002 for phy-to-RTP
residential/access gateways.

We studied the subject, too (see ALCATEL view in uploaded TISPAN docs i=
n
the xchange area):

/tsg16/sg16/xchange/wp2/q03
TISPAN WG3_TD22_=A7 5.3 ConnectionModel Phy-to-Phy.doc 24-Mar-2006 15:5=
2
229k
TISPAN WG3_TD23_=A7 5.3 ConnectionModel RTP-to-RTP.doc 24-Mar-2006 15:5=
2
1.9M

Our understanding is, that the autonomous model is illegal wrt H.248.
Therefore I would disagree in considering the controlled and autonomous=

model equally (as in D275).

Our prime concern is, that the MG-autonoumous action in re-directing a
bearer segment (between Ta' and Tb') requires the "correlation of
Termination info" above the Context level.
The aimed functions on bearer connection segments requires firstly
operations on addressing information (plus potentially subsequent routi=
ng
actions).

Bearing this in mind, I cannot imagine that Ta' and Tb' could be physic=
al
Terminations. Would you agree?
Thus, the scope of your capability could be ephemeral Terminations only=
.
Right?
Concerning ephemerals, there are again two main classes:

1) connection-oriented bearers, and
2) connectionless.

Category (1) requires a dedicated bearer control protocol besides GW
control, - autonomous actions on Ta' and Tb' could mean MG-external bea=
rer
control signalling activity. Actions which would question the Package s=
cope
of "MG internal connections". I would therefore exclude category (1) as=

well.

It remains (2): I could only imagine an IP-based ephemeral without any
bearer control protocol (like Q.1970).
If yes, then we are again in the same situation as in the ETSI discussi=
on.

=3D> the "autonomous model" is (if at all) only applicable for IP and r=
elates
to an "MG-embedded IP (edge) router function" (with certain feedback on=

H.248 ...).

The MG-internal redirection of IP bearer connection segments is possibl=
e in
some (exceptional) cases, but there isn't any general applicability IMH=
O,
primarily due to
* IP address/port ranges ("relation to MG capacity")
* multi-homed IP interface
* support of L2VPNs or L3VPNs at MG
* support of multiple IP realms
* ...

Therefore I got some concerns with the approach of a *generic* Package.=

An alternative could be the consideration of different H.248 Connection=

models in Profiles.

Best regards,
Albrecht

=

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

From megaco-bounces@ietf.org Mon Mar 27 10:26:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNtbX-0007LQ-Ku; Mon, 27 Mar 2006 10:26:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FNtbW-0007LI-1H; Mon, 27 Mar 2006 10:26:02 -0500
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FNtbS-00031c-Qe; Mon, 27 Mar 2006 10:26:02 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2RFPwBX025181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 27 Mar 2006 15:25:58 GMT
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1FNtbS-00036r-LJ; Mon, 27 Mar 2006 10:25:58 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: IETF Announcement list 
From: IESG Secretary 
Message-Id: 
Date: Mon, 27 Mar 2006 10:25:58 -0500
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: megaco@ietf.org
Subject: [Megaco] WG Action: Conclusion of Media Gateway Control WG (megaco)
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

The Media Gateway Control WG (megaco) in the Real-time Applications and
Infrastructure Area has concluded.

The IESG contact persons are Jon Peterson and Cullen Jennings. 

The mailing list will remain active.

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

From megaco-bounces@ietf.org Tue Mar 28 00:32:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO6oT-0003kh-9N; Tue, 28 Mar 2006 00:32:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FO6oR-0003kb-IW
	for megaco@ietf.org; Tue, 28 Mar 2006 00:32:15 -0500
Received: from quantum.websiteactive.com ([70.86.207.162])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO6oP-0008SL-NX
	for megaco@ietf.org; Tue, 28 Mar 2006 00:32:15 -0500
Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:11135
	helo=[127.0.0.1])
	by quantum.websiteactive.com with esmtpa (Exim 4.52)
	id 1FO6oM-0006bi-HB
	for megaco@ietf.org; Tue, 28 Mar 2006 16:32:13 +1100
Message-ID: <4428CA51.4050003@nteczone.com>
Date: Tue, 28 Mar 2006 15:32:01 +1000
From: Christian Groves 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco ietf 
Subject: Service State [Fwd: Re: [Megaco] ServiceChange for a single
	termination (Cold Start)]
Content-Type: multipart/mixed; boundary="------------040809060501070207050001"
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - quantum.websiteactive.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.
--------------040809060501070207050001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,

As a follow up of the recent discussion on the default value of Service 
State, I believe this was discussed back in 2002. Please see attached 
email.

Regards, Christian

-------- Original Message --------
Subject: 	Re: [Megaco] ServiceChange for a single termination (Cold Start)
Date: 	Fri, 19 Apr 2002 11:47:18 -0400
From: 	Terry L Anderson 
Organization: 	Lucent Technologies
To: 	Christian Groves 
CC: 	vbajaj@hss.hns.com, Al Varney , megaco@ietf.org
References: 	<65256BA0.00178569.00@sandesh.hss.hns.com> 
<3CBFA31E.D0FB8548@ericsson.com.au>

Christian
Good point.  I missed the relevance of the ServiceState property in 7.1.5.  There is
states that "in service" is default.  While Service State is not defined to be
precisely the same as ServiceChange forced and restart (maybe it should be for a
termination), I agree that this default indicates the intention defaulting to
inservice.  Thus I think that my assumption #1 is the more consistent.  I still think
that the link between ServiceState and ServiceChange for a termination is ambiguous
enough that it would be helpful to restate the assumption in 7.2.8.

I propose we add the following to 7.2.8 at the end of the current Restart entry:

"When applied to ROOT, this specifies that the Media Gateway as a whole will be in
service and includes all its physical terminations which will be in their default
state ("in service").  Exceptions can be indicated by additional ServiceChange
commands."

As Vikas points out, most uses of wildcard ALL assumes that MGC knows the range of
valid terminationIDs for the GW.  Packages have been proposed (but not yet approved)
for MGC to discover this range if it is not known from provisioning.  Sending
individual (non-wildcard) ServiceChange for every distinct physical termination would
be legal but impractical for most large MGs.

Al Varney asked:

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

There has been previous discussions about the applicability of ServiceChange for
ephemerals.  While there is nothing stating that one could not use ServiceChange to
take an ephemeral out of service, but since it would then be subtracted from any
context it was in, it would cease to exist and so could never be "restarted".  Clearly
serviceChange cannot be used to indicate whether an ephemeral Add will succeed or not
(availability of any underlying network or gateway resources).  I think that the
assumption is that if a GW is in service then any ephemeral Add can be attempted.
Failure of an underlying network can be indicated using nt/netfail, but since events
are only set on terminations, one must Add an ephemeral before such an event can be
used.

I think we currently have no good way to announce that the MG is in service but one or
more classes of ephemerals are unavailable.  I think that a specific error to indicate
this after an Add attempt might be sufficient (I don't believe that there is a good
one now).

Christian Groves wrote:

> G'Day Vikas,
>
> I believe you are getting what you asked for. The default state of all
> terminaton is "inservice".
> If the MG cold starts and sends ServiceChange on "ROOT" then the MGC can assume
> that:
> o as the MG is running and
> o a MG contains terminations and
> o the termination's natural state is "inservice"
> therefore the individual terminations are running also.
>
> Regards, Christian
>
> vbajaj@hss.hns.com wrote:
> >
> > Al,
> >        The advantage you have cited below will hold true only under the
> > assumption
> >   that MG sends ServiceChange for individual terminations instead of using a
> > wildcard.
> >   Sending ServiceChange for individual terminations would be too expensive in
> > terms
> >   of network bandwidth as well as MG processing for extremely large sized
> > Gateways.
> >   I would expect that if MGC is interested in finding out configuration
> > inconsistencies
> >   with its MGs, it would do an Audit at lesiure in parallel to handling normal
> > calls.
> >
> >  IMHO, "ServiceChange on ROOT" should indicate all terminations are up at the
> > MG.
> >  ServiceChange for Out Of Service Terminations can be sent subsequently. Total
> > number of messages required in this scenario would be
> > (1 ServiceChange on ROOT + x ServiceChange for configured but unequipped
> > terminations)
> >
> > Even if we go by approach #2 suggested below, the latter step (i.e. sending
> > ServiceChange
> > for Out Of Service Terminations) will anyway have to be executed.
> >  Subsequent to a ServiceChange on ROOT, if MG uses Wildcarded Termination Id
> > to indicate that all terminations in the MG are In Service, it will need to send
> >  Out of Service ServiceChange for those terminations that have been configured
> >  but not hardware equipped. The number of messages required in this scenario
> > would be
> >
> > (1 ServiceChange on ROOT + 1 ServiceChange with Termination Id "*"+ n
> > ServiceChange
> >   for configured but unequipped terminations (Term Id = "/TG!/Fac1/*))
> >
> > The MG may of course choose not to use a wildcarded
> > termination signifiying all terminations on the MG and instead use multiple
> > ServiceChange commands each with a Termination Id (tg1/fac1/*) that siginfies a
> > DS0 aggregation. In this case, the number of ServiceChange commands would equal
> > the number of such DS0 aggregations in the MG i.e. several ServiceChange
> > messages
> >  would be needed to complete the initial MG-MGC startup sequence. The number of
> >  messages required in this scenario would be
> >
> > (1 ServiceChange on ROOT + n ServiceChange for configured and equipped
> > terminations
> >     (Term Id = "/TG!/Fac1/*))
> >
> > {Assuming most of the terminations in MG would be In Service, n could be a large
> > value unless
> >   the MG is intelligent and can optimize on the number of messages}
> >
> > To summarize, IMO that number of (ServiceChange) messages required at startup
> >  would turn out to be larger in approach #2 than in approach #1. So, why not
> > choose
> >  a strategy that is optimal ?
> >
> > Rgds,
> >
> > Vikas Bajaj
> > NGN Group
> > Hughes Software Systems
> > (www.hssworld.com)
> >
> > Al Varney  on 04/19/2002 04:59:53 AM
> >
> > To:   megaco@ietf.org
> > cc:    (bcc: Vikas Bajaj/HSS)
> >
> > Subject:  Re: [Megaco] ServiceChange for a single termination (Cold  Start)
> >
> > At 02:46 PM 4/18/02 -0400, Terry L Anderson wrote:
> > >Possible clarifications:
> > >ServiceChange on ROOT with method=restart (a registration):
> > >1) implies that all physical terminations on MG are also up.  Exceptions
> > >should be indicated by additional ServiceChanges on the down terminations
> > >using Forced, preferrably in the same message and using wildcards where
> > >possible.
> > >2) implies that all physical terminations on MG are down.  Those that are up
> > >will be indicated by additional ServiceChanges on the up terminations using
> > >method=restart, preferrably in the same message and using wildcards were
> > >possible.
> >
> > ...
> >
> > >Even though I think that most GWs probably would not register until all or
> > >most of their physical terminations are available, I would probably prefer
> > >#2 since I can easily indicated them all up with only one additional
> > >ServiceChange and it seems more natural to indicate those up those that are
> > >down.  But I can be happy with either #1 or #2.
> >
> >     #2 has the added (slight?) advantage that physical termination ID
> > mis-matches (between MGC and MG) are identified when the MG sends
> > SVC(restart) on a termination ID unknown to the MGC.  #1 relies on MGC
> > discovering these (non-existent) terminations 1 at a time, when connections
> > are attempted.  With #1, a mis-match of this type might go undetected for
> > days, until the MGC attempted to use/audit that particular termination ID.
> >
> >     Terminations known only to the MGC will still go "undetected", but
> > since no SVC(restart) is ever received for them, at least the MGC would not
> > be trying to use them.  An audit might eventually reveal the reason for the
> > OOS terminations.  (It is not unusual in "old" voice switches to have
> > termination data populated without having the hardware yet in place, so a
> > mis-match cannot be considered an error in all cases.)
> >
> >     Is there an assumption that MG SVC(ROOT,restart) implies the ephemeral
> > interface(s) are all operational?  If it makes sense to positively assert
> > SVC(restart) on physical terminations, why wouldn't it also make sense to
> > indicate availability of ephemeral interfaces?  I'm thinking particularly
> > of MGs with multiple ephemeral interfaces (IP, ATM, etc.).
> >
> >     Assuming a reasonable SVC mechanism with "ranges" exists, #2 is not a
> > big burden after MG restart.  If SVC is needed for every individual
> > physical termination, then #1 becomes attractive.
> >
> > Al Varney
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

--

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

--------------040809060501070207050001
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

Received: from brsf10.epa.ericsson.se ([146.11.8.4]) by
	eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange
	Internet Mail Service Version 5.5.2653.13)
	id JGQQPQC7; Fri, 19 Apr 2002 17:19:38 +1000
Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111])
	by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA23909
	for ;
	Fri, 19 Apr 2002 17:19:39 +1000 (EST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se
	[193.180.251.47])
	by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g3J7I3025495
	for ;
	Fri, 19 Apr 2002 17:18:03 +1000 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP
	id g3J7JOs7015509; Fri, 19 Apr 2002 09:19:24 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se
	[131.160.30.12])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id
	g3J7JOo5012856; Fri, 19 Apr 2002 10:19:24 +0300 (EET DST)
Message-ID: <3CBFC502.D111C101@lmf.ericsson.se>
Date: Fri, 19 Apr 2002 10:19:30 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Groves 
CC: vbajaj@hss.hns.com, Al Varney , megaco@ietf.org
Subject: Re: [Megaco] ServiceChange for a single termination (Cold Start)
References: <65256BA0.00178569.00@sandesh.hss.hns.com>
	<3CBFA31E.D0FB8548@ericsson.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Ok, so assuming that ROOT is enough to indicate that all Terminations are
"in-service", what error code shall the MG use if the MGC tries to use a termination
which still isn't ready to be used (but WILL be in eg 10 seconds)? 503? 521?

Regards,

Christer Holmberg
Ericsson Finland

Christian Groves wrote:

> G'Day Vikas,
>
> I believe you are getting what you asked for. The default state of all
> terminaton is "inservice".
> If the MG cold starts and sends ServiceChange on "ROOT" then the MGC can assume
> that:
> o as the MG is running and
> o a MG contains terminations and
> o the termination's natural state is "inservice"
> therefore the individual terminations are running also.
>
> Regards, Christian
>
> vbajaj@hss.hns.com wrote:
> >
> > Al,
> >        The advantage you have cited below will hold true only under the
> > assumption
> >   that MG sends ServiceChange for individual terminations instead of using a
> > wildcard.
> >   Sending ServiceChange for individual terminations would be too expensive in
> > terms
> >   of network bandwidth as well as MG processing for extremely large sized
> > Gateways.
> >   I would expect that if MGC is interested in finding out configuration
> > inconsistencies
> >   with its MGs, it would do an Audit at lesiure in parallel to handling normal
> > calls.
> >
> >  IMHO, "ServiceChange on ROOT" should indicate all terminations are up at the
> > MG.
> >  ServiceChange for Out Of Service Terminations can be sent subsequently. Total
> > number of messages required in this scenario would be
> > (1 ServiceChange on ROOT + x ServiceChange for configured but unequipped
> > terminations)
> >
> > Even if we go by approach #2 suggested below, the latter step (i.e. sending
> > ServiceChange
> > for Out Of Service Terminations) will anyway have to be executed.
> >  Subsequent to a ServiceChange on ROOT, if MG uses Wildcarded Termination Id
> > to indicate that all terminations in the MG are In Service, it will need to send
> >  Out of Service ServiceChange for those terminations that have been configured
> >  but not hardware equipped. The number of messages required in this scenario
> > would be
> >
> > (1 ServiceChange on ROOT + 1 ServiceChange with Termination Id "*"+ n
> > ServiceChange
> >   for configured but unequipped terminations (Term Id = "/TG!/Fac1/*))
> >
> > The MG may of course choose not to use a wildcarded
> > termination signifiying all terminations on the MG and instead use multiple
> > ServiceChange commands each with a Termination Id (tg1/fac1/*) that siginfies a
> > DS0 aggregation. In this case, the number of ServiceChange commands would equal
> > the number of such DS0 aggregations in the MG i.e. several ServiceChange
> > messages
> >  would be needed to complete the initial MG-MGC startup sequence. The number of
> >  messages required in this scenario would be
> >
> > (1 ServiceChange on ROOT + n ServiceChange for configured and equipped
> > terminations
> >     (Term Id = "/TG!/Fac1/*))
> >
> > {Assuming most of the terminations in MG would be In Service, n could be a large
> > value unless
> >   the MG is intelligent and can optimize on the number of messages}
> >
> > To summarize, IMO that number of (ServiceChange) messages required at startup
> >  would turn out to be larger in approach #2 than in approach #1. So, why not
> > choose
> >  a strategy that is optimal ?
> >
> > Rgds,
> >
> > Vikas Bajaj
> > NGN Group
> > Hughes Software Systems
> > (www.hssworld.com)
> >
> > Al Varney  on 04/19/2002 04:59:53 AM
> >
> > To:   megaco@ietf.org
> > cc:    (bcc: Vikas Bajaj/HSS)
> >
> > Subject:  Re: [Megaco] ServiceChange for a single termination (Cold  Start)
> >
> > At 02:46 PM 4/18/02 -0400, Terry L Anderson wrote:
> > >Possible clarifications:
> > >ServiceChange on ROOT with method=restart (a registration):
> > >1) implies that all physical terminations on MG are also up.  Exceptions
> > >should be indicated by additional ServiceChanges on the down terminations
> > >using Forced, preferrably in the same message and using wildcards where
> > >possible.
> > >2) implies that all physical terminations on MG are down.  Those that are up
> > >will be indicated by additional ServiceChanges on the up terminations using
> > >method=restart, preferrably in the same message and using wildcards were
> > >possible.
> >
> > ...
> >
> > >Even though I think that most GWs probably would not register until all or
> > >most of their physical terminations are available, I would probably prefer
> > >#2 since I can easily indicated them all up with only one additional
> > >ServiceChange and it seems more natural to indicate those up those that are
> > >down.  But I can be happy with either #1 or #2.
> >
> >     #2 has the added (slight?) advantage that physical termination ID
> > mis-matches (between MGC and MG) are identified when the MG sends
> > SVC(restart) on a termination ID unknown to the MGC.  #1 relies on MGC
> > discovering these (non-existent) terminations 1 at a time, when connections
> > are attempted.  With #1, a mis-match of this type might go undetected for
> > days, until the MGC attempted to use/audit that particular termination ID.
> >
> >     Terminations known only to the MGC will still go "undetected", but
> > since no SVC(restart) is ever received for them, at least the MGC would not
> > be trying to use them.  An audit might eventually reveal the reason for the
> > OOS terminations.  (It is not unusual in "old" voice switches to have
> > termination data populated without having the hardware yet in place, so a
> > mis-match cannot be considered an error in all cases.)
> >
> >     Is there an assumption that MG SVC(ROOT,restart) implies the ephemeral
> > interface(s) are all operational?  If it makes sense to positively assert
> > SVC(restart) on physical terminations, why wouldn't it also make sense to
> > indicate availability of ephemeral interfaces?  I'm thinking particularly
> > of MGs with multiple ephemeral interfaces (IP, ATM, etc.).
> >
> >     Assuming a reasonable SVC mechanism with "ranges" exists, #2 is not a
> > big burden after MG restart.  If SVC is needed for every individual
> > physical termination, then #1 becomes attractive.
> >
> > Al Varney
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > Megaco@ietf.org
> > https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

--------------040809060501070207050001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------040809060501070207050001--

From megaco-bounces@ietf.org Tue Mar 28 01:41:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FO7so-0000Ma-6m; Tue, 28 Mar 2006 01:40:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FO7qL-00089t-4e
	for megaco@ietf.org; Tue, 28 Mar 2006 01:38:17 -0500
Received: from quantum.websiteactive.com ([70.86.207.162])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO7gC-0001Zc-Gd
	for megaco@ietf.org; Tue, 28 Mar 2006 01:27:52 -0500
Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:11192
	helo=[127.0.0.1])
	by quantum.websiteactive.com with esmtpa (Exim 4.52)
	id 1FO7g7-0005zN-NC; Tue, 28 Mar 2006 17:27:44 +1100
Message-ID: <4428D759.9060207@nteczone.com>
Date: Tue, 28 Mar 2006 16:27:37 +1000
From: Christian Groves 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco@ietf.org
Subject: Re: [Megaco] WG Action: Conclusion of Media Gateway Control WG
	(megaco)
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - quantum.websiteactive.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Hello all,

Now that the Megaco WG is officially coming to end, i'd like to 
recognise Tom Taylor for his efforts as WG Chair (informal and formal 
roles) over the last 8 years of Megaco. Tom had the uneviable role of 
acting as a circuit breaker between the many conflicting organisations 
in the early Megaco days when the protocol had lots of growing pains.

So thanks Tom for taking on the WG Chair role over the years and oiling 
the wheels to keep Megaco running.

Regards, Christian

IESG Secretary wrote:

>The Media Gateway Control WG (megaco) in the Real-time Applications and
>Infrastructure Area has concluded.
>
>The IESG contact persons are Jon Peterson and Cullen Jennings. 
>
>The mailing list will remain active.
>
>
>_______________________________________________
>Megaco mailing list
>Megaco@ietf.org
>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>  
>

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

From megaco-bounces@ietf.org Tue Mar 28 05:57:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOBtF-0004At-8n; Tue, 28 Mar 2006 05:57:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOBtE-0004Ao-N8
	for megaco@ietf.org; Tue, 28 Mar 2006 05:57:32 -0500
Received: from web8410.mail.in.yahoo.com ([202.43.219.158])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOBtC-0004me-Ri
	for megaco@ietf.org; Tue, 28 Mar 2006 05:57:32 -0500
Received: (qmail 45651 invoked by uid 60001); 28 Mar 2006 10:57:28 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=nbEkri8SIN6jOfrjzESkAvFZVH09nZMKJaEH53UPKiWMWCd5FAgDihMIwz3uugbcNvOKloozQbPgKRPBXEWEtbQ6ahyWOtS+VMBtCarDdBb1y432GCBjbpqSw9n3m1GyWjBoccw3QIXv22fD8Ah2fJLa19X69uRzB4tLPfMVaSw=
	; 
Message-ID: <20060328105728.45649.qmail@web8410.mail.in.yahoo.com>
Received: from [203.129.230.229] by web8410.mail.in.yahoo.com via HTTP;
	Tue, 28 Mar 2006 11:57:28 BST
Date: Tue, 28 Mar 2006 11:57:28 +0100 (BST)
From: ranjani gopalan 
To: megaco@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Subject: [Megaco] Presentation
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1535935412=="
Errors-To: megaco-bounces@ietf.org

--===============1535935412==
Content-Type: multipart/alternative; boundary="0-491041364-1143543448=:41663"
Content-Transfer-Encoding: 8bit

--0-491041364-1143543448=:41663
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi everyone,
  I needed to give a presentation on Megaco. Could someone please help me with it. I needed to know what points do i need to include. Its basically for a master's course that i am doing.
  Thanks in advance

---------------------------------
 Jiyo cricket on Yahoo! India cricket
Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
--0-491041364-1143543448=:41663
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi everyone,
  I needed to give a presentation on Megaco. Could someone please help me with it. I needed to know what points do i need to include. Its basically for a master's course that i am doing.
  Thanks in advance

Jiyo cricket on Yahoo! India cricket

Yahoo! Messenger Mobile Stay in touch with your buddies all the time.
--0-491041364-1143543448=:41663--

--===============1535935412==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1535935412==--

From megaco-bounces@ietf.org Wed Mar 29 19:05:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOkfd-00032c-QU; Wed, 29 Mar 2006 19:05:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOkfc-00032X-Ex
	for megaco@ietf.org; Wed, 29 Mar 2006 19:05:48 -0500
Received: from zcars04e.nortelnetworks.com ([47.129.242.56]
	helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FOkfb-0001jq-3S
	for megaco@ietf.org; Wed, 29 Mar 2006 19:05:48 -0500
Received: from zcarhxs1.corp.nortel.com
	(zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	k2U01I513403
	for ; Wed, 29 Mar 2006 19:01:18 -0500 (EST)
Received: from [127.0.0.1] ([47.130.16.16] RDNS failed) by
	zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 29 Mar 2006 19:05:43 -0500
Message-ID: <442B20D3.4040403@nortel.com>
Date: Wed, 29 Mar 2006 19:05:39 -0500
From: "Tom-PT Taylor" 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Megaco IETF - Mail List (E-mail)" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Mar 2006 00:05:43.0980 (UTC)
	FILETIME=[B04A6EC0:01C6538D]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Megaco] Package numbering conflict
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

IANA has just advised me that a packaging numbering conflict has crept 
into the system. The package number x0097 was accidentally given out to 
both of the following packages:

calltrace, documented in 3GPP TS 29.232

seg, documented in H.248.1 v3 Annex E.

Note that neither document currently states the package number, only 
that it is to be assigned by IANA.

I have advised IANA based on my assessment of the relative probability 
of implementation to give the seg package a new number.

If anyone has concerns, please let me know.

Tom Taylor

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

From megaco-bounces@ietf.org Wed Mar 29 22:45:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOo6A-0005k7-0P; Wed, 29 Mar 2006 22:45:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOo68-0005k1-R5
	for megaco@ietf.org; Wed, 29 Mar 2006 22:45:24 -0500
Received: from quantum.websiteactive.com ([70.86.207.162])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOo68-0003RV-Ht
	for megaco@ietf.org; Wed, 29 Mar 2006 22:45:24 -0500
Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:10136
	helo=[127.0.0.1])
	by quantum.websiteactive.com with esmtpa (Exim 4.52)
	id 1FOo67-0004pj-8P
	for megaco@ietf.org; Thu, 30 Mar 2006 14:45:24 +1100
Message-ID: <442B544A.3020402@nteczone.com>
Date: Thu, 30 Mar 2006 13:45:14 +1000
From: Christian Groves 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco ietf 
Subject: [Fwd: [Fwd: RE: [Megaco] ServiceChange/ Restart question]]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - quantum.websiteactive.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Further information on ServiceState from 2003.

Christian

-------- Original Message --------
Subject: 	RE: [Megaco] ServiceChange/ Restart question
Date: 	Sun, 9 Nov 2003 19:58:08 -0500
From: 	Kevin Boyle 
To: 	Venugopal Sharma , Troy Cauble 
CC: 	MEGACO list 

Not true.  ServiceStates is a parameter on every termination, not just Root.
Further, the spec indicates that the default value for the ServiceStates
parameter is "Inservice".  This means that upon registration, all
terminations are assumed to be inservice.  

The MG can prevent this by sending subsequent SC Forced messages on the
terminations that are out of service.

Kevin

-----Original Message-----
From: Venugopal Sharma [mailto:skolari@cisco.com] 
Sent: Saturday, November 08, 2003 1:40 PM
To: Troy Cauble
Cc: MEGACO list
Subject: Re: [Megaco] ServiceChange/ Restart question

Troy,

I think ROOT termination indicates MG as a whole. In Service and Out of
Service messages are sent only at the MG level and not per terminations.
Hence 'In service' should only indicate that the H248 stack is up and
running in the MG.

thanks / Venu
--------------
Troy Cauble wrote:
> 
> ON STARTUP an MG sends:
> ==========
> 
> MEGACO/1 [192.168.17.217]
> Transaction = 667 {
>    Context = - {
>      ServiceChange = ROOT {
>        Services {
>          Method = Restart
>        }
>      }
>    }
> }
> 
> Does the use of ROOT imply that all terminations are InService?
> 
> If the MG is configured (via SNMP for example) to have some 
> terminations disabled, should it send "Method = Restart" for each 
> enabled termination instead of one for ROOT?  (All in the same 
> Context/Transaction/Message?)
> 
> If so, should it also send "Method = Forced" or "Method = Graceful"
> for the disabled terminations?
> 
> Thanks,
> 
> -troy
> 
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco

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

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

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

From megaco-bounces@ietf.org Wed Mar 29 22:49:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOo9g-00016W-Kp; Wed, 29 Mar 2006 22:49:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOo9f-000152-Fd
	for megaco@ietf.org; Wed, 29 Mar 2006 22:49:03 -0500
Received: from quantum.websiteactive.com ([70.86.207.162])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOo9f-0003a4-6t
	for megaco@ietf.org; Wed, 29 Mar 2006 22:49:03 -0500
Received: from cpe-61-9-144-63.vic.bigpond.net.au ([61.9.144.63]:10137
	helo=[127.0.0.1])
	by quantum.websiteactive.com with esmtpa (Exim 4.52)
	id 1FOo9e-000518-C8
	for megaco@ietf.org; Thu, 30 Mar 2006 14:49:03 +1100
Message-ID: <442B5526.6000009@nteczone.com>
Date: Thu, 30 Mar 2006 13:48:54 +1000
From: Christian Groves 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: megaco ietf 
Content-Type: text/plain; charset=iso-8859-7; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - quantum.websiteactive.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Subject: [Megaco] [Fwd: [Fwd: RE: Service Change ALL]]
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

In 2001 it was understood that the default state is In-Service.

Christian

-------- Original Message --------
Subject: 	RE: Service Change ALL
Date: 	Mon, 16 Apr 2001 11:19:36 -0400
From: 	Madhu Babu Brahmanapally 
To: 	'Mario Monteiro' , 

Hi Mario,

The example shows MG generating the Registration request and its not for a
given termination. If the MGC needs to address all the terminations
irrespective of their existence in context, today it has to generate two
commands (one for active contexts and other for Null contexts)

(Of course even though the protocol doesn't address about this, but I will
be happy to see that) Similar to the way the MG to register all its
terminations uses all the ROOT termination Identifier, the MGC also should
be able to use the ROOT termination to take all terminations out-of-service,
something like

MGC to MG1:
MEGACO/1 [121.121.121.111]
Transaction = 9998{
      Context = - {
            ServiceChange = ROOT {Services   {
                  Method=Forced.
                  ....................................... etc

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Mario Monteiro
Sent: Monday, April 16, 2001 10:20 AM
To: megaco@fore.com
Subject: Service Change ALL

Appendix A.1 shows an example syntax of restarting terminations as
follows:

MG1 to MGC:
MEGACO/1 [124.124.124.222]
Transaction = 9998{
      Context = - {
            ServiceChange = ROOT {Services   {
                  Method=Restart.
                  ....................................... etc

Section 8.1.2 also states...

The MGC may use the ALL wildcard to address all Contexts on the MG. The
null Context is not included when the ALL wildcard is used.

Question is, if  * were used instead of - in the ServiceChange above,
does this mean that only terminations not in the NULL context will be
restarted? In order to restart all MG terminations ( NULL context +
active contexts)  does the ServiceChange have to be issued twice, once
with * and the other with - ?  Or is there another way to do this?

Thanks - Mario

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

From megaco-bounces@ietf.org Thu Mar 30 05:07:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOu3c-0007P8-Ly; Thu, 30 Mar 2006 05:07:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOu3b-0007P3-4X
	for megaco@ietf.org; Thu, 30 Mar 2006 05:07:11 -0500
Received: from mailrelay2.alcatel.de ([194.113.59.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOu3Y-0002rq-Lw
	for megaco@ietf.org; Thu, 30 Mar 2006 05:07:11 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr
	[155.132.182.205])
	by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005)
	with ESMTP id k2UA7759016537; Thu, 30 Mar 2006 12:07:07 +0200
In-Reply-To: <442B5526.6000009@nteczone.com>
Subject: Megaco Discussion Archive Deepth; Re: [Megaco] [Fwd: [Fwd: RE: Service
	Change ALL]]
To: taylor@nortel.com, Christian Groves 
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: 
From: Albrecht.Schwarz@alcatel.de
Date: Thu, 30 Mar 2006 12:07:06 +0200
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 03/30/2006 12:07:07
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: megaco ietf 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Thanks Christian for pointers!

Raises an old question to me about the archive database organization:

My impression is that the deepth is fixed, and limited to 265 files in
directory
www1.ietf.org/mail-archive/web/megaco/current/

Thus, currently the history ends at July 18, 2001.
I'm wondering how I may access the list discussion before?

Is there another archive directory (besides "/current/")?

Thanks
Albrecht

                      Christian Groves                                                                                                 

                      eczone.com>                  cc:                                                                                 
                                                   Subject: [Megaco] [Fwd: [Fwd: RE: Service Change ALL]]                              
                      30.03.2006 05:48                                                                                                 

In 2001 it was understood that the default state is In-Service.

Christian

-------- Original Message --------
Subject:           RE: Service Change ALL
Date:              Mon, 16 Apr 2001 11:19:36 -0400
From:              Madhu Babu Brahmanapally 
To:          'Mario Monteiro' ,

Hi Mario,

The example shows MG generating the Registration request and its not for a
given termination. If the MGC needs to address all the terminations
irrespective of their existence in context, today it has to generate two
commands (one for active contexts and other for Null contexts)

(Of course even though the protocol doesn't address about this, but I will
be happy to see that) Similar to the way the MG to register all its
terminations uses all the ROOT termination Identifier, the MGC also should
be able to use the ROOT termination to take all terminations
out-of-service,
something like

MGC to MG1:
MEGACO/1 [121.121.121.111]
Transaction = 9998{
      Context = - {
            ServiceChange = ROOT {Services   {
                  Method=Forced.
                  ....................................... etc

Regards
Madhubabu

-----Original Message-----
From: owner-megaco@pit.comms.marconi.com
[mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Mario Monteiro
Sent: Monday, April 16, 2001 10:20 AM
To: megaco@fore.com
Subject: Service Change ALL

Appendix A.1 shows an example syntax of restarting terminations as
follows:

MG1 to MGC:
MEGACO/1 [124.124.124.222]
Transaction = 9998{
      Context = - {
            ServiceChange = ROOT {Services   {
                  Method=Restart.
                  ....................................... etc

Section 8.1.2 also states...

The MGC may use the ALL wildcard to address all Contexts on the MG. The
null Context is not included when the ALL wildcard is used.

Question is, if  * were used instead of - in the ServiceChange above,
does this mean that only terminations not in the NULL context will be
restarted? In order to restart all MG terminations ( NULL context +
active contexts)  does the ServiceChange have to be issued twice, once
with * and the other with - ?  Or is there another way to do this?

Thanks - Mario

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

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

From megaco-bounces@ietf.org Thu Mar 30 07:15:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOw3N-00006H-6t; Thu, 30 Mar 2006 07:15:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOw3M-00006C-4j
	for megaco@ietf.org; Thu, 30 Mar 2006 07:15:04 -0500
Received: from web38502.mail.mud.yahoo.com ([209.191.125.48])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOw3L-0000Dn-SC
	for megaco@ietf.org; Thu, 30 Mar 2006 07:15:04 -0500
Received: (qmail 72125 invoked by uid 60001); 30 Mar 2006 12:15:03 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=tgspvpdvHUfOLR5bZXnFq0CI+88AG7fuFY7yDqrDwwF82wJ6fk5ZhSrYnRbhAFqtgqV/+KrqTERnC44QSfqbMobh1QxBbolwRPOlqJO3P2/gwrapcXgCxqIETUm8WJbm7jTKzGYEZrg6CX+qZp931mw86KiHl8F6NfU17I1YZl4=
	; 
Message-ID: <20060330121503.72123.qmail@web38502.mail.mud.yahoo.com>
Received: from [212.123.193.10] by web38502.mail.mud.yahoo.com via HTTP;
	Thu, 30 Mar 2006 04:15:03 PST
Date: Thu, 30 Mar 2006 04:15:03 -0800 (PST)
From: Hans vandermaarel 
To: megaco@ietf.org
MIME-Version: 1.0
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [Megaco] H.223/H.324m on H248
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============1854743096=="
Errors-To: megaco-bounces@ietf.org

--===============1854743096==
Content-Type: multipart/alternative; boundary="0-837629070-1143720903=:71527"
Content-Transfer-Encoding: 8bit

--0-837629070-1143720903=:71527
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi All,

  Reading the ITU standards I get the impression that it's mandatory to implement H.248.12 for a H.324m or H323 Media Gateway. At the same time I get the feeling that the MGC implementations can't be compatible with any of such implementations as the standard seems quite open in terms of options and ways to handle things.

  I also wondered why one needs H.248.12 at all. I would expect one need not inform the MGC on all itty bitty detail in the H245 protocol. I would expect it is sufficient to inform a MGC on events that alter the codec preferences.

  E.g. a MG which can internally do transcoding of audio and video will start using H.263 with AMR/G.711 as prefered local codecs. By the time it receives a CapabilityExchange it would just send an event telling the MGC to Modify the codecs. The MG could in the response answer it's new preferences.

  Any opinions would be appreciated,

  Hans van der Maarel

---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.
--0-837629070-1143720903=:71527
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi All,

  Reading the ITU standards I get the impression that it's mandatory to implement H.248.12 for a H.324m or H323 Media Gateway. At the same time I get the feeling that the MGC implementations can't be compatible with any of such implementations as the standard seems quite open in terms of options and ways to handle things.

  I also wondered why one needs H.248.12 at all. I would expect one need not inform the MGC on all itty bitty detail in the H245 protocol. I would expect it is sufficient to inform a MGC on events that alter the codec preferences.

  E.g. a MG which can internally do transcoding of audio and video will start using H.263 with AMR/G.711 as prefered local codecs. By the time it receives a CapabilityExchange it would just send an event telling the MGC to Modify the codecs. The MG could in the response answer it's new preferences.

  Any opinions
 would be appreciated,

  Hans van der Maarel

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.
--0-837629070-1143720903=:71527--

--===============1854743096==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1854743096==--

From megaco-bounces@ietf.org Thu Mar 30 08:04:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOwoi-0002oM-VA; Thu, 30 Mar 2006 08:04:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOwoh-0002oH-1x
	for megaco@ietf.org; Thu, 30 Mar 2006 08:03:59 -0500
Received: from mailrelay2.alcatel.de ([194.113.59.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOwog-0002bC-Kb
	for megaco@ietf.org; Thu, 30 Mar 2006 08:03:59 -0500
Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr
	[155.132.182.205])
	by mailrelay2.alcatel.de (8.12.11.20060308/8.12.11/ICT TSC MAIL 2005)
	with ESMTP id k2UD3uLE020102; Thu, 30 Mar 2006 15:03:56 +0200
In-Reply-To: <20060330121503.72123.qmail@web38502.mail.mud.yahoo.com>
Subject: Re: [Megaco] H.223/H.324m on H.248
To: Hans vandermaarel 
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: 
From: Albrecht.Schwarz@alcatel.de
Date: Thu, 30 Mar 2006 15:03:55 +0200
X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 03/30/2006 15:03:56
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.49 on 149.204.45.73
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: megaco@ietf.org
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

I guess that the basic question is, which "capability set" of H.245 sho=
uld
be terminated on the MG, and which on the MGC ("the ratio might be in
theory between 0 ...100%).

H.248.12 was originally designed from H.323 perspective, e.g., interwor=
king
scenarios like to H.324 in my understanding.
Neither the consideration of H.324m, SIP or 3G-324m was the main scope
then.

Guess your motivation is current 3GPP R7 discussion, thus an H.225.0-le=
ss
network application (because of RANAP/BICC in CS domain and SIP in PS
domain). I believe that it's worth to cross-check again the two H.248.1=
2
Packages from that specific 3G-324m point of view.

Albrecht

                                                                       =
                                                              =20
                      Hans                                             =
                                                              =20
                      vandermaarel             To:      megaco@ietf.org=
                                                              =20
                                    Subject: [Megaco] H.223/=
H.324m on H248                                                =20
                                                                       =
                                                              =20
                      30.03.2006 14:15                                 =
                                                              =20
                                                                       =
                                                              =20

Hi All,

Reading the ITU standards I get the impression that it's mandatory to
implement H.248.12 for a H.324m or H323 Media Gateway. At the same time=
 I
get the feeling that the MGC implementations can't be compatible with a=
ny
of such implementations as the standard seems quite open in terms of
options and ways to handle things.

I also wondered why one needs H.248.12 at all. I would expect one need =
not
inform the MGC on all itty bitty detail in the H245 protocol. I would
expect it is sufficient to inform a MGC on events that alter the codec
preferences.

E.g. a MG which can internally do transcoding of audio and video will s=
tart
using H.263 with AMR/G.711 as prefered local codecs. By the time it
receives a CapabilityExchange it would just send an event telling the M=
GC
to Modify the codecs. The MG could in the response answer it's new
preferences.

Any! opinions would be appreciated,

Hans van der Maarel

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great ra=
tes
starting at 1=A2/min._______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

=

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

From megaco-bounces@ietf.org Thu Mar 30 10:20:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOyxG-0004jc-K1; Thu, 30 Mar 2006 10:20:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyxF-0004hn-DI
	for megaco@ietf.org; Thu, 30 Mar 2006 10:20:57 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOyxE-0001CM-Rr
	for megaco@ietf.org; Thu, 30 Mar 2006 10:20:57 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	491D14F0001
	for ; Thu, 30 Mar 2006 17:20:56 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 30 Mar 2006 17:20:56 +0200
Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 30 Mar 2006 17:20:56 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 30 Mar 2006 17:20:55 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Context Id  in reply for failed Add
thread-index: AcZUDYnirp/5LmJCSyiCa2aWIs/xlQ==
From: "Julio Martinez-Minguito \(AL/EAB\)"

To: 
X-OriginalArrivalTime: 30 Mar 2006 15:20:56.0017 (UTC)
	FILETIME=[8A6A5410:01C6540D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Subject: [Megaco] Context Id  in reply for failed Add
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0316446691=="
Errors-To: megaco-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0316446691==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6540D.8A193A5B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6540D.8A193A5B
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi:

If we have request for a new context like:

T=3D1{C=3D${Add=3Dtermination{Media{LocalControl{Mode=3Dinactive}}}}}

And for any reason the add command fails, what shall be the context Id
in the reply: '$',  specific or any of them?
Does it make any difference?

If the reply is=20

P=3D1{C=3D1{Add=3Dtermination{Error =3D 430}}}

The controller does not need to subtract the context 1, because the only
command in the request failed, does it?
If the controller request to subtract C=3D1, that would be an error from
the controller, wouldn't?

They said that to avoid the controller from sending a subtract, the
context id in the reply shall be '$'. But I think that the controller
shall not send the subtract even if the context id is an specific value.

Regards, Julio

------_=_NextPart_001_01C6540D.8A193A5B
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Context Id  in reply for failed Add

Hi:

If we have request =
for a new context like:

T=3D1{C=3D${Add=3Dtermination{Media{LocalControl{Mode=3Din=
active}}}}}

And for any reason =
the add command fails, what shall be the context Id in the reply: =
'$',  specific or any of them?

Does it make any =
difference?

If the reply is =

P=3D1{C=3D1{Add=3Dtermination{Error =3D =
430}}}

The controller =
does not need to subtract the context 1, because the only command in the =
request failed, does it?

If the controller =
request to subtract C=3D1, that would be an error from the controller, =
wouldn't?

They said that to =
avoid the controller from sending a subtract, the context id in the =
reply shall be '$'. But I think that the controller shall not send the =
subtract even if the context id is an specific value.

Regards, =
Julio

------_=_NextPart_001_01C6540D.8A193A5B--

--===============0316446691==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0316446691==--

From megaco-bounces@ietf.org Thu Mar 30 11:01:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FOzaS-0003oz-CC; Thu, 30 Mar 2006 11:01:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FOzaQ-0003of-GS
	for megaco@ietf.org; Thu, 30 Mar 2006 11:01:26 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOzaP-0003E3-6h
	for megaco@ietf.org; Thu, 30 Mar 2006 11:01:26 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2UG1Mu24080
	for ; Thu, 30 Mar 2006 11:01:23 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Context Id  in reply for failed Add
Date: Thu, 30 Mar 2006 11:01:11 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA40790B038@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Context Id  in reply for failed Add
Thread-Index: AcZUDYnirp/5LmJCSyiCa2aWIs/xlQABRnrQ
From: "Kevin Boyle" 
To: "Julio Martinez-Minguito \(AL/EAB\)"
	, 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

If a context cannot exist without terminations, and the initial command
to add a termination to the context failed, then the context does not
exist, right?  In that case, how can a non-existent context have an
identifier?

The context does not exist until the termination is actually placed in
it.  Because this never happened, the context never came into existence
and thus could never have received a ContextID.  Therefore, the MG
should echo back the ContextID it received (C=$).  Anything else would
indicate that a context does exist, which would be non-compliant, and
the responsibility of the MGC to clean up.

Kevin

________________________________

	From: Julio Martinez-Minguito (AL/EAB)
[mailto:julio.martinez-minguito@ericsson.com] 
	Sent: Thursday, March 30, 2006 10:21 AM
	To: megaco@ietf.org
	Subject: [Megaco] Context Id in reply for failed Add

	Hi: 

	If we have request for a new context like: 

	T=1{C=${Add=termination{Media{LocalControl{Mode=inactive}}}}} 

	And for any reason the add command fails, what shall be the
context Id in the reply: '$',  specific or any of them? 
	Does it make any difference? 

	If the reply is 

	P=1{C=1{Add=termination{Error = 430}}} 

	The controller does not need to subtract the context 1, because
the only command in the request failed, does it? 
	If the controller request to subtract C=1, that would be an
error from the controller, wouldn't? 

	They said that to avoid the controller from sending a subtract,
the context id in the reply shall be '$'. But I think that the
controller shall not send the subtract even if the context id is an
specific value.

	Regards, Julio 

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

From megaco-bounces@ietf.org Thu Mar 30 18:16:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FP6N1-0000eB-2n; Thu, 30 Mar 2006 18:16:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6Mz-0000e6-9N
	for megaco@ietf.org; Thu, 30 Mar 2006 18:16:01 -0500
Received: from web34303.mail.mud.yahoo.com ([66.163.178.135])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FP6Mx-0005NA-VB
	for megaco@ietf.org; Thu, 30 Mar 2006 18:16:01 -0500
Received: (qmail 23289 invoked by uid 60001); 30 Mar 2006 23:15:59 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=YYWsoCqTBqiTmLvIGQZNwg8HBfTbWPJ3F4sete7iAoqDWTo9CjWSWt0i8m8vKOX0LH4OmTiQpvjBFuPbxuI8s6zagcMqUWMA+wEyxs8go2y63P01RS9A2N+gfsExNQHbQW6fm2Q5YFptm9Ny1da7hrIjseAmemwmcSTxvK5A4wI=
	; 
Message-ID: <20060330231559.23287.qmail@web34303.mail.mud.yahoo.com>
Received: from [67.53.73.210] by web34303.mail.mud.yahoo.com via HTTP;
	Thu, 30 Mar 2006 15:15:59 PST
Date: Thu, 30 Mar 2006 15:15:59 -0800 (PST)
From: 
To: megaco@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Subject: [Megaco] Megaco ABNF -- clean source
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: xinumike-sip@yahoo.com
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

Hello,

I have been trying to run the megaco abnf source
through a parser...and I end up with a syntax
errors from the cutting and pasting from the RFC. 

Does anybody have a "clean" copy of the ABNF that
a parser might like?  

Can anybody recommend a good parser?  I found 
a couple open source parsers...perhaps that
is my problem too?

I am trying to knock together a tool for doing some
tests.

Thanks,
 Mike

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

From megaco-bounces@ietf.org Fri Mar 31 16:55:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPRa7-0004VJ-22; Fri, 31 Mar 2006 16:54:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRa5-0004VE-J6
	for megaco@ietf.org; Fri, 31 Mar 2006 16:54:57 -0500
Received: from xproxy.gmail.com ([66.249.82.198])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRa2-0008Fl-Cf
	for megaco@ietf.org; Fri, 31 Mar 2006 16:54:57 -0500
Received: by xproxy.gmail.com with SMTP id s12so602594wxc
	for ; Fri, 31 Mar 2006 13:54:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=n63gbo3LSsWZyCFMfV1dtvvrSxlYpgt5/I/9wmFvLzbMtyiHtQU29e9YiWD9hm1bmCqhmpc0khkOYwBerYoCv5kw6O5+R/zXmXQ2pmH6RLTjgsUCwE0GirNwt8FTP7HY9HRlNnyLO7U0N7doY0AFkpIzbN8RIVtRzLrLtcDzrw0=
Received: by 10.70.15.11 with SMTP id 11mr356640wxo;
	Fri, 31 Mar 2006 13:54:52 -0800 (PST)
Received: by 10.70.15.5 with HTTP; Fri, 31 Mar 2006 13:54:52 -0800 (PST)
Message-ID: 
Date: Fri, 31 Mar 2006 16:54:52 -0500
From: "Ron Ho" 
To: megaco@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Subject: [Megaco] Segmentation package
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Type: multipart/mixed; boundary="===============0121591145=="
Errors-To: megaco-bounces@ietf.org

--===============0121591145==
Content-Type: multipart/alternative; 
	boundary="----=_Part_28624_32272431.1143842092354"

------=_Part_28624_32272431.1143842092354
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

There is a Segmentation package mentioned in ETSI ES 283 018. Can anyone
point me out where to find the definition of this package?

Thanks,
Ron

------=_Part_28624_32272431.1143842092354
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

There is a Segmentation package mentioned in ETSI ES 283 018. Can
anyone point me out where to find the definition of this package?

Thanks,

Ron

------=_Part_28624_32272431.1143842092354--

--===============0121591145==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0121591145==--

From megaco-bounces@ietf.org Fri Mar 31 17:20:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPRyr-0005ch-Ec; Fri, 31 Mar 2006 17:20:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRyp-0005bq-Pe
	for megaco@ietf.org; Fri, 31 Mar 2006 17:20:31 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRk6-0000Qv-DB
	for megaco@ietf.org; Fri, 31 Mar 2006 17:05:21 -0500
Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com
	[47.140.202.51])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k2VM5G720401
	for ; Fri, 31 Mar 2006 17:05:16 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
Subject: RE: [Megaco] Segmentation package
Date: Fri, 31 Mar 2006 17:05:15 -0500
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407968DE2@zrtphxm2>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Megaco] Segmentation package
Thread-Index: AcZVDlCXjr+e7tj8T6GNp7N+03yNAQAAKntA
From: "Kevin Boyle" 
To: "Ron Ho" , 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: 
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Media Gateway Control 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Errors-To: megaco-bounces@ietf.org

H.248.1 V3 Section E.14.

Kevin

________________________________

	From: Ron Ho [mailto:ron.ho.megaco@gmail.com] 
	Sent: Friday, March 31, 2006 4:55 PM
	To: megaco@ietf.org
	Subject: [Megaco] Segmentation package

	Hi,

	There is a Segmentation package mentioned in ETSI ES 283 018.
Can anyone point me out where to find the definition of this package?

	Thanks,
	Ron

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