On 2014-05-28 17:46, Matthew Jordan wrote:
On Tue, May 27, 2014 at 4:59 PM, Gunnar Hellstrom
<[email protected]> 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
--
_____________________________________________________________________
-- 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
