Feature #3069
openinvestigate multiple CM Service Request on the same conn
0%
Description
TS 24.008 Section 4.5.2:
According to the protocol architecture described in 3GPP TS 24.007
[20], each CM entity will have its own MM connection. These different
MM connections are identified by the protocol discriminator PD and,
additionally, by the transaction identifier TI.
So for example, one could have multiple calls (same pdisc, but different TI),
or one could have SMS ongoing while a call (different pdisc+TI).
Testing an SMS sent during an ongoing call indeed shows a secondary CM Service Request.
In attached pcap it seems that we are already handling the situation rather well.Nevertheless, take a close look:
- are we handling the TI properly?
- make sure that the tear down of one service handling doesn't cut short any other pending CM Service Requests,
especially if one CM Service Request concludes while the another has just sent the CM Service Request and we are still waiting for the actual CC/RR/... service request following.
(I also notice in attached PCAP that DTMF requests are rejected, and that a call Hold command is rejected; that may have to become separate issues.)
Files
Related issues
Updated by laforge about 6 years ago
neels wrote:
(I also notice in attached PCAP that DTMF requests are rejected, and that a call Hold command is rejected; that may have to become separate issues.)
both are expected with the internal MNCC handler.
Updated by neels about 6 years ago
- Has duplicate Feature #3156: make sure we handle N overlapping CM Service Requests properly added
Updated by neels almost 5 years ago
Sort of related: osmo-msc master has been refactored and now supports multiple use counts of identical type on an ongoing connection (e.g., two SMS transactions at the same time without causing refcount errors)
Updated by neels over 3 years ago
from dim memory i am assuming that osmo-msc handles overlapping CM Service Requests sanely, but indeed there seem to be no ttcn tests for those scenarios.