On Tue, Mar 13, 2012 at 5:17 AM, Emilio Panighetti <emilio...@me.com> wrote: > That's interesting. So if I read you correctly; sipXecs is a > stateless proxy only? Similar in objective to SER and its > derivative projects?
sipXecs includes a stateless proxy called sipXproxy (like SER) and would be the default path when you're doing unattended transfer between local registered endpoints. If you're doing an unattended transfer to a PSTN number however, you need to consider the gateway capabilities and configuration. > I tried Freeswitch for this application, but although it > works, I wasn't impressed on how it rewrites SIP messages > and related SDP; thus searching for a 'pure sip' > implementation that lead me to sipXecs. > > The SBC used in this case can process the REFER; but in > doing so it means the From: and To: headers won't be > rewritten by sipXecs as it's done on INVITEs. > Also, if sipXecs won't intervene in putting calls on/off > hold; what's the purpose of the MOH implementation within > sipXecs? How is a typical implementation supposed to work? MOH uses Freeswitch, so sipXproxy won't intervene but Freeswitch will > Somehow I expected sipXecs would be stateful; although not > necessarily a B2BUA as stated in the 'why-sipxecs' page on > the sipfoundry portal; thus being able to handle basic PBX > functionality internally. I guess you could say sipXecs is stateful as a whole, but sipXproxy is not, so unless you're dial plan involves Freeswitch, sipXbridge the SIP is mostly passed thru unchanged. > Perhaps an example would be appropriate. Is there a sort of > showcase implementation that mentions the role of different > network elements in relation to sipXecs? Like the handling > of call transfers and MOH. n, but would be nice. rummage around on wiki, you may find some gems. disclaimer: Not a SIP guy, but I play one on mailing list. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
