Prateek Raj Singh | 1 Apr 11:13 2004
Picon

Re: subscription :Megaco query

hi Kevin ,

What will be the state of the terminations which are  present at the time of MGW get fail ?
What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ?
 

regards,
prateek
Kevin Boyle wrote:

 

Procedures for MGC control of MGs are described in the spec.  Essentially, the MGC would have to wait for the MG to return to service.

Kevin

-----Original Message-----
From: Prateek Raj Singh Pawar [mailto:prateek <at> cdotd.ernet.in]
Sent: Wednesday, March 24, 2004 11:38 PM
To: Megaco <at> ietf.org
Cc: Prateek Raj Singh
Subject: [Megaco] subscription :Megaco query

Hi ,

This is parteek , working in C-DOT Indian goverment telecom research center . we are currently working on the 3G MSC Server .

Pls add me in the mailing list of megaco .

I h've some queries related with the megaco .

What are the control procedure if  MGC control only one MGW configuration and MGW will fail .

with regards,
PRATEEK RAJ SINGH PAWAR
  Research Engineer
  3G  Mobile Solutions
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039 Akber Bhavan ,Chankya  mail :pprateekraj <at> yahoo
Puri ,  New Delhi-21         pratraj <at> rediff
----------------------------------------------------------------------------
 

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

--  PRATEEK RAJ SINGH PAWAR    Research Engineer     Mobile Solutions          C-DOT            Ph(O):24677525 ext. 324 Room No 824,9th Floor  Cell : +919810652039 Akber Bhavan ,Chankya  mail :pprateekraj <at> yahoo Puri ,  New Delhi-21         pratraj <at> rediff  ----------------------------------------------------------------------------  
Prateek Raj Singh | 1 Apr 12:20 2004
Picon

Megaco mib

    Hi ,
 
Pls tell me the mib for ASN.1 encoding of Megaco
regards,
Prateek

