From: Max M. <max...@si...> - 2013-07-25 18:54:37
|
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 |