[VoiceOps] Ideas for Building Inbound Redundancy

[Alex Balashov]

Hello,

On Tue, Feb 07, 2017 at 01:58:29PM -0500, Nick Olsen wrote:

> Honestly, I haven't done a packet capture on it. But I don't think
> it's technically a reinvite. 

The term "reinvite" refers to one kind of scenario and one kind only: an
in-dialog SIP INVITE, as opposed to an initial SIP INVITE request.

What we experience and user agents present as a "call" is a SIP "dialog"
underneath. This is established by the initial INVITE transaction and
confirmed by the end-to-end ACK. The RFC 3261 § 12 rendition is rather
nebulous, but conveys the idea that it's a piece of short-term state,
akin to a dynamic "circuit" instantiated in a circuit-switched call:

   A key concept for a user agent is that of a dialog.  A dialog
   represents a peer-to-peer SIP relationship between two user agents
   that persists for some time.  The dialog facilitates sequencing of
   messages between the user agents and proper routing of requests
   between both of them.  The dialog represents a context in which to
   interpret SIP messages.

In-dialog requests are scoped to the current dialog, and are indicated
as such by the presence of a To 'tag' attribute. This includes requests
such as REFERs, BYEs (hangups), and in-dialog INVITEs (reinvites). 

Reinvites are a little special because they are considered "target
refresh requests". They can update certain dialog parameters (e.g. the
remote target URI, aka the Contact URI of either peer) as well as
renegotiate media attributes with a new SDP offer-answer exchange. 

This is where the terminological confusion most often comes in.
Reinvites don't intrinsically have anything to do with media, nor does
the nature of a media renegotiation within a dialog inherently prescribe
or prohibit "direct" or "peer-to-peer" media flows. Reinvites are used
to, among other things, "hand off" media in this manner, but they can
also be used to switch codecs, alter packetisation duration, switch
calls to a different media gateway, etc. 

The term "reinvite" is not synonymous with, and has no inherent
connection to, direct media exchange. Reinvites are just reinvites. They
do lots of things.

> In my scenario, I think it's just passing SDP untouched. So the media
> IP's are intact and causes the switch to establish RTP directly. (I
> also see the ULC's User agent (So much sonus)) This can at times be a
> real pain when trying to capture the traffic on the wire simply
> because you're playing Russian Roulette with which IP you're actually
> going to be exchanging RTP with. 

Assuming you don't have this problem solved in some other fashion,
consider sngrep:

https://github.com/irontec/sngrep

When I discovered it in 2016, I realised my entire professional life
prior to that point was just a giant waste.

> But I digress. Frankly, For inbound I don't think you'll ever see
> this. You could probably do something similar (No modification of SDP)
> with Kamilio I suspect. 

Kamailio is a SIP proxy, and does not modify SDP, by its very nature.
Exceptions to that rule generally involve the various outboard RTP
relays that can be used with it, such as rtpproxy and RTPEngine.

> >Or maybe there is even a module available for kamailio that synchronizes
> >active SIP calls between multiple kamailio installations?!

There are numerous ways to accomplish that. Keep in mind that Kamailio's
statefulness is really at the transaction level—that's what "stateful
SIP proxy" means. Its 'dialog' module provides dialog awareness, but
there isn't really much to synchronise. 

Synchronising knowledge of "calls" among Kamailio installations is not
an especially challenging technical problem, but nor does it provide the
redundancy outcomes you may hope for. Kamailio will happily pass
in-dialog requests and their replies statelessly anyway, based on
fundamental SIP message properties. It doesn't check whether they
correspond to a dialog it knows about.

Synchronising in-flight _transactions_ is hard.

>  Yeah, I meant to say Kamailio in my original email. I know asterisk 
> complains when it gets RTP for a call it doesn't have. No idea if Kamilio 
> is the same. But I imagine it would. 

Kamailio is a SIP proxy, and does not receive or handle RTP in any way.

Kamailio + anycast is a well-explored problem. It mostly works, except
for cases where messages within in-flight _transactions_ (not dialogs!)
go to a different Kamailio instance than the one that processed the
transaction-initiating request. 

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/