PBXes » Search » Search Results
Showing posts 1 to 16 of 16 results
Author Post
Thread: Google Voice as SIP Provider
joi

Replies: 99
Views: 30271

RE: Google Voice as SIP Provider 24.08.2018 14:49 Forum: News

Hi!

I had failed call on 2018-08-24 at 14:44:12 through www1 meanwhile al incoming calls pass well.

Cheers.

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

RE: Vpn 16.05.2018 12:58 Forum: Feature Requests

Now everything has almost done look at netstat

Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 33 0 en6
default 192.168.0.1 UGScI 2 0 en0
default link#19 UCSI 3 0 ppp0
a.resolvers.level3 link#19 UHWIi 9 40 ppp0
5.9.79.175/32 ppp0 USc 0 0 ppp0
10.84.233.1 10.84.233.2 UH 1 0 ppp0
17.173.254.222 link#19 UHW3I 0 4 ppp0 8
17.173.254.223 link#19 UHWIi 1 2 ppp0
67.231.240.210/32 ppp0 USc 0 0 ppp0
107.155.198.131/32 ppp0 USc 0 0 ppp0
127 localhost UCS 0 0 lo0
localhost localhost UH 5 1993877 lo0
www1.pbxes.com 192.168.0.1 UGHS 0 0 en6

there're routs to www2, www3, www4 to the right interface but still present wrong route to www1 and pbxes.org 144.76.38.78/32

www1.pbxes.com 192.168.0.1 UGHS 0 0 en6

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

RE: Vpn 05.05.2018 13:43 Forum: Feature Requests

So, I've tried everything. Packets to www1.pbxes.com go through the public instead of VPN, packets to www2.pbxes.com go through VPN though. All the other traffic go through default gateway. Here you are netstat -r, it's easy to see a misconfiguration in the routing:

Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 26 0 en0
default link#19 UCSI 3 0 ppp0
a.resolvers.level3 link#19 UHWIi 3 48 ppp0
5.9.79.175/32 ppp0 USc 0 0 ppp0
10.0.0.156 link#19 UHW3I 0 2 ppp0 9
10.84.233.1 10.84.233.2 UH 1 0 ppp0
10.255.255.255 link#19 UHW3I 0 66 ppp0 6
67.231.240.210/32 ppp0 USc 0 0 ppp0
107.155.198.131/32 ppp0 USc 0 5 ppp0
127 localhost UCS 0 0 lo0
localhost localhost UH 5 1642626 lo0
www1.pbxes.com 192.168.0.1 UGHS 4 4829 en0

I guess you have to add routes to all your networks as you did for 107.155.198.131/32 and delete the route to www1.pbxes.com.

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

RE: Vpn 20.10.2016 13:58 Forum: Feature Requests

You know, as of now a traffic to the PBX goes through default interface but all other routs to the VPN smile It should be on the contrary. Such behaviour take place at Mac OS.

By the other hand on iPhone all traffic (IP and SIP) ignore a VPN connection and pass through usual interface meanwhile VPN is active.

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

RE: Vpn 19.10.2016 11:07 Forum: Feature Requests

So, at the moment a VPN connection establishes as expected but I get a wrong route, below is a record from my Netstat table:

www1.pbxes.com 192.168.0.1 UGHS 1 0 en3

this route should be pointed out to a VPN address.

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

RE: Vpn 17.10.2016 23:29 Forum: Feature Requests

The last time I've tried was 23:19 on 17.10.16, I used user pw: pbxes and PSK: pbxes, without success.

I know that L2TP VPN server can give the routs for using of VPN connection, for the other destinations, if the option "send all traffic over VPN connection" is off, it uses an internal routing tab, it means a regular internet connection.

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

RE: Vpn 17.10.2016 13:43 Forum: Feature Requests

I couldn't connect. Is it L2TP? The password and shared secret are the same - pbxes? Is there Group Name?

If you give through VPN only couple routs for UDP and TCP users will obtain possibility to use VPN for voice and internet access through their own connection.

Thread: RE: PBX is loosing TCP connection
joi

Replies: 4
Views: 8351

RE: PBX is loosing TCP connection 03.10.2016 18:10 Forum: Bugs

It was a buggy router actually, I've replace it and everything become better. I really appreciate your service, thank you once again.

UPD: I found out that many public wi-fi networks have the same issue with NAT-configuraton, how do you think is there any way to quickly debug such issue without control of a router?

Thread: RE: PBX is loosing TCP connection
joi

Replies: 4
Views: 8351

RE: PBX is loosing TCP connection 02.10.2016 23:26 Forum: Bugs

It seems to be you're absolutely right, after review the configuration of modem that provides by my ISP I've managed to find out the problem.

Thanks a lot, it turns to be the cell network is a really good debug tool.

UPD: You know today the issue is appeared again, I absolutely have no idea about it,

Thread: RE: PBX is loosing TCP connection
joi

