thr3ads.net - asterisk users - [asterisk-users] asterisk pjsip webrtc rtp to private IP [Dec 2019]

If this information is useful, please help other people find it:
Share via:

marek

2019-Dec-12 11:57 UTC

[asterisk-users] asterisk pjsip webrtc rtp to private IP

with wireshark i need decrypt traffic every call which is time 
consuming. get debug from pjnat through asterisk is not possible because 
of technical reasons or nobody did it?


in my case its strange that ice candidates are the same

good call

v=0
o=- 3669976329745317845 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS EoNIdKcMZvWBLULGqGPJTDe12ujjFEemeapo
m=audio 52421 RTP/SAVPF 8 0 101
c=IN IP4 10.2.152.36
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3607370648 1 udp 2122260223 10.2.152.36 52421 typ host 
generation 0 network-id 1 network-cost 10
a=candidate:2575820648 1 tcp 1518280447 10.2.152.36 9 typ host tcptype 
active generation 0 network-id 1 network-cost 10

bad call

v=0
o=- 2602173234285924157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS aDrO7zRNTqNWKodpSG62Co1IDoHReEpT8Ga3
m=audio 63249 RTP/SAVPF 8 0 101
c=IN IP4 10.2.152.36
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3607370648 1 udp 2122260223 10.2.152.36 63249 typ host 
generation 0 network-id 1 network-cost 10
a=candidate:2575820648 1 tcp 1518280447 10.2.152.36 9 typ host tcptype 
active generation 0 network-id 1 network-cost 10


but RTP looks like

bad call (1.1.1.1 is "public" ip of PSTN SIP GW)

Got  RTP packet from    1.1.1.1:13460 (type 08, seq 002433, ts 000160, 
len 000160)
Sent RTP packet to      10.2.152.36:63249 (type 08, seq 022470, ts 
000160, len 000160)
Got  RTP packet from    1.1.1.1:13460 (type 08, seq 002434, ts 000320, 
len 000160)
Sent RTP packet to      10.2.152.36:63249 (type 08, seq 022471, ts 
000320, len 000160)
Got  RTP packet from    1.1.1.1:13460 (type 08, seq 002435, ts 000480, 
len 000160)

good call (1.1.1.1 is "public" ip of PSTN SIP GW, 2.2.2.2 is public IP
of router)

Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021197, ts 000160, 
len 000160)
Sent RTP packet to *10.2.152.36:52421 (type 08, seq 032328, ts 000160, 
len 000160)*

[Dec 11 16:59:53] DEBUG[44360]: res_rtp_asterisk.c:6049 
ast_rtp_remote_address_set: Setting RTCP address on RTP instance 
'0x7faa14005408'

Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021198, ts 000320, 
len 000160)
Sent RTP packet to      2.2.2.2:52421 (via ICE) (type 08, seq 032329, ts 
000320, len 000160)
Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021199, ts 000480, 
len 000160)
Sent RTP packet to      2.2.2.2:52421 (via ICE) (type 08, seq 032330, ts 
000480, len 000160)
Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021200, ts 000640, 
len 000160)
Sent RTP packet to      2.2.2.2:52421 (via ICE) (type 08, seq 032331, ts 
000640, len 000160)
Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021201, ts 000800, 
len 000160)

looking for the part where RTP engine switch from *10.2.152.36 to **2.2.2.2*

it looks like**its somewhere in the learning phase*
*


