[SR-Users] Re: Software bill of materials (SBOM)

[Henning Westerholt via sr-users]

Hello,

I think Olle was looking into that some month ago, maybe (when he reads it) can 
share some of his research results if possible.
You can also find some of his articles e.g., on his linkedin page.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Ivan Ribakov via sr-users 
Sent: Mittwoch, 27. September 2023 21:11
To: Kamailio (SER) - Users Mailing List 
Cc: Ivan Ribakov 
Subject: [SR-Users] Software bill of materials (SBOM)

Any recommendations for a tool that can generate SBOM for a Kamailio instance 
based on configured modules?

Thanks,
Ivan
__
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: What is the expected behavior for dispatcher's ds_next_dst?

[Henning Westerholt via sr-users]

Hello Geoff,

thanks for the debug output, it's as I suspected and also described earlier 
from Daniel.

As already mentioned, the common way of working with dispatcher is to call the 
ds_select_dst() in the request route, and then in the failure route just 
iterate over this set of destinations. If you are interested in a more powerful 
way of doing this kind of failure routing, maybe one of the other routing 
modules (like carrierroute and others) offer something more suitable to your 
use-case.

Arguable, the module could clear the content of the XAVP on a new invocation of 
the ds_select_dst() function. It would certainly helpful if its documented, you 
are right.

I can have a look in the next days to it, if you have a good idea about an 
extension, just create a pull request of course.

Cheers,

Henning

--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com

From: Geoff Goas 
Sent: Donnerstag, 28. September 2023 07:13
To: Henning Westerholt ; Kamailio (SER) - Users Mailing List 
; Patrick Karton 
Subject: Re: [SR-Users] Re: What is the expected behavior for dispatcher's 
ds_next_dst?

pv_xavp_print() has enlightened me to the fact that ds_select_dst() does not 
reset the dispatcher destination set XAVP. It only adds the selected 
destinations to the top of the XAVP stack. There are some ds_select_dst() calls 
for group 1 and group 2 earlier on in request_route, and those destinations 
remain in the XAVP stack even after selecting the destination set for group 3. 
To resolve, I added a loop to nullify the XAVP before the call to load the 
group 3 destination set:

while ($xavp(_dsdst_) != null)
{
pv_unset($xavp(_dsdst_));
}

I wonder, though - Is there a "dispatcher-native" way of clearing out the XAVP? 
And should I also clear out the XAVP holding the routing contexts 
"$xavp(_dsctx_)" ?

If this is behaving as designed, then I think others might benefit from the 
documentation explaining how the destination set XAVP contents are managed by 
dispatcher, particularly how the XAVP is not cleared on subsequent 
ds_select_dst() calls.

Thanks all!


From: Geoff Goas 
mailto:geoff.g...@interoptechnologies.com>>
Sent: Wednesday, September 27, 2023 14:19
To: Henning Westerholt mailto:h...@gilawa.com>>; Kamailio 
(SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>; Patrick 
Karton mailto:patrickar...@hotmail.com>>
Subject: Re: [SR-Users] Re: What is the expected behavior for dispatcher's 
ds_next_dst?

Hi Henning,

I used xavp_params_implode() and xlog() to log the contents of the XAVP

You can see the contents of the XAVP in the previously provided log lines 
(showing the contents before and after the ds_next_dst() call):

FAILURE ROUTE: Already have replies on this transaction. Selecting next 
destination from: [grp=3;uri=sip:127.0.0.1:7012;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7011;transport=udp] 
from [grp=3;uri=sip:127.0.0.1:7011;transport=udp;]

FAILURE ROUTE: Already have replies on this transaction. Selecting next 
destination from: [grp=3;uri=sip:127.0.0.1:7011;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:7010;transport=udp] 
from [grp=3;uri=sip:127.0.0.1:7010;transport=udp;]

FAILURE ROUTE: Already have replies on this transaction. Selecting next 
destination from: [grp=3;uri=sip:127.0.0.1:7010;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] 
from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]

FAILURE ROUTE: Already have replies on this transaction. Selecting next 
destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5072;transport=udp] 
from [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]

FAILURE ROUTE: Already have replies on this transaction. Selecting next 
destination from: [grp=2;uri=sip:127.0.0.1:5072;transport=udp;]
FAILURE ROUTE: Next destination selected: [sip:127.0.0.1:5071;transport=udp] 
from [grp=1;uri=sip:127.0.0.1:5071;transport=udp;]

Thanks,



[cid:image001.png@01D9F1EF.51F308A0]




GEOFF GOAS
Manager
Application Engineering




T: +1 239-425-9132 (Florida)
F: +1 239-425-6845
Skype: GeoffGoas



Confidentiality Notice: The information in this e-mail and in any attachment 
may contain information which is legally privileged. It is intended only for 
the attention and use of the named recipient. If you are not the intended 
recipient, you are not authorized to retain, disclose, copy or distribute the 
message and/or any of its attachments. If you received this e-mail in error, 
please notify me and delete this message.






From: Henning Westerholt mailto:h...@gilawa.com>>
Sent: Wednesday, September 27, 2023 13:51
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>; Patrick 
Karton mailto:patrickar...@hotmail.com>>
Cc: Geoff Goas 
mailto:geoff.g...

[SR-Users] Re: Software bill of materials (SBOM)

[Olle E. Johansson via sr-users]

