<div dir="auto">+ country code using osmo-sip-connector is fine with asterisk pbx for osmocom stacks for me.<div dir="auto"><br><div data-smartmail="gmail_signature" dir="auto">regards,<br>Sandi / DUO</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 2, 2019, 19:47 Max <<a href="mailto:msuraev@sysmocom.de">msuraev@sysmocom.de</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<br>
Thanks for write-up.<br>
<br>
Comments are inline below, here's another (unrelated) issue observed <br>
during 35c3: <a href="https://osmocom.org/issues/3741" rel="noreferrer noreferrer" target="_blank">https://osmocom.org/issues/3741</a><br>
<br>
02.01.19 13:11, Keith пишет:<br>
> 1) SIP Connector handling of TON GSM340_TYPE_INTERNATIONAL<br>
><br>
> Apparently at least one person was frustrated at the congress by not<br>
> being able to call out using the numbers stored in their GSM handset<br>
> using the form +CountryCode.<br>
><br>
> As we know this appears at Call Control with TON intl, which sip<br>
> connector then prefixes with '+' before sending to SIP<br>
><br>
> The reason for lack of service at ccc was that the Yate pbx does not<br>
> support this number scheme and needed the 00 prefix.<br>
<br>
The *+12345... format is defined in **ITU-T E.123 so the lack of support <br>
for this format looks like a bug in Yate.*<br>
<br>
*What about 00 prefix? Unless it's defined in some spec, I don't think <br>
it make sense to introduce options just to work around bug in particular <br>
PBX.<br>
*<br>
<br>
> 2) 3G data instabilities<br>
><br>
> ( Just a quick observation note, no pcap! )<br>
><br>
> I happened to notice that pinging a 3G handset from the network side<br>
> (default ping: 1 sec internal, 64 ICMP bytes) keeps the connection<br>
> "alive" and using 3G data is then a pleasant experience, IM, email,<br>
> browsing, SIP call all working nicely. peak max download speed of 16Mbps<br>
> was reported at one time by <a href="http://m.speedof.me" rel="noreferrer noreferrer" target="_blank">m.speedof.me</a><br>
><br>
> However, stopping the ping results in loss of data conex within a few<br>
> seconds, and the behaviour from users point of view is then strikingly<br>
> similar to what's observed on 2G; and I am more or less convinced has to<br>
> do with the unknown Timing Advance issues in the PCU.<br>
<br>
Is there bug for this already? If both 2G and 3G have similar issues in <br>
the absence of MT traffic than there might be something wrong in the <br>
core components (SGSN/GGSN?).<br>
<br>
-- <br>
- Max Suraev <<a href="mailto:msuraev@sysmocom.de" target="_blank" rel="noreferrer">msuraev@sysmocom.de</a>>       <a href="http://www.sysmocom.de/" rel="noreferrer noreferrer" target="_blank">http://www.sysmocom.de/</a><br>
=======================================================================<br>
* sysmocom - systems for mobile communications GmbH<br>
* Alt-Moabit 93<br>
* 10559 Berlin, Germany<br>
* Sitz / Registered office: Berlin, HRB 134158 B<br>
* Geschaeftsfuehrer / Managing Directors: Harald Welte<br>
<br>
</blockquote></div>