Re: [SR-Users] Comunication between devices RTP/SRTP and viceversa

You would achieve this in a failure route, detecting the 488|415 negative replies then resuming the branch with a different SDP profile. However, as others have said already, not all UAs will accept this "hack". Some will consider the new branch with a CSeq NOT incrementing as retransmission -

Re: [SR-Users] Comunication between devices RTP/SRTP and viceversa

Hi, Unfortunately in my experience "Opportunistic SRTP" support is broken in many UAs. There are (at least) two ways of doing it covered indirectly in RFC3264 and the second explicitly in RFC8643 and devices seem

Re: [SR-Users] Comunication between devices RTP/SRTP and viceversa

I can examine the request but how examine the answer if is a Error? Using a failure route? Regards --- I'm SoCIaL, MayBe El 27/01/2022 a las 5:39 p. m., Alex Balashov escribió: Does an examination of the SDP offer and answer respectively not divine the issue? On Jan 27, 2022, at 5:35 PM,

Re: [SR-Users] Comunication between devices RTP/SRTP and viceversa

Does an examination of the SDP offer and answer respectively not divine the issue? > On Jan 27, 2022, at 5:35 PM, Social Boh wrote: > > I'm trying to configure Kamailio to permit communication between devices: > > some use TLS and SRTP > > some UDP and RTP > > with RTPEngine in the middle.

[SR-Users] Comunication between devices RTP/SRTP and viceversa

I'm trying to configure Kamailio to permit communication between devices: some use TLS and SRTP some UDP and RTP with RTPEngine in the middle. A priori I don't know if the device support SRTP or RTP so in the routing I have to detect on the fly how to act. The problem is this: Call from

[SR-Users] Homer7 and Kamailio 5.3

Hi to all, We have a Kamailio 5.3 that sends all traffic to a homer7 using siptrace module with parameters force_send_sock and hep_mode_on,1 and hep_version,3 and trace_mode,1. Everything works fine getting all traffic to Homer7 but, in case Homer7 is not reachable, Kamailio then no longer

Re: [SR-Users] REGISTER with http_async_client ?

Hi, I'm running a scenario very similar to yours with kamailio 5.5.3 and I have no issue. The only difference with your scenario is that I don't do the challenge with the client, I always reply 403 and release the transaction after. I didn't have the time to replicate your exact scenario but it

Re: [SR-Users] 200 OK re transmission only on re-SUBSCRIBE

After extensive testing and trawling endless debug logs the resolution I came to was the below. Any feedback would be welcome, this is in early stages as mentioned so sure lots of tweaks along the way. As we only need the response from the API and no data is passed back (at this stage) I set

[SR-Users] REGISTER with http_async_client?

Hi there, I have a weird issue with kamailio (latest docker image kamailio-ci:5.5.2-alpine) and http_async_client. Before posting a lot of logs, let me describe what I want to achieve. I have a Kamailio and a SIP Phone. The SIP phone sends a REGISTER to kamailio, then in my routing block, I

Re: [SR-Users] Some problems with SIP TRACE

Hello, if you set trace_mode to 1, then then you do not need to use sip_trace() or setting the flag in the request_route, all the traffic is mirrored to hep server. If you do not see anything, check the syslog for errors and eventually run with debug=3 in kamailio.cfg to get more debugging

Re: [SR-Users] 200 OK re transmission only on re-SUBSCRIBE

Many thanks, I will hopefully be able to share what the problem was very soon. I am hoping after a good nights sleep, today I might be able to see the issue. Lewis From: Daniel-Constantin Mierla Sent: 27 January 2022 10:04 To: Kamailio (SER) - Users Mailing List ; Lewis Hutchinson Subject:

Re: [SR-Users] 200 OK re transmission only on re-SUBSCRIBE

Hello, you have to look at your routing script and see if it is missing some return or exit to stop processing when the reply is sent out. Cheers, Daniel On 26.01.22 18:22, Lewis Hutchinson wrote: > > Hi Daniel > >   > > Many thanks, this is in the early stages and to undergo extensive >