Re: [Sipp-users] SIPp Bug in 3.0 - Incorrect Media IP

[Charles P W. <cpw...@us...>]

Eliot,

I can't think of any reason that SIPp would read a differnet packet off 
the network than what it recieves.  Maybe there is some confusion with the 
scenario or something.

Can you include the XML and a -trace_msg log with a single  single call 
(the -m 1 flag will limit SIPp to generating one call), together with the 
wireshark trace of the port from the same host?

Please annotate the -trace_msg log with where things went awry.

Charles

sip...@li... wrote on 12/12/2007 08:20:48 PM:

> 
> It appears that there is a bug in SIPp 3.0 (and earlier) with 
> regards to the media IP in the SDP. I have a Wireshark capture, 
> switch debug, and some debug output from SIPp showing the following 
behavior:
> 
> Our switch sends a 183 w/SDP to SIPp from A.A.A.A.
> The 183 contains a 'c=IN IP4 B.B.B.B' SDP line.
> The debug output from SIPp and the Wireshark packet capture agree on
> the B.B.B.B IP address in the connection line of the SDP.
> 
> Our switch sends a 200 w/SDP to SIPp from A.A.A.A.
> The 200 contains a 'c=IN IP4 B.B.B.B' SDP line.
> The debug output from SIPp shows 'c=IN IP4 A.A.A.A'.
> Wireshark and the switch debug output both show 'c=IN IP4 B.B.B.B'.
> 
> I modified SIPp 3.0 to display the receive buffer in sipp.cpp:
> empty_socket() immediately after the socket read:
> 
>   switch(socket->ss_transport) {
>     case T_TCP:
>     case T_UDP:
>       ret = recvfrom(socket->ss_fd, buffer, readsize, 0, 
> new_destination,  &addrlen);
>       WARNING_P1("DEBUG: Just read from socket:\n%s\n", buffer);
>       break;
>     case T_TLS:
> #ifdef _USE_OPENSSL
>       ret = SSL_read(socket->ss_ssl, buffer, readsize);
>       /* XXX: Check for clean shutdown. */
> #else
>       ERROR("TLS support is not enabled!");
> #endif
>       break;
>   }
> The output shows 'c=IN IP4 A.A.A.A' instead of 'c=IN IP4 B.B.B.B'. 
> So, it looks like the message is being modified before it is read 
> from the socket. I could not find any other recvfrom() call except 
> for the one in rtp_echo, which I am assuming has no bearing on this.
> So, it appears that this is the location where the packet is read 
> from the network socket (and not from a socket to another thread, 
> which I had considered as a possibility). If this is really where it
> is being read from the network socket, how in the world can it be 
> incorrectly reading the packet in such a way that the wrong IP shows
> up in the 'c=' line?
> 
> I would very much appreciate any assistance on getting this quickly 
> resolved. I am available for as much leg work and testing as needed 
> to resolve this. This prevents us from using SIPp to test media 
> issues to devices that use different signaling and media addresses, 
> which is a capability we would very much like to have in SIPp.
> 
> Eliot Gable
> Senior Engineer
> 1228 Euclid Ave, Suite 390
> Cleveland, OH 44115
> 
> Direct: 216-373-4808
> Fax: 216-373-4657
> eg...@br...
> 
> [image removed] 
> 
-------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> 
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Sipp-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/sipp-users