Hello ,
has anyone any experience on testing SER with SIPP ??
I've sent the following mail to sipp-users mailing list, I'm sending it also here, in case anyone has any idea or experience.
---------------------------------------------------------------------------------------------------- Hello all,
I run the basic UAC senario in Host A (1.1.1.1) and the basic UAS senario in Host B (2.2.2.2). I have a SER SIP Proxy in the middle (3.3.3.3).
UAC : ./sipp -sn uac -r 1 -m 1 -d 5000 -i 1.1.1.1 3.3.3.3
UAS : ./sipp -sn uas
SER.cfg :
I use the following hack in ser.cfg, because the default user 'service' is not actually registered in Location DB.
# In INVITE handler .. ...
# --- SIPP hack --- if (uri =~ "^sip:service@3.3.3.3:5060") { rewritehostport("2.2.2.2:5060"); route(1); break; }; # -----------------
# In MAIN Route Block # --------------------- Nothing changed from 'default SER behaviour' :
if ((method != "REGISTER") && (method != "OPTIONS")) { log(1, " Add RR"); record_route(); };
if (loose_route()) { route(1); break; };
Where is the problem : It seems that SER doesn't recognize (in the dialog) the ACK sent by the UAC (Host A), do does not relay it to the UAS. The UAS continues to send '200 OK'... so I can't make it to have a 'full call setup simulation senario'.
Call Flow :
HOST A (UAC) SER HOST B (UAS) -----------> (1) INVITE <----------- (2) 100 Trying --------------> (3) INVITE <------------- (4) 180 Ringing <----------- (5) 180 Ringing <------------- (6) 200 OK <----------- (7) 200 OK -----------> (8) ACK
<------------- (9) 200 OK -----------> (10) ACK .... ....
The first ACK (8) from UAC to SER doesn't relayed to UAS, so UAS keeps sending '200 OK'...
This ACK doesn't go through the 'loose_route()' block because SER thinks that this ACK is not in the dialog. Even if I add the following code in MAIN route block, SER insists to absorb this ACK request. ... } else if (method == "ACK") { # ACK mesgs --> route[1] log(1," * ACK -- not in the DIALOG --"); route(1); break; } else if ...
Do you find something wrong in SER conf ? or do you have any idea why this happening ?
----------------------------------------------------------------------------------------------------
thanks in advance for any hint.
Kostas
Hi kostas,
add a some users and add some static usrloc entries (serctl add 123 password foo@bar.com && serctl ul add 123 sip:123@sipp-ip:port)
and edit the uac scenario file, change everywhere it says [service] to 123
Run sipp and be happy. Sipp will now use the user 123 instead of your hack.
-A
(Ps. Or you can go advanced, and compile sipp with tls support, and also add registration and unregestering to the sipp scenario file)
* Kostas Marneris K.Marneris@otenet.gr [060921 14:48]:
Hello ,
has anyone any experience on testing SER with SIPP ??
I've sent the following mail to sipp-users mailing list, I'm sending it also here, in case anyone has any idea or experience.
Hello all,
I run the basic UAC senario in Host A (1.1.1.1) and the basic UAS senario in Host B (2.2.2.2). I have a SER SIP Proxy in the middle (3.3.3.3).
UAC : ./sipp -sn uac -r 1 -m 1 -d 5000 -i 1.1.1.1 3.3.3.3
UAS : ./sipp -sn uas
SER.cfg :
I use the following hack in ser.cfg, because the default user 'service' is not actually registered in Location DB.
# In INVITE handler .. ...
# --- SIPP hack --- if (uri =~ "^sip:service@3.3.3.3:5060") { rewritehostport("2.2.2.2:5060"); route(1); break; }; # -----------------
# In MAIN Route Block # --------------------- Nothing changed from 'default SER behaviour' :
if ((method != "REGISTER") && (method != "OPTIONS")) { log(1, " Add RR"); record_route(); }; if (loose_route()) { route(1); break; };
Where is the problem : It seems that SER doesn't recognize (in the dialog) the ACK sent by the UAC (Host A), do does not relay it to the UAS. The UAS continues to send '200 OK'... so I can't make it to have a 'full call setup simulation senario'.
Call Flow :
HOST A (UAC) SER HOST B (UAS) -----------> (1) INVITE <----------- (2) 100 Trying --------------> (3) INVITE <------------- (4) 180 Ringing <----------- (5) 180 Ringing <------------- (6) 200 OK <----------- (7) 200 OK -----------> (8) ACK
<------------- (9) 200 OK -----------> (10) ACK
.... ....
The first ACK (8) from UAC to SER doesn't relayed to UAS, so UAS keeps sending '200 OK'...
This ACK doesn't go through the 'loose_route()' block because SER thinks that this ACK is not in the dialog. Even if I add the following code in MAIN route block, SER insists to absorb this ACK request. ... } else if (method == "ACK") { # ACK mesgs --> route[1] log(1," * ACK -- not in the DIALOG --"); route(1); break; } else if ...
Do you find something wrong in SER conf ? or do you have any idea why this happening ?
thanks in advance for any hint.
Kostas _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers