[SOLVED] Is not RTP traffic when forwarding

Hello!
Just warning you I do not speak English, in General, the essence of the problem.
The essence of the problem. If forwarding is not RTP traffic, if you use the function Answer Dial before RTP traffic goes.
Example config:

exten => r,1,Dial(${TRN}/+7xxxxxxxxxx,300,ttT)
same => n,Hangup()

So there is no RTP traffic, respectively, and the silence. If you add before Dial function Answer all the rules.

Example of console output with RTP debug enabled

[root@voip asterisk]# asterisk-rvvvvvv
Asterisk 14.2.1, Copyright © 1999 - 2016, Digium, Inc. and others.
Created by Mark Spencer markster@digium.com
Asterisk comes with ABSOLUTELY NO WARRANTY; type ‘core show warranty’ for detail
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type ‘core show license’ for details.

14.2.1 Connected to Asterisk currently running on voip (pid = 26264)
== Using SIP CoS mark 5 TRN
– Executing [r@tula:1] Dial(“SIP/RTK-0000002a”, “SIP/TRN/+7xxxxxxxxxx,300,ttT”) in new stack
== Using SIP CoS mark 5 TRN
– Called SIP/TRN/+7xxxxxxxxxx
– SIP/RTK-0000002b is making progress passing it to SIP/TRN-0000002a
– SIP/RTK-0000002b is ringing
– SIP/RTK-0000002b is ringing
– SIP/RTK-0000002b answered SIP/TRN-0000002a
– Channel SIP/RTK-0000002b joined ‘simple_bridge’ basic-bridge
– Channel SIP/RTK-0000002a joined ‘simple_bridge’ basic-bridge
– Channel SIP/RTK-0000002b left ‘simple_bridge’ basic-bridge
– Channel SIP/RTK-0000002a left ‘simple_bridge’ basic-bridge
== Spawn extension (tula, r, 1) exited non-zero on ‘SIP/TRN-0000002a’

Number +7xxxxxxxxxx changed. As the name trunk.
Actually the question, who may be faced with this, what could be the reason?

There is no evidence of any problem in the log. You need to enable the debug log and use “sip set debug on”. Please use the log files, not a a scree-scrape, as the log files include times.

I think you should change

exten => r,1,Dial(${TRN}/+7xxxxxxxxxx,300,ttT)

to

exten => r,1,Dial(SIP/+7xxxxxxxxxx@${TRN},300,ttT)

Looks to me like you are trying to Dial the “Trunk” directly, and not the number, but I can’t ensure that. If I’m wrong, this message can be deleted.

The screenshot of the sip exchange below. The call takes place. There are two codec g711a/g711u in the answer silence.

a call is no RTP flow, CMP is.
The problem with RTP flow is solved if you put before you dial, answer
exten => r,1,Answer
same => n,Dial(${TRN}/+7xxxxxxxxxx,300,ttT)
The question is why no Answer, Asterisk does not start RTP flow, maybe the SIP provider?

Asterisk forwards RTP traffic it receives. If it receives no RTP, it doesn’t send any. It would be up to each side to send the RTP media.

You’ve only provided an overview of the SIP exchange. We need to see the details. In particular the SDP.

Thank you all, figured out why it works or doesn’t work. The fact that Asterisk does not send 200 OK, no Answer functions, the service provider, causing the provider does not give RTP traffic. The screenshot below on the left without Answer, the right Answer. All once again many thanks for taking part. :relaxed:

Asterisk should send 200 OK when the outgoing leg answers. Sending 200 OK before then can result in the caller being charged for listening to ringback tone and any automation thinking that the call succeeded.

Asterisk does, in fact, send 200 OK, at 23.871, in the first case, and at the right point to do so.

And I think Asterisk is not able to work by transit.

I don’t understand “by transit”.

What you seem to be doing is a very normal thing to do in Asterisk, but, as already noted, you are not providing enough information to understand why it is not working for you.

It’s my provider. As it turned out this is not a “pure” sip provider, virtual PBX, running sip Protocol. In fact, and there is this anomaly.

Unable to make dumps in pcap format. If you help me get to the bottom.

Asterisk, in fact I understand it can’t work as a transit node.

pcap is too much hassle to work with. What we really want is the text context of the relevant Asterisk log, directly pasted into the thread (as unformatted text, and preferably with nothing but INVITE and BYE transactions).