From Albrecht.Schwarz@alcatel-lucent.com Thu Mar 4 06:21:59 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F58428C141 for ; Thu, 4 Mar 2010 06:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbsS6bbZv5DY for ; Thu, 4 Mar 2010 06:21:45 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5F06A28C13D for ; Thu, 4 Mar 2010 06:21:42 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o24ELV5d019310; Thu, 4 Mar 2010 15:21:38 +0100 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 15:21:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABBA6.0007247A" Date: Thu, 4 Mar 2010 15:21:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AVD-3878 H.248.SDPMapper: "m="-line with multiple transport elements Thread-Index: Acq7pf+dB+v03zHzT5ex+MgZb2QHaQ== From: "Schwarz Albrecht" To: , "Tommy Young" X-OriginalArrivalTime: 04 Mar 2010 14:21:37.0728 (UTC) FILETIME=[0049C400:01CABBA6] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: CHEN Fei A , megaco@ietf.org, Stoetzer-Bradler Juergen Subject: [Megaco] AVD-3878 H.248.SDPMapper: "m="-line with multiple transport elements X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 14:22:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABBA6.0007247A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Christian, Tommy, =20 got a question for clarification: the highlighted "m=3D"-line below, with multiple transport elements, is syntactically not possible with RFC 4566 (2327), but feasible in H.248 due to the alternative option in 7.1.8.1.1.1/H.248.1. Right? Thanks, Albrecht =20 ____H.248.1 _____________________________________________________ =20 7.1.8.1.1 Specific syntax for H.248 text encoding 7.1.8.1.1.1 Rules When text encoding the protocol, the descriptors consist of session descriptions as defined in SDP ([IETF RFC 2327]). In session descriptions sent from the MG to the MGC, the SDP must comply with [IETF RFC 2327]. In session descriptions sent from the MGC to the MG, the following exceptions to the syntax of [IETF RFC 2327] are allowed: * the "s =3D ", "t =3D " and "o =3D " lines are optional; * the use of CHOOSE is allowed in place of a single parameter value; and * the use of alternatives is allowed in place of a single parameter value. ... =20 ____ AVD-3878 _____________________________________________________ http://wftp3.itu.int/av-arch/avc-site/2009-2012/1003_Sha/AVD-3878.zip =20 6.1.2 Relationship with the H.248 Reserve Value concept SDPCapNeg also allows the ability to specify alternatives (via the use of "|") in configuration lists. The MGC can also provide this functionality via the use of over specified property values (or SDP parameters as per ITU-T H.248.39). Over specification of properties is equivalent to providing alternatives which effectively is a "or" function in the same way as "|". For example, given the following Revised Offer/Answer SDP: v=3D0=20 o=3D- 25678 753849 IN IP4 192.0.2.1=20 s=3D =20 c=3DIN IP4 192.0.2.1=20 t=3D0 0=20 m=3Daudio 53456 RTP/AVPF 0 18 =20 a=3Dtcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF=20 a=3Dpcfg:1 t=3D2|1 a=3D1=20 The MGC would construct the following SDP for the first H.248 Group: v=3D0=20 o=3D- 25678 753849 IN IP4 192.0.2.1=20 s=3D =20 c=3DIN IP4 192.0.2.1=20 t=3D0 0=20 m=3Daudio 53456 RTP/AVP RTP/AVPF 0 18 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CABBA6.0007247A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 Christian, Tommy,
 
got a=20 question for clarification:
the=20 highlighted "m=3D"-line below, with = multiple transport=20 elements, is syntactically not possible with RFC 4566 (2327), but = feasible in=20 H.248 due to the alternative option in=20 7.1.8.1.1.1/H.248.1.
Right?
Thanks,
Albrecht
 
____H.248.1=20 _____________________________________________________
=
 
7.1.8.1.1   Specific syntax for H.248 = text=20 encoding
7.1.8.1.1.1         =20 Rules

When text = encoding the=20 protocol, the descriptors consist of session descriptions as defined in = SDP=20 ([IETF RFC 2327]). In session descriptions sent from the MG to the = MGC, the=20 SDP must comply with [IETF RFC 2327]. =20 In session descriptions sent from the MGC to the MG, the = following=20 exceptions to the syntax of [IETF RFC 2327] are=20 allowed:

