Hi,
As mentioned in my previous mail i still have crash issue with video on
IPV6. Can some one please take a look at the below logs and provide some
suggestions.
*2017-04-17 15:33:38.974082+0530 SIPX[3190:953743] -[UConnect
changedAudioCallToVideoCall:]*
*15:33:38.974 pjsua_call.c !Sending re-INVITE on call 0*
*15:33:38.974 pjsua_media.c .Call 0: re-initializing media..*
*15:33:38.975 pjsua_media.c ..RTP socket reachable at
[2001:2::aab1:dd37:c606:94a2:f50d]:4002*
*15:33:38.975 pjsua_media.c ..RTCP socket reachable at
[2001:2::aab1:dd37:c606:94a2:f50d]:4003*
*15:33:38.975 pjsua_media.c ..Media index 0 selected for audio call 0*
*15:33:38.975 pjsua_core.c ....TX 1378 bytes Request msg
INVITE/cseq=11133 (tdta0x150920000) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
*INVITE sip:103@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0*
*Via: SIP/2.0/TCP
xxxxxx.xxx:42312;rport;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*
*Max-Forwards: 70*
*From: sip:***@xxxxxx.xxx;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*To: sip:***@xxxxxx.xxx;tag=jZ4Be8mcX701c*
*Contact:
<sip:104@[2001:2::aab1:dd37:c606:94a2:f50d]:51419;transport=TCP;ob>*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 11133 INVITE*
*Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS*
*Supported: replaces, 100rel, norefersub*
*User-Agent: SIPXUA-1.0 iOS-10.3.1/arm-iPhone8,4/iOS-SDK*
*Content-Type: application/sdp*
*Content-Length: 668*
*v=0*
*o=- 3701412213 3701412214 IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*
*s=pjmedia*
*b=AS:352*
*t=0 0*
*a=X-nat:0*
*m=audio 4000 RTP/AVP 98 97 0 99 9 96*
*c=IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*
*b=TIAS:64000*
*a=rtcp:4001 IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*
*a=sendrecv*
*a=rtpmap:98 speex/16000*
*a=rtpmap:97 speex/8000*
*a=rtpmap:0 PCMU/8000*
*a=rtpmap:99 speex/32000*
*a=rtpmap:9 G722/8000*
*a=rtpmap:96 telephone-event/8000*
*a=fmtp:96 0-16*
*m=video 4002 RTP/AVP 97*
*c=IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*
*b=TIAS:256000*
*a=rtcp:4003 IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*
*a=sendrecv*
*a=rtpmap:97 H264/90000*
*a=fmtp:97 profile-level-id=42e01e; packetization-mode=1*
*--end msg--*
*15:33:38.979 SIPXUA unMuteCall Called*
*2017-04-17 15:33:38.984284+0530 SIPX[3190:953743] -[UConnect speakerOn]*
*15:33:39.236 pj_nat64.c !.ipv6_mod_on_rx*
*15:33:39.236 pj_nat64.c .Incoming INVITE or 200 OK. If they contain
IPv4 addresses, we need to change to ipv6*
*15:33:39.236 pj_nat64.c .**********Incoming INVITE or 200 with IPv4
address**************
*15:33:39.236 pj_nat64.c .SIP/2.0 100 Trying*
*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*
*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 11133 INVITE*
*User-Agent: Vinci-PBX*
*Content-Length: 0*
*15:33:39.236 pj_nat64.c
.****************************************************************
*15:33:39.236 pj_nat64.c .Scanner syntax error at *
*15:33:39.236 pj_nat64.c .Error: Parsing of the incoming INVITE/200 OK
failed at . Leave incoming buffer as is*
*15:33:39.236 pjsua_core.c .RX 365 bytes Response msg
100/INVITE/cseq=11133 (rdata0x150881330) from TCP
2001:2:0:1baa::4225:2ca6:5060:*
*SIP/2.0 100 Trying*
*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*
*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 11133 INVITE*
*User-Agent: Vinci-PBX*
*Content-Length: 0*
*--end msg--*
*15:33:39.239 pj_nat64.c .ipv6_mod_on_rx*
*15:33:39.239 pj_nat64.c .Incoming INVITE or 200 OK. If they contain
IPv4 addresses, we need to change to ipv6*
*15:33:39.239 pj_nat64.c .**********Incoming INVITE or 200 with IPv4
address**************
*15:33:39.239 pj_nat64.c .SIP/2.0 200 OK*
*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*
*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 11133 INVITE*
*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*
*User-Agent: Vinci-PBX*
*Accept: application/sdp*
*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*
*Supported: timer, path, replaces*
*Session-Expires: 120;refresher=uas*
*Content-Type: application/sdp*
*Content-Disposition: session*
*Content-Length: 358*
*v=0*
*o=FreeSWITCH 1492392842 1492392844 IN IP4 xxxxxx.xxx*
*s=FreeSWITCH*
*c=IN IP4 xxxxxx.xxx*
*t=0 0*
*m=audio 29974 RTP/AVP 0 96*
*a=rtpmap:0 PCMU/8000*
*a=rtpmap:96 telephone-event/8000*
*a=fmtp:96 0-16*
*a=ptime:20*
*a=rtcp:29975 IN IP4 xxxxxx.xxx*
*m=video 17638 RTP/AVP 97*
*a=rtpmap:97 H264/90000*
*a=fmtp:97 profile-level-id=42e01e; packetization-mode=1*
*INFO sip:104@[2001:2::aab1:dd37:c606:94a2:f50d]:51419;transport=TCP;ob
SIP/2.0*
*Via: SIP/2.0/TCP xxxxxx.xxx;branch=z9hG4bKm0H32cN7F1c2p*
*Max-Forwards: 70*
*From: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*
*To: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 105875569 INFO*
*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*
*User-Agent: Vinci-PBX*
*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*
*Supported: timer, path, replaces*
*Content-Type: application/media_control+xml*
*Content-Length: 175*
*<?xml version="1.0" encoding="utf-8" ?>*
*<media_control>*
*<vc_primitive>*
*<to_encoder>*
*<picture_fast_update>*
*</picture_fast_update>*
*</to_encoder>*
*</vc_primitive>*
*</media_control>*
*15:33:39.243 pj_nat64.c
.****************************************************************
*15:33:39.243 pj_nat64.c .Extracted ip4 address as xxxxxx.xxx*
*15:33:39.255 pj_nat64.c .Extracted ip4 address as xxxxxx.xxx*
*15:33:39.258 pj_nat64.c .Extracted ip4 address as xxxxxx.xxx*
*2017-04-17 15:33:39.259449+0530 SIPX[3190:953743] audioSession active*
*15:33:39.277 pj_nat64.c .Scanner syntax error at *
*15:33:39.277 pj_nat64.c .Current Content-Length is: 358 and new
Content-Length is 1211 .*
*15:33:39.277 pj_nat64.c .Updated content length needs more bytes than
old one, we must do expand and copy. TODO*
*15:33:39.278 pj_nat64.c .We have successfully parsed the INVITE/200
OK until EOF. Replace rx buffer. pjsip will now print the modified rx
packet.*
*15:33:39.278 pj_nat64.c .Host in Contact header is xxxxxx.xxx*
*15:33:39.287 pjsua_core.c .RX 1892 bytes Response msg
200/INVITE/cseq=11133 (rdata0x150881330) from TCP
2001:2:0:1baa::4225:2ca6:5060:*
*SIP/2.0 200 OK*
*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*
*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 11133 INVITE*
*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*
*User-Agent: Vinci-PBX*
*Accept: application/sdp*
*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*
*Supported: timer, path, replaces*
*Session-Expires: 120;refresher=uas*
*Content-Type: application/sdp*
*Content-Disposition: session*
*Content-Length: 358*
*v=0*
*o=FreeSWITCH 1492392842 1492392844 IN IP6 2001:2:0:1baa::4225:2ca6*
*s=FreeSWITCH*
*c=IN IP6 2001:2:0:1baa::4225:2ca6*
*t=0 0*
*m=audio 29974 RTP/AVP 0 96*
*a=rtpmap:0 PCMU/8000*
*a=2017-04-17 15:33:39.290674+0530 SIPX[3190:953831] routeChangeReason :
AVAudioSessionRouteChangeReasonCategoryChange*
*2017-04-17 15:33:39.290933+0530 SIPX[3190:953831]
-[MTAnswerCallViewController audiRouteChanged:]*
*rtpmap:96 telephone-event/8000*
*a=fmtp:96 0-16*
*a=ptime:20*
*a=rtcp:29975 IN IP6 2001:2:0:1baa::4225:2ca6*
*m=video 17638 RTP/AVP 97*
*a=rtpmap:97 H264/90000*
*a=fmtp:97 profile-level-id=42e01e; packetization-mode=1*
*INFO sip:104@[2001:2::aab1:dd37:c606:94a2:f50d]:51419;transport=TCP;ob
SIP/2.0*
*Via: SIP/2.0/TCP xxxxxx.xxx;branch=z9hG4bKm0H32cN7F1c2p*
*Max-Forwards: 70*
*From: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*
*To: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*
*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*
*CSeq: 105875569 INFO*
*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*
*User-Agent: Vinci-PBX*
*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*
*Supported: timer, path, replaces*
*Content-Type: application/media_control+xml*
*Content-Length: 175*
*<?xml version="1.0" encoding="utf-8" ?>*
*<media_control>*
*<vc_primitive>*
*<to_encoder>*
*<picture_fast_update>*
*</picture_fast_update>*
*</to_encoder>*
*</vc_primitive>*
*</media_control>*
*--end msg--*
*15:33:39.301 sdp.c ....Error parsing SDP in line 15 col 0:
Success*
*Assertion failed: (ctx.last_error != PJ_SUCCESS), function
pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.*
Thanks.
On Wed, Apr 12, 2017 at 5:53 PM, Ashok Narvaneni <***@gmail.com>
wrote:
> Thank you guys for your quick response,
>
> Every thing is working fine with Audio call in IPV6.
> But when i switch audio call to video call it's crashing in IPV6.
>
> Thanks,
> Ashok Narvaneni.
>
> On Thu, Apr 6, 2017 at 7:53 PM, Ashok Narvaneni <***@gmail.com
> > wrote:
>
>> Thanks for the reply Colin.
>>
>> We tried the modification in FS. It's worked fine.
>>
>> Thanks,
>> Ashok Narvaneni.
>>
>> On Wed, Apr 5, 2017 at 6:47 PM, Colin Morelli <***@gmail.com>
>> wrote:
>>
>>> Can't help a whole lot here since I'm not using registrations at all.
>>>
>>> Couple of options off the top of my head:
>>> - If enabling STUN in the PJSIP client is a possibility, I believe
>>> PJSIP can resolve its actual address using STUN before constructing a
>>> contact header and registering. This would not require you to change the
>>> Freeswitch instances at all, but it would require you to have some kind of
>>> STUN server you can use (for testing you can probably just hit Google's
>>> public STUN servers but I have no idea if this is frowned upon by them or
>>> not).
>>>
>>> - Alternatively, I believe there is a setting you can configure in
>>> Freeswitch to ignore the contact header and always use the actual remote
>>> address of the registration request. This would be a better question for
>>> the Freeswitch mailing list, but probably if you look through their guides
>>> on NAT you'll find something here. (Effectively, this is the same thing as
>>> a client device trying to register with a private IPv4 address - either way
>>> the contact header can't be trusted and the FS instance should use actual
>>> available network information)
>>>
>>> Best,
>>> Colin
>>>
>>> On Wed, Apr 5, 2017 at 8:49 AM, JOHAN LANTZ <***@telefonica.com>
>>> wrote:
>>>
>>>> For this problem I really do not know. I think our system does not pay
>>>> that much attention to the Contact header but simply connects the
>>>> registered device with the TCP/TLS socket used.
>>>>
>>>> I doubt there is anything missing on the client side if you simply does
>>>> not receive the INVITE. Are other packets reaching the device? MESSAGE,
>>>> keep-alive, etc?
>>>>
>>>> Johan
>>>>
>>>> From: pjsip on behalf of Ashok Narvaneni
>>>> Reply-To: pjsip list
>>>> Date: Wednesday, 5 April 2017 at 14:40
>>>>
>>>> To: pjsip list
>>>> Subject: Re: [pjsip] NAT64 ios issue
>>>>
>>>> Thank you very much Colin and Johan for your help.
>>>>
>>>> We have made some good progress. Below is the current status.
>>>> IPV4 - Phone register successfully, both Incoming and outgoing calls
>>>> are working fine.
>>>> IPV6 - Phone register successfully, outgoing calls are working fine but
>>>> when some one dial the extension of the phone under IPV6, FreeSwitch server
>>>> doesn't send the INVITE to the phone .
>>>>
>>>> Below is the register packet received on the server. Is there any other
>>>> change we need to make on the app or Is that a FreeSwitch issue. Contact
>>>> header have IPV6 address.
>>>>
>>>> REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
>>>> Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3
>>>> c1b]:63025;rport;branch=z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
>>>> Max-Forwards: 70
>>>> From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
>>>> To: <sip:***@xxxxxx.xxx>
>>>> Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
>>>> CSeq: 57007 REGISTER
>>>> User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
>>>> Supported: outbound, path
>>>> Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;transport=
>>>> TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000
>>>> -0000-0000fea119f6>"
>>>> Expires: 60
>>>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE,
>>>> NOTIFY, REFER, MESSAGE, OPTIONS
>>>> Content-Length: 0
>>>>
>>>> Thanks,
>>>> Ashok Narvaneni.
>>>>
>>>> On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com
>>>> > wrote:
>>>>
>>>>> Hi Ashok
>>>>>
>>>>> Glad the module is more or less doing the job for you. As you can see
>>>>> in the README.md file on GitHub under bullet 2, there is an example on how
>>>>> you can activate this only when connecting to a IPv6 network. Then IPv4
>>>>> continues to work as it has always done. Just hook it into the
>>>>> on_registration callback from pjsip and I think you will be fine.
>>>>>
>>>>> Johan
>>>>>
>>>>> From: pjsip on behalf of Ashok Narvaneni
>>>>> Reply-To: pjsip list
>>>>> Date: Tuesday, 4 April 2017 at 16:36
>>>>> To: pjsip list
>>>>> Subject: Re: [pjsip] NAT64 ios issue
>>>>>
>>>>> Hi Colin,
>>>>>
>>>>> Thanks again for your kind reply.
>>>>> We will make the changes and post our findings.
>>>>> Unfortunately this server is provided by our client which does't have
>>>>> ICE support.
>>>>>
>>>>> Thanks,
>>>>> Ashok Narvaneni.
>>>>>
>>>>> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Ahsok,
>>>>>>
>>>>>> This is one of the reasons I had written my own module (well, that
>>>>>> and supporting ICE). The module I linked does not perform any checks about
>>>>>> the current connection to the SIP server. Among other things, one of the
>>>>>> additional things my modules does is only operate when connected to the
>>>>>> signaling server via IPv6. This can be accomplished by a simple check in
>>>>>> the on_rx and on_tx methods, before touching the SDP:
>>>>>>
>>>>>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>>>>>> == PJSIP_TRANSPORT_IPV6
>>>>>>
>>>>>> With that check at the beginning of the module methods, it should
>>>>>> simply ignore anything that happens on an IPv4 transport and leave the SDP
>>>>>> in-tact.
>>>>>>
>>>>>> As for PJSIP supporting dual stack mode - there's really no sense in
>>>>>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>>>>>> does support dual stack. If you can enable ICE on your server side as well,
>>>>>> that should work for your use case.
>>>>>>
>>>>>> Best,
>>>>>> Colin
>>>>>>
>>>>>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>>>>>> ***@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Colin,
>>>>>>>
>>>>>>> We integrated the module as you suggested and it is working fine.
>>>>>>> However it breaks when we connect the device with an IPV4 network.
>>>>>>> We understand that pjsip does't support dual stack mode. So what is the
>>>>>>> best way to do make the App work with both IPV6 and IPV4 networks.
>>>>>>> Please suggest...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ashok Narvaneni.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>>>>>> ***@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Colin,
>>>>>>>>
>>>>>>>> Thank you very much for detailed answer, I will try that patch and
>>>>>>>> post my findings.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ashok.
>>>>>>>>
>>>>>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <
>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Ashok,
>>>>>>>>>
>>>>>>>>> What's almost certainly happening here is that the SDP returned
>>>>>>>>> from your server contains only IPv4 media addresses. When PJSIP goes to
>>>>>>>>> compare the SDP to local capabilities, it finds only IPv4 addresses for the
>>>>>>>>> remote endpoint, but can't find any local IPv4 interfaces. As a result, it
>>>>>>>>> thinks there's no way it can communicate with the remote server and fails.
>>>>>>>>>
>>>>>>>>> I have been able to fix this with two steps:
>>>>>>>>>
>>>>>>>>> 1) Enable ICE negotiation on both your media server and PJSIP
>>>>>>>>> client. ICE is helpful here because it allows the two endpoints to
>>>>>>>>> communicate multiple candidate media addresses. This step *may* be
>>>>>>>>> optional, although I've never really tested without this.
>>>>>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>>>>>> work around the NAT64 issue. There's an example of one of these
>>>>>>>>> on github <https://github.com/johanlantz/pj-nat64>, and I've
>>>>>>>>> written my own for my app (unfortunately can't share at this time). The
>>>>>>>>> general steps that need to be followed here are:
>>>>>>>>>
>>>>>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>>>>>> - When sending an outgoing SDP, if signaling is connected over
>>>>>>>>> IPv6, then add an IPv4 address to the ICE candidates in the SDP (this step
>>>>>>>>> is optional, and depends on whether or not your server will explicitly
>>>>>>>>> reject an SDP that only contains IPv6 addresses)
>>>>>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>>>>>> candidates list
>>>>>>>>>
>>>>>>>>> As long as this module is registered with a higher priority than
>>>>>>>>> the PJSIP transports module, the SDP will be rewritten before pjmedia
>>>>>>>>> actually parses the SDP. By the time it gets to the media stack, it will
>>>>>>>>> see your synthesized IPv6 addresses, which it can support, and should be
>>>>>>>>> able to establish a media connection.
>>>>>>>>>
>>>>>>>>> Couple of tips here: don't underestimate the nuances of this
>>>>>>>>> issue. It's not necessarily a *hard *problem, but there are a lot
>>>>>>>>> of cases to consider. Once you solve the first issue, you then have the
>>>>>>>>> issue of what happens when the user changes networks during a call (i.e.
>>>>>>>>> their phone switches wifi networks, or off of wifi entirely). Additionally,
>>>>>>>>> if you're working on Android, you probably have this issue on Android as
>>>>>>>>> well, but Google as far as I know does not test apps on a NAT64 network
>>>>>>>>> like Apple does.
>>>>>>>>>
>>>>>>>>> Apologies I can't be more specific at this time but I hope this
>>>>>>>>> points you in the right direction. I think it'd be great for PJSIP to
>>>>>>>>> include this in the core. NAT64 networks are likely to become more
>>>>>>>>> prevalent, and it would be considerably less work to simply add to the core
>>>>>>>>> than it would be to maintain a separate module.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Colin
>>>>>>>>>
>>>>>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We are trying to connect to IPV4 server from our pjsip ios app
>>>>>>>>>> with NAT64.
>>>>>>>>>> We can able to register with the server successfully But when we
>>>>>>>>>> make calls their is no audio and call disconnects.
>>>>>>>>>> Below is the error.
>>>>>>>>>>
>>>>>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.256 pjsua_media.c
>>>>>>>>>> ......pjmedia_stream_info_from_sdp() failed for call_id 1 media 0:
>>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media
>>>>>>>>>> call01:0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_media.c
>>>>>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media
>>>>>>>>>> call01:1: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media
>>>>>>>>>> session: No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>>>>>> [status=220048]*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>>>>>
>>>>>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Ashok Narvaneni.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>>>
>>>>>>>>>> pjsip mailing list
>>>>>>>>>> ***@lists.pjsip.org
>>>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>>
>>>>>>>>> pjsip mailing list
>>>>>>>>> ***@lists.pjsip.org
>>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>
>>>>>>> pjsip mailing list
>>>>>>> ***@lists.pjsip.org
>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>
>>>>>> pjsip mailing list
>>>>>> ***@lists.pjsip.org
>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Visit our blog: http://blog.pjsip.org
>>>>>
>>>>> pjsip mailing list
>>>>> ***@lists.pjsip.org
>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>