Re: [OpenSIPStack] Server implementation question

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I think you are still in the right place.  Your application may choose=20
which transactions it will pass to OpenSBC/OpenSIPStack using the=20
subclass SIP::SIPStack class.   If you want to rewrite any of the=20
headers before OpenSBC sends it out, you can have direct access to the=20
packet in B2BCallInterface::OnOutgoingCall().  If you want to change the =

SIP Headers before OpenSBC can process it, you may hijack it in=20
B2BCallInterface::OnInComingCall().  In my opinion however,  the most=20
elegant way of using OpenSBC is to use it as it is.  You can run it=20
using a different port from you app and use normal SIP Redirect to=20
selectively route transactions to OpenSBC.   You can then just hijack=20
the messages using the different B2BUAHandlers or you may altogether=20
just scrap OpenSBC and write your own using OpenSIPStack.   =20

HTH

Joegen

Thomas Raschbacher wrote:
> So.. if I want to use a 'higher' / transactional interface would I be b=
est off using SIPTransactions or rather SIPFSM::InviteServerTransaction, =
SIPFSM::NonInviteServerTransaction and SIPFSM::InviteClientTransaction, S=
IPFSM::NonInviteClientTransaction ?
>
> Due to the fact that we want to be able to set nearly all sip headers (=
and some of sdp too) from our application we are not sure yet if we are e=
ven going to use OpenSBC or just OpenSIPStack directly to minimize the ov=
erhead of 2 applications communicating with each other. Also we want to b=
e able to act as a proxy and registrar (just like OpenSBC can do if I und=
erstand that right) but possibly also as a client when connecting to anot=
her server.
>
> What would be the best way to do this in your opinion?
>
> -----Original Message-----
> From: ope...@li... [mailto:opensips=
tac...@li...] On Behalf Of joegen@opensipstac=
k.org
> Sent: Freitag, 23. November 2007 12:57
> To: ope...@li...
> Subject: Re: [OpenSIPStack] Server implementation question
>
> Thomas Raschbacher wrote:
>  =20
>> Thanks. The 1st one solved my problem.
>>
>> So .. if I wanted to use a custom authentication class I assume I'd ha=
ve to inherit from B2BAuthInterface right? Also how would I then use that=
?
>> Meaning I still want opensipstack to handle the authentification when =
it gets a REGISTER (with www-auth,..), but want to get the user-credentia=
ls from our system instead of storing them in a list like OpenSBC does..
>>
>>    =20
>
> You are looking at the right place.  For a guy asking for
> documentations, you're doing quire well.
>
>  =20
>> To clarify I want opensipstack to handle the sip requests, but need it=
 to call methods in our application to get information about users, wethe=
r to allow a call or not, ... (also want to always route RTP through the =
application so that the conversation can be recorded if needed.)
>>
>>    =20
>
> If you want to not let opensbc handle RTP, you may need to override
> methods in B2BMediaInterface.   You may simply comment out the entire
> code blocks of TranslateSDPOffer and TranslateSDPAnswer and just return=

> TRUE in both places.
>
>
>  =20
>> /me continues evaluation of opensipstack ;)
>>
>> -----Original Message-----
>> From: ope...@li... [mailto:opensip=
sta...@li...] On Behalf Of joegen@opensipsta=
ck.org
>> Sent: Freitag, 23. November 2007 11:28
>> To: ope...@li...
>> Subject: Re: [OpenSIPStack] Server implementation question
>>
>> Two possible reasons:
>>
>> 1.  You are passing the address of SIPMessage msg to the SIPTransport
>> event which will be destroyed as soon as this function loses scope.
>> Try
>>
>> new SIPTransports::SIPTransportEvent( new SIPMessage(msg),
>> SIPTransports::SIPTransportEvent::UDPPacketArrival);
>>
>> instead.  SIPTransportEvent deletes this pointer in its destructor.
>>
>> 2.  If this is a debug build, OpenSIPStack might be using PMemoryHeap =
to
>> store NEWly create Objects.  Try putting a "#define new PNEW" in the
>> beginning of this file to force you new operator to use the correct
>> implementation.
>>
>>  From what I see, the culprit is item 1.
>>
>> Thomas Raschbacher wrote:
>>
>>    =20
>>> Hi.
>>>
>>> Please have a look at the following code:
>>>
>>> class OpenSipStack_StackTest
>>> {
>>> public:
>>>         void TransportEventTest(SIPMessage msg);
>>>         OpenSipStack_StackTest()
>>>         {
>>>                 m_Stack =3D new SIP::SIPStack();
>>>         }
>>> private:
>>>         SIP::SIPStack * m_Stack;
>>> }
>>>
>>> void OpenSipStackTest::OpenSipStack_StackTest::TransportEventTest(SIP=
Message msg)
>>> {
>>>         SIPTransports::SIPTransportEvent *evt =3D new SIPTransports::=
SIPTransportEvent(&msg, SIPTransports::SIPTransportEvent::UDPPacketArriva=
l);
>>>
>>>         this->m_Stack->OnTransportEvent(evt);
>>>         //this->OnTransportEvent(evt); // class was derived from SIP:=
:SIPStack before..
>>> }
>>>
>>> This is the program's output (I used a register message from the SIP =
rfc):
>>> 23:18:32.858    INF: [CID=3D0x0000] SIP Stack CREATED
>>> 23:18:32.943    DBG: [CID=3D0x06e0]
>>> 23:18:32.943    DBG: [CID=3D0x06e0]       RECEIVE:  REQ: REGISTER (18=
26)
>>> 23:18:32.943    DBG: [CID=3D0x06e0]       FROM: sip:bo...@bi...
>>> 23:18:32.943    DBG: [CID=3D0x06e0]       TO: sip:bo...@bi...
>>> 23:18:32.943    DBG: [CID=3D0x06e0]       XOR: FALSE
>>> 23:18:32.943    DBG: [CID=3D0x06e0]       SRC:  PORT:
>>> 23:18:32.943    DBG: [CID=3D0x06e0]
>>> 23:18:32.953    DBG: [CID=3D0x06e0]
>>> 23:18:32.953    DBG: [CID=3D0x06e0]       *** CREATING TRANSACTION (N=
IST) ***
>>> 23:18:32.953    DBG: [CID=3D0x06e0]       Message: REGISTER sip:regis=
trar.biloxi.c
>>> om SIP/2.0
>>> 23:18:32.953    DBG: [CID=3D0x06e0]       Call-Id: 843817637684230@99=
8sdasdh09
>>> 23:18:32.953    DBG: [CID=3D0x06e0]
>>> 23:18:32.962    DTL: [CID=3D0x06e0] NIST(83912963)        *** CREATED=
 *** - NIST|8
>>> 43817637684230@998sdasdh09|z9hG4bKnashds7|REGISTER
>>>
>>> At that point I get it triggering a breakpoint - heap related
>>> HEAP[OpenSipStackTestConsoleApp.exe]: Invalid Address specified to Rt=
lValidateHeap( 00350000, 0012FC94 )
>>> Windows has triggered a breakpoint in OpenSipStackTestConsoleApp.exe.=

>>>
>>> This may be due to a corruption of the heap, and indicates a bug in O=
penSipStackTestConsoleApp.exe or any of the DLLs it has loaded.
>>>
>>> The output window may have more diagnostic information
>>>
>>> (that is all from the output window..)
>>>
>>> This seems to happen at the end of the OnTransportEvent method (SIPSt=
ack.cxx: 431 ... delete event; )
>>>
>>> Any ideas?
>>>
>>> Thanks
>>>
>>> -----Original Message-----
>>> From: ope...@li... [mailto:opensi=
pst...@li...] On Behalf Of joegen@opensipst=
ack.org
>>> Sent: Freitag, 23. November 2007 10:27
>>> To: ope...@li...
>>> Subject: Re: [OpenSIPStack] Server implementation question
>>>
>>> SIP::SIPStack is probably the best place for you then.  You just need=
 to
>>> create your own SIPTransportEvent and feed it to OnTransportEvent()
>>> virtual method.   I agree that there is not much to work with in term=
s
>>> of documentation and I assure you that this is not a permanent
>>> condition.   It is just that all the hands working on the project are=

>>> currently busy with actual coding of functionalities.   For now, you'=
re
>>> best bet is to ask questions and we can answer it to the best of our
>>> abilities.   I also have plans of creating a near C API wrapper for t=
he
>>> stack to make implementors and integrators life easier.    One thing
>>> that might be a bit of a road block for you is that OpenSIPStack desi=
gn
>>> is not modular and that almost all components like the Transport, FSM=

>>> and the core are intertwined.  Thus, if you need to use third party
>>> replace ments, you will need to subclass the right component.
>>>
>>>
>>> Thomas Raschbacher wrote:
>>>
>>>
>>>      =20
>>>> Joegen,
>>>>
>>>> Well the main thing is that the transport layer is partially existin=
g already and needs to be implemented in some other part of the applicati=
on I think (also we need TCP and TLS too). Problem is that we need to do =
the switching and deciding if a call is valid or not,.. ourselves.
>>>> Maybe I missed something and this functionality can be achieved othe=
rwise (our application does have hardware to connect to analogue/digital =
phones as well as does the switching and more or less the 'media server/p=
roxy' too. Of course we want to use our switching and the media proxying =
- since call recording is a required features.)
>>>>
>>>> If there is an easier way to achieve this please let me know as it i=
s a bit difficult to find those things out as I couldn't find a lot of de=
veloper documentation / the code isn't commented very much explaining whi=
ch class exactly does what.
>>>>
>>>> Regards,
>>>> P.S.: I'm currently playing around with sending Transport events to =
a derived class of SIP::SIPStack and having that process the event to fin=
d out exactly what level of processing this class does already ... It wou=
ld really help me if there was some sort of documentation like an archite=
cture diagram or some short description of which class would be best to u=
se if I want some basic replies and timeouts already implemented, as I do=
n't know if SIPStack is even the right choice or if I rather should look =
at SIPFSM, ...
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: ope...@li... [mailto:opens=
ips...@li...] On Behalf Of Joegen E. Baclo=
r
>>>> Sent: Freitag, 23. November 2007 09:39
>>>> To: jo...@op...; ope...@li...=
t
>>>> Subject: Re: [OpenSIPStack] Server implementation question
>>>>
>>>> Thomas,
>>>>
>>>> BTW, OpenSIPStack default license is MPL 1.1 not GPL/LGPL.   If you =
are
>>>> afraid that the modification below will render your proprietary code=