•           =20 the "s =3D ", "t =3D " and "o =3D " lines are=20 optional;

•           =20 the use of CHOOSE is allowed in place of a single parameter = value;=20 and

•           =20 the use of alternatives is allowed in place = of a=20 single parameter=20 value.

...
 
____=20 AVD-3878=20 _____________________________________________________
=
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1003_Sha/AVD-3878.z= ip
 

6.1.2    =20 Relationship with the = H.248 Reserve=20 Value concept

SDPCapNeg=20 also allows the ability to specify alternatives (via the use of = “|”) in=20 configuration lists. The MGC can also provide this functionality via the = use of=20 over specified property values (or SDP parameters as per ITU-T = H.248.39). Over=20 specification of properties is equivalent to providing alternatives = which=20 effectively is a “or” function in the same way as = “|”.

For example,=20 given the following Revised Offer/Answer SDP:

      v=3D0=20 

      o=3D- =
25678 753849 IN IP4 192.0.2.1 =

      s=3D  =

      c=3DIN IP4 192.0.2.1 =

      t=3D0 0 =

      m=3Daudio 53456 RTP/AVPF =
0 18  =

      a=3Dtcap:1 RTP/AVPF =
RTP/AVP RTP/SAVP RTP/SAVPF 
      a=3Dpcfg:1 =
t=3D2|1 =
a=3D1

The=20 MGC would construct the following SDP for the first H.248=20 Group:

      v=3D0=20 

      o=3D- =
25678 753849 IN IP4 192.0.2.1 =

      s=3D  =

      c=3DIN IP4 192.0.2.1 =

      t=3D0 0 =

      m=3Daudio 53456 RTP/AVP =
