Re: [reSIProcate] Need help in porting to Android

[praveen ch <praveen44com@xxxxxxxxx>]

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@xxxxxxxxxxxxxxx> wrote:

Hi Praveen,

...inline...

On Sun, Jan 26, 2020 at 1:32 AM praveen ch <praveen44com@xxxxxxxxx> 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

 

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.

 

Thanks & Regards,

Praveen Chebolu.

On Sat, Jan 25, 2020 at 1:36 AM Scott Godin <sgodin@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

--

Regards,
praveen chebolu

--

Regards,
praveen chebolu