Re: [Sipp-users] Issue with sending same DTMF in UAC xml file

[Šindelka Pavel]

Hello,

on Windows, try "HxD Hex Editor" or "Hexedit" (I use the latter one, but 
that doesn't mean it is better, I just came across it first years ago 
when I was looking for such a tool). For Linux, use xxd to hexdump a 
file, edit it using any text editor, and use xxd -r to convert it back 
to binary.


But all of these are dangerous weapons, so use them with a lot of care.

To adjust the RTP headers properly, you need to open the pcap file 
first, make yourself familiar with the various fields of the RTP 
headers, understand the relationship between them, and also understand 
the .pcap format structure. The ability of Wireshark to highlight a 
field in the hex dump pane when you click it in the dissection pane 
should help you find what to change using the hex editor. But capturing 
DTMF generated by a phone and using Wireshark to filter out the 
necessary packets may still be a faster way to your goal.


In dtmf_2833_1.pcap, there are 10 packets; in all of them, you have to 
change the "sequence number" field to grow monotonously by 1 and start 
from a higher value than the last one in the file dtmf_2833_2.pcap; the 
"timestamp" value must be the same in all of them (for telephone-event 
packets in particular - this is not the case for normal audio or video 
codecs), but it has to be higher than the timestamp value in 
dtmf_2833_2.pcap.


So rather than editing the pcap file manually, it may be worthier to 
write a script that will generate .pcap files as needed for the 
particular test scenarios.


P.

Dne 20.05.2022 v 12:20 Vinayak Makwana napsal(a):

Hi
    Thanks for your response
My scenario it's as below:
first I am sending DTMF 1 then DTMF 2 and then DTMF 1 again . but 3rd 
DTMF 1 is not detected in Freeswitch.
Can you please give me suggestions like how can i change sequence 
number or RTP timestamp? and
Can you provide me with a binary editor link from where I can make 
changes in the PCAP file?


Regards
Vinayak Makwana

On Wed, May 18, 2022 at 9:22 PM Šindelka Pavel  wrote:

I would assume that the pcap player invoked by SIPp does not
adjust the
RTP sequence numbers and/or RTP timestamps when playing the .pcap
files,
so if the receiving RTP stack checks them, it considers all the
packets
of the second instance to arrive late and ignores them. But it is
weird
if a DTMF received in one call affects its processing in another
call,
is that indeed the case?

If my assumption is correct, you'll have to create a copy of the pcap
file and edit the sequence numbers and/or timestamps using some
editor
of binary files, or capture some real DTMF, or maybe modify the
source
code of the pcap player to take care of this.

Pavel


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


*https://www.ecosmob.com/itexpo/ <https://www.ecosmob.com/itexpo/>
*
*
*
*Disclaimer**
*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely 
those of the originator and do not necessarily represent those of the 
Company or its sister concerns. Any liability (in negligence, contract 
or otherwise) arising from any third party taking any action, or 
refraining from taking any action on the basis of any of the 
information contained in this email is hereby excluded.


*Confidentiality*
This communication (including any attachment/s) is intended only for 
the use of the addressee(s) and contains information that is 
PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, 
distribution, or copying of this communication is prohibited. Please 
inform originator if you have received it in error.


*Caution for viruses, malware etc.*
This communication, including any attachments, may not be free of 
viruses, trojans, similar or new contaminants/malware, interceptions 
or interference, and may not be compatible with your systems. You 
shall carry out virus/malware scanning on your own before opening any 
attachment to this e-mail. The sender of this e-mail and Company 
including its sister concerns shall not be liable for any damage that 
may incur to you as a result of viruses, incompleteness of this 
message, a delay in receipt of this message or any other computer 
problems.
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Issue with sending same DTMF in UAC xml file

[Šindelka Pavel]

I would assume that the pcap player invoked by SIPp does not adjust the 
RTP sequence numbers and/or RTP timestamps when playing the .pcap files, 
so if the receiving RTP stack checks them, it considers all the packets 
of the second instance to arrive late and ignores them. But it is weird 
if a DTMF received in one call affects its processing in another call, 
is that indeed the case?


If my assumption is correct, you'll have to create a copy of the pcap 
file and edit the sequence numbers and/or timestamps using some editor 
of binary files, or capture some real DTMF, or maybe modify the source 
code of the pcap player to take care of this.


Pavel


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Testing Asterisk with Basic UAC

[Šindelka Pavel]

Look into the manual how to handle the authentication dynamically. The 
contents of the Authorization header cannot be static as it is a 
response to a dynamically changing challenge used to prove that the UAC 
knows the shared secret. So the correct procedure is that you send a 
request with no Authorization header at all (or one with an old 
contents), and if the UAS sends you a 401 with an authentication 
challenge, you re-send the same request with an Authorization header 
with the correct answer to the challenge.


The UAC scenario must account for this possibility, it is not done 
automatically. I.e. one possible implementation:


send INVITE without Authorization

recv 100, 180, 183, ... optional

recv 401 optional next auth-invite

recv 200 next call-success

label auth-invite

send INVITE with Authorisation

recv 100, 180, 183, ... optional

recv 401 optional next authentication-failure

recv 200

label call-success

...

label authentication-failure


Pavel



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] tcpdump capture not always showing SIP signalling messages, but DIS (Distributed Interactive Simulator) protocol messages in Wireshark

[Šindelka Pavel]

That sounds more like a Wireshark configuration issue, where heuristics 
or static port assignment chooses to dissect the packet contents as DIS 
rather than SIP. Do you use standard SIP ports (5060) in your test 
setup? What have the "misinterpreted" packets have in common that 
differs from what the "properly interpreted" packets have in common?


Try to disable DIS in supported protocols of Wireshark and see whether 
it helps.


P.

Dne 21.07.2021 v 14:20 Nagy Akos napsal(a):

Hello dear SIPp experts,
 I didn't found any related thread in the archive, so I'm asking: we 
got a proper working SIPp generator on CentOS - connected to a SBC 
(Session Border Controller). With different scenarios working okay. 
SIPp logs (-trace_msg) are all fine. But if I capture with tcpdump -i 
any -s 0 -w /tmp/capture.cap: the capture is strange sometimes. Some 
messages appear as proper SIP messages, but some appear as "DIS 
(Distributed Interactive Simulator) protocol" messages - as the 
Wireshark shows it. Any suggestion?

 (We don't use TLS, obviously.)
 (Due to company secrecy, I'm not allowed to attach capture.)
 (I know, we can work with the SIPp log files, -trace_msg. But since 
we highly used to work with captures, it's easier and more comfortable 
for us to work with captures.)

  ;Thanks in advance and regards,
Akos Nagy


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIPp traffic testing

[Šindelka Pavel]

The missing part of the puzzle was that you use TCP. So there are two 
issues, one related to SIPp and another one related to real world 
deployment:


 * with TCP, the difference between UAC mode and UAS mode begins as low
   as in whether to bind to port 5060 for listening as UAS, or whether
   to bind to an ephemeral port for sending as UAC. I am not sure how
   this is internally handled in SIPp.
 * in real SIP deployment, the devices are rarely on public IPs, so the
   mode where each peer establishes its own TCP session (or even more
   sessions in sequence) towards the other peer's port 5060 to send its
   requests and receive responses to them is not practically usable on
   the call path between CPE and the exchange (or SBC). So if a CPE
   needs to use TCP to talk to the exchange (e.g. because TLS is used),
   the CPE needs to establish a TCP session as a client, in order to
   deliver the REGISTER, but that session then stays open "forever"
   (and prolonged by the the re-REGISTERs), and is reused not only for
   requests sent by the CPE (like outgoing INVITEs), but also for
   requests sent by the exchange (incoming INVITEs from the CPE
   perspective). I'm afraid I cannot imagine how to imitate this
   behaviour using SIPp without modifying the code, which is way above
   my capabilities.

P.


Dne 01.11.2020 v 1:20 sshark wsk napsal(a):
Here are the scenario files, input files & scripts. I will try and 
test with an older version of SIPp. I have to build it for my environment


Thanks

On Sun, Nov 1, 2020 at 7:31 AM Šindelka Pavel <mailto:sinde...@ttc.cz>> wrote:


Until the bug gets fixed, can you try an older version of SIPp?
Or, can you send me your scenarios for checking on my 3.6.0?

P.

Dne 28.10.2020 v 10:23 sshark wsk napsal(a):

I tried to use the scenario described in the link below,
unfortunately my sipp crashes with segmentation fault. Have
raised an issue in GitHub
https://sourceforge.net/p/sipp/mailman/message/34707334/

Any other ways I can achieve what I initially posted...


On Mon, Oct 5, 2020 at 2:23 PM sshark wsk mailto:sshark...@gmail.com>> wrote:

I have the below. I guess for the called party, as I am
finishing the thread for registration adn then wait for
INVITE in the same IP/port it seems to work. Maybe it's not a
good idea ?
Do you think the 3PCC scenario is the only way it will work
for my requirement ?

_Server1 script_
bindIP=10.10.10.1
port=5060
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./register_and_call.xml -inf ./A_user.csv -trace_msg

_Server2 script_
bindIP=10.10.10.2
port=5061
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./reg.xml -inf ./B_user_register.csv -trace_msg
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./receive.xml -inf ./B_user_answer.csv -trace_msg

I also saw some other posting where you can run UAC & UAS
with one instance of the sipp. Does that work ?
https://github.com/SIPp/sipp/issues/362



    On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel
mailto:sinde...@ttc.cz>> wrote:

> my plan for the called user is to keep different
> scenarios for register and process invites.
But that's only possible if the tested device is fine
with the REGISTER
coming from a different socket than the one which is
indicated in the
Contact uri, as is the case with vanilla SIP. In real
life environments,
which I suppose you are going to test, the SBC stores the
actual socket
from which the REGISTER has arrived, and sends the INVITE
to that stored
socket regardless what was written in the Contact uri in
the REGISTER.

As you want the calls to overlap, the scenario expecting
the INVITEs
(and later on receiving or sending the BYEs) must be running
continuously, so you cannot simultaneously send the
REGISTERs from the
same socket.

> I am struggling with the setup to continue to run
called user to
> continuously process invites. Should I be just using
labels to
> continue the loop in the "process invites" scenario ?
This sounds to me as if you haven't understood the
relationship between
threads and Call-IDs. At the beginning, the scenario
receives an initial
INVITE with some Call-ID yet unknown to it, so it spawns
a new thread
for that call, answers the INVITE with a 200, then
receives or sends a
BYE and responds it/gets it responded with a 200, and 

Re: [Sipp-users] SIPp traffic testing

[Šindelka Pavel]

Until the bug gets fixed, can you try an older version of SIPp? Or, can 
you send me your scenarios for checking on my 3.6.0?


P.

Dne 28.10.2020 v 10:23 sshark wsk napsal(a):
I tried to use the scenario described in the link below, 
unfortunately my sipp crashes with segmentation fault. Have raised an 
issue in GitHub

https://sourceforge.net/p/sipp/mailman/message/34707334/

Any other ways I can achieve what I initially posted...


On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <mailto:sshark...@gmail.com>> wrote:


I have the below. I guess for the called party, as I am finishing
the thread for registration adn then wait for INVITE in the same
IP/port it seems to work. Maybe it's not a good idea ?
Do you think the 3PCC scenario is the only way it will work for my
requirement ?

_Server1 script_
bindIP=10.10.10.1
port=5060
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./register_and_call.xml -inf ./A_user.csv -trace_msg

_Server2 script_
bindIP=10.10.10.2
port=5061
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./reg.xml
-inf ./B_user_register.csv -trace_msg
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./receive.xml -inf ./B_user_answer.csv -trace_msg

I also saw some other posting where you can run UAC & UAS with one
instance of the sipp. Does that work ?
https://github.com/SIPp/sipp/issues/362



On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel mailto:sinde...@ttc.cz>> wrote:

> my plan for the called user is to keep different
> scenarios for register and process invites.
But that's only possible if the tested device is fine with the
REGISTER
coming from a different socket than the one which is indicated
in the
Contact uri, as is the case with vanilla SIP. In real life
environments,
which I suppose you are going to test, the SBC stores the
actual socket
from which the REGISTER has arrived, and sends the INVITE to
that stored
socket regardless what was written in the Contact uri in the
REGISTER.

As you want the calls to overlap, the scenario expecting the
INVITEs
(and later on receiving or sending the BYEs) must be running
continuously, so you cannot simultaneously send the REGISTERs
from the
same socket.

> I am struggling with the setup to continue to run called user to
> continuously process invites. Should I be just using labels to
> continue the loop in the "process invites" scenario ?
This sounds to me as if you haven't understood the
relationship between
threads and Call-IDs. At the beginning, the scenario receives
an initial
INVITE with some Call-ID yet unknown to it, so it spawns a new
thread
for that call, answers the INVITE with a 200, then receives or
sends a
BYE and responds it/gets it responded with a 200, and all that
time the
Call-ID stays attached to the thread. If there are no other
messages to
send or receive left in the scenario, the thread will end
after some
guard timer expires (which is there to handle eventual
retransmissions
of the BYE or the 200 to it if they arrive) and SIPp stops
recognizing
that Call-ID, but if you jump to the beginning of the
scenario, the
thread will expect another INVITE with the same Call-ID -
which will
never arrive (or at least should never arrive).

So you don't need to do anything special in order that a
scenario was
ready for a new call. It just sits there listening at its
socket, and if
an INVITE with a yet unknown Call-ID arrives, it handles it in
a freshly
spawn dedicated thread. If several INVITEs come "at once" with an
individual Call-ID each, several threads get spawned "at once".

P.

Dne 04.10.2020 v 14:27 sshark wsk napsal(a):
> Hi Pavel,
>
> Thanks, yes I did go through that post and various other posts
> describing the challenges of running UAC & UAS for called
party..
> As I mentioned, my plan for the called user is to keep different
> scenarios for register and process invites.
>
> I am struggling with the setup to continue to run called user to
> continuously process invites. Should I be just using labels to
> continue the loop in the "process invites" scenario ?
>
> //sshark
>
> On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel
mailto:sinde...@ttc.cz>> wrote:
>> Hi sshark,
>>
>> could you pleas

Re: [Sipp-users] Conditional private header in INVITE

[Šindelka Pavel]

Exactement.

P.

Dne 27.10.2020 v 21:21 Olivier Thomas napsal(a):

Hi Pawel !

You means something like that :


  
    
    value="1" />

  


**




**
condexec_inverse="true"*>




*Olivier Thomas*

18 rue Guyon de Guercheville
Hérouville Saint-Clair
Tél : 06 16 44 92 57
olivier3.tho...@gmail.com <mailto:olivier3.tho...@gmail.com>



Le mar. 27 oct. 2020 à 20:16, Šindelka Pavel <mailto:sinde...@ttc.cz>> a écrit :


Maybe there are other possibilities, but I would use two INVITE
templates, with and without the P-My-Header, and send one ot the
other depending on the variable setting.

P.

Dne 27.10.2020 v 20:01 Olivier Thomas napsal(a):

Hello guys,

Does someone know if there is a way to make a private header
optional in a SIPp scenario ?

I would like to add a private header "P-My-Header" in the INVITE
requests only if a variable is set.

For instance, I would like to add this header only if the
[field0] from my input CSV file is equal to 0.
If [field0] is equal to any other value, the header "P-My-Header"
will not be added in INVITE requests.

Or maybe do you know a better way to do the same thing... ?

Thanks a lot for your help!
Regards,

*Olivier Thomas*

olivier3.tho...@gmail.com <mailto:olivier3.tho...@gmail.com>



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net  <mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Conditional private header in INVITE

[Šindelka Pavel]

Maybe there are other possibilities, but I would use two INVITE 
templates, with and without the P-My-Header, and send one ot the other 
depending on the variable setting.


P.

Dne 27.10.2020 v 20:01 Olivier Thomas napsal(a):

Hello guys,

Does someone know if there is a way to make a private header optional 
in a SIPp scenario ?


I would like to add a private header "P-My-Header" in the INVITE 
requests only if a variable is set.


For instance, I would like to add this header only if the [field0] 
from my input CSV file is equal to 0.
If [field0] is equal to any other value, the header "P-My-Header" will 
not be added in INVITE requests.


Or maybe do you know a better way to do the same thing... ?

Thanks a lot for your help!
Regards,

*Olivier Thomas*

olivier3.tho...@gmail.com 



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIPp traffic testing

[Šindelka Pavel]

my plan for the called user is to keep different
scenarios for register and process invites.
But that's only possible if the tested device is fine with the REGISTER 
coming from a different socket than the one which is indicated in the 
Contact uri, as is the case with vanilla SIP. In real life environments, 
which I suppose you are going to test, the SBC stores the actual socket 
from which the REGISTER has arrived, and sends the INVITE to that stored 
socket regardless what was written in the Contact uri in the REGISTER.


As you want the calls to overlap, the scenario expecting the INVITEs 
(and later on receiving or sending the BYEs) must be running 
continuously, so you cannot simultaneously send the REGISTERs from the 
same socket.



I am struggling with the setup to continue to run called user to
continuously process invites. Should I be just using labels to
continue the loop in the "process invites" scenario ?
This sounds to me as if you haven't understood the relationship between 
threads and Call-IDs. At the beginning, the scenario receives an initial 
INVITE with some Call-ID yet unknown to it, so it spawns a new thread 
for that call, answers the INVITE with a 200, then receives or sends a 
BYE and responds it/gets it responded with a 200, and all that time the 
Call-ID stays attached to the thread. If there are no other messages to 
send or receive left in the scenario, the thread will end after some 
guard timer expires (which is there to handle eventual retransmissions 
of the BYE or the 200 to it if they arrive) and SIPp stops recognizing 
that Call-ID, but if you jump to the beginning of the scenario, the 
thread will expect another INVITE with the same Call-ID - which will 
never arrive (or at least should never arrive).


So you don't need to do anything special in order that a scenario was 
ready for a new call. It just sits there listening at its socket, and if 
an INVITE with a yet unknown Call-ID arrives, it handles it in a freshly 
spawn dedicated thread. If several INVITEs come "at once" with an 
individual Call-ID each, several threads get spawned "at once".


P.

Dne 04.10.2020 v 14:27 sshark wsk napsal(a):

Hi Pavel,

Thanks, yes I did go through that post and various other posts
describing the challenges of running UAC & UAS for called party..
As I mentioned, my plan for the called user is to keep different
scenarios for register and process invites.

I am struggling with the setup to continue to run called user to
continuously process invites. Should I be just using labels to
continue the loop in the "process invites" scenario ?

//sshark

On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel  wrote:

Hi sshark,

could you please read https://sourceforge.net/p/sipp/mailman/message/34707334/ 
first if you haven't yet?

I think I've put pretty much everything in there on how to create "amphibious" 
scenarios behaving as both UAC and UAS, which is what you need in order to create a 
scenario which will register and keep updating the registration (as a UAC) and answer 
incoming calls (as a UAS) while it stays bound to the same local UDP socket. The need to 
stay bound to the same socket explains why I deem all the timing to be done using SIPp 
itself to be a better way than using bash scripts to spawn execution of the scenarios. 
It's true, however, that on the calling side you could spawn a registration, outgoing 
call, and unregistration as three separate scenarios binding to the same local port by 
shell script, but then you'd have to use one socket per user.

I didn't detail there the reasons why a Call-ID of a REGISTER must be different 
from the one of the INVITE, but normal SIP stacks should ignore or reject an 
INVITE with the same Call-ID like one in a previously received REGISTER, at 
least if it came soon enough after that REGISTER.

So as you don't insist on the unregistrations at the called side (from the 
point of view of traffic volume, registration updates will generate 1/2 of the 
traffic volume as compared to un-registrations and re-registrations with the 
same periodicity), the A and B scenarios (or rather scenario pairs) can be 
completely independent. Plus in the wild, an active un-registration is a rare 
beast.

There's just one point to the periodicity of the registration updates, some 
registrars/SBCs have not only maximum registration time but also a minimum one, and if 
you attempt to register for a shorter time, they respond with "423 interval too 
brief", so even if you'll be actually updating the registration every minute, you 
have to indicate an Expires value which will satisfy the SBC and/or registrar.

So in my approach, the B scenario would optionally accept and respond INVITEs 
(and possibly OPTIONS depending on the behaiour of the system being tested) by 
a corresponding branch, and mandatorily accept commands from the timer instance 
and spawn another branch which would periodical

Re: [Sipp-users] SIPp traffic testing

[Šindelka Pavel]

Hi sshark,

could you please read 
https://sourceforge.net/p/sipp/mailman/message/34707334/ first if you 
haven't yet?


I think I've put pretty much everything in there on how to create 
"amphibious" scenarios behaving as both UAC and UAS, which is what you 
need in order to create a scenario which will register and keep updating 
the registration (as a UAC) and answer incoming calls (as a UAS) while 
it stays bound to the same local UDP socket. The need to stay bound to 
the same socket explains why I deem all the timing to be done using SIPp 
itself to be a better way than using bash scripts to spawn execution of 
the scenarios. It's true, however, that on the calling side you could 
spawn a registration, outgoing call, and unregistration as three 
separate scenarios binding to the same local port by shell script, but 
then you'd have to use one socket per user.


I didn't detail there the reasons why a Call-ID of a REGISTER must be 
different from the one of the INVITE, but normal SIP stacks should 
ignore or reject an INVITE with the same Call-ID like one in a 
previously received REGISTER, at least if it came soon enough after that 
REGISTER.


So as you don't insist on the unregistrations at the called side (from 
the point of view of traffic volume, registration updates will generate 
1/2 of the traffic volume as compared to un-registrations and 
re-registrations with the same periodicity), the A and B scenarios (or 
rather scenario pairs) can be completely independent. Plus in the wild, 
an active un-registration is a rare beast.


