Hi there,
Question: how can I advertise and later match multiple FQDNs per socket?
Example:
auto_aliases=no
alias="mydomain.net":5060
alias="mydomain.net":5061
alias="client1.mydomain.net":5060
alias="client1.mydomain.net":5061
# looks like I can advertise only one address per socket?
listen=udp
On 24.03.20 18:11, Ben Kaufman wrote:
> I may be misinterpreting this, but RFC3261 section 18.2.2 ( Sending Responses
> ):
>
> - The server transport uses the value of the top Via header field in
> - order to determine where to send a response. It MUST follow the
> - following process:
> -
> -
Hello Daniel,
In fact we are using dmq + dialog for dlg profile replication, we haven't
noticed yet the issue described on the ticket that you mentioned but it
worth apply those patches for sure.
If I detect something wrong regarding to dmq+dialog I will let you know.
Thank you again for your gr
I may be misinterpreting this, but RFC3261 section 18.2.2 ( Sending Responses ):
- The server transport uses the value of the top Via header field in
- order to determine where to send a response. It MUST follow the
- following process:
-
- o If the "sent-protocol" is a reliable transport pr
Yes, tcp is typically using ephemeral source port, in the way that is
allocated by the tcp stack/kernel, not easy to be specified by the
client app. But the client app can get the local (ephemeral) port after
connect() using getsockname() and use it to build the SIP message that
is going to be sent
Shouldn't *TCP* use an ephemeral source port, and expect replies to be to the
source port?
Ben Kaufman
-Original Message-
From: sr-users On Behalf Of
Daniel-Constantin Mierla
Sent: Tuesday, March 24, 2020 9:01 AM
To: Kamailio (SER) - Users Mailing List ; Juha
Heinanen
Subject: Re:
Hello,
this is the test to detect devices behind NAT that use STUN, so they
discover properly the public IP of the NAT router, but the port
allocation is different for STUN and SIP traffic.
If you have an asymmetric signalling client, then this test is not
useful -- actually nat traversal cannot
Hello,
probably you can use an htable to store that the ds_load_remove() was
called for a specific call id, but we can make that error log message to
debug level, there can be cross BYEs at the end of a call resulting in
same situation.
Cheers,
Daniel
On 24.03.20 13:55, harneet singh wrote:
> Th
In kamailio/etc/kamailio.cfg NAT test is based on nat_uac_test("19").
19 includes test 16:
16 - Test if the source port is different from the port in the “Via”
header. If the “Via” header contains no port, it uses the default SIP
port 5060
Based on a couple of tests using baresip, looks lik
Thanks Daniel,
Your suggestion was very helpful. I am now able to see the dialog load go
down on Dispatcher as expected in case of session expiry.
Just an extra error log is what I keep getting per occurrence. I believe
the reason for this is that the event_route[tm:local-request] will be
called t
Hello,
we have to update the docs for timeout_avp in sst module to reflect this
behaviour.
Related to the dispatcher load, try using the
event_route[tm:local-request], inside it you can catch the BYE generated
by Kamailio.
It could be a good addition to make dispatcher decrease the load also
fro
Hi Daniel,
Your timely response is much appreciated. I was able to fetch the
Session-Expires value from the INVITE's SE header, albeit with a minor
modification. I guess there were missing "(Double Quotes)" in the argument
to is_present_hf. After fixing that, things worked and the Dialog Expiry is
Hello,
ok, thanks for testing and feedback, it will be backported.
If you use dialog with dmq, you may want to test also:
* https://github.com/kamailio/kamailio/issues/2224#issuecomment-602730307
Cheers,
Daniel
On 23.03.20 23:37, José Seabra wrote:
> Hello Daniel,
>
> Thank you for your supp
I just added basic info about them:
*
https://www.kamailio.org/wiki/cookbooks/devel/transformations#surlencodeparam
You can add examples and more docs -- that would be appreciated.
Cheers,
Daniel
On 24.03.20 09:14, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> the s.urlencode.param/s.urldec
Hello,
the s.urlencode.param/s.urldecode.param transformations should be good
to use, likely they were forgotten to be added in the wiki -- the code
for them was a contribution merged like 7 years ago.
Cheers,
Daniel
On 23.03.20 20:54, João Vitor Arruda wrote:
> Hello,
>
> I was looking in the t
15 matches
Mail list logo