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.

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

SIP connection through Proxy #32

Open
arnauos opened this issue Dec 16, 2018 · 15 comments
Open

SIP connection through Proxy #32

arnauos opened this issue Dec 16, 2018 · 15 comments

Comments

@arnauos
Copy link

arnauos commented Dec 16, 2018

Hi, my internet service provider requires the user of a Proxy Server (10.31.255.134:5070) in order to connect to the landline SIP account (connection goes through a different vlan than regular internet traffic).

dic 16 15:53:19 FX1 callblockerd[1049]: INFO:   starting callblockerd 0.11.1
dic 16 15:53:19 FX1 callblockerd[1049]: error: XDG_RUNTIME_DIR not set in the environment.
dic 16 15:53:19 FX1 callblockerd[1049]: getaddrinfo: Success
dic 16 15:53:19 FX1 callblockerd[1049]: resolving hostname telefonica.net to IPv4 address failed

Is there a way to make this work with callblocker?

Thanks

@pamapa
Copy link
Owner

pamapa commented Dec 16, 2018

using directly the IP address and not the URL might help

@arnauos
Copy link
Author

arnauos commented Dec 16, 2018

Did some more tests.

Setting the proxy address and port on the domain field returns:

dic 16 20:11:45 FX1 callblockerd[27886]: INFO:   starting callblockerd 0.11.1
dic 16 20:11:45 FX1 callblockerd[27886]: error: XDG_RUNTIME_DIR not set in the environment.
dic 16 20:11:45 FX1 callblockerd[27886]: getaddrinfo: Success
dic 16 20:11:45 FX1 callblockerd[27886]: resolving hostname 10.31.255.134:5070 to IPv4 address failed

Setting only the IP address returns a 408 when registering (timeout?)

dic 16 20:12:24 FX1 callblockerd[28087]: INFO:   starting callblockerd 0.11.1
dic 16 20:12:24 FX1 callblockerd[28087]: error: XDG_RUNTIME_DIR not set in the environment.
dic 16 20:12:56 FX1 callblockerd[28087]: registration on domain '10.31.255.134' with username 'XXXXXXXXX' failed (code=408)

Adding the "@telefonica.net" after the username, returns the following error:

dic 16 20:12:03 FX1 callblockerd[27976]: INFO:   starting callblockerd 0.11.1
dic 16 20:12:04 FX1 callblockerd[27976]: error: XDG_RUNTIME_DIR not set in the environment.
dic 16 20:12:04 FX1 callblockerd[27976]: pjsua_acc_add() failed (Invalid URI (PJSIP_EINVALIDURI))

@pamapa
Copy link
Owner

pamapa commented Dec 17, 2018

hard to say what the problem is!

you can increase the log level with "log_level" to "debug" as described here https://github.com/pamapa/callblocker/tree/master/etc/callblocker to see more. In case of SIP "pjsip_log_level" to "5".

@pamapa
Copy link
Owner

pamapa commented Dec 18, 2018

ok, i looked into the code, for SIP the pjsip library is used and no proxy support used yet.

In "SipAccount SipAccount::add" can you add something additionally like this?
cfg.reg_use_proxy=3;
// cfg.require_100rel=1; // not sure its needed
cfg.proxy_cnt=1;
cfg.proxy[0]=pj_str("sip:;lr"); // outbound_proxy

I have no proxy to try out. Maybe this site helps you:
https://wiki.asterisk.org/wiki/display/AST/PJSIP+with+Proxies

@arnauos
Copy link
Author

arnauos commented Dec 19, 2018

Good news, I have added the lines you said after this one:

cfg.cred_info[0].data = pj_str((char*)m_settings.password.c_str());
Manually specifying the proxy address (as per notation I saw in documentation):

  cfg.reg_use_proxy=3;
  // cfg.require_100rel=1; // not sure its needed
  cfg.proxy_cnt=1;
  cfg.proxy[0]=pj_str("sip:10.31.255.134:5070\;lr"); // outbound_proxy