Still digging through this. There are tools that can list your packages if you 
install Linux packages, i.e. Debian.
But there are no tools that can parse your kamailio config to really see what’s 
loaded and active.

It all depends on what you want to do with the SBOM - if you want to check for 
vulnerabilities, list licenses
or have a generic inventory.

/O

> On 28 Sep 2023, at 09:41, Henning Westerholt via sr-users 
>  wrote:
> 
> Hello,
>  
> I think Olle was looking into that some month ago, maybe (when he reads it) 
> can share some of his research results if possible.
> You can also find some of his articles e.g., on his linkedin page.
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com 
>  
> From: Ivan Ribakov via sr-users  > 
> Sent: Mittwoch, 27. September 2023 21:11
> To: Kamailio (SER) - Users Mailing List  >
> Cc: Ivan Ribakov mailto:i.riba...@zaleos.net>>
> Subject: [SR-Users] Software bill of materials (SBOM)
>  
> Any recommendations for a tool that can generate SBOM for a Kamailio instance 
> based on configured modules?
>  
> Thanks,
> Ivan
> __
> 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] kamailio Behind nat. How Record-Route should be added ？

[codenot--- via sr-users]

UA1(192.168.0.1)  --> kamailio (internal:192.168.0.2  public:1.1.1.1) -->  
UA2(2.2.2.2)
if in  UA1 INVITE, I write KSR.rr.record_route().  
so  UA2(2.2.2.2) received sip msg (Record-Route: ), so 
Kamailio can received BYE/ACK from UA2.
but，Kamailio can't received BYE/ACK  from UA1.

if in UA1 INVITE, i write 
KSR.rr.record_route_advertised_address("192.168.0.2"), then Kamailio can 
received  BYE/ACK  from UA1, but not from UA2.

what can i do, let Kamailio receive BYE/ACK  from both sides ？
__
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: kamailio Behind nat. How Record-Route should be added ？

[Yuriy G via sr-users]

 There are many possibilities.
One of - use listen names and advertised address with allow_double_rr
option.

Once you do that - you'll be able to add 2 rr headers, and kamailio will be
able to handle gateway functionality between interfaces via RR/Route headers

On Thu, 28 Sept 2023, 11:53 codenot--- via sr-users, <
sr-users@lists.kamailio.org> wrote:

> UA1(192.168.0.1)  --> kamailio (internal:192.168.0.2  public:1.1.1.1) -->
> UA2(2.2.2.2)
> if in  UA1 INVITE, I write KSR.rr.record_route().
> so  UA2(2.2.2.2) received sip msg (Record-Route: ), so
> Kamailio can received BYE/ACK from UA2.
> but，Kamailio can't received BYE/ACK  from UA1.
>
> if in UA1 INVITE, i write
> KSR.rr.record_route_advertised_address("192.168.0.2"), then Kamailio can
> received  BYE/ACK  from UA1, but not from UA2.
>
> what can i do, let Kamailio receive BYE/ACK  from both sides ？
> __
> 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: Software bill of materials (SBOM)

[Ivan Ribakov via sr-users]

Hi Olle,

Yes, I realised by now that taking enabled Kamailio modules into account
when generating SBOM is too much to ask. I'd be ok with obtaining full list
of Kamailio dependencies (with transitive dependencies if possible) and
then manually filtering them based on module usage. Not sure if at any
point during Kamailio build process all sources + dependency
sources/binaries are present in the system for scanning/identification?

I'm mainly interested in listing (and validating licenses) and having a
general inventory. Any recommendations?




-- 
Ivan Ribakov
Software Engineer
www.zaleos.net





On Thu, 28 Sept 2023 at 10:58, Olle E. Johansson via sr-users <
sr-users@lists.kamailio.org> wrote:

> Still digging through this. There are tools that can list your packages if
> you install Linux packages, i.e. Debian.
> But there are no tools that can parse your kamailio config to really see
> what’s loaded and active.
>
> It all depends on what you want to do with the SBOM - if you want to check
> for vulnerabilities, list licenses
> or have a generic inventory.
>
> /O
>
> On 28 Sep 2023, at 09:41, Henning Westerholt via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
> Hello,
>
> I think Olle was looking into that some month ago, maybe (when he reads
> it) can share some of his research results if possible.
> You can also find some of his articles e.g., on his linkedin page.
>
> Cheers,
>
> Henning
>
> --
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
>
> *From:* Ivan Ribakov via sr-users 
> *Sent:* Mittwoch, 27. September 2023 21:11
> *To:* Kamailio (SER) - Users Mailing List 
> *Cc:* Ivan Ribakov 
> *Subject:* [SR-Users] Software bill of materials (SBOM)
>
> Any recommendations for a tool that can generate SBOM for a Kamailio
> instance based on configured modules?
>
> Thanks,
> Ivan
> __
> 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] Re: kamailio Behind nat. How Record-Route should be added ？

[codenot--- via sr-users]

modparam("rr", "enable_double_rr", 1)
i tried. but it does't work
__
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: kamailio Behind nat. How Record-Route should be added ？

[codenot--- via sr-users]

i tried. but it does't work.
modparam("rr", "enable_double_rr", 1)
__
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: Software bill of materials (SBOM)

[Olle E. Johansson via sr-users]

