issue with DatagramSocket

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I have a problem with a DatagramPacket which receives incorrect bytes. I made a capture with ethereal to see what is actually sent over the network and I see a difference between what is captured with ethereal and what is displayed with the following code:

       DatagramSocket socket = new DatagramSocket(5062, 192.168.1.201);

       byte[] buffer = new byte[65535];
       DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
       try {
           socket.receive(packet);
       } catch (IOException e) {
           e.printStackTrace();
       }
       InetAddress remoteAddress = packet.getAddress();
       int remotePort = packet.getPort();

       System.out.println(packet.getData());

Here is what is displayed with the previous code:

:SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.201:5060;branch=z9hG4bK4cdee679367a
Via: SIP/2.0/UDP 192.168.1.201:5064;branch=z9hG4bK-1-0_32755
From: sipp <sip:sipp@xxxxxxxxxxxxx:5064>;tag=32755_1
To: sut <sip:proxy@xxxxxxxxxxxxx:5062>;tag=1
Call-ID: 1-32755@xxxxxxxxxxxxx
CSeq: 1 INVITE
Contact: <sip:192.168.1.201:5062;transport=UDP>
Content-Type: application/tent-Type: application/sdp
Content-Length:  139

v=0
o=user1 53655765 2353687637 IN IPV4 192.168.1.201
s=-
c=IN IPV4 192.168.1.201
t=0 0
m=audio 6004 RTP/AVP 0
a=rtpmap:0 PCMU/8000

And here is what is captured with ethereal:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.201:5060;branch=z9hG4bK4cdee679367a
Via: SIP/2.0/UDP 192.168.1.201:5064;branch=z9hG4bK-1-0_32755
From: sipp <sip:sipp@xxxxxxxxxxxxx:5064>;tag=32755_1
To: sut <sip:proxy@xxxxxxxxxxxxx:5062>;tag=1
Call-ID: 1-32755@xxxxxxxxxxxxx
CSeq: 1 INVITE
Contact: <sip:192.168.1.201:5062;transport=UDP>
Content-Type: application/sdp
Content-Length: 139

v=0
o=user1 53655765 2353687637 IN IPV4 192.168.1.201
s=-
c=IN IPV4 192.168.1.201
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

The first line and the header Content-Type do not match.
If anyone has already have the same type of problem, any help would be appreciated. I also had a problem with bea jrockit JVM, which datagramPacket.getLength() was not corresponding to the actual content length of the packet. I patched it with a loop over the bytes returned with packet.getData(), and when I find a value of 0 for the current byte, I consider the index of the current byte as the actual length of data I can read from the packet.

Thanks a lot,

yohann


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux