Hi,
Some weeks ago I managed to integrate osmobts with my asterisk server. In the beginning, I did
not get any call progress, ( as opposed to running WITHOUT asterisk ). I realized that defining
the msc to sipconnector socket effectively disabled all the logic related to this.
To remedy the situation, I set an asterisk "progress statement" whenever the extensions.conf
indicated a number belonging to my GSM network. This works OK, but now, I don't get call progress
on calls toward PSTN. These extensions do not have "progress" statements, since all SIP phones
interpret the call progress sip messages such as RINGING.
I am interested in your comments whether msc + sipconnector should emulate mobiles as "sip phones",
it does seem to just silently drop call progress messages, and is this the way it should work?
The functionality IS there, since when osmobts was bridging the calls, call progress WAS there.
Well, I kludged up a solution for the GSM-only situation, and this seems suboptimal.
I guess some clever asterisk hacking would solve that, possibly having a redundant progress statement
on ALL extensions would do it, but would I not lose "actual" call progress signals from the PSTN,
since asterisk would emulate them? Another way would be a small "local" asterisk.....before the *real* one.
Boldly moving on to MultiBTS and handover....
Gullik
Osmocom stacks doesnt have any problem with some pbx especially asterisk. If you facing cannot get call progress via pstn, please give us details log.
One i can remain you, nat also need to be configure to yes for many case.
regards, Sandi / DUO
On Sat, Jan 12, 2019, 19:48 Gullik Webjorn <gullik.webjorn@corevalue.se wrote:
Hi,
Some weeks ago I managed to integrate osmobts with my asterisk server. In the beginning, I did
not get any call progress, ( as opposed to running WITHOUT asterisk ). I realized that defining
the msc to sipconnector socket effectively disabled all the logic related to this.
To remedy the situation, I set an asterisk "progress statement" whenever the extensions.conf
indicated a number belonging to my GSM network. This works OK, but now, I don't get call progress
on calls toward PSTN. These extensions do not have "progress" statements, since all SIP phones
interpret the call progress sip messages such as RINGING.
I am interested in your comments whether msc + sipconnector should emulate mobiles as "sip phones",
it does seem to just silently drop call progress messages, and is this the way it should work?
The functionality IS there, since when osmobts was bridging the calls, call progress WAS there.
Well, I kludged up a solution for the GSM-only situation, and this seems suboptimal.
I guess some clever asterisk hacking would solve that, possibly having a redundant progress statement
on ALL extensions would do it, but would I not lose "actual" call progress signals from the PSTN,
since asterisk would emulate them? Another way would be a small "local" asterisk.....before the *real* one.
Boldly moving on to MultiBTS and handover....
Gullik
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".
when osmobts was bridging the calls
Nah. osmo-bts *never* bridges nor ever bridged calls. Old openbsc's osmo-nitb? openbts??
Boldly moving on to MultiBTS and handover....
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
Hi Neels,
On 2019-01-14 15:04, Neels Hofmeyr wrote:
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.
This is Thunderbird on Ubuntu, my "office" laptop. I will see if I can fix it.
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".
when osmobts was bridging the calls
Hmm, I clearly remember I could make calls BEFORE using the -M /tmp/msc_mncc command, which I believe then became a config file option. However, I was not very interested in a "stand-alone" system, so I soon emerged on the path to integrate with asterisk. But if you say so.....not only computer memory fail ...maybe I did not have audio, but call progress, i.e. "ringing" ?? And that is really what is missing here, I believe, ?? sip-sofia ?? responds "183 ringing", but no call progress in the phone. I fixed it by forcing asterisk to generate progress.
Nah. osmo-bts *never* bridges nor ever bridged calls. Old openbsc's osmo-nitb? openbts??
Boldly moving on to MultiBTS and handover....
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.
I *do* have clock sources, however not integrated tonight :-) Limesdr mini feels "being worked at", for me it means multiple affordable BTS pocket size , and I will gladly help in making it more usable. Tomorrow I will attempt calibrating output, and possibly input, comparing spec analyzer traces with reported signal levels. And Harald pointed me in the right direction, the lack of output on the LimeSDR, so I will remedy that as well, adding a booster, to bring level up to +15 dBm, more useful but still within allowed +20 dBm for indoor use.
~N
Always an optimist,
Gullik
On 12/01/2019 13:48, Gullik Webjorn wrote:
Hi,
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).
These extensions do not have "progress" statements, since all SIP phones
interpret the call progress sip messages such as RINGING.
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.
I am interested in your comments whether msc + sipconnector should emulate mobiles as "sip phones",
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.
-
Gullik Webjorn -
Keith -
Neels Hofmeyr -
Sandi Suhendro