pj-nat64 icon indicating copy to clipboard operation
pj-nat64 copied to clipboard

Published 20 hours ago • verified publisher icon johanlantz

integration issues

Open jgathm opened this issue 8 years ago • 15 comments

Hi

Many thanks for your code I'm trying to integrate !

I'm facing a first issue. I will go deeper by myself but here it is:

When receiving an incoming call replace_sdp_ipv4_with_ipv6 is called,

-ipv4 addresses are correctly parsed detected -IP4 gets replaced by IP6 but the ipv4 addresses are not replaced, ie I have in the modified message:

o=FreeSWITCH 1466244684 1466244685 IN IP6 192.168.1.124

s=FreeSWITCH

c=IN IP6 192.168.1.124

t=0 0

jgathm avatar Jun 19 '16 09:06 jgathm

I got this problem fixed by using a 9.3.2 iOS device. I believe this is because of a behavior required > 9.2

The ability to synthesize IPv6 addresses was added to getaddrinfo in iOS 9.2 and OS X 10.11.2. However, leveraging it does not break compatibility with older system versions. See getaddrinfo(3) Mac OS X Developer Tools Manual Page.

https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html

jgathm avatar Jun 19 '16 11:06 jgathm

some more feedback:

  1. incoming call works, hears audio.
  2. pjsip hangup sends BYE message that does not seem to be treated by the server.
  3. outgoing call does not work, IP6 SDP header get replaced by "IP4 192.168.1.1." I'm using pj_nat64_set_active_account

jgathm avatar Jun 19 '16 11:06 jgathm

Hi

The BYE message is coming after 32 sec? In that case there is a header like Route that is not being replaced correctly. Check the code there are some scenarios which might exist in your server and not in ours. If the call ends after 32 sec it's because the ACK failed since it creates a new transaction and that transaction tried to use an IP4 address.

For our server this works fine but I think I have a comment in the code that I have not tested all possible headers that may contain ip4 addresses.

  1. Our server supports latching that is why 193.169.1.1 works. I had no environment to test replacing the ip with he info from the via header so I just implemented it without testing. However just to know, did you set the rewrite sdp flag to true for this account. Otherwise it would never work even if you set the account in my code. You must first tell pjsip to activate sdp via rewriting.

Johan

On Sunday, 19 June 2016, jgathm [email protected] wrote:

some more feedback:

  1. incoming call works, hears audio.
  2. pjsip hangup sends BYE message that does not seem to be treated by the server.
  3. outgoing call does not work, IP6 SDP header get replaced by "IP4 192.168.1.1." I'm using pj_nat64_set_active_account

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/johanlantz/pj-nat64/issues/1#issuecomment-226992411, or mute the thread https://github.com/notifications/unsubscribe/AHHbFx_nLGgyYivmxEyljHBJrZDtjwhLks5qNShygaJpZM4I5IDh .

johanlantz avatar Jun 19 '16 18:06 johanlantz

Hi

  1. I hang up with pjsip after a few seconds, before the 32 seconds. I have BYE sent and OK server answer. Will also look in server what's going on.

  2. I activated SDP rewriting in pjsip account config, and I now have in the SDP the IP4 of the local IPv4 network of my mac, the one that has created the NAT64. Not working yet, but since it's now a double NAT before reaching my SIP server on the Internet, I'll dig into generic NAT issue.

jgathm avatar Jun 19 '16 21:06 jgathm

Hi

  1. Ok, if you receive the 200 OK for your BYE it should in theory be ok.
  2. I never had a chance to test this case. I just added the sdp rewrite option in case anyone wanted to try so please keep me updated if you can make it work. Otherwise I recommend that you check if your server can support latching or port switching. This is how our server works, once it detects incoming audio it sends the outgoing to the same connection. That is why 192.168.1.1 works, it just needs to be an address the server can not resolve for it to fall back to latching the media.

Our app is working with these changes and it has passed AppStore review in the last couple of days.

BR

Johan

2016-06-19 23:30 GMT+02:00 jgathm [email protected]:

Hi

  1. I hang up with pjsip after a few seconds, before the 32 seconds. I have BYE sent and OK server answer. Will also look in server what's going on.

  2. I activated SDP rewriting in pjsip account config, and I now have in the SDP the IP4 of the local IPv4 network of my mac, the one that has created the NAT64. Not working yet, but since it's now a double NAT before reaching my SIP server on the Internet, I'll dig into generic NAT issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johanlantz/pj-nat64/issues/1#issuecomment-227021447, or mute the thread https://github.com/notifications/unsubscribe/AHHbFx7oJyoeCykeEMS75WIMRi3rHCKGks5qNbTxgaJpZM4I5IDh .

johanlantz avatar Jun 20 '16 14:06 johanlantz

Hi -Are you using TCP or UDP transport ? -are you still using the proxy workaround ?

Otherwise some feedback: I have checked and latching is already active on servers. BYE is received by server (network capture) yet the servers does not ACKnowledge it by SIP message.

