[SR-Users] [SOLVED] Re: RTPEngine IPv4 to IPv6 bridging returning c=IN IP4 0.0.0.0 on answer?

Anthony Messina amessina at messinet.com
Thu Feb 26 02:41:21 CET 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150225/a6879bb9/attachment.sig>


More information about the sr-users mailing list