There's just one point to the periodicity of the registration updates, 
some registrars/SBCs have not only maximum registration time but also a 
minimum one, and if you attempt to register for a shorter time, they 
respond with "423 interval too brief", so even if you'll be actually 
updating the registration every minute, you have to indicate an Expires 
value which will satisfy the SBC and/or registrar.


So in my approach, the B scenario would optionally accept and respond 
INVITEs (and possibly OPTIONS depending on the behaiour of the system 
being tested) by a corresponding branch, and mandatorily accept commands 
from the timer instance and spawn another branch which would 
periodically register. Eventually, that branch could accept a 
termination command from the timer instance if you want the scenario 
group to terminate autonomously after a predefined number of cycles or 
amount of time (I've never tried the |-m| command line option with a UAS 
scenario, maybe it works too).


The A scenario would accept trigger commands from its own timer 
scenario, where a single call in the timer scenario would use two 
distinct Call-IDs in the commands it would send to the executive 
scenario a few seconds apart: the first one would be made up and would 
trigger the registration, the second one would be the native one of the 
timer scenario and would trigger the outgoing call. The random duration 
of the outgoing call would be determined by the executive scenario, 
which would send a command to the timer one as a notification that the 
call has ended; in response to that, the timer would send back a command 
with the made-up call ID to trigger the unregistration. This way of 
synchronizing two threads within the same scenario is the simplest one I 
could find throughout the years.


The overlapping would be provided by the |-l 2| command line option as 
I've suggested earlier (third call cannot start until the first one ends).


P.

Dne 03.10.2020 v 6:11 sshark wsk napsal(a):

Thanks for the email, The main goal for me is to keep some constant
traffic on the SIP servers. I thought of having
registration/deregistration flows as they do invoke different
functions/procedures within the SIP server. If it introduces too much
complexity, then I am happy with doing re-registration rather than
de-register/register again...

How can I approach in doing this, can sipp orchestrate this or better
use shell script to do a loop and use sipp ?

Thanks for your help..

On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel  wrote:

Okay, the diagram shows clearly that the calls can and should overlap.

Is it an absolute must that the called side was de-registering and
re-registering again for every call, or may it register in the beginning
and keep renewing the registration periodically, and just accept
incoming calls? If the unregistration of the called side is not
mandatory, this will remove the need for synchronization between the A
side script and the B side script.

P.

Dne 30.09.2020 v 14:35 sshark wsk napsal(a):

I have below setup available with me
Shell Script1: Handles A party
Scenario 1 - A user to register and send INVITE and handle subsequent
messages (180, 200OK, ACK) and then deregister user

Shell Script2: Handles B party
Scenario 2 - B user to register
Scenario 3 - B user to accept INVITE and handle appropriate messages
(180, 200OK, ACK)
Scenario 4 - B user 

Re: [Sipp-users] SIPp traffic testing

[Šindelka Pavel]

Okay, the diagram shows clearly that the calls can and should overlap.

Is it an absolute must that the called side was de-registering and 
re-registering again for every call, or may it register in the beginning 
and keep renewing the registration periodically, and just accept 
incoming calls? If the unregistration of the called side is not 
mandatory, this will remove the need for synchronization between the A 
side script and the B side script.


P.

Dne 30.09.2020 v 14:35 sshark wsk napsal(a):

I have below setup available with me
Shell Script1: Handles A party
Scenario 1 - A user to register and send INVITE and handle subsequent
messages (180, 200OK, ACK) and then deregister user

Shell Script2: Handles B party
Scenario 2 - B user to register
Scenario 3 - B user to accept INVITE and handle appropriate messages
(180, 200OK, ACK)
Scenario 4 - B user to de-register

Have drafted a sequence diagram on what I had in mind. I hope it
explains what I have in mind..



On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel  wrote:

Do you want a single scenario to act as both A and B subscribers or you plan to 
use two scenarios? The thing is that if you want each user to unregister after 
the call, you need to have some synchronization between the A and B side even 
if each runs as a separate scenario on a different machine, otherwise you'll 
find A knocking on a closed door at B sooner or later.

You also state contradictory requirements - if you want at least one call "on 
air" at any given instant of time, the calls must be overlapping, whereas 
unregistering An,Bn after a call and then registering An+1,Bn+1 creates a gap between the 
calls. So choose which one of these two requirements is more important.

My approach would be to use a timer scenario, sending sync messages to both the 
A and B scenarios, with Call-IDs in the sync messages generated from 
[call_number] so that the sync message triggering the REGISTER at A and the one 
triggering the INVITE at A would be sent by the same call at the timer scenario 
but seen as two independent calls at the A scenario. To choose the right row in 
the csv file, I'd compute the row ID in the timing scenario and deliver it from 
there as a value of some P-user-index header - this way, all the calculations 
(call number modulo 5) would be done in the timer scenario and the A and B 
scenarios would just use the value extracted from that header in the 
synchronization messages. So you would not need to start sipp in loops, you'd 
just specify the total number of calls and number of calls per unit of time, 
and the modulo 5 would do the rest of the job.

I remember I was not able to make the 3PCC extended work some years ago, so you 
may have tough time making three scenarios (timer, A, B) work, but maybe it's 
not an issue any more, or it even never was and it was just some mistake I 
could not find in my setup.

-l 2 option on the command line should make sure that not more than two trigger 
calls will be active simultaneously, so the third call should not start before 
the first one finishes.

Pavel

Dne 29.09.2020 v 14:07 sshark wsk napsal(a):

Continuation to below thread, I have some additional questions
https://sourceforge.net/p/sipp/mailman/message/35176307/

I would like to know if anyone has some sample scenario files for
1. Have bunch of users for A (5) & B (5)
2. Register B1 party and listen for INVITEs
3. Register A1 party and setup call towards A party
4. Keep the call predefined period/can be random (~10s)
5. Terminate the call
6. De-register A1 & B1
7. Continue to the next set of users - A2/B2, A3/B3, A4/B4, A5/B5
8. Once list is exhausted, start from A1/B1

I am able to create the scenario file (Register/call/answer), however
would like to get some hints on how to do the below
- How SIPp can be scheduled to run through a loop
- Our goal is to have at least 1 call through the network at a given
point of time to simulate background testing

Thank You in advance for any inputs/feedback


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users




___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIPp traffic testing

[Šindelka Pavel]

Do you want a single scenario to act as both A and B subscribers or you 
plan to use two scenarios? The thing is that if you want each user to 
unregister after the call, you need to have some synchronization between 
the A and B side even if each runs as a separate scenario on a different 
machine, otherwise you'll find A knocking on a closed door at B sooner 
or later.


You also state contradictory requirements - if you want at least one 
call "on air" at any given instant of time, the calls must be 
overlapping, whereas unregistering A_n ,B_n after a call and then 
registering A_n+1 ,B_n+1 creates a gap between the calls. So choose 
which one of these two requirements is more important.


My approach would be to use a timer scenario, sending sync messages to 
both the A and B scenarios, with Call-IDs in the sync messages generated 
from [call_number] so that the sync message triggering the REGISTER at A 
and the one triggering the INVITE at A would be sent by the same call at 
the timer scenario but seen as two independent calls at the A scenario. 
To choose the right row in the csv file, I'd compute the row ID in the 
timing scenario and deliver it from there as a value of some 
P-user-index header - this way, all the calculations (call number modulo 
5) would be done in the timer scenario and the A and B scenarios would 
just use the value extracted from that header in the synchronization 
messages. So you would not need to start sipp in loops, you'd just 
specify the total number of calls and number of calls per unit of time, 
and the modulo 5 would do the rest of the job.


I remember I was not able to make the 3PCC extended work some years ago, 
so you may have tough time making three scenarios (timer, A, B) work, 
but maybe it's not an issue any more, or it even never was and it was 
just some mistake I could not find in my setup.


|-l 2| option on the command line should make sure that not more than 
two trigger calls will be active simultaneously, so the third call 
should not start before the first one finishes.


Pavel

Dne 29.09.2020 v 14:07 sshark wsk napsal(a):

Continuation to below thread, I have some additional questions
https://sourceforge.net/p/sipp/mailman/message/35176307/

I would like to know if anyone has some sample scenario files for
1. Have bunch of users for A (5) & B (5)
2. Register B1 party and listen for INVITEs
3. Register A1 party and setup call towards A party
4. Keep the call predefined period/can be random (~10s)
5. Terminate the call
6. De-register A1 & B1
7. Continue to the next set of users - A2/B2, A3/B3, A4/B4, A5/B5
8. Once list is exhausted, start from A1/B1

I am able to create the scenario file (Register/call/answer), however
would like to get some hints on how to do the below
- How SIPp can be scheduled to run through a loop
- Our goal is to have at least 1 call through the network at a given
point of time to simulate background testing

Thank You in advance for any inputs/feedback


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

So with sipp 3.995 (the last version available at sourceforge, which is 
closest to the 3.3 I was using before migrating to the new laptop), the 
|ontimeout| attribute works as expected (i.e. when the timeout elapses, 
the scenario execution jumps to the label indicated in the |ontimeout| 
attribute - see the scenario screen below), but as I've suggested 
earlier, the presence of || before 
the || 
causes the timeout not to ever happen. Which I've concluded to be quite 
logical back then when I was dealing with it myself, and as I could work 
that around, I gave up trying to understand that in detail quite quickly.


Now, I gave it a bit more, so I've configured also the 100 and 180 with 
|timeout| and |ontimeout|, where the timeout for the 100 was different 
from the one for the 180 and the 200 (I've commented out the rest of 
optional responses). Regardless whether the 100's timeout was longer or 
shorter than the one for the 180 and the 200, it always fired first.