> On 28 Sep 2023, at 12:36, Ivan Ribakov via sr-users 
>  wrote:
> 
> Hi Olle,
> 
> Yes, I realised by now that taking enabled Kamailio modules into account when 
> generating SBOM is too much to ask. I'd be ok with obtaining full list of 
> Kamailio dependencies (with transitive dependencies if possible) and then 
> manually filtering them based on module usage. Not sure if at any point 
> during Kamailio build process all sources + dependency sources/binaries are 
> present in the system for scanning/identification?
> 
> I'm mainly interested in listing (and validating licenses) and having a 
> general inventory. Any recommendations?
> 
I did try a beta of a tool in cyclonedx toolset for scanning C files and it 
crashed. Will try again, but so far I haven’t succeeded. 
I suggest we would need one SBOM based on a linux distro, like Debian and one
more generic based on C code and the versions of libraries we recommend. I have 
tried to add pointers to the various
third party dependencies in the READMEs over the years in a somewhat 
unstructured effort, but the information is there.
Maybe we can add the dependencies in a way that’s parseable in order to build 
an SBOM.

C code doesn’t have package management like Python, Perl, Go and others so it’s 
tricky to automate creation of SBOMs.

I think that the SBOM tree for the source code and dependencies would grow 
quite large.

Anyway -  at this time, I failed. :-)

/O
> 
> 
> 
> -- 
> Ivan Ribakov
> Software Engineer
> www.zaleos.net 
> 
> 
> 
> 
> 
> On Thu, 28 Sept 2023 at 10:58, Olle E. Johansson via sr-users 
> mailto:sr-users@lists.kamailio.org>> wrote:
>> Still digging through this. There are tools that can list your packages if 
>> you install Linux packages, i.e. Debian.
>> But there are no tools that can parse your kamailio config to really see 
>> what’s loaded and active.
>> 
>> It all depends on what you want to do with the SBOM - if you want to check 
>> for vulnerabilities, list licenses
>> or have a generic inventory.
>> 
>> /O
>> 
>>> On 28 Sep 2023, at 09:41, Henning Westerholt via sr-users 
>>> mailto:sr-users@lists.kamailio.org>> wrote:
>>> 
>>> Hello,
>>>  
>>> I think Olle was looking into that some month ago, maybe (when he reads it) 
>>> can share some of his research results if possible.
>>> You can also find some of his articles e.g., on his linkedin page.
>>>  
>>> Cheers,
>>>  
>>> Henning
>>>  
>>> -- 
>>> Henning Westerholt – https://skalatan.de/blog/
>>> Kamailio services – https://gilawa.com 
>>>  
>>> From: Ivan Ribakov via sr-users >> > 
>>> Sent: Mittwoch, 27. September 2023 21:11
>>> To: Kamailio (SER) - Users Mailing List >> >
>>> Cc: Ivan Ribakov mailto:i.riba...@zaleos.net>>
>>> Subject: [SR-Users] Software bill of materials (SBOM)
>>>  
>>> Any recommendations for a tool that can generate SBOM for a Kamailio 
>>> instance based on configured modules?
>>>  
>>> Thanks,
>>> Ivan
>>> __
>>> 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:

__
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] periodic could not resolve hostname

[Sergiu Pojoga via sr-users]

Aloha,

I'm experiencing this internal DNS problem with Kamailio, can't seem to
figure out what's causing it. Maybe someone can help.

Essentially, from time to time (one or two times a day) this situation
happens, starting with logs:

linux kamailio[773]: ERROR: uac [uac_reg.c:1163]: uac_reg_send(): failed to
send request for [some-uuid]
linux kamailio[773]: ERROR:  [core/resolve.c:1730]:
sip_hostport2su(): could not resolve hostname: "my.domain.net"
linux kamailio[773]: ERROR: tm [ut.h:309]: uri2dst2(): failed to resolve "
my.domain.net"
linux kamailio[773]: ERROR: tm [uac.c:480]: t_uac_prepare(): no socket found

# Do a Kamailio internal DNS lookup, no results found???
root@linux:~# kamcmd dns.lookup a my.domain.net
error: 400 - Not found

# Do a system DNS lookup. All good.
root@linux:~# dig my.domain.net
;; QUESTION SECTION:
;my.domain.net. IN A
;; ANSWER SECTION:
my.domain.net. 18000 IN A 192.168.0.1

# Delete internal Kamailio DNS record
root@linux:~# kamcmd dns.delete_a my.domain.net

# Lookup again right away. It's there, problem fixed. Why??
root@linux:~# kamcmd dns.lookup a my.domain.net
{
  name: my.domain.net
  type: A
  size_bytes: 120
  reference_counter: 2
  permanent: no
  expires: 7674
  last_used: 0
  negative_entry: no
  records: {
  {
 rr_idx: 0
 rr_ip: 192.168.0.1
 rr_permanent: no
 rr_expires: 7674
  }
   }
}
__
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: periodic could not resolve hostname

[Daniel-Constantin Mierla via sr-users]

Hello,

when this happens, can you look at the cache content and see if the
corresponding record has negative_entry set to yes? If that's the case,
the record was marked as bad (unresolvable due to a failed dns query or
maybe blocklisting activated on 503).

Cheers,
Daniel

