I am not sure about SSL. But I tried to find more about IP/port problem. It is not 100% clear to me so far. I had to dig down myself to see how this works...:)
There are special techniques including protocols such as STUN, TURN, ICE etc to let a client on a NAT-protected device know its real IP address. This document might be some help:
http://communicationsserverteam.com/archive/2009/04/22/433.aspxIt uses "TURN" protocol in the example. In your case, STUN is used. Not sure what the difference is, but they look quite similar. In essence, your client sends a STUN request to an external STUN server, which replies back with your real (external) IP address. (Look at frames 495 and 498 - they are probably indicating your IP in some form). Now your client can advertise this IP to your peers. Port number should also be taken care of in a similar manner, but that is not very clear in your packets.
Once these things are determined, they are specified in SDP attribute "candidate". Look at frames 602 (SIP Invite) and 741 (SIP 200 OK - accept call). First, SDP media (m) information indicates media port number to be used. But also attributes (a) "candidate" specify the real information. It has IP, port information in some form. Port is probably a clear number, but in your case, looks like 22300 and 22301 instead of 22308. The other port number 43312 is clearly mentioned.
Hope this helps. Also do "Follow TCP stream" on one of the SIP packets. That will be helpful too.
- Abhijit
On Wed, Mar 24, 2010 at 9:42 PM, vishal borkar
<weeshalll@xxxxxxxxx> wrote:
Accepted that the SIP data might be encrypted.but the frames that you mentioned (NO 406 onwards ) do not carry the actual SIP data. If you see closely the SIP data
is travelling in SSL packets (Frame no 422 onwards).All of it seems to be plain text.
And my IP and port is nowhere to be seen in those packets.So my problem still persists.
Thanks and regards,
Vishal.