So there are two differences in 3.6 as compared to 3.3:

 * optional messages preceding the mandatory one with ontimeout now
   don't prevent the timer from firing (improvement),
 * the ontimeout value is not used (regression).

Given that, I'd think that someone has made modifications to the 
handling of optional messages when a timeout is specified for the 
mandatory one following them, and this may have included some mistake in 
processing of the ontimeout attribute.


Hence I suggest you to raise an issue at github. Maybe with a note that 
it should be selectible whether a expiration of this particular timeout 
is considered a call failure or not, as when we want to send a BYE only 
if the remote peer didn't within some time, it may not always be 
considered a failure.


Other than that, sipp kept saying it cannot load or parse your scenario 
file until I've copy-pasted it to another one using a text editor. 
Changing iso-8859-2 to iso-8859-1 in the original file did not help. 
|| was missing in it, but with the copy, sipp just 
complained about absence of label 3, not about a problem with the whole 
file. Weird. So maybe do the same and try again before filing a bug, the 
3.6 parser has been reworked as compared to 3.3, so the same problem 
with the file may cause a different outcome there.


P.

|-- Scenario Screen  [1-9]: Change 
Screen --||

||  Call-rate(length)   Port   Total-time  Total-calls Remote-host||
||  10.0(0 ms)/1.000s   5060  15.20 s    1 127.0.0.1:5082(UDP)||
||
||  Call limit reached (-m 1), 1.006 s period  16 ms scheduler resolution||
||  1 calls (limit 615)    Peak was 1 calls, after 0 s||
||  0 Running, 2 Paused, 4 Woken up||
||  0 dead call msg (discarded)    0 out-of-call msg (discarded)||
||  3 open sockets||
||  0 Total RTP pckts sent 0.000 last period RTP rate 
(kB/s)||

||
|| Messages  Retrans Timeout   
Unexpected-Msg||

||    REGISTER --> 1 0||
|| 200 <-- 1 0 0 0||
|| 500 <-- 0 0 0 0||
|| 401 <-- 0 0 0 0||
||    REGISTER --> 0 0||
|| 200 <-- 0 0 0 0||
||   Pause [   4000ms] 1 0||
||  INVITE --> 1 0||
|| 200 <-- 0 0 1 0||
||
|| ACK --> 0 0||
||   Pause [    500ms] 0 0||
||  [ NOP ]||
||   Pause [   8000ms] 0 0||
|| BYE --> 1 0||
|| 200 <-- 0 0 0 0||
||
||   Pause [   4000ms] 0 0||
||    REGISTER --> 0 0||
|| 200 <-- 0 0 0 0||
|| 500 <-- 0 0 0 0||
|| 480 <-- 0 0 0 0||
|| 401 <-- 0 0 0 0||
||    REGISTER --> 0 0 0||
|| 200 <-- 0 0 0 0||
||   Pause [   4000ms] 0 0||
||--- Waiting for active calls to end. Press [q] again to force 
exit. ---||

|


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

Oops... I've tried to run your scenario and realized that I haven't 
compiled sipp at my new Windows laptop under cygwin yet (and the one 
saved from the old one asks for old libraries not available any more by 
peaceful means). So it won't be fast I'm afraid as I never did that 
before, last time a colleague did that for me who is not a colleague any 
more.


P.

Dne 26.03.2020 v 1:25 sshark wsk napsal(a):

Hi Alberto,

Thank you, honestly I could not find any difference from the line you 
have used. I tried it with below and my sipp does not go the label 
after timeout
ontimeout="BYE_AND_REGISTER">


I agree to your comment about sending CANCEL instead of BYE

I even compiled SIPp yesterday and tried, still same. Running on 
Ubuntu 18.04, hope it's not a reason :)

SIPp v3.6.0-23-g4dad7f2-SCTP-PCAP-RTPSTREAM

@Pavel Sindelka <mailto:sindelk...@gmail.com> - Were you able to test 
my scenario file and see if it worked or not...


Thanks for all the help
sshark


On Tue, Mar 24, 2020 at 11:29 PM Alberto Valente 
mailto:alberto-r-vale...@telecom.pt>> 
wrote:


I had the idea of having a similar scenario some time ago. I found
time to look for it and tested it in version 3.6.0 and it works
(it just doesn’t unregisters the calling subscriber).

I run it with  sudo sipp -sf ims/regInvCancel.xml -i
source-ip-address -inf csv/csvfile.csv remote-address:remote-port -m 1

The csv file has a line (may have more) like:

+351123456789;[authentication username=+351123456789
password=somepassword];somefqdn.com
<http://somefqdn.com>;3600;+351987654321;+3512;

+351123456789 – Subscriber to register and originate call

[authentication username=+351123456789 password=somepassword –
Authentication user and password

somefqdn.com <http://somefqdn.com> – subscriber realm

3600: time to use for register duration

;+351987654321 . Number to call

Just one note. If call is not answered send BYE is not the right
option.  A CANCEL request shall be used instead.

Best regards;

<http://altice.pt/>

*Alberto Valente*
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt <mailto:alberto.r.vale...@telecom.pt>
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
*altice.pt* <http://altice.pt>

facebook <https://www.facebook.com/alticeportugal>linkedin
<https://www.linkedin.com/company/altice-portugal/>twitter
<http://twitter.com/altice_portugal>sapovideos
<http://videos.sapo.pt/alticeportugal>youtube
<http://www.youtube.com/alticeportugal>

AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
confidencial, propriedade da Altice Portugal e/ou das demais
sociedades que com ela se encontrem em relação de domínio,
Fundação Altice Portugal e ACS, destinando-se ao uso exclusivo do
destinatário. Se não for o destinatário pretendido, não deve usar,
distribuir, imprimir ou copiar este e-mail. Se recebeu esta
mensagem por engano, por favor informe o emissor e elimine-a
imediatamente.
Obrigado

*From:*Šindelka Pavel [mailto:sinde...@ttc.cz
<mailto:sinde...@ttc.cz>]
*Sent:* terça-feira, 24 de março de 2020 07:24
*To:* sshark wsk mailto:sshark...@gmail.com>>
*Cc:* sipp-users@lists.sourceforge.net
<mailto:sipp-users@lists.sourceforge.net>
*Subject:* Re: [Sipp-users] ontimeout label does not work - sipp 3.6

Please post the complete scenario. I'll run it using an older SIPp
version on which my own scenarios with |ontimeout| work properly.

P.

Dne 24.03.2020 v 0:46 sshark wsk napsal(a):

Hi Pavel,

Thanks for your email

1. I am trying this flag for the first time. I have not tried
it with earlier SIPp versions. I just provided what version I
am testing on as I saw some threads showing that older
versions do not support this functionality.

2. I tried with optional recv lines removed, still same. It
timeout but it is treated as failed rather than jumping to
de-register sequence.

3. I have entire scenario in one file (reg, invite/answer,
dereg) and using the same call_id. I can see the registration
& call setup progresses until 180

BR,

sshark

On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel
mailto:sinde...@ttc.cz>> wrote:

Hi Sshark,

1. you've indicated a particular version of SIPp; have you
done that because your scenario did work in previous
versions and with this one it stopped, or did you just
want to provide as much information as possible but you
actually haven't tried this particular scenario with any
previous SIPp versi

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

Please post the complete scenario. I'll run it using an older SIPp 
version on which my own scenarios with |ontimeout| work properly.


P.

Dne 24.03.2020 v 0:46 sshark wsk napsal(a):

Hi Pavel,

Thanks for your email

1. I am trying this flag for the first time. I have not tried it with 
earlier SIPp versions. I just provided what version I am testing on as 
I saw some threads showing that older versions do not support this 
functionality.
2. I tried with optional recv lines removed, still same. It 
timeout but it is treated as failed rather than jumping to de-register 
sequence.
3. I have entire scenario in one file (reg, invite/answer, dereg) and 
using the same call_id. I can see the registration & call setup 
progresses until 180


BR,
sshark


On Tue, Mar 24, 2020 at 2:37 AM Šindelka Pavel <mailto:sinde...@ttc.cz>> wrote:


Hi Sshark,

1. you've indicated a particular version of SIPp; have you done
that because your scenario did work in previous versions and with
this one it stopped, or did you just want to provide as much
information as possible but you actually haven't tried this
particular scenario with any previous SIPp version?

2. I remember I had some trouble to make ontimeout work in one of
the older releases (and I haven't changed the scenarios since, so
don't read it as "and it worked flawlessly in the never ones"),
but I cannot remember the details (except that even with the
|ontimeout| handling defined next to the |timeout| specification,
a call where a timeout has elapsed is always counted as a failed
one which is sometimes not desirable, but you're not that far
yet). So can you try without the || between the || and _ ? It's not a solution, it is a
diagnostic step, but I'm afraid this type of setup (optional
messages and one mandatory one with a timeout specified) may not
have been addressed in the SIPp code.

3. I hope you don't actually send |REGISTER| and |INVITE| with the
same |Call-ID| value, as a normal SIP stack would fail on that.
This one is not related to |ontimeout|, it's related to how SIP
itself works.

Pavel


Dne 23.03.2020 v 13:43 sshark wsk napsal(a):

Hi Alberto,

Thank you for your suggestion. I have tried with below flag.
However still the it does not work


Is it possible to do some debug mode/prints to see why it does
not work

BR,
Sshark

On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente
mailto:alberto-r-vale...@telecom.pt>> wrote:

I think you must use something like



Where xx stands for the number of milliseconds you want
to wait for the 200 OK Mresponse

Best regards

<http://altice.pt/>

*Alberto Valente*
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt
<mailto:alberto.r.vale...@telecom.pt>
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
*altice.pt* <http://altice.pt>

facebook <https://www.facebook.com/alticeportugal>linkedin
<https://www.linkedin.com/company/altice-portugal/>twitter
<http://twitter.com/altice_portugal>sapovideos
<http://videos.sapo.pt/alticeportugal>youtube
<http://www.youtube.com/alticeportugal>

AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm
informação confidencial, propriedade da Altice Portugal e/ou
das demais sociedades que com ela se encontrem em relação de
domínio, Fundação Altice Portugal e ACS, destinando-se ao uso
exclusivo do destinatário. Se não for o destinatário
pretendido, não deve usar, distribuir, imprimir ou copiar
este e-mail. Se recebeu esta mensagem por engano, por favor
informe o emissor e elimine-a imediatamente.
Obrigado

*From:*sshark wsk [mailto:sshark...@gmail.com
<mailto:sshark...@gmail.com>]
*Sent:* sábado, 21 de março de 2020 04:17
*To:* sipp-users@lists.sourceforge.net
<mailto:sipp-users@lists.sourceforge.net>
*Subject:* [Sipp-users] ontimeout label does not work - sipp 3.6

Dear Users,

I have sipp version - SIPp
v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM

I have prepared a UAC scenario where

1. User sends SIP registration

2. Gets 401/200 OK and registers

3. Sends INVITE

3. Waits for 100/180/200

4. Sends ACK

5. Pauses for 4s and sends BYE

6. De-register the user

In step 3, I would like to timeout if User B does not answer
(not receiving 200 OK within a certain time) with below



 Unfortunately above does not work

I run SIPp with below flags

./sipp 192.168.1.1 -bind_local -i 10.

Re: [Sipp-users] ontimeout label does not work - sipp 3.6

[Šindelka Pavel]

Hi Sshark,

1. you've indicated a particular version of SIPp; have you done that 
because your scenario did work in previous versions and with this one it 
stopped, or did you just want to provide as much information as possible 
but you actually haven't tried this particular scenario with any 
previous SIPp version?


2. I remember I had some trouble to make ontimeout work in one of the 
older releases (and I haven't changed the scenarios since, so don't read 
it as "and it worked flawlessly in the never ones"), but I cannot 
remember the details (except that even with the |ontimeout| handling 
defined next to the |timeout| specification, a call where a timeout has 
elapsed is always counted as a failed one which is sometimes not 
desirable, but you're not that far yet). So can you try without the 
|| between the || and _response="200" ontimeout="do_something" ... > ? It's not a solution, it 
is a diagnostic step, but I'm afraid this type of setup (optional 
messages and one mandatory one with a timeout specified) may not have 
been addressed in the SIPp code.


3. I hope you don't actually send |REGISTER| and |INVITE| with the same 
|Call-ID| value, as a normal SIP stack would fail on that. This one is 
not related to |ontimeout|, it's related to how SIP itself works.


Pavel


Dne 23.03.2020 v 13:43 sshark wsk napsal(a):

Hi Alberto,

Thank you for your suggestion. I have tried with below flag. However 
still the it does not work



Is it possible to do some debug mode/prints to see why it does not work

BR,
Sshark

On Mon, Mar 23, 2020 at 8:01 PM Alberto Valente 
mailto:alberto-r-vale...@telecom.pt>> 
wrote:


I think you must use something like



Where xx stands for the number of milliseconds you want to
wait for the 200 OK Mresponse

Best regards



*Alberto Valente*
DEO/EFV - Core Network and Service platforms Engineering

+351 963288480 / +351 215000290
alberto.r.vale...@telecom.pt 
Rua Tomás Ribeiro Nº2
1050-229 LISBOA
*altice.pt* 

facebook linkedin
twitter
sapovideos
youtube


AVISO DE CONFIDENCIALIDADE
Esta mensagem e quaisquer ficheiros anexos a ela contêm informação
confidencial, propriedade da Altice Portugal e/ou das demais
sociedades que com ela se encontrem em relação de domínio,
Fundação Altice Portugal e ACS, destinando-se ao uso exclusivo do
destinatário. Se não for o destinatário pretendido, não deve usar,
distribuir, imprimir ou copiar este e-mail. Se recebeu esta
mensagem por engano, por favor informe o emissor e elimine-a
imediatamente.
Obrigado

*From:*sshark wsk [mailto:sshark...@gmail.com
]
*Sent:* sábado, 21 de março de 2020 04:17
*To:* sipp-users@lists.sourceforge.net

*Subject:* [Sipp-users] ontimeout label does not work - sipp 3.6

Dear Users,

I have sipp version - SIPp v3.6-dev-112-g8c0e358-TLS-PCAP-RTPSTREAM

I have prepared a UAC scenario where

1. User sends SIP registration

2. Gets 401/200 OK and registers

3. Sends INVITE

3. Waits for 100/180/200

4. Sends ACK

5. Pauses for 4s and sends BYE

6. De-register the user

In step 3, I would like to timeout if User B does not answer (not



receiving 200 OK within a certain time) with below



 Unfortunately above does not work

I run SIPp with below flags

./sipp 192.168.1.1 -bind_local -i 10.10.10.1 -mp 5 -t u1 -p
5060 -recv_timeout 3200 -sf register_and_call.xml -inf USER_A.csv
-m 1 -trace_msg

Hope you can assist me

Thank You

sshark



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] How to send push notification in Asterisk

[Šindelka Pavel]

I'm not sure how this question is related to SIPp, but in general the softphone 
app needs to request a unique url from the operating system and deliver it to 
the PBX (Asterisk, SIPp) in some form, usually a parameter of the Contact uri 
in the REGISTER request. When handling an incoming call to the mobile device, 
the PBX then has to send a http request to that url, causing a notification 
message to be sent to the mobile device, which makes the OS wake up the 
application; the application should then re-register using SIP to re-drill the 
firewall pinholes so that the incoming INVITE from the PBX could reach it.

From a SIPp scenario, you can spawn a shell command, so generating the HTTP 
request should not be a big deal. From Asterisk, you can invoke an AGI script 
in  doing the same.

P.

Dne 27.12.2019 v 6:42 kumar uppu napsal(a):

HI All

How to send push notification to android app from asterisk PBX

The problem i.e.

when android app gone to background, the not able to get the incoming calls, 
for this need send the push notification to re-register the phone and should 
make call from next


