Still does not work...

[910198]

Dear SipBroker Support Team

I am user of SipBroker/VoXalot for almost 1 year. Since the beginning I regarded the service amazing and everything worked smoothly for incoming as well as outgoing calls.

Do not know why, since the last week of July, the incoming calls from PSTN were dropped after something like 30 seconds. Nothing were done on my network. No changes, absolutely nothing and the incoming calls from PSTN simply stoped to work.

I made a trace and I discovered an interesting clue. The call setup (Invite, 100 Trying, 180 Ringing and 200 OK) was negotiated all the time with the server 64.34.163.35, but, the ACK came from other server, 64.34.162.221. The firewall waited for the ACK from the server 64.34.163.35, but it came from 64.34.162.221 and then it was blocked. The type of NAT is "Restricted Cone NAT".

I even made a workaround applying a static port forwarding on the router, but this "solution" was not good because the lack of mobility. It is not possible to make a static port forwarding on every network that I use. Most of the home networks use modem/routers with "Restricted Cone NAT". I have friends (users of SipBroker) with the same problem.

I kindly beg to someone at SipBroker to analyze this case and give me an answer about what is wrong. I completely willing to provide more information as necessary.

Thanks in advance. Best regards,

André Silveira

[wondermanila]

Originally Posted by 910198

The call setup (Invite, 100 Trying, 180 Ringing and 200 OK) was negotiated all the time with the server 64.34.163.35, but, the ACK came from other server, 64.34.162.221. The firewall waited for the ACK from the server 64.34.163.35, but it came from 64.34.162.221 and then it was blocked. The type of NAT is "Restricted Cone NAT".

Hi, André Silveira
Are you an vox premium user? What is "Invite, 100 Trying, 180 Ringing and 200 OK"

Are you using an ATA?

[martin]

Which access number are you using. The contact IP address is:

200.152.246.50

Which is not one of ours!

The user agent is also:

EasyPABX

Again not ours!
.

[martin]

A couple of other things to note:

1. The ACK message originates from an end point and *not* the proxy. In this case the end point is SIP Broker. The following diagram is from the SIP RFC and should help you visualise:

       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

The ACK is sent to the CONTACT defined by the other user agent. In your case, SJ Phone. If you have a look at the 200 OK message just before the ACK you will see that your SJ Phone is sending:

    Status-Line: SIP/2.0 200 OK
        Status-Code: 200
        Resent Packet: False
    Message Header
        Via: SIP/2.0/UDP 64.34.163.35;branch=z9hG4bK1e37.1b2efd56.0,SIP/2.0/UDP 64.34.162.221;branch=z9hG4bK1e37.32435635.0,SIP/2.0/UDP 200.152.246.50:5060;rport=5060;branch=z9hG4bK29ec4ad4
        Content-Length: 218
        Contact: <sip:910198@201.13.48.4:5060>

I'm guessing you are behind a firewall. If so, then I suspect your problem is with SJ Phone STUN handling. There are a few other posts in the forum with people having similar ACK problems using SJ Phone.
.

[910198]

Dear Martin,

Thank you for your answer. I would like to make some comments in order to gather more information to solve this problem:

1- As you requested, the access numbers that I have tried are +55-11-3511-5700, +55-21-3521-2840 (VoIP Sharing in Brazil) and +34-91-771-1720 (Adam Telefonia IP in Spain).

2- I do not believe in a problem with SJPhone, because the problem is exactly the same with SJPhone, X-Lite and with my ATA.

3- I use the STUN server of VoXalot (stun.voxalot.com). I do not believe in a problem with STUN because the audio stream is established normally for some seconds (30 seconds), but is torn down because the ACK timeout.

4- Yes, there is a Stateful Inspection Firewall on the router, but I do not believe in a problem on the firewall, because the phone rings normally. It means that the firewall permits the SIP messages to be passed from Internet to the UA on the internal network. As I stated before, the problem seems to be on the fact that the firewall waits the ACK from the same IP address of the other messages, but it comes from a different IP address. As I said previously, everything always worked fine, and, without any change, the incoming calls from PSTN stopped to work.

5- I agree with you about what the RFC 3261 says, but if you briefly take a look on the file that I have sent, you will see the diagram below. This is scenario of the problem. Pay special attention on the ACK message.

200.152.246.50   64.34.162.221   64.34.163.35      201.13.48.4
PSTN Provider    sipbroker.com   voxalot.com		
      |                |                |                |
      |    INVITE F1   |                |                |
      |--------------->|    INVITE F2   |                |
      |  100 Trying F3 |--------------->|    INVITE F4   |
      |<---------------|  100 Trying F5 |--------------->|
      |                |<-------------- | 180 Ringing F6 |
      |                | 180 Ringing F7 |<---------------|
      | 180 Ringing F8 |<---------------|     200 OK F9  |
      |<---------------|    200 OK F10  |<---------------|
      |    200 OK F11  |<---------------|                |
      |<---------------|                |                |
      |      ACK       |      ACK F12                    |
      |--------------->|-------------------------------->|
      |                   Media Session                  |
      |<================================================>|
      |                       BYE F13                    |
      |<-------------------------------------------------|
      |                     200 OK F14                   |
      |------------------------------------------------->|
      |                                                  |