On 28.09.23 14:48, Sergiu Pojoga via sr-users wrote:
> Aloha,
>
> I'm experiencing this internal DNS problem with Kamailio, can't seem
> to figure out what's causing it. Maybe someone can help.
>
> Essentially, from time to time (one or two times a day) this situation
> happens, starting with logs:
>
> linux kamailio[773]: ERROR: uac [uac_reg.c:1163]: uac_reg_send():
> failed to send request for [some-uuid]
> linux kamailio[773]: ERROR:  [core/resolve.c:1730]:
> sip_hostport2su(): could not resolve hostname: "my.domain.net
> "
> linux kamailio[773]: ERROR: tm [ut.h:309]: uri2dst2(): failed to
> resolve "my.domain.net "
> linux kamailio[773]: ERROR: tm [uac.c:480]: t_uac_prepare(): no socket
> found
>
> # Do a Kamailio internal DNS lookup, no results found???
> root@linux:~# kamcmd dns.lookup a my.domain.net 
> error: 400 - Not found
>
> # Do a system DNS lookup. All good.
> root@linux:~# dig my.domain.net 
> ;; QUESTION SECTION:
> ;my.domain.net . IN A
> ;; ANSWER SECTION:
> my.domain.net . 18000 IN A 192.168.0.1
>
> # Delete internal Kamailio DNS record
> root@linux:~# kamcmd dns.delete_a my.domain.net 
>
> # Lookup again right away. It's there, problem fixed. Why??
> root@linux:~# kamcmd dns.lookup a my.domain.net 
> {
>   name: my.domain.net 
>   type: A
>   size_bytes: 120
>   reference_counter: 2
>   permanent: no
>   expires: 7674
>   last_used: 0
>   negative_entry: no
>   records: {
>       {
>          rr_idx: 0
>          rr_ip: 192.168.0.1
>          rr_permanent: no
>          rr_expires: 7674
>       }
>    }
> }
>
> __
> 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:

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy - Training Services -- asipto.com
Kamailio World Conference - kamailioworld.com
__
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: Software bill of materials (SBOM)

[Ivan Ribakov via sr-users]

I see, thanks for sharing your experience Olle.

I'm no autoconf expert - does anyone know if it's possible to dump more or
less concise list of all linked libraries used either during build
configuration or the actual build process? I'm thinking that should be
pretty close to the source of truth for direct dependencies involved and
could act as a starting point for a manual process of figuring out versions
and licenses.

On Thu, 28 Sept 2023, 13:13 Olle E. Johansson,  wrote:

>
>
> On 28 Sep 2023, at 12:36, Ivan Ribakov via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
> Hi Olle,
>
> Yes, I realised by now that taking enabled Kamailio modules into account
> when generating SBOM is too much to ask. I'd be ok with obtaining full list
> of Kamailio dependencies (with transitive dependencies if possible) and
> then manually filtering them based on module usage. Not sure if at any
> point during Kamailio build process all sources + dependency
> sources/binaries are present in the system for scanning/identification?
>
> I'm mainly interested in listing (and validating licenses) and having a
> general inventory. Any recommendations?
>
> I did try a beta of a tool in cyclonedx toolset for scanning C files and
> it crashed. Will try again, but so far I haven’t succeeded.
> I suggest we would need one SBOM based on a linux distro, like Debian and
> one
> more generic based on C code and the versions of libraries we recommend. I
> have tried to add pointers to the various
> third party dependencies in the READMEs over the years in a somewhat
> unstructured effort, but the information is there.
> Maybe we can add the dependencies in a way that’s parseable in order to
> build an SBOM.
>
> C code doesn’t have package management like Python, Perl, Go and others so
> it’s tricky to automate creation of SBOMs.
>
> I think that the SBOM tree for the source code and dependencies would grow
> quite large.
>
> Anyway -  at this time, I failed. :-)
>
> /O
>
>
>
>
> --
> Ivan Ribakov
> Software Engineer
> www.zaleos.net
>
>
>
>
>
> On Thu, 28 Sept 2023 at 10:58, Olle E. Johansson via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>> Still digging through this. There are tools that can list your packages
>> if you install Linux packages, i.e. Debian.
>> But there are no tools that can parse your kamailio config to really see
>> what’s loaded and active.
>>
>> It all depends on what you want to do with the SBOM - if you want to
>> check for vulnerabilities, list licenses
>> or have a generic inventory.
>>
>> /O
>>
>> On 28 Sep 2023, at 09:41, Henning Westerholt via sr-users <
>> sr-users@lists.kamailio.org> wrote:
>>
>> Hello,
>>
>> I think Olle was looking into that some month ago, maybe (when he reads
>> it) can share some of his research results if possible.
>> You can also find some of his articles e.g., on his linkedin page.
>>
>> Cheers,
>>
>> Henning
>>
>> --
>> Henning Westerholt – https://skalatan.de/blog/
>> Kamailio services – https://gilawa.com
>>
>> *From:* Ivan Ribakov via sr-users 
>> *Sent:* Mittwoch, 27. September 2023 21:11
>> *To:* Kamailio (SER) - Users Mailing List 
>> *Cc:* Ivan Ribakov 
>> *Subject:* [SR-Users] Software bill of materials (SBOM)
>>
>> Any recommendations for a tool that can generate SBOM for a Kamailio
>> instance based on configured modules?
>>
>> Thanks,
>> Ivan
>> __
>> 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:
>
>
>
__
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: Software bill of materials (SBOM)

