22 Sep
2006
22 Sep
'06
7:51 a.m.
thanks for your help, but in this case (the commands you propose)
the signalling traffic does not pass through SER at all.
I can always test 2 boxes (one running UAC, the other running UAS)
using the default XML files.
If I use the following (in case you had a typo error) :
UAS:
./sipp -sn uas -rsa 2.2.2.2
UAC:
./sipp -sn uac 3.3.3.3 -r 1 -m 1 -d 5000 -i 1.1.1.1 -rsa 2.2.2.2
then in this case the traffic goes through SER but I have the same problem.
==> ACK is absorbed by SER and does not RELAYED to UAS.
thank you anyway,
Kostas
Verbeiren, David wrote:
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.
This may not be exactly what you want to test but I've done tests with
SIPp and various SIP proxies, SER being one of them, by targeting the
UAS itself on the SIPp command line but with a "remote sending address"
parameter specifying the proxy to use. This works great and does not
require the 'service' user to be known to SER as it simply looks at the
hostname (or ip address) part of the URI to proxy the call.
This gives the following modified command lines:
UAC :
./sipp -sn uac 2.2.2.2 -r 1 -m 1 -d 5000 -i 1.1.1.1 -rsa 3.3.3.3
UAS :
./sipp -sn uas -rsa 3.3.3.3
The remote sending address is similar to the "outbound proxy" parameter
found on many SIP phones.
This way of running SIPp gives the call flow you describe but shortcuts
most of the ser.cfg routing logic as uri!=myself.
Regards,
-David
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers