[asterisk-dev] Sip call consciously without audio

[Matthew Jordan]

On Tue, May 27, 2014 at 4:59 PM, Gunnar Hellstrom
<gunnar.hellstrom at omnitor.se> wrote:
> On 2014-05-25 21:33, Gunnar Hellstrom wrote:
>
> Hi,
>
> chan-sip.c in release 11 and 12 is dropping sip calls in which no common
> audio media is negotiated, regardless of if other media are negotiated.
>
> There are very valid cases when a call is wanted with any combination of
> video and text, but no audio.
>
> One place where calls without audio are blocked is in the function:
> sip_request_call
>
> Where a comment in the beginning says:
>     /* mask request with some set of allowed formats.
>      * XXX this needs to be fixed.
>      * The original code uses AST_FORMAT_AUDIO_MASK, but it is
>      * unclear what to use here. We have global_capabilities, which is
>      * configured from sip.conf, and sip_tech.capabilities, which is
>      * hardwired to all audio formats.
>      */
> And then an audio-less call is blocked by this statement:
>
> if (!(ast_format_cap_has_type(cap, AST_FORMAT_TYPE_AUDIO))) {
>         ast_log(LOG_NOTICE, "Asked to get a channel of unsupported format %s
> while capability is %s\n",
>         ast_getformatname_multiple(tmp, sizeof(tmp), cap),
>         ast_getformatname_multiple(tmp2, sizeof(tmp2), sip_cfg.caps));
>         *cause = AST_CAUSE_BEARERCAPABILITY_NOTAVAIL;    /* Can't find codec
> to connect to host */
>         return NULL;
>
> ---------
>
> There is a similar check for outgoing calls in chan-sip.c function sip_call
> :
> /* If there are no audio formats left to offer, punt */
>     if (!(ast_format_cap_has_type(p->jointcaps, AST_FORMAT_TYPE_AUDIO))) {
>         ast_log(LOG_WARNING, "No audio format found to offer. Cancelling
> call to %s\n", p->username);
>         res = -1;
>
> I suggest that the check in both these places is replaced with a check for
> any common supported media and codec.
>
> Something like:
>
> if (!(ast_format_cap_has_type(cap,
> (AST_FORMAT_TYPE_AUDIO||AST_FORMAT_TYPE_VIDEO||AST_FORMAT_TYPE_TEXT))) {
>
> Yes, it works with this modification in the two mentioned locations:
>
> if (!(ast_format_cap_has_type(cap, AST_FORMAT_TYPE_AUDIO) ||
>       ast_format_cap_has_type(cap, AST_FORMAT_TYPE_VIDEO) ||
>       ast_format_cap_has_type(cap, AST_FORMAT_TYPE_TEXT))) {

I ran into a similar situation when testing out chan_pjsip in Asterisk
12 for some of the format work going on [1]. When negotiating calls
that consist only of video (since it does not, yet, support real-time
text), some strange behaviour cropped up. Initially, I put together a
patch that restricted it in a fashion similar to chan_sip [2]; Olle,
however, correctly pointed out what you did - that there are
situations where video only or video + other stuff is desirable.

[1] http://lists.digium.com/pipermail/asterisk-dev/2014-March/066084.html
[2] http://lists.digium.com/pipermail/asterisk-dev/2014-March/066088.html

So, to answer your initial questions:

>
> Is this sufficient?

I'm not sure :-)

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.

> 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.

> Does anyone know if audio-less calls are already supported in the new stack
> pjsip?
>

No, this problem exists there too.

>
> 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).



-- 
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