[Daniel-Constantin Mierla via sr-users]

On 28.09.23 13:13, Olle E. Johansson via sr-users wrote:
>
>
>> On 28 Sep 2023, at 12:36, Ivan Ribakov via sr-users
>>  wrote:
>>
>> Hi Olle,
>>
>> Yes, I realised by now that taking enabled Kamailio modules into
>> account when generating SBOM is too much to ask. I'd be ok with
>> obtaining full list of Kamailio dependencies (with transitive
>> dependencies if possible) and then manually filtering them based on
>> module usage. Not sure if at any point during Kamailio build process
>> all sources + dependency sources/binaries are present in the system
>> for scanning/identification?
>>
>> I'm mainly interested in listing (and validating licenses) and having
>> a general inventory. Any recommendations?
>>
> I did try a beta of a tool in cyclonedx toolset for scanning C files
> and it crashed. Will try again, but so far I haven’t succeeded. 
> I suggest we would need one SBOM based on a linux distro, like Debian
> and one
> more generic based on C code and the versions of libraries we
> recommend. I have tried to add pointers to the various
> third party dependencies in the READMEs over the years in a somewhat
> unstructured effort, but the information is there.
> Maybe we can add the dependencies in a way that’s parseable in order
> to build an SBOM.
>
> C code doesn’t have package management like Python, Perl, Go and
> others so it’s tricky to automate creation of SBOMs.
>
> I think that the SBOM tree for the source code and dependencies would
> grow quite large.
>
> Anyway -  at this time, I failed. :-)

Maybe leveraging ldd in a first phase can help building the chain of
dependencies:

$ ldd src/kamailio
    linux-vdso.so.1 (0x91745000)
    libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x90f3)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x90d8)
    /lib/ld-linux-aarch64.so.1 (0x9170c000)

$ ldd src/modules/tls/tls.so
    linux-vdso.so.1 (0x96e5d000)
    libssl.so.3 => /lib/aarch64-linux-gnu/libssl.so.3 (0x96ca)
    libcrypto.so.3 => /lib/aarch64-linux-gnu/libcrypto.so.3
(0x968b)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x9670)
    /lib/ld-linux-aarch64.so.1 (0x96e24000)

$ ldd /lib/aarch64-linux-gnu/libcrypto.so.3
    linux-vdso.so.1 (0x9952c000)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x98f5)
    /lib/ld-linux-aarch64.so.1 (0x994f3000)

Might take some time, a matter of what modules are used, but if really
needed, the process should be doable manually.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com
__
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: periodic could not resolve hostname

[Sergiu Pojoga via sr-users]

Your suggestion led me to review the DNS settings and found
`dns_cache_negative_ttl=600` which kind of matches the occasional dns
outage period. Changes the value to 0 (disabled). Will see how it goes, so
far no more errors of this kind.

Thanks again Daniel.



On Thu, Sep 28, 2023 at 1:02 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> when this happens, can you look at the cache content and see if the
> corresponding record has negative_entry set to yes? If that's the case, the
> record was marked as bad (unresolvable due to a failed dns query or maybe
> blocklisting activated on 503).
>
> Cheers,
> Daniel
> On 28.09.23 14:48, Sergiu Pojoga via sr-users wrote:
>
> Aloha,
>
> I'm experiencing this internal DNS problem with Kamailio, can't seem to
> figure out what's causing it. Maybe someone can help.
>
> Essentially, from time to time (one or two times a day) this situation
> happens, starting with logs:
>
> linux kamailio[773]: ERROR: uac [uac_reg.c:1163]: uac_reg_send(): failed
> to send request for [some-uuid]
> linux kamailio[773]: ERROR:  [core/resolve.c:1730]:
> sip_hostport2su(): could not resolve hostname: "my.domain.net"
> linux kamailio[773]: ERROR: tm [ut.h:309]: uri2dst2(): failed to resolve "
> my.domain.net"
> linux kamailio[773]: ERROR: tm [uac.c:480]: t_uac_prepare(): no socket
> found
>
> # Do a Kamailio internal DNS lookup, no results found???
> root@linux:~# kamcmd dns.lookup a my.domain.net
> error: 400 - Not found
>
> # Do a system DNS lookup. All good.
> root@linux:~# dig my.domain.net
> ;; QUESTION SECTION:
> ;my.domain.net. IN A
> ;; ANSWER SECTION:
> my.domain.net. 18000 IN A 192.168.0.1
>
> # Delete internal Kamailio DNS record
> root@linux:~# kamcmd dns.delete_a my.domain.net
>
> # Lookup again right away. It's there, problem fixed. Why??
> root@linux:~# kamcmd dns.lookup a my.domain.net
> {
>   name: my.domain.net
>   type: A
>   size_bytes: 120
>   reference_counter: 2
>   permanent: no
>   expires: 7674
>   last_used: 0
>   negative_entry: no
>   records: {
>   {
>  rr_idx: 0
>  rr_ip: 192.168.0.1
>  rr_permanent: no
>  rr_expires: 7674
>   }
>}
> }
>
> __
> 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:
>
> --
> Daniel-Constantin Mierla (@ asipto.com)twitter.com/miconda -- 
> linkedin.com/in/miconda
> Kamailio Consultancy - Training Services -- asipto.com
> Kamailio World Conference - kamailioworld.com
>
>
__
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: CANCEL first, then INVITE.

[James Lipski via sr-users]

Hello,

As with my previous update, I'm using the skeleton configurations (with minor 
changes, such as defining an external voicemail destination) just for testing 
purposes. With the skeleton configurations, I'm still seeing that the INVITE 
packet to the voicemail server sent first, and then the CANCEL to the second 
endpoint (please see SIP trace below). In this call example the second endpoint 
is a PBX, and is configured to route unanswered calls towards it's own local 
voicemail system. Is there a way to switch the behaviour so that the CANCEL 
packet towards endpoint 2 is sent FIRST; and then the INVITE to the voicemail 
system second? Thank you. 

10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.

2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060
INVITE sip:1010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: ;tag=pqxa29jt8v
t: 
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: ;reg-id=1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Proxy-Authorization: Digest 
username="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315

v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP 
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: ;tag=pqxa29jt8v
t: 
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0


2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678
INVITE 
sip:1010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
 SIP/2.0
Record-Route: 
Via: SIP/2.0/UDP 
10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: ;tag=pqxa29jt8v
t: 
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: 
;reg-id=1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Session-Expires: 3600
Min-SE: 90
c: application/sdp
l: 315

v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117
s=call
c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: 
f: ;tag=pqxa29jt8v
t: ;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0

2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: 
f: ;tag=pqxa29jt8v
t: ;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: 
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247

v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metrics
a=sendrecv

2023/09/28 15:41:39.172272 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: 
f: ;tag=pqxa29jt8v
t: ;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
m: 
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
c: application/sdp
l: 247

v=0
o=- 1982229263 1982229263 IN IP4 10.0.0.188
s=-
c=IN IP4 10.0.0.188
t=0 0
m=audio 59112 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-xr:rcvr-rtt=all voip-metri

[SR-Users] Re: CANCEL first, then INVITE.

[Ben Kaufman via sr-users]

I can reproduce this behavior easily with the config below, but I'm not quite 
sure how/why it matters.



request_route {
xinfo("[$ru] recieved\n");

$rd = "target2";
append_branch("sip:$rU@target1", "1.0");

t_load_contacts();
t_next_contacts();

t_on_failure("MANAGE_FAILURE");
t_on_branch("MANAGE_BRANCH");
t_set_fr(5000);
t_relay();
exit;
}

branch_route[MANAGE_BRANCH] {
xinfo("Sending [$ru]\n");
}

failure_route[MANAGE_FAILURE] {
if ( t_branch_timeout() ) {
xinfo("Branch timed out.\n");
}

if ( !t_next_contacts() ) {
send_reply("503", "Server Error");
exit;
}

t_on_failure("MANAGE_FAILURE");
t_relay();
}

-Original Message-
From: James Lipski via sr-users  
Sent: Thursday, September 28, 2023 3:08 PM
To: Kamailio (SER) - Users Mailing List 
Cc: James Lipski 
Subject: [SR-Users] Re: CANCEL first, then INVITE.

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.


Hello,

As with my previous update, I'm using the skeleton configurations (with minor 
changes, such as defining an external voicemail destination) just for testing 
purposes. With the skeleton configurations, I'm still seeing that the INVITE 
packet to the voicemail server sent first, and then the CANCEL to the second 
endpoint (please see SIP trace below). In this call example the second endpoint 
is a PBX, and is configured to route unanswered calls towards it's own local 
voicemail system. Is there a way to switch the behaviour so that the CANCEL 
packet towards endpoint 2 is sent FIRST; and then the INVITE to the voicemail 
system second? Thank you.

10.0.0.117 --- snom (endpoint 1)
10.0.0.177 --- kamailio
10.0.0.188 --- PBX (endpoint 2)
10.0.0.26 --- external voicemail system.

2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE 
sip:1010@10.0.0.177 SIP/2.0
v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
f: ;tag=pqxa29jt8v
t: 
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD785/10.1.159.12
m: ;reg-id=1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Proxy-Authorization: Digest 
username="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
",algorithm=MD5
c: application/sdp
l: 315

v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
SIP/2.0 100 trying -- your call is important to us
v: SIP/2.0/UDP 
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
f: ;tag=pqxa29jt8v
t: 
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Content-Length: 0


2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678 INVITE 
sip:1010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
 SIP/2.0
Record-Route: 
Via: SIP/2.0/UDP 
10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
f: ;tag=pqxa29jt8v
t: 
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
Max-Forwards: 69
User-Agent: snomD785/10.1.159.12
m: 
;reg-id=1
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, replaces, from-change
Session-Expires: 3600
Min-SE: 90
c: application/sdp
l: 315

v=0
o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
t=0 0
m=audio 61370 RTP/AVP 9 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

2023/09/28 15:41:39.126941 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 100 Trying
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: 
f: ;tag=pqxa29jt8v
t: ;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVITE
l: 0

2023/09/28 15:41:39.171314 10.0.0.188:5678 -> 10.0.0.177:5060
SIP/2.0 183 Session Progress
v: SIP/2.0/UDP 10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0
v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274
Record-Route: 
f: ;tag=pqxa29jt8v
t: ;tag=c3579c1a01
i: f1d61565275f-tqgd64ng8qmq
CSeq: 2 INVIT

[SR-Users] Re: CANCEL first, then INVITE.

[Ben Kaufman via sr-users]

