[sr-dev] IMS_ISC technical specification

[Mojtaba]

Hello Ali,
I think there is a misunderstanding, When the PSI that hosted by the AS
send a initial request to SCSCF, the SCSCF really considered the request is
on behalf of IMPU. Then you have to make choice where the request
forwarded. In this case you have to check some conditions. The
P_Asserted_Identity is one of them. More conditions are appear in TS
24.229, 5.7.3 that you mentioned it before.
Nevertheless if you want make call to a registered user from your AS, Why
you don't send your reguest to ICSCF? because the ICSCF could found the
IMPU is registered or not (by LIR/LIA) and forward your request to SCSCF
and UE.
*With Best Regards.Mojtaba*

On Sat, Jul 27, 2019 at 9:47 AM Ali Shirvani <aj.shirvani at gmail.com> wrote:

> Hello Mojtaba,
>
> Thanks for your reply, I just tested P-Asserted-Identity, but S-CSCF
> doesn't route the request to the registered client.
>
> Regards,
> Ali
>
> On Wed, Jul 24, 2019 at 6:02 PM Mojtaba <mespio at gmail.com> wrote:
>
>> According to TS 24.229, The AS could send request to SCSCF, too.
>> But some rules shall be obeied.
>> For example did you add P-Asserted-Identity header to your request?
>> With Best Regards.Mojtaba
>>
>> On Wed, 24 Jul 2019, 17:19 Ali Shirvani <aj.shirvani at gmail.com wrote:
>>
>>> Hello Mojtaba,
>>>
>>> Thanks for your reply. You are completely correct, my current
>>> configuration work fine when request initiated from UEs, but I want to
>>> handle SIP requests that initiated by application server.
>>> When UE sends request to S-CSCF, kamailio fetch iFC from HSS and check
>>> if the request match with iFC or not, if it matched kamailio forward the
>>> request to the application server.
>>> But when application server send request to S-CSCF, isc_from_as('orig')
>>> return false and I couldn't forward request to the target UE.
>>>
>>> Regards,
>>> Ali
>>>
>>> On Wed, Jul 24, 2019 at 3:45 PM Mojtaba <mespio at gmail.com> wrote:
>>>
>>>> Hello Ali,
>>>> The SCSCF has IFC service for decision what it should do with incoming
>>>> SIP message. During check all rules in IFC, If it match with one or some
>>>> rules, actually it marked with that rules. Then the real meaning of marking
>>>> is the SIP message is matched with one or some rules in IFC.
>>>> With Best Regards.
>>>>
>>>> On Wed, Jul 24, 2019 at 2:48 PM Ali Shirvani <aj.shirvani at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I read some portion of imc_isc_mod.c, specially isc_from_as function.
>>>>> In that function there is some function call that searching for some marks
>>>>> in the SIP message. Also I read section 5.7.3 from TS 24.229 but I didn't
>>>>> find the marking mechanism that used in isc_from_as function.
>>>>>
>>>>> Would you please point me to the technical specification that
>>>>> implemented in IMS_ISC module?
>>>>>
>>>>> Regards,
>>>>> Ali
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Development Mailing List
>>>>> sr-dev at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> --Mojtaba Esfandiari.S
>>>> _______________________________________________
>>>> Kamailio (SER) - Development Mailing List
>>>> sr-dev at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>> _______________________________________________
>>> Kamailio (SER) - Development Mailing List
>>> sr-dev at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> sr-dev at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> sr-dev at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>


-- 
--Mojtaba Esfandiari.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20190727/81723049/attachment-0001.html>