From albrecht.schwarz@alcatel-lucent.com Mon Jun 3 01:13:01 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256B921F935A; Mon, 3 Jun 2013 01:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBF0zWsSFp9l; Mon, 3 Jun 2013 01:12:32 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BD93B21F92F5; Mon, 3 Jun 2013 01:11:15 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r538AQDm021293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Jun 2013 03:10:26 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r538AHwO017294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 04:10:26 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 3 Jun 2013 04:10:22 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.41]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 3 Jun 2013 10:10:10 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: 3GPP RTP header extension Thread-Index: Ac5YY467f6iD3KE+RZKtUYPDcgGk6wHzLKGw Date: Mon, 3 Jun 2013 08:10:10 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC046CF5@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C377766@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "megaco@ietf.org" , "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Subject: Re: [Megaco] 3GPP RTP header extension X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 08:13:09 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The subject was also on the agenda of 3GPP CT4 at last meeting. It may be noted that RFC 5285 is special with regards to the definition of = two capabilities of a) IP data path (RTP header extension; clause 4/RFC 5285) and b) IP signaling path (SDP signalling; ; clauses 5&6/RFC 5285) in a single RFC. Both capabilities could be also defined in separated RFCs. The tight coupling of both capabilities in a single RFC may be interpreted = in the following: the network should not forward RTP packets with extended = headers in case of missing SDP "a=3Dextmap:" signalling or/and failed SDP O= /A. E.g., an interim RTP translator (RTP transport translator or RTP media tran= slator) would block RTP packets with extension headers (dependent on above = SDP O/A ...). Conclusion: there seems to be some implicit semantics in RFC 5285 in my understanding. Regards, Albrecht From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: Freitag, 24. Mai 2013 12:06 To: mmusic@ietf.org Subject: [MMUSIC] 3GPP RTP header extension Hi, In the virtual interim meeting yesterday, I was requested to look into the = RTP header extension(s) defined by 3GPP. 3GPP SA4 has defined a header extension for "Coordination of Video Orientat= ion" purpose (may be of interest for CLUE btw, but that's a separate story)= . The length of the extension is 1 byte. For more information, see section 7.4.5 of 3GPP TS 24.114 :) http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-c10.zip Regards, Christer --_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The subject was also on the a= genda of 3GPP CT4 at last meeting.

 

It may be noted that RFC 5285= is special with regards to the definition of two capabilities of

a) IP data path (RTP header e= xtension; clause 4/RFC 5285) and

b) IP signaling path (SDP sig= nalling; ; clauses 5&6/RFC 5285)

in a single RFC. Both capabil= ities could be also defined in separated RFCs.

 

The tight coupling of both ca= pabilities in a single RFC may be interpreted in the following: the network= should not forward RTP packets with extended headers in case of missing SDP “a=3Dextmap:” signalling or/and failed = SDP O/A.

 

E.g., an interim RTP translat= or (RTP transport translator or RTP media translator) would block RTP packe= ts with extension headers (dependent on above SDP O/A …).

 

Conclusion:=

there seems to be some implic= it semantics in RFC 5285 in my understanding.

 

Regards,

Albrecht

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.o= rg] On Behalf Of Christer Holmberg
Sent: Freitag, 24. Mai 2013 12:06
To: mmusic@ietf.org
Subject: [MMUSIC] 3GPP RTP header extension

 

Hi,

 

In the virtual interim meeting = yesterday, I was requested to look into the RTP header extension(s) defined= by 3GPP.

 

3GPP SA4 has defined a header e= xtension for “Coordination of Video Orientation” purpose (may b= e of interest for CLUE btw, but that’s a separate story). The length = of the extension is 1 byte.

 

For more information, see secti= on 7.4.5 of 3GPP TS 24.114 :)

 

http://www.3gpp.org/ftp/S= pecs/archive/26_series/26.114/26114-c10.zip

 

Regards,

 

Christer

