Hi All, Was just reading a old NBAR2 document relating to Protocol Pack 7 when I saw this note:   Note The RTP audio/video sub-classification parameters are generic in nature and will match only on generic RTP traffic. More specific classification such as ms-lync-audio, cisco-jabber-audio, facetime, and cisco-phone will not match as RTP, and therefore will not match the audio/video sub-classification. Ref: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_nbar/configuration/xe-3s/qos-nbar-xe-3s-book/nbar-protocl-pack.html   Can anyone speak more to this claim and if it is still valid? I mean we are now way up on Protocol Pack 33 or 36 for Advanced but if match protocol rtp audio can't actually match stuff like cisco-phone audio and cisco-jabber-audio then it's a pretty damming statement for Cisco and further proof that the entire AVC/NBAR2 suite needs to be made a free feature of IPBase on all supported routers. I mean I personally have configured heaps of routers with match protocol rtp audio under a class-map for voice and I am sure thousands of others have done it as well. Hell I have had multiple Cisco Gold partners turn around and confirm this design and even specifically tell me that match protocol rtp audio will match Cisco IP phones and Cisco Jabber audio calls.   Am I getting worried over nothing or is this actually a huge gotcha that Cisco and partners alike have managed to overlook? ... View more

Hi All, Not sure how many people were using it but with the non-IOS train of WLC code, under webauth you could put script like the following in your login.html:       function writeAP() {         var url = window.location.href;         var args = new Object();         var query = location.search.substring(1);         var pairs = query.split("&");         for(var i=0;i<pairs.length;i++){           var pos = pairs[i].indexOf('=');           if(pos == -1) continue;           var argname = pairs[i].substring(0,pos);           var value = pairs[i].substring(pos+1);           args[argname] = unescape(value);             }         var APmac = args.ap_mac;         document.write(APmac);         }       function writeSSID() {       var url = window.location.href;       var args = new Object();       var query = location.search.substring(1);       var pairs = query.split("&");       for(var i=0;i<pairs.length;i++){           var pos = pairs[i].indexOf('=');           if(pos == -1) continue;           var argname = pairs[i].substring(0,pos);           var value = pairs[i].substring(pos+1);           args[argname] = unescape(value);       }         var wlan = args.wlan;         document.write(wlan);         }   The main point being that you could extract details like the args.wlan (the SSID) and use it in the HTML or even to make decisions (ie we had a very different page display for our Welcome SSID vs our Guest SSID, one required auth while the other just made you accept the T&C's). I have just transferred our same webauth bundle to our new CT5760 WLC and although I can get webauth to work (though my testing is far from complete), I just noticed that all the args.[argname] are all coming out as undefined which is stuffing up my html output. There are some fairly simple ways to get around this but I'm wondering if anyone knows if the API has just changed, or has it been removed completely. I guess based on the current webauth bundle for the 5760 we know that args.switch_url and args.statusCode do work. Maybe they changed the name of wlan to ssid, I just wish Cisco would publish such info rather than forcing me to write ugly html hacks to list all the new valid arguments. Cause my ability to write html sux very badly. Thanks, Kevin-John Beasley ... View more