now the next message from the uas (100 trying) is marked as
un-expected followed by "dead call" errors. makes me think that the
200 OK on the registration marked the call as dead.
I was afraid of that but I didn't want to scare you right away :-)
The clean way out should be the following:
* you would run a sidekick scenario in parallel to your one, in the
"3pcc master-slave mode"
* your main scenario would begin with <recv request="REGISTER"
optional="true" next="process_REGISTER"/> followed by <recvCmd/> (a
mandatory one), followed by the session establishment (<send> ...
INVITE sip... </send> etc., the last message of this branch would
contain a next="scenario_end" attribute)
* after that message, you would place
<label id="process_REGISTER"/>
<send> ... 200 OK ... [last-Cseq:] ... </send>
<sendCmd><<![CDATA[
[last_Call-ID:]
]]></sendCmd>
<label id="scenario_end"/>
* the sidekick scenario would contain just
<recvCmd/>
<pause milliseconds="1000"/>
<sendCmd><<![CDATA[
Call-ID: [call_number]-[pid]@[local_ip]
]]></sendCmd>
The overall principle is: the main scenario receives a REGISTER,
responds it, and sends a Cmd to the sidekick scenario, pushing it to
send back a (delayed) Cmd with a new, independently created call-ID.
Upon reception of the latter Cmd, the main scenario starts an as if
completely independent pass through itself, which would take the
INVITE-sending path.
I've never tried this practically so I'm curious whether it shall work.
You may have to add some bogus stuff to the sidekick scenario so that it
doesn't claim inability to determine in which mode to start.
P.
Dne 14.7.2016 v 20:35 Drell, David napsal(a):
thank you for the pointer. I had seen that in the manual but it did
not click how I could take advantage of that.
So that got me past the reject of the invite, but now the next message
from the uas (100 trying) is marked as un-expected followed by "dead
call" errors. makes me think that the 200 OK on the registration
marked the call as dead.
is this correct?
We have developed a fair number of sipp scripts to test our video
endpoint but this is the first time we are trying to use it for
registered scenarios. What is the best practice for using sipp in
this way? Should we have two different sipp instances, one to handle
registrations and another to handle calls?
thank you.
David
------------------------------------------------------------------------
*From:* sindelka <sinde...@ttc.cz>
*Sent:* Thursday, July 14, 2016 1:12:45 PM
*To:* sipp-users@lists.sourceforge.net
*Subject:* Re: [Sipp-users] question about new call ID from register
to invite
Hi David,
a single pass through a scenario (a "call") has to use the same
Call-ID, that's the principle of SIPp operation. I have written a more
detailed explanation in this response to a loosely related question
<https://sourceforge.net/p/sipp/mailman/message/34707334/>.
For your case, a quick workaround would be to use a feature of SIPp
described in the manual:
Note: [call_id] can be pre-pended with an arbitrary string using
'///'. Example: Call-ID: ABCDEFGHIJ///[call_id] - it will still be
recognized by SIPp as part of the same call.
So you would still use the Call-ID value extracted from the incoming
REGISTER also for the dialog initiated using the INVITE, but for all
messages sent in the context of that dialog, you would prepend the
Call-ID value with e.g. a "my///" string. This should be enough to
make the UUT interpret such Call-ID value as a distinct one, while
SIPp would recognize the messages received with this modified call-id
value as belonging to the same pass through the scenario.
Pavel
Dne 14.7.2016 v 18:30 Drell, David napsal(a):
hi all,
my scenario is sipp acting as registrar and proxy which accepts the
registration then invites the unit I am testing.
uas-uut sipp
---------- ------
--> REGISTER -->
<-- 200 OK <--
<-- INVITE <-----
--> 100 -->
--> 180 -->
--> 200 -->
sipp is using the same call ID from the received register in the
outbound invite - which is wrong and causes my uas code to reject the
invite.
how can I make sipp increment the call ID when it starts the call?
thank you.
////////////////////////////////// scenario below
//////////////////////////////////////
<scenario name="Gs registers with sipp as CUCM">
<recv request="REGISTER" ></recv>
<send>
<![CDATA[
SIP/2.0 200 OK
Via: SIP/2.0/TCP [local_ip];branch=[branch]
From: "2367" <sip:2367@[local_ip]>;tag=[call_number]
To: <sip:2367@[local_ip]>;tag=585257356
Date: Wed, 13 Jul 2016 14:32:59 GMT
[last_Call-ID:]
Server: Cisco-CUCM10.5
CSeq: 1 REGISTER
Expires: 120
Contact: <sip:2367@[local_ip];transport=tcp>;methods="INVITE, ACK,
BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK,
UPDATE, REFER"
Supported: X-cisco-sis-7.1.1
Content-Length: 0
]]>
</send>
<send>
<![CDATA[
INVITE sip:2367@[local_ip];transport=tcp SIP/2.0
Via: SIP/2.0/TCP [local_ip];branch=[branch]
From: "GS Austin Dev Codec 8" <sip:2368@[local_ip]>;tag=[call_number]
To: <sip:2367@[local_ip]>
Date: Wed, 13 Jul 2016 14:33:24 GMT
Call-ID: [call_id]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Send-Info: conference, x-cisco-conference
Alert-Info: <file://Bellcore-dr1/>
Contact:
<sip:2368@[local_ip];transport=tcp>;video;audio;proxy=replace;+sip.instance="<urn:uuid:8500b350-5ef3-592d-bd58-77ebbd405217>"
Remote-Party-ID: "GS Austin Dev Codec 8"
<sip:2368@[local_ip];x-cisco-callback-number=2368>;party=calling;screen=yes;privacy=off
Max-Forwards: 69
Content-Length: 0
]]>
</send>
<recv response="100" optional="true"></recv>
</scenario>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
