Freeswitch as a B2B Application Server for IMS
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. -----------------------------------------------------------------------------------------------------
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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Cavalera Claudio Luigi
-
Michael Jerris