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
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 andrew@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 - 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 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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 <andrew@uconnected.com.aumailto:andrew@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 - 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.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
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#xdrfRXGjGG0TOA6VYV0iy49IuOSUFuMghz7c... 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 hw@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 <andrew@uconnected.com.au mailto:andrew@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
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#xdrfRXGjGG0TOA6VYV0iy49IuOSUFuMghz7c...
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.8mailto: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.8mailto: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.8mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_hash.c:778]: internal_get_dlg(): no dialog callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto:callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060' found DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_hash.c:813]: get_dlg(): no dialog callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto:callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060' found DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_handlers.c:1224]: dlg_lookup_msg_dialog(): dlg with callid '504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060' not found DEBUG: {1 102 INVITE 504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto: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.8mailto:504966da0d624fd85a04e68a62c945f5@5.6.7.8:5060} dialog [dlg_hash.c:778]: internal_get_dlg(): no dialog callid='504966da0d624fd85a04e68a62c945f5@5.6.7.8mailto: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 <hw@skalatan.demailto:hw@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 <andrew@uconnected.com.aumailto:andrew@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 - 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.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
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+4J... 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#JbzCpj4xhIYx6Zv3Kh89D08BpqR0pkYiHp9p... https://0bin.net/paste/T-TPl6Db+IpQOuGM#JbzCpj4xhIYx6Zv3Kh89D08BpqR0pkYiHp9pHSrW5uH
Thanks!
Andrew
On 30 Apr 2019, at 9:06 pm, Henning Westerholt hw@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#xdrfRXGjGG0TOA6VYV0iy49IuOSUFuMghz7c... 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 <hw@skalatan.de mailto:hw@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 <andrew@uconnected.com.au mailto:andrew@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
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 andrew@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+4J... 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#JbzCpj4xhIYx6Zv3Kh89D08BpqR0pkYiHp9p... https://0bin.net/paste/T-TPl6Db+IpQOuGM#JbzCpj4xhIYx6Zv3Kh89D08BpqR0pkYiHp9pHSrW5uH
Thanks!
Andrew
On 30 Apr 2019, at 9:06 pm, Henning Westerholt <hw@skalatan.de mailto:hw@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#xdrfRXGjGG0TOA6VYV0iy49IuOSUFuMghz7c... 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 <hw@skalatan.de mailto:hw@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 <andrew@uconnected.com.au mailto:andrew@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
-
Andrew White -
Henning Westerholt -
Karsten Horsmann