I did some tests here with TCP and got the same problem.... maybe it's a
bug affecting only TCP...
I can confirm that with UDP the problem does not happen!
I had a quick look over the code but didn't find any obvious error... If
you are into coding take a look in open_connections() from sipp.cpp
Regards!
On Thu, Jul 25, 2013 at 12:13 PM, Max Magee <max.ma...@singlewire.com>wrote:
> Hi Patrick,
>
> I've tried it with -t t1 and -t tn, both have the same problem.
>
> 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]>
> ...
>
> -Max
>
>
> On Thu, Jul 25, 2013 at 10:03 AM, Patrick Wakano <pwak...@gmail.com>wrote:
>
>> are using multi socket transport mode?
>> what is your cmd line?
>>
>>
>>
>>
>>
>> On Thu, Jul 25, 2013 at 11:39 AM, Max Magee <max.ma...@singlewire.com>wrote:
>>
>>> 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-users mailing list
>>> Sipp-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/sipp-users
>>>
>>>
>>
>
------------------------------------------------------------------------------
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-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
