[reSIProcate] Need help in porting to Android

Scott Godin sgodin at sipspectrum.com
Mon Jan 27 11:37:01 CST 2020


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.


> 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.


>
>
> [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.



>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20200127/63bfbd4c/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/20200127/63bfbd4c/attachment.png>


More information about the resiprocate-devel mailing list