RTP/AVPF 0 18  =

 

 
 
 
------_=_NextPart_001_01CABBA6.0007247A-- From Christian.Groves@nteczone.com Thu Mar 4 19:51:03 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D17028C164 for ; Thu, 4 Mar 2010 19:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWxb1raWS7xC for ; Thu, 4 Mar 2010 19:51:02 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by core3.amsl.com (Postfix) with ESMTP id C149428C0CF for ; Thu, 4 Mar 2010 19:51:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBACQMkEt20cCW/2dsb2JhbAAH1DGEfQSJcA Received: from ppp118-209-192-150.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.192.150]) by ipmail07.adl2.internode.on.net with ESMTP; 05 Mar 2010 14:21:02 +1030 Message-ID: <4B907FA2.60802@nteczone.com> Date: Fri, 05 Mar 2010 14:50:58 +1100 From: Christian Groves User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Schwarz Albrecht References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: CHEN Fei A , megaco@ietf.org, Stoetzer-Bradler Juergen Subject: Re: [Megaco] AVD-3878 H.248.SDPMapper: "m="-line with multiple transport elements X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 03:51:03 -0000 Hello Albrecht, Yes that is correct. Regards, Christian Schwarz Albrecht wrote: > Hello Christian, Tommy, > got a question for clarification: > the highlighted "m="-line below, with multiple transport elements, is > syntactically not possible with RFC 4566 (2327), but feasible in H.248 > due to the alternative option in 7.1.8.1.1.1/H.248.1. > Right? > Thanks, > Albrecht > ____H.248.1 _____________________________________________________ > > > 7.1.8.1.1 Specific syntax for H.248 text encoding > > > 7.1.8.1.1.1 Rules > > When text encoding the protocol, the descriptors consist of session > descriptions as defined in SDP ([IETF RFC 2327]). In session > descriptions sent from the MG to the MGC, the SDP must comply with > [IETF RFC 2327]. In session descriptions sent from the MGC to the MG, > the following exceptions to the syntax of [IETF RFC 2327] are allowed: > > • the "s = ", "t = " and "o = " lines are optional; > > • the use of CHOOSE is allowed in place of a single parameter value; and > > • the use of alternatives is allowed in place of a single parameter value. > > ... > ____ AVD-3878 _____________________________________________________ > http://wftp3.itu.int/av-arch/avc-site/2009-2012/1003_Sha/AVD-3878.zip > > > 6.1.2 Relationship with the H.248 Reserve Value concept > > SDPCapNeg also allows the ability to specify alternatives (via the use > of “|”) in configuration lists. The MGC can also provide this > functionality via the use of over specified property values (or SDP > parameters as per ITU-T H.248.39). Over specification of properties is > equivalent to providing alternatives which effectively is a “or” > function in the same way as “|”. > > For example, given the following Revised Offer/Answer SDP: > > v=0 > > o=- 25678 753849 IN IP4 192.0.2.1 > s= > c=IN IP4 192.0.2.1 > t=0 0 > m=audio 53456 RTP/AVPF 0 18 > a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF > a=pcfg:1 t=2|1 a=1 > > The MGC would construct the following SDP for the first H.248 Group: > > v=0 > > o=- 25678 753849 IN IP4 192.0.2.1 > s= > c=IN IP4 192.0.2.1 > t=0 0 > m=audio 53456 RTP/AVP RTP/AVPF 0 18 > From Christian.Groves@nteczone.com Thu Mar 4 19:53:24 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD5528C139 for ; Thu, 4 Mar 2010 19:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23cEzIAj+GTx for ; Thu, 4 Mar 2010 19:53:23 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by core3.amsl.com (Postfix) with ESMTP id 2FA7928C0CF for ; Thu, 4 Mar 2010 19:53:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBACQMkEt20cCW/2dsb2JhbAAH1DGEfQQ Received: from ppp118-209-192-150.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.192.150]) by ipmail07.adl2.internode.on.net with ESMTP; 05 Mar 2010 14:23:25 +1030 Message-ID: <4B908032.5010402@nteczone.com> Date: Fri, 05 Mar 2010 14:53:22 +1100 From: Christian Groves User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Megaco] H.248 Related contributions for March ITU-T Q.3/16 meeting X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 03:53:24 -0000 Hello all, The documents for next weeks ITU-T Q.3/16 meeting can be found at: http://wftp3.itu.int/av-arch//avc-site/2009-2012/1003_Sha/1003_Sha.html The agenda is in TD-03. Regards, Christian From Francois.Plagnard@enea.com Wed Mar 10 02:45:47 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210BB3A694C for ; Wed, 10 Mar 2010 02:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mURccujhnZ7j for ; Wed, 10 Mar 2010 02:45:46 -0800 (PST) Received: from mx-3.enea.com (mx-3.enea.com [192.36.1.72]) by core3.amsl.com (Postfix) with ESMTP id 2E6463A68CF for ; Wed, 10 Mar 2010 02:45:45 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 11:45:46 +0100 Message-ID: In-Reply-To: <4B1B9554.2040506@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unsupported embedded signal Thread-Index: Acp2ZzxTgWkXpWHWTqSC+m5ahhBuLxJ1vLUg From: =?iso-8859-1?Q?Fran=E7ois_Plagnard?= To: Subject: [Megaco] Unsupported embedded signal X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 10:45:47 -0000 Hello, What must do a gateway when it receives a requested event with an = embedded signal which is not supported by the gateway? Must the gateway reject the command or must it accept the event even if = it cannot play the signal? Best regards, =20 -------------------------------------------- Fran=E7ois Plagnard =20 ENEA Netbricks --------------------------------------------- =20 From Albrecht.Schwarz@alcatel-lucent.com Thu Mar 11 19:16:57 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717873A6A2C for ; Thu, 11 Mar 2010 19:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q372IJ9eHdTd for ; Thu, 11 Mar 2010 19:16:55 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 4EC413A6359 for ; Thu, 11 Mar 2010 19:16:54 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2C3GrnE029054; Fri, 12 Mar 2010 04:16:53 +0100 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 04:16:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Mar 2010 04:16:51 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Unsupported embedded signal Thread-Index: Acp2ZzxTgWkXpWHWTqSC+m5ahhBuLxJ1vLUgAFTojvA= References: <4B1B9554.2040506@nteczone.com> From: "Schwarz Albrecht" To: =?iso-8859-1?Q?Fran=E7ois_Plagnard?= , X-OriginalArrivalTime: 12 Mar 2010 03:16:53.0396 (UTC) FILETIME=[76ADAD40:01CAC192] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Megaco] Unsupported embedded signal X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 03:16:57 -0000 In general, an H.248 Profile-less operated H.248 Control Association, = the MG shall reply with an appropriate (H.248.8) error code. It's a = master-slave relationship, thus the master got to known whether = requested actions are executed or not. The other scenario might be that the H.248 CA is operated in "profile = mode", i.e. the MG did register with a ProfileID. A profile specification allows to specify the details of package usage, = e.g. whether a signal is mandatory or optional, and the particular MG = behaviour. Did you refer to a specific profile definition, Fran=E7ois? -Albrecht =20 > -----Original Message----- > From: megaco-bounces@ietf.org=20 > [mailto:megaco-bounces@ietf.org] On Behalf Of Fran=E7ois Plagnard > Sent: Mittwoch, 10. M=E4rz 2010 11:46 > To: megaco@ietf.org > Subject: [Megaco] Unsupported embedded signal >=20 > Hello, >=20 > What must do a gateway when it receives a requested event=20 > with an embedded signal which is not supported by the gateway? >=20 > Must the gateway reject the command or must it accept the=20 > event even if it cannot play the signal? >=20 > Best regards, > =20 > -------------------------------------------- > Fran=E7ois Plagnard > =20 > ENEA Netbricks > --------------------------------------------- > =20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco >=20 From Thiago.Kleinke@keymile.com Wed Mar 17 07:45:07 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBD83A6CE9 for ; Wed, 17 Mar 2010 07:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2+Uyv+CtRqK for ; Wed, 17 Mar 2010 07:45:06 -0700 (PDT) Received: from mail.ch.keymile.com (mail.ch.keymile.com [193.17.201.103]) by core3.amsl.com (Postfix) with SMTP id EA5693A6CF2 for ; Wed, 17 Mar 2010 07:37:03 -0700 (PDT) Received: from SRVCHBER1212.ch.keymile.net ([172.31.32.9]) by eSafe SMTP Relay 1266768427; Wed, 17 Mar 2010 15:27:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC5DF.52626C61" Date: Wed, 17 Mar 2010 15:35:56 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MG answer DTMF Relay Thread-Index: AcrF3yexiEgw8TU1TWSmbpIIY3qCYw== From: "Kleinke, Thiago" To: X-ESAFE-STATUS: Mail allowed X-ESAFE-DETAILS: Cc: "Rezende, Daniel" Subject: [Megaco] MG answer DTMF Relay X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 14:45:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC5DF.52626C61 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Guys, =20 Is there any difference when MG sends the following answer: =20 a=3Drtpmap:101 telephone-event/8000/0 =20 instead of: =20 a=3Drtpmap:101 telephone-event/8000 =20 Will MGC drop this information because of /0? =20 Regards, =20 Thiago Willian Kleinke =20 ------_=_NextPart_001_01CAC5DF.52626C61 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Guys,

 

