[SR-Users] Re: Kamailio multidomain IMS
Hi, Christoph. To serve different domains you need to map fqdn received from UE/multiple domains - to the naptr of your I-CSCSF.. To achieve that in my IMS setup I created 3gppnetwork.org.zone which resolve all dns naptr queries like ims.mnc0xx.mccyyy.3gppnetwork.org - to naptr record of local I-CSCF - like below: *.3gppnetwork.org. 1D IN NAPTR 30 100 "s" "SIP+D2U""" _sip._udp.ims.mnc001.mcc001.3gppnetwork.org. -- obelousov.tel On Mon, 20 May 2024 at 00:03, Valentin Christoph via sr-users < sr-users@lists.kamailio.org> wrote: > Dear IMS enthusiasts :-) > > > > Has anyone experience with Kamailio IMS (CSCF) setups, where users with > different domain names can be registered at one and the same S-CSCF? > > > > Is this feasible at all? > > > > I mean one IMS for users @ims1.example.com, @ims2.example.com, > @ims3.example.com,…….. in one and the same S-CSCF, I-CSCF, P-CSCF. > > > > Thanks, > > Christoph > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: IMS SCSCF redundancy
Hi. I have a question re: IMS SCSCF redundancy.:There are several SCSCF instances, registration happens via SCSCF1, it goes down after that. UE make MO call.. PCSCF resolves the common SCSCF fqdn and sends an invite to available SCSCF2 which does not have UE profile as well as AS address (which is received during registration SAR/SAA in iFC). There are 2 options here, either to release the call (as per 3gpp spec upon specific release code, eg 408/503 UE should perform re-registration - not happen in our case unfortunately), or to send request for iFC (suspend the call, fire SAR, receive SAA, check available services, etc) and upon success continue the call (to AS first)/ Lke IMS Registrar SCSCF save function, but for the invite. To continue the call without interaction with AS is not a good idea.. Any advice or workaround on how to achieve desired SCSCF redundancy ? -- obelousov.tel __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: STIR/SHAKEN with Kamailio
Hi, Ben. Inline is how we implemented mentioned points in our project, If that will be helpful. Not sure if SS helps much to prevent spoofed calls, but there could be other bonuses like rcd/branded calling which sounds like a promising cnam extension. -- obelousov.tel On Fri, 20 Oct 2023 at 16:25, Ben Kaufman via sr-users < sr-users@lists.kamailio.org> wrote: > My point was simply that there's more challenge in the bureaucracy than > technical implementation. > > From a technical standpoint, the corner cases to consider are: > > 1. Number validity. Sure things that fit into an e.164 and/or recognizable > number patterns are simple. What happens when someone sends a From: URI of > `sip:anonym...@domain.com` - IIRC, the orig_tn field within the identity > header is supposed to be numeric. Do you reject the call? Attest it as > "C" and provide this in the `orig_tn` field or in a separate field? > [Oleg] We are using P-Asserted-Identity instead of From, it keeps the number even if CLIR is enabled. As per ATIS-174 The ‘orig’ claim ‘tn’ value shall be derived using the following rules: - The P-Asserted-Identity header field value shall be used as the telephone identity, if present, otherwise the From header field value shall be used. - If there are two P-Asserted-Identity header field values, the authentication service shall have logic to choose the most appropriate one based on local service provider policy. - The action taken when neither the P-Asserted-Identity header field value nor the From header contain tel URI identities is outside the scope of the SHAKEN framework. > > 2. Handling of forwarded calls - If you're sending a Diversion: header, do > you also add an Identity header with a `div` passport? Rewrite the From > header? How do you determine the attestation in that case? > [Oleg] For the forwarded calls (with enabled diversion) we are checking if Identity is present. If yes - send call as it is, otherwise assign attestation C, > > 3. Known customers sending numbers for which you're not the provider? > Strictly speaking this should attest as "B", but supposing that you're a > secondary vendor for the customer, and they're sending their primary number > which is with a different provider? Do you then allow them to submit an > LOA (or whatever your jurisdictional equivalent is) and attest as A? > [Oleg] If A-number does nor belong to operator - we assign attestation B > > The questions above are strictly for STI Authentication. Verification has > some other idiosyncrasies. Consider that there's three attestation levels > for authentication, and normally as a carrier it is not desirable to pass > the Identity header to the customer (consider if Privacy: is on). The > general practice is to assign this to a verstat parameter to the user > portion of a PAI header's **USER** field, which is syntactically awkward in > Kamailio. Also strictly speaking AFAIK, the verstat only has two values - > passed or failed - so there's three possible attestation levels but they > only map to two verification levels. Therea are suggestions on how to deal > with this, but I'm not sure on their official status. > > This brings up the final complexity: It's a rapidly evolving system > without a high degree of consistency vendor to vendor, so there's as much > of a challenge of staying on top of things as anything else. > > -Original Message- > From: Olle E. Johansson via sr-users > Sent: Friday, October 20, 2023 2:08 AM > To: Kamailio (SER) - Users Mailing List > Cc: Olle E. Johansson > Subject: [SR-Users] Re: STIR/SHAKEN with Kamailio > > CAUTION: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > > On 19 Oct 2023, at 18:46, Alex Balashov via sr-users < > sr-users@lists.kamailio.org> wrote: > > > > Would join Kaufman here to say that free-range STIR/SHAKEN > > implementations in the US are limited by the small number of certified > > authentication providers, but presumably the EU version will to some > > extent avoid US-style Guilded Age corporate welfare... > Sadly that's my view of the US implementation. I can't say if it solved > the problem, but I can see that a lot of new and old actors got an > oppurtunity to earn more money. > > There's no EU-wide implementation or regulation at this point. I am aware > of France. There are certainly discussions. > /O > > > > -- Alex > > > >> On 19 Oct 2023, at 09:33, Ben Kaufman via sr-users < > sr-users@lists.kamailio.org> wrote: > >> > >> Like some of the other posters here, we've implemented it as a > 302-redirect server. This was the primary reason for using the secsipid > rather than stirshaken module. Both modules have a function to append an > Identity header, but secsipid also has functions to simply build the > identity header which can then easily be appended to the reply, rather than > only appending to the request and pluc
[SR-Users] Re: IMS integration with AS
Hi, Carsten. Understood, thank you for clarifications. -- obelousov.tel On Thu, Dec 22, 2022 at 11:28 AM Carsten Bock wrote: > Hi Oleg, > > This is supported by Kamailio IMS and we use it rather frequently. > > However, one point is your description is not properly right: > " constructs Register message (which keeps all details of subscriber > register message) " > > If you need to have all the details of the subscriber register message > (e.g. REGISTER sent by the UE), you will not find them by default in the > 3rd Party registration generated by Kamailio, as it is creating a new > REGISTER (e.g. it has a new Call-ID, Contact pointing to the IMS rather > than to the UE, ...). However, you can instruct the HSS to include the > original REGISTER message as a message body or you can do a "SUBSCRIBE" > (check PUA_reginfo and related modules) for the user status in order to get > more details of the subscriber. > > Thanks, > Carsten > -- > Carsten Bock I CTO & Founder > > ng-voice GmbH > > Trostbrücke 1 I 20457 Hamburg I Germany > T +49 179 2021244 I www.ng-voice.com > > Registry Office at Local Court Hamburg, HRB 120189 > Managing Directors: Dr. David Bachmann, Carsten Bock > > > Am Mi., 21. Dez. 2022 um 14:16 Uhr schrieb Oleg Belousov < > obelou...@gmail.com>: > >> Hi. >> Can you please advise if existing ims implementation supports integration >> with ims AS (Application Server), in particular for the third party >> registration: >> - upon UE registration is completed, S-CSCF constructs Register message >> (which keeps all details of subscriber register message) and submits it to >> AS server as regular SIP-message (TS 24.229 5.4.1.7 Notification of >> Application Servers about registration status). S-CSCF obtains AS address >> from SAA (Server Assignment Answer) diameter message, received from HSS >> upon successful registration. >> -- >> obelousov.tel >> __ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to >> the sender! >> Edit mailing list options or unsubscribe: >> > __ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] IMS integration with AS
Hi. Can you please advise if existing ims implementation supports integration with ims AS (Application Server), in particular for the third party registration: - upon UE registration is completed, S-CSCF constructs Register message (which keeps all details of subscriber register message) and submits it to AS server as regular SIP-message (TS 24.229 5.4.1.7 Notification of Application Servers about registration status). S-CSCF obtains AS address from SAA (Server Assignment Answer) diameter message, received from HSS upon successful registration. -- obelousov.tel __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Re: [SR-Users] ims ipsec connectivity
Hi, Thank you, Carsten, the issue was due to NAT, registration is fine when deploy ims in the same network as epc. -- obelousov.tel On Mon, Nov 14, 2022 at 4:43 PM Carsten Bock wrote: > Hi, > > be aware, that IPSec for VoLTE does not work for NAT. > > Thanks, > Carsten > -- > Carsten Bock I CTO & Founder > > ng-voice GmbH > > Trostbrücke 1 I 20457 Hamburg I Germany > T +49 179 2021244 I www.ng-voice.com > > Registry Office at Local Court Hamburg, HRB 120189 > Managing Directors: Dr. David Bachmann, Carsten Bock > > > Am Mo., 14. Nov. 2022 um 16:09 Uhr schrieb Oleg Belousov < > obelou...@gmail.com>: > >> Hi, Hossein. >> Increased privileges for proxy container, now can see records in both SPD >> and SAD, but still ipsec is not established. Possible because UE is behind >> NAY - will check that either. Thanks for your advice. >> # ip xfrm state count >> SAD count 28 >> # ip xfrm policy count >> SPD IN 16 OUT 16 FWD 0 >> >> Hi, Giovanni. >> Thank you. Yes, I saw that fork and am going to try it as well. Not quite >> clear why those patches not included onto the main release. >> -- >> obelousov.tel >> >> >> On Mon, Nov 14, 2022 at 11:07 AM Giovanni Maruzzelli >> wrote: >> >>> Hello, >>> >>> you may also want to check Supreeth ipsec patches : >>> >>> https://github.com/herlesupreeth/kamailio >>> >>> -giovanni >>> >>> On Fri, Nov 11, 2022 at 1:44 PM Oleg Belousov >>> wrote: >>> >>>> Hi, Hossein. >>>> No, there are not. The output of these two commands is just empty. >>>> Should enable it? >>>> -- >>>> obelousov.tel >>>> >>>> >>>> On Thu, Nov 10, 2022 at 9:08 PM H Yavari >>>> wrote: >>>> >>>>> Hi Oleg, >>>>> >>>>> Can you check the ipsec SA in the OS and see that SA and policies are >>>>> there or not: >>>>> >> ip x s l >>>>> >> ip x p l >>>>> >>>>> BR, >>>>> Hossein >>>>> >>>>> On Thursday, November 10, 2022 at 03:12:34 AM PST, Oleg Belousov < >>>>> obelou...@gmail.com> wrote: >>>>> >>>>> >>>>> Hi. >>>>> Working on ims integration with the actual handset, have got a >>>>> problem with ipsec establishment to complete registration. >>>>> >>>>> Initial steps are fine, including diameter exchange and 401 (with >>>>> security server details) toward UE. On the next step UE and kamailio >>>>> should >>>>> establish ipsec connection, and UE to submit the next register with a >>>>> response. As per trace UE is trying to establish the same (can see initial >>>>> TCP SYN encapsulated onto ESP), using port-s, provided in Security-Server, >>>>> but get an ICMP packet from server with destination/protocol unreachable. >>>>> No more info either in P-SCSF log, no in kern.log. Proxy is listening to >>>>> that port, it is tcp and available over telnet, so should not be a >>>>> connectivity issue. >>>>> Please let know if any ideas how to troubleshoot that further, >>>>> -- >>>>> obelousov.tel >>>>> __ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> sr-users@lists.kamailio.org >>>>> Important: keep the mailing list in the recipients, do not reply only >>>>> to the sender! >>>>> Edit mailing list options or unsubscribe: >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> __ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> sr-users@lists.kamailio.org >>>>> Important: keep the mailing list in the recipients, do not reply only >>>>> to the sender! >>>>> Edit mailing list options or unsubscribe: >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>>> __ >>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>> sr-users@lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not r
Re: [SR-Users] Create new listener on the fly
Hello. I'm wondering why not having the ability to create a SIP listener on the fly/usage instead of bunch of listeners at startup can be a limitation. I believe each listener can serve multiple ipsec connections, or it is not the case? -- obelousov.tel On Thu, Oct 27, 2022 at 5:26 PM Carsten Bock wrote: > Hi Hossein, > > due to those limitations, we are using a custom, in-house solution for our > MNO/MVNO deployments, which we haven't released as open-source (yet). > > Thanks, > Carsten > > -- > Carsten Bock I CTO & Founder > > ng-voice GmbH > > Trostbrücke 1 I 20457 Hamburg I Germany > T +49 179 2021244 I www.ng-voice.com > > Registry Office at Local Court Hamburg, HRB 120189 > Managing Directors: Dr. David Bachmann, Carsten Bock > > > Am Mi., 26. Okt. 2022 um 18:29 Uhr schrieb H Yavari < > hyav...@rocketmail.com>: > >> Hi Casrten, >> >> Thanks for the comment. I know you provide IMS, have you contributed to >> Kamailio IPsec, or do you have something in-house solution for this part? >> (I hope this question will not be off-topic) >> >> BR >> Hossein >> >> >> On Wednesday, October 26, 2022 at 06:37:33 AM PDT, Carsten Bock < >> cars...@ng-voice.com> wrote: >> >> >> Hi Hossein, >> >> yes, you are right, it is in-efficient. It may be fine for a private >> network/PoC/Lab/ or anything else small, but it will not really work for a >> commercial network - for that you need something different. >> >> Thanks, >> Carsten >> -- >> Carsten Bock I CTO & Founder >> >> ng-voice GmbH >> >> Trostbrücke 1 I 20457 Hamburg I Germany >> T +49 179 2021244 I www.ng-voice.com >> >> Registry Office at Local Court Hamburg, HRB 120189 >> Managing Directors: Dr. David Bachmann, Carsten Bock >> >> >> Am Di., 25. Okt. 2022 um 23:03 Uhr schrieb H Yavari < >> hyav...@rocketmail.com>: >> >> Thanks Alex for your elaboration; you are right. >> This is the reason that the current ims_ipsec module will create a bunch >> of listeners at startup that looks not efficient. >> >> >> Regards, >> Hossein >> >> >> On Tuesday, October 25, 2022 at 01:28:38 PM PDT, Alex Balashov < >> abalas...@evaristesys.com> wrote: >> >> >> Well, no, it just stems from some knowledge of Kamailio’s multiprocess >> architecture. >> >> Kamailio uses a static pool of preforked SIP worker processes, and this >> is initialised once upon startup. These child processes are spawned for >> every listener, and communicate and share data using SysV IPC and shared >> memory. The shared memory pool is likewise initialised upon startup, as is >> the small fixed-size area of private memory associated with each other >> worker process (“package memory”). >> >> While perhaps not strictly impossible to alter, this setup isn’t >> particularly amenable to the dynamic creation and destruction of listeners, >> or the additional child processes they beget. The child processes need to >> be forked on startup, before their heap is laden with runtime baggage. All >> this is relatively expensive to initialise. >> >> — Alex >> >> > On Oct 25, 2022, at 4:14 PM, H Yavari wrote: >> > >> > Thanks Alex. >> > Is there any document or material that tells more about those reasons? >> > >> > >> > Regards, >> > Hossein >> > >> > >> > On Tuesday, October 25, 2022 at 01:00:18 PM PDT, Alex Balashov < >> abalas...@evaristesys.com> wrote: >> > >> > >> > Hi, >> > >> > Unfortunately, for a variety of architectural reasons, this is not >> practical. >> > >> > — Alex >> > >> > > On Oct 25, 2022, at 12:43 PM, H Yavari >> wrote: >> > > >> > > Hi Kamailio community, >> > > >> > > >> > > I am running an IPsec server beside Kamailio, so I am interested to >> know if there is any method to create a SIP listener on a specific port on >> the fly. I mean, when I create the IPsec SAs through the IPsec server, I >> ask Kamailio to create a listener/handler for that port too. >> > > This case might be very rare, but it is always good to hear community >> ideas. >> > > >> > > Thank you. >> > > >> > > Regards, >> > > Hossein >> > >> > > __ >> > > Kamailio - Users Mailing List - Non Commercial Discussions >> > > sr-users@lists.kamailio.org >> > > Important: keep the mailing list in the recipients, do not reply only >> to the sender! >> > > Edit mailing list options or unsubscribe: >> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> > -- >> > Alex Balashov | Principal | Evariste Systems LLC >> > >> > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) >> > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ >> > >> > >> > __ >> > Kamailio - Users Mailing List - Non Commercial Discussions >> > sr-users@lists.kamailio.org >> > Important: keep the mailing list in the recipients, do not reply only >> to the sender! >> > Edit mailing list options or unsubscribe: >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> > >> > __
Re: [SR-Users] ims ipsec connectivity
Hi, Hossein. Increased privileges for proxy container, now can see records in both SPD and SAD, but still ipsec is not established. Possible because UE is behind NAY - will check that either. Thanks for your advice. # ip xfrm state count SAD count 28 # ip xfrm policy count SPD IN 16 OUT 16 FWD 0 Hi, Giovanni. Thank you. Yes, I saw that fork and am going to try it as well. Not quite clear why those patches not included onto the main release. -- obelousov.tel On Mon, Nov 14, 2022 at 11:07 AM Giovanni Maruzzelli wrote: > Hello, > > you may also want to check Supreeth ipsec patches : > > https://github.com/herlesupreeth/kamailio > > -giovanni > > On Fri, Nov 11, 2022 at 1:44 PM Oleg Belousov wrote: > >> Hi, Hossein. >> No, there are not. The output of these two commands is just empty. Should >> enable it? >> -- >> obelousov.tel >> >> >> On Thu, Nov 10, 2022 at 9:08 PM H Yavari wrote: >> >>> Hi Oleg, >>> >>> Can you check the ipsec SA in the OS and see that SA and policies are >>> there or not: >>> >> ip x s l >>> >> ip x p l >>> >>> BR, >>> Hossein >>> >>> On Thursday, November 10, 2022 at 03:12:34 AM PST, Oleg Belousov < >>> obelou...@gmail.com> wrote: >>> >>> >>> Hi. >>> Working on ims integration with the actual handset, have got a >>> problem with ipsec establishment to complete registration. >>> >>> Initial steps are fine, including diameter exchange and 401 (with >>> security server details) toward UE. On the next step UE and kamailio should >>> establish ipsec connection, and UE to submit the next register with a >>> response. As per trace UE is trying to establish the same (can see initial >>> TCP SYN encapsulated onto ESP), using port-s, provided in Security-Server, >>> but get an ICMP packet from server with destination/protocol unreachable. >>> No more info either in P-SCSF log, no in kern.log. Proxy is listening to >>> that port, it is tcp and available over telnet, so should not be a >>> connectivity issue. >>> Please let know if any ideas how to troubleshoot that further, >>> -- >>> obelousov.tel >>> __ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> sr-users@lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply only to >>> the sender! >>> Edit mailing list options or unsubscribe: >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> __ >>> Kamailio - Users Mailing List - Non Commercial Discussions >>> sr-users@lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply only to >>> the sender! >>> Edit mailing list options or unsubscribe: >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> __ >> Kamailio - Users Mailing List - Non Commercial Discussions >> sr-users@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to >> the sender! >> Edit mailing list options or unsubscribe: >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > > -- > Sincerely, > > Giovanni Maruzzelli > OpenTelecom.IT > cell: +39 347 266 56 18 > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] ims ipsec connectivity
Hi, Hossein. No, there are not. The output of these two commands is just empty. Should enable it? -- obelousov.tel On Thu, Nov 10, 2022 at 9:08 PM H Yavari wrote: > Hi Oleg, > > Can you check the ipsec SA in the OS and see that SA and policies are > there or not: > >> ip x s l > >> ip x p l > > BR, > Hossein > > On Thursday, November 10, 2022 at 03:12:34 AM PST, Oleg Belousov < > obelou...@gmail.com> wrote: > > > Hi. > Working on ims integration with the actual handset, have got a > problem with ipsec establishment to complete registration. > > Initial steps are fine, including diameter exchange and 401 (with security > server details) toward UE. On the next step UE and kamailio should > establish ipsec connection, and UE to submit the next register with a > response. As per trace UE is trying to establish the same (can see initial > TCP SYN encapsulated onto ESP), using port-s, provided in Security-Server, > but get an ICMP packet from server with destination/protocol unreachable. > No more info either in P-SCSF log, no in kern.log. Proxy is listening to > that port, it is tcp and available over telnet, so should not be a > connectivity issue. > Please let know if any ideas how to troubleshoot that further, > -- > obelousov.tel > __ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > __ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] ims ipsec connectivity
Hi. Working on ims integration with the actual handset, have got a problem with ipsec establishment to complete registration. Initial steps are fine, including diameter exchange and 401 (with security server details) toward UE. On the next step UE and kamailio should establish ipsec connection, and UE to submit the next register with a response. As per trace UE is trying to establish the same (can see initial TCP SYN encapsulated onto ESP), using port-s, provided in Security-Server, but get an ICMP packet from server with destination/protocol unreachable. No more info either in P-SCSF log, no in kern.log. Proxy is listening to that port, it is tcp and available over telnet, so should not be a connectivity issue. Please let know if any ideas how to troubleshoot that further, -- obelousov.tel __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] ims_auth with AKAv1-MD5
Thank you Alberto, for the confirmation. Will update if I have resynchronization test results. -- obelousov.tel On Mon, Oct 24, 2022 at 9:05 AM Alberto Diez wrote: > Hi Oleg, > > Yes the S-CSCF implementaiton of AKAv1-MD5 works with an actual SIM card > for a first registration. For Re-registration I am not 100% sure it works > because it receives a previous nonce and the response is calculated over > the new message, apparently there is a configuration parameter > max_nonce_reuse which is relevant in this case. Also the resynchronization > I haven't tested with a real SIM card. > Best regards > > alberto > El 14/10/2022 a las 13:52, Oleg Belousov escribió: > > Hello, > I'm wondering if ims_auth is tested with actual SIM-card/AKAv1-MD5 > authentication? Bit concerned with that since as per authorize.c source > code can see for AUTH_AKAV1_MD5/AUTH_AKAV2_MD5/AUTH_MD5 response is counted > in the same way, though algorithms are different. > -- > obelousov.tel > > __ > Kamailio - Users Mailing List - Non Commercial > discussionssr-us...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or > unsubscribe:https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] ims_auth with AKAv1-MD5
Hello, I'm wondering if ims_auth is tested with actual SIM-card/AKAv1-MD5 authentication? Bit concerned with that since as per authorize.c source code can see for AUTH_AKAV1_MD5/AUTH_AKAV2_MD5/AUTH_MD5 response is counted in the same way, though algorithms are different. -- obelousov.tel __ Kamailio - Users Mailing List - Non Commercial Discussions sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] STIR/SHAKEN public key
Hi, David.
Our CA provided us a single file which consists of such 3 certs, in order
you mentioned, so yes - you need to publish a single file in that order:
your cert, CA cert, root cert.
--
obelousov.tel
On Thu, Nov 4, 2021 at 9:57 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:
> Hello guys,
>
> So the PA sent us 3 files:
>
> 1- out cert
> 2- the intermediate cert
> 3- the root cert
>
> Should i copy those into a single file in that order and then publish that
> as the cert.pem in
>
> *secsipid_add_identity("$fU", "$rU", "A", "",
> "https://kamailio.org/stir/$rd/cert.pem
> <https://kamailio.org/stir/$rd/cert.pem>", "/secsipid/$rd/key.pem");*
>
>
> ??
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Thu, Nov 4, 2021 at 6:55 PM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
>> Yep, that much was clear from the outset.
>> The wording on the docs confused me, because it reads "public key". BUt
>> now i see it's the cert and the client will get the pk from the cert.
>> Thanks for taking the time to explain!
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337
>>
>>
>> On Thu, Nov 4, 2021 at 6:35 PM Ben Kaufman
>> wrote:
>>
>>> Not sure if it was clarified or not, but it should be an https URL from
>>> where your certificate can be downloaded, not the actual certificate itself.
>>>
>>>
>>>
>>> *Ben Kaufman*
>>>
>>>
>>>
>>> *From:* sr-users * On Behalf Of *David
>>> Villasmil
>>> *Sent:* Thursday, November 4, 2021 12:00 PM
>>> *To:* Kamailio (SER) - Users Mailing List
>>> *Subject:* Re: [SR-Users] STIR/SHAKEN public key
>>>
>>>
>>>
>>> Thanks Oleg, i misunderstood all that.
>>>
>>> Regards,
>>>
>>>
>>>
>>> David Villasmil
>>>
>>> email: david.villasmil.w...@gmail.com
>>>
>>> phone: +34669448337
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 4, 2021 at 4:58 PM Oleg Belousov
>>> wrote:
>>>
>>> Hi.
>>>
>>> It should be certificate issued by CA certified by the Shaken Policy
>>> Administrator (iConnective in US)..
>>>
>>> --
>>> obelousov.tel
>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fobelousov.tel%2F&data=04%7C01%7Cbkaufman%40nexvortex.com%7Cc7a43b3de31c404450cc08d99fb4ef2f%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C637716421732872628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tGrsS8EC2s%2BbcpseVdLDm0Z7NHSeIrklPzzAJC3TskE%3D&reserved=0>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 4, 2021 at 5:39 PM David Villasmil <
>>> david.villasmil.w...@gmail.com> wrote:
>>>
>>> Hello guys,
>>>
>>> I'm testing with 2 providers right now, and one of them is asking me to
>>> include my whole certificate on the
>>>
>>> *secsipid_add_identity(origTN, destTN, attest, origID, x5u, keyPath)*
>>>
>>> like:
>>>
>>> *secsipid_add_identity("$fU", "$rU", "A", "",
>>> "https://kamailio.org/stir/$rd/cert.pem
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkamailio.org%2Fstir%2F%24rd%2Fcert.pem&data=04%7C01%7Cbkaufman%40nexvortex.com%7Cc7a43b3de31c404450cc08d99fb4ef2f%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C637716421732872628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9hcmnq0bD4n89HczPIHjyb54ZDdi8RBfwP%2FqyjoQuas%3D&reserved=0>",
>>> "/secsipid/$rd/key.pem");*
>>>
>>> but it is stated that:
>>>
>>> *x5u is the HTTP URL referencing to the public key that should be used
>>> to verify the signature;*
>>>
>>> One provider is asking to put the cert there, the other hasn't asked
>>> that yet.
>>>
>>> So i'm a little confused, should the x5u be the actual cert (with its
>>> intermediary?) or only the public key?
>>>
>>> Regards,
>>>
>>> David Villasmil
>>>
>>> email: david.villasmil.w...@gmail.com
>>>
>>> phone: +34669448337
>>>
>
Re: [SR-Users] STIR/SHAKEN public key
Sorry, David if I was not clear.
x5u should keep the url to the service provider certificate. As per shaken
framework that certificate to be issued by Certificate Authority (CA), That
CA is a company which is approved by Policy Administrator to issue shake
certificates. It is indeed a bit complicated - please check ATIS-180.
--
obelousov.tel
On Thu, Nov 4, 2021 at 6:03 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:
> Thanks Oleg, i misunderstood all that.
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Thu, Nov 4, 2021 at 4:58 PM Oleg Belousov wrote:
>
>> Hi.
>> It should be certificate issued by CA certified by the Shaken Policy
>> Administrator (iConnective in US)..
>> --
>> obelousov.tel
>>
>>
>> On Thu, Nov 4, 2021 at 5:39 PM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>>> Hello guys,
>>>
>>> I'm testing with 2 providers right now, and one of them is asking me to
>>> include my whole certificate on the
>>>
>>> *secsipid_add_identity(origTN, destTN, attest, origID, x5u, keyPath)*
>>>
>>> like:
>>>
>>> *secsipid_add_identity("$fU", "$rU", "A", "",
>>> "https://kamailio.org/stir/$rd/cert.pem
>>> <https://kamailio.org/stir/$rd/cert.pem>", "/secsipid/$rd/key.pem");*
>>>
>>> but it is stated that:
>>>
>>> *x5u is the HTTP URL referencing to the public key that should be used
>>> to verify the signature;*
>>>
>>> One provider is asking to put the cert there, the other hasn't asked
>>> that yet.
>>>
>>> So i'm a little confused, should the x5u be the actual cert (with its
>>> intermediary?) or only the public key?
>>>
>>> Regards,
>>>
>>> David Villasmil
>>> email: david.villasmil.w...@gmail.com
>>> phone: +34669448337
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> * sr-users@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] STIR/SHAKEN public key
Hi.
It should be certificate issued by CA certified by the Shaken Policy
Administrator (iConnective in US)..
--
obelousov.tel
On Thu, Nov 4, 2021 at 5:39 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:
> Hello guys,
>
> I'm testing with 2 providers right now, and one of them is asking me to
> include my whole certificate on the
>
> *secsipid_add_identity(origTN, destTN, attest, origID, x5u, keyPath)*
>
> like:
>
> *secsipid_add_identity("$fU", "$rU", "A", "",
> "https://kamailio.org/stir/$rd/cert.pem
> ", "/secsipid/$rd/key.pem");*
>
> but it is stated that:
>
> *x5u is the HTTP URL referencing to the public key that should be used to
> verify the signature;*
>
> One provider is asking to put the cert there, the other hasn't asked that
> yet.
>
> So i'm a little confused, should the x5u be the actual cert (with its
> intermediary?) or only the public key?
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to get Stir/Shaken certificates
STIR-SHAKEN is currently only applicable for the US and Canada. To be part of it service provider must have an Operating Company Number (OCN) which allows access to NANPA Numbering Resource assignments. That also means (and as per my knowledge/experience) - US/Canadian SPs only sign calls with +1 destination. It is however worth it to check if the identity header is present in calls you receive. If it is here - then you can validate MT calls even not being part of a stir-shaken ecosystem. -- obelousov.tel On Thu, Jul 22, 2021 at 4:31 PM Benoît Panizzon wrote: > Hi > > > You need first to register with STI-PA (Policy Administrator), in > > order to receive a token to obtain further certificates from an > > approved Certification Authority. > > In the US STI-PA is Iconectiv, in Canada - Neustar. Please check that > > link https://authenticate.iconectiv.com/ > > Thank you for that link. This is very interesting. > > We receive an increasing number of calls from spoofed US numbers in > Switzerland. Mostly tech support scams. I was pondering if there is a > way to validate them via STIR/SHAKEN. > > We try to filter out invalid +1 prefixes and lengths, but that is a > rather fuzzy thing to do. > > So it would be great, if we could implement STIR/SHAKEN to validate > received calls from the +1 prefix. > > Unfortunately to register for a STI-PA account, only TSP with an > address in he United States are allowed. Do you know if there is a way > to register as a Swiss Ofcom registered TSP? > > (And yes, I am aware that signature signalling also has to be > implemented but we have to start somewhere). > > Hopefully STIR/SHAKEN can in future be deployed on a global level. > Germany and UK would also benefit a lot, seeing also a lot of spoofed > calls with their prefixes. > > -- > Mit freundlichen Grüssen > > -Benoît Panizzon- @ HomeOffice und normal erreichbar > -- > I m p r o W a r e A G-Leiter Commerce Kunden > __ > > Zurlindenstrasse 29 Tel +41 61 826 93 00 > CH-4133 PrattelnFax +41 61 826 93 01 > Schweiz Web http://www.imp.ch > __ > __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to get Stir/Shaken certificates
Hi. You need first to register with STI-PA (Policy Administrator), in order to receive a token to obtain further certificates from an approved Certification Authority. In the US STI-PA is Iconectiv, in Canada - Neustar. Please check that link https://authenticate.iconectiv.com/ -- obelousov.tel On Thu, Jul 22, 2021 at 3:38 PM ryan embgrets wrote: > Greetings. > > Does someone know where one can get stir/shaken certificates? > > Are they same as letsencrypt or do I need to obtain them from some other > authority. > > If someone could provide me with a link to that authority it will be very > helpful. > > Thanks again for your help and time. > > Ryan > __ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] SIP-links adjacency
Thanks, Alex, David. Will check your suggestions.
--
obelousov.tel
On Mon, Oct 7, 2019 at 1:51 PM Alex Balashov
wrote:
> In hindsight and upon better understanding the requirement, David’s
> suggestion—or something like it, e.g. htable-based—makes more sense.
>
> Hashing would only ensure that given incoming IP X, the same outbound
> dispatcher set is chosen, which is what I thought you were trying to
> achieve. But it doesn’t allow you to dictate what that set will actually
> be, only that it will be consistent.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> On Oct 7, 2019, at 6:44 AM, David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
>
> You could also use the dialplan module, using the match regexp to return
> the GID of the incoming ip.
>
> Say all calls coming from 192.168.0.100 must use the IPs 192.168.100.2 and
> 3 for outbound.
>
> I.e.:
>
> Adding a record in the dialplan table which includes
> match_exp=“192.168.0.100”, attrs=“100”
>
> Adding records in the dispatcher, like:
>
> GID destination
> 100 192.168.100.2
> 100 192.168.100.3
> ...
>
> Then use the inbound source_ip (192.168.0.100) to match using dialplan
> then getting the list of destinations from the dispatcher, something like:
>
> dp_match("1", "$si");
> xlog("[DISPATCH] inbound '$si' will use dispatcher GID:
> '$var(dispatcher_id)'\n");
> xlog("[DISPATCH] avp(dsdstid): $avp(dsdstid)\n");
>
> if(!ds_select_dst("$var(dispatcher_id)", "4"))
> {
> send_reply("404", "No destination");
> exit;
> } else {
> xlog("[DISPATCH] ds_select_dst was succesful'\n");
> }
> xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n");
> t_on_failure("RTF_DISPATCH");
> route(RELAY);
> exit;
>
> Hope that helps
>
>
> David
>
> On Mon, 7 Oct 2019 at 11:22, Alex Balashov
> wrote:
>
>> Hi Oleg,
>>
>> What about choosing the dispatcher group based on a hash
>>
>>
>> https://kamailio.org/docs/modules/5.2.x/modules/cfgutils.html#cfgutils.f.core_hash
>>
>> over a SIP attribute that is tied to the source IP of the inbound SBC,
>> such as $si or $fd?
>>
>>
>> https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#si_-_source_ip_address
>>
>>
>> https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#fd_-_from_uri_domain
>>
>> — Alex
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>> On Oct 7, 2019, at 5:43 AM, Oleg Belousov wrote:
>>
>>
>>
>> Hello.
>> In our setup kamailio perfoms some logic depending on call direction,
>> inbound or outbound. Call direction is identified by 2 SBC IP
>> (IP_inbound/IP_outbound), we currently use for that 2 dispatcher groups and
>> that is working fine.
>>
>> Now number of peer nodes increased from one SBC till few tens, but we
>> still need to keep SIP-links adjacency, meaning that call which arrived
>> from SBC_N IP_inbound
>> need to be submitted via same SBC_N IP_outbound and vice versa. There
>> could be few approaches to implement that requirement, I'm wondering if can
>> use existing dispatcher function/select destination logic to support
>> SIP-links adjacency.
>> --
>> obelousov.tel
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] SIP-links adjacency
Hello. In our setup kamailio perfoms some logic depending on call direction, inbound or outbound. Call direction is identified by 2 SBC IP (IP_inbound/IP_outbound), we currently use for that 2 dispatcher groups and that is working fine. Now number of peer nodes increased from one SBC till few tens, but we still need to keep SIP-links adjacency, meaning that call which arrived from SBC_N IP_inbound need to be submitted via same SBC_N IP_outbound and vice versa. There could be few approaches to implement that requirement, I'm wondering if can use existing dispatcher function/select destination logic to support SIP-links adjacency. -- obelousov.tel ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
