Acme Packet docs; The parameter is called refer-calltransfer. When this feature is enabled, the Net-Net SBC creates an INVITE
message whenever it receives a REFER. From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Tuesday, March 13, 2012 6:57 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Signaling issues on new install 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=4-ok-...@mail.gmail.com> 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 "The information in this electronic mail message is the sender's confidential business and may be legally privileged. It is intended solely for the addressee(s). Access to this internet electronic mail message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful." "The sender believes that this E-mail and any attachments were free of any virus, worm, Trojan horse, and/or malicious code when sent. This message and its attachments could have been infected during transmission. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. The sender's employer is not liable for any loss or damage arising in any way from this message or its attachments." "In connection with representing sellers and/or buyers in real estate transactions, Coldwell Banker Residential Brokerage real estate sales associates have absolutely no authority to create binding contractual obligations on behalf of a seller or on behalf of a buyer via any written or verbal communications including, but not limited to email communications." [v1.0.07.109]
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