Also, since a picture is worth a thousand words, it can be seen here that the 
INVITE for the new branch is sent before the CANCEL of the earlier branch.  
Again, I'm not sure why this would make any difference, but it does seem to be 
the current behavior.


[A screenshot of a computer screen  Description automatically generated]




-Original Message-
From: Ben Kaufman via sr-users 
Sent: Thursday, September 28, 2023 5:05 PM
To: Kamailio (SER) - Users Mailing List 
Cc: James Lipski ; Ben Kaufman 
Subject: [SR-Users] Re: CANCEL first, then INVITE.



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.





I can reproduce this behavior easily with the config below, but I'm not quite 
sure how/why it matters.







request_route {

xinfo("[$ru] recieved\n");



$rd = "target2";

append_branch("sip:$rU@target1", "1.0");



t_load_contacts();

t_next_contacts();



t_on_failure("MANAGE_FAILURE");

t_on_branch("MANAGE_BRANCH");

t_set_fr(5000);

t_relay();

exit;

}



branch_route[MANAGE_BRANCH] {

xinfo("Sending [$ru]\n");

}



failure_route[MANAGE_FAILURE] {

if ( t_branch_timeout() ) {

xinfo("Branch timed out.\n");

}



if ( !t_next_contacts() ) {

send_reply("503", "Server Error");

exit;

}



t_on_failure("MANAGE_FAILURE");

t_relay();

}



-Original Message-

From: James Lipski via sr-users 
mailto:sr-users@lists.kamailio.org>>

Sent: Thursday, September 28, 2023 3:08 PM

To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>

Cc: James Lipski mailto:jameslip...@protonmail.com>>

Subject: [SR-Users] Re: CANCEL first, then INVITE.



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.





Hello,



As with my previous update, I'm using the skeleton configurations (with minor 
changes, such as defining an external voicemail destination) just for testing 
purposes. With the skeleton configurations, I'm still seeing that the INVITE 
packet to the voicemail server sent first, and then the CANCEL to the second 
endpoint (please see SIP trace below). In this call example the second endpoint 
is a PBX, and is configured to route unanswered calls towards it's own local 
voicemail system. Is there a way to switch the behaviour so that the CANCEL 
packet towards endpoint 2 is sent FIRST; and then the INVITE to the voicemail 
system second? Thank you.



10.0.0.117 --- snom (endpoint 1)

10.0.0.177 --- kamailio

10.0.0.188 --- PBX (endpoint 2)

10.0.0.26 --- external voicemail system.



2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE 
sip:1010@10.0.0.177 SIP/2.0

v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport

f: ;tag=pqxa29jt8v

t: 

i: f1d61565275f-tqgd64ng8qmq

CSeq: 2 INVITE

Max-Forwards: 70

User-Agent: snomD785/10.1.159.12

m: ;reg-id=1

Accept: application/sdp

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
MESSAGE, INFO, UPDATE

Allow-Events: talk, hold, refer, call-info

Supported: timer, replaces, from-change

Session-Expires: 3600

Min-SE: 90

Proxy-Authorization: Digest 
username="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4

",algorithm=MD5

c: application/sdp

l: 315



v=0

o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117

t=0 0

m=audio 61370 RTP/AVP 9 0 8 18 101

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

a=sendrecv



2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274

SIP/2.0 100 trying -- your call is important to us

v: SIP/2.0/UDP 
10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117

f: ;tag=pqxa29jt8v

t: 

i: f1d61565275f-tqgd64ng8qmq

CSeq: 2 INVITE

Content-Length: 0





2023/09/28 15:41:39.125338 10.0.0.177:5060 -> 10.0.0.188:5678 INVITE 
sip:1010@10.0.0.188:5678;transport=udp;line=aab32389;alias=10.0.0.188~5678~1
 SIP/2.0

Record-Route: 

Via: SIP/2.0/UDP 
10.0.0.177;branch=z9hG4bK87d3.36c49e4bbd41f8c5625007842e35ce3a.0

v: SIP/2.0/UDP 
10.0.0.117:40274;received=10.0.0.117;branch=z9hG4bK-30wsteb4v1cl;rport=40274

f: ;tag=pqxa29jt8v

t: 

i: f1d61565275f-tqgd64ng8qmq

CSeq: 2 INVITE

Max-Forwards: 69

User-Agent: snomD785/10.1.159.12

m: 
;reg-id=1

Accept: application/sdp

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
MESSAGE, INFO, UPDATE

Allow-Events: talk, hold, refer, call-info

Supported: timer, replaces, from-change

Session-Expires: 3600

Min-SE: 90

c: application/sdp

l: 315



v=0

o=root 1457342879 1457342879 IN IP4 10.0.0.

[SR-Users] Re: CANCEL first, then INVITE.

[James Lipski via sr-users]

Hello,

To add to my previous reply, the reason for asking whether if it's possible to 
change the order of transactions (CANCEL first, then INVITE) is I've ran into 
issues where 2 200OKs are being received roughly at the same time; such as the 
call example from my previous post, where the receiving UA sends a 200OK for 
CSeq INVITE and a 200OK for CSeq CANCEL (only tested with 3CX, and Asterisk as 
the receiving UA); which seems to cause a conflict.

When testing this call scenario with another platform (an aged proxy platform 
that hopefully will be replaced with kamailio), when the call forks, it sends a 
CANCEL first to the second endpoint and the INVITE to the voicemail server.

