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/