Hi Henning/Karsten, Thanks so much for your feedback.
@Henning - you’re right, I’ve misunderstood the purpose of cseq_diff. Thanks for pointing that out, I’ve removed that reference! I’ve done a debug and privatised a few values (IPs, phone numbers, passwords, etc): https://0bin.net/paste/yjXiQF4-IO7HSRvE#xdrfRXGjGG0TOA6VYV0iy49IuOSUFuMghz7cyUK1fhO <https://0bin.net/paste/yjXiQF4-IO7HSRvE#xdrfRXGjGG0TOA6VYV0iy49IuOSUFuMghz7cyUK1fhO> Flow of the call: A (Originating client) -> B (Kamailio) -> C (Provider) 5.6.7.8: A 1.2.3.4: B (Public IP, advertise) 10.0.1.2: B (Private IP) 0400123123: Phone number being dialed siptrunk.provider.local: C I don’t understand the dialog module well, however it appears the auth header is created around line 456. The lines below that read as follows: DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_cseq.c:59]: dlg_cseq_prepare_msg(): prepare msg for cseq update operations DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_cseq.c:145]: dlg_cseq_update(): initiating cseq updates DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_hash.c:778]: internal_get_dlg(): no dialog callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060' found DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_hash.c:813]: get_dlg(): no dialog callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060' found DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_handlers.c:1224]: dlg_lookup_msg_dialog(): dlg with callid '504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060' not found DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_cseq.c:151]: dlg_cseq_update(): no dialog for this request This reads to me like the dialog wasn’t tracked, and as it can’t find it, it isn’t incrementing it. Is that correct? The first reference I can see to dialog is on line 135, which is quite similar: DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_hash.c:778]: internal_get_dlg(): no dialog callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060’ found This makes me thing that the dialog isn’t being created in the first place. However I have the dlg_flag enabled in kamailio.cfg: modparam("dialog", "dlg_flag", 4) modparam("dialog", "track_cseq_updates", 1) modparam("dialog", "event_callback", "ksr_dialog_event") I’ve had a good read through the dialog module docs, and it appears setting the dlg_flag should enable dialog creation during the initial request. Have I missed setting something here? Thanks! Andrew > On 28 Apr 2019, at 10:29 am, Henning Westerholt <h...@skalatan.de> wrote: > > Hello, > > why do you set the variable cseq_diff to 1? From the module README: > > "The CSeq difference is stored in $dlg_var(cseq_diff), be sure this variable > is not overwritten via config operation." > > A suggestion would be to test this with DBG log level, so see if the dialog > module is logging something related to the CSEQ update code path. There is > some log output that should be visible. > > Cheers, > > Henning > > Am 27.04.19 um 18:27 schrieb Karsten Horsmann: >> Hi, >> >> AFAIK the uac module don't support cseq autoupdate. >> >> CSeq is not increased automatically by uac_auth() during authentication - >> the follow up request may be rejected. CSeq can be increased when >> authenticating INVITE requests - dialog module has to be used, with CSeq >> tracking feature enabled (see the readme of dialog module). >> >> Hmm are you sure that the dialog module is taking care of your second >> INVITE? >> >> Kind regards >> Karsten >> >> Andrew White <and...@uconnected.com.au <mailto:and...@uconnected.com.au>> >> schrieb am Fr., 26. Apr. 2019, 19:15: >> Hi all, >> >> I’m still building with app_ruby and loving it - for the most part! >> >> I’m having an issue with one of my providers responding with a 482 on auth >> invite. Researching, it appears that my CSeq isn’t incrementing and this is >> the reason for the issue. >> >> I already have the relevant flag set in my kamailio.cfg however: >> >> modparam("dialog", "track_cseq_updates", 1) >> >> During my uac_auth, I’ve tried manually setting the diff, as well as running >> msg_iflag_reset (as suggested by Daniel - >> https://github.com/kamailio/kamailio/issues/1359 >> <https://github.com/kamailio/kamailio/issues/1359> - unfortunately the >> function isn’t exported in KEMI): >> >> >> if KSR::UAC.uac_auth() >> then >> >> KSR.info("UAC authed, relaying") >> >> #KSR::COREX.msg_iflag_reset("UAC_AUTH") >> >> KSR::PV.sets("$dlg_var(cseq_diff)", >> "1") >> >> KSR.info("CSeq diff: >> #{KSR::PV.gete("$dlg_var(cseq_diff)")}") >> >> KSR::TM.t_relay() >> >> >> Unfortunately in both cases the actual CSeq doesn’t increment in the second >> INVITE: >> >> INVITE 1 (unauthenticated): >> > CSeq: 102 INVITE >> >> INVITE 2 (with Authorization header): >> > CSeq: 102 INVITE >> >> I’m unsure if I’ve missed something silly around the track_cseq_updates >> flag, or if app_ruby somehow isn’t interacting with the dialog module when >> running uac_auth to trigger the increment? >> >> Thanks! >> >> Kind regards, >> >> Andrew >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> > -- > Henning Westerholt - https://skalatan.de/blog/ <https://skalatan.de/blog/> > Kamailio services - https://skalatan.de/services > <https://skalatan.de/services>
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