jgathm avatar Jun 30 '16 07:06 jgathm

Hi

We use TCP transport only.

So latching is active and you still have not incoming media? That is strange because that works for us.

I will retry the BYE but as far as I remember it was working ok. Maybe your server looks at the route or contact header for information on where to send the response and something is still missing an update. In our case it seems the server ignores the info in Contact etc and just relies on the TCP connection where the signalling is done.

Johan

2016-06-30 9:33 GMT+02:00 jgathm [email protected]:

Hi -Are you using TCP or UDP transport ? -are you still using the proxy workaround ?

Otherwise some feedback: I have checked and latching is already active on servers. BYE is received by server (network capture) yet the servers does not ACKnowledge it by SIP message.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johanlantz/pj-nat64/issues/1#issuecomment-229582215, or mute the thread https://github.com/notifications/unsubscribe/AHHbFxr6iIRpyw79nQjsc8XGu2h0tITyks5qQ3FRgaJpZM4I5IDh .

johanlantz avatar Jun 30 '16 11:06 johanlantz

There has been another company working on rewriting the Route-Record headers as well. It was required for them to make it work with a vanilla Freeswitch. Since I do not have them in our setup it was enough to just do Contact header manipulations.

Hopefully they will share their code when it is polished.

johanlantz avatar Aug 22 '16 14:08 johanlantz

I am also facing issue in the integration. Exact issue I am facing in my code is : No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

I am trying to follow this step.But I don't understand how should I add file in the make file that is step4. Please help. I am new to objective C and pjsip

https://stackoverflow.com/questions/43915256/pjsip-registration-to-ipv4-server-from-nat64-network-in-ios

shwetadodiya avatar Sep 10 '18 17:09 shwetadodiya

I have not been working with pjsip for over a year so I am no longer actively supporting this project. I was hoping this would be working out of the box by now.

We deployed commercial products using it on android and iOS and many other companies have done so as well. That said, this is quite a complex scenario so depending on the infrastructure you are using you might have to make some custom changes as well and then you need to know C rather well. As for the make file etc I suggest you read up on how that works because it heavily depends on how your project is setup. This code is then a drop in pjsip module so you do not have to modify any pjsip code.

johanlantz avatar Sep 11 '18 11:09 johanlantz

Actually, pjsip supports Nat64 natively right now ( also with long awaited ip change handler )

ferreol avatar Sep 11 '18 20:09 ferreol

so you mean we dont have to include this files externally for NAT64support?

Sent from my iPhone

On 11-Sep-2018, at 2:07 PM, ferreol [email protected] wrote:

Actually, pjsip supports Nat64 natively right now ( also with long awaited ip change handler )

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

shwetadodiya avatar Sep 11 '18 20:09 shwetadodiya

I would investigate the current state of pjsip before using this solution. It was developed a long time before there was a commitment to NAT64 from pjsip. It does work and it might be applicable for some cases but it requires pretty good knowledge of the inner workings of both pjsip and SIP in general.

johanlantz avatar Sep 12 '18 07:09 johanlantz

Okay.

Thank you very much. I am using pjsip2.8 and prevously using 2.7. I tried to use NAT64 class in both the library it didnt work and give me error. I request please help me and if you can check in latest library also. Thank you very much

Sent from my iPhone

On 12-Sep-2018, at 1:56 AM, johanlantz [email protected] wrote:

I would investigate the current state of pjsip before using this solution. It was developed a long time before there was a commitment to NAT64 from pjsip. It does work and it might be applicable for some cases but it requires pretty good knowledge of the inner workings of both pjsip and SIP in general.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

shwetadodiya avatar Sep 12 '18 15:09 shwetadodiya

Hi,

This is the Exact issue :

09:29:42.686 sip_endpoint.c .Module "mod-ua" registered

09:29:42.686 sip_endpoint.c .Modul

2018-09-12 09:29:42.758653-0600 ABCCompany[334:14959] -[DalErrorLog writeLogToBuffer]_block_invoke@99 -info- e "mod-100rel" registered

09:29:42.686 sip_endpoint.c .Module "mod-pjsua" registered

09:29:42.686 sip_endpoint.c .Module "mod-invite" registered

09:29:42.686 pjsua_core.c .Trying STUN server test2.ABCCompany.ca http://test2.ABCCompany.ca IPv4 (1 of 1)..

