Hi Henning, Thanks for your email, you pointed me in the right direction!
It turns out my configuration wasn’t setting the required flag during the actual routing. I didn’t understand the dialog module required you to set this flag ad-hoc, I just assumed this was done with the FLT/FLB default flags in the configuration. My Cseq is now incrementing, thanks again for your help! Andrew > On 1 May 2019, at 10:43 am, Andrew White <and...@uconnected.com.au> wrote: > > Hi Henning, > > Thanks for your reply! > > I believe I have it in the correct place. My kamailio.cfg is fairly simple, > as I do all my processing within app_ruby. Here’s the full config: > > https://0bin.net/paste/AQHG2Le8Opj0WT3Z#fUWSxjpEDyAmfNoLqrJ0Lwh5+STvEMJsa+4Jnw48I5+ > > <https://0bin.net/paste/AQHG2Le8Opj0WT3Z#fUWSxjpEDyAmfNoLqrJ0Lwh5+STvEMJsa+4Jnw48I5+> > > I’m not sure what you mean with initial dialog forming requests. Are you > saying I need to set the flag at the time the dialog is formed? > > My configuration of request_route and its child routes are fairly generic too: > > https://0bin.net/paste/T-TPl6Db+IpQOuGM#JbzCpj4xhIYx6Zv3Kh89D08BpqR0pkYiHp9pHSrW5uH > > <https://0bin.net/paste/T-TPl6Db+IpQOuGM#JbzCpj4xhIYx6Zv3Kh89D08BpqR0pkYiHp9pHSrW5uH> > > Thanks! > > Andrew > >> On 30 Apr 2019, at 9:06 pm, Henning Westerholt <h...@skalatan.de >> <mailto:h...@skalatan.de>> wrote: >> >> Hello Andrew, >> >> It seems indeed that the dialog is not found, and therefore the cseq can't >> be incremented. >> >> just to make sure there is no obvious error - you actually set the dlg_flag >> 4 in the proper place in the configuration - e.g. for initial dialog forming >> requests? >> >> Cheers, >> >> Henning >> >> Am 29.04.19 um 13:01 schrieb Andrew White: >>> 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 >>> <mailto: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 >>> <mailto: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 >>> <mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060} dialog >>> [dlg_hash.c:778]: internal_get_dlg(): no dialog >>> callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto:callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060' found >>> DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060} dialog >>> [dlg_hash.c:813]: get_dlg(): no dialog >>> callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto:callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060' found >>> DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060} dialog >>> [dlg_handlers.c:1224]: dlg_lookup_msg_dialog(): dlg with callid >>> '504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060' not found >>> DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto: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 >>> <mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8>:5060} dialog >>> [dlg_hash.c:778]: internal_get_dlg(): no dialog >>> callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8 >>> <mailto: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 >>>> <mailto: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> >> -- >> 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