This is what I suppose happened before the problem, when everything worked properly.

200.152.246.50   64.34.162.221   64.34.163.35      201.13.48.4
PSTN Provider    sipbroker.com   voxalot.com		
      |                |                |                |
      |    INVITE F1   |                |                |
      |--------------->|    INVITE F2   |                |
      |  100 Trying F3 |--------------->|    INVITE F4   |
      |<---------------|  100 Trying F5 |--------------->|
      |                |<-------------- | 180 Ringing F6 |
      |                | 180 Ringing F7 |<---------------|
      | 180 Ringing F8 |<---------------|     200 OK F9  |
      |<---------------|    200 OK F10  |<---------------|
      |    200 OK F11  |<---------------|                |
      |<---------------|                |                |
      |       ACK      |       ACK      |    ACK F12     |
      |--------------->|--------------->|--------------->|
      |                   Media Session                  |
      |<================================================>|
      |                       BYE F13                    |
      |<-------------------------------------------------|
      |                     200 OK F14                   |
      |------------------------------------------------->|
      |                                                  |

I thank you again for your attention and ask you to help me to solve this problem. If you need more information, please let me know.

Sincerely,

André Silveira

[martin]

Hello André,

5- I agree with you about what the RFC 3261 says, but if you briefly take a look on the file that I have sent, you will see the diagram below. This is scenario of the problem. Pay special attention on the ACK message.

Exactly.

If you take a closer look:

200.152.246.50 (the PSTN provider) is sending the ACK to sipbroker.com instead of sending it directly to 201.13.48.4 (see my diagram)

sipbroker.com is forced to be part of the route by the PSTN provider. This part of the problem needs to be addressed by the PSTN provider.

The reason sipbroker.com bypasses voxalot.com is because we fixed a loose route problem back in July http://forum.voxalot.com/sip-broker-...html#post10989 where SIP Broker was placing itself in the dialog when it should not have been.

Either way, the solution is to allow ACKs from all of the end points you want to communicate with. Take another look at the RFC diagram I posted and you will see that ACKs come to you *directly* from the end point and not via proxies.

Once again the only reason that sipbroker.com is getting the ACK is because the PSTN provider is sending it there.

Hope this makes sense.
.

[910198]

Hi Martin,

Thank you again. Now at least I know that actually something changed on SipBroker/VoXalot configuration in July. Now there is a consistent explanation to the problem.

But the point is that the problem still exists for me and for all people that have the same scenario: home networks. This way you became VoXalot a service only for specialists that know how to configure a firewall. I guess you want to make the things easier so that any kind of user can subscribe and use the service smoothly.

What about when am I in a airport or hotel? Should I spoke to the Airport/Hotel Network Administrator: "Could you please create a static port forwarding to my IP address on your firewall so that I can receive incoming calls to my VoXalot number"?

What about the mobility?

What about when are there more than one endpoint on a private network? Most of the firewalls of these small routers does not support more than one static port forwarding to the same port (5060), but to different IP addresses.

I understood that you have made a change according to the RFC: nothing wrong. Nevertheless I believe that you fixed a small problem, but a bigger problem was created. The consequence is that many users like me now have problems on incoming calls from PSTN.

I humblely beg you to reconsider this decision. Sometimes I thought about to upgrade my account to premium, but with this problem is not worth.

Sincerely,

André Silveira

[910198]

Hello Martin,

Just to add more information in order to help to solve this problem, I made more tests during a business travel I had. I made tests on the airport network, on the hotel network and on the customer network. In all of them, the result was the same: incoming calls from PSTN did not work.

The main point is that if there were more Sip Broker users in these places, none of them could receive incoming calls from PSTN.

I kindly ask tou to analyze this issue once more, please, so that we can have this service (incoming calls from PSTN) running back again.

Thank you!

André

[martin]

Hello André,

I assure you the PSTN access numbers are working for the vast majority of end points that are SIP compliant. As such, there is nothing for us to "fix".

As I mentioned in my post:

the solution is to allow ACKs from all of the end points you want to communicate with. Take another look at the RFC diagram I posted and you will see that ACKs come to you *directly* from the end point and not via proxies.

It should be noted that the logs show these numbers are successfully used 1000's of times per day. In fact we use them for conference calls with clients and never have problems.

You need to fix your end point to accept the ACKs
.

[910198]

Hello Martin,

Thank you for your response.

Concerning what you said

You need to fix your end point to accept the ACKs

unfortunately I can not agree with you. The reason is in everything we wrote on this thread until now. The endpoint (SIP Phone) would accept the ACKs if them arrived on it. But they do not arrive because of what is described some messages above. It does not depend on the end point configuration to work. For the ACK to arrive it is necessary to create some mappings on the firewall. This is simply impossible on public networks. If the ACK came from the same IP address of the INVITE, the ACK would arrive, because the mapping would be created dynamically by the stateful inspection firewall.

I also assure you that before the change occurred in July described at http://forum.voxalot.com/sip-broker-...necessary.html everything worked well.

I guess my point would be clear enough if you made a test on a public network, like airport or some hotel, where you do not have any administrator autonomy to change configuration.

Thank you once more. Regards,

André