With other SBC's, it holds the refer locally and negotiates between the two (UA and ITSP), and thats what the Acme needs to do in this case. The UA (phone) knows how to handle REFER, and if sipxbridge is handling the trunking or remote users, it also holds the refer and doesn't transmit it to the provider.
On Tue, Mar 13, 2012 at 6:22 AM, Emilio Panighetti <[email protected]> wrote: > > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum > In-Reply-To: <CAMgKNJVaKB4cG3Q6jFMM=hqPoV+=k3jo=WieGqzFb= > [email protected]> > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <66564> > Message-ID: <[email protected]> > > > > Tony > > Thanks for getting back to me. > > The SBC is an Acme Packet. The way we have it set up; in > relation to sipXecs is as follows: > > The SBC has 'access'; 'peer' and 'core' realms. > > When an IP phone registers; it does it through the 'access' > realm; which performs NAT traversal and routes the call to > sipXecs via its core realm. sipXecs sees the device as not > behind NAT. > > When calling voicemail or conference bridge on sipXecs; > there is only one session going from the IP phone though the > SBC to sipXecs. > > When I dial a PSTN number; the call has the same flow as > above except that sipXecs proxies the INVITE to the SBC on > its 'peer' realm. The SBC in turn transparently delivers the > call to the appropriate PSTN trunk. > sipXecs sees the peer realm as a gateway; as in there are no > registrations. > > The SBC is configured to anchor media from the IP phone to > sipXecs, but it doesn't anchor media on the peer realm. > > So let's say we have a call established as: > > IP Phone -> [SBC access] -> [SBC core] -> sipXecss -> [SBC > peer] -> SIP Trunk provider > > media is anchored at the SBC: The IP phone sees [SBC access] > media address and everything else after that sees media > coming from [SBC core]. Both of these are routable IPs; so > this suits the needs. > > Now the IP phone initiates an unattended transfer to another > PSTN number. > > the REFER shows the same path as above; but [SBC peer] is > configured to reject the REFER because [SIP Trunk provider] > does not allow the REFER method; so the REFER cannot be > completed. My expectation; after using other software like > FreeSHITCH; was that sipXecs would consume the REFER and in > turn generate another INVITE towards PSTN number [SBC peer]. > Seems I'm mistaken in my expectation here. > > For MOH; what I, perhaps naively; though it would happen is > that if sipXecs receives a ReINVITE originated from the IP > phone where its SDP contains 'a=sendonly'; it would ReINVITE > the PSTN leg to its IVR which is playing MOH. Once the IP > phone sends another ReINVITE with 'a=sendrecv'; sipXecs then > forwards that SDP so its IVR in no longer on the call. > > my questions in regards to sipXecs is what is the expected > behavior in this case when it receives a REFER or the > On-hold signal from the IP phone. > > Thanks > _______________________________________________ > 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/
