headers
Christian Groves | 1 May 2007 06:42

Re: IndAudMediaDescriptor

Hello Raphael,

Please see my responses below.

Regards, Christian

Raphael Tryster wrote:
> >From 7.2.5 text describing the AuditValue command:
>
>    ¸    To audit an individual property in the media descriptor the 
>         relevant stream ID (optional), group ID(optional) and 
>         propertyID are included. The current value of the property is 
>         returned. Group ID is used in the case where the local control 
>         Reserve Group flag is used. Group ID 1 corresponds to the first 
>         group (session decription) reserved, Group ID 2 the next group 
>         etcetera.
>
> I see this groupID and propertyID described in ASN.1 but not in ABNF.  Does it / should it exist in ABNF?
>   
[CNG] The issue here is that as the ABNF uses SDP for the local and 
remote descriptors it doesn't use the formal groupID, propertyID 
structures. See H.248.1 sect 7.1.8. The MGC must use SDP to specify the 
information it requires to audit. This isn't fully described but 
H.248.39 shows how you can identifying parameters.
> Also, is it correct that it is possible to audit an individual property of a single stream or all streams in
the media descriptor, but it is not possible to audit all properties of a single stream?
>   
[CNG] When you say stream do you mean by simply auditing the streamID 
that you'd get back local, remote, local control and statistics 
descriptors for the stream? I think its certainly possible to request
(Continue reading)

Permalink | Reply | 4 comments |
headers
Raphael Tryster | 1 May 2007 08:48

RE: IndAudMediaDescriptor

Hello Christian,

... and Tuesday morning.

Thanks for the reply.  I see the information to which you referred in H.248.39, but the text I quoted also
appears in H.248 version 2, which does not have auditing local and remote descriptors, hence my puzzlement.

I see now another difference between versions 2 and 3 regarding audit of the media descriptor: version 3
allows repeated parameters, e.g. multiple indAudlocalParm in indAudlocalControlDescriptor,
whereas version 2 allows only one.  So in version 3 it would be possible to audit the mode, reservevalue,
reservegroup and all package properties of a local control descriptor in one command using */*, but in
version 2 it is not.  Was there some deliberate reason for the restriction in version 2, or was it an oversight?

Regards, 

Raphael Tryster

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves <at> nteczone.com] 
Sent: Tuesday, May 01, 2007 6:42 AM
To: Raphael Tryster
Cc: megaco <at> ietf.org
Subject: Re: [Megaco] IndAudMediaDescriptor

Hello Raphael,

Please see my responses below.

Regards, Christian
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Groves | 1 May 2007 08:24

Re: ServiceIncompleteFlag in case of ASN

Hello Rambabu,

Please see my response below.

Regards, Christian

Rambabu Gajula wrote:
>
> Hi,
>
> I am trying to understand the Service Incomplete flag (Described in 
> Specification H.248 Version 3 section: 7.2.8.1.10).
>
> As per the H.248 Specification, Initial Service Change Request message 
> should go in Version-1 format. The newly added element should go now 
> in “X-SC”.
>
> Extension Containers Service Change request.
>
> The Name: SIC Type: Boolean Possible Values: ON
>
> 1) The type mentioned here is BOOLEAN, but the ASN.1 Syntax in 
> “NonStandardIdentifier” is experimental “IA5String”. How we will map 
> the Boolean to IA5String.
>

[CNG] As the section says the value is encoded as per the given ABNF, so 
its a simple string mapping.
>
> 2) Possible Values: ON, As per my understanding in case of Boolean
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Groves | 1 May 2007 09:12

Re: IndAudMediaDescriptor

G'Day Raphael,

I agree always good to start the morning with helpful emails... should 
be more of them :).

I usually base my comments on H.248.1v3 as lot of issues have been 
clarified/fixed in this version.
 From memory it was probably an oversight, I can't imagine why we'd 
knowlingly disallow this.

Regards, Christian

Raphael Tryster wrote:
> Hello Christian,
>
> ... and Tuesday morning.
>
> Thanks for the reply.  I see the information to which you referred in H.248.39, but the text I quoted also
appears in H.248 version 2, which does not have auditing local and remote descriptors, hence my puzzlement.
>
> I see now another difference between versions 2 and 3 regarding audit of the media descriptor: version 3
allows repeated parameters, e.g. multiple indAudlocalParm in indAudlocalControlDescriptor,
whereas version 2 allows only one.  So in version 3 it would be possible to audit the mode, reservevalue,
reservegroup and all package properties of a local control descriptor in one command using */*, but in
version 2 it is not.  Was there some deliberate reason for the restriction in version 2, or was it an oversight?
>  
> Regards, 
>  
> Raphael Tryster
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Raphael Tryster | 3 May 2007 09:30

RE: IndAudMediaDescriptor

G'Day Christian,

I wonder if there is still an oversight in v3 regarding termination
state audit.

indAudterminationStateDescriptor = TerminationStateToken LBRKT
indAudterminationStateParm RBRKT

