On Thu, May 29, 2014 at 3:31 PM, Gunnar Hellstrom <[email protected]> wrote: > On 2014-05-28 17:46, Matthew Jordan wrote: >> >> On Tue, May 27, 2014 at 4:59 PM, Gunnar Hellstrom >> <[email protected]> wrote:
<snip> > > It works fine for calls with only real-time text ( red + t140 ). > Still I am also not sure what might happen in other configurations than the > ones we have with SIP everywhere. I'd say that's a great starting point. Since Asterisk, today, is typically limited in accepting a single media stream of each type (audio/video/text), tests that verify that single stream of each type should give a reasonable accounting of how the core will handle these situations. >> >> One of the bigger questions when you don't have audio is "what happens >> in the core". chan_sip may create a channel with the correct >> formats/capabilities, but there *may be* some strange things that >> happen in dialplan applications and in the channel core if a channel >> doesn't have audio. Some testing of the core + relevant dialplan >> applications is probably in order. > > We are doing some of that, but should be formalized. > Agreed. There's been some work on revamping Asterisk's format media core; this would be an excellent time to expand testing to cover these scenarios. There is a "working" document on the wiki for various test cases that should be exercised under that work: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite It includes tests scenarios that could be expanded on. I've updated the page to note that all supported media stream types should be verified. Note that some of the expected behaviour on that page only applies to the PJSIP stack - chan_sip has its own rules about media negotiation that are a bit "quirky", but - for the sake of backwards compatibility - probably not worth changing. The Asterisk Test Suite (http://svn.asterisk.org/svn/testsuite/asterisk/trunk) has the ability to orchestrate SIPp scenarios and/or instances of Asterisk to automate verification of these kinds of scenarios. In addition to manual testing, the test scenarios on that wiki page will map to tests in the test suite. It's relatively easy to incorporate SIPp scenarios into the Test Suite - any contributions on said scenarios would be hugely appreciated :-) >>> Are there other cases than calls with video and text media that should >>> have >>> the same possibility to have calls without audio? >> >> Possibly calls that negotiate image only. Typically, Asterisk only >> supports switching from audio to image in a re-INVITE to support T.38 >> - but it expects to get audio initially. There's probably a >> substantial amount of work beyond just the negotiation aspects to >> fully support that. > > If there are any plans to support MSRP in Asterisk, it would provide another > reason to support callswithout audio. > MSRP would be cool, but I don't have any plans to work on that during the next few months. However, I can't speak for everyone in the community - and planning for the future is always a good idea. >> >>> Does anyone know if audio-less calls are already supported in the new >>> stack >>> pjsip? >>> >> No, this problem exists there too. > > OK, how can it be entered in the plans? > As well as carry over the good real-time text ( T.140 + red = RFC 4103 ) > support that there is in release 11, ( and likely in 12 using chan-sip. ) . > How can that be entered in the plans? The goal of the media format work was to at least make the PJSIP stack support audio OR video - so we should at least be able to handle RTT streams when that capability is added in the future. That work is ongoing now. Adding RTT support would be a great addition. If someone were interested in doing it themselves, we'd be happy to provide guidance on the best way to get that done in the PJSIP stack. That could happen at any time. Otherwise - if someone wanted to just make sure that such a feature is "on the radar" - we typically set the goals for the next version of Asterisk at AstriDevCon at AstriCon. The results of the devcon are up on the wiki under the Roadmap pages: https://wiki.asterisk.org/wiki/display/AST/Roadmap Large scale projects typically get their own planning page to help coordinate activities. Of course, discussing it on the -dev list also helps! >> >>> Or would it be preferred to create a combined mask for all valid SIP >>> media >>> formats in frame.h ? >>> >> I'm not sure that's the solution, although I'd have to see a patch to >> know for sure. I would thin, however, that each negotiated media >> session should be treated independently for compatibility. What those >> media sessions are, however, should not impact whether or not a >> channel is created; they should just be compatible (based on their >> respective types). > > We will compose a proposed patch. >> That'd be fantastic. When you have a patch ready, please submit it for code review: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process I'm looking forward to seeing it! Thanks - Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
