VoIP Mailing List Archives

[Claudio.Cavalera at it...]

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

[mike at jerris.com]

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: