MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "SIPit19_Summary",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "1358": {
                "pageid": 1358,
                "ns": 0,
                "title": "Rtcwebit2 summary",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "The second SIP Forum RTCWeb Interoperability Test was hosted by TMC in Santa Clara, California, Monday November 18, 2013.\n\nWe had a very successful test session. Most of the scenarios we exercised \"just worked\" the first time. We had two browser implementations, and one application suite at the table. The scenarios we tested included a rich combination of nat and firewall restricted network paths, ensuring that the expected media and datachannel path was taken in each scenario. (This included forcing the browsers to communicate only through a Turn server.)\n\nOne observation from the tests is that implementations cannot rely on streams being available until onAddStream is called. This may or may not happen before the setRemoteDescription success callback.\n\nWe found a few deployed applications that are currently changing their behavior based on the User-Agent string, and have cost themselves starting to automatically work cross-browser as the browsers are being updated. New application developers should isolate such decisions. (It would have been nice to disable these checks to see if cross-browser DataChannels worked with the browser code at the table.)\n\nHaving a rich application suite available helped drive effective tests, and provided very useful feedback for the application developer. All application developers should consider attending the next event to get the quick feedback this kind of testing environment provides."
                    }
                ]
            },
            "1303": {
                "pageid": 1303,
                "ns": 0,
                "title": "SIPit18 Summary",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "<pre>\n160 people from 16 countries attended SIPit 18 with 73 different SIP implementations.\n\nA short summary of some of the capabilities of those implementations follows:\n\nUDP \t\t\t\t\t73\nTCP \t\t\t\t\t53\nTLS \t\t\t\t\t30\nSCTP \t\t\t\t\t6\nSRTP \t\t\t\t\t10 (7 use sdes)\nrport \t\t\t\t\t36\nGRUU \t\t\t\t\t5\noutbound \t\t\t\t2\nconnect-reuse \t\t\t\t6\nIPv6 \t\t\t\t\t19\nFull 3263 \t\t\t\t25\n3263 no naptr (SRV on) \t\t\t13\nA only \t\t\t\t\t22\nIP only (no DNS) \t\t\t9\nSession timer \t\t\t\t38\nPrack \t\t\t\t\t32 (9 non-trivial users)\nUpdate \t\t\t\t\t25\nNIT fixes (4320) \t\t\t7\nOut of Dialog Refer \t\t\t3\nDialog package \t\t\t\t8\nTurn \t\t\t\t\t3\nXCAP \t\t\t\t\t4 (2 servers)\n\nGenerally, the level of interoperability was very high.\n\nVery few of the attendees were aware of GRUU, but there were some implementations to test\n(and they interoperated). The big surprise was the number of SIP over SCTP implementations\ntesting at this event.\n\nThere was significant testing of TLS and SRTP. TLS interoperability is solidifying.\nSRTP interoperability was poor (key exchange is not working)\n\nThere were several common implementation errors and questions. Below are\nrough descriptions of each (in no particular order). I'll send more detailed messages\nwhen I'm back online in a couple of weeks.\n\n- Several UAs were doing 3263 lookups but ignoring the port from the SRV record,\n  always sending to 5060\n\n- Many UAs are gratuitously putting ports in URIs when the appropriate thing to do\n  would be to only place a domain name. This particularly caused error when the\n  port retrieved from SRV was placed explicitly in the RURI of the message sent\n\n- There was non-trivial testing of RPID at this event. There was disagreement around\n  where <activities> was legal or had meaning.\n\n- More than one implementation still has ACK-200 vs ACK-non200 confused. In particular,\n  more than one implementation used the branch parameter from an INVITE in the ACK-200.\n  There was also some confusion leading to reusing the INVITE branch parameter in PRACKs\n\n- Those testing IPv6 made different assumptions about enclosing literal v6 addresses in Vias\n   in []. By the end of the event, most implementations were accepting either. Its about 50/50\n   on what gets sent.\n\n- The SIP over SCTP implementers point out a need for clarification around using the 1 to many\n   vs 1 to 1 mode.\n\n- Several implementations (including a few mature ones) are still having case-insensitivity related\n  interop problems. I saw arguments over \"Digest\" vs \"DIGEST\", and case sensitivity around\n  mime-types.\n\n- There were many questions about record-routing when changing transports, and where the\n   double-record-routing technique we've been suggesting people use is documented.\n\n- Implementers are looking for better guidance for solving the issue we identified with discarding\n  transactions state on an ACK-200. We need to get more guidance into current bugzilla report\n  and/or issue a draft on this soon.\n\n- There were a few XCAP tests at this event. Interoperability was mixed. Very little \"just worked\",\n   but after agreements were made about URI paths and versions of schemas most tests were\n   successful.\n\n- Several UAs still miss that request-merging and handling multiple-200s (or multiple 183s) is even\n  a concern.\n\n</pre>"
                    }
                ]
            }
        }
    }
}