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/
