Dialplan for autocreatepeer=yes

How to create the dialplan for autocreatepeer=yes

You don’t use it as it is only implemented for chan_sip, which will no longer be included starting from next year’s release of Asterisk.

I believe you would need to make the extension be algorithmically related to the peer names, e.g. the common practice of using ${EXTEN}, although the regcontext mechanism might work. All these are rarely used., and there is very limited support for chan_sip, even for commonly used features.

I’ve tried the same, but it is throwing the following error:
Not acceptable here.
On the terminal, it shows the following notice:
WARNING[28865][C-000002b7]: chan_sip.c:10804 process_sdp: Rejecting secure audio stream without encryption details: audio 61478 UDP/TLS/RTP/SAVPF 109 9 0 8 101

From your other topic, you are using WebRTC. There is a very good chance that the interactions between that and autocreatepeer have never been properly tested. Whilst I’ve never used WebRTC, I also understand that it is a moving target, and using an effectively unsupported, lame duck, channel driver for it is likely to result in something that breaks quite quickly.

Nontheless, I think the message means the client failed to provide any encryption key in its request, which would seem to be a bug in the client.


Will this work if I call to 10103.

though it is not work

In sip.conf, I’ve added autocreatepeer=yes for auto register of all peers who connect to my sip server

You’d need to provide detailed logging of the registration and dial processing, and also sip show peers output.

However, it is quite likely that it either not compatible with the new WebRTC code, or, more generally, got broken by another change and wasn’t noticed, because so few people use the feature and those that did weren’t keeping code up to date. In both those cases, it is very unlikely to get fixed.

sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
101004/2ailhvbd D Yes Yes 39063 OK (73 ms)
10103/mgnklui5 (Unspecified) D Yes Yes 0 UNKNOWN
10104/5mdatt6e D Yes Yes 39067 OK (71 ms)
3 sip peers [Monitored: 2 online, 1 offline Unmonitored: 0 online, 0 offline]

Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
[Sep 1 16:53:02] NOTICE[5611][C-00000302]: chan_sip.c:10405 process_sdp: Received SAVPF profle in audio offer but AVPF is not enabled, enabling: audio 57621 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126
[Sep 1 16:53:02] WARNING[5611][C-00000302]: chan_sip.c:10804 process_sdp: Rejecting secure audio stream without encryption details: audio 57621 UDP/TLS/RTP/SAVPF 111 63 103 104 9 0 8 106 105 13 110 112 113 126

I don’t know enough about Asterisk WebRTC to know whether this is useful, but the peer does seem to have been created.

This looks like the inbound leg, so it doesn’t seem to have got as far as the dialplan. I imagine AVPF would need to be enabled in the global settings, given than there is no way of making non-default settings when auto-generating peers. However, I cannot find any code in chan_sip.c that would support a global setting for “avpf”, so I don’t think that you can use autocreatepeer with WebRTC.

Already given avpf=yes in sip.conf

You can only put it in the peer section, and if you have a peer section, you don’t need autocreatepeer.

The only place where the quoted string “avpf” appears is:

			} else if (!strcasecmp(v->name, "avpf")) {
				ast_set2_flag(&peer->flags[2], ast_true(v->value), SIP_PAGE3_USE_AVPF);

which is in:

static struct sip_peer *build_peer(const char *name, struct ast_variable *v_head, struct ast_variable *alt, int realtime, int devstate_only)

If it had been supported in the general section as well, it would have been in:

static int handle_common_options(struct ast_flags *flags, struct ast_flags *mask, struct ast_variable *v)

as is the case for “dtmfmode”.

(Settings for the general section only, would have appeared in:

static int reload_config(enum channelreloadreason reason)

for example “bindaddr”.)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.