09:29:42.687 resolver.c .Transmitting 47 bytes to NS 0 (8.8.8.8:53 http://8.8.8.8:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.687 resolver.c .Transmitting 47 bytes to NS 1 (8.8.4.4:53 http://8.8.4.4:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.687 resolver.c .Transmitting 47 bytes to NS 2 (208.67.222.222:53 http://208.67.222.222:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.687 resolver.c .Transmitting 47 bytes to NS 3 (208.67.220.220:53 http://208.67.220.220:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.687 stunresolve .Failed in pj_dns_srv_resolve(): No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

09:29:42.687

2018-09-12 09:29:42.763035-0600 ABCCompany[334:14959] -[DalErrorLog writeLogToBuffer]_block_invoke@99 -info- pjsua_core.c .Error starting STUN socket for test2.ABCCompany.ca http://test2.ABCCompany.ca: No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

09:29:42.687 pjsua_core.c .STUN resolution failed: No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

09:29:42.687 pjsua_core.c .Ignoring STUN resolution failure (by setting)

09:29:42.724 coreaudio_dev.c .. dev_id 0: iPhone IO device (in=1, out=1) 8000Hz

09:29:42.724 coreaudio_dev.c ..core audio initialized

09:29:42.724 pjlib ..select() I/O Queue created (0x103901228)

09:29:42.730 sip_endpoint.c .Module "mod-evsub" registered

09:29:42.730 sip_endpoint.c .Module "mod-presence" registered

09:29:42.730 sip_endpoint.c .Module "mod-mwi" registered

09:29:42.730 sip_endpoint.c .Module "mod-refer" registered

09:29:42.730 sip_endpoint.c .Module "mod-pjsua-pres" registered

09:29:42.730 sip_endpoint.c .Module "mod-pjsua-im" registered

09:29:42.730 sip_endpoint.c .Modul

2018-09-12 09:29:42.767214-0600 ABCCompany[334:14959] -[DalErrorLog writeLogToBuffer]_block_invoke@99 -info- e "mod-pjsua-options" registered

09:29:42.730 pjsua_core.c .1 SIP worker threads created

09:29:42.730 pjsua_core.c .pjsua version 2.8 for iOS-11.4/arm-iPhone7,2/iOS-SDK initialized

09:29:42.730 pjsua_core.c .PJSUA state changed: CREATED --> INIT

09:29:42.731 tcptp:49475 SIP TCP listener ready for incoming connections at 169.254.104.124:49475 http://169.254.104.124:49475

09:29:42.731 pjsua_core.c Trying STUN server test2.ABCCompany.ca http://test2.ABCCompany.ca IPv4 (1 of 1)..

09:29:42.731 resolver.c Transmitting 47 bytes to NS 0 (8.8.8.8:53 http://8.8.8.8:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.731 resolver.c Transmitting 47 bytes to NS 1 (8.8.4.4:53 http://8.8.4.4:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.731 resolver.c Transmitting 47 bytes to NS 2 (208.67.222.222:53 http://208.67.222.222:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.731 resolver.c Transmitting 47 bytes to NS 3 (208.67.22

2018-09-12 09:29:42.771538-0600 ABCCompany[334:14959] -[DalErrorLog writeLogToBuffer]_block_invoke@99 -info- 0.220:53): DNS SRV query for _stun._udp.test2.ABCCompany.ca http://udp.test2.ABCCompany.ca: Network is unreachable

09:29:42.731 stunresolve Failed in pj_dns_srv_resolve(): No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

09:29:42.731 pjsua_core.c Error starting STUN socket for test2.ABCCompany.ca http://test2.ABCCompany.ca: No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

09:29:42.731 pjsua_core.c STUN resolution failed: No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)

09:29:42.731 pjsua_core.c Ignoring STUN resolution failure (by setting)

09:29:42.732 pjsua_core.c SIP UDP socket reachable at 169.254.104.124:63871 http://169.254.104.124:63871

09:29:42.732 udp0x107fb6ef0 SIP UDP transport started, published address is 169.254.104.124:63871 http://169.254.104.124:63871

09:29:42.732 pjsua_core.c PJSUA state changed: INIT --> STARTING

09:29:42.732 sip_endpoint.c .Module "mod-unsolicited-mwi" registered

09:29:42.732 pjsua_core.c .PJSUA state changed: STARTING --> RUNNING

09:29:42.743 pjsua_acc.c Adding ac

2018-09-12 09:29:42.776008-0600 ABCCompany[334:14959] -[DalErrorLog writeLogToBuffer]_block_invoke@99 -info- count: id=sip:[email protected] sip%[email protected]

09:29:42.743 pjsua_acc.c .Account sip:[email protected] sip%[email protected] added with id 0

On Wed, Sep 12, 2018 at 9:32 AM shweta dodiya [email protected] wrote:

Okay.

Thank you very much. I am using pjsip2.8 and prevously using 2.7. I tried to use NAT64 class in both the library it didnt work and give me error. I request please help me and if you can check in latest library also. Thank you very much

Sent from my iPhone

On 12-Sep-2018, at 1:56 AM, johanlantz [email protected] wrote:

I would investigate the current state of pjsip before using this solution. It was developed a long time before there was a commitment to NAT64 from pjsip. It does work and it might be applicable for some cases but it requires pretty good knowledge of the inner workings of both pjsip and SIP in general.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/johanlantz/pj-nat64/issues/1#issuecomment-420550017, or mute the thread https://github.com/notifications/unsubscribe-auth/ABcQD-t7jkvweISH6OVAG2mGwRiFiz8iks5uaL44gaJpZM4I5IDh .

shwetadodiya avatar Sep 12 '18 15:09 shwetadodiya