http://blog.gmane.org/gmane.ietf.megaco hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.megaco/6212 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:39:56 http://comments.gmane.org/gmane.ietf.megaco/6210 <pre>Dear All! We'd like to early point out to one proposal for coming meeting, concerning the discussion of a new (SDP limited) H.248 wildcard method. The draft contributions are uploaded to the Exchange directory: http://ifa.itu.int/t/2013/sg16/exchange/wp1/q03/2013-06%20Meeting/Pre-meetingDiscussions/ ifa.itu.int - /t/2013/sg16/exchange/wp1/q03/2013-06 Meeting/Pre-meetingDiscussions/ [To Parent Directory] 4/15/2013 5:12 PM 37066 AVD-4370_H.248.39_ExtendedSDPWildcarding_Ed02.docx 4/15/2013 5:12 PM 33002 AVD-4371_H.248.39_fingerprint_Ed02.docx AVD-4370 motivates and defines the wildcard. AVD-4171 provides a first example use case. We've identified so far at least two application areas: a) NAT-T e.g., a=ssrc:~ cname:~ b) TLS and DTLS basec Transport security: e.g., a=fingerprint:~ ~ Early feedback would be appreciated, Albrecht __________________________________________________ Dr. Albrecht Schwarz Alcatel-Lucent Albrecht.Schwarz&lt; at &gt;alcatel-lucent.com </pre> Schwarz, Albrecht (Albrecht 2013-04-15T15:21:29 http://comments.gmane.org/gmane.ietf.megaco/6204 <pre>Hi, Silence suppresion can be turned "on" via the "s:on" parameter in Local connection options specified by Call Agent in MGCP. Example : CRCX 1006 aaln/1&lt; at &gt;rx.com MGCP 1.0 NCS 1.0 C: 0 L: p:20, a:PCMU, s:on, sc-rtp:60/50, sc-rtcp:80/70 M: recvonly X: 0123456789AC R: hu 1. In 200 Ok of this above request how does client specify that it supports silence suppresion? 2. During silence period the client would send the comfort noise packts(CN,paylaod 13) to the remote party. How does remote party decode the CN(comfort noise) packets? Looking forward for some help in this issue. Regards Sumant </pre> Sumant Gupta 2013-03-07T05:55:51 http://comments.gmane.org/gmane.ietf.megaco/6201 <pre>Hi, Can someone please help me understand the interaction between the H.248 Mode property and Signals/Events? We're testing MGC-MG interop, and aren't quite agreeing over a Modify request for a termination with a single stream that * sets the Mode to RecvOnly * plays an external tone. The key bits of H.248.1 text up for discussion seem to be: * from 7.1.7: The allowed values for the Mode Property are "SendOnly", "RecvOnly", "SendRecv", "Inactive" and "LoopBack". "SendOnly", "RecvOnly" and "LoopBack" are with respect to the exterior of the context, so that, for example, a stream set to mode = "SendOnly" does not pass received media into the context. When a stream is set to "LoopBack" on a termination, media received (Local Descriptor) on the termination will be looped back to the sending side (Remote Descriptor) of the termination and no media is passed between that termination and other terminations in the context. The looped back media shall be sent according to the Remote Descriptor. The default value for the Mode Property is "Inactive". Signals and events are not affected by the Mode Property. The LocalControl Mode Property takes precedence over any mode specified in the Local and Remote Descriptors. * From 6.1.1: * The Topology Descriptor (who hears/sees whom). The topology of a context describes the flow of media between the terminations within a context. In contrast, the Mode Property of a termination ("SendOnly"/"RecvOnly"/...) describes the flow of the media at the egress/ingress of the media gateway. So I think we've both interpreted the Mode property differently: * One view treats the Mode property as absolute: that is, RecvOnly means absolutely no media is sent out to this termination, SendOnly means any and all received media is absolutely ignored. Setting the mode doesn't affect the Signals and Events that are programmed on a given termination, neither does it affect any subsequent programming - but it can and does affect the result of the programming. So in this case a Mode of RecvOnly combined with an external tone means the tone gets played in the DSP but absolutely no media is sent out to that termination. Another way to explain our implementation is in this picture: [MG egress/ingress]&lt;--- flow affected by Mode property ---&gt;[termination including DSP for signals/events]&lt;--- flow affected by Topology descriptor ---&gt;[context media mixpoint] * The other (that expects to see the tone played to the termination) effectively says that the Mode property affects the flow of media between the termination and the context media mixpoint: [MG egress/ingress]&lt;------&gt;[termination including DSP for signals/events]&lt;--- flow affected by Mode and Topology ---&gt;[context media mixpoint] What's the right answer here? The first view seems to go against the text from 7.1.7, and the second view seems to go against that from 6.1.1. Please don't hesitate to get back to me if any of this is unclear. Many thanks in advance, Mark ---- Mark Overton Project Manager, Carrier Systems Division Metaswitch Networks mark.overton&lt; at &gt;metaswitch.com&lt;mailto:mark.overton&lt; at &gt;metaswitch.com&gt; +44 20 8366 1177 www.metaswitch.com&lt;http://www.metaswitch.com/&gt; _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Mark Overton 2013-03-05T11:00:35 http://comments.gmane.org/gmane.ietf.megaco/6199 <pre>Hello Chrisitian, guess you noted as well the publication of RFC 6871, which allows to finalize draft H.248.80. Regards, Albrecht -----Original Message----- From: mmusic-bounces&lt; at &gt;ietf.org [mailto:mmusic-bounces&lt; at &gt;ietf.org] On Behalf Of rfc-editor&lt; at &gt;rfc-editor.org Sent: Mittwoch, 27. Februar 2013 20:35 To: ietf-announce&lt; at &gt;ietf.org; rfc-dist&lt; at &gt;rfc-editor.org Cc: mmusic&lt; at &gt;ietf.org; rfc-editor&lt; at &gt;rfc-editor.org Subject: [MMUSIC] RFC 6871 on Session Description Protocol (SDP) Media Capabilities Negotiation A new Request for Comments is now available in online RFC libraries. RFC 6871 Title: Session Description Protocol (SDP) Media Capabilities Negotiation Author: R. Gilman, R. Even, F. Andreasen Status: Standards Track Stream: IETF Date: February 2013 Mailbox: bob_gilman&lt; at &gt;comcast.net, roni.even&lt; at &gt;mail01.huawei.com, fandreas&lt; at &gt;cisco.com Pages: 55 Characters: 124829 Updates: RFC5939 I-D Tag: draft-ietf-mmusic-sdp-media-capabilities-17.txt URL: http://www.rfc-editor.org/rfc/rfc6871.txt Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. This document updates the IANA Considerations of RFC 5939. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor&lt; at &gt;rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ mmusic mailing list mmusic&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mmusic </pre> Schwarz, Albrecht (Albrecht 2013-02-28T08:09:52 http://comments.gmane.org/gmane.ietf.megaco/6195 <pre>Hi all, When MG has some terminations in out of service state, which are not registered in MGC, MG is sending "service change" message to MGC for each TID's as seen; MEGACO/1 [10.10.10.10] Transaction=31582{Context=-{ServiceChange=P25{Services{Method=Restart,Reason="900 Service Restored",20121217T08144897}}}} Because of not created termination ID's MGC returns error message, like the one below; !/1 [100.100.100.100]:2944 P=31582{C=-{SC=P25{ER=430{"Unknown TrmID"}}}} It is clear. I wonder that; What message must be sent from MGC to MG just after creating new termination at MGC? Must it be "service change" message to put TID in service state, or "modify" message to connect TID to null context as seen below; !/1 [100.100.100.100]:2944 T=456731602{C=-{MF=P25{E=2600571907{al/*},SG{}}}} If the service change message is true, what type of mesage format will be sent? Best Regards, M. NECAT ISIK _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> ISIK, NECAT (NECAT 2012-12-26T21:50:21 http://comments.gmane.org/gmane.ietf.megaco/6194 <pre>fyi, we've already uploaded a couple of TCP and TLS related contributions, see http://www.itu.int/md/T13-SG16-130114-C/en The high level order is C-2, 3, 4, 43 and the overviews C-13 (TCP) and C-14 (TLS). __________________________________________________ Dr. Albrecht Schwarz Alcatel-Lucent Albrecht.Schwarz&lt; at &gt;alcatel-lucent.com _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Schwarz, Albrecht (Albrecht 2012-12-13T10:13:06 http://comments.gmane.org/gmane.ietf.megaco/6192 <pre>Hi, Sorry for using the forum for the following help, however since its urgent and am strapped for time, I thought of posting it. 1. Need to implement and integrate MGCP digitmap - is there any open source available for it which can be used. 2. Is there any other references apart from RFC, form where I can get more details. ~Thanx Abhijit _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Abhijit Dutta 2012-10-11T02:25:36 http://comments.gmane.org/gmane.ietf.megaco/6190 <pre>Hello, FYI, there is a ITU-T SG16 Q.3 meeting next week discussing H.248. For those interested in the latest progress of H.248 the agenda (TD-04) and documents for the meeting can be found at: http://ftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/1209_Bri.html Regards, Christian Groves Q.3 Rapportuer </pre> Christian Groves 2012-09-21T03:17:30 http://comments.gmane.org/gmane.ietf.megaco/6187 <pre>Hi, As pre spec: "If the timer expires and a member of the candidate set of alternatives is fully satisfied, a timeout completion with full match is reported. If the timer expires and part or none of any candidate alternative is satisfied, a timeout completion with partial match is reported. In either case, if the digit map completion event allows for detailed timeout reporting, the reported dial string will end with 'L', 'S', or 'T' as appropriate" What we see is MG reports collected digit string but does not include "S" event in cases where it appears the MG waited for the S timer to expire before reporting the Digitstring. Q: should MG be including the Termination method with Digitstring ? Q: in case of PM with empty digit string, should the Termination method be included ? Q: in case of PM, does the MS report the partially collected digits? If Digitmap is xxxx and MS detects "123" and S timer expires waiting for 4th digit, which OBSERVEDEVENT should MS send: OBSERVEDEVENTS = 214 { 1:DD/CE { DS = "", METH = PM }, or OBSERVEDEVENTS = 214 { 1:DD/CE { DS = "123", METH = PM }, or OBSERVEDEVENTS = 214 { 1:DD/CE { DS = "123S", METH = PM } ~Thanx Abhijit _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Abhijit Dutta 2012-08-30T07:00:22 http://comments.gmane.org/gmane.ietf.megaco/6185 <pre>Hi, Assume MG sends a ServiceChange encoded as MEGACO/1 with VERSION=3 MGC supports offered version, how does it encode the response; as MEGACO/1 or MEGACO/3? I see the example in ITU H248.1 (09/2005) Appendix I showing a response of MEGACO/1 but I was unable to find this discussed anywhere else in the specification. Thank you Chaim Geretz _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Chaim Geretz 2012-08-22T16:54:25 http://comments.gmane.org/gmane.ietf.megaco/6182 <pre>Hello all, I came across a strange scenario which I haven't been able to justify it from the H.248.1 document. We have an MGC-MG connection in a call waiting scenario where the MGC applies call-waiting tone to the MG in a physical termination via the following message: C = 1 { MF=port_1{ SG { CG/CW } } } The message is successfully ack'ed by the MG and the PSTN subscriber successfully hears the call-waiting tone. What will happen to the call-waiting tone if the MGC issues an Add command with wildcard "$" and ring-back tone application, like the one below? C = 1 { A=$ { M { O { MO=IN,NT/JIT=0 } , L { SDP } } , SG{CG/RT} } } [ As expected, the MG chooses an ephemeral termination in the subsequent Add Reply] Does H.248.1 state anywhere that if a signal is applied in a command that bears a wildcard "$" termination, , it will replace the last signal that was applied in the physical termination? We observed that upon sending the Add command, the call-waiting tone is deactivated! I would consider this behavior as a MG deficiency, but I would gladly like to hear your opinion, as well. Thank you, Greg _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Beis, Grigoris (NSN - GR/Athens 2012-08-22T09:20:59 http://comments.gmane.org/gmane.ietf.megaco/6175 <pre>[Cc'd megaco list due to H.248.2] The T.38 parameters as defined by ITU-T T.38 are related to a T.38 endpoint implementation, such as the T.38 user plane interworking function as e.g. located in an H.248 IP-to-TDM media gateway (e.g. 3GPP IM-MGW). There are fundamentally two signaling options for such T.38 configurations: a) SDP-based: using T.38 Annex D defined SDP elements embedded in H.248 descriptors b) Property-based: using H.248.2, IP Fax package defined properties, such as specified by clauses 10.1.3 to 10.1.7 Both H.248 signalling options are basically equivalent, - independent of SDP- or Property-based signaling elements. The signaling elements relate to the T.38 endpoint, but NOT to any remote G3FE. [Note: the H.248 IP fax package version 1 (from 2005/2007) does not yet contain the latest T.38V4 (2010) parameter. But this aspect is irrelevant in this discussion due to the proposal in 3GPP for the SDP-based method.] Thus, all "T.38 SDP attributes" (in C3-121327) are related to gateway capabilities (such as supported T.38 configurations by an IM-MGW implementation) (NOTE: attached is T.38 Table B.1 for H.323 gateways, which again underlines the relation to gateway capabilities). The MGC / MGCF may be either a) aware of the supported T.38 configuration(s) by his associated MGs or b) unaware. Awareness may be achieved via auditing or configuration management. Unawareness is basically possible, but may lead to inefficient or even ineffective H.248 scenarios for T.38. Dependent on the amount of "supported T.38 configuration(s)" knowledge at MGC level would be the content of the SIP-level SDP O/A procedures. Conclusions for C3-121327 (http://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_70_Chicago/Docs/C3-121327.zip): NOTEs 1 and 2 in Table X.3.1 are incorrect in my opinion. The text related to "remote CS FAX equipment" (term should be anyway replaced by term G3FE) should be just deleted. And there would be correspondent changes at other tables. -Albrecht _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Schwarz, Albrecht (Albrecht 2012-08-01T14:16:56 http://comments.gmane.org/gmane.ietf.megaco/6172 <pre>Hi All, Could anyone please point me to any specification/documentation which I refer for call-flows and H.248 functionality when using for T38. Thanks a lot, Best Regards, Kapil _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Kapil gupta 2012-07-24T18:27:03 http://comments.gmane.org/gmane.ietf.megaco/6169 <pre>Hi All, I am working on Signaling Gateway which also supports MEGACO commands to providie Media Gateway functionality. When MGC sends MEGACO command , he specifiies the termination-id , how will I determine that termination id mentioned in Megaco message will map to which TDM channel id ? From the spec, I got information that termination-id format will be choosen by Media Gateway, Is it some kind of configuration which needs to be done in MG as well as in MGC ? any response would be really appriciared !! thanks a lot. Best Regards, Kapil _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Kapil gupta 2012-06-13T03:30:24 http://comments.gmane.org/gmane.ietf.megaco/6167 <pre> Hi All, As per specs: (H248v2) section E.3 "Tonegen package is designed to be extended ONLY. Also it mentions that no tone ids are defined/specified in the package. It is the responsibility of the packages derived from it to add possible values...." Please verify the understanding based on the above statement ------------------------------------------------------------------------------ 1. MGC cannot send tongen/pt to MG since, since it needs to define the tone(s) in the request ( which will contradict the spec). 2. So if assumption (1) is correct, then in case MG receives such request it will return an error response back. 3. If assumption (1) is incorrect in which cases MGC can send tonegen request and with what kind of tone ids in the list? ~Thanx Abhijit _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Abhijit Dutta 2012-05-30T07:36:15 http://comments.gmane.org/gmane.ietf.megaco/6166 <pre>Hi All, As per specs: (H248v2) section E.3 "Tonegen package is designed to be extended ONLY. Also it mentions that no tone ids are defined/specified in the package. It is the responsibility of the packages derived from it to add possible values...." Please verify the understanding based on the above statement ------------------------------------------------------------------------------ 1. MGC cannot send tongen/pt to MG since, since it needs to define the tone(s) in the request ( which will contradict the spec). 2. So if assumption (1) is correct, then in case MG receives such request it will return an error response back. 3. If assumption (1) is incorrect in which cases MGC can send tonegen request and with what kind of tone ids in the list? ~Thanx Abhijit _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Abhijit Dutta 2012-05-29T11:16:28 http://comments.gmane.org/gmane.ietf.megaco/6165 <pre> fyi, in order to complete the work on H.248.NATTP2P at coming SG16 meeting, we've uploaded already a set of contributions: http://www.itu.int/md/T09-SG16-120430-C/en C-791 to 798 (ex 796) /Albrecht _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Schwarz, Albrecht (Albrecht 2012-03-27T12:53:23 http://comments.gmane.org/gmane.ietf.megaco/6164 <pre> http://salsaytumbao.com/httpi3-p.php?idname=431 Get Back Some Financial Independence Into Your Life. _______________ He oftendone that. algernon visszaszerzesnek </pre> Ganesh Kumar 2012-03-20T15:21:42 http://comments.gmane.org/gmane.ietf.megaco/6155 <pre>Hi all, for some king of application I need individual digits to be reported to the softswitch from the media server. I want to know what should be the format of megaco request for this. Please provide me with an example of the same Thanks Kapila _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Kapila Arora 2012-02-23T03:44:57 http://comments.gmane.org/gmane.ietf.megaco/6154 <pre>Hi, Sorry for this naïve question - I am posting it since there is no clear indication in the RFC. Can local and remote descriptor contain differ IP address types - one say IPv4 and another IPv6. If not, what should the MGC return (error code) in reply during such situations. ~Thanx Abhijit _______________________________________________ Megaco mailing list Megaco&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/megaco </pre> Abhijit Dutta 2012-02-22T19:08:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.megaco