--_000_786615F3A85DF44AA2A76164A71FE1AC046CF5FR711WXCHMBA03zeu_-- From albrecht.schwarz@alcatel-lucent.com Wed Jun 19 04:20:40 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3552121F9A08; Wed, 19 Jun 2013 04:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFgVxKr99ikg; Wed, 19 Jun 2013 04:20:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBE21F99FB; Wed, 19 Jun 2013 04:20:34 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r5JBKRQj001944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2013 06:20:27 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5JBKRfD009438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 07:20:27 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Jun 2013 07:20:17 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 19 Jun 2013 13:19:55 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , Hadriel Kaplan , "" Thread-Topic: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types Thread-Index: AQHOalAj8gpobm3rD0OdKV/RhKM1q5k36qyAgAT7yiA= Date: Wed, 19 Jun 2013 11:19:54 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC068C36@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <20130615192422.22852.89043.idtracker@ietfa.amsl.com> <786615F3A85DF44AA2A76164A71FE1AC065CCF@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C39C367@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C39C367@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "megaco@ietf.org" Subject: Re: [Megaco] [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:20:40 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Christer, Hadriel, I don't want to delay the publication. Don't see any principle issue, too. In case of a future revision of this RFC, then it might be beneficial to tr= y to add a term definition for B2BUA (because the whole taxonomy is actuall= y based on this term). 2nd I suppose a difference between B2BUA vs PROXY, hence might be worth as = well to point out differences. Personally, I could see following resolution proposal (based on ITU terms): Background: the subject as such was studied in Y.1251 (http://www.itu.int/r= ec/dologin_pub.asp?lang=3De&id=3DT-REC-Y.1251-200208-I!!PDF-E&type=3Ditems = ). Possible definition of term "B2BUA": B2BUA: provides a service interworking function (according clause 3.2/ITU-= T Y.1251) with following limitations, 1. network planes: only IP control and IP user plane; 2. protocol stack: same protocol at each side of the service interwor= king function. NOTE 1: hence, a B2BUA is not a proxy. Proxy (derived from ITU-T Y.2902): A system authorized to work on behalf of= another system including responding to protocol requests. NOTE 1: hence, a proxy does not provide any interworking function (neither = service interworking nor network interworking). NOTE 2: a proxy as network element is an intermediary node in the sense of = identical protocol stacks at incoming and outgoing interfaces of the proxy. SIP B2BUA: provides a B2BUA function with for the SIP, i.e., a service in= terworking function (according clause 3.2/ITU-T Y.1251) in the IP control p= lane. NOTE: the service interworking function may include as well the interworkin= g of the protocol stack for SIP transport (e.g., SIP-over-UDP/IP4 to SIP-ov= er-SCTP/IPv6 interworking). ... and then subsequent, derived term definitions for media plane B2BUA back-to-back IP host etc Just some thoughts, Albrecht -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Sonntag, 16. Juni 2013 11:04 To: Schwarz, Albrecht (Albrecht); Hadriel Kaplan; Subject: VS: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway mo= del and media plane b2bua types (As co-chair) Hi Albrecht, I do appreciate the fact that you have taken a look at the draft, and studi= ed its applicability from a SG16 perspective. In the conclusion part, you ask whether there is a need to provide feedback= to STRAW. Keep in mind that the WGLC for the draft has finished, and that publication= has been requested by the chairs. Now, that does not prevent us from taking the draft back to the WG, and do = changes, but in order for that to happen there normally has to be some issu= es that need to be changed/addressed in order to publish the document as an= RFC. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: straw-bounces@ietf.org [mai= lto:straw-bounces@ietf.org] Puolesta Schwarz, Albrecht (Albrecht) L=E4hetetty: 16. kes=E4kuuta 2013 8:13 Vastaanottaja: Hadriel Kaplan; > Aihe: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and= media plane b2bua types Hi Hadriel, fyi, some high-level comments to the taxonomy draft from perspective of dec= omposed SBCs (according H.248 model) http://ftp3.itu.int/av-arch/avc-site/2= 013-2016/1306_Osl/AVD-4391.zip Regards, Albrecht _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw --_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Christer, Hadriel,

 

I don't want to delay the pu= blication.

Don't see any principle issu= e, too.

 

In case of a future revision= of this RFC, then it might be beneficial to try to add a term definition f= or B2BUA (because the whole taxonomy is actually based on this term).<= /o:p>

2nd I suppose a difference b= etween B2BUA vs PROXY, hence might be worth as well to point out difference= s.

 

Personally, I could see foll= owing resolution proposal (based on ITU terms):

Background: the subject as s= uch was studied in Y.1251 (http://w= ww.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-Y.1251-200208-I!!PDF= -E&type=3Ditems ).

 

Possible definition of term “B2BUA&= #8221;:

 

B2BUA:  provides a service interworking function (according clause 3.2/IT= U-T Y.1251) with following limitations,

1. &nb= sp;     network plane= s: only IP control and IP user plane;

2. &nb= sp;     protocol stac= k: same protocol at each side of the service interworking function.

NOTE 1: hence, a B2BUA is not a proxy.

 

Proxy (derived from ITU-T Y.2902): A system authorized to work on behalf of another system inc= luding responding to protocol requests.

NOTE 1: hence, a proxy does not provide any interworking function (neither service interw= orking nor network interworking).

NOTE 2: a proxy as network element is an intermediary node in the sense of identical protocol stacks at incom= ing and outgoing interfaces of the proxy.

 

SIP B2BUA:   provides a B2BUA function with for the SIP, i.e., a service in= terworking function (according clause 3.2/ITU-T Y.1251) in the IP control plane.

NOTE: the service interworking function may = include as well the interworking of the protocol stack for SIP transport (e= .g., SIP-over-UDP/IP4 to SIP-over-SCTP/IPv6 interworking).

 

… and then subsequent,= derived term definitions for

media plane B2BUA=

back-to-back IP host

etc

 

Just some thoughts,

Albrecht

 

 

-----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sonntag, 16. Juni 2013 11:04
To: Schwarz, Albrecht (Albrecht); Hadriel Kaplan; <straw@ietf.org> Subject: VS: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway mo= del and media plane b2bua types

 

(As co-chair)

 

Hi Albrecht,

 

I do appreciate the fact that you have taken a lo= ok at the draft, and studied its applicability from a SG16 perspective.

 

In the conclusion part, you ask whether there is = a need to provide feedback to STRAW.

 

Keep in mind that the WGLC for the draft has fini= shed, and that publication has been requested by the chairs.

 

Now, that does not prevent us from taking the dra= ft back to the WG, and do changes, but in order for that to happen there no= rmally has to be some issues that need to be changed/addressed in order to = publish the document as an RFC.

 

Regards,

 

Christer

 

 

 

-----Alkuper=E4inen viesti-----

L=E4hett=E4j=E4: straw-bounc= es@ietf.org [mailto:straw-bounces@ietf.org<= /span>] Puolesta Schwarz, Albrecht (Albrecht)

L=E4hetetty: 16. kes=E4kuuta 2013 8:13=

Vastaanottaja: Hadriel Kaplan; <s= traw@ietf.org>

Aihe: [straw] draft-ietf-straw-b2bua-taxonomy: de= composed gateway model and media plane b2bua types

 

Hi Hadriel,

fyi, some high-level comments to the taxonomy dra= ft from perspective of decomposed SBCs (according H.248 model) http://ftp3.itu= .int/av-arch/avc-site/2013-2016/1306_Osl/AVD-4391.zip

 

Regards,

Albrecht

_______________________________________________

straw mailing list

straw@ietf.org=

https://www.ie= tf.org/mailman/listinfo/straw

--_000_786615F3A85DF44AA2A76164A71FE1AC068C36FR711WXCHMBA03zeu_-- From panglum@hotmail.com Thu Jun 20 09:47:14 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D46F21F9D00 for ; Thu, 20 Jun 2013 09:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBugaa3RcpSP for ; Thu, 20 Jun 2013 09:47:08 -0700 (PDT) Received: from blu0-omc2-s13.blu0.hotmail.com (blu0-omc2-s13.blu0.hotmail.com [65.55.111.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9F621F9C59 for ; Thu, 20 Jun 2013 09:47:08 -0700 (PDT) Received: from BLU171-W25 ([65.55.111.71]) by blu0-omc2-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jun 2013 09:47:08 -0700 X-TMN: [ezSBxuvUVOe3dNFD1jmMUK3l1iDeGhop] X-Originating-Email: [panglum@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d59deda6-1fed-491b-a12d-6cdad72da569_" From: Patrick Anglum To: "megaco@ietf.org" Date: Thu, 20 Jun 2013 09:47:07 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2013 16:47:08.0661 (UTC) FILETIME=[CDAF6A50:01CE6DD5] X-Mailman-Approved-At: Fri, 21 Jun 2013 08:33:11 -0700 Subject: [Megaco] Book on Megaco/H248 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:29:42 -0000 --_d59deda6-1fed-491b-a12d-6cdad72da569_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can anyone suggest a book on Megaco and/or H.248. I mainly need to know how to decode wireshark traces and determine where a = fault lies. I am pretty good at SIP and MGCP but Megaco has thrown me for a loop. And yes=2C I have the RFCs. When I was learning SIP=2C I also had the RFCs. However=2C it was books with example call flows etc. that helped the most. I find the RFC's best are best as a reference when determining if the obser= ved behaviour is correct or not. Pat = --_d59deda6-1fed-491b-a12d-6cdad72da569_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can anyone suggest a book on Meg= aco and/or H.248.

I mainly need to know how to decode wireshark trac= es and determine where a fault lies.

I am pretty good at SIP and MGC= P but Megaco has thrown me for a loop.

And yes=2C I have the RFCs.When I was learning SIP=2C I also had the RFCs.
However=2C it was book= s with example call flows etc. that helped the most.
I find the RFC's be= st are best as a reference when determining if the observed behaviour is co= rrect or not.

Pat
= --_d59deda6-1fed-491b-a12d-6cdad72da569_-- From Christian.Groves@nteczone.com Sat Jun 22 04:53:41 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7275521F9F2D for ; Sat, 22 Jun 2013 04:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eumM4-lzCWC for ; Sat, 22 Jun 2013 04:53:40 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 2383F21F9F2B for ; Sat, 22 Jun 2013 04:53:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwVAPSPxVFQ1KrFPGdsb2JhbAANToM6wASBFAMBAQEBOIJYAQEBBAEBATUbGgEKEQsYCRYPCQMCAQIBFRwUEwYCAQGIFqodkgyPUBaDSwOsKA Received: from ti0059a380-dhcp0708.bb.online.no (HELO [127.0.0.1]) ([80.212.170.197]) by ipmail07.adl2.internode.on.net with ESMTP; 22 Jun 2013 21:23:34 +0930 Message-ID: <51C59033.3050807@nteczone.com> Date: Sat, 22 Jun 2013 21:53:23 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: megaco@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Megaco] Book on Megaco/H248 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 11:53:41 -0000 Hello Pat, I'm not sure if you have the recommendations (http://www.itu.int/rec/T-REC-H/en). These are more up to date than the RFCs. Some of these also contain call flows. Another source are the various 3GPP and ETSI profiles. i.e. TS 29.232 (http://www.3gpp.org/ftp/Specs/html-info/29232.htm) etc. I'm not aware of a book that details H.248/Megaco. Regards, Christian On 21/06/2013 2:47 AM, Patrick Anglum wrote: > Can anyone suggest a book on Megaco and/or H.248. > > I mainly need to know how to decode wireshark traces and determine > where a fault lies. > > I am pretty good at SIP and MGCP but Megaco has thrown me for a loop. > > And yes, I have the RFCs. > When I was learning SIP, I also had the RFCs. > However, it was books with example call flows etc. that helped the most. > I find the RFC's best are best as a reference when determining if the > observed behaviour is correct or not. > > Pat > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco From albrecht.schwarz@alcatel-lucent.com Tue Jun 25 07:56:41 2013 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4690111E8132 for ; Tue, 25 Jun 2013 07:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDN7GwTTDxKu for ; Tue, 25 Jun 2013 07:56:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB9C21E80E2 for ; Tue, 25 Jun 2013 07:56:10 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5PEu8tW026487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Jun 2013 09:56:08 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5PEtsoE004091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Jun 2013 10:56:08 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 25 Jun 2013 10:55:52 -0400 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.135]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 25 Jun 2013 16:55:39 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "megaco@ietf.org" Thread-Topic: SG16 Oct/Nov meeting: input drafts Thread-Index: Ac5xtA28cqpsawQ0QIeKKA4A7bklEQ== Date: Tue, 25 Jun 2013 14:55:38 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC06CB91@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC06CB91FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Megaco] SG16 Oct/Nov meeting: input drafts X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:56:42 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC06CB91FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable fyi, following nine H.248.x input drafts are already available as TD-WP1: http://www.itu.int/md/T13-SG16-131028-TD-WP1/en [ 86-WP1 ] 2013-06-21 Editor H.248.WEBRTC H.248.WEBRTC "Guidelines on the use of H.248 capabilities for Web-b= ased Real-Time Communication Services in H.248 Profiles" (New): Input draft= Ed. 0.7 Q3/16 [ 85-WP1 ] 2013-06-21 Editor H.248.TLSPROF H.248.TLSPROF: "Guidelines on the use of H.248 capabilities= for transport security in TLS networks in H.248 Profiles" (New): Input dra= ft Ed. 0.10 Q3/16 [ 84-WP1 ] 2013-06-21 Editor H.248.TLS = H.248.TLS: "Gateway control protocol: H.248 packages for control of= transport security using TLS" (New): Input draft Ed. 0.10 Q3/16<= http://www.itu.int/md/meetingdoc.asp?lang=3Den&parent=3DT13-SG16-131028-TD-= WP1&question=3DQ3/16> [ 83-WP1 ] 2013-06-21 Editor H.248.TCP = H.248.TCP: "Gateway control protocol: TCP support packages" (New): = Input draft Ed. 0.7 Q3/16 [ 82-WP1 ] 2013-06-21 Editor H.248.RTPTOPO H.248.RTPTOPO: "RTP topology dependent RTCP handling by H.2= 48 Media Gateways with IP Terminations" (New): Input draft Ed. 0.17 = Q3/16 [ 81-WP1 ] 2013-06-21 Editor H.248.RTCPPROF H.248.RTCPPROF: "Guidelines on the use of H.248 capabilitie= s for performance monitoring in RTP networks in H.248 Profiles" (New): Inpu= t draft Ed. 0.10 Q3/16 [ 80-WP1 ] 2013-06-21 Editor H.248.DTLS= H.248.DTLS: "Gateway control protocol: H.248 support for control of= transport security using DTLS" (New): Input draft Ed. 0.3 Q3/16<= http://www.itu.int/md/meetingdoc.asp?lang=3Den&parent=3DT13-SG16-131028-TD-= WP1&question=3DQ3/16> [ 79-WP1 ] 2013-06-21 Editor H.248.DPI = H.248.DPI "Gateway control protocol: H.248 Support for deep packet = inspection" (New): Input draft Ed. 0.19 Q3/16 [ 78-WP1 ] 2013-06-21 Editor H.248.78 = H.248.78 "Gateway control protocol: Bearer-level application level gateway"= (Rev.): Input draft Ed. 0.2 Q3/16 -Albrecht --_000_786615F3A85DF44AA2A76164A71FE1AC06CB91FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
fyi, following nine H.248.x input drafts are already available as TD-W= P1:
 <= /div>
 <= /div>
[ = 86-WP1 ]  
  		2013-06-21 Editor H.248.WEBRTC   H.248.WEBRTC "Guidelines on the use of H.248 capabilities for Web-= based Real-Time Communication Services in H.248 Profiles" (New): Input= draft Ed. 0.7     Q3/16  
  [ 85-WP1 ]  
  		2013-06-21 Editor H.248.TLSPROF   H.248.TLSPROF: "Guidelines on the use of H.248 capabilities for= transport security in TLS networks in H.248 Profiles" (New): Input dr= aft Ed. 0.10     Q3/= 16  
  [ = 84-WP1 ]  
  		2013-06-21 Editor H.248.TLS   H.248.TLS: "Gateway control protocol: H.248 packages for control o= f transport security using TLS" (New): Input draft Ed. 0.10     Q3/16  
  [ 83-WP1 ]  
  		2013-06-21 Editor H.248.TCP   H.248.TCP: "Gateway control protocol: TCP support packages"= ; (New): Input draft Ed. 0.7     Q3/= 16  
  [ = 82-WP1 ]  
  		2013-06-21 Editor H.248.RTPTOPO   H.248.RTPTOPO: "RTP topology dependent RTCP handling by H.248 Medi= a Gateways with IP Terminations" (New): Input draft Ed. 0.17     Q3/16  
  [ 81-WP1 ]  
  		2013-06-21 Editor H.248.RTCPPROF   H.248.RTCPPROF: "Guidelines on the use of H.248 capabilities fo= r performance monitoring in RTP networks in H.248 Profiles" (New): Inp= ut draft Ed. 0.10     Q3/= 16  
  [ = 80-WP1 ]  
  		2013-06-21 Editor H.248.DTLS   H.248.DTLS: "Gateway control protocol: H.248 support for control o= f transport security using DTLS" (New): Input draft Ed. 0.3     Q3/16  
  [ 79-WP1 ]  
  		2013-06-21 Editor H.248.DPI   H.248.DPI "Gateway control protocol: H.248 Support for deep pac= ket inspection" (New): Input draft Ed. 0.19  =   Q3/= 16  
  [ = 78-WP1 ]  
  		2013-06-21 Editor H.248.78=   H.248.78 "Gateway control protocol: Bearer-level application level= gateway" (Rev.): Input draft Ed. 0.2    = ; Q3/16  
 <= /div>
-Albrecht
 <= /div> --_000_786615F3A85DF44AA2A76164A71FE1AC06CB91FR711WXCHMBA03zeu_--