Hi
To determine, if rtpengine was engaged during an invite or not, I make use of rr params for all messages in following transactions and I set an avp for all messages in the current transaction.
When the call is canceled, I would need to call rtpengine_delete to make sure rtpengine stops listening for rtp packets.
Unfortunately, the avp I set during the INVITE, does not seem to be present while the CANCEL message is processed, despite to my understanding being in the same transaction.
How can I pass some information from an INVITE to the corresponding CANCEL?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello Benoit,
You can use $T_inv(...) to access attributes of the original INVITE transaction, to which the CANCEL pertains:
https://www.kamailio.org/wikidocs/cookbooks/5.8.x/pseudovariables/#t_invpv
However, you may instead consider the attractive simplicity of just calling rtpengine_delete() for every CANCEL, regardless of whether RTPEngine was engaged. If the <Call-ID, From-tag> tuple is not recognised by RTPEngine, no harm, no foul -- not an even error. Yes, there is the overhead of a synchronous round trip to RTPEngine involved in this. However, in most cases, the consequences aren't too significant.
As someone who has built many overcomplicated Rube Goldberg machines and systems with a lot of this kind of conditional logic, I've come to appreciate, over the years, the appeal of a simpler mechanism with fewer moving parts, even at the cost of some inefficiency.
-- Alex
Hi Alex
Thank you, I'll check that out.
Unfortunately, life sometimes is not that simple, like when you have to find a way to process spiralling calls with rtpengine.
And yes, unfortunately loop-protect is not the solution as some codec quicks are needed depending on the direction of the call.
For this to work, each spiral needs to pass an unique callID to rtpengine. So adding a counter to the real callID, let's call it extraID did the trick (with an X- header and adding a rr_param to process messages the other way round etc.)
But i got stuck when trying to nicely tell rtpengine to stop listening for callID-extraID on a CANCEL as I have not yet found a way to get hold of that extraID.
rtpengine will eventually time out, but I try to tidy up correctly.
Curious: why is this necessary? Is there a possibility there is an unnecessary complicating assumption at the root of your setup?
Maybe not, but I have to wonder.
-- Alex
Hi Alex
*sigh* yes I guess you may ask. Somehow I think we do 'normal' VSP business, but it looks like we seem to have a complicated set-up.
Our set-up basically looks like this:
We have a core kamailio node taking care of dialog handling, CDR gathering for billing, routing and which has interconnections to other VSP, voicemail etc. but they are more or less firewalled from the internet.
We have a registrar kamailio node taking care of connected customer, dynamic registrations, authentication facing the bad dangerous internet. No dialog module enable! This node does not know how to route stuff. It his relatively simple minded. If the call is from a customer, route it to the core who will then account for the call and know how to route. If the call is from the core, then look up the location and route to the customer if registered. Of course there is more like failure handling, call forwarding handling etc. but you get the basic idea.
At the moment, we use a commercial SBC to handle RTP on the interconnection side to other VSP, but also to proxy RTP and registrations from customer CPE. Especially with registrations it's not always behaving according to SIP standard and causes a lot of issues. But also on the interconnection to other VSP side, it has some limitations, for example it can't stand crypto in an SDP and will reply with 450 (or whatever the sip code is to reject an SDP) when crypto is present. It also considers ipv6 addresses to be something that needs rejecting.
We want to get rid of the SBC, especially on the side towards our customer, the sooner the better.
Hey we could allow customers to encrypt their RTP traffic and talk a modern ip protocol!
So, as the registrar are facing the bad and dangerous internet anyway I somehow prefer to keep our core kamailio a bit behind firewalls, my conclusion was to run rtpengine on the registrar any maybe also benefit from some advantages with firewalls and cpe who prefer to exchange RTP and Signaling to the same IP.
Now picture customer A on the registrar calling customer B on the same registrar.
The registrar authenticates the caller, rtpengine maybe talks ipv6 and crypto as suggested by the caller, throws in some ICE magic etc. all nice stuff to do with the customer. But as the registrar instance has no clue where the destination number is, it just routes the call to the core. As the destination could be behind our SBC, or maybe another VSP which only accepts IPv4, I have to make sure I remove crypto and use IPv4 in the SDP towards the core.
Well, now the call is on the core, the routing table for the destination is looked up. Hey, it's also a customer of ours, let's route the call back to the registrar!
The registrar look up the location table and determines what ip version and protocol that customer is registered with, if it's IPv6 then activate ICE. Offer Crypto!
Well, for this to work, I need to run the call separately through rtpengine again, with a different callID. If I activate loop-protect on rtpengine, then the settings which are compatible towards our SBC and interconnection would be sent to the customer as the 2nd invocation of rtpengine would be ignored.
I hope this makes sense.
Benoit,
I think the first part of that sentence, about normal VSP business, is a powerful intuition, and you should double down on it instead of waving it away.
I've been reading your posts for a while. If you permit me a broad characterisation, which I don't mean to be inflammatory or characterologically unflattering:
I think you frequently raise very captivating and nuanced technical problems, and that you are extremely energetic and motivated, and succeed in inventive, innovative, nuanced and incisive technical workarounds, using very clever and original techniques. I'm struck by the level of the quick aptitude for understanding, assimilating and applying small implementational details of all kinds, and the energy and enthusiasm with which you do this again and again. If I had 25% of your vigour and industry, I might be a very wealthy man.
But almost every time, I wonder: "What is so complex about his service provider environment? Is he providing something so intricate? Very large-scale? Planetary? Intergalactic?" :-)
Often, overly clever workarounds and innovations end up being counterproductive in the long run, because they leave behind a devastating trail of technical debt, complicate institutional memory and knowledge transfer, create friction in training and communication of how the system works, impede delegation and the creation of replicable business processes around it, etc. And from a purely engineering point of view, overly complicated systems are more susceptible to bit rot, lopsided maintenance, and in general, entropy. Squeezing the balloon of complexity in one place inflates it somewhere else. One cannot escape thermodynamics.
[snip description of VSP environment]
I appreciate the well-rounded and detailed description.
From my perspective, I think it confirms that you are not doing anything extraordinary or overly unusual, and probably should not require many extraordinary or overly unusual tricks.
RTPEngine's loop-protect solution, as you point out, has the pitfall that many UAs improperly reflect the 'a=rtpengine:xxx' attribute, even though the standards are crystal-clear that they are not to reflect SDP attributes they don't understand. The standards are equally clear that endpoints are to ignore any SDP attributes they don't understand.
I think this is an example of a situation--perhaps one of many--where you just need some zoomed-out, big-picture perspective, rather than yet another technical fix. From a functional perspective, both approaches will solve your problem, but methodologically, the latter is more likely to leave you with more problems.
Consider:
- SIP proxies participate in a single logical call leg. Leg A comes in, leg A goes out.
- In contrast, the better-known B2BUAs (Back-to-Back User Agents), on which most big brand SBCs, PBXs and softswitches are founded, mediate two logically independent call legs: Leg "A" in, Leg "B" out.
These have their own Call-IDs, From/To tags, sequence numbers, and other SIP attributes, and the B2BUA is free to decide the level of opacity, or transparency, with which it shall translate events on leg "B" back to leg "A", and vice versa.
In contrast, a proxy does not have the flexibility to do this, and must instead propagate events with fidelity along one chain between both parties;
- There are numerous technical trade-offs to the B2BUA and proxy approach, and they should be carefully weighed. The proxy approach doesn't "naturally" provide topology hiding, and poses an array of possible issues related to sending a call back (call looping) to the same UA that initiated it. Even where dialog spiraling can be used to obviate the most straightforward problem, other issues arise;
- Kamailio, by virtue of being a SIP proxy at the core, mandates the proxy approach;
- Because RTPEngine tracks call state by <Call-ID, From-tag>, that is one of the complications in the penultimate point;
- Only a relatively small percentage of your calls are "hairpinned" or "on-net" ("Hey, it's also a customer of ours, let's route the call back to the registrar!"), so you don't need to architect your entire platform around this principle; by definition, these calls are exceptional, even if they are not astronomically rare;
- For those calls, you could deploy a lightweight, signalling-only B2BUA to solve these "looping" problems. SEMS has historically been recommended for this purpose often, but the community edition has fallen into a bit of disrepair. FreeSWITCH, Asterisk, Drachtio, and others make good alternatives.
Adding a B2BUA to your platform is also a moving part and introduces complexity. However, the call flow is extremely straightforward, the software componentry involved is very straightforward, and forwarding requests is a core competency of Kamailio that is very idiomatic. Compared to your solution of manipulating the Call-ID in baroque ways, it's much less internally complex, and runs in more well-worn grooves that will be more easily understood by other Kamailio operators and SIP experts in the future.
-- Alex
Fred,
This is beautiful:
<extension name="b2bua"> <condition field="destination_number" expression="^b2bua-(.+)$"> <action application="log" data="INFO entered b2bua extension"/> <action application="set" data=“sendto=${sip_via_host}:5080"/> <action application="set" data="bypass_media=true"/> <action application="set" data="sip_copy_custom_headers=false"/> <action application="bridge" data="[sip_h_X-PGPX=${uuid}]sofia/internal/$1@${sendto}"/> <action application="hangup"/> </condition>
I was not aware it was that simple. Thank you for the education!
-- Alex
Hi
Indeed. I was considering asterisk as I tend to use what I know. But with Asterisk I would have to add quite some config to pass on required additional customer sip header.
If that's that simple with FreeSwitch and header can be transparently passed on, I'll have a look at it.
This would also solve another problem. We have some CPE with limited memory which struggle with a long record-route list.
Indeed, and this is why I recommended it. It would solve a larger class of problems, above and beyond the one you currently face with RTPEngine per se.
-- Alex
Thanks Alex for the high praise. =)
But with Asterisk I would have to add quite some config to pass on required additional customer sip header.
Yeah, Asterisk also doesn’t allow for media bypass from the start. Instead it requires the pbx to anchor media and then does a re-invite to bypass; which is just not a great method (imo). With FreeSWITCH not doing any media it is quite performative and also allows for the call to be “taken over” by freeswitch with it’s standard uuid controls.
Regards,
Fred Posner p: +1 (352) 664-3733 https://fred.tel
-
Alex Balashov -
Benoit Panizzon -
Fred Posner