; at-most-once per item
indAudterminationStateParm = pkgdName / propertyParm /
ServiceStatesToken
[(EQUAL/INEQUAL) serviceStatesValue ] / BufferToken
; When values are included a Select operation is implied.
; AND/OR logic is specified at context level.

I don't see how it makes sense to say "at-most-once" if only one
instance of indAudterminationStateParm is allowed.  Compare this with
local control, where indAudlocalParm can be repeated, as we discussed
previously.

indAudlocalControlDescriptor = LocalControlToken LBRKT indAudlocalParm
*(COMMA indAudlocalParm) RBRKT

; at-most-once per item
indAudlocalParm = ModeToken [(EQUAL/INEQUAL) streamModes]/ pkgdName /
propertyParm / ReservedValueToken / ReservedGroupToken
; propertyparm and streamModes are used only to specify audit selection
; criteria. AND/OR selection logic is specified at context level.

Regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Amit Yedidia | 3 May 2007 14:24
Favicon

Text Overlay parameters in h.248.19 Amendment 1

Hi,

 

Text Overlay package in H.248.19 Amendment 1 contain the following parameters:

Text Width (textw)

Text Height (texth)

Relative Text Font Size (textfontsize)

 

What is the relation between those parameters?

My assumption was that the dimension of the box containing the text will be textw x texth,

And the size of the fonts within this box will be related to its height.

Am I correct?

 

 

 

Amit Yedidia

Tel.  +972-3-976 4598

Fax. +972-3-976 4233

http://www.audiocodes.com/

Email:amit.yedidia <at> audiocodes.com

1 Hayarden St. Airport City,

Lod 70151 Israel

 

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Tom-PT Taylor | 4 May 2007 03:02
Favicon

[Fwd: I-D ACTION:draft-taylor-megaco-obsol3525-00.txt]

We are obsoleting the Megaco RFC, as discussed a while ago. The body of this 
draft explains where to get more up-to-date specifications. The IANA registry 
remains, and RFC 3525 will remain in the repository but with altered status.

Please send any comments to the Megaco list. If no one has any comments on the 
text of this draft, I'll send it to the IESG in a week or two.

Tom Taylor

Internet-Drafts <at> ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Reclassification of RFC 3525 to Historic
> 	Author(s)	: T. Taylor
> 	Filename	: draft-taylor-megaco-obsol3525-00.txt
> 	Pages		: 4
> 	Date		: 2007-5-3
> 	
>    This document reclassifies RFC 3525, Gateway Control Protocol Version
>    1, to Historic Status.  This memo also obsoletes RFC 3525.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-taylor-megaco-obsol3525-00.txt
>
Permalink | Reply | 501 comments |
headers
Christian Groves | 4 May 2007 07:12

Re: [Fwd: I-D ACTION:draft-taylor-megaco-obsol3525-00.txt]

Hello Tom,

The text looks reasonable. A few comments:

1. Comment on IANA impacts: "The IANA registries established by RFC 3525 
and extended by successive versions of ITU-T H.248.1 remain in force, 
along with the requirement  for expert review by an IESG-designated 
expert."

I agree these are true of changing the status to Historic. The 2nd 
statement with respect to review by an IESG-designated expert however is 
proposed to be changed, see 
<http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-63.zip> . 
I'm currently in discussion with IANA on how best to document it.

To avoid confusion I would suggest just to state: "The IANA registries 
established by RFC 3525 and extended by successive versions of ITU-T 
H.248.1 remain in force." in the draft.

2. I think it would be good to include a reference to RFC2026 (and some 
text about it) so people understand what Historic is and under what 
clause the RFC is being moved to historic status.

3. Linked to the above comment do we need to re-inforce the difference 
between making a "specification" historic and making the Megaco protocol 
itself historic? i.e.

"RFC 3525 <as a specification of the Megaco protocol> has been rendered 
even more obsolete by the publication of
   further versions of ITU-T Recommendation H.248.1.  Version 2 [h248v2]
   was published in May, 2002, and is the version most widely deployed
   at present.  It is also the version that other standards bodies such
   as 3GPP are currently using as the basis for their own profile
   specifications.  Version 3 [h248v3] was published more recently, in
   September, 2005.

   In short, RFC 3525 <as a specification> may serve as an introduction 
to the Megaco/H.248
   protocol, but is misleading as a description of the protocol as
   currently standardized or deployed.  It is appropriate to reclassify
   RFC 3525 <specification> to Historic status <in favour of the more 
recent ITU specifications>."

Regards, Christian

