Hi Holger,
On Feb 22, 2017 1:02 AM, "Holger Freyther" holger@freyther.de wrote:
On 21 Feb 2017, at 21:40, Keith keith@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
Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array. I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd
I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario.
I'm wondering what to do with this work.
Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right. Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative.
I can publish my work on meas_web to github.
Keith.
We could include and maintain all related code to a subdirectory of contributed in openbsc.git, if you'd like.
Hi Harald,
On Fri, Feb 24, 2017 at 11:05 AM, Harald Welte laforge@gnumonks.org wrote:
We could include and maintain all related code to a subdirectory of contributed in openbsc.git, if you'd like.
Are you talking about meas_web or something else. Your e-mail didn't include any context :(
On Fri, Feb 24, 2017 at 12:05 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Hi Harald,
On Fri, Feb 24, 2017 at 11:05 AM, Harald Welte laforge@gnumonks.org wrote:
We could include and maintain all related code to a subdirectory of contributed in openbsc.git, if you'd like.
Are you talking about meas_web or something else. Your e-mail didn't include any context :(
I frankly don't know what's the best way here. Putting a web app into OpenBSC feels awkward, but it may make sense, given it's tightly coupled and is pretty small. OTOH it has its own installation requirements and debian packaging, which might make it a bit tricky when it's inside OpenBSC repo - I would appreciate thoughts on this. May be we can create two deb packages from the OpenBSC repo with one dedicated to meas_web?
Hi Keith,
On Fri, Feb 24, 2017 at 7:42 AM, Keith keith@rhizomatica.org wrote:
Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array.
Thank you. Please submit a patch when main meas_json lands into the master.
It looks like the patch was lost during the patchworks->Gerrit transition, so I re-submitted it to Gerrit here: https://gerrit.osmocom.org/#/c/1915/
I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd
Yes, this should rather be client side I believe.
I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario.
Sounds very useful indeed! And yes, ARFCN clearly should be dynamic before such a change oculd be merged. But this doesn't mean you should not commit your change in a WIP branch - commit early, commit often. :)
I'm wondering what to do with this work.
I'm glad the code is useful and happy to review your changes.
Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right.
If the commit is ready in general - please submit it to Gerrit and add me as a reviewer.
Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative.
Well, it's a kind of an external API, so it's as useful as any other API.
I can publish my work on meas_web to github.
That would be great. Please submit a pull request when you feel ready.
-
Alexander Chemeris -
Harald Welte -
Keith