From prvs=5209032b7=shalu.dhamija@rancoretech.com Fri Oct 2 23:59:01 2009
Return-Path: Hello All, I have queries regarding the implementation of automatic speech recogntion(asr) service. I am using asr package for this purpose. The MRFC can control the MRFP to recognize the voice by this package. If the MRFC indicates the MRFP with the signal asrwgs(asr recognition with grammar script), the recognition grammar shall be the SRGS or other script to be specified in the rgs(recogntion grammer script) parameter in the signals descriptor of the megaco modify command. I am confused about the value of the rgs. Is the following value for the rgs correct?? rgs = " #ABNF 1.0 UTF-8; language en; mode voice; root $basicCmd /** * Basic command. * @example please move the window * @example open a file */ public $basicCmd = $http://grammar.example.com/politeness.gram#startPolite $command $http://grammar.example.com/politeness.gram#endPolite; $command = $action $object; $action = /10/ open {TAG-CONTENT-1} | /2/ close {TAG-CONTENT-2} | /1/ delete {TAG-CONTENT-3} | /1/ move {TAG-CONTENT-4}; $object = [the | a] (window | file | menu ; " i.e. the script is sent inline with the megaco modify command. If the above behaviour is not correct, Can someone illustrate an example stating the value of the rgs parameter. Regards, Shalu
------=_Part_52312_29404841.1254553210018-- From shashanka2005@gmail.com Wed Oct 7 02:31:39 2009 Return-Path:
NOTE 1 – The IP sustainable byte rate = Rs relates to IP = packets, i.e.=20 exclusive lower protocol layers.
)------_=_NextPart_001_01CA4B27.699ADB78-- From thomas.belling@nsn.com Mon Oct 12 10:00:30 2009 Return-Path:
From: 3GPP_TSG_CT_WG3 - Core = Network and=20 Terminals WG 3 [mailto:3GPP_TSG_CT_WG3@LIST.ETSI.ORG] On Behalf Of=20 Belling, Thomas (NSN - DE/Munich)
Sent: Donnerstag, 8. = Oktober=20 2009 11:49
To: = 3GPP_TSG_CT_WG3@LIST.ETSI.ORG
Subject: Re:=20 Iq/Ix-controlled IP byte-rate policing (based on H.248.53=20 tman)Hi=20 Albrecht:<removing ietf megaco becaue I am not a member of this=20 list>some=20 quotations from H.248.539 Deriving policy enforcement point parameters from = parameters=20 of traffic management
and other packages
In this clause, relationships between the generic = traffic=20 parameters, as defined in clauses 6 to 8, and
specific traffic policers are provided. Such a traffic = policer=20 could be part of a general PEP.
Parameter mapping recommendations are required due = to:
TISPAN Traffic Management = Packages
(This appendix does not form an integral part of this=20 Recommendation)
This Appendix contains the Traffic Management package = version 1,=20 which is based on a copy of the
original version of the ETSI TISPAN Traffic Management = package=20 (see [b-ETSI TS 102 333]).
This Appendix is for the information of = implementers.
...
II.1.6 Procedures
...
The = interpretation=20 of these properties (i.e.
pdr,=20 sdr, dvt=20 and mbs) is = dependent=20 on the type oftransport is associated with the H.248 Terminations, = for=20 example, ATM or IP. The package makes
no assumptions as to what layers (e.g. layer 2 or = layer 3) are=20 included in the properties and therefore
it is recommended to include the exact interpretations = in a=20 profile, e.g. based on parameter mapping
guidelines according clause 9.
Although this is not really related to the core of my = discussion paper,=20 the text in the Introduction to the traffic management package = v1 =20 in H.248.53 does not fully fit to your explanations. Perhaps ITU-T = should=20 consider updating this a bit.
But I=20 also base my analysis on Clause 9 in the lack of other information, = although=20 this is mentioned only as an example in tman v1 (as used in=20 3GPP).
Clause=20 9 considers the relationship to a couple of diffrent algorithms. for = IP these=20 are algorithms based on Y.1221 or RFC 2216.=20
I do not = believe we=20 should mandate a gateway to apply a particular leacky bucket algorithm = amd=20 select one particulat of those references. In particular, I have some = concerns=20 about the very complex two-stage algorithm for traffic policying = described in=20 Y.1221. We should not mandate a gateway to use this.
I=20 certainly also do not intend to invent semantics that are in conflict = with=20 Clause 9. My analysis rather intended to derive more information about = the=20 semantics from this clause, which strictly speaking also only provides = indirect clues about the semantics by clatifying how the parameters = could be=20 used at a gateway assuming the gateway is using this or that=20 algorithm.
If you=20 look into normative changes I propose you will find that I only = clarify that=20 the bitrate shall include all layers from IP upward, and that ithe=20 sustainable bit rate shall be calculated averaging over a = time that=20 is sufficiently long to average out effect of bursts and=20 jitter.
In=20 doing so, I only follow recommendations given in H.248.53 for tman v1: = it is recommended to = include the=20 exact interpretations in a profile
Do you=20 have concerns with these explanations?
From: ext Schwarz Albrecht=20 [mailto:Albrecht.Schwarz@alcatel-lucent.de]
Sent: Thursday, = October=20 08, 2009 9:00 AM
To: Belling, Thomas (NSN - DE/Munich);=20 3GPP_TSG_CT_WG3@LIST.ETSI.ORG
Cc: megaco;=20 simao.campos@itu.int
Subject: Iq/Ix-controlled IP byte-rate = policing=20 (based on H.248.53 tman)Hi Thomas,just read your 091251:Two comments/concerns:
- Don't refer ETSI TISPAN TS 102 = 333!
because
-=20 tman v1 was transferred to ITU-T some years ago, H.248.53 is thus = the only=20 relevant reference for tman
- there isn't any IANA registry = anymore for=20 the original ETSI package, thus TS 102 333 is really irrelevant in = your=20 contribution=20- Semantic of tman properties
=3D> = cl. 9/H.248.53=20 is normative, it's not just examples of policer types
=3D> = Iq/Ix got to=20 select a particular policing algorithm (which must be = equivalent to=20 cl. 9), or leave it open and then implicitly refer to cl. 9 (i.e., = either a=20 Y.1221 or RFC 2216 policer for IP byte-rate policing)
=3D> I'm = concerned=20 that you want introduce a 2nd semantic for tman properties when = reading=20 "Interpreting sdr and pdr at the gateway as = recommended in=20 Clause 9 of H.248.53 requires ...".
Again, cl. 9 mandates = parameter=20 mappings between H.248 elements and policer types.
If you are = unhappy=20 with the tman semantics, then contribute against H.248.53 itself, = but=20 profile-specific package semantics would be the wrong approach in my = opinion.Note: reference for tman is H.248.53 = (03/09), which=20 supersedes H.248.53 (06/08), - but H.248.53 (03/09) is unfortunately = not yet=20 published by ITU-T.Regards,Albrecht
NOTE 1 – The IP sustainable byte rate = Rs relates to IP = packets, i.e.=20 exclusive lower protocol layers.
)------_=_NextPart_001_01CA4B5D.56EEC3CD-- From Matia.Marcu@Teledata-Networks.com Mon Oct 19 04:08:30 2009 Return-Path:
From: 3GPP_TSG_CT_WG3 - Core = Network and=20 Terminals WG 3 [mailto:3GPP_TSG_CT_WG3@LIST.ETSI.ORG] On Behalf Of=20 Belling, Thomas (NSN - DE/Munich)
Sent: Donnerstag, 8. = Oktober=20 2009 11:49
To: = 3GPP_TSG_CT_WG3@LIST.ETSI.ORG
Subject: Re:=20 Iq/Ix-controlled IP byte-rate policing (based on H.248.53=20 tman)Hi=20 Albrecht:<removing ietf megaco becaue I am not a member of this=20 list>some=20 quotations from H.248.539 Deriving policy enforcement point parameters from = parameters=20 of traffic management
and other packages
In this clause, relationships between the generic = traffic=20 parameters, as defined in clauses 6 to 8, and
specific traffic policers are provided. Such a traffic = policer=20 could be part of a general PEP.
Parameter mapping recommendations are required due = to:
TISPAN Traffic Management = Packages
(This appendix does not form an integral part of this=20 Recommendation)
This Appendix contains the Traffic Management package = version 1,=20 which is based on a copy of the
original version of the ETSI TISPAN Traffic Management = package=20 (see [b-ETSI TS 102 333]).
This Appendix is for the information of = implementers.
...
II.1.6 Procedures
...
The = interpretation=20 of these properties (i.e.
pdr,=20 sdr, dvt=20 and mbs) is = dependent=20 on the type oftransport is associated with the H.248 Terminations, = for=20 example, ATM or IP. The package makes
no assumptions as to what layers (e.g. layer 2 or = layer 3) are=20 included in the properties and therefore
it is recommended to include the exact interpretations = in a=20 profile, e.g. based on parameter mapping
guidelines according clause 9.
Although this is not really related to the core of my = discussion paper,=20 the text in the Introduction to the traffic management package = v1 =20 in H.248.53 does not fully fit to your explanations. Perhaps ITU-T = should=20 consider updating this a bit.
But I=20 also base my analysis on Clause 9 in the lack of other information, = although=20 this is mentioned only as an example in tman v1 (as used in=20 3GPP).
Clause=20 9 considers the relationship to a couple of diffrent algorithms. for = IP these=20 are algorithms based on Y.1221 or RFC 2216.=20
I do not = believe we=20 should mandate a gateway to apply a particular leacky bucket algorithm = amd=20 select one particulat of those references. In particular, I have some = concerns=20 about the very complex two-stage algorithm for traffic policying = described in=20 Y.1221. We should not mandate a gateway to use this.
I=20 certainly also do not intend to invent semantics that are in conflict = with=20 Clause 9. My analysis rather intended to derive more information about = the=20 semantics from this clause, which strictly speaking also only provides = indirect clues about the semantics by clatifying how the parameters = could be=20 used at a gateway assuming the gateway is using this or that=20 algorithm.
If you=20 look into normative changes I propose you will find that I only = clarify that=20 the bitrate shall include all layers from IP upward, and that ithe=20 sustainable bit rate shall be calculated averaging over a = time that=20 is sufficiently long to average out effect of bursts and=20 jitter.
In=20 doing so, I only follow recommendations given in H.248.53 for tman v1: = it is recommended to = include the=20 exact interpretations in a profile
Do you=20 have concerns with these explanations?
From: ext Schwarz Albrecht=20 [mailto:Albrecht.Schwarz@alcatel-lucent.de]
Sent: Thursday, = October=20 08, 2009 9:00 AM
To: Belling, Thomas (NSN - DE/Munich);=20 3GPP_TSG_CT_WG3@LIST.ETSI.ORG
Cc: megaco;=20 simao.campos@itu.int
Subject: Iq/Ix-controlled IP byte-rate = policing=20 (based on H.248.53 tman)Hi Thomas,just read your 091251:Two comments/concerns:
- Don't refer ETSI TISPAN TS 102 = 333!
because
-=20 tman v1 was transferred to ITU-T some years ago, H.248.53 is thus = the only=20 relevant reference for tman
- there isn't any IANA registry = anymore for=20 the original ETSI package, thus TS 102 333 is really irrelevant in = your=20 contribution=20- Semantic of tman properties
=3D> = cl. 9/H.248.53=20 is normative, it's not just examples of policer types
=3D> = Iq/Ix got to=20 select a particular policing algorithm (which must be = equivalent to=20 cl. 9), or leave it open and then implicitly refer to cl. 9 (i.e., = either a=20 Y.1221 or RFC 2216 policer for IP byte-rate policing)
=3D> I'm = concerned=20 that you want introduce a 2nd semantic for tman properties when = reading=20 "Interpreting sdr and pdr at the gateway as = recommended in=20 Clause 9 of H.248.53 requires ...".
Again, cl. 9 mandates = parameter=20 mappings between H.248 elements and policer types.
If you are = unhappy=20 with the tman semantics, then contribute against H.248.53 itself, = but=20 profile-specific package semantics would be the wrong approach in my = opinion.Note: reference for tman is H.248.53 = (03/09), which=20 supersedes H.248.53 (06/08), - but H.248.53 (03/09) is unfortunately = not yet=20 published by ITU-T.Regards,Albrecht
According
to rfc 4566, it is possible to use "$" in the fmt field of the =
media
description lines.
Does
the "$" cover a mixture of fixed and dynamic payloads? For =
example:
is the following exchange legal (assuming =
ReserveValue=3Dtrue)?
command:
m=3Daudio $ RTP/AVP =
$
reply:
=
m=3Daudio 4444
RTP/AVP 8 18 120 13
&nbs=
p;  =
;
a=3Drtpmap:120 telephone-event/8000
a=3Dfmtp:120 =
0-15
a=3Dfmtp:18 =
annexb=3Dyes
Many
thanks,
Matia
Consider
an MG that has terminations C1, C2 and C3. C1 is in context 1, C2 =
is in
context 2, and C3 is in the null context. What is the correct =
reply to
this transaction?
!/1 [192.168.59.1]:2944 =
T=3D2629{
C=3D*{O-AV=3DC1{AT{M}}, =
O-AV=3DC2{AT{M}},
O-AV=3DC3{AT{M}}}}
Answer
1:
MEGACO/1 =
[192.168.59.2]:2944
Reply=3D2629{
&nbs=
p; =
Context=3D1{
&nbs=
p;  =
; =
AuditValue=3DC1{Media{LocalControl{Mode=3DSendReceive},TerminationState{S=
erviceStates=3DInService,
Buffer=3DOFF}}},
&nbs=
p;  =
; =
AuditValue=3DC2{Error=3D435{"Termination
not in specified context"}},
&nbs=
p;  =
; =
AuditValue=3DC3{Error=3D435{"Termination
not in specified context"}}
&nbs=
p; },
&nbs=
p; =
Context=3D2{
&nbs=
p;  =
; =
AuditValue=3DC1{Error=3D435{"Termination
not in specified context"}},
&nbs=
p;  =
; =
AuditValue=3DC2{Media{LocalControl{Mode=3DSendReceive},TerminationState{S=
erviceStates=3DInService,
Buffer=3DOFF}}},
&nbs=
p;  =
; =
AuditValue=3DC3{Error=3D435{"Termination
not in specified context"}}
&nbs=
p; }
}
Answer
2:
MEGACO/1 =
[192.168.59.2]:2944
Reply=3D2629{
&nbs=
p; =
Context=3D1{
&nbs=
p;  =
; =
AuditValue=3DC1{Media{LocalControl{Mode=3DSendReceive},TerminationState{S=
erviceStates=3DInService,
Buffer=3DOFF}}},
&nbs=
p; },
&nbs=
p; =
Context=3D2{
&nbs=
p;  =
; =
AuditValue=3DC2{Media{LocalControl{Mode=3DSendReceive},TerminationState{S=
erviceStates=3DInService,
Buffer=3DOFF}}}
&nbs=
p; }
}
Answer
3:
MEGACO/1 =
[192.168.59.2]:2944
Reply=3D2629{
&nbs=
p; =
Context=3D1{
&nbs=
p;  =
; =
AuditValue=3DC1{Media{LocalControl{Mode=3DSendReceive},TerminationState{S=
erviceStates=3DInService,
Buffer=3DOFF}}},
&nbs=
p;  =
; =
AuditValue=3DC3{Error=3D431{"No
TerminationID matched a wildcard"}}
&nbs=
p; },
&nbs=
p; =
Context=3D2{
&nbs=
p;  =
; =
AuditValue=3DC2{Media{LocalControl{Mode=3DSendReceive},TerminationState{S=
erviceStates=3DInService,
Buffer=3DOFF}}},
&nbs=
p;  =
; =
AuditValue=3DC3{Error=3D431{"No
TerminationID matched a wildcard"}}
&nbs=
p; }
}
Why
should it be Answer 1? Although section 7.2.5 says that "the =
command
Context=3D*{AuditValue=3Dt2/*{Audit{Packages}}} returns =
Context=3D1{AuditValue=3Dt2/1{Packages{ccc,ddd}}},
Context=3D2{AuditValue=3Dt2/2{Packages{ccc,ddd}}}", this case is =
different,
because the terminations are enumerated explicitly, and so a reply is =
expected
for each termination listed, for each context that exists. =
Why
should it be Answer 2? Because of 6.3.2, "ContextID =
wildcarded (ALL)
with TerminationID specific: In the case where the ContextID is =
wildcarded (i.e.
ContextID =3D ALL) and the TerminationID is fully specified, the effect =
is
identical to a command specifying the non-NULL context that contains the
specified termination. Thus a search must be made to find the =
context and
only one instance of the command is executed. No errors are reported for
contexts that do not contain the specified =
termination".
Why should it be Answer 3? =
Because
6.3.2 continues, "If the termination is not contained in any =
(non-NULL)
context then Error Code 431 (“No TerminationID matched a =
wildcard”)
is returned".
Answer
2 seems to be the most manageable and useful, but that doesn't count for =
much
if an MGC is expecting a different format and will draw wrong =
conclusions if it
doesn’t get it. So, if anyone can see the right answer =
clearly, I
would appreciate it.
Raphael
Tryster
> -----Original Message-----
> From: Hiroshi Tamura =
[mailto:tamura@cs.ricoh.co.jp]>=20
Sent: Dienstag, 20. Oktober 2009 09:32
> To: Michael.Chen@lsi.com; =
Ed.Schulz@lsi.com; t09sg16q14@lists.itu.int
> Cc:=20
tamura@cs.ricoh.co.jp
> Subject: [T16Q14] COM 16 - C 194 (V.34 =
fallback in=20
T.38)
>
> Michael, Ed and All,
>
> As I cannot =
attend=20
the meeting next week, let me comment here.
>
> 1 =
Combination of New=20
emitting GW and existing receiving GW
> Receiving GW does not =
understand=20
the new field "T38ModemType".
> Is it guaranteed that it just =
ignores the=20
field?
> Did you fully consider the compatibility item with =
the
>=20
current implementation?
>
> 2 G3 only at one GW and V.34 =
only at the=20
other GW What
> happens in this case? It implicitly says "prefer"=20
type.
>
> 3 Annex B
> As it is H.323 call-setup, you =
should=20
consider the ASN.1
> syntax to add H.225.0.
> I do not =
remember the=20
exact recomendation.
>
> 4 Recommendation to =
Industry
> How do=20
you proceed?
>
> Best regards,
> --
> Hiroshi=20
Tamura
>
>
>
Ericsson =
GmbH. Sitz:=20
D=FCsseldorf. Registergericht: Amtsgericht D=FCsseldorf, HRB 33012. =
Gesch=E4ftsf=FChrer:=20
Carsten Ahrens. Aufsichtsratsvorsitzender: Anders Olin
This =
Communication=20
is Confidential. We only send and receive email on the basis of the =
terms set=20
out at www.ericsson.com/email_=
disclaimer=20