I also created a hosts entry file for my provider domain (telefonica.net) pointing to the proxy address to bypass the resolve error.

Now callblocker registers succesfully and I can see on the log the incoming calls. I can set them to block but I can't see callblocker hanging up the call.

Will do some more testing tomorrow.

Thanks! :D

@arnauos
Copy link
Author

arnauos commented Dec 20, 2018

Ok, did some more testing.

  • Receiving "registration on domain 'telefonica.net' with username 'XXXXXXXXX' failed (code=408)" on the logs but it does register
  • Calls are being correctly logged by the app
  • Calls are identified when present on the blacklist but they are not always blocked (from 10 test, got one time blocked only)
  • When blocking, call is cut on the caller but the rest of the phones continue ringing (landline phones connected to a CISCO SPA-112 ATA) -> how is the call blocked? if it's with an answer+hangup the rest of the phones should stop ringing...

@pamapa
Copy link
Owner

pamapa commented Dec 22, 2018

The call is actually blocked by a simply answer+hangup.

i think we are getting closer to make it work.
Can you try with un-commenting "cfg.require_100rel=1;"?:

cfg.reg_use_proxy=3;
cfg.require_100rel=1; // this might help
cfg.proxy_cnt=1;
cfg.proxy[0]=pj_str("sip:10.31.255.134:5070\;lr"); // outbound_proxy

@arnauos
Copy link
Author

arnauos commented Dec 23, 2018

I observe the same behaviour with require_100rel added.

Today it seems to be cutting calls successfully, but landline phones still continue ringing. Just guessing, maybe the answer+hangup is too fast for the ATA to acknowledge that the call has been taken elsewhere?

@pamapa
Copy link
Owner

pamapa commented Dec 28, 2018

yes, i was also think about "too fast". Can you try adding a sleep? either after detecting its a spam or just before the hangup.

@pamapa
Copy link
Owner

pamapa commented Jan 2, 2019

also remember in case of analog phones the caller information (CID) is transmitted between the first and second ring. so one ring is always expected for analog phones.

pamapa added a commit that referenced this issue Jan 2, 2019
@arnauos
Copy link
Author

arnauos commented Jan 4, 2019

Yeah, one or two rings does not matter, but call ending is a must.

Will try adding the sleep and do some more testing in few weeks as I'll have some free time.

I'll report back then. Thanks!

@pamapa
Copy link
Owner

pamapa commented Jan 6, 2019

what is also very interesting is what happens in the function "void SipAccount::onCallState(pjsua_call_id call_id, pjsip_event* e)".

what is logged in the cases where the hangup was not done?

  • Logger::debug("[%s] call state changed to %s", number.c_str(), state.c_str());
    Does "Logger::debug("hangup...");" occur?

@pamapa
Copy link
Owner

pamapa commented Sep 7, 2020

what is the state here, does proxy work for you?

@arnauos
Copy link
Author

arnauos commented Sep 7, 2020

Sorry, one thing led to another and in the end, I totally forgot 😱

I will continue the tests in a few days and report back.

@arnauos
Copy link
Author

arnauos commented Sep 24, 2020

Hi, I did a new install and some more testing, I think the issues are down to my sip provider as I can't get consistent results during testing.

I also had a sip client open and overall, the same behaviour was observed.

  • connection through proxy = seems to work after defining the hosts entry for the domain and adding the outbound_proxy in settings ("sip:x.x.x.x:yyyy;lr"), this is mostly due to my providers setup
  • however, I still get some registration failed code=408 messages
  • call blocking works correctly sometimes
  • tried adding sleep before the call block, also changing pjsua_call_hangup to pjsua_call_answer with diferent status codes (486, 600, 603...) with the same results observed, sometimes blocked, sometimes the ATA and the SIP client keep ringing

So, overall, I think the issue might be that sometimes the client can't register (code=408) and call blocking will not work correctly until it succesfully connects.

Not sure on how to fix the code=408 error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants