I would be interested in why the SBC tries to onvolve itself in an entirely internal call. If you have an SBC, the question becomes what ytou are using it for...
trunking remote users This is the most typical deployment, where the SBC passes the registrations through to sipx and sipx is no aware of nat or remote users and the SBC is usually an unamanaged gateway for dialplan use. If it is configured like this, internal calls will not involve the SBC and the SBC will simply be involved with trunking and remote users. You might consider providing more information on how your SBC fits into your network and what functionality you are expecting from its current configuration. On Tue, Mar 13, 2012 at 5:26 PM, Douglas Hubler <[email protected]> wrote: > On Tue, Mar 13, 2012 at 5:17 AM, Emilio Panighetti <[email protected]> > 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 > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
