opensipstack-osbcdevel

[OpenSBC] An enhanced HTTP Config Module for OpenSBC

[Joegen E. B. <joe...@gm...>]

Hi Everyone,

As I have hinted in the past, there is a plan to provide a new level of 
administrative interface for OpenSBC.  As most of you might have 
discovered by now, OpenSBC is very easy to install and requires 
virtually no configuration for you to be able to run and use it.   This 
is all because of a built-in HTTP server that allows for OpenSBC to be 
configured remotely.   However, since version 1.1.4 and with the 
introduction of more advanced features like SIP Trunking, the built-in 
HTTP Config Pages is out-growing its simplicity.    We are now in a 
point where we need to decide what technology to use to bring the 
configuration modules to the next level.    We need to seriously 
consider the following criteria in choosing the solution.

1.  It should be very easy to install and package
2.  Built-in access to back-end databases preferably Postgress
3.  Must be able to host Dynamic HTML Content
4.  Other criteria that might be useful are support for XML-RPC and SOAP


Some of the basic choices that I pulled out straight from my thoughts are

1.  A separate web interface easily installable as standard Apache Web 
application.  Choices are PHP, JSP Ruby with SQL back-end
2.  Stand-alone Python HTTP Server just like the trac project.  See 
http://trac.edgewall.org/
3.  Enhance the HTTP Admin to support Fast-CGI extension to allow for 
dynamic HTTP content to be hosted straight by OpenSBC

I would want to hear from everyone if you are leaning towards a certain 
approach or would want another approach altogether.

Joegen

Re: [OpenSBC] An enhanced HTTP Config Module for OpenSBC

[Jonas G. <jon...@gm...>]

I would use a SQL backend and do #3.

On Dec 3, 2007 4:42 AM, Joegen E. Baclor <joe...@gm...> wrote:
> Hi Everyone,
>
> As I have hinted in the past, there is a plan to provide a new level of
> administrative interface for OpenSBC.  As most of you might have
> discovered by now, OpenSBC is very easy to install and requires
> virtually no configuration for you to be able to run and use it.   This
> is all because of a built-in HTTP server that allows for OpenSBC to be
> configured remotely.   However, since version 1.1.4 and with the
> introduction of more advanced features like SIP Trunking, the built-in
> HTTP Config Pages is out-growing its simplicity.    We are now in a
> point where we need to decide what technology to use to bring the
> configuration modules to the next level.    We need to seriously
> consider the following criteria in choosing the solution.
>
> 1.  It should be very easy to install and package
> 2.  Built-in access to back-end databases preferably Postgress
> 3.  Must be able to host Dynamic HTML Content
> 4.  Other criteria that might be useful are support for XML-RPC and SOAP
>
>
> Some of the basic choices that I pulled out straight from my thoughts are
>
> 1.  A separate web interface easily installable as standard Apache Web
> application.  Choices are PHP, JSP Ruby with SQL back-end
> 2.  Stand-alone Python HTTP Server just like the trac project.  See
> http://trac.edgewall.org/
> 3.  Enhance the HTTP Admin to support Fast-CGI extension to allow for
> dynamic HTTP content to be hosted straight by OpenSBC
>
> I would want to hear from everyone if you are leaning towards a certain
> approach or would want another approach altogether.
>
> Joegen
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Opensipstack-osbcdevel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-osbcdevel
>

Re: [OpenSBC] An enhanced HTTP Config Module for OpenSBC

[Joegen E. B. <joe...@gm...>]

To sum up.  One in the list is in favor of a python approach and another 
in favor of a built-in fast CGI approach.   Everyone seems unanimous in 
having SQL server support.  Just this morning, Ryan Colobong pointed me 
to http://www.cherrypy.org/ which is another python based solution to 
incorporate dynamic web pages to opensbc.   There seem to be a lot of 
resources we could use in a python based solution.   However, fast-cgi 
support in OpenSBC would carry on the tradition of simplicity in 
installation, it will take a lot longer just to develop the module that 
enabled fast-cgi support not to mention that HTTP is not really the turf 
OpenSIPStack.   At this point I am leaning towards a python based 
solution.   For those who  are willing to pitch in your ideas, now is 
the time to speak up.