Is there any difference when MG = sends the following answer:

 

a=3Drtpmap:101 = telephone-event/8000/0

 

instead = of:

 

a=3Drtpmap:101 = telephone-event/8000

 

Will MGC drop this information = because of /0?

 

Regards,

 

Thiago Willian Kleinke

 

------_=_NextPart_001_01CAC5DF.52626C61-- From Albrecht.Schwarz@alcatel-lucent.com Wed Mar 17 19:15:02 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F1C3A67A6 for ; Wed, 17 Mar 2010 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.564 X-Spam-Level: X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpxBEfqwCaZ5 for ; Wed, 17 Mar 2010 19:15:01 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 365483A67DF for ; Wed, 17 Mar 2010 19:15:00 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2I2F9Xw030606; Thu, 18 Mar 2010 03:15:09 +0100 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 03:15:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC640.D5041192" Date: Thu, 18 Mar 2010 03:15:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] MG answer DTMF Relay Thread-Index: AcrF3yexiEgw8TU1TWSmbpIIY3qCYwAXuysg References: From: "Schwarz Albrecht" To: "Kleinke, Thiago" , X-OriginalArrivalTime: 18 Mar 2010 02:15:09.0197 (UTC) FILETIME=[D54843D0:01CAC640] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "Rezende, Daniel" Subject: Re: [Megaco] MG answer DTMF Relay X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 02:15:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC640.D5041192 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your question got two parts, one related to SDP and the other one to = H.248: =20 1) SDP The SDP line is syntactically correct as you know, see RFC 4566. The encoding parameter is optional, dependent on ... Thus you should raise your question on: https://www.ietf.org/mailman/listinfo/mmusic = =20 https://www.ietf.org/mailman/listinfo/avt = =20 a=3Drtpmap: / [/] The particular SDP line is semantically questionable, see RFC 4733. = Because there is not any semantic defined for the encoding parameter for = telephone-events. At least to my knowledge. =20 2) H.248 > Is there any difference when MG sends the following answer: ... Your question is incomplete because your should first provide the MGC = request command. The MG reply is dependent on the request command, e.g. whether = wildcarding is used in the SDP line. Or if the MGC did request a full = specified "a=3D" line, which is supported by the MG, then the MG has to = omit the SDP line in the reply. Thus your example looks strange (at least requires more background). =20 -Albrecht =20 ________________________________ From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On = Behalf Of Kleinke, Thiago Sent: Mittwoch, 17. M=E4rz 2010 15:36 To: megaco@ietf.org Cc: Rezende, Daniel Subject: [Megaco] MG answer DTMF Relay =09 =09 Guys, =20 Is there any difference when MG sends the following answer: =20 a=3Drtpmap:101 telephone-event/8000/0 =20 instead of: =20 a=3Drtpmap:101 telephone-event/8000 =20 Will MGC drop this information because of /0? =20 Regards, =20 Thiago Willian Kleinke =09 =09 =20 ------_=_NextPart_001_01CAC640.D5041192 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Your question got two parts, one related to = SDP and the=20 other one to H.248:
 
