[asterisk-dev] Sip call consciously without audio

[Gunnar Hellstrom]

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:
>> 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 :-)
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.
>
> 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.
>> 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.
>
>> 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?
>
>> 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.
>
>
>
Thanks,
Gunnar