Replies: 4
Views: 8351

PBX is loosing TCP connection 02.10.2016 17:17 Forum: Bugs

Hi!

I've got some SIP extensions that is working with SIP clients of iPhones. I've tried Bria for iPhone and Groundwire with the same negative result.

I'm using TCP protocol and background mode for the both application in that they listen to incoming TCP traffic and wake-up the app in case of incoming call is detected.

Generally such configuration works but after 6-8 minutes since the registration the both apps stop seeing any incoming call and TCP activity. Vendors of apps can't debag an issue cause it simply nothing happening during the issue, there're no any logs also.

As the behaviours of two different apps exactly the same I guess that the issue on the PBX side. I can make the log or simulate the issue at any time, just let me know.

Thanks.

Thread: RE: Vpn
joi

Replies: 13
Views: 15186

Vpn 14.09.2016 22:32 Forum: Feature Requests

As you may be know Apple in their new OS X and iOS drops support of VPN PPTP so it'll be hard to use VPN service in the nearest feature. Is it possible to add support of L2TP for example?

Thread: RE: Traceroute & ping tool
joi

Replies: 2
Views: 6270

RE: Traceroute & ping tool 14.09.2016 22:28 Forum: Feature Requests

Amazing! Thank you!

This information have to be added to the help!

Thread: RE: Traceroute & ping tool
joi

Replies: 2
Views: 6270

Traceroute & ping tool 10.09.2016 14:46 Forum: Feature Requests

It'd be great to have a traceroute and ping tool from each of the servers for diagnose network issues with trunk providers. It'd possible through VPN service but unfortunately this way is closed.

Thread: RE: TCP transport problem
joi

Replies: 3
Views: 7521

RE: TCP transport problem 07.01.2016 14:38 Forum: Bugs

Thank you for the fix. Now it looks like everything woks well.

Thread: RE: TCP transport problem
joi

Replies: 3
Views: 7521

TCP transport problem 11.12.2015 15:10 Forum: Bugs

Zitat:
Hi there,

I use the Bria for iPhone as SIP-clent via TCP-transport. Everything had been fine until the new version was pushed out. They’ve changed format of header, but it still correspond to the standards though as they affirm.

Here it is the header from log of the older version, it works fine:
Contact: <sip:xxxxxx-1082@192.168.0.10:62799;transport=tcp>;
+sip.instance=« <urn:uuid:22caa650900012da01636af0bba72626ba28359b>";reg-id=1

Here it is the new one and a warning after:
Contact: <sip:xxxxxx-1082@192.168.0.10:62370;
rinstance=c82b652c896f558e;transport=tcp>

NOTICE[127241] chan_sip.c: ‘<sip:xxxxxx-1082@192.168.0.10:62370;
rinstance=c82b652c896f558e;transport=tc' is not a valid SIP contact (missing sip: ) trying to use anyway

Below is the statement from vendor of Bria:
"It seems that your PBX has a problem with the contact header that Bria is sending internally somehow. It does receive the request successfully, and the Contact: header is well formed on reception and initial parsing. However, it has internally truncated the end off of this header.

This header is well formed as sent by Bria and initially parsed by your PBX, so something in your PBX is likely truncating this incorrectly. The logging level doesn't show how/why it's done this, but I suspect it might be related to the length of the first information in the angle brackets. There is a difference in the contact header Bria sends in the two versions. Both are well formed, but are different implementations.

I suspect there’s something you should be able to change with your PBX implementation which will prevent it from performing the truncation and this should solve the issue you’re having."

As a result Bria can’t receive any incoming call using TCP transport. Could you investigate it?



Is it possible to obtain an any answer for my report?! I don’t insist on supporting of me but I expect for some attention to the problem by this way this service will be more predictable, isn’t it?

Thread: Soft-phone Telephone.app for Mac 488 Not acceptable here error
joi

Replies: 0
Views: 12984

Soft-phone Telephone.app for Mac 488 Not acceptable here error 20.02.2015 18:46 Forum: Terminal Equipment

Hi there!

Some months ago I’ve had a trouble with Telephone app 1.1.4 it stopped calling with an error « 488 Not acceptable here ».

I doesn’t do anything at all, it just stopped calling. In the mean time the Bria 4 doesn’t have a such problem and works as expected with the same settings.

So I’ve tried to reinstall the Telephone app, I’ve used the only G.711 setting, no result ….

My be some one knows what else can I do with it?

With best wishes.

Update: Suddenly I’ve found workaround for this problem - I start using an alternative port 5061 and everything became ok. I’ve just found such string in the logs:

pjsua_acc.c !..Unable to create/send REGISTER: Object is busy (PJSIP_EBUSY)

I can’t find the process yet which locks the default port 5060, but may be this information will be helpful for someone.

Showing posts 1 to 16 of 16 results

Powered by Burning Board Lite 1.0.2 © 2001-2004 WoltLab GmbH
English Translation by Satelk