Thanks
--
Kumar




___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Discarding message which can't be mapped to a known SIPp cal when UAS receive INVITE message

[Šindelka Pavel]

scenarios not shown, error message from the UAS not shown, packet capture from 
the UAS side not shown... hard to say what's wrong.

P.

Dne 30.7.2019 v 21:37 Mohanraj S napsal(a):

Hi,

I'm trying to make end to end call in Clearwater IMS environment using SIPp, 
but I'm getting Error “Discarding message which can't be mapped to a known SIPp 
call” on SIPp UAS endpoint for the incoming INVITE from SIPp Client(UAC).
But when i use Jitsi as UAS i'm successful in making end to end call. Could 
someone help here.

UAS Command:
"sipp 34.68.201.203 -sf uas.xml -m 1 -t t1 -trace_msg -trace_err"

UAS Output:
-- Scenario Screen  [1-9]: Change Screen --
Call-rate(length) Port Total-time Total-calls Remote-host
10.0(0 ms)/1.000s 5062 184.33 s 1 34.68.201.203:5060(TCP)

Call limit reached (-m 1), 1.002 s period 1 ms scheduler resolution
1 calls (limit 120) Peak was 1 calls, after 0 s
0 Running, 2 Paused, 3 Woken up
0 dead call msg (discarded) 1 out-of-call msg (discarded)
4 open sockets

 Messages  Retrans   Timeout   Unexpected-Msg
REGISTER --> 1 0 0
 100 <-- 0 0 0 0
 401 <-- 1 0 0 0
REGISTER --> 1 0 0
 100 <-- 0 0 0 0
 200 <-- 1 0 0 0
  INVITE <-- 0 0 0 0

 180 --> 0 0
 200 --> 0 0 0
 ACK <--  E-RTD1 0 0 0 0

 BYE <-- 0 0 0 0
 200 --> 0 0
   Pause [   4000ms] 0 0


--- Waiting for active calls to end. Press [q] again to force exit. ---

Last Error: Discarding message which can't be mapped to a known SIPp cal...

UAC command:
"sipp 34.68.201.203 -sf sippCall.xml -inf sippCall.csv -m 1 -t t1 -trace_msg 
-trace_err"

UAC Output:
-- Scenario Screen  [1-9]: Change Screen --
Call-rate(length) Port Total-time Total-calls Remote-host
10.0(0 ms)/1.000s 5063 34.27 s 1 34.68.201.203:5060(TCP)

Call limit reached (-m 1), 0.000 s period 0 ms scheduler resolution
0 calls (limit 960) Peak was 1 calls, after 0 s
0 Running, 3 Paused, 0 Woken up
0 dead call msg (discarded) 0 out-of-call msg (discarded)
0 open sockets

 Messages  Retrans   Timeout   Unexpected-Msg
REGISTER --> 1 0 0
 100 <-- 0 0 0 0
 401 <-- 1 0 0 0
REGISTER --> 1 0 0
 100 <-- 0 0 0 0
 200 <-- 1 0 0 0
   Pause [   2000ms] 1 0
  INVITE --> 1 0 0
 100 <-- 1 0 0 0
 180 <-- 0 0 0 1
 200 <--  E-RTD1 0 0 0 0

 ACK --> 0 0
  [ NOP ]
   Pause [30.0s] 0 0
 BYE --> 0 0 0
 200 <-- 0 0 0 0


-- Test Terminated 

- Statistics Screen --- [1-9]: Change Screen --
Start Time | 2019-07-30 19:04:11.633714 1564513451.633714
Last Reset Time | 2019-07-30 19:04:45.905139 1564513485.905139
Current Time | 2019-07-30 19:04:45.905300 1564513485.905300
-+---+--
Counter Name | Periodic value | Cumulative value
-+---+--
Elapsed Time | 00:00:00:00 | 00:00:34:271000
Call Rate | 0.000 cps | 0.029 cps
-+---+--
Incoming call created | 0 | 0
OutGoing call created | 0 | 1
Total Call created | | 1
Current Call | 0 |
-+---+--
Successful call | 0 | 0
Failed call | 0 | 1
-+---+--
Response Time 1 | 00:00:00:00 | 00:00:00:00
Call Length | 00:00:00:00 | 00:00:34:153000
-- Test Terminated 

2019-07-30 19:04:45.891481 1564513485.891481: Aborting call on unexpected 
message for Call-Id '1-21223@172.18.0.4': while 
expecting '180' (index 10), received 'SIP/2.0 408 Request Timeout
Via: SIP/2.0/TCP 
172.18.0.4:5063;rport=39243;received=10.16.0.1;branch=z9hG4bK-21223-1-8

Re: [Sipp-users] SIPp IMS registration

[Šindelka Pavel]

http://sipp.sourceforge.net/doc/reference.html#SIP+authentication

P.

Dne 7.5.2019 v 0:41 Kaushik Kumar Acharya napsal(a):
Hello All,
Can we test live IMS network with SIPp? If yes, plz help me with the 
registration script.

Sipp——> REGISTER—>IMS att network
IMS att Network—-401 —-> SIPp
SIPp——-> REGISTER—> IMS att network

In this second REGISTER request how I can send authorization parameters in my 
xml? i mean ‘nonce’ and ‘opaque’ value. I believe these are calculated 
according to the parameters received in the 401 challenge request, but I don’t 
know how to incorporate these params in my xml. Kindly help. I am using SIPp 
after several years.. Plz help


Thanks—-
Kaushik




___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--

Ing. Pavel Šindelka
senior specialista

[cid:part2.1BE735AF.455DAA88@ttc.cz]


TTC MARCONI s. r. o.
Třebohostická 987/5, 100 00  Praha 10
+420 234 051 712, +420 602 355 199
sinde...@ttc.cz, 
www.ttc-marconi.com

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Plug N Play SIPp scenario

[Šindelka Pavel]

Hello,

the only step I'd not be sure of is how the operating system will deal with 
SIPp asking to open a socket on a multicast address. So that's the first thing 
to try. You'll have to assign the multicast address to an  interface first, in 
addition to a unicast one, by means of the operating system. You can only use 
IP addresses which are already up in the system as values of -i and other 
command line parameters of SIPp).

The next issue is that I would assume that the 200 OK response to the SUBSCRIBE 
as well as the NOTIFY have to be sent from, and the 200 OK response to the 
NOTIFY may be expected on, a unicast address of the server. To achieve that, 
you'll need to run two scenarios in parallel, one bound to the multicast 
address and only handling the reception of the SUBSCRIBE and the other one 
bound to the unicast one and handling all the rest.

The scenario bound to the multicast address will expect the SUBSCRIBE to arrive 
and forward all its headers (using the [last-*] keywords) to the other scenario 
by means of . The other scenario will use  and  in 
 to extract from the received inter-scenario message the contents of 
Contact and other headers it needs to use to populate the headers of the NOTIFY 
and of the 200 OK response to the SUBSCRIBE, use  to set the 
destination for the 200 OK response to the subscribe it will send send to the 
socket address extracted from the topmost Via header of the SUBSCRIBE, send the 
200 OK, then use  again to set the destination for the NOTIFY to the 
socket address extracted from the Contact, send the NOTIFY with the necessary 
Content and with Subscription-State set to terminated;reason=noresource to 
properly terminate the dialog initiated by the SUBSCRIBE instead of having to 
handle the unsubscription request coming from the phone, and wait for the 200 
OK response to that NOTIFY from the phone.

The double  may be an overkill in most real life cases, but in general 
the phone may indicate a different socket in the Via (for the response to the 
current request) and in the Contact (for subsequent requests within the same 
dialog).

Also, something is telling me that a scenario decides whether to behave as an 
UAS or UAC depending on whether  or  is the first tag in the file 
even if a  precedes it, so you'll have to put  before the  in the scenario bound to the unicast 
socket to make it act as an UAS one although the optional SUBSCRIBE will 
actually never come.

Pavel


Dne 15.4.2019 v 20:14 Ed Lentz napsal(a):
I am trying to get a PNP server working so I can send a url to my SIP based 
phones.  Here is the sequence that has to happen:

Phone sends a subscribe message to 224.0.1.75
Server sends an OK back to the phone
Server sends a Notify to the phone to check-sync along with the URL
Phone sends back a OK
phone contacts the url address to download the appropriate files.

Is this something SIPp can handle?  If so How would I start?

Thanks

--






___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] AWS EC2 NAT 1:1

[Šindelka Pavel]

If you know the public IP in advance, just use a variable such as [$public_ip] 
instead of [local_ip] everywhere in the scenario (so unless you already use 
custom scenarios, you have to use the -sd command line parameter to dump the 
embedded one(s) into file(s), modify them accordingly and use -sf file_name on 
the command line), and add -set public_ip your.public.ip.address to the command 
line (maybe there has to be a = sign rather than a space between the variable 
name and its value).

Pavel


Dne 2.4.2019 v 23:14 Cyril Constantin napsal(a):
Hi Guys,

I'm trying from an AWS EC2 to generate SIPP calls to a remote server also 
hosted on AWS EC2, the problem is that I only have one internal private IP to 
bind on with SIPP and can't rewrite the SIP headers with -i option to use my 
AWS EC2 public IP.

My remote server reject my INVITE with a 488 Not acceptable here because 
messages come from a public IP but SIP headers contain the internal IP that I 
was using to bind.

AWS EC2 is doing a NAT 1:1 between the public IP and private IP but it's not 
possible to assign an ethernet interface with a public IP.

Do you see a way to achieve it ?

Thanks in advance for your help.

Best Regards




___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--

Ing. Pavel Šindelka
senior specialista

[cid:part2.B27A57D3.8A8FCA40@ttc.cz]


TTC MARCONI s. r. o.
Třebohostická 987/5, 100 00  Praha 10
+420 234 051 712, +420 602 355 199
sinde...@ttc.cz, 
www.ttc-marconi.com

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SDP Parser Error

[Šindelka Pavel]

Unless the formatting got broken as you've copied the SDP here, the blank lines 
between a=maxptime:20 and a=3gOoBTC break the RFC:

"An SDP session description consists of a number of lines of text of the form 
=". A blank line doesn't match such description so is not 
permitted.

Pavel


Dne 25.2.2019 v 13:23 kumar uppu napsal(a):

HI All,

is SDP allow 4 lines spaces in SDP Information,

Here my question is is following sdp is correct or not?

if it not correct may i know the possibilities for getting these type of sdp ?

Following is the SDP information


v=0

o=HuaweiSoftx3000 1084342939 1084342940 IN IP4 10.206.1.40

s=SipCall

c=IN IP4 10.206.1.40

t=0 0

m=audio 41234 RTP/AVP 102 18 8 0 116

a=rtpmap:102 AMR/8000

a=fmtp:102 mode-set=7

a=rtpmap:18 G729/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:116 telephone-event/8000

a=ptime:20

a=maxptime:20

a=3gOoBTC

Thanks

--
Kumar




___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--

Ing. Pavel Šindelka
senior specialista

[cid:part2.C9592146.D408300D@ttc.cz]


TTC MARCONI s. r. o.
Třebohostická 987/5, 100 00  Praha 10
+420 234 051 712, +420 602 355 199
sinde...@ttc.cz, 
www.ttc-marconi.com

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] UAC with auth (Github sipp-samples/uac-auth.xml): SiPp ignores 401

[Šindelka Pavel]

This time the -m 1 is missing on your command line, so sipp sends new "calls" 
(actually, runs the scenario with new Call-ID values) without any limit.

P.

Dne 25.10.2018 v 18:25 Olivier napsal(a):
Thanks Pavel for replying.

Thanks to your advice, I restarted all over, using another Asterisk client 
instance as a guide to a canonical REGISTER dialog.
When I got a successful REGISTER dialog between 2 Asterisk instances, I stopped 
Asterisk on client host and used SIPp instead.
I progressed step by step to the point I saw my Asterisk server replying with a 
200OK to the REGISTER !

I'm very happy with this result but the issue is that this REGISTER dialog is 
repeated many times while I would like to play it only once.
How can I do that ?


SIPp is invoked with:
sipp 192.168.64.46:5062<http://192.168.64.46:5062> -sf 
/home/foobar/my-uac-auth.xml -ap passsipp -s sipp -i 192.168.64.45 -p 5062


My /home/foobar/my-uac-auth.xml
file is now:


  
  


  

  

  
  

  
  

  

  

  
  

  

  




Here is a trace of corresponding REGISTER dialog (captured on Asterisk and 
received on SIPp host):

<--- SIP read from UDP:192.168.64.45:5062<http://192.168.64.45:5062> --->
REGISTER sip:192.168.64.46:5062<http://192.168.64.46:5062> SIP/2.0
Via: SIP/2.0/UDP 192.168.64.45:5062;branch=z9hG4bK-19512-22-0
From: 
mailto:sip%3Asipp@192.168.64.46>>;tag=19512SIPpTag0022
To: mailto:sip%3Asipp@192.168.64.46>>
Call-ID: 22-19512@192.168.64.45<mailto:22-19512@192.168.64.45>
CSeq: 1 REGISTER
Contact: http://sip:s@192.168.64.45:5062>>
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 0

<->
--- (11 headers 0 lines) ---
Sending to 192.168.64.45:5062<http://192.168.64.45:5062> (no NAT)
Sending to 192.168.64.45:5062<http://192.168.64.45:5062> (no NAT)

<--- Transmitting (no NAT) to 192.168.64.45:5062<http://192.168.64.45:5062> --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 
192.168.64.45:5062;branch=z9hG4bK-19512-22-0;received=192.168.64.45
From: 
mailto:sip%3Asipp@192.168.64.46>>;tag=19512SIPpTag0022
To: mailto:sip%3Asipp@192.168.64.46>>;tag=as41ad7250
Call-ID: 22-19512@192.168.64.45<mailto:22-19512@192.168.64.45>
CSeq: 1 REGISTER
Server: Asterisk PBX 13.23.1~dfsg-1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="canonical", nonce="3386ce74"
Content-Length: 0


<>
Scheduling destruction of SIP dialog 
'22-19512@192.168.64.45<mailto:22-19512@192.168.64.45>' in 32000 ms (Method: 
REGISTER)

<--- SIP read from UDP:192.168.64.45:5062<http://192.168.64.45:5062> --->
REGISTER sip:192.168.64.46:5062<http://192.168.64.46:5062> SIP/2.0
Via: SIP/2.0/UDP 192.168.64.45:5062;branch=z9hG4bK-19512-22-3
From: 
mailto:sip%3Asipp@192.168.64.46>>;tag=19512SIPpTag0022
To: mailto:sip%3Asipp@192.168.64.46>>
Call-ID: 22-19512@192.168.64.45<mailto:22-19512@192.168.64.45>
CSeq: 1 REGISTER
Contact: http://sip:s@192.168.64.45:5062>>
Max-Forwards: 70
Authorization: Digest 
username="sipp",realm="canonical",uri="sip:192.168.64.46:5062<http://192.168.64.46:5062>",nonce="3386ce74",response="b0388098db7f3fd69dbd4c8a030d8d28",algorithm=MD5
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 0

<->
--- (12 headers 0 lines) ---
Sending to 192.168.64.45:5062<http://192.168.64.45:5062> (no NAT)

<--- Transmitting (no NAT) to 192.168.64.45:5062<http://192.168.64.45:5062> --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
192.168.64.45:5062;branch=z9hG4bK-19512-22-3;received=192.168.64.45
From: 
mailto:sip%3Asipp@192.168.64.46>>;tag=19512SIPpTag0022
To: mailto:sip%3Asipp@192.168.64.46>>;tag=as41ad7250
Call-ID: 22-19512@192.168.64.45<mailto:22-19512@192.168.64.45>
CSeq: 1 REGISTER
Server: Asterisk PBX 13.23.1~dfsg-1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 120
Contact: http://sip:s@192.168.64.45:5062>>;expires=120
Date: Thu, 25 Oct 2018 16:08:24 GMT
Content-Length: 0



