This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Alexander Chemeris alexander.chemeris at gmail.comHi Holger, On Feb 22, 2017 1:02 AM, "Holger Freyther" <holger at freyther.de> wrote: > On 21 Feb 2017, at 21:40, Keith <keith at rhizomatica.org> wrote: Hi Keith, > On the question about SIP re-invite, I am talking about operating > without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP > streams at the same time as handover. From what I've read, this is quite > feasable, as part of the SIP spec. > I think this is already considered as part of the development of the > osmo-sip-connector, which is a project I really want to see moving > forward and hope to find time to contribute to over the next few months. yes for the osmo-sip-connector I have ignored the topic of handover. In general I try to see how long I get away with not having to touch the UDP/RTP streams. You don't really need to touch RTP stream if you do re-invite. In case of hand-over the new BTS might send from a different src IP, src Port and will most likely have a new SSRC, timestamp seqno. It is a bit of a question of how "your" PBX will handle it. I can see a couple of outcomes. a.) It has some support for "NAT" handling and will just use the new stream and return packages to the new src IP/src port. It might go back and forth but at some point the old bts will stop sending things. b.) It will accept the new stream but will try to send to the old BTS. The we would have one-way audio. c.) It will reject it as it is a unknown src ip/port. I think for b.) and c.) we will require SIP re-invite but also need to look at the AoIP spec to see if they say how to handle this scenario. But that depends on how the PBX handles this as well. So it means for handover we always need to look at BSC/SIP+PBX and how it is handling SDP/RTP. If I remember correctly, (b) is what's going to happen if a client is following vanilla SIP spec, because changing RTP IP/port requires updating SDP which is done with a re-invite. (a) is a hack supported by many SIP clients, but it may depend not only on PBX, but also on its configuration parameters, on SBCs used on a network, etc So if you want to be nice to the other party and follow the spec, it's better to do re-invite :) Btw, re-invite will need to be implemented anyway if you want to support call hold. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170222/83020609/attachment.htm>