Re: [asterisk-users] PJSIP sending RTP to private address
About this case: the old SIP channel behaves correctly.
On Sun, May 17, 2020 at 2:44 AM Saint Michael wrote:
> My phone is located behind a NAT, 172.16.0.0/21.
> Asterisk 16 is on a public IP.
> PJSIP has the config below:
> force_rport=yes
> direct_media=yes
> disable_direct_media_on_nat = yes
> direct_media_method=invite
>
> But when I send a call I see the RTP being sent to my private address, vs
> the public IP. This only happens when Asterisk has dialed the call to
> another carrier. If instead of Dial I choose Answer() and MusicOnHold, then
> the RTP gets shipped to the right address.
> This is a sample of the erroneous behavior:
> Got RTP packet fromXX.XX.XX.XX:17510 (type 00, seq 024786, ts 017440,
> len 000160)
> Sent RTP packet to 172.16.7.254:50798 (type 00, seq 010736, ts
> 017440, len 000160)
>
> 172.16.7.254 is my private address.
> What am I missing? Should I open a bug?
> Asterisk should never, ever send RTP to a private address when Asterisk
> itself is on a public IP.
> Before you ask, the dialplan is 3 lines,
> '_X.' => 1. NoOP()
> 2. Dial(PJSIP/${EXTEN}@carrier)
> 3. Hangup()
>
>
>
>
>
>
>
>
>
>
>
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Help missing
What is the application that you are missing? On Sun, May 17, 2020 at 01:32 Saint Michael wrote: > I want to see the help when I type core show application , and it's > not available. This is asterisk 16 from sources. I have libxml2-dev > installed. Ubuntu 19 > What am I missing? > Philip > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Meaning of RTT in channelstats
On Sun, May 17, 2020 at 5:36 AM Michael Maier wrote: > On 17.05.20 at 01:28 Joshua C. Colp wrote: > > On Sat, May 16, 2020 at 10:58 AM Michael Maier > wrote: > > > >> => How are the RTT values exactly calculated? Which values are actually > >> used for? > >> > > > > The value is calculated according to the logic in the RFC[1]. > Specifically > > using embedded timestamps in the RTCP packets and calculated delays. The > > value is presented in seconds I believe in the output. > > Thanks Joshua! > > >> => What about the processing time between the inbound leg and the > outbound > >> leg (transcoding, ...)? > >> > > > > That has no impact within this, since it's calculated using the RTCP > > traffic which is not used for media. It's really just for round trip time > > of a UDP packet, not for end to end time of a single audio packet/frame > > through the system. > > Let's try to sum it up on base of the given easy example how to get the > complete delay between those two speakers: > > A calls B: > ...Receive. > .Transmit.. > > BridgeId ChannelId UpTime.. Codec. CountLost Pct Jitter > CountLost Pct Jitter RTT > > > === > > c8137221 327-0004 03:22:42 g722 608K 00 0.000 > 608K 00 0.000 0.000 > c8137221 providePJSIP-xxx-0 03:22:42 alaw 608K 00 0.000 > 608K 00 0.000 0.023 > > A says something. > > 1. quantization:20 ms > 2. processing time on the phone base / DECT:? > 3. way from phone base to asterisk: 0 ms > 4. processing time on asterisk / transcoding: ? > 5. transport to destination:11.5 ms > 6. processing time on destination side: ? > > Therefore it would take about 35 ms until B can here A. Is this basically > a correct estimation or did I miss(understand) something? > Roughly speaking, yes. It'd likely be more because of the aspects that aren't represented here but yes. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Meaning of RTT in channelstats
On 17.05.20 at 01:28 Joshua C. Colp wrote: > On Sat, May 16, 2020 at 10:58 AM Michael Maier wrote: > >> => How are the RTT values exactly calculated? Which values are actually >> used for? >> > > The value is calculated according to the logic in the RFC[1]. Specifically > using embedded timestamps in the RTCP packets and calculated delays. The > value is presented in seconds I believe in the output. Thanks Joshua! >> => What about the processing time between the inbound leg and the outbound >> leg (transcoding, ...)? >> > > That has no impact within this, since it's calculated using the RTCP > traffic which is not used for media. It's really just for round trip time > of a UDP packet, not for end to end time of a single audio packet/frame > through the system. Let's try to sum it up on base of the given easy example how to get the complete delay between those two speakers: A calls B: ...Receive. .Transmit.. BridgeId ChannelId UpTime.. Codec. CountLost Pct Jitter CountLost Pct Jitter RTT === c8137221 327-0004 03:22:42 g722 608K 00 0.000 608K 00 0.000 0.000 c8137221 providePJSIP-xxx-0 03:22:42 alaw 608K 00 0.000 608K 00 0.000 0.023 A says something. 1. quantization:20 ms 2. processing time on the phone base / DECT:? 3. way from phone base to asterisk: 0 ms 4. processing time on asterisk / transcoding: ? 5. transport to destination:11.5 ms 6. processing time on destination side: ? Therefore it would take about 35 ms until B can here A. Is this basically a correct estimation or did I miss(understand) something? Thanks Michael > [1] https://tools.ietf.org/html/rfc3550 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