Dne 12/12/2019 v 11:51 Joshua C. Colp napsal(a):> On Thu, Dec 12, 2019 at 6:39 AM marek <cervajs64 at gmail.com 
> <mailto:cervajs64 at gmail.com>> wrote:
>
>     hi,
>
>     i have following topology
>
>     PSTN - Asterisk ---- internet -----  router - jssip client (wss)
>
>     Asterisk 13.29.1 on public IP, chan_pjsip for wss, chan_sip/udp
>     for SIP
>     connection to PSTN
>
>     router - public IP/private IP (NAT)
>
>     jssip client - private IP - sip over websocket to Asterisk PJSIP
>
>
>     ~30% of calls has problem with no audio. reason is that Asterisk is
>     sending RTP to private IP of jssip
>
>     SDP looks the same for good call and bad call too
>
>
>     i searched through res_rtp_asterisk.c but i'm not sure where to put
>     DEBUG info about which IP and why Asterisk pick for RTP
>
>     any hint?
>
>
>     is it possible debug Asterisk STUN request/response ? or is it
>     hidden in
>     pjsip internals?
>
>
> ICE is performed using pjnath, which is part of pjproject and not 
> Asterisk itself. Looking at the SDP and the ICE candidates can tell 
> you the possibilities for the paths, and a wireshark capture can show 
> you the actual traffic going back and forth and what is being attempted.
>
> -- 
> Joshua C. Colp
> Senior Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com <http://www.sangoma.com> and 
> www.asterisk.org <http://www.asterisk.org>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191212/60e69750/attachment.html>

Joshua C. Colp

2019-Dec-12 12:02 UTC

head link

[asterisk-users] asterisk pjsip webrtc rtp to private IP

On Thu, Dec 12, 2019 at 7:57 AM marek <cervajs64 at gmail.com> wrote:
> with wireshark i need decrypt traffic every call which is time consuming.
> get debug from pjnat through asterisk is not possible because of technical
> reasons or nobody did it?
>
>
> in my case its strange that ice candidates are the same
>
> good call
>
> v=0
> o=- 3669976329745317845 2 IN IP4 127.0.0.1
> s=-
> t=0 0
> a=msid-semantic: WMS EoNIdKcMZvWBLULGqGPJTDe12ujjFEemeapo
> m=audio 52421 RTP/SAVPF 8 0 101
> c=IN IP4 10.2.152.36
> a=rtcp:9 IN IP4 0.0.0.0
> a=candidate:3607370648 1 udp 2122260223 10.2.152.36 52421 typ host
> generation 0 network-id 1 network-cost 10
> a=candidate:2575820648 1 tcp 1518280447 10.2.152.36 9 typ host tcptype
> active generation 0 network-id 1 network-cost 10
>
> bad call
>
> v=0
> o=- 2602173234285924157 2 IN IP4 127.0.0.1
> s=-
> t=0 0
> a=msid-semantic: WMS aDrO7zRNTqNWKodpSG62Co1IDoHReEpT8Ga3
> m=audio 63249 RTP/SAVPF 8 0 101
> c=IN IP4 10.2.152.36
> a=rtcp:9 IN IP4 0.0.0.0
> a=candidate:3607370648 1 udp 2122260223 10.2.152.36 63249 typ host
> generation 0 network-id 1 network-cost 10
> a=candidate:2575820648 1 tcp 1518280447 10.2.152.36 9 typ host tcptype
> active generation 0 network-id 1 network-cost 10
>
>
> but RTP looks like
>
> bad call (1.1.1.1 is "public" ip of PSTN SIP GW)
>
> Got  RTP packet from    1.1.1.1:13460 (type 08, seq 002433, ts 000160,
> len 000160)
> Sent RTP packet to      10.2.152.36:63249 (type 08, seq 022470, ts
> 000160, len 000160)
> Got  RTP packet from    1.1.1.1:13460 (type 08, seq 002434, ts 000320,
> len 000160)
> Sent RTP packet to      10.2.152.36:63249 (type 08, seq 022471, ts
> 000320, len 000160)
> Got  RTP packet from    1.1.1.1:13460 (type 08, seq 002435, ts 000480,
> len 000160)
>
> good call (1.1.1.1 is "public" ip of PSTN SIP GW, 2.2.2.2 is
public IP of
> router)
>
> Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021197, ts 000160,
> len 000160)
> Sent RTP packet to      *10.2.152.36:52421 <http://10.2.152.36:52421>
> (type 08, seq 032328, ts 000160, len 000160)*
>
> [Dec 11 16:59:53] DEBUG[44360]: res_rtp_asterisk.c:6049
> ast_rtp_remote_address_set: Setting RTCP address on RTP instance
> '0x7faa14005408'
>
> Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021198, ts 000320,
> len 000160)
> Sent RTP packet to      2.2.2.2:52421 (via ICE) (type 08, seq 032329, ts
> 000320, len 000160)
> Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021199, ts 000480,
> len 000160)
> Sent RTP packet to      2.2.2.2:52421 (via ICE) (type 08, seq 032330, ts
> 000480, len 000160)
> Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021200, ts 000640,
> len 000160)
> Sent RTP packet to      2.2.2.2:52421 (via ICE) (type 08, seq 032331, ts
> 000640, len 000160)
> Got  RTP packet from    1.1.1.1:15026 (type 08, seq 021201, ts 000800,
> len 000160)
>
> looking for the part where RTP engine switch from *10.2.152.36 to *
> *2.2.2.2*
>
> it looks like its somewhere in the learning phase
>
You need to look at the ICE candidates given by Asterisk as well, and
ensure that if it is behind NAT it is configured in rtp.conf to do some
mapping of candidates, as well as ensuring the firewall is open. The
wireshark capture like I said will provide insight into what ICE is doing.