--  PRATEEK RAJ SINGH PAWAR    Research Engineer     Mobile Solutions          C-DOT            Ph(O):24677525 ext. 324 Room No 824,9th Floor  Cell : +919810652039 Akber Bhavan ,Chankya  mail :pprateekraj <at> yahoo Puri ,  New Delhi-21         pratraj <at> rediff  ----------------------------------------------------------------------------  
Tönu Trump (AS/EAB | 1 Apr 11:09 2004
Picon

RE: Re: H.248.xx Enhanced Acoustic Control Package; RE: Basic Mod el & Near End Definition; RE: Question on echo control direction

Dear all,

The Draft ITU-T Rec. G.799.1 is clearly stating which direction the network echo cancellers need to be connected:

8.1.1	Echo Control
In compliance with ITU-T Rec. G.177, Transmission Planning for voiceband services over hybrid
internet/PSTN connections, a voice-over-IP connection traversing a hybrid is required to include a
G.168 compliant echo canceller. Since the echo canceller needs to have a constant delay for its echo path,
it shall be placed so that the echo path is on the TDM side of the interface that includes the hybrid. Issues
that need to be addressed are:
·	Issues related to modem and other voice-band data signals
·	Tail Capacity
Network Operators and Service Providers should ensure that echo cancellation is applied in the most
appropriate location for the specific configuration. The echo canceller shall be associated with the
TIGIN gateway in one of three possible configurations, as outlined in the following sections.  
It should be reinforced that all voice connections involving GSTN to IP interworking involving a hybrid
require echo cancellation and the Network Operator or Service Provider choosing to utilize either
configuration B or C below should ensure that an echo canceller is provisioned on the TDM bearer side of the
hybrid Internet/GSTN connection. 

Best regards,
Tõnu Trump
Rapporteur Q.7/15

-----Original Message-----
From: owner-tsg15q7 <at> itu.int [mailto:owner-tsg15q7 <at> itu.int]On Behalf Of
peter.goldstein <at> ties.itu.int
Sent: den 31 mars 2004 10:12
To: albrecht.schwarz <at> alcatel.de
Cc: adrian.soncodi <at> tekelec.com; megaco <at> ietf.org; tsg15q7 <at> itu.int
Subject: Fwd: Re: H.248.xx Enhanced Acoustic Control Package; RE: Basic
Model & Near End Definition; RE: [Megaco] Question on echo control
direction

----- Forwarded message from pgoldste <at> ties.itu.ch -----
    From: pgoldste <at> ties.itu.ch
Reply-To: pgoldste <at> ties.itu.ch
 Subject: Re: H.248.xx Enhanced Acoustic Control Package; RE: Basic Model & 
Near End Definition; RE: [Megaco] Question on echo control direction
      To: Albrecht.Schwarz <at> alcatel.de

Dear All,

ITU-T Rec.Q.115.1 describes where and when Echo Control Devices are needed and 
provided in a voice call. This nezwork logic is independent of the signalling 
systems used and the network technology (TDM, Mobile, Packet).
ITU-T Rec.Q.115.0 describes protocols to control Echo Control Devices (on a per 
call basis). In a TDM network this may be something like c-bit of time slot 16 
(PCM 30); in a VoIP GW a H.248 SPNE (Signal Processing Network Equipment) 
Package has been defined, this allows a MGC to control a ECD associated with a 
MG. This package complements the TDM Package which does not provide the 
required flexibility (an ECD may have to be controlled at any point in time of 
a call).
ITU-T Rec. Q.115.1 refers to Network Echo Control Devices (e.g. Echo 
Cancellers, Echosuppressors).
There exist a final draft new REC.Q.115.2 Logic for the Control of VEDs (Voice 
Enhancement Devices/Functions). Acoustic Echo Control is part of such a 
device/function.
>From the control point of view Echo Control Devices are considered to 
be "half", i.e. an ECD is controlling the echo from only one echo source. If a 
specific implementation provides "full" echo control then this is considered as 
two "halfs" and the two "halfs" are controlled independently.

regards;
Peter Goldstein
Siemens Switzerland
(Rapporteur Q.10/11)

  
Quoting Albrecht.Schwarz <at> alcatel.de:

> 
> Adrian,
> 
> when reading the Half Echo-Control Device (HECD) section, I was reminded to
> Q.115.1 and G.799.1:
> 
> ITU-T Recommendation Q.115.1
> Logic for the control of echo control devices and functions
> 
> ITU-T Recommendation G.799.1
> 
> Functionality and Interface Specifications for GSTN Transport Network
> Equipment for Interconnecting GSTN and IP Networks
> 
> 
> 
> For instance, Q.115.1 is, inter alia, providing definitions for incoming
> echo control device (IECD) and outgoing echo control device (OECD), G.799.1
> is extensively dealing with EC in TDM-to-Packet media gateways.
> 
> 
> 
> Did you already consider these ITU-T recs. in your package proposal? I
> guess that we need alignment.
> 
> 
> 
> May anyone of the Q7/15 experts comment on the HECD block in the proposed
> H.248 package.
> 
> 
> 
> Regards,
> 
> Albrecht
> 
> 
> 
> 
> 
>                                                                              
>                                                                        
>                       "Soncodi, Adrian"                                      
>                                                                        
>                       <Adrian.Soncodi <at> t         To:      Albrecht
> SCHWARZ/DE/ALCATEL <at> ALCATEL                                                   
>      
>                       ekelec.com>               cc:      <megaco <at> ietf.org>   
>                                                                        
>                                                 Subject: H.248.xx Enhanced
> Acoustic Control Package; RE: Basic Model & Near End Definition; RE:      
>                       29.03.2004 21:17          [Megaco] Question on echo
> control direction                                                          
>                                                                              
>                                                                        
>                                                                              
>                                                                        
> 
> 
> 
> 
> Albrecht,
> 
> Still on the EC issue... I may be jumping ahead here while you are trying
> to propose a resolution, but this is what I think:
> 
> First, it doesn't look like we can "fix" the EC omission in the TDM package
> without affecting either some existing MG implementations or some MGC-MG
> procedures on deployed systems.
> 
> Then there are also other capabilities similar to EC, and for which there
> is currently no H.248 package. For example:
> - ANR automatic noise reduction
> - ALC automatic level control
> - ALE adaptive listener enhancement
> These are used mostly (but not only) for wireless calls.
> 
> So I was thinking we might as well define a new package, to fix the EC and
> also provide the above capabilities.
> 
> Attached is an outline of what this "Enhanced Acoustic Control Package"
> might contain. I did not include the "audio gain", which is defined in the
> TDM package. (Maybe I should have, because this is also directional, so
> apparently it has the same problem as EC.)
> 
> Please let me know what you think. If anyone is interested in pursuing this
> work in the ITU-T group, please let me know.
> 
> Regards,
> 
> Adrian
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Albrecht.Schwarz <at> alcatel.de [mailto:Albrecht.Schwarz <at> alcatel.de]
> Sent: Wednesday, March 24, 2004 11:09 AM
> To: Soncodi, Adrian
> Cc: megaco <at> ietf.org
> Subject: Basic Model & Near End Definition; RE: [Megaco] Question on
> echo control direction
> 
> 
> 
> Adrian,
> 
> you are addressing a bunch of valid questions.
> Before responding on your details, I'd like to synchronize our
> understanding.
> 
> Please find enclosed some powerpoint slides
> (NGN_EchoCanceller_Principle_r02.PPT), these pictures reflecting my "world
> view" on H.248 MG-embedded ECs:-)
> Do you agree with "near end", "half way" definitions?
> Is my view inline with yours?
> 
> Perhaps one issue is the use of term "near end" in NGN environments,
> whereas G.168 precisely talks about "cancelled end" since the 2002 version.
> 
> Any G.168 experts view? Please correct me if I'm wrong.
> 
> Best regards,
> Albrecht
> 
> 
> 
> 
> (See attached file: NGN_EchoCanceller_Principle_r02.PPT)(See attached file:
> NGN_EchoCanceller_Principle_r02.pdf)
> 
> 
> 
> 
>                       "Soncodi, Adrian"
> 
>                       <Adrian.Soncodi <at> t         To:      Albrecht
> SCHWARZ/DE/ALCATEL <at> ALCATEL
> 
>                       ekelec.com>               cc:      <megaco <at> ietf.org>
> 
>                                                 Subject: RE: [Megaco]
> Question on echo control direction
> 
>                       19.03.2004 18:46
> 
> 
> 
> 
> 
> 
> 
> Albrecht,
> 
> Let's say both switches perform near-end, half way EC as you suggest. Then
> the question is: what do you mean by "near-end half way EC"? Is it:
> a) Cancelling echo towards the near-end user, so that he does not hear
> echo? or
> b) Cancelling echo generated by the near end, so that the far end user does
> not hear echo?
> 
> In other words, which one happens when the MGC instructs the MG to turn EC
> on? I'm not saying it should be one or another, I'm saying that the H.248
> standard should specify it, because it matters.
> 
> Kevin says it should be a). I just point out that most of the MGs today do
> b). And I found one MG that does a). So if MGCs follow the ISUP procedures
> to turn EC on at both ends using b), they may have the surprise that some
> EC devices are "flipped over", and thus they become ineffective as they
> work over the long path. Or, instead of being complementary, both EC
> devices cancel in the same direction ... you see the problem.
> 
> I don't quite understand the rest of you e-mail. What do you mean by "Any
> EC requirement in addition ... must be signalled correspondingly." Signaled
> where? in H.248 you only have one ec property.
> 
> Are you suggesting that the MGC just signals "ec=on", and then the exact
> behavior of the MG (i.e. the direction of the half-way EC device etc.)
> depends on the local MG provisioning? This could be a solution, but even
> so, the H.248 standard should make it clear. And the MGC would still have
> to know what is the case in order to properly implement two-way echo
> control procedures.
> 
> To conclude, I'm still trying to find out what the MG's expected behavior
> is. See my long e-mail for pros and cons of a) and b). But I believe if we
> don't clarify it, there will be interop problems.
> 
> Adrian
> 
> 
> 
> 
> -----Original Message-----
> From: Albrecht.Schwarz <at> alcatel.de [mailto:Albrecht.Schwarz <at> alcatel.de]
> Sent: Friday, March 19, 2004 3:06 AM
> To: Soncodi, Adrian
> Cc: Kevin Boyle; megaco <at> ietf.org; megaco-admin <at> ietf.org
> Subject: RE: [Megaco] Question on echo control direction
> 
> 
> 
> Adrian,
> I couldn't find any contradiction between Kevin's and your statements.
> 
> My understanding is that the "basic" EC settings for circuit-to-packet MGs,
> where the POTS/ISDN terminal is accessed via a circuit-switched network,
> are:
> - near-end EC, and
> - half way only ("I don't know the exact G.168 terminology").
> 
> I think that this common understanding may be derived from legacy PSTN/ISDN
> networks.
> Any EC requirement in addition, e.g., like
> - far-end EC,
> - 2 near-end "H.248 TDM Terminations" (in a TDM-to-TDM call), and/or
> - full way
> must be signalled correspondingly.
> 
> My impression is that the "basic settings" are sufficient for almost all
> cases. The additional EC capabilities are valid network scenarios (e.g.,
> inter-operater interworking, replacement of an international exchange,
> tandem echo cancellation, two satellite links in the TDM-to-TDM call
> scenario, missing near-end EC capability in peer MG, etc), but rather
> exeptional cases (like in pre-NGN TDM networks).
> 
> Regards,
> Albrecht
> 
> 
> 
> 
> 
> 
>                       "Soncodi, Adrian"
> 
>                       <Adrian.Soncodi <at> t         To:      "Kevin Boyle"
> <kboyle <at> nortelnetworks.com>, <megaco <at> ietf.org>
> 
>                       ekelec.com>               cc:
> 
>                       Sent by:                  Subject: RE: [Megaco]
> Question on echo control direction
> 
>                       megaco-admin <at> ietf
> 
>                       .org
> 
> 
> 
>                       18.03.2004 18:13
> 
> 
> 
> 
> 
> 
> 
> Kevin,
> 
> In your message you say:
> 
> 
>  "I cannot find anything that specifies this, but I don't know why someone
> would use an echo canceller to cancel echo inside the context... Why not
> just fix the DSP to not introduce the echo in the first place?  You don't
> generally find echo on the transition from TDM<->packet."
> 
> 
> Actually, it's not the DSP that introduces echo. It's the 4-wire to 2-wire
> conversion beyond the TDM termination. So for a TDM-packet-TDM call, we
> have the following:
> 
> - Typically, echo is cancelled at both ends of the call. Originating and
> terminating switch each cancel in different directions.
> 
> - For an echo device to cancel in one direction, it has to take the other
> path as reference, wait for the signal to turn around from the user, and
> then compare the two and clean the echo. This involves a delay buffer (echo
> tail), typically up to 64 ms, sometimes up to 128 ms (I don't know of MGs
> that can do more).
> 
> - As a consequence, each switch typically cancels echo over the short path.
> For a TDM-packet-TDM call, the short path is usually the TDM, while the
> long path is the packet network plus the other TDM. If you wait for the
> signal to turn around on the packet side, many times the delay is bigger
> than the buffer size and the EC device becomes ineffective.
> 
> - Consider two MG-s interconnected by a packet network. If these were
> traditional TDM switches, each one would clean the stream going towards the
> other (for example, the echo indications in ISUP IAM/ACM are designed to
> achieve this result). This corresponds to the direction into the packet
> network.
> 
> - Another reason to clean the stream into the packet network is that if the
> stream has echo, then the encoding/decoding performed by some compression
> algorithms results in lower quality voice (i.e. some algorithms are
> optimized for "clean" voice).
> 
> - A solution for this would be to turn echo control on the packet-side
> terminations. Then if these terminations work like you say they should, the
> desired result would be achieved. Unfortunately, all the MGs I know cannot
> do this. They can only apply a half EC device on the TDM termination
> (probably because the package name is TDM)
> 
> - Another aspect: For a conference call with N TDM terminations in a
> context, in order cancel the echo generated by one TDM circuit it is
> simpler to clean its stream going into the context than the other N-1 going
> out of the context.
> 
> - Until now, I thought I knew the answer to this one. Although this does
> not seem to be clearly specified either in MGCP or in MEGACO, for all the
> MGs I've seen, if you turn on echo on a TDM termination they clear the
> stream going into the packet network. They reference the backwards stream
> to TDM, which is turned around over the short path. So it looks like most
> of the existing MGs do not work like you recommended -- people, correct me
> if I'm wrong here.
> 
> - However, recently I stumbled upon an MG that behaves exactly the
> opposite. So now I really have a problem, because there is no way for an
> MGC to know whether the ec property results in the insertion of a full EC
> device or a half device, and which direction.
> 
> - By analogy with signals (although ec is a propery not a signal), this
> should work as you said, i.e. towards the outside of the context. But if
> you would like to standardize this behavior, already a lot of MGs would be
> non-compliant (again, people?).
> 
> - There is also no way for an MGC to audit for this behavior. But if MGs
> were allowed to behave both ways, then you could have different MGs at the
> two ends and then of a TDM-packet-TDM call, and it becomes impossible to
> provide two-way echo cancellation.
> 
> So how do you propose we clarify all this?
> 
> Thanks,
> 
> Adrian
> 
> 
>       -----Original Message-----
>       From: Kevin Boyle [mailto:kboyle <at> nortelnetworks.com]
>       Sent: Wednesday, March 17, 2004 6:12 PM
>       To: Soncodi, Adrian; megaco <at> ietf.org
>       Subject: RE: [Megaco] Question on echo control direction
> 
> 
> 
>       Ecan generally applies to the network transition point to avoid
>       reflections off the transition.  Therefore, it would make sense that
>       the echo canceller on the TDM termination would cancel echo outwards
>       toward the TDM facility.
> 
> 
>       I cannot find anything that specifies this, but I don't know why
>       someone would use an echo canceller to cancel echo inside the
>       context... Why not just fix the DSP to not introduce the echo in the
>       first place?  You don't generally find echo on the transition from
>       TDM<->packet.
> 
> 
>       Kevin
> 
> 
>       -----Original Message-----
>       From: Soncodi, Adrian [mailto:Adrian.Soncodi <at> tekelec.com]
>       Sent: Wednesday, March 17, 2004 6:51 PM
>       To: megaco <at> ietf.org
>       Subject: [Megaco] Question on echo control direction
> 
> 
>       Hi,
> 
> 
>       When an MCG turns on echo control for a TDM termination on the MG,
>       which one of the following audio streams becomes "clean" of echo:
> 
> 
>       a) The stream from the termination outwards to the TDM facility, or
>       b) The stream from the termination inwards into the context
>       (presumably going out on another facility associated with another
>       termination in the context) (I am assuming that only a half-echo
>       canceller is inserted, because most of the MGs can only do that. The
>       other half would be on the other termination.)
> 
> 
>       Where is this specified? the TDM package in H.248 annex E does not
>       say.
> 
> 
>       Thanks,
> 
> 
>       Adrian
> 
> 
> 
> 
> 
> 
>       _______________________________________________
>       Megaco mailing list
>       Megaco <at> ietf.org
>       https://www1.ietf.org/mailman/listinfo/megaco
> 
> 
> 
> 
> 
> 
> 