Any clue ?

Le jeu. 25 oct. 2018 à 13:26, Šindelka Pavel 
mailto:sinde...@ttc.cz>> a écrit :
Hi Olivier,

looking at your command line with -m=1 and at the scenario, I suppose that the 
repeated REGISTER requests without the authentication header you can see are 
retransmissions of the initial one, implying that the sipp machine/process does 
not receive the responses from the Asterisk.

This can have a number of reasons:

  *   wrong population of the headers in the messages generated from the 
scenario (should not be the case as you've specified -i on the command line)
  *   routing issue (unlikely unless you've intentionally s

Re: [Sipp-users] UAC with auth (Github sipp-samples/uac-auth.xml): SiPp ignores 401

[Šindelka Pavel]

Hi Olivier,

looking at your command line with -m=1 and at the scenario, I suppose that the 
repeated REGISTER requests without the authentication header you can see are 
retransmissions of the initial one, implying that the sipp machine/process does 
not receive the responses from the Asterisk.

This can have a number of reasons:

  *   wrong population of the headers in the messages generated from the 
scenario (should not be the case as you've specified -i on the command line)
  *   routing issue (unlikely unless you've intentionally split 192.168.64.0/24 
into several subnets or misconfigured the network mask on either machine 
unintentionally)
  *   Asterisk configuration issue (not permitting incoming registrations from 
this address/subnet)
  *   firewall issue on either machine

So SIPp logs, Asterisk logs, and tcpdump/Wireshark are your best friends. See 
whether the REGISTER arrives to the Asterisk, what is its contents, and whether 
the Asterisk responds at all and where it sends the responses.

Pavel

Dne 25.10.2018 v 11:17 Olivier napsal(a):
Hello,

I'm quite new to SIPp.
I've just discovered [1].
I'm testing this uac-auth.xml file with the bellow command against an Asterisk 
instance:

sipp -sf uac-auth.xml 192.168.64.250 -au 7005 -ap 7005 -s 7005 -i 192.168.64.45 
-m 1

I see that Asterisk challenges incoming REGISTER with a WWW-Authenticate but 
SIPp does not reply with any new REGISTER with an Authorization header.
Instead, it keeps sending first REGISTER.

1. Am I correct to expect, with referenced uac-auth.xml, SIPp to send a 
REGISTER with an Authorization header ?

2. If negative, what should be changed to in uac-auth.xml to implement this ? 
If positive, is it correct to expect [authentication] lines in a REGISTER to be 
replaced with an Authorization built with data coming from matching 401 reply 
(nonce, realm, ...) ?

Best regards

[1] https://github.com/rkday/sipp-samples/blob/master/uac-auth.xml





___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Issue using Sipp with Proxy

[Šindelka Pavel]

Not sure I understand what you are doing.

If you really use the embedded scenarios, do you just change the IP address of 
the machine running the UAS script during the execution of the script, and the 
script sends the next packet from the new address? Or you haven't reached that 
point so far, and you are talking about the ACK related to the initial INVITE?

In any case, SIPp running an UAC scenario normally sends to the address on the 
command line and if running an UAS scenario, it responds to the address from 
which the initial request has arrived. It does not automatically respect 
record-route or its absence. If you want to change the remote address during a 
call, you have to use ereg to extract the address from the Contact header in 
the received message and use 
setdest to make SIPp 
use that address as a destination for the subsequent messages in the call. It 
means that to make the ACK be sent to a different destination socket than the 
preceding INVITE, you cannot use the embedded UAC scenario and you have to 
create your own one.

Pavel

Dne 8.10.2018 v 2:57 Julian Kovacek napsal(a):
Hello,

I’m having an issue simulating a scenario from rfc: 
https://tools.ietf.org/html/rfc3665#section-3.7
Were SIPP is Alice(UAC) and Bob(UAS).

The Problem:
My Ack is being sent to the proxy from Alice. It should be sent to Bob from 
Alice.

My Setup:
Version: sipp-3.5.2
uac: sipp 10.2.1.30 -m 1 -sn uac -s 311234567890 -d 5000
uas:  sipp 10.2.1.30  -sn uas

Is there a config or argument I am missing?





___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] sipp: strcmp and log message issue

[Šindelka Pavel]

Well, information from an 8 years old thread may theoretically not be 
accurate any more if someone has "cleaned up" the code in the meantime.


However, as you've checked that it doesn't work even if you use 
|| the documented way with one variable and one constant (value) 
, I'd rather ask myself whether the || can properly handle 
variables of type |double|.


So my next test would be to add, right after the two || statements 
you already have, the following:


|||

||
|
If you don't get |zero=0| or |zero=0.0| or something similar as output, 
I'd think about further comparing the |double| value to a numeric 
constant using the || command and then execute some || with 
embedded || and || conditionally to find out what is the 
root cause - whether the conversion of a |double| value to printable 
text or the || itself.


P.

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] sipp: strcmp and log message issue

[Šindelka Pavel]

First of all, where have you found the |strcmp| syntax with |variable2|? 
The manual for current version (3.4) doesn't mention anything alike and 
says: A *string variable* and a *value* can be compared using the 
|| action.


So I'd first try the following:

|||
|
If this works, it means that || itself works and that || 
can print |double| values properly.


The next step would be

|||
|
If this helps, you're done; if it doesn't, you have to dive into the 
source code.


Pavel

___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Sipp presence implementation

[Šindelka Pavel]

I'm not sure I understand what you are asking for.

A "call" in a scenario actually represents any single SIP dialog, which 
can currently be established using an INVITE and terminated using a BYE, 
or established using a SUBSCRIBE and terminated using another SUBSCRIBE 
or a NOTIFY, or established using a REFER and terminated using a NOTIFY.


The state of each dialog changes independently even if the same UA 
participates in both. So making a SIPp scenario or an actual UA permit 
messages belonging to two independent dialogs affect a state machine 
common for both would not be a good idea as that state machine would 
anyway have to be two in one.


So describe in more detail the expected behavior, there are ways to 
synchronize two dialogs using additional SIPp instances, so that you 
could e.g. initiate a pickup call by sending an INVITE with Replaces 
when you receive a NOTIFY about an incoming call to another UA.


Pavel

Dne 29.6.2018 v 16:11 Mert Metin napsal(a):


Hi,

We try to add presence to our sipp xml’s.

We can send subscribe and receive notify .

When subscriber status has changed one notify message comes to sipp 
different Call-ID with invite.


Different Call-ID’s gives error by sipp. How can we implement 
different Call-ID’s in one call scenario?


We can see that these two message are two different call by sipp.

But we want to run sipp with different two Call-ID in one call scenario.

NOTIFY Call-ID is: 960497191@192.168.134.6 

INVITE Call-ID is: 36ECF_070518_170808_15001_15000@192.168.134.6 



NOTIFY sip:15001@192.168.179.153 
;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.179.153:5060;branch=z9hG4bKfBzr2tL
Max-Forwards: 70
From: >;tag=2a7847d46
To: >;tag=415684934
Contact: >

Call-ID: 960497191@192.168.134.6 
CSeq: 57049 NOTIFY
User-Agent: Sip-Spc v.   t111 d65535
Supported: replaces, timer
Allow: 
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,PRACK,UPDATE,PUBLISH,SUBSCRIBE

Event: dialog
Subscription-State:active
Content-Type: application/dialog-info+xml
Content-Length: 208


state='full'entity='sip:15000@192.168.179.153 
'>


confirmed







INVITE sip:15001@192.168.134.6 
;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.179.153:5060;branch=z9hG4bKW37cJ1p
Max-Forwards: 70
From: >;tag=896c33429

To: mailto:sip%3A15001@192.168.134.6>>
Contact: >
Call-ID: 36ECF_070518_170808_15001_15000@192.168.134.6 


CSeq: 125930 INVITE
Session-Expires: 300;refresher=uac
Min-SE: 90
User-Agent: Sip-Spc v.  t47 d49
Supported: replaces, 100rel, timer
Allow: 
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,PRACK,UPDATE,PUBLISH,SUBSCRIBE

Alert-Info:;info=Internal
Content-Type: application/sdp
Content-Length: 341

v=0
o=SIP 1439163165 1439163294 IN IP4 192.168.179.59
s=Phone-Call
c=IN IP4 192.168.179.59
t=0 0
m=audio 11796 RTP/AVP 0 8 18 9 101 
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:30
a=sendrecv


Best Regards,

Mert METİN


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIPp TCP with source port of 5060

[Šindelka Pavel]

You've answered to yourself, TCP connections are session-based so the 
client always uses an "ephemeral" port which is chosen dynamicaly by the 
TCP stack of the OS. So depending on what you actually need to achieve, 
it might be an option to set the port information in the scenario 
manually to 5060 (in Via etc.) and use netfilter (iptables) to src-nat 
the sent packets' source address and port to those you want (10.249.130.10:

5060)

But bear in mind that it will be possible to establish only one such TCP 
session per remote socket address, as when a TCP session ends, there is 
a guard time during which any packet coming from the same socket address 
at client side is ignored by the server.


Pavel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Unable to send G729 packets using SIPP UAS

[Šindelka Pavel]

To replay a previously captured RTP stream in SIPp, you have to use 
pcap_play_audio. Only packets belonging to the stream must be present in 
the pcap file replay, so in Wireshark, you must apply a display filter 
to display only packets belonging to that stream out of the original 
capture (such as rtp.ssid == 0x12345678), and then use File -> Export 
Specified Packets -> Displayed to save these packets to a new pcap file.


Wireshark does not look at the payload of the RTP, only to payload type 
number, so the payload may actually be G.729 but if the payload type 
number says it is PCMA, Wireshark will display it as such. Try the 
Wireshark RTP player - if you can hear the original audio, the payload 
type number and the actual payload match each other, otherwise they don't.


P.

Dne 21.4.2018 v 10:10 hema...@advaitamtech.com napsal(a):


Hello All,

I wanted to send G729 encoded RTP packets from my SIPP UAS, I tried it 
by putting only the g729 nedia attribute in the SDP of 200 OK and by 
sending G729 encoded files. I did encoding using below methods.


1) By downloading a PCM wav file and converting to .g729 file using 
online tool


2) By using my G729 support Voip Client and capturing the RTP packets 
whicg is G729 encoded.


I tried sending above files, Both cases SIPP UAS sending it as PCMA 
encoded RTP packets only, When i verified it in wireshark capture


SIPP software version i am using is 3.4.1,

Can you please help to send G729 encoded RTP packets from my SIPP UAS

Thanks & Regards

Hemanth



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Wireshark - SIPp - .pcapng

[Šindelka Pavel]

Not sure what exactly you are asking.

You can use play_pcap_audio to replay a single RTP stream. The .pcap 
file to be played must not contain anything else but that stream. SIPp 
then changes the source and destination addresses and ports according to 
actual values used locally (from auto-media-port in the scenario and 
from the mi command line parameter) but keeps the rest (ssrc, sequence 
numbers) unchanged.


So to replicate a failed call scenario based on a pcap, you have to

- use a display filter which shows only that single RTP stream and use 
"export selected packets -> displayed" to save them into a new .pcap 
file which you would then use for play_pcap_audio,


- use a display filter like "sip.Call-ID==your_call-id" to show only 
messages belonging to the SIP dialog in question and use "export 
selected packets -> displayed" to save them into another new .pcap(ng) file


- disable the SIP dissector, set Wireshark to display non-dissected data 
as text and run tshark from command line:


tshark.exe -r your_single_SIP_dialog_file_name.pcapng -T fields -e 
data.text > your_file_name.txt


to extract the SIP conversation from the pcap(ng) file into a text form 
(switching on "display SIP text" in SIP preferences doesn't currently 
work well with tshark)


- edit your_file_name.txt to add the XML tags around the messages to 
convert it into a SIPp scenario file


Pavel


Dne 11.4.2018 v 13:59 Franklin Angulo napsal(a):


Hi. I am using SIPp to create test scenarios that simulate real SIP 
communication scenarios between server and client that have generated 
errors when installing a real VoIP system. I have a capture .pcapng of 
Wireshark and I want that based on this capture I can generate a SIP 
scene with which I can perform my tests in the laboratory with my SIP 
phone or the server depending on the case that occurs. What I do first 
is convert the .pcapng to .pcap format to include the .pcap in the 
statement  . My 
scenario is:


IP Phone IP Server

IP Phone Invite ---> IP Server
IP Phone <- 100 IP Server
IP Phone <- 407 IP Server
IP Phone ACK ---> IP Server
IP Phone Invite ---> IP Server
IP Phone <- 100 IP Server
IP Phone <- 180 IP Server
IP Phone < RTP (G711U)
IP Phone <- 200 OK SDP G711U IP Server
IP Phone <- 180 IP Server
IP Phone Cancel ---> IP Server
IP Phone <- 481 Call IP Server
IP Phone ACK ---> IP Server
IP Phone <- 200 OK SDP G711U IP Server
IP Phone <- By IP Server

Is it possible to generate this scenario with the audio and the SIP / 
SDP that the .pcapng file from Wireshark gives me, having compiled the 
SIPp with ./configure --with-pcap or does it have to add another module?


Thank you very much for the information!

Carefully greetings,

Franklin



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIP/2.0 503 Service Unavailable

[Šindelka Pavel]

I've asked you to send me the pcap file, not the result of its 
processing by cloudshark, but even this way I can see that there is a 
blank space between the "sip:201081@" and "ims.com". No wonder that 
the server goes crazy since what it gets on the INVITE line is not a 
valid SIP uri.


Check To and From for the same issue.

P.

Dne 20.3.2018 v 13:42 Sunil Kumar napsal(a):

more-

2364
	273.582105 	10.224.61.13 	10.224.61.22 	SIP 	1245 	Request: REGISTER 
sip:ims.com <http://ims.com> (1 binding) |

2365
	273.596708 	10.224.61.22 	10.224.61.13 	SIP 	925 	Status: 200 OK (1 
binding) |

2402
	280.504694 	10.224.61.13 	10.224.61.22 	SIP/SDP 	2264 	Request: 
INVITE sip:201081@ ims.com <http://ims.com> |

2404
280.506174  10.224.61.2210.224.61.13SIP 414 Status: 
100 Trying |
2406
	280.563608 	10.224.61.22 	10.224.61.13 	SIP 	703 	*Status: 503 
Service Unavailable |*

2463
	291.567453  	10.224.61.13 	10.224.61.22 	SIP 	1127 
Request: REGISTER sip: ims.com <http://ims.com> (1 binding) |

2465
	291.636028  	10.224.61.22 	10.224.61.13 	SIP 	574 
Status: 401 Unauthorized |

2467
	291.636427  	10.224.61.13 	10.224.61.22 	SIP 	1245 
Request: REGISTER sip: ims.com <http://ims.com> (1 binding) |

2469
	291.654531  	10.224.61.22 	10.224.61.13 	SIP 	925 
Status: 200 OK (1 binding) |






Frame 2406: 703 bytes on wire (5624 bits), 703 bytes captured (5624 bits)
Ethernet II, Src: PcsCompu_ff:d2:88 (08:00:27:ff:d2:88), Dst: 
PcsCompu_ab:71:0f (08:00:27:ab:71:0f)

Internet Protocol Version 4, Src: 10.224.61.22, Dst: 10.224.61.13
Transmission Control Protocol, Src Port: rlm-admin (5054), Dst Port: 
34312 (34312), Seq: 349, Ack: 2199, Len: 637

Session Initiation Protocol (503)


On Tue, Mar 20, 2018 at 6:06 PM, Sunil Kumar <skgola1...@gmail.com 
<mailto:skgola1...@gmail.com>> wrote:


