Hi Gullik, what is up with your email client? It seems to insert two line feeds every 100 characters or so. I've never seen such weird flow as in your mails. Harder to follow your sentences when they break in the middle. Using external PBX is not trivial, and as soon as you do, all local call switching in osmo-msc is switched off. In general, using osmo-sip-connector works; what is not satisfactory yet is the codec negotiation. Sadly, so far the easiest solution is to hardcode a payload type number into osmo-sip-connector and clamp everything to one specific codec. For example, look at the neels/fr branch in osmo-sip-connector.git. But yours sounds more like a SIP negotiation issue?? I haven't used asterisk yet, but AFAIK at least yate, freeswitch and kamailio work without "clever hacking". Nah. osmo-bts *never* bridges nor ever bridged calls. Old openbsc's osmo-nitb? openbts?? Since you mentioned lime before, let me say that even using timing-accurate sysmoBTS, I had 90% handover failure until I properly calibrated the internal clock. With a lime and no external clock source, you're hopelessly doomed. ~N

On 12/01/2019 13:48, Gullik Webjorn wrote: Hi Gullik, please find a couple of comments inline that I hope are helpful. First, I recommend to run sngrep and watch the SIP transactions between the osmo-sip-connector and asterisk. This should make it very clear, visually, what's happening (or not). What do you mean by interpret?  Do you mean that a SIP device will generate internal audible ringback on receiving 180 Ringing? Osmo SIP-connector is incomplete, but will react to (interpret?) a 180 Ringing, of course it does. It will also react to a 183. On receipt of a 180 or 183 it will send MNCC_ALERT_REQ. and .. actually looking at that, there's a flag we set: progress.desc: GSM48_PROGR_IN_BAND_AVAIL. We appear to be sending that on a 180, and that might not be correct. So when you said "I don't get call progress on calls toward PSTN", I wonder are you talking about early media (ringback)? In GSM, the called party should generate ringback, the GSM phone is not required to generate audible ringing notification. see  GSM 02.40 - Procedure for call progress indications, specifically 2.1: "Except  for  ring  tone,  all  tones  indicating  call  progress  to  a  Mobile  Station  user  shall  be  generated  in  the MS, on the basis of signals from the network where available, and are according to the standard defined in this specification." "For mobile terminated calls, the ring tone will be generated in the called MSC" and Section 2.2: "The  ring  tone  will  be  sent  over  the  traffic  channel,  since  this  channel  must  be  available  for  traffic immediately it is answered (exception: Off Air Call Set Up). The Ring Tone is therefore generated by the PLMN or PSTN supporting the called phone" But whether your asterisk is generating ringback or not is kind of OT for this mailing list. Anyway, I'm not sure that is your issue. As Neels mentioned, (obviously) your codec setup needs to be correct as well, in order for your PBX to send correctly encoded early media ringback. Personally. I think, no it should not. I wonder is this terminology/idea arising from OpenBTS? There was (is?) talk about MS just being "SIP endpoints" with openbts, I know it was something some devs on openBTS view(ed) as a plus point, and thought this was a much better idea than supported the (much more complex) traditional GSM core network spec. (which is what osmocom is doing). NOTE, I believe I have at some point in the past, noticed some phone on a commercial network generating what I could swear sounded like locally generated ringback. It was just TOO clean. Maybe one could look at the spec again and see if it's actually possible. Osmo sip connector could then set whatever is required to indeed make the MS generate a local audible ringback, although I'm not sure this would be supported all the way back through MSC/BSC to the MS, as I don't think we support this so-called "off the air" SETUP.