<div dir="auto"><div>Hi Holger,<br><div class="gmail_extra"><br><div class="gmail_quote">On Feb 22, 2017 1:02 AM, "Holger Freyther" <<a href="mailto:holger@freyther.de">holger@freyther.de</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 21 Feb 2017, at 21:40, Keith <<a href="mailto:keith@rhizomatica.org">keith@rhizomatica.org</a>> wrote:<br>
<br>
<br>
Hi Keith,<br>
<div class="quoted-text"><br>
<br>
> On the question about SIP re-invite, I am talking about operating<br>
> without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP<br>
> streams at the same time as handover. From what I've read, this is quite<br>
> feasable, as part of the SIP spec.<br>
> I think this is already considered as part of the development of the<br>
> osmo-sip-connector, which is a project I really want to see moving<br>
> forward and hope to find time to contribute to over the next few months.<br>
<br>
</div>yes for the osmo-sip-connector I have ignored the topic of handover. In<br>
general I try to see how long I get away with not having to touch the<br>
UDP/RTP streams.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">You don't really need to touch RTP stream if you do re-invite.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In case of hand-over the new BTS might send from a different src IP,<br>
src Port and will most likely have a new SSRC, timestamp seqno. It is<br>
a bit of a question of how "your" PBX will handle it. I can see a<br>
couple of outcomes.<br>
<br>
a.) It has some support for "NAT" handling and will just use the new<br>
stream and return packages to the new src IP/src port. It might go back<br>
and forth but at some point the old bts will stop sending things.<br>
<br>
b.) It will accept the new stream but will try to send to the old BTS.<br>
The we would have one-way audio.<br>
<br>
c.) It will reject it as it is a unknown src ip/port.<br>
<br>
I think for b.) and c.) we will require SIP re-invite but also need<br>
to look at the AoIP spec to see if they say how to handle this<br>
scenario. But that depends on how the PBX handles this as well. So it<br>
means for handover we always need to look at BSC/SIP+PBX and how it is<br>
handling SDP/RTP.<br>
</blockquote></div><br></div><div class="gmail_extra" dir="auto">If I remember correctly,</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">(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.</div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">(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<br style="font-family:sans-serif"><br>So if you want to be nice to the other party and follow the spec, it's better to do re-invite :)<br><br>Btw, re-invite will need to be implemented anyway if you want to support call hold.<br><br style="font-family:sans-serif"><div data-smartmail="gmail_signature" style="font-family:sans-serif" dir="auto">Please excuse typos. Written with a touchscreen keyboard.<br><br>--<br>Regards,<br>Alexander Chemeris<br>CTO/Founder Fairwaves, Inc.<br><a href="https://fairwaves.co">https://fairwaves.co</a></div></div></div></div>