Dear all,
I have switched on logging to file and have set the log level to "debug" for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot find any output in the log file related to MGCP if I get an error. Is there a trick to make the MGCP module more verbose?
Thanks, Kristian
Hi Kristian,
On Mon, Dec 05, 2016 at 07:01:36PM +0100, Kristian Martens wrote:
I have switched on logging to file and have set the log level to "debug" for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot find any output in the log file related to MGCP if I get an error. Is there a trick to make the MGCP module more verbose?
it would be helpful if you could attach your config file, so we can check it.
Hi Harald,
thank you for your answer. Please find attached the config. files.
Regards, Kristian
Am 05.12.2016 um 21:30 schrieb Harald Welte:
Hi Kristian,
On Mon, Dec 05, 2016 at 07:01:36PM +0100, Kristian Martens wrote:
I have switched on logging to file and have set the log level to "debug" for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot find any output in the log file related to MGCP if I get an error. Is there a trick to make the MGCP module more verbose?
it would be helpful if you could attach your config file, so we can check it.
Hi Kristian,
the log file looks fine. All "DMGCP" log lines, especially from openbsc/src/libmgcp/*.c should now be visible.
The big question now is: Does your MSC actually issue MGCP towards the BSC? Do you get answers from the BSC (i.e. any sign of the BSC processing them) but still you see no related log output?
Regards, Harald
Hi Harald,
thank you for your answer. Yes, the call agent requests a new connection to the MGW. And it gets an answer. Mostly it fails, and suddenly, one time, it was OK and I wanted to find out the reason for this strange behaviour (see attached pcap). I also wanted to have the log output inside the specific log file. So do I need to specify the log file section again in the osmo-bsc-mgcp.cfg as it is in osmo-bsc.cfg? Could this be the reason why I do not find MGCP log messages in it?
Thanks, Kristian
Am 06.12.2016 um 11:16 schrieb Harald Welte:
Hi Kristian,
the log file looks fine. All "DMGCP" log lines, especially from openbsc/src/libmgcp/*.c should now be visible.
The big question now is: Does your MSC actually issue MGCP towards the BSC? Do you get answers from the BSC (i.e. any sign of the BSC processing them) but still you see no related log output?
Regards, Harald
On 06 Dec 2016, at 14:16, Kristian Martens kristian.martens@ng4t.com wrote:
Hi Harald,
Hey!
thank you for your answer. Yes, the call agent requests a new connection to the MGW. And it gets an answer. Mostly it fails, and suddenly, one time, it was OK and I wanted to find out the reason for this strange behaviour (see attached pcap). I also wanted to have the log output inside the specific log file. So do I need to specify the log file section again in the osmo-bsc-mgcp.cfg as it is in osmo-bsc.cfg? Could this be the reason why I do not find MGCP log messages in it?
in contrib/mgcp_server.py we have a small python piece to send CRCX/MDCX/DLCX to the GW. I have not tried to replay your message but you could modify the utility. Just looking at the trace I see that a dynamic payload type is used but it is not mapped to an audio codec. This is problematic and might be the origin of your issue. Our SDP code is not great but I think it started to understand codec name to payloadtype mapping.
The other fun thing is that it starts to accept it. For replayed messages it should have a cached (the last) result. Was there any other message in between?
holger
On Tue, Dec 06, 2016 at 02:16:27PM +0100, Kristian Martens wrote:
inside the specific log file. So do I need to specify the log file section again in the osmo-bsc-mgcp.cfg as it is in osmo-bsc.cfg?
Each of the osmo-* programs has its own logging. The osmo-bsc_mgcp does not read the osmo-bsc.cfg, so if you want osmo-bsc_mgcp to log things, you need to put that logging config in the osmo-bsc_mgcp.cfg file.
~N
Hi Neels,
On Wed, Dec 07, 2016 at 01:16:19PM +0100, Neels Hofmeyr wrote:
Each of the osmo-* programs has its own logging. The osmo-bsc_mgcp does not read the osmo-bsc.cfg, so if you want osmo-bsc_mgcp to log things, you need to put that logging config in the osmo-bsc_mgcp.cfg file.
both files were attached to a mail earlier in the threads and had mgcp debug logging enabled.
All,
thank you for your answers. I wasn't aware that the logging is specified for each module separately. I inserted the file logging into ..-mgcp.cfg and now I can find all information needed.
Cheers, Kristian
Am 07.12.2016 um 13:38 schrieb Harald Welte:
Hi Neels,
On Wed, Dec 07, 2016 at 01:16:19PM +0100, Neels Hofmeyr wrote:
Each of the osmo-* programs has its own logging. The osmo-bsc_mgcp does not read the osmo-bsc.cfg, so if you want osmo-bsc_mgcp to log things, you need to put that logging config in the osmo-bsc_mgcp.cfg file.
both files were attached to a mail earlier in the threads and had mgcp debug logging enabled.
Hello,
two UEs (A and B) are successfully registered in a network. Now A tries to call B. B is paged by the core via A interface but the sysmoBSC/BTS does not seem to page the UE (or UE does not answer paging). What could be the reason for this behaviour? How could the problem be debugged? Please find the attached pcap for your reference.
Thanks, Kristian
On 07 Dec 2016, at 17:52, Kristian Martens kristian.martens@ng4t.com wrote:
Hello,
Hi!
two UEs (A and B) are successfully registered in a network. Now A tries to call B. B is paged by the core via A interface but the sysmoBSC/BTS does not seem to page the UE (or UE does not answer paging). What could be the reason for this behaviour? How could the problem be debugged? Please find the attached pcap for your reference.
nice MNC! The P-TMSI doesn't really look that random but it might be an index into an internal data structure?
So on A this looks right. The LAI is 262-79-1 and this is where you are paging. In general it might be:
* osmo-bsc doesn't translate this to actual paging. E.g. not linking/ handling the location area identifier. You could trace the RSL protocol and see if a paging command is being sent (periodically) to the BTS?
* The MS still has a radio channel open. I notice that clear command is being sent so this is unlikely to be the case. Also IMSI seems to be match.. maybe the MS still calculates the paging group wrongly? That is far fetched though.
holger
Hi,
I have captured a trace. Can you find something out?
Thanks,
Kristian
Am 07.12.2016 um 18:13 schrieb Holger Freyther:
On 07 Dec 2016, at 17:52, Kristian Martens kristian.martens@ng4t.com wrote:
Hello,
Hi!
two UEs (A and B) are successfully registered in a network. Now A tries to call B. B is paged by the core via A interface but the sysmoBSC/BTS does not seem to page the UE (or UE does not answer paging). What could be the reason for this behaviour? How could the problem be debugged? Please find the attached pcap for your reference.
nice MNC! The P-TMSI doesn't really look that random but it might be an index into an internal data structure?
So on A this looks right. The LAI is 262-79-1 and this is where you are paging. In general it might be:
- osmo-bsc doesn't translate this to actual paging. E.g. not linking/
handling the location area identifier. You could trace the RSL protocol and see if a paging command is being sent (periodically) to the BTS?
- The MS still has a radio channel open. I notice that clear command is
being sent so this is unlikely to be the case. Also IMSI seems to be match.. maybe the MS still calculates the paging group wrongly? That is far fetched though.
holger
On 07 Dec 2016, at 18:41, Kristian Martens kristian.martens@ng4t.com wrote:
Hi,
I have captured a trace. Can you find something out?
do you see a paging command in that trace? Do you perhaps have:
LOGP(DMSC, LOGL_ERROR, "Unsupported Cell Identifier List: %s\n", osmo_hexdump(data, data_length));
in the logs?
cheers holger
Thank you, yes, I can see
Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:398 Rx MSC UDT BSSMAP PAGING Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:149 Unsupported Cell Identifier List: 00 62 f2 97 00 01 00 00
How can this list be setup in the BSC? Thanks, Kristian
Am 07.12.2016 um 18:44 schrieb Holger Freyther:
On 07 Dec 2016, at 18:41, Kristian Martens kristian.martens@ng4t.com wrote:
Hi,
I have captured a trace. Can you find something out?
do you see a paging command in that trace? Do you perhaps have:
LOGP(DMSC, LOGL_ERROR, "Unsupported Cell Identifier List: %s\n", osmo_hexdump(data, data_length));
in the logs?
cheers holger
On 07 Dec 2016, at 19:03, Kristian Martens kristian.martens@ng4t.com wrote:
Thank you, yes, I can see
Hi!
Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:398 Rx MSC UDT BSSMAP PAGING Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:149 Unsupported Cell Identifier List: 00 62 f2 97 00 01 00 00
How can this list be setup in the BSC?
So far none of my customers used that paging mode and before implementing something that might or might not be correct, I decided to put an error in it so it can be added in the future.
a.) Add mode for it and send a patch b.) Ask someone to implement this mode? c.) Switch to the one "supported"
have a nice evening
holger
Hi,
OK, so which paging mode would be supported? E.g. just for LAI?
Regards, Kristian
Am 07.12.2016 um 19:04 schrieb Holger Freyther:
On 07 Dec 2016, at 19:03, Kristian Martens kristian.martens@ng4t.com wrote:
Thank you, yes, I can see
Hi!
Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:398 Rx MSC UDT BSSMAP PAGING Thu Jan 1 03:14:10 1970 <000a> osmo_bsc_bssap.c:149 Unsupported Cell Identifier List: 00 62 f2 97 00 01 00 00
How can this list be setup in the BSC?
So far none of my customers used that paging mode and before implementing something that might or might not be correct, I decided to put an error in it so it can be added in the future.
a.) Add mode for it and send a patch b.) Ask someone to implement this mode? c.) Switch to the one "supported"
have a nice evening
holger
Hi Kristian,
On Wed, Dec 07, 2016 at 05:52:15PM +0100, Kristian Martens wrote:
two UEs (A and B) are successfully registered in a network. Now A tries to call B. B is paged by the core via A interface but the sysmoBSC/BTS does not seem to page the UE (or UE does not answer paging). What could be the reason for this behaviour? How could the problem be debugged? Please find the attached pcap for your reference.
Most important is to find out what is actually happening on the air interface vs. the Abis interface.
If you have an air-interface protocol tracer, or are familiar with OsmocomBB, or you have a phone with Qualcomm DIAG + QXDM, or a Sagem OT phone, etc. you could get a protocol trace of the phone side. This is the most reliable method to know what arrives at the phone or not.
Next best to that, you can enable GSMTAP generation in osmo-bts, which I believe is sufficiently documented in the manual. Using that, particulary for the PCH L1 SAPI, you will get a 'pseudo air interface trace' consisting of anything that the BTS hands to the PHY for transmission.
BTW, this is what my mgcp.cfg looks like to give me lots of log output on the console:
log stderr logging print extended-timestamp 1 logging level all debug logging filter all 1 mgcp [...]
~N
On 06 Dec 2016, at 08:53, Kristian Martens kristian.martens@ng4t.com wrote:
Hi Harald,
Hi!
thank you for your answer. Please find attached the config. files.
osmo-bsc_mcgp only "recently" gained transcoding and doesn't support conversion from all codecs to all. Your BSC config seems to either select fr1 or fr2 for a call and your MGCP config claims these endpoints are AMR (and you are looping the audio). It seems a bit like a mismatch. osmo-bsc_mgcp doesn't support mixed codec support (mostly because BSC and MGCP MGW do not communicate with each other).
regards holger
-
Harald Welte -
Holger Freyther -
Kristian Martens -
Neels Hofmeyr