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/
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 пишет:
- 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. *
- 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?).
+ 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@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 пишет:
- 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.
- 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@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
On 02/01/2019 13:46, Max wrote:
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.
- 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?).
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 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 -
Keith -
Max -
Sandi Suhendro