Thanks pavel,
I used cloudshark now i am able to see the sip. It showing the -
status: 401 unauthorized

29  
2.29950010.224.61.1310.224.61.22SIP 1123Request:
REGISTER sip:ims.com <http://ims.com> (1 binding) |
34  
2.31458410.224.61.1310.224.61.22SIP 1123Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
39  
2.32356910.224.61.1310.224.61.22SIP 1123Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
41  
2.33286910.224.61.2210.224.61.13SIP 570 Status: 
401
Unauthorized |
43  
2.33325810.224.61.1310.224.61.22SIP 1241Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
47  
2.33551710.224.61.1310.224.61.22SIP 1123Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
49  
2.33878010.224.61.2210.224.61.13SIP 570 Status: 
401
Unauthorized |
51  
2.33916510.224.61.1310.224.61.22SIP 1241Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
52  
2.34436710.224.61.2210.224.61.13SIP 570 Status: 
401
Unauthorized |



so what i need to do to fix this issue.

On Tue, Mar 20, 2018 at 5:30 PM, Šindelka Pavel <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>> wrote:

Show me all the parameters you start sipp with, and send me
the file. tcpdump won't show you that SIP is inside the IP
packets unless you add some other command line options. That's
why I've told you to open the file using Wireshark. You can
use cloudshark.org <http://cloudshark.org> if you don't want
to install Wireshark locally.

P.

Dne 20.3.2018 v 12:46 Sunil Kumar napsal(a):

Hi pavel,
Thanks again. I tried tcpdump in parallel but there is no SIP
i found all are IP, STP, ARP etc.

*[]ubuntu@stress:~$ sudo tcpdump -i eth0 -s 0 -w 0007.pcap*

following i used to read the .pcap file-
    *sudo tcpdump -r 0006.pcap*

thanks,
sunil

On Tue, Mar 20, 2018 at 4:13 PM, Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>> wrote:

Sunil,

the exact command would be

tcpdump -i interface_name -s 0 -w
/tmp/some_file_name.pcap port x.y.z

where:

- interface_name is the name of the interface through
which the machine running sipp communicates with the
machine where the server sending the 503 is running; if
both run at the same machine, the interface name would be lo

- /tmp/some_file_name.pcap is the name of the resulting file

- xyz is the tcp or udp port at which the server is
listening.

  

Re: [Sipp-users] SIP/2.0 503 Service Unavailable

[Šindelka Pavel]

Show me all the parameters you start sipp with, and send me the file. 
tcpdump won't show you that SIP is inside the IP packets unless you add 
some other command line options. That's why I've told you to open the 
file using Wireshark. You can use cloudshark.org if you don't want to 
install Wireshark locally.


P.

Dne 20.3.2018 v 12:46 Sunil Kumar napsal(a):

Hi pavel,
Thanks again. I tried tcpdump in parallel but there is no SIP i found 
all are IP, STP, ARP etc.


*[]ubuntu@stress:~$ sudo tcpdump -i eth0 -s 0 -w 0007.pcap*

following i used to read the .pcap file-
*sudo tcpdump -r 0006.pcap*

thanks,
sunil

On Tue, Mar 20, 2018 at 4:13 PM, Šindelka Pavel <sinde...@ttc.cz 
<mailto:sinde...@ttc.cz>> wrote:


Sunil,

the exact command would be

tcpdump -i interface_name -s 0 -w /tmp/some_file_name.pcap port x.y.z

where:

- interface_name is the name of the interface through which the
machine running sipp communicates with the machine where the
server sending the 503 is running; if both run at the same
machine, the interface name would be lo

- /tmp/some_file_name.pcap is the name of the resulting file

- xyz is the tcp or udp port at which the server is listening.

The typical reason why a server would send 503 is that it has some
serious problem, either with your message (such as when you send a
message using a TCP transport and indicate an UDP Via), or it has
some internal problem which is not related to the received message
in particular. The server logs should tell you more but those log
messages you've sent were not related.

Pavel


Dne 20.3.2018 v 10:07 Sunil Kumar napsal(a):

Thanks for replying. What is the main cause of  of 503 service
unavailable according to you. What is exact command for tcpdump.


On Tue, Mar 20, 2018 at 2:14 PM, Sunil Kumar
<skgola1...@gmail.com <mailto:skgola1...@gmail.com>> wrote:

Hi Pavel,
Thanks for replying. I am using project clearwater, in which
i am doing stress testing which is using SIPp basically. But
when i am running that command all calls are failing giving
503 error, can you provide some solution regarding that.

here i am trying 100 call 5 min is duration and this is going
to *sprout node. *ims.com <http://ims.com> is my home domain
*[]ubuntu@stress:~$ sudo /usr/share/clearwater/bin/run_stress
ims.com <http://ims.com> 100 5*
[sudo] password for ubuntu:
Starting initial registration, will take 1 seconds
Initial registration succeeded
Starting test
Test complete

Elapsed time: 00:04:36
Start: 2018-03-20 21:37:12.980619
End: 2018-03-20 21:42:01.082712 

Total calls: 5
Successful calls: 0 (0.0%)
Failed calls: 5 (100.0%)
Unfinished calls: 0

Retransmissions: 0

Average time from INVITE to 180 Ringing: 0.0ms
# of calls with 0-2ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 2-10ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 10-20ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 20-50ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 50-100ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 100-200ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 200-500ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 500-1000ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 1000-2000ms from INVITE to 180 Ringing: 0 (0.0%)
# of calls with 2000+ms from INVITE to 180 Ringing: 0 (0.0%)
Failed: call success rate 0.0% is lower than target 100.0%!

Total re-REGISTERs: 16
Successful re-REGISTERs: 16 (100.0%)
Failed re-REGISTERS: 0 (0.0%)

REGISTER retransmissions: 0

Average time from REGISTER to 200 OK: 52.0ms

Log files at /var/log/clearwater-sip-stress/26840_*


*
*
sprout node log:
*[sprout]ubuntu@sprout:/var/log/sprout$ tail -50
sprout_current.txt*


--end msg--
20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
uri_classifier.cpp:139: home domain: false, local_to_node:
true, is_gruu: false, enforce_user_phone: false, prefer_sip:
true, treat_number_as_phone: false
20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
uri_classifier.cpp:172: Classified URI as 3
20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
common_sip_processing.cpp:180: Skipping SAS logging for
OPTIONS request
20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
thread_dispatcher.cpp:554: Recieved message 0x7f32a422b620 on
worker thread
20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
thread_dispatcher.cpp:571: Admitted request 0x7f32a422b620 on
worker thread

Re: [Sipp-users] SIP/2.0 503 Service Unavailable

[Šindelka Pavel]

OPTIONS/cseq=683401 (rdata0x7f32a406b528)
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
uri_classifier.cpp:139: home domain: false, local_to_node: true,
is_gruu: false, enforce_user_phone: false, prefer_sip: true,
treat_number_as_phone: false
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
uri_classifier.cpp:172: Classified URI as 3
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug pjsip:     
 endpoint Response msg 200/OPTIONS/cseq=683401
(tdta0x7f333c2de180) created
20-03-2018 16:07:52.719 UTC [7f32e0770700] Verbose
common_sip_processing.cpp:103: TX 282 bytes Response msg
200/OPTIONS/cseq=683401 (tdta0x7f333c2de180) to TCP
10.224.61.22:46000 <http://10.224.61.22:46000>:
--start msg--

SIP/2.0 200 OK
Via: SIP/2.0/TCP
10.224.61.22;rport=46000;received=10.224.61.22;branch=z9hG4bK-683401
Call-ID: poll-sip-683401
From: "poll-sip" <sip:poll-sip@10.224.61.22
<mailto:sip%3Apoll-sip@10.224.61.22>>;tag=683401
To: <sip:poll-sip@10.224.61.22
<mailto:sip%3Apoll-sip@10.224.61.22>>;tag=z9hG4bK-683401
CSeq: 683401 OPTIONS
Content-Length:  0


--end msg--
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
common_sip_processing.cpp:275: Skipping SAS logging for OPTIONS
response
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug pjsip:
tdta0x7f333c2d Destroying txdata Response msg
200/OPTIONS/cseq=683401 (tdta0x7f333c2de180)
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
thread_dispatcher.cpp:270: Worker thread completed processing
message 0x7f32a406b528
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
thread_dispatcher.cpp:284: Request latency = 220us
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
event_statistic_accumulator.cpp:32: Accumulate 220 for 0x2a0b778
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
event_statistic_accumulator.cpp:32: Accumulate 220 for 0x2a0b7f0
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
load_monitor.cpp:341: Not recalculating rate as we haven't
processed 20 requests yet (only 3).
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug utils.cpp:878:
Removed IOHook 0x7f32e076fe30 to stack. There are now 0 hooks
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
thread_dispatcher.cpp:158: Attempting to process queue element
20-03-2018 16:07:54.720 UTC [7f32aa704700] Verbose pjsip:
tcps0x7f32a422 TCP connection closed
20-03-2018 16:07:54.720 UTC [7f32aa704700] Debug
connection_tracker.cpp:67: Connection 0x7f32a422b2e8 has been
destroyed
20-03-2018 16:07:54.720 UTC [7f32aa704700] Verbose pjsip:
tcps0x7f32a422 TCP transport destroyed with reason 70016: End of
file (PJ_EEOF)
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip:   
tcplis:5052 TCP listener 10.224.61.22:5052
<http://10.224.61.22:5052>: got incoming TCP connection from
10.224.61.8:40825 <http://10.224.61.8:40825>, sock=442
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip:
tcps0x7f32a422 tcp->base.local_name: 10.224.61.22
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip:
tcps0x7f32a422 TCP server transport created
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip:
tcps0x7f32a42b TCP connection closed
20-03-2018 16:07:56.623 UTC [7f32aa704700] Debug
connection_tracker.cpp:67: Connection 0x7f32a42bc998 has been
destroyed
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip:
tcps0x7f32a42b TCP transport destroyed with reason 70016: End of
file (PJ_EEOF)


On Tue, Mar 20, 2018 at 1:55 PM, Šindelka Pavel <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>> wrote:

Hi Sunil,


Please give some solution.


Please give some information.

From what you have sent so far it is clear that the 503 is
coming from some UAS which I guess is not another SIPp
instance running an UAS script. So either your UAC script in
SIPp is sending something that makes that UAS go crazy, or
that UAS has some problem irrelevant to SIPp at all.

Pavel


Dne 20.3.2018 v 9:12 Sunil Kumar napsal(a):

Hi team sipp,
I am getting SIP/2.0 503 Service Unavailable. Please give
some solution.

*[]ubuntu@stress:/var/log/clearwater-sip-stress$ cat
21491_caller_errors.log*
sipp: The following events occured:
2018-03-20      19:13:22.256018 1521553402.256018: Aborting
call on unexpected message for Call-Id '1-21501@1  27.0.1.1':
while expecting '183' (index 2), received 'SIP/2.0 503
Service Unavailable
Via: SIP/2.0/TCP
127.0.1.1:41238;received=10.224.61.13;branch=z9hG4bK-21501-1-0
Record-Route: http://scscf.sprout.ims.com>;transport=TCP;lr;billing-role=charge-term>
Record-Route: http://ims.com>
;transport=TCP;lr;

Re: [Sipp-users] SIP/2.0 503 Service Unavailable

[Šindelka Pavel]

K
Via: SIP/2.0/TCP 
10.224.61.22;rport=46000;received=10.224.61.22;branch=z9hG4bK-683401

Call-ID: poll-sip-683401
From: "poll-sip" <sip:poll-sip@10.224.61.22 
<mailto:sip%3Apoll-sip@10.224.61.22>>;tag=683401
To: <sip:poll-sip@10.224.61.22 
<mailto:sip%3Apoll-sip@10.224.61.22>>;tag=z9hG4bK-683401

CSeq: 683401 OPTIONS
Content-Length:  0


--end msg--
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug 
common_sip_processing.cpp:275: Skipping SAS logging for OPTIONS response
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug pjsip: tdta0x7f333c2d 
Destroying txdata Response msg 200/OPTIONS/cseq=683401 
(tdta0x7f333c2de180)
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug 
thread_dispatcher.cpp:270: Worker thread completed processing message 
0x7f32a406b528
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug 
thread_dispatcher.cpp:284: Request latency = 220us
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug 
event_statistic_accumulator.cpp:32: Accumulate 220 for 0x2a0b778
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug 
event_statistic_accumulator.cpp:32: Accumulate 220 for 0x2a0b7f0
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug load_monitor.cpp:341: 
Not recalculating rate as we haven't processed 20 requests yet (only 3).
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug utils.cpp:878: 
Removed IOHook 0x7f32e076fe30 to stack. There are now 0 hooks
20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug 
thread_dispatcher.cpp:158: Attempting to process queue element
20-03-2018 16:07:54.720 UTC [7f32aa704700] Verbose pjsip: 
tcps0x7f32a422 TCP connection closed
20-03-2018 16:07:54.720 UTC [7f32aa704700] Debug 
connection_tracker.cpp:67: Connection 0x7f32a422b2e8 has been destroyed
20-03-2018 16:07:54.720 UTC [7f32aa704700] Verbose pjsip: 
tcps0x7f32a422 TCP transport destroyed with reason 70016: End of file 
(PJ_EEOF)
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip:    
tcplis:5052 TCP listener 10.224.61.22:5052 <http://10.224.61.22:5052>: 
got incoming TCP connection from 10.224.61.8:40825 
<http://10.224.61.8:40825>, sock=442
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: 
tcps0x7f32a422 tcp->base.local_name: 10.224.61.22
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: 
tcps0x7f32a422 TCP server transport created
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: 
tcps0x7f32a42b TCP connection closed
20-03-2018 16:07:56.623 UTC [7f32aa704700] Debug 
connection_tracker.cpp:67: Connection 0x7f32a42bc998 has been destroyed
20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: 
tcps0x7f32a42b TCP transport destroyed with reason 70016: End of file 
(PJ_EEOF)



On Tue, Mar 20, 2018 at 1:55 PM, Šindelka Pavel <sinde...@ttc.cz 
<mailto:sinde...@ttc.cz>> wrote:


Hi Sunil,


Please give some solution.


Please give some information.

From what you have sent so far it is clear that the 503 is coming
from some UAS which I guess is not another SIPp instance running
an UAS script. So either your UAC script in SIPp is sending
something that makes that UAS go crazy, or that UAS has some
problem irrelevant to SIPp at all.

Pavel


Dne 20.3.2018 v 9:12 Sunil Kumar napsal(a):

Hi team sipp,
I am getting SIP/2.0 503 Service Unavailable. Please give some
solution.

*[]ubuntu@stress:/var/log/clearwater-sip-stress$ cat
21491_caller_errors.log*
sipp: The following events occured:
2018-03-20      19:13:22.256018 1521553402.256018: Aborting call
on unexpected message for Call-Id '1-21501@1          27.0.1.1':
while expecting '183' (index 2), received 'SIP/2.0 503 Service
Unavailable
Via: SIP/2.0/TCP 127.0.1.1:41238;received=10.224.61.13
;branch=z9hG4bK-21501-1-0
Record-Route: http://scscf.sprout.ims.com>;transport=TCP;lr;billing-role=charge-term>
Record-Route: http://ims.com>
;transport=TCP;lr;billing-role=charge-orig>
Call-ID: 1-21501@127.0.1.1 <mailto:1-21501@127.0.1.1>
From: <sip:201012@ ims.com <http://ims.com> >;tag=21501SIPpTag001
To: <sip:201045@ ims.com <http://ims.com>
>;tag=z9hG4bKPjKAqRQhSEDZfI8vg52uWhPdLZWlb4.o7s
CSeq: 1 INVITE
P-Charging-Vector: icid-value="21501SIPpTag001";orig-ioi= ims.com
<http://ims.com> ;term-ioi= ims.com <http://ims.com>
P-Charging-Function-Addresses: ccf=0.0.0.0
Content-Length:  0



