Project

General

Profile

Actions

Feature #4543

closed

Emergency call suport in osmo-gsm-tester

Added by laforge almost 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/12/2020
Due date:
% Done:

70%

Spec Reference:

Description

Let's figure out how we can initiate an emergency call in osmo-gsm-tester, via ofono, using regular MS/UE.

Please pay extra attention to not leak any emergency calls to public networks:
  • the osmo-gsm-tester production setup should have better shielding than the R&D setup
  • make sure your network advertises support for emergency calls in SYSTEM INFORMATION. If it doesn't, a MS is mandated to switch to other networks before issuing the emergency call

Files

emergency_call.pcapng emergency_call.pcapng 205 KB pespin, 10/14/2020 06:52 PM

Related issues

Related to OsmoBSC - Feature #4549: Emergency Call Priority / Pre-EmptionResolveddexter05/12/2020

Actions
Actions #1

Updated by pespin over 3 years ago

Some interesting ofono bits to verify/test emergency calls:


13:04:37.557224 tst                          /gobi_1: DBG: 'org.ofono.VoiceCallManager'.PropertyChanged() -> EmergencyNumbers=['08', '000', '999', '110', '112', '911', '118', '119']

alse, 'RemoteMultiparty': False, 'Multiparty': False, 'Name': '', 'LineIdentification': '1020', 'RemoteHeld': False}" 
12:58:49.482029 tst                          /gobi_2: DBG: 'org.ofono.VoiceCallManager'.CallAdded() -> /gobi_2/voicecall01="{'State': 'dialing', 'Emergency': False, 'RemoteMultiparty': False, 'Multiparty': False, 'Name': '', 'LineIdentification': '1019', 'RemoteHeld': False}" 

Actions #2

Updated by pespin over 3 years ago

Actions #3

Updated by pespin over 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

I had to add support for emergency calls in our oso-gsm-tester branch from our ofono.git fork. After doing so, I can see the Emergency setup being sent.

However, I currently see several issues when running the test (where MSC is configured to forward emergency calls to MT, and there's an MO_MT call being placed):
1- For some reason, one of the 2 (I think MT) MS is being LU rejected all the time, I need to check why.
2- Despite being rejected, the MSC is trying to forward the emergency calls to that msisdn.
3- The MSC should be paging the MT before trying to send a CC setup for it?

Actions #5

Updated by pespin over 3 years ago

from IRC:

<pespin> I finally got the emergency call working. I had a bug in python code not setting the msisdn routing line in osmo-msc.cfg. But osmo-msc is definetly behaving really strange when that is not set, it should be saying something at startup or promptly reject the emergency call if the routing is not set. Instead it was trying to setup a call towards the same MS...
<LaF0rge> pespin: well, I guess nobody ever tested that. Maybe we should simply route it to 112 by default, i.e. set that vty setting to 112 as a compile-default before parsing the config file

Patch adding test to verify emergency calls, passes fine:
https://gerrit.osmocom.org/c/osmo-gsm-tester/+/20669 sysmocom: Enable emergency call testing in default-suites.conf

I'm also adding the ofono patch intrudocing emergency call support to our osmo-gsm-tester ofono.git branch, so it gets upstreamed eventually.

Actions #6

Updated by pespin over 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 30 to 70

Assigning to dexter as we concluded he would be doing some manual tests to fix the strange behavior when no routing msisdn is set in the VTY.

Once that has been looked at, we can close the ticket.

Actions #7

Updated by pespin over 3 years ago

  • Related to Feature #4549: Emergency Call Priority / Pre-Emption added
Actions #8

Updated by pespin over 3 years ago

  • Assignee changed from pespin to dexter
Actions #9

Updated by dexter over 3 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)