ICE is what is used to figure out the path and determine the IP
address/port to use. If that fails, then it won't work.

I would also urge you to learn more about the lower level details of WebRTC
if you plan on deploying it. You really need some understanding of
ICE/STUN/DTLS-SRTP if deploying, as those are fundamental aspects and stuff
doesn't just work in all cases. Digging into why it's not working takes
you
down to those.

-- 
Joshua C. Colp
Senior Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191212/99a3c717/attachment.html>

marek

2019-Dec-12 12:57 UTC

head link

[asterisk-users] asterisk pjsip webrtc rtp to private IP

Asterisk is on public IP (as described in the first email)

i have 10 years experience in voip, 4 years webrtc in production. i know 
about ICE/STUN/DTLS-SRTP. yes, not every detail but the basic mechanism

but i confess. i dont understand WHY Asterisk SOMETIMES switches 
destination IP in RTP. this is not only about ICE. its about RTP engine 
too which is Asterisk specific

and Asterisk DEBUG is not helping


... going back to read res_rtp_asterisk.c & decrypting pcaps with wireshark


Dne 12/12/2019 v 13:02 Joshua C. Colp napsal(a):> On Thu, Dec 12, 2019 at 7:57 AM marek <cervajs64 at gmail.com 
> <mailto:cervajs64 at gmail.com>> wrote:
>
>     with wireshark i need decrypt traffic every call which is time
>     consuming. get debug from pjnat through asterisk is not possible
>     because of technical reasons or nobody did it?
>
>
>     in my case its strange that ice candidates are the same
>
>     good call
>
>     v=0
>     o=- 3669976329745317845 2 IN IP4 127.0.0.1
>     s=-
>     t=0 0
>     a=msid-semantic: WMS EoNIdKcMZvWBLULGqGPJTDe12ujjFEemeapo
>     m=audio 52421 RTP/SAVPF 8 0 101
>     c=IN IP4 10.2.152.36
>     a=rtcp:9 IN IP4 0.0.0.0
>     a=candidate:3607370648 1 udp 2122260223 10.2.152.36 52421 typ host
>     generation 0 network-id 1 network-cost 10
>     a=candidate:2575820648 1 tcp 1518280447 10.2.152.36 9 typ host
>     tcptype active generation 0 network-id 1 network-cost 10
>
>     bad call
>
>     v=0
>     o=- 2602173234285924157 2 IN IP4 127.0.0.1
>     s=-
>     t=0 0
>     a=msid-semantic: WMS aDrO7zRNTqNWKodpSG62Co1IDoHReEpT8Ga3
>     m=audio 63249 RTP/SAVPF 8 0 101
>     c=IN IP4 10.2.152.36
>     a=rtcp:9 IN IP4 0.0.0.0
>     a=candidate:3607370648 1 udp 2122260223 10.2.152.36 63249 typ host
>     generation 0 network-id 1 network-cost 10
>     a=candidate:2575820648 1 tcp 1518280447 10.2.152.36 9 typ host
>     tcptype active generation 0 network-id 1 network-cost 10
>
>
>     but RTP looks like
>
>     bad call (1.1.1.1 is "public" ip of PSTN SIP GW)
>
>     Got  RTP packet from 1.1.1.1:13460 <http://1.1.1.1:13460> (type
>     08, seq 002433, ts 000160, len 000160)
>     Sent RTP packet to 10.2.152.36:63249 <http://10.2.152.36:63249>
>     (type 08, seq 022470, ts 000160, len 000160)
>     Got  RTP packet from 1.1.1.1:13460 <http://1.1.1.1:13460> (type
>     08, seq 002434, ts 000320, len 000160)
>     Sent RTP packet to 10.2.152.36:63249 <http://10.2.152.36:63249>
>     (type 08, seq 022471, ts 000320, len 000160)
>     Got  RTP packet from 1.1.1.1:13460 <http://1.1.1.1:13460> (type
>     08, seq 002435, ts 000480, len 000160)
>
>     good call (1.1.1.1 is "public" ip of PSTN SIP GW, 2.2.2.2 is
>     public IP of router)
>
>     Got  RTP packet from 1.1.1.1:15026 <http://1.1.1.1:15026> (type
>     08, seq 021197, ts 000160, len 000160)
>     Sent RTP packet to *10.2.152.36:52421 <http://10.2.152.36:52421>
>     (type 08, seq 032328, ts 000160, len 000160)*
>
>     [Dec 11 16:59:53] DEBUG[44360]: res_rtp_asterisk.c:6049
>     ast_rtp_remote_address_set: Setting RTCP address on RTP instance
>     '0x7faa14005408'
>
>     Got  RTP packet from 1.1.1.1:15026 <http://1.1.1.1:15026> (type
>     08, seq 021198, ts 000320, len 000160)
>     Sent RTP packet to 2.2.2.2:52421 <http://2.2.2.2:52421> (via ICE)
>     (type 08, seq 032329, ts 000320, len 000160)
>     Got  RTP packet from 1.1.1.1:15026 <http://1.1.1.1:15026> (type
>     08, seq 021199, ts 000480, len 000160)
>     Sent RTP packet to 2.2.2.2:52421 <http://2.2.2.2:52421> (via ICE)
>     (type 08, seq 032330, ts 000480, len 000160)
>     Got  RTP packet from 1.1.1.1:15026 <http://1.1.1.1:15026> (type
>     08, seq 021200, ts 000640, len 000160)
>     Sent RTP packet to 2.2.2.2:52421 <http://2.2.2.2:52421> (via ICE)
>     (type 08, seq 032331, ts 000640, len 000160)
>     Got  RTP packet from 1.1.1.1:15026 <http://1.1.1.1:15026> (type
>     08, seq 021201, ts 000800, len 000160)
>
>     looking for the part where RTP engine switch from *10.2.152.36 to
>     **2.2.2.2*
>
>     it looks like**its somewhere in the learning phase
>
>
> You need to look at the ICE candidates given by Asterisk as well, and 
> ensure that if it is behind NAT it is configured in rtp.conf to do 
> some mapping of candidates, as well as ensuring the firewall is open. 
> The wireshark capture like I said will provide insight into what ICE 
> is doing.
>
> ICE is what is used to figure out the path and determine the IP 
> address/port to use. If that fails, then it won't work.
>
> I would also urge you to learn more about the lower level details of 
> WebRTC if you plan on deploying it. You really need some understanding 
> of ICE/STUN/DTLS-SRTP if deploying, as those are fundamental aspects 
> and stuff doesn't just work in all cases. Digging into why it's not
> working takes you down to those.
>
> -- 
> Joshua C. Colp
> Senior Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com <http://www.sangoma.com> and 
> www.asterisk.org <http://www.asterisk.org>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20191212/89ebd113/attachment.html>

Maybe Matching Threads

Search for more apparently analagous threads

asterisk users - Dec 2019 - asterisk pjsip webrtc rtp to private IP

[asterisk-users] asterisk pjsip webrtc rtp to private IP

[asterisk-users] asterisk pjsip webrtc rtp to private IP

[asterisk-users] asterisk pjsip webrtc rtp to private IP

Maybe Matching Threads