Thanks Patrick,
I was looking around in there myself (I'm not a C++ guy, but I've worked
with some C in the distant past)- I just don't know enough about how the
C++ libraries are supposed to work to really get anywhere.
I might switch over to the devs group to see if they can assist.
-Max
On Thu, Jul 25, 2013 at 11:53 AM, Patrick Wakano <pwak...@gmail.com> wrote:
> 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
