[Freeswitch-users] Freeswitch as a B2B Application Server for IMS

[Michael Jerris]

Some of these things make sense is some scenarios but not others.   
Most people are wanting to do full topology hiding, so we don't by  
default pass very much across a bridge.  I am interested in working on  
this, feel free to contact me off list with your findings.

Mike

On Jun 17, 2009, at 11:20 AM, Cavalera Claudio Luigi wrote:

> Hello freeswitchers,
> lately I'm trying to set up a testbed to ivestigate a potential use of
> freeswitch as a Back-to-Back application server in an IMS  
> architecture.
>
> I've seen IMS specs are also linked here
> http://wiki.freeswitch.org/wiki/Documentation
> so I've thinked maybe there's a chance :-)
>
> I also have the inner feeling that fs could do an amazing job in IMS
> field as he does in NGN.
>
> For my testing I'm now using OpenIMSCore as control layer (where  
> phones
> do register) and I'm trying to put fs on top of it as a b2b  
> application
> server to provide services.
>
> I would like to share with you my experience to see if something could
> be done about this scenario (or if it's worth the trouble at least).
>
> Alice and Bob are two users registered to the IMS Core and they both
> have a profile for which originating and terminating INVITEs get
> triggered towards the fs application server.
>
> When Alice calls Bob the call setup would include three legs:
>
> 1) Alice -> PCSCF (orig) -> SCSCF (orig) -> FS (orig)
>
> 2) FS (orig) -> SCSCF (orig) -> ICSCF -> SCSCF (term) -> FS (term)
>
> 3) FS (term) -> SCSCF (term) -> PCSCF(term) -> Bob
>
>
> This partially works already with fs out of the box, but there are a
> still a few issues to be solved.
>
> When FS starts the brand new leg 2) as a B2B User Agent he should keep
> the Route: header in the SIP INVITE "almost the same" as the one he
> received in the leg 1)
>
> I see here two different issues:
> a) Getting the Route: header out of incoming invite in leg 1)
> b) Writing the proper Route: header and have FS behaving correctly at
> transport layer in the outgoing INVITE in leg 2)
>
> a) Now please correct me if I'm wrong: at the moment the <Route:>  
> header
> is not a channel variable available in fs (e.g. I don't get it with  
> the
> "info" app). It there were a way to get this header out of the  
> incoming
> INVITEs, I could do the logic to parse it and forge a proper one in  
> the
> outgoing INVITE.
>
>
> b) Concerning how to write the <Route> header, I'm already working  
> with
> fs_path directive which also makes FS behaves correctly at network
> layer.
> Could someone please elaborate a little bit about the alternative to
> fs_path directive?
>
> I've seen there are already many in theory:
> - combining sip_h_Route= with
> http://wiki.freeswitch.org/wiki/Variable_sip_network_destination
> - use of http://wiki.freeswitch.org/wiki/Variable_sip_route_uri
> - use of fs_path=
> http://wiki.freeswitch.org/wiki/ 
> Sofia#Specifying_SIP_Proxy_With_fs_path
>
>
> I've simplified the scenario a little bit, there are other things that
> the B2B AS should do (e.g. removing Record-Route:) but FS do them
> already from what I've tested.
> If anyone in the community is interested I'm here to provide further
> information or share my experience to implement the best solution.
>
> Best regards,
> Claudio
>
>
>
>
> Internet Email Confidentiality Footer
> -----------------------------------------------------------------------------------------------------
> La presente comunicazione, con le informazioni in essa contenute e  
> ogni documento o file allegato, e' rivolta unicamente alla/e persona/ 
> e cui e' indirizzata ed alle altre da questa autorizzata/e a  
> riceverla. Se non siete i destinatari/autorizzati siete avvisati che  
> qualsiasi azione, copia, comunicazione, divulgazione o simili basate  
> sul contenuto di tali informazioni e' vietata e potrebbe essere  
> contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia  
> di protezione dei dati personali). Se avete ricevuto questa  
> comunicazione per errore, vi preghiamo di darne immediata notizia al  
> mittente e di distruggere il messaggio originale e ogni file  
> allegato senza farne copia alcuna o riprodurne in alcun modo il  
> contenuto.
>
> This e-mail and its attachments are intended for the addressee(s)  
> only and are confidential and/or may contain legally privileged  
> information. If you have received this message by mistake or are not  
> one of the addressees above, you may take no action based on it, and  
> you may not copy or show it to anyone; please reply to this e-mail  
> and point out the error which has occurred.
> -----------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org