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
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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On 21 April 2017 at 10:46, Denys Pozniak denys.pozniak@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
"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@connection-telecom.com> wrote:
On 21 April 2017 at 10:46, Denys Pozniak denys.pozniak@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
Thank you for the explanation!
On 21 April 2017 at 14:50, Richard Fuchs rfuchs@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Arsen -
Denys Pozniak -
Richard Fuchs -
Steve Davies