Now it works running with your way. Thanks.
The sipp doc shows to use the server IP before the options. It would have
been useful if document had more elaborate use cases and addressed this..
On Fri, Mar 25, 2011 at 12:42 PM, mayamatakeshi <[email protected]>wrote:
>
> On Sat, Mar 26, 2011 at 1:21 AM, Romel Khan <[email protected]> wrote:
>
>> Looks like sipp doesn't properly populate the remote_ip as soon as -i and
>>> -bind_local options are used. The remote_ip is wrongly populated with the
>>> local IP. I ran this in 3.2 version::
>>> sipp 10.49.16.20:5060 -bind_local 10.49.138.20 -i 10.49.138.20 -m 1
>>> -s 19734380000 -sf crpuac.xml -trace_msg
>>>
>>> Note request uri is 10.49.138.20 when it should be 10.49.16.20:
>>> :::::::::::
>>>
>>> INVITE sip:[email protected]:5060 SIP/2.0
>>> Via: SIP/2.0/UDP 10.49.138.20:5060;branch=z9hG4bK-32471-1-0
>>> From: sipp <sip:[email protected]:5060
>>> ,otg=siptest1>;tag=32471SIPpTag001
>>> To: sut <sip:[email protected]:5060>
>>> Call-ID: [email protected]
>>> CSeq: 1 INVITE
>>> Contact: sip:[email protected]:5060
>>> ...
>>>
>>
> I never used bind_local. Are you sure it requires a parameter?
> Also, I usually leave the server IP:Port at the end to avoid confusing the
> argument parser. So I would try it like this:
> sipp -bind_local -i 10.49.138.20 -m 1 -s 19734380000 -sf crpuac.xml
> -trace_msg 10.49.16.20:5060
>
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