Thanks,
Sunil



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users
<https://lists.sourceforge.net/lists/listinfo/sipp-user

Re: [Sipp-users] SIPp to Test Opensips Load balancer

[Šindelka Pavel]

I think  that the invite request is looping within the load balancer 
script.
Almost correct. You don't need to wait for the 483 to make that 
conclusion, it is enough to watch the INVITE going back and forth 
between 192.168.100.21 and 192.168.100.17 (and get bigger and bigger, as 
each new pass through any of the two processes, the LB and proxy, adds 
another Via header, plus each pass through the proxy adds another P-hint 
header). So the problem is not a loop within the load balancer but the 
fact that the proxy returns the INVITE back to the load balancer instead 
of sending it to the server (the UAS in your case).


The point is that the request-uri (as well as the To-uri) contains an IP 
address of the LB, which would rarely be the case in real life 
deployment, and that the proxy following the LB ini the chain is not 
configured accordingly.


So the LB, when handling the INVITE, properly routes it to the proxy but 
does not change the request-uri. The proxy then routes the INVITE 
according to the unchanged request-uri which means that it sends it back 
to the LB.


In real life deployment, you would have an fqdn in the request-uri, and 
the LB and the proxy would route the request based on some local 
policies but would not change the request-uri as there would be no need 
to do so.


In the load balancer, the local policy is the load balancing 
configuration itself, where addresses of next hops (in your case, the 
proxies) are written, and you can see by the capture that it works - the 
INVITE is forwarded to the IP:port of the proxy.


In the proxy, the local policy may consist in translation of the 
request-uri fqdn using a standard DNS resolution, or there may be an own 
configuration table responsible for that. In the former case, both 
proxies would forward the request to the same IP unless the DNS would 
provide a different individual response to each of them.


So change the request-uri in the UAC script to some fqdn (like 
my.sipserver.lan) and find out how to make the proxy translate that name 
into the IP address and port of the UAS script.


In another words, nothing related to SIPp ;-)

P.


Dne 21.2.2018 v 16:43 Mayur Koshal napsal(a):

Hi Pavel,

Attached is the pcap file with invite request,  and also the uac 
message log. These logs were taken with probing off.
The previous logs were taken with probing mode on(2) and thats why  
could not see invite request.


In these logs I can see Too many hops reply and I think that the 
invite request is looping within the load balancer script.


Regards
Mayur


On Wed, Feb 21, 2018 at 12:09 AM, Šindelka Pavel <sinde...@ttc.cz 
<mailto:sinde...@ttc.cz>> wrote:


The .pcap file you've attached shows just a single OPTIONS request
responded with 484, no INVITE or any other SIP message in it, so
hard to say whether something in the INVITE was wrong or not. The
script seems fine to me at first glance. Bear in mind that SIPp
itself is not very sensitive about the contents of the messages so
there may be an error in some header which the SIPp UAS does not
analyze, so the fact that the UAS script is happy with what it
receives directly from the UAC script does not mean that the UAC
script has formed the INVITE properly.

The opensips LB description doesn't seem to require a registration
of the calling user as a pre-requisite for forwarding of an
INVITE, so the behaviour cannot be explained by a missing
Service-Route header in the INVITE.

So try to capture with better settings so that the INVITE from the
SIPp script is visible in it. If it looks fine, the rest must be
the configuration of the opensips LB.

P.


Dne 20.2.2018 v 19:10 Mayur Koshal napsal(a):

Hi Pavel,

Thanks for your reply and sorry for the delayed response.


I have tried the setup as below :

*UAC(192.168.100.21:5065)---LB (192.168.100.21:5060)--SIP
Proxy (192.168.100.17:5060)UAS(192.168.100.17:5080
<http://192.168.100.17:5080>)
*
sipp commands used :

.*/sipp -sf uac_mod.xml 192.168.100.21:5060
<http://192.168.100.21:5060> -s archana -i 192.168.100.21 -p 5065
-r 1 -rp 1000 -m 10

./sipp -sf uas_mod_orig.xml -rsa 192.168.100.21:5060
<http://192.168.100.21:5060> -i 192.168.100.17 -p 5080*
*
*
where I have registered user archana in the SIP proxy server .

I am running 1 instance of sipp (UAC) in the machine with LB and
UAS in the machine with SIP Proxy.

But I was not successful and got the error message as address
incomplete.
It goes to the load balancer script where it load balances but it
says address incomplete and does not move forward.

Not able to figure out where the problem is ? Request your help
as do not know where I am going wrong ?

The wireshark logs as well as the uas and uac xmls are attached.

The Opensips LB Logs are as below where destina

Re: [Sipp-users] SIPp to Test Opensips Load balancer

[Šindelka Pavel]

Well, as for me, the load balancer stands there to hide from the 
individual clients the topology of the core network and to spread evenly 
the load between them. I know nothing at all about OpenSips LB in 
particular, but a normal SBC does not need to know the individual user 
accounts in advance - when it sees the first REGISTER, it chooses the 
right core machine according to its load distribution rules, and 
remembers that assignment if the REGISTER is successful. And if an 
INVITE comes from the same user, it re-uses the association. If we talk 
about "trunk" peers which do not register, then the core machine is 
chosen individually for each new dialog (on UDP) or each new TCP session 
(on TCP).


So in your example scenario, I would run a single UAC scenario talking 
to the LB, and as many UAS scenarios as you have proxies. In case of two 
core machines and even call distribution and UDP, you should end up with 
2 N calls at the UAC and N calls at each UAS. With TCP, all the UAC 
calls may end at the same UAS if the "single-TCP-session-for-all-calls" 
mode is used at UAC SIPp side, or again 1:1 share on both UAS if 
"new-TCP-session-for-each-call" mode is used.


P.


Dne 15.1.2018 v 18:24 Mayur Koshal napsal(a):

Hi All,


I am using sipp to run performance of the Opensips proxy server.

My setup is as :
*
UAC(192.168.100.19:5065)--Opensips Proxy 
Server(192.168.100.187:5060)UAS(192.168.100.187:5080 
)

*

I have registered a user Mayur@192.168.100.187:5080 
 in the Opensips using 
./opensipsctl ul add command.



UAC  command : ./sipp -sf uac.xml 192.168.100.187:5060 
 -s Mayur -i 192.168.100.19 -p 5065 -m 10
UAS  command : ./sipp -sf uas.xml -rsa 192.168.100.187:5060 
 -i 192.168.100.187 -p 5080 -m 10


I have been able to successfully run the setup and test the 
performance of opensips.(Thanks to Pavel for resolving the issues 
which I faced.)




*Now I have introduced a load balancer in between UAC and Opensips 
proxy server like :*



*UAC(192.168.100.19:5065 )  Opensips 
LB(192.168.100.19:5060)
--  Opensips Proxy 
Server(192.168.100.187:5060)UAS(192.168.100.187:5080 
)*



The load balancer forwards the incoming request to the proxy server as 
it is configured in the load balancer table.


*My Ques are :

1) Should I add the user in the load balancer or Opensips Proxy server ?

2) How will the UAC and UAS commands look like in this case of load 
balancing. I am somehow not able to figure out.




Request your help and suggestion for the sipp configuration to be used 
for testing the load balancer setup. I have tried some but did 
not succeed.*



Thanks

Regards
Mayur


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIPp audio local

[Šindelka Pavel]

is there a possibility to capture the RTP stream while the client and 
server are on the same IP?

That's not really a SIPp question, but nevertheless:

 * first, make sure the two instances off SIPp use different port
   ranges for the RTP.
 * next:
 o if you run SIPp on linux, you can run one instance of tcpdump
   with -i eth0 or what your network interface name is to capture
   the communication with the external machine, and another
   instance of tcpdump with -i lo to capture the RTP running
   between the two SIPp instances. Or you can install Wireshark and
   run a single instance of dumpcap or tshark with several -i
   options (or choose several interfaces if running a GUI Wireshark).
 o if you run SIPp on Windows, you may have tough time. Normally,
   there is no visible "lo" interface in Windows, but you can
   install npcap and during the installation choose the option to
   create the lo. However, I am not sure how Wireshark will behave
   if you have WinPcap and npcap installed simultaneously, and SIPp
   needs WinPcap to replay pcap files which contain RTP packets. I
   haven't tried yet whether npcap installed in WinPcap-compatible
   mode can substitute WinPcap in this role.

Pavel

Dne 15.1.2018 v 14:49 Pedro Oliveira Silva napsal(a):


Hello,

I have a problem that I was wondering if you could help me with.

I have a SIPp scenario with one SIPp in client mode sending SIP to an 
Application Server that then sends to another SIPp in server mode. 
Client and Server SIPp are on the same machine while the Application 
Server is on another machine.


Besides SIP I’m also sending an RTP stream so that I can also test the 
audio.


The problem is that since the Client and Server are on the same 
machine I haven’t been able to capture the RTP stream. If I put either 
the client or the server on another machine I can correctly capture 
the RTP stream.


To send the RTP stream I’m using “” 
and to capture the traffic I’m using tshark.


Has any of you ever tried this or is there a possibility to capture 
the RTP stream while the client and server are on the same IP?


Thanks in advance.

/Best Regards,/

/Pedro Oliveira Silva./



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Sending INVITE to multiple servers

[Šindelka Pavel]

Do you have in mind sending the very same INVITE to different 
destinations (as a forking proxy would do) or just talking to several 
remote servers from the same scenario but sending only its own call to 
each of them?


In any case, look at the setdest 
in the manual. 
If forking is your goal, you'll have tough time handling the responses.


P.


Dne 28.12.2017 v 17:40 Kusai Mansawala via Sipp-users napsal(a):

Hi,

I have just started using SIP-P. I need your help in a scenario where 
I need to send INVITE requests to multiple users or softphones or 
servers at a time. Any help in this scenario would be appreciable.


Thank You in advance




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Modifying variables values

[Šindelka Pavel]

Hi Wilmar,

if you need to create the do while loop in each call, it is more or less 
simple:



 
  
 





  
   
   
  


... the cycle body ...

 



... continuation after the cycle ...

If you wanted something else, elaborate.

P.

Dne 26.11.2017 v 23:55 Wilmar Pérez via Sipp-users napsal(a):

Hi all,

I am trying to understand if I can create a scenario that allows me to 
auto-increment a doubles type variable. It would be similar to a /for 
/or /do... while /loop. If not, I guess I'd need to play with 
something external (e.g. python) to run the scenario with different 
values.


Thank you!

Wilmar


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Help

[Šindelka Pavel]

At a quick overview on a smartphone, two points:

1) the To: tag in your ACK is constant so it cannot mirror the value assigned 
by the opposite party. Hence the opposite party cannot map the message to the 
dialog, so it repeats the 200 as required when no ACK is received.

2) if you want SIPp to send RTP, you have to put a corresponding statement to 
your scenario, it does not happen automatically.

Pavel

Dne 28. 11. 2017 19:51 napsal uživatel gdcarvalh...@gmail.com:

Folks,

I'm making a test on a IVR Machine from a softphone installed on my workstation 
(10.0.4.147 = my workstation / 10.0.8.67 = IVR). Here is the result of 
Wireshark:

[cid:image001.png@01D3685F.DC1175F0]

[cid:image002.png@01D36860.257B8F00]



I did the same test from SIPP to IVR and I used the scenario below:















































  

  

  



  



  

  



  

  



  

  



  

  

  

  

  



  

  

  



  



  

  



  



  

  



  

  



  

  







The result of this second test is just below:

[cid:image003.png@01D36866.AE2612C0]





[cid:image004.png@01D36867.D80B8470]



The problem is that when I make the call through the softphone, the ura is 
sending the RTP to me soon after the 183 (as print below). This is correct 
behavior.

[cid:image005.png@01D36867.D80B8470]



But when I am making the call through SIPP the same is not occurring and I get 
the BYE upon receipt of several 200.

[cid:image006.png@01D36867.D80B8470]



Is there anything wrong with this scenario? Please help me.

Thanks in advance for your help and attention.

Best regards.











--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] UAS that responds with same codec(s) as in incoming SDP offer

[Šindelka Pavel]

Hi Andreas,

I was doing something remotely similar in the past. My approach to your 
case would roughly be the following:


- use one || per payload type number position in the |m=| line to 
extract the payload type numbers into dedicated variables, something like


|||
||  ||
||    search_in="msg" assign_to="dummy,codec_1"/>||
||    search_in="msg" assign_to="dummy,codec_2"/>||
||    search_in="msg" assign_to="dummy,dummy_2,codec_3"/>||
||    search_in="msg" assign_to="dummy,dummy_2,codec_4"/>||

||    ...||
||  ||

|

||

- use conditional commands to compose the SDP answer in a variable, 
first appending the payload type numbers to the end of the |m=| line and 
then appending the |a=rtpmap| lines for that codec, something like



 
  
 



 
  
 



 
  
 


...

Next, you need to search through your composed |m=| line, and provide 
the appropriate |a=| lines for each known payload type number, something 
like


|||
|| ||
||  ||
|||  assign_to="is_pcmu"||
|||  assign_to="is_pcma"
||  assign_to="is_g729"

|| ||
||
|

|| ||
||  ||


||
||
||
|| ||
||  ||


||


|| ||
||  ||


||
  
The above should work but does not take into account dynamic payload 
types (and even payload type numbers below 96 can be used for dynamic 
assignment).


Bear in mind that the variable |[$a_lines]| has a line break at its end 
unless it is completely empty, so the next line of your SDP must follow 
it directly:


|v=0||
||o=ccs-0-275-2 02722940331338705 331338705 IN IP[local_ip_type] 
[local_ip]||

||s=SIP Call||
||c=IN IP[media_ip_type] [media_ip]||
||t=0 0||
||[$m_line]||
||[$a_lines]||a=sendrecv||
|
Happy debugging, I haven't tested anything. Remarks:

- if the |"[ $]"| construct does not work in regexp matching against a 
variable, you may have to compose the |m=| line with a space in the end 
first, then parse it for known codecs with plain |" "| instead of the 
|"[ $]"|, and finally trim the last |" "|.

- it is possible that |\r\n| can be used instead of |\x0d\x0a|.
- if you want to silently drop unexpected payload type numbers, you have 
to change the regexps parsing the received |m=| line, replace the last 
|([0-9]+)| by a |-separated list of known payload type numbers, such as 
|(0|8|18|101)|. Doing so adds complexity as you have to handle the 
possibility of ending up with empty |[$a_lines]| (which you have to test 
for and append |"\x0d\x0a"| if it happens) and if you want to test 
things like codec order in SDP answer different from the one in the SDP 
offer.


Pavel



Dne 13.11.2017 v 2:21 Andreas Byström (Polystar) napsal(a):


Hi

Has someone ever created a UAS script that respond with the same 
codec(s) as the incoming INVITE SDP offer?


The scripts I have used I usually create the 200 OK using something 
like this:




  

Re: [Sipp-users] UAS that responds with same codec(s) as in incoming SDP offer

[Šindelka Pavel]

Luis,

there are multiple issues with providing a wide static codec list in an 
SDP answer.


First, an SDP answer may only narrow the codec list received in an SDP 
offer, not extend it. So the SDP answer should not contain any codec 
which wasn't present in the SDP offer.


Second, for sending the RTP, each endpoint should use the codec most 
preferred by the remote party, so if the most preferred codec in the 
answer differs from the most preferred codec in the offer, you'll end up 
with


- either different codec to be used in each direction of the session,