----- End forwarded message -----
Carsten Waitzmann | 1 Apr 16:16 2004
Picon
Picon

Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: Hairpin case A/u Law conversion

Hello Christian,

I took your suggestion as a basis for the following example:

MGC -> MG:
MEGACO / 1 [1.2.3.4]
Transaction = 100 {
    Context = $  { Add = TDM1 {
                                       Media  {
                                              LocalControl {Mode = 
SendReceive},
                                              Local {a=h248item:TMR = 
0000 0010}}
                                 }}}

MG -> MGC
MEGACO / 1 [1.2.3.5]
Reply = 100 {
    Context = 1 {
                              Add = TDM1 {
                                           Media  {
                                                Local {a=h248item:TMR = 
00000010}
                                                       }}}}

Is this usage in line to what you have in mind?
H.248.15 specifies: a=h248item:<package name>/<property name> = <value>. 
For H.248.1 C.9 I do not know which package applies to property TMR. But 
H.248.15 states "To enable the carriage of package defined properties in 
the local and remote descriptors of the text encoded H.248.1 protocol 
the Package attribute shall be used" thus I am wondering whether a 
package name isn't mandatory?

Thanks  a lot!

Carsten

Alcatel

Christian Groves wrote:

> Hello Tom and Albrecht,
>
> What peice of information do you want to signal explicitely? Doesn't 
> TMR allow you to specify 64Kbit UDI? If so then its supported by 
> H.248.1 Annex C.9. For H.248 text users this (or any element in Annex 
> C) can be tranferred via H.248.15. Alternatively Q.1950 sect 5.7.1.2 
> specifies an equivalent encoding.
>
> Regards, Christian
>
> Tom Taylor wrote:
>
>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my 
>> intervention.  My old draft has been allowed to expire because it did 
>> not seem to be of much interest to the community.
>>
>> You are right: the draft just referred to doesn't apply to TDM, only 
>> to the packet side.  I wasn't thinking.  I agree that in the absence 
>> of the attributes provided in my old draft, TDM bearer 
>> characteristics are assumed rather than signalled explicitly.
>>
>> Albrecht.Schwarz <at> alcatel.de wrote:
>>
>>> I think that the question is, whether this specific TDM bearer 
>>> capability
>>> should be (1) explicitly signalled, or whether (2) implicit 
>>> assumption is
>>> already sufficient.
>>>
>>> With regard to (1), Tom, I guess that your refer to
>>>
>>> * RTP/CLEARMODE
>>>   RTP payload format for a 64 kbit/s transparent call
>>>   
>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt
>>>
>>> But, this coming RFC may not be directly applied, e.g., 
>>> packetization time
>>> parameter isn't applicable IMHO. Pls correct me if wrong.
>>>
>>> Or do you refer to your proposals in your expired draft wrt
>>> * TDM/CLEARMODE
>>>   Conventions for the use of the Session Description Protocol (SDP)
>>>   for Digital Circuit Connections
>>>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt
>>>
>>> My conclusion is, that an explicit signalling method doesn't exist 
>>> today
>>> ("exception might be Q.1950").
>>> Even though, an explicit TDM Media Descriptor for I.231.1  might be 
>>> helpful
>>> for unambigously specification in certain MG implementations.
>>>
>>>
>>> With regard to (2):
>>> Implicit signaling is in my understanding the situation of today. In 
>>> case
>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
>>> Descriptors with transparent channel indications", when a transparent
>>> 64-kbit/s bearer connection may be established.
>>> Sometimes this is also called "native TDM switching", or "native TDM
>>> hairpinning", but technically it is exactly representing an ISDN B 
>>> channel
>>> with I.231.1 bearer service. [=> the channel may bypass the DSP, but in
>>> case that a DSP is looped-in, then must be the DSP channel operation 
>>> mode
>>> configured for 'Clearmode']
>>>
>>> Last comment:
>>> Such kind of implicit signalling mechanism is often assumed in telco
>>> industry, because this is the legacy signaling mechanism within a TDM
>>> switch ("if there aren't any signaled bearer capabilities then 
>>> transparent
>>> channel; any needed bearer capability in addition must be explicitly
>>> signalled, like signal processing network equipment functions, e.g., 
>>> EC").
>>>
>>> TDM hairpinning means, an "H.248-controlled TDM switching function" 
>>> from
>>> H.248 Media Gateway perspective. Hence, this implicit signalling 
>>> assumption
>>> may be still valid, or do you see any needs for explicit signaling
>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>>>
>>> Regards
>>>
>>> Albrecht
>>>
>>>
>>>
>>>
>>>
>>>
>>>                                                                                                                                                     
>>>                       Tom 
>>> Taylor                                                                                                                    
>>>                       <taylor <at> nortelne         To:      Zhao Bo 
>>> <zbo <at> huawei.com>                                                                    
>>>                       tworks.com>              cc:      Albrecht 
>>> SCHWARZ/DE/ALCATEL <at> ALCATEL, 
>>> megaco <at> ietf.org                                        
>>>                                                Subject: Re: TDM 
>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law 
>>> conversion                                                 
>>> 26.02.2004 
>>> 14:05                                                                                                              
>>>                                                                                                                                                     
>>>                                                                                                                                                     
>>>
>>>
>>>
>>>
>>> I think you would do it by specifying the CLEARMODE codec in the 
>>> Local and
>>> Remote
>>> descriptors.  Unfortunately, CLEARMODE is still under consideration 
>>> by the
>>> IESG
>>> and hasn't reached RFC status.
>>>
>>> Zhao Bo wrote:
>>>
>>>> Dear Albrecht:
>>>>    Is there any H.248 package defined to signal the UDI transparency
>>>
>>>
>>>
>>> properties in TDM hairping case?
>>>
>>>>    Best regards
>>>>
>>>> ----- Original Message -----
>>>> From: <Albrecht.Schwarz <at> alcatel.de>
>>>> To: "Zhao Bo" <zbo <at> huawei.com>
>>>> Cc: <megaco <at> ietf.org>; <megaco-admin <at> ietf.org>
>>>> Sent: Wednesday, February 25, 2004 10:24 PM
>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>>>>
>>>>
>>>>
>>>> Dear Zhao Bo,
>>>>
>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248
>>>
>>>
>>>
>>> standards
>>>
>>>> ("please correct if I'm wrong"), I'd like to use the following one for
>>>> responding your questions:
>>>>
>>>>
>>>
>>> *********************************************************************************** 
>>>
>>>
>>>
>>>> Definition:
>>>> TDM Hairpinning
>>>> ? is a scenario whereby a call is being made between two TDM 
>>>> endpoints on
>>>
>>>
>>>
>>> a
>>>
>>>>    single media gateway. The media comes in on one TDM channel and 
>>>> goes
>>>>    out on another TDM channel through the use of an internal loop 
>>>> in the
>>>>    media gateway.
>>>>
>>>> Note 1: due to the fact that there are local call types at local
>>>
>>>
>>>
>>> exchanges
>>>
>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types 
>>>> behind the
>>>> general "TDM hairpinning" capability (dependent on required type of 
>>>> IWF,
>>>> etc.) in corresponding H.248 MG types
>>>>
>>>> Note 2: H.248/MEGCOP perspective
>>>> TDM Hairpinning = Single H.248 Context with 2 H.248 TDM Terminations
>>>>
>>>
>>> ************************************************************************************ 
>>>
>>>
>>>
>>>> Based on this hairpinning understanding, my answers are:
>>>>
>>>> (1) Speech telephony service: G.711 companding formats are a 
>>>> property of
>>>> the corresponding H.248 TDM termination
>>>>
>>>> [Note: dependent on MG architecture and implementation, property 
>>>> might be
>>>> signalled or preprovisioned. Of course, G.711 companding law is an
>>>
>>>
>>>
>>> inherent
>>>
>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way, 
>>>> how
>>>> this DS0 property is associated with the corresponding H.248 TDM
>>>> Termination property may only realized MG-internally for very 
>>>> specific MG
>>>> architectures. Generally it is up to the MGC, particularly if some (or
>>>
>>>
>>>
>>> all)
>>>
>>>> DS0's are ISDN B channels.]
>>>>
>>>> (2) Voiceband Data services: same as in (1)
>>>>
>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of
>>>> interoperability, a V.152 compliant implementation shall support at 
>>>> least
>>>> both G.711 A-law and G.711 ì-law codecs as VBD codecs. "]
>>>>
>>>> (3) ISDN UDI = all ISDN Teleservices with ISDN I.231. bearer service
>>>> requirement
>>>> => H.248 TDM Termination property must be signalled by MGC, if not, MG
>>>
>>>
>>>
>>> may
>>>
>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
>>>> channel) in TDM hairpinning scenarios ...
>>>>
>>>>
>>>> Conclusion:
>>>> IF your MG is supporting
>>>> PSTN lines (= H.248 ALN Termination),
>>>> PSTN trunks (= H.248 TDM Termination), and
>>>> ISDN B channels (= H.248 TDM Termination)
>>>>
>>>> AND IF you've such services and interworking requirements
>>>>
>>>> THEN you should generally signal the corresponding properties ...
>>>>
>>>> ... in case of
>>>> TDM hairpinning,
>>>> ALN hairpinning, or
>>>> ALN-to-TDM connection types.
>>>>
>>>> Regards,
>>>> Albrecht
>>>>
>>>> ALCATEL
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>>                      Zhao Bo
>>>
>>>
>>>
>>>
>>>>                      <zbo <at> huawei.com>         To:      megaco <at> ietf.org
>>>
>>>
>>>
>>>
>>>>                      Sent by:                 cc:
>>>
>>>
>>>
>>>
>>>>                      megaco-admin <at> iet         Subject: [Megaco] 
>>>> Hairpin
>>>
>>>
>>>
>>> case A/u Law conversion
>>>
>>>>                      f.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>>                      25.02.2004 08:11
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> In this case, the A/u law format of a TDM ciruit can be 
>>>> provisioned,  but
>>>> the MG doesn't know the service type of a call, thus
>>>> has no way to know if a conversion is needed. For speech service
>>>
>>>
>>>
>>> conversion
>>>
>>>> may be needed; for data service like isdn UDI, conversion is not
>>>
>>>
>>>
>>> permitted.
>>>
>>>> Is there any method to solve this problem?
>>>>
>>>> Zhao Bo
>>>>
>>>> *****************************************************************
>>>> This e-mail and its attachments contain confidential information from
>>>> HUAWEI, which is intended only for the person or entity whose 
>>>> address is
>>>> listed above. Any use of the information contained herein in any way
>>>> (including, but not limited to, total or partial disclosure,
>>>
>>>
>>>
>>> reproduction,
>>>
>>>> or dissemination) by persons other than the intended recipient(s) is
>>>> prohibited. If you receive this e-mail in error, please notify the 
>>>> sender
>>>> by phone or email immediately and delete it!
>>>> *****************************************************************
>>>>
>>>> _______________________________________________
>>>> Megaco mailing list
>>>> Megaco <at> ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Megaco mailing list
>>>> Megaco <at> ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>> 1èr‰šŠX§‚X¬´Ç iÊ"z×è®m¶›?ÿ0Ö'­~Šàþf¢–f§þX¬¶)ߣùž§(
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>
>
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we 
> only send and receive e-mails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
Kevin Boyle | 1 Apr 15:56 2004

RE: subscription :Megaco query

That would depend upon how the MG came back into service.  As stated in the
spec, the default value of the ServiceStates property is "Inservice".  This
means that upon a cold start registration of the MG, all terminations are
inservice, unless and until the MG reports otherwise via a separate
ServiceChange command on the OOS terms.

The MGC is always free to audit to determine the ServiceState of
terminations in the MG.

Kevin

  _____  

From: Prateek Raj Singh [mailto:prateek <at> cdotd.ernet.in] 
Sent: Thursday, April 01, 2004 4:13 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Megaco <at> ietf.org
Subject: Re: [Megaco] subscription :Megaco query

hi Kevin , 

What will be the state of the terminations which are  present at the time of
MGW get fail ? 
What mechanism provided by the megaco to maintain the same state at the both
end MGC and MGW ? 

regards, 
prateek 
Kevin Boyle wrote: 

Procedures for MGC control of MGs are described in the spec.  Essentially,
the MGC would have to wait for the MG to return to service. 

Kevin 

-----Original Message----- 
From: Prateek Raj Singh Pawar [mailto:prateek <at> cdotd.ernet.in
<mailto:prateek <at> cdotd.ernet.in> ] 
Sent: Wednesday, March 24, 2004 11:38 PM 
To: Megaco <at> ietf.org 
Cc: Prateek Raj Singh 
Subject: [Megaco] subscription :Megaco query 

Hi , 

This is parteek , working in C-DOT Indian goverment telecom research center
. we are currently working on the 3G MSC Server . 

Pls add me in the mailing list of megaco . 

I h've some queries related with the megaco . 

What are the control procedure if  MGC control only one MGW configuration
and MGW will fail . 

with regards, 
PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
  3G  Mobile Solutions 
      C-DOT            Ph(O):24677525 ext. 324 
Room No 824,9th Floor  Cell : +919810652039 Akber Bhavan ,Chankya  mail
:pprateekraj <at> yahoo 
Puri ,  New Delhi-21         pratraj <at> rediff 
----------------------------------------------------------------------------

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

--

-- 

PRATEEK RAJ SINGH PAWAR 

  Research Engineer 

   Mobile Solutions   

      C-DOT            Ph(O):24677525 ext. 324

Room No 824,9th Floor  Cell : +919810652039

Akber Bhavan ,Chankya  mail :pprateekraj <at> yahoo

Puri ,  New Delhi-21         pratraj <at> rediff 

----------------------------------------------------------------------------
Zhao Bo | 2 Apr 11:59 2004

question about H.248.26

Hi Kevin:

As per H.248.26, for "pri" parameter of "em" signal:

There is no default value for this parameter, and the MGC should always provide a positive non-zero value.

Why? Why MG cannot use a provsioned value.
Best regards

Zhao Bo

*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for
the person or entity whose address is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!
*****************************************************************
Kevin Boyle | 2 Apr 17:24 2004

RE: question about H.248.26

If the MG was in charge of running metering, then there would be no point to
having this package.  Because this package is intended to allow MGC control
of metering pulse application, the MGC should indeed perform that control.

Kevin

-----Original Message-----
From: Zhao Bo [mailto:zbo <at> huawei.com] 
Sent: Friday, April 02, 2004 5:00 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: megaco <at> ietf.org
Subject: question about H.248.26

Hi Kevin:

As per H.248.26, for "pri" parameter of "em" signal:

There is no default value for this parameter, and the MGC should always
provide a positive non-zero value.

Why? Why MG cannot use a provsioned value.
Best regards

Zhao Bo

*****************************************************************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
*****************************************************************
Christian Groves | 6 Apr 03:55 2004
Picon

Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: Hairpin case A/u Law conversion

Hello Carsten,

Yes this is what I had in mind. The package ID for Annex C is 0.

ie. H.248.1 Annex A
PkgdName ::= OCTET STRING(SIZE(4))
-- represents Package Name (2 octets) plus Property, Event,
-- Signal Names or Statistics ID. (2 octets)
-- To wildcard a package use 0xFFFF for first two octets, choose
-- is not allowed. To reference native property tag specified in
-- Annex C, use 0x0000 as first two octets.

Regards, Christian

Carsten Waitzmann wrote:

> Hello Christian,
> 
> I took your suggestion as a basis for the following example:
> 
> MGC -> MG:
> MEGACO / 1 [1.2.3.4]
> Transaction = 100 {
>    Context = $  { Add = TDM1 {
>                                       Media  {
>                                              LocalControl {Mode = 
> SendReceive},
>                                              Local {a=h248item:TMR = 
> 0000 0010}}
>                                 }}}
> 
> MG -> MGC
> MEGACO / 1 [1.2.3.5]
> Reply = 100 {
>    Context = 1 {
>                              Add = TDM1 {
>                                           Media  {
>                                                Local {a=h248item:TMR = 
> 00000010}
>                                                       }}}}
> 
> Is this usage in line to what you have in mind?
> H.248.15 specifies: a=h248item:<package name>/<property name> = <value>. 
> For H.248.1 C.9 I do not know which package applies to property TMR. But 
> H.248.15 states "To enable the carriage of package defined properties in 
> the local and remote descriptors of the text encoded H.248.1 protocol 
> the Package attribute shall be used" thus I am wondering whether a 
> package name isn't mandatory?
> 
> Thanks  a lot!
> 
> Carsten
> 
> Alcatel
> 
> Christian Groves wrote:
> 
>> Hello Tom and Albrecht,
>>
>> What peice of information do you want to signal explicitely? Doesn't 
>> TMR allow you to specify 64Kbit UDI? If so then its supported by 
>> H.248.1 Annex C.9. For H.248 text users this (or any element in Annex 
>> C) can be tranferred via H.248.15. Alternatively Q.1950 sect 5.7.1.2 
>> specifies an equivalent encoding.
>>
>> Regards, Christian
>>
>> Tom Taylor wrote:
>>
>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my 
>>> intervention.  My old draft has been allowed to expire because it did 
>>> not seem to be of much interest to the community.
>>>
>>> You are right: the draft just referred to doesn't apply to TDM, only 
>>> to the packet side.  I wasn't thinking.  I agree that in the absence 
>>> of the attributes provided in my old draft, TDM bearer 
>>> characteristics are assumed rather than signalled explicitly.
>>>
>>> Albrecht.Schwarz <at> alcatel.de wrote:
>>>
>>>> I think that the question is, whether this specific TDM bearer 
>>>> capability
>>>> should be (1) explicitly signalled, or whether (2) implicit 
>>>> assumption is
>>>> already sufficient.
>>>>
>>>> With regard to (1), Tom, I guess that your refer to
>>>>
>>>> * RTP/CLEARMODE
>>>>   RTP payload format for a 64 kbit/s transparent call
>>>>   
>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt
>>>>
>>>> But, this coming RFC may not be directly applied, e.g., 
>>>> packetization time
>>>> parameter isn't applicable IMHO. Pls correct me if wrong.
>>>>
>>>> Or do you refer to your proposals in your expired draft wrt
>>>> * TDM/CLEARMODE
>>>>   Conventions for the use of the Session Description Protocol (SDP)
>>>>   for Digital Circuit Connections
>>>>   http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt
>>>>
>>>> My conclusion is, that an explicit signalling method doesn't exist 
>>>> today
>>>> ("exception might be Q.1950").
>>>> Even though, an explicit TDM Media Descriptor for I.231.1  might be 
>>>> helpful
>>>> for unambigously specification in certain MG implementations.
>>>>
>>>>
>>>> With regard to (2):
>>>> Implicit signaling is in my understanding the situation of today. In 
>>>> case
>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media
>>>> Descriptors with transparent channel indications", when a transparent
>>>> 64-kbit/s bearer connection may be established.
>>>> Sometimes this is also called "native TDM switching", or "native TDM
>>>> hairpinning", but technically it is exactly representing an ISDN B 
>>>> channel
>>>> with I.231.1 bearer service. [=> the channel may bypass the DSP, but in
>>>> case that a DSP is looped-in, then must be the DSP channel operation 
>>>> mode
>>>> configured for 'Clearmode']
>>>>
>>>> Last comment:
>>>> Such kind of implicit signalling mechanism is often assumed in telco
>>>> industry, because this is the legacy signaling mechanism within a TDM
>>>> switch ("if there aren't any signaled bearer capabilities then 
>>>> transparent
>>>> channel; any needed bearer capability in addition must be explicitly
>>>> signalled, like signal processing network equipment functions, e.g., 
>>>> EC").
>>>>
>>>> TDM hairpinning means, an "H.248-controlled TDM switching function" 
>>>> from
>>>> H.248 Media Gateway perspective. Hence, this implicit signalling 
>>>> assumption
>>>> may be still valid, or do you see any needs for explicit signaling
>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls?
>>>>
>>>> Regards
>>>>
>>>> Albrecht
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                                                                                                                                                     
>>>>                       Tom 
>>>> Taylor                                                                                                                    
>>>>                       <taylor <at> nortelne         To:      Zhao Bo 
>>>> <zbo <at> huawei.com>                                                                    
>>>>                       tworks.com>              cc:      Albrecht 
>>>> SCHWARZ/DE/ALCATEL <at> ALCATEL, 
>>>> megaco <at> ietf.org                                        
>>>>                                                Subject: Re: TDM 
>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law 
>>>> conversion                                                 
>>>> 26.02.2004 
>>>> 14:05                                                                                                              
>>>>                                                                                                                                                     
>>>>                                                                                                                                                     
>>>>
>>>>
>>>>
>>>>
>>>> I think you would do it by specifying the CLEARMODE codec in the 
>>>> Local and
>>>> Remote
>>>> descriptors.  Unfortunately, CLEARMODE is still under consideration 
>>>> by the
>>>> IESG
>>>> and hasn't reached RFC status.
>>>>
>>>> Zhao Bo wrote:
>>>>
>>>>> Dear Albrecht:
>>>>>    Is there any H.248 package defined to signal the UDI transparency
>>>>
>>>>
>>>>
>>>>
>>>> properties in TDM hairping case?
>>>>
>>>>>    Best regards
>>>>>
>>>>> ----- Original Message -----
>>>>> From: <Albrecht.Schwarz <at> alcatel.de>
>>>>> To: "Zhao Bo" <zbo <at> huawei.com>
>>>>> Cc: <megaco <at> ietf.org>; <megaco-admin <at> ietf.org>
>>>>> Sent: Wednesday, February 25, 2004 10:24 PM
>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion
>>>>>
>>>>>
>>>>>
>>>>> Dear Zhao Bo,
>>>>>
>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248
>>>>
>>>>
>>>>
>>>>
>>>> standards
>>>>
>>>>> ("please correct if I'm wrong"), I'd like to use the following one for
>>>>> responding your questions:
>>>>>
>>>>>
>>>>
>>>> *********************************************************************************** 
>>>>
>>>>
>>>>
>>>>> Definition:
>>>>> TDM Hairpinning
>>>>> ? is a scenario whereby a call is being made between two TDM 
>>>>> endpoints on
>>>>
>>>>
>>>>
>>>>
>>>> a
>>>>
>>>>>    single media gateway. The media comes in on one TDM channel and 
>>>>> goes
>>>>>    out on another TDM channel through the use of an internal loop 
>>>>> in the
>>>>>    media gateway.
>>>>>
>>>>> Note 1: due to the fact that there are local call types at local
>>>>
>>>>
>>>>
>>>>
>>>> exchanges
>>>>
>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PSTN,
>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types 
>>>>> behind the
>>>>> general "TDM hairpinning" capability (dependent on required type of 
>>>>> IWF,
>>>>> etc.) in corresponding H.248 MG types
>>>>>
>>>>> Note 2: H.248/MEGCOP perspective
>>>>> TDM Hairpinning = Single H.248 Context with 2 H.248 TDM Terminations
>>>>>
>>>>
>>>> ************************************************************************************ 
>>>>
>>>>
>>>>
>>>>> Based on this hairpinning understanding, my answers are:
>>>>>
>>>>> (1) Speech telephony service: G.711 companding formats are a 
>>>>> property of
>>>>> the corresponding H.248 TDM termination
>>>>>
>>>>> [Note: dependent on MG architecture and implementation, property 
>>>>> might be
>>>>> signalled or preprovisioned. Of course, G.711 companding law is an
>>>>
>>>>
>>>>
>>>>
>>>> inherent
>>>>
>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way, 
>>>>> how
>>>>> this DS0 property is associated with the corresponding H.248 TDM
>>>>> Termination property may only realized MG-internally for very 
>>>>> specific MG
>>>>> architectures. Generally it is up to the MGC, particularly if some (or
>>>>
>>>>
>>>>
>>>>
>>>> all)
>>>>
>>>>> DS0's are ISDN B channels.]
>>>>>
>>>>> (2) Voiceband Data services: same as in (1)
>>>>>
>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of
>>>>> interoperability, a V.152 compliant implementation shall support at 
>>>>> least
>>>>> both G.711 A-law and G.711 ì-law codecs as VBD codecs. "]
>>>>>
>>>>> (3) ISDN UDI = all ISDN Teleservices with ISDN I.231. bearer service
>>>>> requirement
>>>>> => H.248 TDM Termination property must be signalled by MGC, if not, MG
>>>>
>>>>
>>>>
>>>>
>>>> may
>>>>
>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bearer
>>>>> channel) in TDM hairpinning scenarios ...
>>>>>
>>>>>
>>>>> Conclusion:
>>>>> IF your MG is supporting
>>>>> PSTN lines (= H.248 ALN Termination),
>>>>> PSTN trunks (= H.248 TDM Termination), and
>>>>> ISDN B channels (= H.248 TDM Termination)
>>>>>
>>>>> AND IF you've such services and interworking requirements
>>>>>
>>>>> THEN you should generally signal the corresponding properties ...
>>>>>
>>>>> ... in case of
>>>>> TDM hairpinning,
>>>>> ALN hairpinning, or
>>>>> ALN-to-TDM connection types.
>>>>>
>>>>> Regards,
>>>>> Albrecht
>>>>>
>>>>> ALCATEL
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>>                      Zhao Bo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>                      <zbo <at> huawei.com>         To:      megaco <at> ietf.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>                      Sent by:                 cc:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>                      megaco-admin <at> iet         Subject: [Megaco] 
>>>>> Hairpin
>>>>
>>>>
>>>>
>>>>
>>>> case A/u Law conversion
>>>>
>>>>>                      f.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>                      25.02.2004 08:11
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> In this case, the A/u law format of a TDM ciruit can be 
>>>>> provisioned,  but
>>>>> the MG doesn't know the service type of a call, thus
>>>>> has no way to know if a conversion is needed. For speech service
>>>>
>>>>
>>>>
>>>>
>>>> conversion
>>>>
>>>>> may be needed; for data service like isdn UDI, conversion is not
>>>>
>>>>
>>>>
>>>>
>>>> permitted.
>>>>
>>>>> Is there any method to solve this problem?
>>>>>
>>>>> Zhao Bo
>>>>>
>>>>> *****************************************************************
>>>>> This e-mail and its attachments contain confidential information from
>>>>> HUAWEI, which is intended only for the person or entity whose 
>>>>> address is
>>>>> listed above. Any use of the information contained herein in any way
>>>>> (including, but not limited to, total or partial disclosure,
>>>>
>>>>
>>>>
>>>>
>>>> reproduction,
>>>>
>>>>> or dissemination) by persons other than the intended recipient(s) is
>>>>> prohibited. If you receive this e-mail in error, please notify the 
>>>>> sender
>>>>> by phone or email immediately and delete it!
>>>>> *****************************************************************
>>>>>
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> Megaco <at> ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Megaco mailing list
>>>>> Megaco <at> ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>> 1èr‰šŠX§‚X¬´Ç iÊ"z×è®m¶›?ÿ0Ö'­~Šàþf¢–f§þX¬¶)ߣùž§(
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco <at> ietf.org
>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>
>>
>> This communication is confidential and intended solely for the 
>> addressee(s). Any unauthorized review, use, disclosure or distribution 
>> is prohibited. If you believe this message has been sent to you in 
>> error, please notify the sender by replying to this transmission and 
>> delete the message without disclosing it. Thank you.
>>
>> E-mail including attachments is susceptible to data corruption, 
>> interruption, unauthorized amendment, tampering and viruses, and we 
>> only send and receive e-mails on the basis that we are not liable for 
>> any such corruption, interception, amendment, tampering or viruses or 
>> any consequences thereof.
>>
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
> 
ll | 6 Apr 09:02 2004

About DCME(digital Circuit Multiplication Equipment)

hi,everyone,
	Is there  a package for DCME(digital Circuit Multiplication Equipment)?

Best Regards

 				

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡lihu
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡l12381 <at> huawei.com
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2004-04-06
Christian Groves | 6 Apr 03:40 2004
Picon

ITU-SG16 Q.3 [Fwd: Notice of the Beijing meeting (11-14 May 2004)]

Hello all,

For your information, please find attached the invitation to the next SG16 
meeting Q.3 meeting where H.248 will be discussed. If you are interested in 
attending it is important to sort out the visa issues as soon as possible.

Regards, Christian

-------- Original Message --------
Subject: Notice of the Beijing meeting (11-14 May 2004)
Date: Thu, 1 Apr 2004 03:37:37 -0500 (EST)
From: OKUBO Sakae <okubo <at> MXZ.MESH.NE.JP>
To: itu-sg16 <at> external.cisco.com
CC: Pierre-Andre PROBST <probst-pa <at> bluewin.ch>

*** This notice and the host's information as attached will be ***
*** placed at <http://ftp3.itu.ch/av-arch/avc-site/0405_Bei/>. ***

To Experts of ITU-T SG16 Questions F, G, K, 2, 3, 4 and 5/16

Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa <at> bluewin.ch>
     Mr. M. Matsumoto, Vice-Chairman of SG16 <mmatsumoto <at> waseda.jp>
     Mr. S. Campos-Neto, ITU TSB <simao.campos <at> itu.int>
     Mr. L. Jiang, MII <jianglt <at> public.bta.net.cn>
     Ms. Y. Shen, MII <shenyaqin <at> catr.com.cn>
     Mr. C. Hansen, Rapporteur for Q.B/16 <chris.hansen <at> INTEL.COM>,
     Mr. P. Luthi, Rapporteur for Q.1/16 <patrick.luthi <at> TANDBERG.NO>

De S-H. Jeong   Rapporteur for Q.F/16 <shjeong <at> hufs.ac.kr>
     M. Euchner   Rapporteur for Q.G/16 <Martin.Euchner <at> siemens.com>
     L. Lehmann   Rapporteur for Q.K/16 <Leo.Lehmann <at> bakom.admin.ch>
     P. Jones     Rapporteur for Q.2/16 <paulej <at> packetizer.com>
     C. Groves    Rapporteur for Q.3/16 <Christian.Groves <at> ericsson.com.au>
     S. Okubo     Rapporteur for Q.4/16 <sokubo <at> waseda.jp>
     R. Gilman    Rapporteur for Q.5/16 <rrg <at> avaya.com>

     -------------------------------------------------------------------
     Subject: Notice of Joint Rapporteur Meeting in Beijing, China
     Date:    31 March 2004
     -------------------------------------------------------------------

Dear experts of Questions F, G, K, 2-5/16,

The subject meeting of ITU-T SG16 experts will be held in Beijing,
China at the kind invitation of China Academy of Telecommunications
Research of MII and China Communications Standards Association. Details
of the meeting are contained herein.

Please note that Q.B/16 and Q.1/16 may meet concurrently and we will
have joint sessions with these Questions in that case.

1. Date
^^^^^^^

      11 (Tuesday) - 14 (Friday) May 2004
      Meeting will start at 9:00 AM on the first day
      Closing around 18:00 on the final day

2. Venue
^^^^^^^^

GUANGZHOU HOTEL
No.A3, Xi Dan Heng Er Tiao,
Xicheng District, Beijing,
China
Tel: +86 10 66078866
Fax: +86 10 66085998
Post Code: 100031

3. Topics (tentative)
^^^^^^^^^^^^^^^^^^^^^

1) Review of the relevant group activities

2) Q.F/16 Quality of Service and End-to-end Performance in Multimedia
     Systems

      - Progress work for:
          * Annex N H.323
          * H.priority
          * H.trans.cont

