Hello,
Let me help you understand the excellent tool Brekeke gave us by allowing us to see the session details. I'm sure you will find it most helpful in debugging your problem.
A call consists of 2 parts.
1) The call from the UA/Phone to the Brekeke sip server
2) The call from the Brekeke sip server to another UA or Provider
For example let's assume the call is from a sip phone to brekeke to a provider.
In the first leg of the call phone to provider you can see the session info.
The first leg is also broken into two parts. The first Listen/Send/Target refers to your Sip server so in my example we have:
Part 1
Listen-port = 10946
Send-Port = 10938
Target = SipServerIpAddress
This means that the Sip server is listening to your ip phone's voice stream(rtp) on port 10946, sending voice streams(rtp) to your ip phone from the sip server's port 10938 and the sip server ip address is the target.
Part 2
Listen-port = 10938
Send-Port = 10946
Target = IpPhoneIPAddress:Port
This is the inverse of part one but again it only deals with the sip servers ports, not the ip phone. The Target here does reveal the phones listening port as it follows the Target's ipaddress. This tells you that the phone wants it's rtp voice stream sent to that port. Typically, in a ip phone you can specify what range of ports the phone can use for rtp. In a Linksys spa-941 it defaults to 16384-16482. Now, what get's confusing is when the phone is behind a nat router and the sip server is not in that lan you may see a number for the ip phones port in the Target that you don't recognize. That is because the nat router changes it. If your phone is behind a nat router and your sip server is not in that lan and the target port for the ip phone is not what you expect then the router is changing it. This should still work since Brekeke sends it to the port specified in the target anyway. Some routers have the ability to exclude a port range from translation.
Post some more info about your situation or post your session details to get more detailed help.