Why Does ICE Return Public IP in WebRTC but Private IP in MicroSIP?

Asterisk Asterisk SIP
1

Hello everyone,

I’m troubleshooting some SIP/WebRTC NAT issues and came across something odd.

When using a WebRTC client, ICE negotiation correctly returns a public IP in the SDP offer, and everything works as expected. However, when I use MicroSIP (with ICE enabled), the SDP includes a private/internal IP instead.
As can be seen here in rtp set debug on

Sent RTP packet to      {MY PUBLIC IP}:55473 (via ICE) (type 09, seq 023994, ts 000080, len 000090)
Got  RTP packet from    {MY PUBLIC IP}:55473 (type 09, seq 030619, ts 3340734212, len 000170)

MicroSIp With ICE enabled:

Sent RTP packet to      192.168.1.77:4035 (type 00, seq 006999, ts 005920, len 000160)

With ICE disabled:

Got  RTP packet from    {MY PUBLIC IP}:4002 (type 00, seq 009740, ts 039040, len 000160)
Sent RTP packet to      {MY PUBLIC IP}:4002 (type 00, seq 007840, ts 011200, len 000160)

As a result, audio fails in the MicroSIP when ICE is enabled.

Question
Why does ICE behave differently between these two clients? Shouldn’t both be able to discover and advertise the public IP if ICE is working properly? Both are running In my machine.

Any insight would be greatly appreciated!

Note: I’ve added the following to rtp.conf to help with NAT and both endpoints have ice_support=yes:

[ice_host_candidates]
172.19.0.5 => {Azure VM PUBLIC_IP}

Where 172.19.0.5 is a Docker internal IP that is used when SDP is exchange when I don’t have [ice_host_candidates] configured.

Thank you!

2

This is what the remote client would have put in the SDP for the c= line. ICE did not negotiate, be it at all or successfully. Why that is - no clue. Basically no information in here to be able to provide any detail.

A packet capture would show the actual ICE negotiation occurring using STUN packets, and the SDP on each side would show the ICE candidates each side provided.

3

I don’t know if this helps, If not where/how can I check ICE negotiations?
Logs From Asterisk:

INVITE sip:100@{Azure VM PUBLIC_IP};transport=tcp SIP/2.0
Via: SIP/2.0/TCP {MY PUBLIC IP}:56415;rport;branch=z9hG4bKPj5deef4c8fc9848d0aa77e139c5ec167c;alias
Max-Forwards: 70
From: "6001" <sip:6001@{Azure VM PUBLIC_IP}>;tag=b5f068f8a88e41839cec48067b79a011
To: <sip:100@{Azure VM PUBLIC_IP}>
Contact: <sip:6001@{MY PUBLIC IP}:56415;transport=TCP;ob>;+sip.ice
Call-ID: f919fc3bd7d245dab913c282174e9875
CSeq: 9500 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: MicroSIP/3.21.6
Authorization: Digest username="6001", realm="asterisk", nonce="1752589363/2d4071fc827f74b17ba1e5357b1ddc3f", uri="sip:100@{Azure VM PUBLIC_IP};transport=tcp", response="d83712ceacb1279631e926081da2e0ac", algorithm=MD5, cnonce="129e94242c09491dbf9ae66112d0db43", opaque="3cfe4a7870d8cc40", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length:  1016

v=0
o=- 3961581763 3961581763 IN IP4 192.168.1.77
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4011 RTP/AVP 8 0 96 97 98 101 102
c=IN IP4 192.168.1.77
b=TIAS:64000
a=rtcp:4003 IN IP4 192.168.1.77
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:96 G7221/32000
a=fmtp:96 bitrate=24000
a=rtpmap:97 G7221/32000
a=fmtp:97 bitrate=32000
a=rtpmap:98 G7221/32000
a=fmtp:98 bitrate=48000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:102 telephone-event/32000
a=fmtp:102 0-16
a=ssrc:1557209456 cname:0ae90d246d800373
a=ice-ufrag:161e5482
a=ice-pwd:2a8d287153a8348c36b81c5e
a=candidate:Hc0a8014d 1 UDP 2130706431 192.168.1.77 4011 typ host
a=candidate:Hac1fd001 1 UDP 2130706175 172.31.208.1 4011 typ host
a=candidate:Hc0a83801 1 UDP 2130705919 192.168.56.1 4011 typ host
a=candidate:Hc0a8014d 2 UDP 2130706430 192.168.1.77 4003 typ host
a=candidate:Hac1fd001 2 UDP 2130706174 172.31.208.1 4003 typ host
a=candidate:Hc0a83801 2 UDP 2130705918 192.168.56.1 4003 typ host
<--- Transmitting SIP response (1208 bytes) to TCP:{MY PUBLIC IP}:56415 --->
SIP/2.0 200 OK
Via: SIP/2.0/TCP {MY PUBLIC IP}:56415;rport=56415;received={MY PUBLIC IP};branch=z9hG4bKPj5deef4c8fc9848d0aa77e139c5ec167c;alias
Call-ID: f919fc3bd7d245dab913c282174e9875
From: "6001" <sip:6001@{Azure VM PUBLIC_IP}>;tag=b5f068f8a88e41839cec48067b79a011
To: <sip:100@{Azure VM PUBLIC_IP}>;tag=16939b6a-f0ac-4e5a-85e7-4bd8fe62bfb8
CSeq: 9500 INVITE
Server: Asterisk PBX 18.24.3
Contact: <sip:{Azure VM PUBLIC_IP}:5060;transport=TCP>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, INFO
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   499

v=0
o=- 3961581763 3961581765 IN IP4 {Azure VM PUBLIC_IP}
s=Asterisk
c=IN IP4 {Azure VM PUBLIC_IP}
t=0 0
m=audio 10056 RTP/AVP 0 8 101
a=ice-ufrag:269589e06dad6c9d391d16f9040d1598
a=ice-pwd:16ef439b148e044b002af27605e02253
a=candidate:H87ec6c8f 1 UDP 2130706431 {Azure VM PUBLIC_IP} 10056 typ host
a=candidate:H87ec6c8f 2 UDP 2130706430 {Azure VM PUBLIC_IP} 10057 typ host
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:140
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
4

These are the ICE candidates from MicroSIP.

These are the ICE candidates from Asterisk.

Your network arrangement is complex, so you’re going to need to look at the actual traffic to understand what is going on and why it is failing to find a viable ICE yourself.

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.