Hello, this is exactly what I was trying to do, but what I do not know how to manage is the authentication mechanism to keep the authentication between all scenarios. How can the authentication details (nonce ...) be kept? If this works for you, could you send me or point me to som simple scenario? I ask for this, because I previously tried to register first and then the INVITE. Unfortunamtely I got the Unauthorized message which is why I tried the REGISTER-INVITE scenario.
Also, could this be caused by old SIPp version? For me the sipp -v reports SIPp v3.1, version unknown, built Mar 27 2010, 20:07:37. BTW, Interesting is this is officially accepted scenario. Best regards Lukas > ------------ Původní zpráva ------------ > Od: Jeanne Clément <c.jea...@astellia.com> > Předmět: RE: [Sipp-users] Authentication mechanism in sipp > Datum: 23.7.2010 11:50:01 > ---------------------------------------- > The message "2010-07-23 10:43:10: Discarding message which can't be mapped to > a > known SIPp call" sounds familiar to me but it's old. > You should investigate this way: > SIPp has a limitation; it's unable to handle 2 different call-id in the same > call. Therefore it's not possible to register (use one call-id) then wait for > an > incoming INVITE (which come with another call-id). > > What I do for the users receiving the INVITE is to use two scenarios : one for > registering and on for standing by awaiting incoming calls. I register all my > users with the first one and when it's over, I launch the second one. > > Hope this help > > Regards > > Clément JEANNE. > > Stagiaire R&D. > > > > Astellia > > Tel.: +33 (0)2 99 04 80 60 > > Visit our web site: www.astellia.com > > > -----Message d'origine----- > De : Oliva Lukáš [mailto:p...@seznam.cz] > Envoyé : vendredi 23 juillet 2010 11:02 > À : Jeanne Clément > Cc : sipp-users@lists.sourceforge.net > Objet : RE: [Sipp-users] Authentication mechanism in sipp > > Hello, > thanks for fast response. I was interested in running REGISTER and INVITE > session as tow separate tests which is why I was interested in authentication > mechanism. > > > Hi, I don't understand very well what you mean. > > The nonce used when you deRegister is not supposed to be the same the one > used > > in Register. I don't understand how you manage to do that... When you > > deregister, your OpenIMS core should send you a new 401 containing a new > nonce > > (to avoid replay attack). > > Considering the replay atack you are right. I was just following the SIP > software I know which uses simplified scenario for DeREGISTER, but the one you > propose is correct and works. > > > The scenario here > > > http://sipp.sourceforge.net/wiki/index.php/Howto_test_on_Open_Source_IMS_platform_using_SIPp > > works with OpenIMS very well. > > For the mentionned xml file, I tried to use it for my experimental openimscore > installation and I have serious problems with not accepted INVITE on the > terminating side of sipp. It seems that terminating sipp does not recognize > INVITE as valid initial INVITE for the conversation. > > Please check pcap files from the test recorded on CSCF machine, sipp > scenarios I > used, error and message list and the openimscore configuration files as > reference. > > My OpenIMSCore configuration consists: > - collocated CSCF roles on 22.101.1.32 (P - port 4060, I - port 5060, S - > port > 6060) > - FHoSS together with DNS server on 22.101.1.33 > - machine from which load sipp was executed 22.101.1.34 on ports 5060, 5061 > All the machines have fresh installed Debian Linux. The DNS was verified to > work, firewall is switched off. > The sipp binary is version 3.1 selfcompiled with auth support, tls support and > gsl. > > The test was intended to register and run The test was executed with following > lines: > sipp-auth-tls-gsl -sf register-invite_bob-orig-server.xml 22.101.1.32:4060 -i > 22.101.1.34 -p 5060 -t u1 -trace_err -trace_msg -m 1 > sipp-auth-tls-gsl -sf register-invite_bob-orig.xml 22.101.1.32:4060 -i > 22.101.1.34 -p 5061 -t u1 -trace_err -trace_msg -m 1 > > During the test, REGISTERs were okay, but the for the INVITE part, I got this > message on the terminating side: > 2010-07-23 10:43:10: Discarding message which can't be mapped to a known SIPp > call > > you can find the details in attached _errors file. > > While I checked togehter with my colleagues the SIP packets in pcap files and > did not find anything strange (excluding to some OpenIMSCore specialities like > received part in Via in INVITE), I address now to you for help. > > For completeness, following lines were reported in openimscore logfiles: > > ==> /var/log/OpenIMSCore/pcscf.log <== > 2(28161) >> Orig_Initial > 4(28163) >> Orig_Initial_reply > 1(28160) >> Term_Initial > > ==> /var/log/OpenIMSCore/scscf.log <== > 1(27645) >> Orig > 3(27647) >> Term > 4(27648) >> Orig_reply > 3(27647) >> Term_reply > 48 > ==> /var/log/OpenIMSCore/pcscf.log <== > 5(28164) >> Term_Initial_failure > 1(28160) >> Orig_Initial_reply > 1(28160) >> Orig_Initial_failure > > ==> /var/log/OpenIMSCore/scscf.log <== > 4(27648) >> Term_reply > 4(27648) >> Orig_reply > > > Best regards > Lukas > > > > Regards > > > > Clément JEANNE. > > > > Stagiaire R&D. > > > > > > > > Astellia > > > > Tel.: +33 (0)2 99 04 80 60 > > > > Visit our web site: www.astellia.com > > > > > > -----Message d'origine----- > > De : Oliva Lukáš [mailto:p...@seznam.cz] > > Envoyé : mercredi 21 juillet 2010 13:18 > > À : sipp-users@lists.sourceforge.net > > Objet : [Sipp-users] Authentication mechanism in sipp > > > > Hello, > > I try to build basic scenarios with the sipp tool to verify some basic > > functionality of OpenIMSCore (previously SIP Express Router), so I started > with > > Register - DeRegister. While I was able to REGISTER successfully (as for the > > callflow and what FHoSS reported), I am unable to use results of previous > > authentication (from 2 REGISTER). I tried to use [authenticate user= ... > > password= ...] once more, but the nonce count is then again 0000001 which > seems > > to result in 471 Unauthorized. > > My question therefore is, is there a mechanism how to include correct > > authorization header with right (increased) value of Nonce Count (nc)? > > > > For reference, please see my scenario: > > > > UE -> PCSCF > > > > REGISTER -> > > <- 471 > > REGISTER -> > > <- 200 OK > > > > <pause 5000 ms> > > > > REGISTER (Expires = 0) -> > > <- 200 OK > > > > The attached source files are based on example source files from openimscore > > site. > > > > Best regards > > > > Lukas > > > > > > Astellia celebrates its 10th anniversary in 2010 > > 10 years of innovation and client proximity > > > > Ce message et tout document joint sont confidentiels et à l'intention > exclusive > > des destinataires. > > S'ils vous ont été adressés par erreur, merci d'en informer immédiatement > > l'expéditeur et de les détruire. > > Toute copie, diffusion ou utilisation non autorisée est interdite. Tout > message > > électronique est susceptible d'altération : Astellia décline toute > > responsabilité si le message ou les documents joints ont subi une quelconque > > modification. > > > > This message and any attachment are confidential and intended solely to its > > addressees. > > If you are not the intended recipient please cancel it and inform > > immediately > > the sender. > > Any unauthorised copy or dissemination is prohibited. Electronic messages > > may > be > > altered: Astellia shall not be liable for those circumstances. > > > > > > > > Astellia celebrates its 10th anniversary in 2010 > 10 years of innovation and client proximity > > Ce message et tout document joint sont confidentiels et à l'intention > exclusive > des destinataires. > S'ils vous ont été adressés par erreur, merci d'en informer immédiatement > l'expéditeur et de les détruire. > Toute copie, diffusion ou utilisation non autorisée est interdite. Tout > message > électronique est susceptible d'altération : Astellia décline toute > responsabilité si le message ou les documents joints ont subi une quelconque > modification. > > This message and any attachment are confidential and intended solely to its > addressees. > If you are not the intended recipient please cancel it and inform immediately > the sender. > Any unauthorised copy or dissemination is prohibited. Electronic messages may > be > altered: Astellia shall not be liable for those circumstances. > > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
