t
Cc: Brooks Bridges
Subject: RE: [SR-Users] t_relay changing source IP?
Hello,
in case of UDP Kamailio should use the process which received the message to
also send it out (if you do not use anything like forcing a particular send
socket or multi-homed).
Anything unusual if you look e.g. w
, October 26, 2021 5:00 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_relay changing source IP?
We are using UDP everywhere currently. TCP is on the roadmap, but not
implemented yet except for xhttp_rpc communication.
-Original Message-
From: Daniel-Constantin
nday, October 25, 2021 3:48 PM
> To: Kamailio (SER) - Users Mailing List
> Subject: RE: [SR-Users] t_relay changing source IP?
>
> Correct.
>
> listen=lo:5060
> listen=eth0:5060
> listen=eth1:5060
> listen=XXX.XXX.XXX.XXX:5060 (<--- HA IP)
>
> -Original Mes
gt; To: Kamailio (SER) - Users Mailing List
> Subject: RE: [SR-Users] t_relay changing source IP?
>
> Correct.
>
> listen=lo:5060
> listen=eth0:5060
> listen=eth1:5060
> listen=XXX.XXX.XXX.XXX:5060 (<--- HA IP)
>
> -Original Message-
> From: sr-users On B
eason. I am not a fan of static configuration of things
> like that in shared environments.
>
> -Original Message-
> From: Brooks Bridges
> Sent: Monday, October 25, 2021 3:48 PM
> To: Kamailio (SER) - Users Mailing List
> Subject: RE: [SR-Users] t_relay changing
o:5060
> listen=eth0:5060
> listen=eth1:5060
> listen=XXX.XXX.XXX.XXX:5060 (<--- HA IP)
>
> -Original Message-
> From: sr-users On Behalf Of Alex
> Balashov
> Sent: Monday, October 25, 2021 3:35 PM
> To: Kamailio (SER) - Users Mailing List
> Subject: R
things like
that in shared environments.
-Original Message-
From: Brooks Bridges
Sent: Monday, October 25, 2021 3:48 PM
To: Kamailio (SER) - Users Mailing List
Subject: RE: [SR-Users] t_relay changing source IP?
Correct.
listen=lo:5060
listen=eth0:5060
listen=eth1:5060
listen
Correct.
listen=lo:5060
listen=eth0:5060
listen=eth1:5060
listen=XXX.XXX.XXX.XXX:5060 (<--- HA IP)
-Original Message-
From: sr-users On Behalf Of Alex Balashov
Sent: Monday, October 25, 2021 3:35 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_relay chang
inception and this has just recently become an
> issue.
>
> -Original Message-
> From: sr-users On Behalf Of Alex
> Balashov
> Sent: Monday, October 25, 2021 3:19 PM
> To: Kamailio (SER) - Users Mailing List
> Subject: Re: [SR-Users] t_relay changing sou
That's been set to 0 since inception and this has just recently become an issue.
-Original Message-
From: sr-users On Behalf Of Alex Balashov
Sent: Monday, October 25, 2021 3:19 PM
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_relay changing source IP?
Doe
Does the behaviour differ depending on whether ‘mhomed’ is on?
https://www.kamailio.org/wiki/cookbooks/5.5.x/core#mhomed
> On Oct 25, 2021, at 6:15 PM, Brooks Bridges wrote:
>
> So we have a box that's bound to all interfaces on the server, and one
> specific IP address (that is an HA IP), and
Found an old discussion about this issue,
https://lists.kamailio.org/pipermail/sr-users/2010-April/027703.html
It says that the t_relay error is because after drop of single/all
branches, there's none left to relay. However, it is not clear what the
solution is, as t_relay failure won't trigger a
Hello,
before t_relay() you can't see what is going to the network, because
some headers are added when knowing target address and local socket
(e.g, Via, Record-Route). You can use onsend_route for seeing the
request just before writing to the network.
https://www.kamailio.org/wiki/cookbooks/dev
hi!
one of the ways (not related to t_relay, rather general solution), use this
event_route:
https://www.kamailio.org/docs/modules/5.0.x/modules/corex.html#async.evr.network_io
in the event route to print the message's content you can use $mb to print
what is sent/received.
hope this helped.
ch
Many thanks, I've managed to handle a call properly.
I really want to thank Daniel, and all that have helped on this subject.
Regards
J.
On Mon, Jan 8, 2018 at 11:42 PM, Joel Serrano wrote:
> Just a hint here, try setting $du and then t_relay...
>
> On Mon, Jan 8, 2018 at 11:55 Jean Cérien wr
Just a hint here, try setting $du and then t_relay...
On Mon, Jan 8, 2018 at 11:55 Jean Cérien wrote:
>
> Hi
>
> While I'm trying to get the provider fix the SBC, I am implementing the
> workaround.
>
> Almost done here, storing and retrieving the correct address is fine, but
> when I set my $ru
Hi
While I'm trying to get the provider fix the SBC, I am implementing the
workaround.
Almost done here, storing and retrieving the correct address is fine, but
when I set my $ru to the corrected value (asterisk IP), the t_relay still
sends the packet to the kamailio IP -
$ru="sip:number@asteris
Many, many thanks !
I've posted the full dialog unredacted here: https://pastebin.com/EE9iwgZf
The OK from Kamailio back to VOIP provider has
Record-Route:
Contact:
So my understanding is that the ACK should be
ACK sip:NUMBER@ASTERISKIP:5060 SIP/2.0
and not
ACK sip:NUMBER@KAMAILIOIP:5060
Hi,
On Mon, Jan 8, 2018 at 2:39 PM, Jean Cérien wrote:
>
> Thanks for this answer. The voip provider is not really eager to alter its
> SBC as it considers that the contact field is not mandatory in the ACK. The
> RFC states (section 8.1.1.8)
>
The problem is not that the ACK doesn't carry a Co
Thanks for this answer. The voip provider is not really eager to alter its
SBC as it considers that the contact field is not mandatory in the ACK. The
RFC states (section 8.1.1.8)
The Contact header field MUST be present and contain exactly one SIP
or SIPS URI in any request that can result in
Hello,
if one side of the call is breaking the contact, then a workaround in
kamailio is to use htable to store the contact address per
callid+from/to tag. I encountered couple of times such situation and the
condition in the config file is like:
- if the r-uri of ACK (BYE, etc...) matches "mys
Hi Jean,
as pointed out earlier, the ACK is probably broken. Every packet after the
200 OK should have the contact of the 200 OK in the Request URI. Your
example packet carries probably the original request URI, which is most
certainly wrong, exept if you use some topology hiding.
This is somethi
traffic look
> like? Are Asterisk and Kamailio on different Servers?
>
>
>
> -Steve
>
>
>
> *From:* sr-users [mailto:sr-users-boun...@lists.kamailio.org] *On Behalf
> Of *Jean Cérien
> *Sent:* Tuesday, January 2, 2018 8:04 AM
> *To:* Daniel-Constantin Mierla
&
Cc: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_relay dying ?
Hello
Any suggestion as to why the ACK is not forwarded to the Asterisk box and stays
on the kamailio server ?
REgards
J.
On Tue, Dec 26, 2017 at 11:49 AM, Jean Cérien
mailto:cerien.j...@gmail.com>> wrote:
Hello
Any suggestion as to why the ACK is not forwarded to the Asterisk box and
stays on the kamailio server ?
REgards
J.
On Tue, Dec 26, 2017 at 11:49 AM, Jean Cérien wrote:
>
> Daniel
>
> Many thanks for your help in this holidays season.
>
> The ACK is now going out and executions follows,
Pay attention to the answer 200 ok from asterisk and the one that kamailio
sends to the provider side. The ACK specifies the values taken from the Contact
header in the response 200 OK
>Вторник, 26 декабря 2017, 19:54 +03:00 от Евгений Голей :
>
>Daniel hello!
>
>This is because the provider mu
Daniel hello!
This is because the provider must respond to the ACK not with KAMAILIOIP: 5060
SIP / 2.0, and in the domain part, asterisk addresses must be specified.
Send the config.
Evgeniy
>Вторник, 26 декабря 2017, 18:53 +03:00 от Jean Cérien :
>
>
>Daniel
>
>Many thanks for your help in t
Daniel
Many thanks for your help in this holidays season.
The ACK is now going out and executions follows, which is good, however,
the ack is sent to the Kamailio box itself and not actually forwarded to
the asterisk (I've attached at the end of this message the initial invite,
received ACK and
Hi
You said that only thing changed is the Provider chanded their end.
Have you compared the previous signaling to the current ?
Previous I mean before provider change their switch.
Could there be some difference and that causes this error.
Tomi
On 21 Dec 2017, at 23.01, Jean Cérien wrote:
He
I just tested and works fine. Try with master branch and default config
file.
To test I modified a bit the default kamailio.cfg and I have in
route[RELAY]:
xlog("===* request $rm before relay\n");
if (!t_relay()) {
xlog("===x request $rm not relayed\n");
sl_reply_e
Many thanks for your help.
I've applied the patch, recompiled and I see no difference unfortunately.
The ACK is not forwarded, and execution after t_relay stops.
I've set the debug level to 4 and captured the traces - I believe the
section dealing with the ACK is there: https://pastebin.com/TG03Y
Hello,
can you give a try with latest master branch or by using the patch from
next link?
-
https://github.com/kamailio/kamailio/commit/52111974b4571e0562e8e731df80f48dbc504915
Apparently the t_realy() stopped script execution (by returning 0) when
e2e ACK forwarding was successful. The patch
Hello
I've tried mhomed = 1 with no luck - not so sure what you mean by default
route, I've added listen = udp:myadsress:5060
I also have auto_aliases=no and alias=myaddress
However, what bugs me is that execution seems to stop INSIDE t_relay and
the info message after the t_relay is not displayed
Check that your installation have one NIC with only one default route on
host.
If not check that "mhomed=1" is enabled.
Sergey
пт, 22 дек. 2017 г. в 0:02, Jean Cérien :
>
> Hello
> I am using kamailio 5.0.2, on a debian 9 system.
>
> Everything was running fine, until one of our voip provider ch
34 matches
Mail list logo