3) Q.G/16 Security of Multimedia Systems and Services

      - Progress work for:
          * H.235 Annex G
          * other study items in the living list (TD-71/WP2, January 2004)

4) Q.K/16 Mobility for Multimedia Systems and Services

      - Further elaboration TD-53/WP2 (January 2004)
      - Mobility aspects of presence service; co-ordination with Q.2/16
      - Study of new service features
      - Follow up workplan

5) Q.2/16 Multimedia over packet networks using H.323 systems

      - Progress work for:
          * H.460.tppr
          * H.460.trans
          * H.460.relreq
          * H.gaam
          * H.323 Annexes I & N
          * H.323 Annexes Dv3, Gv2, Ov2
          * H.sms
          * H.presence

6) Q.3/16 Infrastructure and interoperability for Multimedia over
            packet networks

      - Progress work for:
          * H.248-subseries
          * H.245 v11
          * H.341

7) Q.4/16 Video and data conferencing using Internet-supported services

      - H.350-series maintenance
      - Addition to H.350-series
      - Presence use scenarios
      - Study of new service features

8) Q.5/16 Control of NAT and Firewall Traversal for Multimedia Systems

      - Progress NAT/firewall traversal methods

9) Interaction with other groups

      - NGN
      - Others

10) Future work plan

4. Documents
^^^^^^^^^^^^

   /// Registration of the document: by 23:59 UTC, 30 April 2004 ///
   /// Distribution of the document: by 23:59 UTC, 4 May 2004    ///
   /// Use the ftp site (or e-mail reflector) for distribution   ///