Tom-PT Taylor wrote:
> We are obsoleting the Megaco RFC, as discussed a while ago. The body 
> of this draft explains where to get more up-to-date specifications. 
> The IANA registry remains, and RFC 3525 will remain in the repository 
> but with altered status.
>
> Please send any comments to the Megaco list. If no one has any 
> comments on the text of this draft, I'll send it to the IESG in a week 
> or two.
>
> Tom Taylor
>
> Internet-Drafts <at> ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>>     Title        : Reclassification of RFC 3525 to Historic
>>     Author(s)    : T. Taylor
>>     Filename    : draft-taylor-megaco-obsol3525-00.txt
>>     Pages        : 4
>>     Date        : 2007-5-3
>>     
>>    This document reclassifies RFC 3525, Gateway Control Protocol Version
>>    1, to Historic Status.  This memo also obsoletes RFC 3525.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-taylor-megaco-obsol3525-00.txt
>>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
Permalink | Reply | 501 comments |
headers
Rambabu Gajula | 4 May 2007 07:16
Favicon

Handoff triggered from MGC to NewMgc

Hi,
 
During MGC initiated Handoff request to MGW, the MGW should aware off the new MGC(ServiceChangeMgcID) ?
 
MGW can allow to start control association with new MGC which is not aware of that MGCId at MGW level?
 
1) Is this not cause any security/un authorized more attacks on MGCs?
2) Is there any mechanism on run time to exchange which encoding/decoding scheme(ASN/ABNF)should be used in new control associations?
 
 
 
Thanks a lot for your time and help.
 
st1\:* { BEHAVIOR: url(#ieooui) } <at> font-face { font-family: Arial Narrow; } <at> page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; mso-style-parent: ""; mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman" } SPAN.SpellE { mso-style-name: ""; mso-spl-e: yes } SPAN.GramE { mso-style-name: ""; mso-gram-e: yes } DIV.Section1 { page: Section1 }

Thanks with Regards,

Rambabu Gajula

 
 
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 0 comments |
headers
Tom-PT Taylor | 4 May 2007 19:21
Favicon

Re: [Fwd: I-D ACTION:draft-taylor-megaco-obsol3525-00.txt]

The matter of who designates the expert is in the realm of politics. The IESG 
will have something to say about it. I've copied Cullen Jennings and Jon 
Peterson, the most directly affected Area Directors.

Your other suggestions are good ones and will be taken up in a second version of 
the I-D.

Christian Groves wrote:
> Hello Tom,
> 
> The text looks reasonable. A few comments:
> 
> 1. Comment on IANA impacts: "The IANA registries established by RFC 3525 
> and extended by successive versions of ITU-T H.248.1 remain in force, 
> along with the requirement  for expert review by an IESG-designated 
> expert."
> 
> I agree these are true of changing the status to Historic. The 2nd 
> statement with respect to review by an IESG-designated expert however is 
> proposed to be changed, see 
> <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/TD-63.zip> . 
> I'm currently in discussion with IANA on how best to document it.
> 
> To avoid confusion I would suggest just to state: "The IANA registries 
> established by RFC 3525 and extended by successive versions of ITU-T 
> H.248.1 remain in force." in the draft.
> 
> 2. I think it would be good to include a reference to RFC2026 (and some 
> text about it) so people understand what Historic is and under what 
> clause the RFC is being moved to historic status.
> 
> 3. Linked to the above comment do we need to re-inforce the difference 
> between making a "specification" historic and making the Megaco protocol 
> itself historic? i.e.
> 
> "RFC 3525 <as a specification of the Megaco protocol> has been rendered 
> even more obsolete by the publication of
>   further versions of ITU-T Recommendation H.248.1.  Version 2 [h248v2]
>   was published in May, 2002, and is the version most widely deployed
>   at present.  It is also the version that other standards bodies such
>   as 3GPP are currently using as the basis for their own profile
>   specifications.  Version 3 [h248v3] was published more recently, in
>   September, 2005.
> 
>   In short, RFC 3525 <as a specification> may serve as an introduction 
> to the Megaco/H.248
>   protocol, but is misleading as a description of the protocol as
>   currently standardized or deployed.  It is appropriate to reclassify
>   RFC 3525 <specification> to Historic status <in favour of the more 
> recent ITU specifications>."
> 
> 
> 
> Regards, Christian
> 
> Tom-PT Taylor wrote:
>> We are obsoleting the Megaco RFC, as discussed a while ago. The body 
>> of this draft explains where to get more up-to-date specifications. 
>> The IANA registry remains, and RFC 3525 will remain in the repository 
>> but with altered status.
>>
>> Please send any comments to the Megaco list. If no one has any 
>> comments on the text of this draft, I'll send it to the IESG in a week 
>> or two.
>>
>> Tom Taylor
>>
>> Internet-Drafts <at> ietf.org wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>
>>>
>>>     Title        : Reclassification of RFC 3525 to Historic
>>>     Author(s)    : T. Taylor
>>>     Filename    : draft-taylor-megaco-obsol3525-00.txt
>>>     Pages        : 4
>>>     Date        : 2007-5-3
>>>        This document reclassifies RFC 3525, Gateway Control Protocol 
>>> Version
>>>    1, to Historic Status.  This memo also obsoletes RFC 3525.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-taylor-megaco-obsol3525-00.txt
>>>
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
> 
>
Permalink | Reply | 0 comments |

Gmane