Re: [Sipp-devel] Fwd: local_port wrong/doesn't match actual socket value

[Rob D. <rk...@rk...>]

I agree that this is a bug, and I have a rough idea what's going on
(partly thanks to the fact it works on UDP) - UDP sockets have a
call_port variable containing this port number, whereas local_port
gets used for all other sockets, even where it actually sends from an
ephemeral port. The relevant code is around line 2073 of call.cpp -
search for "E_Message_Local_Port".

I haven't had much luck this evening with either binding the TCP
socket to local_port before sending (which wouldn't work for -t tn at
any rate) or with getting the ephemeral port from the socket and using
that in the call (I can get *an* ephemeral port from it, but it's not
the one data's being sent on...). I'll have a better look at fixing
this when I have a bit more time - thanks for reporting it.

Rob

On 25 July 2013 19:54, Max Magee <max...@si...> wrote:
> Pretty sure an issue I'm having (outlined in the attached message I
> originally sent to the sipp-users email list) is a bug with TCP [local_port]
> keyword population as well as -p <port> parameter being overridden when
> using -t tn or t1 options.  This message is mostly a heads-up rather than a
> request for help at this point.  I didn't have any headway from just
> wandering around in call.cpp (I'm not a c developer, so the actual
> connection stuff was pretty Greek to me).
>
> At the suggestion of Patrick W. below, I tried switching to UDP, when I did,
> the port was correctly set in the message.
>
> This is the Call Manager log, specifying where the connection was coming
> from (47708), and the data, auto-populated from [local_port] below:
> 33991040.001 |12:16:02.145 |AppInfo  |//SIP/SIPUdp/wait_UdpDataInd: Incoming
> SIP UDP message size 2014 from <local SIPp IP>:[47708]:
> [2329558,NET]
> REFER sip:<server IP> SIP/2.0
> Via: SIP/2.0/UDP <local SIPp IP>:47708;branch=z9hG4bK-1152-1-0
> From: sipp <sip:000000000000@<local SIPp
> IP>:47708>;tag=000000000000000011152-0ba70cb4
>
> This does not work using TCP.  I've tried it with -t t1 and -t tn, both have
> the same problem.
>
> The command line I originally attempted to use (the output in the message
> below is from the TCP attempt):
> sipp <server ip>:5060 -m 1 -t tn -sf register.xml -rxsf receiver.xml -inf
> testdb.csv -infindex testdb.csv 4 -d 110000 -r 40 -i <local ip> -base_cseq
> 100 -trace_err -trace_msg
>
> A typical stanza from one of the xml templates looks like this:
> <scenario name="Emulate 7962">
>   <send>
>     <![CDATA[
>             REFER sip:[remote_ip] SIP/2.0
>       Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
>       From: sipp
> <sip:[field0]@[local_ip]:[local_port]>;tag=[field0]0000[call_number][pid]-[field1]
>       To: <sip:[remote_ip]>
>       Call-ID: [call_id]
>       Date: [timestamp]
>       CSeq: [cseq] REFER
>       User-Agent: Cisco-CP7962G/9.3.1
>       Expires: 10
>       Max-Forwards: 70
>       Contact: <sip:[field0]@[local_ip]:[local_port]>
> ...
>
> ---------- Forwarded message ----------
> From: Max Magee <max...@si...>
> Date: Thu, Jul 25, 2013 at 9:39 AM
> Subject: local_port wrong/doesn't match actual socket value
> To: "sip...@li..." <sip...@li...>
>
>
> I am using SIPp to connect to a CUCM.  I can register and maintain
> registration through a TCP register -> next -> pause -> register loop.
> There seems to be no problem with that, except that the port that SIPp is
> using (according to Call Manager logs, packet captures, and socket analysis)
> is not being keyword-replaced using [local_port] in my scripts.
>
> What I see is that that local_port keyword is replaced by a random port
> value around 5060 (or whatever value is specified using the -p flag) , which
> is fine, but then I would expect SIPp to then communicate over that port.
> Instead, it selects a different high ephemeral port, (I've seen 49899,
> 49566, 46000, 46004) and connects on that.  I don't care which way it
> connects (either using my port or not), but I would want the [local_port]
> value to represent the actual socket that it did use.  Is this a bug?
>
> So a typical CUCM log entry looks like this (I've removed some IP's for
> security:
> 33820833.004 |11:17:41.043 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP
> TCP message from <local SIPp address> on port 46000 index 103142 with 2112
> bytes:
> [2329408,NET]
> REGISTER sip:<server address> SIP/2.0
> Via: SIP/2.0/TCP <local SIPp address>:5062;branch=z9hG4bK-9092-1-2
> From: <sip:803000@<server address>>;tag=000000000000000019092-0ba70cb4
> To: <sip:803000@<server address>
> Call-ID: 1-9092@<local SIPp address>
> Max-Forwards: 70
> Date: 2013-07-24        11:17:35:932    1374682655.932906
> CSeq: 102 REGISTER
> User-Agent: Cisco-CP7962G/9.3.1^M
> Contact: <sip:cadf8fab-b12d-007f-9ed6-e9186c162ff9@<local SIPp
> address>:5062;transport=TCP>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000000000000>";+u.sip!devicename.ccm.cisco.com="SEP000000000000";+u.sip!model.ccm.cisco.com="404"
> ...
>
> Notice that although the socket is actually connecting on 46000 (the local
> port), [local_port] replacement is getting populated with 5062.
>
> The problem is that later on, CUCM sends a request to that device, using the
> port and other info listed in the Contact field.  This breaks the CUCM
> response mechanism because there is no device registered/connected on that
> port.  (I'm using a modified version of SIPp that allows registration to be
> maintained in client mode, and also can receive incoming requests in server
> mode.)  This problem exists in the trunk of SIPp as well.
>
> I've tried setting the -bind_local flag, but it seems like that re-routes my
> remote target to my localhost (which breaks everything, since I end up
> sending to myself).  I played with -rsa, but I don't think that has anything
> to do with the local port settings.
>
> So I'm flailing out to you kind people now.
>
> Thanks for any help,
>
> Max Magee
> Singlewire Software
> Madison, WI USA
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Sipp-devel mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/sipp-devel
>