1)     When you are going to submit a document, please notify
         Paul Jones <paulej <at> packetizer.com>, document manager of this
         meeting, as soon as possible, by 23:59 UTC, Friday 30 April 2004
         at the latest. Document number AVD-nnnn will be allocated. Early
         indication of your submission plan is welcome and encouraged.

Note: Prefix "AVD" comes from Audio, Video and Data.

2)     You are advised to include a header as follows:

   ------------------------------------------------------------------
|                                                                  |
| ITU Telecommunication Standardization Sector  Document AVD-{nnnn}|
| Study Group 16                            {Version m if relevant}|
| Q.F, G, K, 2-5/16 Rapporteur Meeting                       {Date}|
| Beijing, 11-14 May 2004                                          |
|                                                                  |
| SOURCE*: {                                               }       |
| TITLE  : {                                               }       |
| PURPOSE: {Proposal, Discussion, Information, Report, etc.}       |
|                                                                  |
|                       _________________________                  |
|                                                                  |
|                                                                  |
|                                                                  |
|  *Contact: Name, e-mail                                          |
   ------------------------------------------------------------------

Note: A template for the AVD document can be found at:
        <http://ftp3.itu.ch/av-arch/avc-site/0405_Bei/AVD-template.doc>
        This may be modified and used for the purpose of document submission
        at this meeting.

