Matt, thank you very much for your help!
> 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.
I didn't patch. Just using "vanilla" Asterisk from your website ...
> 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.
This information is very valuable to me as it drastically cuts the number
possible parameter combinations.
> 3) While documentation sometimes is lacking for some parts of
> Asterisk, this setting is actually pretty well documented in
> sip.conf.sample:
You are right. After compiling, I have made and installed the configuration
sample files and have read those of them which I thought I needed. Thus, I
already have read the section regarding directmedia, but I never would have
come to the idea that this could be the same as canreinvite. Most examples
around the net still use both without further explanation; even my ITSP sent me
a sample configuration which also used both. Once again, thanks for clarifying!
> 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.
I think I am in a bridge. As far as I can recall, I have seen respective
messages in the Asterisk console after having started Asterisk with -vvvc, and
as far as I have understood, there is no support for direct T38. I'll test
again ...
> 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);
> ...
Thanks again ... very instructive.
> 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.
For me, the reason was that I thought that I needed the gateway capability for
faxing via T.38 (seems that I was wrong here), and that I didn't see any T.38
packet in the logs when using 1.8.x (regardless of which configuration
parameters I was using).
Matt, I nearly don't dare to ask, but could you eventually take a quick look
into the logs I have provided? Do you see any reason why asterisk hangs up,
claiming a critical packet timeout, although all packets seemingly have been
answered timely and appropriately?
Regards,
Recursive
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
