[asterisk-dev] Sip call consciously without audio

[Matthew Jordan]

On Thu, May 29, 2014 at 3:31 PM, Gunnar Hellstrom
<gunnar.hellstrom at omnitor.se> wrote:
> On 2014-05-28 17:46, Matthew Jordan wrote:
>>
>> On Tue, May 27, 2014 at 4:59 PM, Gunnar Hellstrom
>> <gunnar.hellstrom at omnitor.se> 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