3)     File format: Use of Word, PDF, ASCII or HTML is recommended.

4)     All the contributors are requested to distribute their documents
         as early as possible, at least 7 calendar days in advance of the
         meeting (23:59 UTC, Tuesday 4 May 2004 or before) by posting
         them at either of the following:

    - Uploading via FTP
          Site:     ftp3.itu.int/
          User ID:  avguest
          Password: Avguest  (Note the uppercase 'A')
          Directory: avc-site/Incoming

    - E-mail reflector

          E-mail address: itu-sg16 <at> external.cisco.com
          To subscribe:
              Send e-mail to majordomo <at> cisco.com
              In the body of the message, put: subscribe itu-sg16

Please avoid the use of reflector when your document is voluminous.

5)     Input documents can be retrieved from /0405_Bei directory of the
         ftp site once Mr. Jones has an opportunity to put them into
         place.

         The documents will also be available through the following URLs:
             http://ftp3.itu.int/av-arch/avc-site/0405_Bei/
             ftp://avguest:Avguest <at> ftp3.itu.int/avc-site/0405_Bei/

6)     The document distribution / presentation at the meeting will be
         all electronic.  Participants must bring along a laptop and
         802.11b wireless card in order to access the documents.

5. Logistic information
^^^^^^^^^^^^^^^^^^^^^^^