Joegen



Joegen E. Baclor wrote:
> Hi Everyone,
>
> As I have hinted in the past, there is a plan to provide a new level of 
> administrative interface for OpenSBC.  As most of you might have 
> discovered by now, OpenSBC is very easy to install and requires 
> virtually no configuration for you to be able to run and use it.   This 
> is all because of a built-in HTTP server that allows for OpenSBC to be 
> configured remotely.   However, since version 1.1.4 and with the 
> introduction of more advanced features like SIP Trunking, the built-in 
> HTTP Config Pages is out-growing its simplicity.    We are now in a 
> point where we need to decide what technology to use to bring the 
> configuration modules to the next level.    We need to seriously 
> consider the following criteria in choosing the solution.
>
> 1.  It should be very easy to install and package
> 2.  Built-in access to back-end databases preferably Postgress
> 3.  Must be able to host Dynamic HTML Content
> 4.  Other criteria that might be useful are support for XML-RPC and SOAP
>
>
> Some of the basic choices that I pulled out straight from my thoughts are
>
> 1.  A separate web interface easily installable as standard Apache Web 
> application.  Choices are PHP, JSP Ruby with SQL back-end
> 2.  Stand-alone Python HTTP Server just like the trac project.  See 
> http://trac.edgewall.org/
> 3.  Enhance the HTTP Admin to support Fast-CGI extension to allow for 
> dynamic HTTP content to be hosted straight by OpenSBC
>
> I would want to hear from everyone if you are leaning towards a certain 
> approach or would want another approach altogether.
>
> Joegen
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Opensipstack-osbcdevel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-osbcdevel
>
>
>   

Re: [OpenSBC] [OpenSIPStack] B2BUA how to route

[Joegen E. B. <joe...@gm...>]

sales@ER wrote:
> Hi Joegen
>
>   
>> I see what you mean.   I am not really familiar with the use of the
>> Remote-Party-Id.   We have implemented P-Asserted-Identity for this
>> instead.   Can you point me to the RFC that discusses the use cases for
>> Remote-Party-Id?
>>     
>
> Yes the P-Asserted-Identity replaced the Remote-Party-Id in the RFC but it
> is still in used in older SBC models and my ITSP has not updated the SBC i
> am accessing.  I need to modifry the xml code to and and elseif to test for
> this possiblity.   Please direct me to the xml that is managing this
> identity.
>   

For you be able to rewrite any header before it gets sent to the UAS you 
need to override SBCBackDoorCallHandler::OnOutgoingCall();

Look for the declaration of class SBCBackDoorCallHandler in 
SBCBackDoorTrunk.cxx.  Add a new member function

virtual void OnOutgoingCall(
    B2BUAConnection & connection,
    B2BUACall & call,
    SIPMessage & invite
  );


This function will be called whenever there is a new INVITE that will be 
sent out by the backdoor trunk.   Implement this function right after 
BOOL SBCBackDoorCallHandler::OnReceivedMergedInvite() methid in 
SBCBackDoorTrunk.cxx


You may add special headers to invite using this code

SIPHeader myHeader(  "Remote-Party-Id", "Whatever the value is" );
invite.AddCustomHeader( myHeader );

HTH

