[asterisk-users] T.38 not working - help needed with log interpretation

[Matthew Jordan]

On Mon, Dec 15, 2014 at 3:34 AM, Recursive <lists at binarus.de> wrote:
>

<snip>

>> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', I don't know what Asterisk 13 will do with this setting.
>>
> I suspect Asterisk 13 will just ignore it. To make things worse, there seems to be a configuration directive named reinvite (not a typo); I have found it in at least one example and one article, but with no documentation, so the difference between canreinvite and reinvite is completely unclear to me. chan_sip seems to be documented very poorly, unlike chan_pjsip / res_pjsip.

I'm just going to comment on the 'directmedia'/'canreinvite' points here.

1) There is no 'reinvite' setting in chan_sip. If you patched
Asterisk, than your mileage may vary.
2) 'directmedia' is the same thing as 'canreinvite'. They are the same
setting. 'directmedia' replaced the nomenclature 'canreinvite' because
it actually describes what the setting does: it determines whether or
not Asterisk will attempt to re-INVITE media directly between RTP
capable peers.
3) While documentation sometimes is lacking for some parts of
Asterisk, this setting is actually pretty well documented in
sip.conf.sample:

{quote}
; By default, Asterisk tries to re-invite media streams to an optimal
path. If there's
; no reason for Asterisk to stay in the media path, the media will be
redirected.
; This does not really work well in the case where Asterisk is outside and the
; clients are on the inside of a NAT. In that case, you want to set
directmedia=nonat.
;
;directmedia=yes                ; Asterisk by default tries to redirect the
                                ; RTP media stream to go directly from
                                ; the caller to the callee.  Some devices do not
                                ; support this (especially if one of
them is behind a NAT).
                                ; The default setting is YES. If you
have all clients
                                ; behind a NAT, or for some other
reason want Asterisk to
                                ; stay in the audio path, you may want
to turn this off.

                                ; This setting also affect direct RTP
                                ; at call setup (a new feature in 1.4
- setting up the
                                ; call directly between the endpoints
instead of sending
                                ; a re-INVITE).

                                ; Additionally this option does not
disable all reINVITE operations.
                                ; It only controls Asterisk generating
reINVITEs for the specific
                                ; purpose of setting up a direct media
path. If a reINVITE is
                                ; needed to switch a media stream to
inactive (when placed on
                                ; hold) or to T.38, it will still be
done, regardless of this
                                ; setting. Note that direct T.38 is
not supported.

;directmedia=nonat              ; An additional option is to allow
media path redirection
                                ; (reinvite) but only when the peer
where the media is being
                                ; sent is known to not be behind a NAT
(as the RTP core can
                                ; determine it based on the apparent
IP address the media
                                ; arrives from).

;directmedia=update             ; Yet a third option... use UPDATE for
media path redirection,
                                ; instead of INVITE. This can be
combined with 'nonat', as
                                ; 'directmedia=update,nonat'. It implies 'yes'.

;directmedia=outgoing           ; When sending directmedia reinvites,
do not send an immediate
                                ; reinvite on an incoming call leg.
This option is useful when
                                ; peered with another SIP user agent
that is known to send
                                ; immediate direct media reinvites
upon call establishment. Setting
                                ; the option in this situation helps
to prevent potential glares.
                                ; Setting this option implies 'yes'.

{quote}

Note that none of this matters until you are in a bridge. If you are
in a bridge, I would expect Asterisk to re-INVITE the media back to
Asterisk when one of the sides offers T.38 (and, in fact, we have
automated tests that check for this sort of thing). You shouldn't have
to set directmedia to 'no', but - in the interest of making your
system easier to debug and to remove variables - you may want to set
it to 'no' for the involved peers.

>> For asterisk 1.6 & 1.8 you would need to set 'canreinvite=no', it may be safer to add 'directmedia=no' to your peer configurations in case you change the global setting.
>>
> I'll add directmedia = no to the peer configuration, and I'll remove canreinvite at all since I definitely won't use Asterisk below major version 13 any more.

Just use 'directmedia'. They are the same setting (snippet from
chan_sip's configuration parsing):

    } else if (!strcasecmp(v->name, "directmedia") ||
!strcasecmp(v->name, "canreinvite")) {
        ast_set_flag(&mask[0], SIP_REINVITE);
        ...

Note that these settings and their behaviour is the same from 1.8
through 13. While I'm glad to see anyone using the latest and greatest
- yay Asterisk 13! - this isn't a reason to go to Asterisk 13.

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