The meeting will be hosted by China Academy of Telecommunications
Research of MII and China Communications Standards Association.

Please refer to the participants' information document kindly prepared
by the host, which is available at:
    <http://ftp3.itu.int/av-arch/avc-site/0405_Bei/Participants-info.zip>

6. Registration
^^^^^^^^^^^^^^^

To register your meeting attendance, please send the Meeting
Registration / Hotel Room Reservation Form provided by the host in the
participants' information document to
      Ms. Jiang Hong <jianghong <at> catr.com.cn>
with copy to
      Ms.Yaqin Shen <shenyaqin <at> catr.com.cn> and
      CCSA <ccsacontact <at> ccsa.org.cn>
by 28 April 2004.

7. Hotel Room Reservation
^^^^^^^^^^^^^^^^^^^^^^^^^

You are recommended to stay at GUANGZHOU HOTEL, the meeting place. For
room reservation, please indicate the dates of your stay in the Meeting
Registration / Hotel Room Reservation Form.

We are looking forward to meeting with you in Beijing.

       Sincerely yours,

       Seong-ho JEONG
       Martin EUCHNER
       Robert GILMAN
       Paul JONES (document manager of this meeting)
       Christian GROVES
       Sakae OKUBO (meeting organizer of this meeting)
       Leo LEHMANN

                                     ----------

Attachment (Participants-info_Beijing.doc): application/msword, 81 KiB

Gmane