Hi Brett,
In what context are you performing these operations? Is it a failure_route? If
not, can you try it in a failure_route?
I ask because this is very surprising behaviour. t_reply() should create an
entirely brand-new reply message, and no elements of a previously received
reply on some
Hey Brett,
I agree that the terminology around the ’suspend’ might be confusing. The
concept that this configuration vernacular is trying to invoke — and, in fact,
uses under the hood — is that of the TM module’s t_suspend() / t_continue()
functionality:
Hey Alex,
Thanks that was really helpful.The $avps were available. Just needs a
little refactoring to work as expected.
Doesn't feel like a "suspend". I think calling it that and not being more
clear in the docs is confusing. But I can see how it kinda makes sense.
Appreciate the help,
Brett
On
Hello,
I'm receiving calls which I forward to a server I KNOW will reply with a
302. When I get that 302, I parse some information and then t_reply(302)
the originator. The 302 I create needs to have it's own contact header
which I am adding with append_to_reply(). That works great. BUT the
A little more helpfully, perhaps:
- By default, a transaction is not created until t_relay(); if you want
`http_async_client` to preserve any transaction-affiliated information, you’ll
need to create it explicitly with t_newtran() beforehand;
- Only transaction-persistent information is
> On Aug 18, 2022, at 5:50 PM, Brett Nemeroff
> wrote:
>
> When I get to the end of the HTTP_REPLY block, I'm EXPECTING it to RESUME
> FROM the suspended location from the original route block, which it does NOT
> seem to do. Is that expected?
No, alas, that’s not going to happen.
— Alex
Hello Kamailio Team!
I've tried following the documentation for http_async_query() with
suspend=1 and not getting results I'm expecting. Perhaps I'm
misunderstanding the documentation.
Basically I'm performing a http_async_query() with suspend set to 1 and a
"route_name" set to HTTP_REPLY.
When
Dear All,
Thank you in advance .
Facing issue is setting up tls with kamailio 5.5.4 on ec2 Amazon
linux server.
Getting this error.
Aug 18 20:36:33 abc.domain /usr/local/mykamailio/sbin/kamailio[10772]:
ERROR: tls [tls_server.c:1329]: tls_h_read_f(): protocol level error
Aug 18 20:36:33
> On Aug 18, 2022, at 7:33 AM, Greg Troxel wrote:
>
>
> Alex Balashov writes:
>
>> In principle, that’s right. Practically, this depends on the behaviour
>> of various intermediaries. I have seen both behaviours. In the
>> scenarios I have troubleshot, receiving only the first fragment on
Alex Balashov writes:
>>> This should not prevent the INVITE from being parsed; typically in
>>> real-world scenarios with a 1500 byte MTU, the first fragment captures
>>> all SIP headers, and fragmentation slices up the SDP
>>> payload. Fragmentation won’t adulterate the Request Line (first
Alex Balashov writes:
> Hi Ali,
>
> Kamailio reassembles fragmented UDP just fine.
Do you really mean that, or "operating systems reassemble fragmented UDP
packets and hand the full packet to Kamailio"?
> However, additional UDP fragments beyond the first packet don’t always
> get to
Hi Ali,
Kamailio reassembles fragmented UDP just fine.
However, additional UDP fragments beyond the first packet don’t always get to
Kamailio, since they don’t have a UDP header. UDP fragments can be dropped by
stateful firewalls and/or NAT gateways for this reason.
This should not prevent
Hello,
first: 5.2.5 is really old by now and not maintained, it is not easy
anymore to get proper answers for questions related to it. You should
upgrade to a recent release.
Kamailio has nothing to do with defragmentation of incoming UDP packets,
it is the kernel/ip stack doing it. If it is
Hello,
I looked at code and I couldn't spot quickly anything wrong with using
the xavp. I added more debug message in the git master branch.
Can you add:
pv_xavp_print();
just before save() in your config and test with git master branch and
debug=3? Then send the log messages printed for the
Hello all,
Lately I faced an issue that Kamailio is not responding to some invite packets
coming from SBC. When investigating I found that these packets exceeds MTU size.
Could this be the issue? Knowing that in Kamailio configuration I have a
condition on is_method("INVITE"). Could be that in
Hi Daniel
debug=3
Two CEP already registered. Registering a 3rd one (snom).
Some IP and Hostnames replaced by 'HIDDEN'.
Aug 18 07:52:55 dev-cpereg02 kamailio[1187007]: INFO: [1 315995001
zygwpey7@snom 1899942452
Hi Daniel
> what actually happens? New registrations are accepted with different
> contact headers? Have you run with debug=3 to see if you can spot any
> hint in the logs?
Well I did a different test, which I think hints where the problem is:
== Test 1 ==
modparam("registrar", "max_contacts",
17 matches
Mail list logo
