|Main Archive Page > Month Archives > wireshark-users archives|
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
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:
It 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.
On Wed, Mar 24, 2010 at 9:42 PM, vishal borkar <email@example.com> wrote:
> Accepted that the SIP data might be encrypted.but the frames that you
> (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,
Sent via: Wireshark-users mailing list <firstname.lastname@example.org>