1) SDP
The SDP line is syntactically correct as you = know, see=20 RFC 4566.
The encoding parameter is optional, dependent = on=20 ...
Thus you should raise your question=20 on:
https://www.ietf.org/mailman/listinfo/avt
 a=3Drtpmap:<payload =
type> <encoding name>/<clock rate> [/<encoding
         parameters>]


The particular SDP line is =
semantically questionable, see RFC 4733. Because there is not any =
semantic defined for the encoding parameter for =
telephone-events.
At least to my =
knowledge.
 
2) H.248
> Is there any difference when MG sends the following =
answer: ...
Your question is incomplete because your = should first=20 provide the MGC request command.
The MG reply is dependent on the request = command, e.g.=20 whether wildcarding is used in the SDP line. Or if the MGC did request a = full=20 specified "a=3D" line, which is supported by the MG, then the MG has to = omit the=20 SDP line in the reply.
Thus your example looks strange (at least = requires more=20 background).
 
-Albrecht
 

From: megaco-bounces@ietf.org=20 [mailto:megaco-bounces@ietf.org] On Behalf Of Kleinke,=20 Thiago
Sent: Mittwoch, 17. M=E4rz 2010 15:36
To:=20 megaco@ietf.org
Cc: Rezende, Daniel
Subject: = [Megaco] MG=20 answer DTMF Relay

Guys,

 

Is there any difference when = MG sends the=20 following answer:

 

a=3Drtpmap:101=20 telephone-event/8000/0

 

instead = of:

 

a=3Drtpmap:101=20 telephone-event/8000

 

Will MGC drop this information = because of=20 /0?

 

Regards,

 

Thiago=20 Willian Kleinke

 

------_=_NextPart_001_01CAC640.D5041192-- From Christian.Groves@nteczone.com Tue Mar 30 20:38:15 2010 Return-Path: X-Original-To: megaco@core3.amsl.com Delivered-To: megaco@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47493A6A45 for ; Tue, 30 Mar 2010 20:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Q3cHZ4ng0G for ; Tue, 30 Mar 2010 20:38:15 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by core3.amsl.com (Postfix) with ESMTP id 381AA3A6882 for ; Tue, 30 Mar 2010 20:38:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAA9fskt20SvR/2dsb2JhbAAH3DuFAAQ Received: from ppp118-209-43-209.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.43.209]) by ipmail05.adl6.internode.on.net with ESMTP; 31 Mar 2010 14:08:39 +1030 Message-ID: <4BB2C3BE.2020701@nteczone.com> Date: Wed, 31 Mar 2010 14:38:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: megaco ietf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Megaco] Results of the Q.3/16 Meeting in Shanghai X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 03:38:16 -0000 Hello all, For those interesting in the results of the Shanghai meeting and the latest drafts of the current work items please see: http://ftp3.itu.int/av-arch/avc-site/2009-2012/1003_Sha/1003_Sha.html The meeting report is in TD-10. Regards, Christian