Hello André,
Quote:
|
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.
.