Thank you.

--- Original Message ---
On Thursday, September 28th, 2023 at 6:13 PM, Ben Kaufman  
wrote:

> Also, since a picture is worth a thousand words, it can be seen here that the 
> INVITE for the new branch is sent before the CANCEL of the earlier branch. 
> Again, I’m not sure why this would make any difference, but it does seem to 
> be the current behavior.
>
> [A screenshot of a computer screen
>
> Description automatically generated]
>
> -Original Message-
> From: Ben Kaufman via sr-users 
> Sent: Thursday, September 28, 2023 5:05 PM
> To: Kamailio (SER) - Users Mailing List 
> Cc: James Lipski ; Ben Kaufman 
> 
> Subject: [SR-Users] Re: CANCEL first, then INVITE.
>
> 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.
>
> I can reproduce this behavior easily with the config below, but I'm not quite 
> sure how/why it matters.
>
> request_route {
>
> xinfo("[$ru] recieved\n");
>
> $rd = "target2";
>
> append_branch("sip:$rU@target1", "1.0");
>
> t_load_contacts();
>
> t_next_contacts();
>
> t_on_failure("MANAGE_FAILURE");
>
> t_on_branch("MANAGE_BRANCH");
>
> t_set_fr(5000);
>
> t_relay();
>
> exit;
>
> }
>
> branch_route[MANAGE_BRANCH] {
>
> xinfo("Sending [$ru]\n");
>
> }
>
> failure_route[MANAGE_FAILURE] {
>
> if ( t_branch_timeout() ) {
>
> xinfo("Branch timed out.\n");
>
> }
>
> if ( !t_next_contacts() ) {
>
> send_reply("503", "Server Error");
>
> exit;
>
> }
>
> t_on_failure("MANAGE_FAILURE");
>
> t_relay();
>
> }
>
> -Original Message-
>
> From: James Lipski via sr-users 
>
> Sent: Thursday, September 28, 2023 3:08 PM
>
> To: Kamailio (SER) - Users Mailing List 
>
> Cc: James Lipski 
>
> Subject: [SR-Users] Re: CANCEL first, then INVITE.
>
> 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.
>
> Hello,
>
> As with my previous update, I'm using the skeleton configurations (with minor 
> changes, such as defining an external voicemail destination) just for testing 
> purposes. With the skeleton configurations, I'm still seeing that the INVITE 
> packet to the voicemail server sent first, and then the CANCEL to the second 
> endpoint (please see SIP trace below). In this call example the second 
> endpoint is a PBX, and is configured to route unanswered calls towards it's 
> own local voicemail system. Is there a way to switch the behaviour so that 
> the CANCEL packet towards endpoint 2 is sent FIRST; and then the INVITE to 
> the voicemail system second? Thank you.
>
> 10.0.0.117 --- snom (endpoint 1)
>
> 10.0.0.177 --- kamailio
>
> 10.0.0.188 --- PBX (endpoint 2)
>
> 10.0.0.26 --- external voicemail system.
>
> 2023/09/28 15:41:39.122897 10.0.0.117:40274 -> 10.0.0.177:5060 INVITE 
> sip:1010@10.0.0.177 SIP/2.0
>
> v: SIP/2.0/UDP 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport
>
> f: ;tag=pqxa29jt8v
>
> t: 
>
> i: f1d61565275f-tqgd64ng8qmq
>
> CSeq: 2 INVITE
>
> Max-Forwards: 70
>
> User-Agent: snomD785/10.1.159.12
>
> m: ;reg-id=1
>
> Accept: application/sdp
>
> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, 
> MESSAGE, INFO, UPDATE
>
> Allow-Events: talk, hold, refer, call-info
>
> Supported: timer, replaces, from-change
>
> Session-Expires: 3600
>
> Min-SE: 90
>
> Proxy-Authorization: Digest 
> username="1006",realm="10.0.0.177",nonce="ZRXYH2UV1vNTJ01Zmy97xZsd43iZmRNW",uri="sip:1010@10.0.0.177",response="4a1d80ae375ae8d56d7b7c602e5bbcd4
>
> ",algorithm=MD5
>
> c: application/sdp
>
> l: 315
>
> v=0
>
> o=root 1457342879 1457342879 IN IP4 10.0.0.117 s=call c=IN IP4 10.0.0.117
>
> t=0 0
>
> m=audio 61370 RTP/AVP 9 0 8 18 101
>
> a=rtpmap:9 G722/8000
>
> a=rtpmap:0 PCMU/8000
>
> a=rtpmap:8 PCMA/8000
>
> a=rtpmap:18 G729/8000
>
> a=fmtp:18 annexb=no
>
> a=rtpmap:101 telephone-event/8000
>
> a=fmtp:101 0-15
>
> a=ptime:20
>
> a=sendrecv
>
> 2023/09/28 15:41:39.124438 10.0.0.177:5060 -> 10.0.0.117:40274
>
> SIP/2.0 100 trying -- your call is important to us
>
> v: SIP/2.0/UDP 
> 10.0.0.117:40274;branch=z9hG4bK-30wsteb4v1cl;rport=40274;received=10.0.0.117
>
> f: ;tag=pqxa29jt8v
>
> t: 
>
> i: f1d61565275f-tqgd64ng8