Which IP address has been sent to carrier in SDP offer? GLOBAL_IPv6 or EXTERNAL_IPv4?

On Tuesday 24 February 2015 19:20:15 Anthony Messina wrote: > This is probably very likely a configuration issue on my part, but I > wanted > to check before reporting an RTPEngine bug... > > > > Thank you for any pointers or suggestions. > > > > This is a multi-homed server where > > > > em1: INTERNAL_IPv4 & GLOBAL_IPv6 > em2: EXTERNAL_IPv4 > > > > Note that below, the IPv6 address on my server is the same on priv and pub > and is reachable from "internal" and "external" endpoints. I have it set > this way as I eventually want to use ICE and have it create the proper > IPv4/IPv6 candidates regardless of the RTPEngine --interface. > > > > I'm running RTPEngine with the following: > > > /usr/sbin/rtpengine > --table=0 > --interface=pub/EXTERNAL_IPv4 > --interface=pub/GLOBAL_IPv6 > --interface=priv/INTERNAL_IPv4 > --interface=priv/GLOBAL_IPv6 > --listen-ng=127.0.0.1:12221 > --tos=184 > --log-level=7 > --pidfile=/run/rtpengine/rtpengine.test.pid > > > > I'm trying to bridge an IPv4-initated call to an IPv6 carrier. The call > seems to flow properly until the carrier's SDP is passed through RTPEngine > on answer. The snippets are here, and I have attached the full log. > > > > [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Received command 'answer' from > 127.0.0.1:38786 > [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Dump for 'answer' from 127.0.0.1:38786: > { "sdp": "v=0 > o=FreeSWITCH 1424799070 1424799071 IN IP6 CARRIER_IPv6 > s=FreeSWITCH > c=IN IP6 CARRIER_IPv6 > t=0 0 > m=audio 24308 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:20 > a=rtcp:24309 IN IP6 CARRIER_IPv6 > > > > > The CARRIER_IPv6 gets converted as follows with 0.0.0.0 in place of what > should be the address of my RTPEngine instance. Shouldn't it be returning > the IPv4 address of my RTPEngine instance (either priv or pub as called > from Kamailio)? > > > > [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Replying to 'answer' from > 127.0.0.1:38786 [TdBe4MJa1DC4teIllJkqq6U-PAw9Zh4y] Response dump for > 'answer' to > 127.0.0.1:38786: { "sdp": "v=0 > o=FreeSWITCH 1424799070 1424799071 IN IP4 0.0.0.0 > s=FreeSWITCH > c=IN IP4 0.0.0.0 > t=0 0 > m=audio 38914 RTP/SAVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=silenceSupp:off - - - - > a=ptime:20 > a=sendrecv > a=rtcp:38915 > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > inline:Jby5IPt4WlNySLd66eK+Mcky8yJeUwp7dWH7W3aO

On 24/02/15 08:20 PM, Anthony Messina wrote: This was indeed an old bug which apparently nobody ever came across. I've just fixed it in master. https://github.com/sipwise/rtpengine/commit/956d07d42e106231aa4cae13d706b30e 7833ae89