2 Jan
2019
2 Jan
'19
2:11 p.m.
Hi all.
1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL
Apparently at least one person was frustrated at the congress by not
being able to call out using the numbers stored in their GSM handset
using the form +CountryCode.
As we know this appears at Call Control with TON intl, which sip
connector then prefixes with '+' before sending to SIP
The reason for lack of service at ccc was that the Yate pbx does not
support this number scheme and needed the 00 prefix. This would have
been trivial to patch had we known, and it prompts me to think this
should probably be implemented as a runtime config option in sip section
'tonintl prefix' or some such? It would seem correct for it to be
restricted to the set of either '00' or '+', no other options really
makes sense, not even "no prefix". right?
2) 3G data instabilities
( Just a quick observation note, no pcap! )
I happened to notice that pinging a 3G handset from the network side
(default ping: 1 sec internal, 64 ICMP bytes) keeps the connection
"alive" and using 3G data is then a pleasant experience, IM, email,
browsing, SIP call all working nicely. peak max download speed of 16Mbps
was reported at one time by m.speedof.me
However, stopping the ping results in loss of data conex within a few
seconds, and the behaviour from users point of view is then strikingly
similar to what's observed on 2G; and I am more or less convinced has to
do with the unknown Timing Advance issues in the PCU.
So I thought I'd note it down here.
k/
2 Jan
2 Jan
2:46 p.m.
Hi.
Thanks for write-up.
Comments are inline below, here's another (unrelated) issue observed
during 35c3: https://osmocom.org/issues/3741
02.01.19 13:11, Keith пишет:
1) SIP Connector handling of TON
GSM340_TYPE_INTERNATIONAL
Apparently at least one person was frustrated at the congress by not
being able to call out using the numbers stored in their GSM handset
using the form +CountryCode.
As we know this appears at Call Control with TON intl, which sip
connector then prefixes with '+' before sending to SIP
The reason for lack of service at ccc was that the Yate pbx does not
support this number scheme and needed the 00 prefix.
The *+12345... format is defined in **ITU-T E.123 so the lack of support
for this format looks like a bug in Yate.*
*What about 00 prefix? Unless it's defined in some spec, I don't think
it make sense to introduce options just to work around bug in particular
PBX.
*
2) 3G data instabilities
( Just a quick observation note, no pcap! )
I happened to notice that pinging a 3G handset from the network side
(default ping: 1 sec internal, 64 ICMP bytes) keeps the connection
"alive" and using 3G data is then a pleasant experience, IM, email,
browsing, SIP call all working nicely. peak max download speed of 16Mbps
was reported at one time by m.speedof.me
However, stopping the ping results in loss of data conex within a few
seconds, and the behaviour from users point of view is then strikingly
similar to what's observed on 2G; and I am more or less convinced has to
do with the unknown Timing Advance issues in the PCU.
Is there bug for this already? If both 2G and 3G have similar issues in
the absence of MT traffic than there might be something wrong in the
core components (SGSN/GGSN?).
--
- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Harald Welte
3:13 p.m.
+ country code using osmo-sip-connector is fine with asterisk pbx for
osmocom stacks for me.
regards,
Sandi / DUO
On Wed, Jan 2, 2019, 19:47 Max <msuraev(a)sysmocom.de wrote:
Hi.
Thanks for write-up.
Comments are inline below, here's another (unrelated) issue observed
during 35c3: https://osmocom.org/issues/3741
02.01.19 13:11, Keith пишет:
1) SIP Connector handling of TON
GSM340_TYPE_INTERNATIONAL
Apparently at least one person was frustrated at the congress by not
being able to call out using the numbers stored in their GSM handset
using the form +CountryCode.
As we know this appears at Call Control with TON intl, which sip
connector then prefixes with '+' before sending to SIP
The reason for lack of service at ccc was that the Yate pbx does not
support this number scheme and needed the 00 prefix.
The *+12345... format is defined in **ITU-T E.123 so the lack of support
for this format looks like a bug in Yate.*
*What about 00 prefix? Unless it's defined in some spec, I don't think
it make sense to introduce options just to work around bug in particular
PBX.
*
2) 3G data instabilities
( Just a quick observation note, no pcap! )
I happened to notice that pinging a 3G handset from the network side
(default ping: 1 sec internal, 64 ICMP bytes) keeps the connection
"alive" and using 3G data is then a pleasant experience, IM, email,
browsing, SIP call all working nicely. peak max download speed of 16Mbps
was reported at one time by m.speedof.me
However, stopping the ping results in loss of data conex within a few
seconds, and the behaviour from users point of view is then strikingly
similar to what's observed on 2G; and I am more or less convinced has to
do with the unknown Timing Advance issues in the PCU.
Is there bug for this already? If both 2G and 3G have similar issues in
the absence of MT traffic than there might be something wrong in the
core components (SGSN/GGSN?).
--
- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Harald Welte
3:54 p.m.
On 02/01/2019 13:46, Max wrote:
I don't know if there's a specific issue for this as such, there are a
number of issues that would seem related, but most of them filed under
OsmoPCU. I believe there is something(s) wrong in the core components,
and that was indeed the local feedback I got in the GSM room.. :))
but I don't know what to file. I'd need to get 3G setup at home to
contribute anything useful, hence the simple note.
k/
Hi.
02.01.19 13:11, Keith пишет:
The *+12345... format is defined in **ITU-T E.123 so the lack of
support for this format looks like a bug in Yate.*
*What about 00 prefix? Unless it's defined in some spec, I don't think
it make sense to introduce options just to work around bug in
particular PBX.
*
It's probably not a BUG as such, but rather a (lack of) implementation
in the configured dialplan. I'm not so familiar with YATE, but I would
imagine it is probably something that would have also been fixed by a
simple regex modification in some yate config file. '^(+|00)' or
something..
you make a good point though, and I glad I asked before submitting a patch.
all the same, maybe it might be a nice thing for users to have, just as
a convenience?
Without a config option, for a user faced with a non compliant upstream
SIP UA over which they have no control, they would have no choice but to
patch and recompile the sip connector.
2) 3G data
instabilities
I happened to notice that pinging a 3G handset from the network side
(default ping: 1 sec internal, 64 ICMP bytes) keeps the connection
"alive"
Is there bug for this already? If both 2G and 3G have similar
issues
in the absence of MT traffic than there might be something wrong in
the core components (SGSN/GGSN?). 
3 Jan
3 Jan
12:08 p.m.
Hi Keith,
On Wed, Jan 02, 2019 at 02:54:55PM +0100, Keith wrote:
It's probably not a BUG as such, but rather a
(lack of) implementation
in the configured dialplan. I'm not so familiar with YATE, but I would
imagine it is probably something that would have also been fixed by a
simple regex modification in some yate config file. '^(+|00)' or
something..
you make a good point though, and I glad I asked before submitting a patch.
all the same, maybe it might be a nice thing for users to have, just as
a convenience?
I would argue we should first try to find out if there's a config/setting
in yate that can make it support the '+' format. If there's an easy fix
by just changing configs/dialplans, then we should document this in the
Osmocom wiki and/or osmo-sip-connector manual.
Implementing a workaround is an option, but I would only do it if we are
sure there is no other way to fix it, short if patching the yate source
code on the other side.
Without a config option, for a user faced with a non
compliant upstream
SIP UA over which they have no control, they would have no choice but to
patch and recompile the sip connector.
If the problem exists with more implementations than just yate, it would
be a strong indication that we should implement some work-around on our
side. But if it's only yate, see above comment.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1993
days inactive
1994
days old
4 comments
4 participants
participants (4)
-
Harald Welte -
Keith -
Max -
Sandi Suhendro