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 |
From: Rob D. <rk...@rk...> - 2013-07-25 20:25:26
|
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 > |
From: Patrick W. <pw...@gm...> - 2013-07-26 17:09:12
|
Hi Max, Not sure if this is the correct fix but now I did get the correct port binded for TCP. Find this piece of code near the end of the function open_connections() from sipp.cpp and add the marked lines: if((!multisocket) && (transport == T_TCP || transport == T_TLS || transport == T_SCTP) && (sendMode != MODE_SERVER)) { if((tcp_multiplex = new_sipp_socket(local_ip_is_ipv6, transport)) == NULL) { ERROR_NO("Unable to get a TCP socket"); } /* OJA FIXME: is it correct? */ if (use_remote_sending_addr) { remote_sockaddr = remote_sending_sockaddr ; } sipp_customize_socket(tcp_multiplex); + if(sipp_bind_socket(tcp_multiplex, &local_sockaddr, NULL)) { + ERROR_NO("Unable to bind TCP socket"); + } if(sipp_connect_socket(tcp_multiplex, &remote_sockaddr)) { if(reset_number >0){ WARNING("Failed to reconnect\n"); sipp_close_socket(main_socket); reset_number--; return 1; }else{ .... Patrick On Thu, Jul 25, 2013 at 5:25 PM, Rob Day <rk...@rk...> wrote: > 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 > > > > > ------------------------------------------------------------------------------ > 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 > |