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 <[email protected]> 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 [email protected] >> <mailto:[email protected]>:5060} dialog >> [dlg_cseq.c:59]: dlg_cseq_prepare_msg(): prepare msg for cseq update >> operations >> DEBUG: {1 102 INVITE [email protected] >> <mailto:[email protected]>:5060} dialog >> [dlg_cseq.c:145]: dlg_cseq_update(): initiating cseq updates >> DEBUG: {1 102 INVITE [email protected] >> <mailto:[email protected]>:5060} dialog >> [dlg_hash.c:778]: internal_get_dlg(): no dialog >> callid='[email protected] >> <mailto:callid='[email protected]>:5060' found >> DEBUG: {1 102 INVITE [email protected] >> <mailto:[email protected]>:5060} dialog >> [dlg_hash.c:813]: get_dlg(): no dialog >> callid='[email protected] >> <mailto:callid='[email protected]>:5060' found >> DEBUG: {1 102 INVITE [email protected] >> <mailto:[email protected]>:5060} dialog >> [dlg_handlers.c:1224]: dlg_lookup_msg_dialog(): dlg with callid >> '[email protected] >> <mailto:[email protected]>:5060' not found >> DEBUG: {1 102 INVITE [email protected] >> <mailto:[email protected]>: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 [email protected] >> <mailto:[email protected]>:5060} dialog >> [dlg_hash.c:778]: internal_get_dlg(): no dialog >> callid='[email protected] >> <mailto:callid='[email protected]>: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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> 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 [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