- or a re-INVITE from the remote party with a new SDP offer containing 
just a single codec so that you had no choice => you have to foresee one 
extra re-INVITE in your scenario plus we get back to point 1.


Pavel


Dne 13.11.2017 v 13:19 Luis Rojas G. napsal(a):

Hello,

I don't know the answer to your question, but why are you answering 
200 OK with only one codec? You have the problem of updating the UAS 
script every time you change codec in phone because of that.
Why don't you program several codecs in UAS, so anytime you change in 
phone is to one of the already supported codecs? it will not be an 
"unlimited number of payload types", but at least a bigger set.


Best regards,

Luis

in On 11/12/2017 10:21 PM, Andreas Byström (Polystar) wrote:


Hi

Has someone ever created a UAS script that respond with the same 
codec(s) as the incoming INVITE SDP offer?


The scripts I have used I usually create the 200 OK using something 
like this:




  

Re: [Sipp-users] Add record route to a response

[Šindelka Pavel]

Not sure I got what you mean by "across", English is not my native 
language. If you have in mind that A and B are both local subscribers of 
CUCM and the call between them has to pass through CUCM, then to do 
this, you need much more complex scenarios than the embedded ones. In 
particular you need that both register in one thread (a "call" in SIPp 
terminology), and then A them initiates a session in another thread, 
while B is ready to accept it.


If this is the case: to implement this, you need conditional execution 
at UAC side (to take a different branch of the scenario depending on 
call number) and an auxiliary timer instance of SIPp at the UAS side, as 
the UAS needs to receive an impulse from outside to start a thread. So 
while the INVITE-awaiting branch of the scenario is a regular one, the 
REGISTER-sending one is triggered by receiving a SIPp inter-instance 
command.


I have described this here in deeper detail several times in the past. 
Maybe you could start from this message 
<https://sourceforge.net/p/sipp/mailman/message/34707334/>.


If it is not the case, e.g. if A or B or both are trunk peers, please 
provide a rough flow diagram of what your scenario should look like, 
similar to the following one, and indicate which elements should be 
replaced by SIPp scenarios and whether they are trunk peers or 
registering subscribers. And consider whether we should continue on the 
mailing list or whether to move away from there.


|A proxy B||
|||--- INVITE --->|   |
|   |--- INVITE --->|
:   :   :
|   |<--- 200 --|
|<--- 200 --|   |
:   :   :
|- ACK >|
:   :   :
|

P.

Dne 8.11.2017 v 17:47 Marco Menozzi napsal(a):

Have you ever tried across a Cisco CUCM ?

Marco

2017-11-08 17:23 GMT+01:00 Šindelka Pavel <sinde...@ttc.cz 
<mailto:sinde...@ttc.cz>>:


Yes, provided that you bind each instance to a different port on
the loopback interface (127.0.0.1). This is relevant for UDP, for
TCP the client will choose an ephemeral port for establishing
connection so it won't conflict, but there are other caveats.

Pavel Šindelka

Dne 8. 11. 2017 5:18 odpoledne napsal uživatel Marco Menozzi
<mmenozz...@gmail.com <mailto:mmenozz...@gmail.com>>:

Understood.

Is it possible to perform it running uac.xml and uas.xml from
same laptop ?

Marco

2017-11-08 17:17 GMT+01:00 Šindelka Pavel <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>>:

In your scenario, sipp running uas.xml replaces the B
party and sipp running uac.xml replaces the A party.

Depending on which of the parties you want to simulate or
whether you want to simulate both, you need to run one or
two instances of sipp and to choose the uas /uac behaviour
for it/them.

The embedded uac.xml will not send the BYE to an IP
address  extracted from any uri received in a response
unless you explicitly tell it to do so and point it to a
particular uri from which it should extract the address.
Similarly, the embedded uas scenario will send the
response to BYE to the same IP from which it has got the
initial INVITE, even if the BYE comes from another one,
unless you explicitly ask it to do do.

Omlouvám se za stručnost, píšu z mobilu.

Pavel Šindelka

Dne 8. 11. 2017 4:49 odpoledne napsal uživatel Marco
Menozzi <mmenozz...@gmail.com <mailto:mmenozz...@gmail.com>>:

Hi

thanks for your feedback.

the purpose is to reproduce a situation where

A calls B

B answer to A without Contact Header and with Record
Route set.

My questions is: would it be enough to use uas.xml
script to reproduce the above or I need to also
trigger a uac.xml too ?

Marco

2017-11-08 16:29 GMT+01:00 Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>>:

Can you be more specific regarding for which of
the following steps you need assistance?

1) run the sipp binary with a single command line
parameter |-sd uas| , thus asking it to dump the
embedded uas.xml to stdout while redirecting
stdout to file my_uas.xml:

|sipp -sd uas > my_uas.xml|

2) edit |my_uas.xml| the required way (remove
|Contact:..|, add |Record-Route:...|)

3) run sip

Re: [Sipp-users] Add record route to a response

[Šindelka Pavel]

Yes, provided that you bind each instance to a different port on the loopback 
interface (127.0.0.1). This is relevant for UDP, for TCP the client will choose 
an ephemeral port for establishing connection so it won't conflict, but there 
are other caveats.

Pavel Šindelka

Dne 8. 11. 2017 5:18 odpoledne napsal uživatel Marco Menozzi 
<mmenozz...@gmail.com>:
Understood.

Is it possible to perform it running uac.xml and uas.xml from same laptop ?

Marco

2017-11-08 17:17 GMT+01:00 Šindelka Pavel 
<sinde...@ttc.cz<mailto:sinde...@ttc.cz>>:
In your scenario, sipp running uas.xml replaces the B party and sipp running 
uac.xml replaces the A party.

Depending on which of the parties you want to simulate or whether you want to 
simulate both, you need to run one or two instances of sipp and to choose the 
uas /uac behaviour for it/them.

The embedded uac.xml will not send the BYE to an IP address  extracted from any 
uri received in a response unless you explicitly tell it to do so and point it 
to a particular uri from which it should extract the address. Similarly, the 
embedded uas scenario will send the response to BYE to the same IP from which 
it has got the initial INVITE, even if the BYE comes from another one, unless 
you explicitly ask it to do do.

Omlouvám se za stručnost, píšu z mobilu.

Pavel Šindelka

Dne 8. 11. 2017 4:49 odpoledne napsal uživatel Marco Menozzi 
<mmenozz...@gmail.com<mailto:mmenozz...@gmail.com>>:
Hi

thanks for your feedback.

the purpose is to reproduce a situation where

A calls B

B answer to A without Contact Header and with Record Route set.

My questions is: would it be enough to use uas.xml script to reproduce the 
above or I need to also trigger a uac.xml too ?

Marco

2017-11-08 16:29 GMT+01:00 Šindelka Pavel 
<sinde...@ttc.cz<mailto:sinde...@ttc.cz>>:

Can you be more specific regarding for which of the following steps you need 
assistance?

1) run the sipp binary with a single command line parameter -sd uas , thus 
asking it to dump the embedded uas.xml to stdout while redirecting stdout to 
file my_uas.xml:

sipp -sd uas > my_uas.xml

2) edit my_uas.xml the required way (remove Contact:.., add Record-Route:...)

3) run sipp with all the command line parameters you use normally plus -sf 
my_uas.xml , thus telling it to run your modified UAS scenario rather than the 
embedded one

?

P.

Dne 7.11.2017 v 13:15 Marco Menozzi napsal(a):
Hi

sorry but I'm pretty new with scripting with this tool.

I would need to reproduce a scenario where sipp is used to answer a phone call, 
removing Contact Header and adding a Record Route field with option "lr" (loose 
routing).

A calls B (sipp) . B answers with 180 ringing without Contact Header and adding 
Record Route .

I thought to manipulate uas.xml script to perform that but I don't know how to 
perform the action above.

thanks

cheers
Marco




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Add record route to a response

[Šindelka Pavel]

In your scenario, sipp running uas.xml replaces the B party and sipp running 
uac.xml replaces the A party.

Depending on which of the parties you want to simulate or whether you want to 
simulate both, you need to run one or two instances of sipp and to choose the 
uas /uac behaviour for it/them.

The embedded uac.xml will not send the BYE to an IP address  extracted from any 
uri received in a response unless you explicitly tell it to do so and point it 
to a particular uri from which it should extract the address. Similarly, the 
embedded uas scenario will send the response to BYE to the same IP from which 
it has got the initial INVITE, even if the BYE comes from another one, unless 
you explicitly ask it to do do.

Omlouvám se za stručnost, píšu z mobilu.

Pavel Šindelka

Dne 8. 11. 2017 4:49 odpoledne napsal uživatel Marco Menozzi 
<mmenozz...@gmail.com>:
Hi

thanks for your feedback.

the purpose is to reproduce a situation where

A calls B

B answer to A without Contact Header and with Record Route set.

My questions is: would it be enough to use uas.xml script to reproduce the 
above or I need to also trigger a uac.xml too ?

Marco

2017-11-08 16:29 GMT+01:00 Šindelka Pavel 
<sinde...@ttc.cz<mailto:sinde...@ttc.cz>>:

Can you be more specific regarding for which of the following steps you need 
assistance?

1) run the sipp binary with a single command line parameter -sd uas , thus 
asking it to dump the embedded uas.xml to stdout while redirecting stdout to 
file my_uas.xml:

sipp -sd uas > my_uas.xml

2) edit my_uas.xml the required way (remove Contact:.., add Record-Route:...)

3) run sipp with all the command line parameters you use normally plus -sf 
my_uas.xml , thus telling it to run your modified UAS scenario rather than the 
embedded one

?

P.

Dne 7.11.2017 v 13:15 Marco Menozzi napsal(a):
Hi

sorry but I'm pretty new with scripting with this tool.

I would need to reproduce a scenario where sipp is used to answer a phone call, 
removing Contact Header and adding a Record Route field with option "lr" (loose 
routing).

A calls B (sipp) . B answers with 180 ringing without Contact Header and adding 
Record Route .

I thought to manipulate uas.xml script to perform that but I don't know how to 
perform the action above.

thanks

cheers
Marco




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Add record route to a response

[Šindelka Pavel]

Can you be more specific regarding for which of the following steps you 
need assistance?


1) run the sipp binary with a single command line parameter |-sd uas| , 
thus asking it to dump the embedded uas.xml to stdout while redirecting 
stdout to file my_uas.xml:


|sipp -sd uas > my_uas.xml|

2) edit |my_uas.xml| the required way (remove |Contact:..|, add 
|Record-Route:...|)


3) run sipp with all the command line parameters you use normally plus 
|-sf my_uas.xml| , thus telling it to run your modified UAS scenario 
rather than the embedded one


?

P.

Dne 7.11.2017 v 13:15 Marco Menozzi napsal(a):

Hi

sorry but I'm pretty new with scripting with this tool.

I would need to reproduce a scenario where sipp is used to answer a 
phone call, removing Contact Header and adding a Record Route field 
with option "lr" (loose routing).


A calls B (sipp) . B answers with 180 ringing without Contact Header 
and adding Record Route .


I thought to manipulate uas.xml script to perform that but I don't 
know how to perform the action above.


thanks

cheers
Marco



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Fwd: Non standard headers

[Šindelka Pavel]

Hi Wilmar,

SIPp has been created as a test tool so non-standard headers do work in 
terms that you can send them and parse them using . I'm not sure 
whether the [last_*] construct works with them, though.


P.


Dne 4.11.2017 v 15:10 Wilmar Pérez via Sipp-users napsal(a):

Hello all,

I am just wondering if I can work with non standard headers within 
SIPp scenarios. I have not been able to find any information so far.


Thank you,

Wilmar



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Fwd: XML Body content.

[Šindelka Pavel]

Hi Wilmar,

at least there must be a blank line between the last SIP header and the 
beginning of the content (RFC3261).


Second, I am not sure whether the fact that you have a different number 
of spaces in front of headers up to Contact and in front of headers from 
Allow on may not confuse SIPp too.


Given that my SIPp 3.2 drops any number of spaces in the beginning of a 
content line, it may not be the case, but maybe the handling of leading 
spaces differs between header lines and content lines.


P.


Dne 4.11.2017 v 15:10 Wilmar Pérez via Sipp-users napsal(a):

Hi all,

I am trying to insert some XML body content in my scenarios but I have 
not been able to format them properly. I figure I may need to escape 
them but how? I have tried the obvious without much success.  This is 
an example:



--

    
  
---

And this is what I get when I run it:

Images intégrées 1

What am I doing wrong?

Thanks in advance for your comments.

Best regards,

Wilmar





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] Supported encapsulation type

[Šindelka Pavel]

Hard to say without the original file and the command line you've used to run editcap. 
P.
Omlouvám se za stručnost, píšu z mobilu.
Pavel Šindelka
Dne 6. 10. 2016 10:53 odpoledne napsal uživatel Andy Chen :Hi,I have a SIPP platform that's setup to add members to a conference platform and then play a pcap file.  I used Wireshark to create a pcap file with RTP codec type of G.722.  I noticed the first time when I ran it, I got the error stating something about "unsupported link-type of 0".  Then I used this tool editcap to set it to Ethernet link-type but now I got this error message:







Unsupported ethernet type 15889.I'm currently at a loss on how to get this pcap file to work with my sipp configuration.Any advice would be appreciated.Thanks.--Andy--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] UAS and variables

[Šindelka Pavel]

Hi Michael, 
three possibilities:
* a typo in one of the occurrences (not applicable if you have copy-pasted all occurrences here) 
* an invisible character in one of the occurrences due to some joke of your text editor (delete all of them including their surrounding "" or [] and type then again) 
* a missing /, > or " somewhere else in the scenario (remove all three lines and run the scenario without them) 
Other than that, you do not need the References statement at all since you both capture the variable and use it, which makes more than a single occurrence.
Pavel Šindelka
Dne 29. 9. 2016 12:01 dopoledne napsal uživatel "Herman, Michael" :




I am working on setting up testing between two SIPP servers, one as the UAC and one as the UAS. We use some non-standard headers that I want the UAS to capture and use in subsequent responses. In my receive block, I have added 





After the receive block, I have added 


Cisco-Gucid: [$ciscogucid]


When I run this scenario, I receive an error, "2016-09-28
13:17:07.855907 
1475086627.855907: Variable $ciscogucid is referenced 1 times!”


Any ideas why?


Thanks.





--

Michael Herman
Senior
 Principal Architect, Telephony

michael.herman@asurion.com      

voice (615) 445-3345  mobile (615) 473-7793

Asurion I 648
 Grassmere Park Nashville, TN 37211
www.asurion.com | Twitter | Facebook












This message (including any attachments) contains confidential and/or privileged information. It is intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, please notify the sender immediately and delete
 this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

--
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users

Re: [Sipp-users] SIPP RTP echo both Video and Audio

[Šindelka Pavel]

Can you paste here the SDP you have used in your scenario file? And does the Cisco thing send an SDP offer in its INVITE or does it expect one from the UAS?
Pavel
Dne 2. 9. 2016 6:47 PM napsal uživatel Morgan CHARPENTIER :







Hello,
 
I’m trying to set a SIPp UAS in order to answer SIP calls from a Cisco Callbridge and replicate both video and audio.
It works for audio but not for Video
 
Sipp is launched with
./sipp –sn uas –rtp_echo –mp 32768
 
From what I can see with tcpdump during a call :
-I Well see a rtp flow on UDP 32768 but I also see callbridge initiating UDP packets to 32769. SIPP server answer with an port unreachable icmp packet. I assume 32769 is RTCP and not necessarily implemented on Sipp. So 32768 UDP should
 embed both video and audio or video capability is not advertised to the Callbridge.
 
Is there a configuration to be done on SIPp UAS in order to echo both audio and video flows ?
 
Thanks much for your help.
 
Regards
Morgan
 


--
___
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users