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
