12 Jan
2019
12 Jan
'19
1:48 p.m.
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
12 Jan
12 Jan
2 p.m.
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(a)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
14 Jan
14 Jan
3:04 p.m.
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
11:34 p.m.
Hi Neels,
On 2019-01-14 15:04, Neels Hofmeyr wrote:
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.
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. ~N
Always an optimist,
Gullik
4:30 p.m.
New subject: ringback in gsm. (was Re: A ramble about MSC, sip-connector and asterisk.)
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.
2427
days inactive
2429
days old
4 comments
4 participants
participants (4)
-
Gullik Webjorn -
Keith -
Neels Hofmeyr -
Sandi Suhendro