On Wednesday, February 25, 2015 08:31:38 AM Richard Fuchs wrote:
On 24/02/15 08:20 PM, 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
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
Richard, this patch does indeed fix the problem. Thank you. -A
--
Anthony -
https://messinet.com/ -
https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E