Hi Rob,
I am not sure if the the issue is simply one of documentation, in the docs
the line below suggested that the cseq value should be the same as the last
received request..
*[cseq]*-Provides the CSeq value of the last request received. This value
can be incremented (e.g. [cseq+1] adds 1 to the CSeq value of the last
request).
In the case of a UAC scenario I send an ACK, this is sent after a response
has been received such as a 200, there was no last request received in the
UAC dialog, so it seems to have the value of the last request sent which
was sent by the SIPp instance (The second INVITE after the 401 challenge).
This doesn't quite fit with the documentation.
I had a look in the source and spotted a keyword 'last_cseq_number' that
suggested it fit the bill,
so far the limited testing I have done says this works great and is what I
am thinking of using for thiese cases; as it does not appear to be
documented I just wanted to make sure I wasn't about to be out on a limb
and the keyword was not about to be depreciated?
Also, I have noticed that the keyword [sipp_version] seems to be providing
the value 'unknown', is that a known problem?
Thanks
Paul
.
On Wed, Feb 4, 2015 at 8:55 PM, Rob Day <r...@rkd.me.uk> wrote:
> Can you send the full message log?
>
> On 4 February 2015 at 07:22, Paul Miller <idkpmil...@sip2serve.com> wrote:
> > Hi,
> >
> > I am using SIPp v 3.4.1, and have the snippit below in a UAC call
> > originating script.
> >
> > =============================
> >
> > <!-- awaiting to receive message -->
> > <recv response="200">
> > </recv>
> >
> >
> > <send>
> > <![CDATA[
> >
> > ACK sip:[service]@[field0] SIP/2.0
> > Via: SIP/2.0/[transport] [local_ip]:[local_port]
> > From:
> >
> <sip:[field1]@[field0]:[local_port]>;tag=24417923471779367133[call_number]
> > To: <sip:[service]@[field0]>;[peer_tag_param]
> > Call-ID: [call_id]
> > CSeq: [cseq] ACK
> > Max-Forwards: 70
> > Contact:
> <sip:[field1]@[local_ip]:[local_port];transport=[transport]>
> > P-Asserted-Identity: <sip:[field2]@[field0]>
> > [field3]
> > User-Agent: SIPp_v_[sipp_version]
> > Content-Length: 0
> >
> > ]]>
> > </send>
> >
> >
> > =============================
> >
> > As you can see in the message log below the ACK following receipt of the
> > 200OK is decremented instead of using the last received response (the
> 200).
> > The UAS keeps repeating the 200OK and so SIPp repeats the ACK until
> closure.
> >
> > =============================
> >
> > ----------------------------------------------- 2015-02-04
> 03:10:30.519336
> > UDP message received [879] bytes :
> >
> > SIP/2.0 200 OK
> > Via: SIP/2.0/UDP 192.168.0.122:5060;received=192.168.0.122
> > From: <sip:5...@sip2serve.com:5060>;tag=244179234717793671331
> > To: <sip:*4...@sip2serve.com>;tag=as06fb6455
> > Call-ID: 1-2587@192.168.0.122
> > CSeq: 3 INVITE
> > Server: FPBX-2.9.0(1.8.13.0)
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> > PUBLISH
> > Supported: replaces, timer
> > Contact: <sip:*43@192.168.0.23:5060>
> > Content-Type: application/sdp
> > Content-Length: 416
> >
> > v=0
> > o=root 1135431446 1135431446 IN IP4 192.168.0.23
> > s=Asterisk PBX 1.8.13.0
> > c=IN IP4 192.168.0.23
> > b=CT:384
> > t=0 0
> > m=audio 12008 RTP/AVP 9 8 0 101
> > a=rtpmap:9 G722/8000
> > a=rtpmap:8 PCMA/8000
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-16
> > a=ptime:20
> > a=sendrecv
> > m=video 12006 RTP/AVP 34 98 99
> > a=rtpmap:34 H263/90000
> > a=rtpmap:98 h263-1998/90000
> > a=rtpmap:99 H264/90000
> > a=sendrecv
> >
> > ----------------------------------------------- 2015-02-04
> 03:10:30.519520
> > UDP message sent (556 bytes):
> >
> > ACK sip:*4...@sip2serve.com SIP/2.0
> > Via: SIP/2.0/UDP 192.168.0.122:5060
> > From: <sip:5...@sip2serve.com:5060>;tag=244179234717793671331
> > To: <sip:*4...@sip2serve.com>;;tag=as06fb6455
> > Call-ID: 1-2587@192.168.0.122
> > CSeq: 2 ACK
> > Max-Forwards: 70
> > Contact: <sip:5965@192.168.0.122:5060;transport=UDP>
> > P-Asserted-Identity: <sip:5...@sip2serve.com>
> > Authorization: Digest
> > username="5965",realm="sip2serve.com",uri="sip:192.168.0.23:5060
> ",nonce="747527ae",response="3a1a50e29cac58593333b2c0c2ccf345",algorithm=MD5
> > User-Agent: SIPp_v_unknown
> > Content-Length: 0
> >
> >
> > ==============================
> >
> > Can someone explain?
> > Thanks
> >
> > Paul
> >
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take
> a
> > look and join the conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Sipp-users mailing list
> > Sipp-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/sipp-users
> >
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
