21 Apr
2017
21 Apr
'17
10:46 a.m.
Hello!
I have next topology: ISP->Kamailio + Rtpengine->WebRTC
Sometimes I receive from Browser side SDP like below with private IPs in
ICE candidates.
- Please explain why it happens?
- How ICE finds a pair? I think Rtpengine obtains packet from Browser
and somehow matches with peer (as it can't reach Browser via private IP)
U KAMAILIO_IP:34150 -> RTPENGINE_IP:22222
0_16586_545 d3:sdp962:v=0.
o=- 3981552194926701250 2 IN IP4 127.0.0.1.
s=-.
t=0 0.
a=msid-semantic: WMS 5efe361e-087d-47de-98f6-9b51427d3764.
m=audio 50589 RTP/SAVPF 8 0.
c=IN IP4 192.168.2.205.
a=rtcp:9 IN IP4 0.0.0.0.
a=candidate:710145796 1 udp 2122255103 <(212)%20225-5103>
2001::9d38:6abd:3c21:28f:3f57:fd32 50588 typ host generation 0 network-id 1
network-cost 50.
a=candidate:2355154215 1 udp 2122194687 <(212)%20219-4687> 192.168.2.205
50589 typ host generation 0 network-id 2.
a=ice-ufrag:sPAh.
a=ice-pwd:RjXqOz8rpwjhKPU3BzXkJd1d.
a=fingerprint:sha-256 04:AF:D4:6C:07:C2:DD:18:48:E0:
BC:46:15:15:00:5F:C9:AD:CF:8D:F3:94:55:5A:54:0C:37:B3:E6:44:63:EC.
a=setup:active.
a=mid:audio.
a=sendrecv.
a=rtcp-mux.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=ssrc:3055599516 <(305)%20559-9516> cname:n0Cdw7SNbYDIba8s.
a=ssrc:3055599516 <(305)%20559-9516> msid:5efe361e-087d-47de-98f6-9b51427d3764
41750b25-d640-4bad-8953-55f4e2684c49.
a=ssrc:3055599516 <(305)%20559-9516> mslabel:5efe361e-087d-47de-
98f6-9b51427d3764.
a=ssrc:3055599516 <(305)%20559-9516> label:41750b25-d640-4bad-8953-
55f4e2684c49.
3:ICE6:remove5:flagsl13:trust-address14:media-handover8:
SDES-offe7:replacel6:origin18:session-connectione18:
transport-protocol7:RTP/AVP8:rtcp-muxl5:offer6:accepte7:
call-id37:domain.com_29465313:received-froml3:IP412:10.23.
255.93e8:from-tag13:QQcg5eFv08S9K6:to-tag10:nsebpmf7ia7:command6:answere
21 Apr
21 Apr
2:06 p.m.
Hi Denys,
It is nothing unusual to see private ip address in the ICE candidate list.
rfc5245 : "Naturally, one viable candidate is a transport address obtained
directly from a local interface."
Here you can find more info:
https://tools.ietf.org/html/rfc5245#section-2.1
On Fri, Apr 21, 2017 at 11:46 AM, Denys Pozniak <denys.pozniak(a)crazycall.com
wrote:
Hello!
I have next topology: ISP->Kamailio + Rtpengine->WebRTC
Sometimes I receive from Browser side SDP like below with private IPs in
ICE candidates.
- Please explain why it happens?
- How ICE finds a pair? I think Rtpengine obtains packet from Browser
and somehow matches with peer (as it can't reach Browser via private IP)
U KAMAILIO_IP:34150 -> RTPENGINE_IP:22222
0_16586_545 d3:sdp962:v=0.
o=- 3981552194926701250 2 IN IP4 127.0.0.1.
s=-.
t=0 0.
a=msid-semantic: WMS 5efe361e-087d-47de-98f6-9b51427d3764.
m=audio 50589 RTP/SAVPF 8 0.
c=IN IP4 192.168.2.205.
a=rtcp:9 IN IP4 0.0.0.0.
a=candidate:710145796 1 udp 2122255103 <(212)%20225-5103>
2001::9d38:6abd:3c21:28f:3f57:fd32 50588 typ host generation 0 network-id
1 network-cost 50.
a=candidate:2355154215 1 udp 2122194687 <(212)%20219-4687> 192.168.2.205
50589 typ host generation 0 network-id 2.
a=ice-ufrag:sPAh.
a=ice-pwd:RjXqOz8rpwjhKPU3BzXkJd1d.
a=fingerprint:sha-256 04:AF:D4:6C:07:C2:DD:18:48:E0:
BC:46:15:15:00:5F:C9:AD:CF:8D:F3:94:55:5A:54:0C:37:B3:E6:44:63:EC.
a=setup:active.
a=mid:audio.
a=sendrecv.
a=rtcp-mux.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=ssrc:3055599516 <(305)%20559-9516> cname:n0Cdw7SNbYDIba8s.
a=ssrc:3055599516 <(305)%20559-9516> msid:5efe361e-087d-47de-98f6-9b51427d3764
41750b25-d640-4bad-8953-55f4e2684c49.
a=ssrc:3055599516 <(305)%20559-9516> mslabel:5efe361e-087d-47de-98f
6-9b51427d3764.
a=ssrc:3055599516 <(305)%20559-9516> label:41750b25-d640-4bad-8953-
55f4e2684c49.
3:ICE6:remove5:flagsl13:trust-address14:media-handover8:SDES
-offe7:replacel6:origin18:session-connectione18:transport-
protocol7:RTP/AVP8:rtcp-muxl5:offer6:accepte7:call-id37:
domain.com_29465313:received-froml3:IP412:10.23.255.93e8:
from-tag13:QQcg5eFv08S9K6:to-tag10:nsebpmf7ia7:command6:answere
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Regards,
Arsen Semionov
Eurolan.info
cell: +442035198881
2:20 p.m.
On 21 April 2017 at 10:46, Denys Pozniak <denys.pozniak(a)crazycall.com>
wrote:
Sometimes I receive from Browser side SDP like below
with private IPs in
ICE candidates.
For us it is important that those private IPs are included since for many
customers we have "NATless" routing available via a VPN.
ICE will find the private to private path over the VPN and that's exactly
what we want!
Steve
2:30 p.m.
"It is nothing unusual to see private ip address in the ICE candidate list. "
- Yes, I agree with you, but according to my opinion here must be also
public IP which obtained from STUN server.
We have own STUN (coturn) and I saw that browser did request and received
response with his public IP.
On 21 April 2017 at 14:20, Steve Davies <
steve-lists-srusers(a)connection-telecom.com> wrote:
On 21 April 2017 at 10:46, Denys Pozniak <denys.pozniak(a)crazycall.com>
wrote:
Sometimes I receive from Browser side SDP like
below with private IPs in
ICE candidates.
For us it is important that those private IPs are included since for many
customers we have "NATless" routing available via a VPN.
ICE will find the private to private path over the VPN and that's exactly
what we want!
Steve
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:50 p.m.
On 04/21/2017 04:46 AM, Denys Pozniak wrote:
Hello!
I have next topology: ISP->Kamailio + Rtpengine->WebRTC
Sometimes I receive from Browser side SDP like below with private IPs
in ICE candidates.
* Please explain why it happens?
* How ICE finds a pair? I think Rtpengine obtains packet from
Browser and somehow matches with peer (as it can't reach Browser
via private IP)
ICE candidate collection is done entirely on the client side, i.e. in
the browser. If your browser fails to obtain public address ICE
candidates, it's a problem with the browser script.
ICE should still be able to find a working candidate pair though,
because once the opposite direction SDP is seen by the browser (which
should contain public address ICE candidates from the other client or
rtpengine), the browser will start sending checks to these candidates
and the other side will then see the NAT'd address and use this to run
checks. ICE completion would be delayed until after the answer/200 is
seen, but it should still complete.
Cheers
3:11 p.m.
Thank you for the explanation!
On 21 April 2017 at 14:50, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/21/2017 04:46 AM, Denys Pozniak wrote:
Hello!
I have next topology: ISP->Kamailio + Rtpengine->WebRTC
Sometimes I receive from Browser side SDP like below with private IPs in
ICE candidates.
- Please explain why it happens?
- How ICE finds a pair? I think Rtpengine obtains packet from Browser
and somehow matches with peer (as it can't reach Browser via private IP)
ICE candidate collection is done entirely on the client side, i.e. in the
browser. If your browser fails to obtain public address ICE candidates,
it's a problem with the browser script.
ICE should still be able to find a working candidate pair though, because
once the opposite direction SDP is seen by the browser (which should
contain public address ICE candidates from the other client or rtpengine),
the browser will start sending checks to these candidates and the other
side will then see the NAT'd address and use this to run checks. ICE
completion would be delayed until after the answer/200 is seen, but it
should still complete.
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2582
days inactive
2582
days old
5 comments
4 participants
participants (4)
-
Arsen -
Denys Pozniak -
Richard Fuchs -
Steve Davies