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 :-) 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 -- _____________________________________________________________________ -- 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
