Re: [RFCv2] doc: Proposal for LTE/IMS API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?= <sjurbren@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

Hi Rémi,

>> > > +             boolean PreConditionCheck(string Type, string
>> > > PeerAddress, +                                     uint16 PeerPort,
>> > >  uint16 LocalPort) +
>> >
>> > That stuff is per context. Should it not be in the context object rather
>> > than in the IMS manager?
>>
>> oFono should only consider QoS information from the IMS
>> Default and Dedicated bearers when checking the precondition.
>>
>> In theory there might be more than one IMS APN for a operator,
>> but I really don't see this as a real life scenario for this.
>> If anyone disagrees please speak out and explain...
>
> Well, I don't care if it is part of the normal context interface, or if it is
> an extra IMS-specific interface on the IMS context object path. But this is
> clearly a per-context thing so it should be in the context.
>
> I don't want to end up in a 'woops' situation down the line. And I don't trust
> operators not to actually implement those useless in real life scenarii...

One option could be to keep it here in the IMS API but
to include the Local IP Address as a argument to the PreConditionCheck.
This fits quite nicely with the QoS SIP Precondition operation and can
easily be used
by oFono core to map to the right APN.

There is still a theoretical problem here if you get the same Home Address from
two IMS APN, If anyone think this is an issue I'll throw in the towel
and move the
PreConditionCheck to the ConnectionContext object ;-)

Anyway, I think either solution would work just fine.
In terms of the "separation of concern" i think keeping it here is the
best solution,
but putting it in the ConnectionContext is more flexible.

I'm not going to keep arguing for this forever ;-)

>> > > +             array{string} PcscfAddresses [readonly]
>> >
>> > Should this be in the context object? The AT command is per CID. Would it
>> > make any sense for a network to have different P-CSCF based on the
>> > bearer?
>>
>> As mentioned above, I don't see why an operator would ever have more than
>> one IMS APN. If we only have one IMS APN, then we might as well present
>> this information here in the IMS API.
>
> How do you cope with two connections to the same APN?

3GPP TS 24.229,  B.2.2.1 "PDP context activation and P-CSCF discovery",
describes that the P-CSCF can be provided as dynamic parameter with the
PDN connection, stored on the ISIM, or by provisioning. As far as I understand
this It is up to the IMS application to select which one of the P-CSCF
addresses it should use.

So I think the best would be to expose the P-CSCF address stored on ISIM
in the IMS API, and move add the P-CSCF provided with the PDN Connection
to the ConnectionContext API.


Regards,
Sjur