[reSIProcate] Need help in porting to Android

Tue Jan 28 11:15:45 CST 2020

Dear Scott,

Thanks very much for your clarification. Updated my comments inline *(Blue
color)*
Added one Basic call flow to explain the role of ReSIProcate SIP stack and
3rd party SIP stack for handling multiple services. Could you please check
below call flow and share your overall opinion?

Thanks & Regards,
Praveen Chebolu.

On Tue, Jan 28, 2020 at 12:37 AM Scott Godin <sgodin at sipspectrum.com> wrote:

> Hi Praveen,
>
> ...inline...
>
> On Sun, Jan 26, 2020 at 1:32 AM praveen ch <praveen44com at gmail.com> wrote:
>
>> Dear Scott,
>>
>> Refer below architecture for more details. Actually we have 2 SIP stacks,
>> One from 3rd party for RCS functionality and want to use our SIP Stack for
>> VoLTE functionality.
>> ReSIProcate SIP stack can even work alone when RCS is disabled in device.
>> Resiprocate SIP stack will send INVITE for Call to 3rd Party SIP stack
>> which acts as Master Stack, which sends and receives SIP messages to
>> Network. Master SIP stack when it receives incoming call INVITE, parses the
>> sip contents and based on the service type like MMTEL will forward the SIP
>> contents to ReSIProcate sip stack. Here the role of 3rd Party SIP stack is
>> validate the SIP messages from ReSIProcate were aligned with the
>> registered contents like Auth Header, Security-verify headers etc.
>>
>> 1) Registration procedure - Completely taken care by 3rd party SIP Stack.
>> Once registration is completed, will indicate to IMS (Resiprocate) with
>> Response contents. This will help my module in IMS stack to do fake
>> registration by updating the database needed by ReSIProcate. Is there any
>> way we can do fake registration from ReSIProcate stack?
>>
>
> [Scott]  Which database are you referring to?  As long as DUM app code can
> access the RCS registration database, you can modify the headers on your
> outbound INVITE, etc, to route correctly to other registered users.  This
> should be possible all outside the DUM code.
>
* <Praveen>  Database - Here i am looking for what all context from SIP
stack need to update thru our customized API so that INVITE sessions can be
handled properly by SIP stack. As I mentioned, Register method will be
triggered and taken care completely by 3rd party SIP stack (Refer below
pasted Call flow for more details)   *

>
>
>> 2) For MO Call -> Dialer to DUM to ReSiprocate stack. INVITE will be sent
>> to 3rd party SIP stack...3rd Party SIP stack will send to Network directly.
>> 3) For MT Call -> Network to 3rd Part SIP stack, after parsing SIP stack
>> finds that it is incoming VoLTE call. 3rd party SIP stack will forwards to
>> ReSIProcate SIP stack for further processing of incoming Call.
>>
>
> [Scott]  I'm not sure MO and MT stand for.
>
*    <Praveen>  MO stands for Mobile Originating, MT stands for Mobile
Terminating*

>
>
>>
>>
>> [image: image.png]
>>
>>
>> As i understand from the code, DUM is like TU layer in SIP stack.
>> ReSIProcate stack handles both Transaction and Transport Layers. How can
>> DUM layer works without ReSIP stack?
>>
>
> [Scott]  This is correct.  DUM wasn't designed to work without the resip
> stack below it, however it uses a FIFO to communicate between the stack and
> dum/tu layers, so it should be possible to separate.  Right now, I'm not
> thinking that is best path forward.  More below.
>
>
>> Could you please help me for any other better approach you see for above
>> architecture?
>>
>
> [Scott] When you say that messages are passed between resip and 3rd party
> stack, is that just using the normal SIP transports to do that, or are you
> using some other mechanism for inter stack communication?  In order to
> minimize work in both stacks, I would suggest that you pass SIP messages
> between the 2 stacks using the standard SIP transports.   If you do this,
> you should be able to use resip unmodified.
> *<Praveen> Using Transport has complications in our architecture. Hence we
> were thinking of something like below call flow, which we are seeing less
> impact on SIP layer. But the challenge is on ReSIProcate SIP stack, how it
> can handle the messages without sending out register to Server. We were
> still looking at SIP stack, what to be done internally so that further
> sessions can be handled properly.*
>
[image: image.png]

>
>
>>
>> Thanks & Regards,
>> Praveen Chebolu.
>>
>>
>> On Sat, Jan 25, 2020 at 1:36 AM Scott Godin <sgodin at sipspectrum.com>
>> wrote:
>>
>>> Hi Praveen,
>>>
>>> If you search the mailing lists I think you will find that other's have
>>> used resip an Android with no major issues.  Not sure why you would need
>>> DUM changes to do this.  You can use DUM without forming a client
>>> registration (without any customization/modifications), so I'm not really
>>> sure what you mean by a fake registration and what the purpose of that is.
>>>
>>> Best Regards,
>>> Scott Godin
>>> SIP Spectrum, Inc.
>>>
>>> On Fri, Jan 24, 2020 at 9:59 AM praveen ch <praveen44com at gmail.com>
>>> wrote:
>>>
>>>> Dear All,
>>>>
>>>> We are looking for porting to Android Device for supporting VoLTE
>>>> support. For this we need lot of changes to be done at DUM layer. Before
>>>> that we need whether support for Android have faced any major problems?
>>>>
>>>> We have other Master IMS stack in the device which does only
>>>> registration, so we need some modification to be done at ReSIP stack to
>>>> handle fake registration. Anyone have been tried to modify code for
>>>> handling fake registration?
>>>>
>>>> --
>>>> Regards,
>>>> praveen chebolu
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel at resiprocate.org
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>
>>
>> --
>> Regards,
>> praveen chebolu
>>
>

-- 
Regards,
praveen chebolu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20200129/7f8c30ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 42255 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20200129/7f8c30ce/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 136660 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20200129/7f8c30ce/attachment-0001.png>