Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

integration issues #1

Open
jgathm opened this issue Jun 19, 2016 · 15 comments
Open

integration issues #1

jgathm opened this issue Jun 19, 2016 · 15 comments

Comments

@jgathm
Copy link

jgathm commented Jun 19, 2016

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
Copy link
Author

jgathm commented Jun 19, 2016 •
edited
Loading

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
Copy link
Author

jgathm commented Jun 19, 2016

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

@johanlantz
Copy link
Owner

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
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHHbFx_nLGgyYivmxEyljHBJrZDtjwhLks5qNShygaJpZM4I5IDh
.

@jgathm
Copy link
Author

jgathm commented Jun 19, 2016

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.

@johanlantz
Copy link
Owner

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
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHHbFx7oJyoeCykeEMS75WIMRi3rHCKGks5qNbTxgaJpZM4I5IDh
.

@jgathm
Copy link
Author

jgathm commented Jun 30, 2016

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.

@johanlantz
Copy link
Owner

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
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AHHbFxr6iIRpyw79nQjsc8XGu2h0tITyks5qQ3FRgaJpZM4I5IDh
.

@johanlantz
Copy link
Owner

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.

@shwetadodiya
Copy link

shwetadodiya commented Sep 10, 2018 •
edited
Loading

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

@johanlantz
Copy link
Owner

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.

@ferreol
Copy link

ferreol commented Sep 11, 2018

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

@shwetadodiya
Copy link

shwetadodiya commented Sep 11, 2018 via email

@johanlantz
Copy link
Owner

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.

@shwetadodiya
Copy link

shwetadodiya commented Sep 12, 2018 via email

@shwetadodiya
Copy link

shwetadodiya commented Sep 12, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@shwetadodiya @ferreol @johanlantz @jgathm