>>>> violating the license, do not worry.  The only thing covered by the =
MPL
>>>> is the modification done to OpenSIPStack alone and not your entire
>>>> application.  Thus, If you indeed deploy your own transport, then th=
e
>>>> code block below is the only thing you are obliged to make open or
>>>> contribute back to OpenSIPStack.    Can you share why you want to us=
e
>>>> another transport though?
>>>>
>>>> Joegen
>>>>
>>>> jo...@op... wrote:
>>>>
>>>>
>>>>
>>>>        =20
>>>>> Hi Thomas,
>>>>>
>>>>> You need to create your custom transports as descendant of
>>>>> SIPTransport.   You would then need to override the following Virtu=
al
>>>>> Method in SIPTransportManager to return an instance fo your custom =
transport
>>>>>
>>>>> SIPTransport * SIPTransportManager::OnCreateTransport(
>>>>>   const char * userAgentName,
>>>>>   SIPTransport::Protocol protocol
>>>>> )
>>>>> {
>>>>>   if( protocol =3D=3D SIPTransport::UDP )
>>>>>     return new SIPUDPTransport( userAgentName, this );
>>>>>   else if( protocol =3D=3D SIPTransport::TCP )
>>>>>     return new SIPTCPTransport( userAgentName, this );
>>>>>
>>>>>   return NULL;
>>>>> }
>>>>>
>>>>>
>>>>> Hope that helps.
>>>>>
>>>>> Joegen
>>>>>
>>>>> Thomas Raschbacher wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          =20
>>>>>> Hi,
>>>>>>
>>>>>> If I wanted to use a custom transport without changing opensipstac=
kcode itself (ie it being in a different library and just sending events =
to the stack when it receives / sends/sent messages) how would I best do =
that? (Need to use existing transports in non (L)GPL application, but wan=
t to use as much of opensipstack as possible - the parser itself is no pr=
oblem of course, but I'd like to use a higher 'level' than just that whic=
h also implements timers and responses like TRYING, ...)
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Mit freundlichen Gr=FC=DFen
>>>>>> Thomas Raschbacher
>>>>>> ____________________________________________
>>>>>> itCampus Technology GmbH
>>>>>> =D6sterreich * Deutschland * Italien
>>>>>> Wehlistra=DFe 27b
>>>>>> 1200 Wien
>>>>>> tho...@it...
>>>>>> Tel: +43 (1) 33418557-58
>>>>>> Fax: +43 (1) 33418557-958
>>>>>> http://www.itctec.com
>>>>>> UID: ATU 6339 0618
>>>>>> Firmenbuchnr: FN292598t, Handelsgericht Wien
>>>>>> Gesch=E4ftsf=FChrer: Andreas G=FCnser, Andreas Lassmann
>>>>>> Joint Venture von itCampus und MEC
>>>>>>
>>>>>> itCampus Gruppe
>>>>>> Deutschland * Gro=DFbritannien * Italien * =D6sterreich * Schweiz =
* Slowakei
>>>>>> http://www.itcampus.eu
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------=
-------
>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>> _______________________________________________
>>>>>> opensipstack-devel mailing list
>>>>>> ope...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            =20
>>>>> -------------------------------------------------------------------=
------
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> opensipstack-devel mailing list
>>>>> ope...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          =20
>>>> --------------------------------------------------------------------=
-----
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> opensipstack-devel mailing list
>>>> ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>
>>>> --------------------------------------------------------------------=
-----
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> opensipstack-devel mailing list
>>>> ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        =20
>>> ---------------------------------------------------------------------=
----
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> opensipstack-devel mailing list
>>> ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>
>>> ---------------------------------------------------------------------=
----
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> opensipstack-devel mailing list
>>> ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>
>>>
>>>
>>>
>>>
>>>      =20
>>
>> ----------------------------------------------------------------------=
---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> opensipstack-devel mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>
>> ----------------------------------------------------------------------=
---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> opensipstack-devel mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>
>>
>>
>>
>>    =20
>
>
>
> -----------------------------------------------------------------------=
--
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
> -----------------------------------------------------------------------=
--
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
>
>  =20