Joegen
> Warren Kreckler
>
>
> ----- Original Message ----- 
> From: "Joegen E. Baclor" <joe...@gm...>
> To: "sales@ER" <sa...@el...>
> Sent: Tuesday, December 11, 2007 8:32 PM
> Subject: Re: [OpenSIPStack] B2BUA how to route
>
>
>   
>> sales@ER wrote:
>>     
>>> Hi Joegen
>>>
>>> Thank you very much for your replies.
>>>
>>> 1.  I'm using the lastest version.
>>>
>>>       
>> Then your ITSP must be seeing just a single via.  If you think the
>> contrary, send me a packet capture from sipx->OpenSBC and OpenSBC->ITSP
>>
>>
>>
>>     
>>> 3.  sipX does not re-write  header as far as I know.  Are you asking for
>>> sipX header(s) dealing with Caller-ID?
>>>
>>>  Remote-Party-ID to determine the Calling ID.  This is not an element
>>> created
>>>  by Sipx.  The SBC will need to extract the user part of the From URI
>>>       
> and
>   
>>>  create a Remote-Party-ID. I did not see this capability with OpenSBC.
>>>  Without this, the called party on the PSTN will either see "Private
>>>  Caller"or "Anonymous" on their phone instead of the DID.
>>>
>>>
>>>       
>> I see what you mean.   I am not really familiar with the use of the
>> Remote-Party-Id.   We have implemented P-Asserted-Identity for this
>> instead.   Can you point me to the RFC that discusses the use cases for
>> Remote-Party-Id?
>>
>>
>>     
>>> Warren Kreckler
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- 
>>> From: "Joegen E. Baclor" <joe...@gm...>
>>> To: "sales@ER" <sa...@el...>
>>> Cc: <ope...@li...>
>>> Sent: Sunday, December 09, 2007 7:21 PM
>>> Subject: Re: [OpenSIPStack] B2BUA how to route
>>>
>>>
>>>
>>>       
>>>> inline...
>>>>
>>>> sales@ER wrote:
>>>>
>>>>         
>>>>> Yes  They call it peer to peer.  By that they meam
>>>>>
>>>>>
>>>>> 1. Via Headers: ITSP has stated that they can accept only 1 Via
>>>>> statement in an INVITE.  As background, each device will add a Via
>>>>>
>>>>>           
>>> statement
>>>
>>>       
>>>>> to the INVITE to if it has processed the INVITE.  Only the last or top
>>>>>
>>>>>           
>>> entry
>>>
>>>       
>>>>> is really of interest to the party that next handles the INVITE.  In
>>>>>
>>>>>           
>>> order
>>>
>>>       
>>>>> for ITSP to accept the INVITE of an outbound call, OpenSBC will
>>>>> need to strip off all previous Via statements from the INVITE and add
>>>>>
>>>>>           
>>> its'
>>>
>>>       
>>>>> own.  I have not found any capability to remove the previously
>>>>>           
> inserted
>   
>>> Via
>>>
>>>       
>>>>> statements.
>>>>>
>>>>>
>>>>>           
>>>> What version are you using?   There was a bug introduced when we got
>>>> back from sipIT 21 due to the changes made there that had the vias not
>>>> getting stripped.  Please use the latest CVS.   OpenSBC should be
>>>> stripping the via before the B2BUA sends the INVITE out to the UAS.
>>>>
>>>>
>>>>
>>>>         
>>>>> 2.  Lock IP Address and port to first sender: This option comes into
>>>>>
>>>>>           
>>> play
>>>
>>>       
>>>>> when a call has been answered either by a person or system component
>>>>>
>>>>>           
>>> (i.e.
>>>
>>>       
>>>>> Auto Attendant) and a transfer is attempted.  When the transferred
>>>>>           
> call
>   
>>> is
>>>
>>>       
>>>>> answered by a new phone or component, it will negotiate use of a new
>>>>>           
> RTP
>   
>>>>> port for the media stream.  Some service providers, ITSP included,
>>>>> do not allow the RTP port to change once the initial call is
>>>>>
>>>>>           
>>> established.
>>>
>>>       
>>>>> They do this to protect against the "hijacking" of a call by Hackers.
>>>>>
>>>>>           
>>> Since
>>>
>>>       
>>>>> the media is flowing through a SBC, the SBC then needs to manage which
>>>>>
>>>>>           
>>> ports
>>>
>>>       
>>>>> are used to exchange media (voice).   If the original port is not
>>>>>
>>>>>           
>>> utilized
>>>
>>>       
>>>>> for the media back to the carrier, the PSTN will not hear any audio
>>>>>           
> once
>   
>>> the
>>>
>>>       
>>>>> call is transferred.  I do not see this capability with OpenSBC.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> In media proxy mode (Always Proxy Media = true), OpenSBC does not
>>>>         
> change
>   
>>>> the port of RTP even during reInvites.
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> 3.  Calling ID:  SIPxchange utilizes the From: element to provide the
>>>>> Calling ID (DID).  It normally inserts the userID in the user part of
>>>>>
>>>>>           
>>> the
>>>
>>>       
>>>>> >From URI.  ITSP uses the INVITE element
>>>>> Remote-Party-ID to determine the Calling ID.  This is not an element
>>>>>
>>>>>           
>>> created
>>>
>>>       
>>>>> by Sipx.  The SBC will need to extract the user part of the From URI
>>>>>           
> and
>   
>>>>> create a Remote-Party-ID. I did not see this capability with OpenSBC.
>>>>> Without this, the called party on the PSTN will either see "Private
>>>>> Caller"or "Anonymous" on their phone instead of the DID.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> Can you send a sample of this from header that is rewritten by sipX?
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> Warren Kreckler
>>>>>
>>>>> ----- Original Message ----- 
>>>>> From: "Joegen E. Baclor" <joe...@gm...>
>>>>> To: <ope...@li...>
>>>>> Cc: <jo...@op...>
>>>>> Sent: Friday, December 07, 2007 12:08 AM
>>>>> Subject: Re: [OpenSIPStack] B2BUA how to route
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> You need to use the SIP Trunking capability of OpenSBC for this.   Do
>>>>>> you need to authenticate calls with your ITSP?
>>>>>>
>>>>>>
>>>>>> sales@ER wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Hi
>>>>>>>
>>>>>>> Almost have this puppy working.
>>>>>>>
>>>>>>> Sipx and opensbc generally well understood.
>>>>>>>
>>>>>>> Problem:
>>>>>>>
>>>>>>> When OSBC receives INVITE from sipX =>  ITSP,
>>>>>>> OSBC route the INVITE back to sipX.
>>>>>>>
>>>>>>> We have two rules in the B2Bua route
>>>>>>> [sip:202.100.2.23:5060] sip: 202.100.2.23  this goes to our ITSP
>>>>>>> [sip:sipx.sip.net:5060] sip:sipx.sip.net            this point to
>>>>>>>               
> our
>   
>>>>>>>               
>>>>> sipx
>>>>>
>>>>>
>>>>>           
>>>>>>> the missing rule/route?
>>>>>>>
>>>>>>> Where do you put the rule and what should the rule say to route
>>>>>>>               
> INVITE
>   
>>>>>>>               
>>>>> out
>>>>>
>>>>>
>>>>>           
>>>>>>> to our ITSP?
>>>>>>>
>>>>>>> Warren Kreckler
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> ------------------------------------------------------------------------
>>>>         
> -
>   
>>>>>>> SF.Net email is sponsored by: The Future of Linux Business White
>>>>>>>               
> Paper
>   
>>>>>>> from Novell.  From the desktop to the data center, Linux is going
>>>>>>> mainstream.  Let it simplify your IT future.
>>>>>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>>>>>>> _______________________________________________
>>>>>>> opensipstack-devel mailing list
>>>>>>> ope...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> ------------------------------------------------------------------------
>>>>         
> -
>   
>>>>>> SF.Net email is sponsored by:
>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>> It's the best place to buy or sell services for
>>>>>> just about anything Open Source.
>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>> _______________________________________________
>>>>>> opensipstack-devel mailing list
>>>>>> ope...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>>
>>>>>           
>>>
>>>
>>>
>>>       
>>     
>
>
>
>
>