On Sep 25, 2012, at 17:36, Alex Balashov <abalashov at evaristesys.com> wrote:

According to very unambiguous directives from the pertinent RFCs, all routing should always be done based on the Request URI / INVITE request line. The To header should NEVER be used for routing (in >= 3261). It is a purely cosmetic commentary on the intended logical endpoint of the call.

True de juris. All over the map de facto. At least judging from some of my vendor's offerings. And to respond to the original question, while I have no experience with your endpoint, that is generally the point at which I start doing header rewrites on the Acmes. I find it easier than arranging for a meeting of the minds between the two+ vendors involved. --Jon Radel

**grumble** There's an Edgemarc in the middle and it is throwing a 404 because it doesn't know what to do with the call. I think I am now sending what the 3CX wants but unfortunately a proxy is required for this implementation. I knew it was too soon to declare victory. Back to scratching my head. On Tue, Oct 2, 2012 at 8:33 AM, PE <peeip989 at gmail.com> wrote:

Thanks all. It is too early to declare victory but based on my tests it looks like the Acme SIPConnect feature + Broadworks Alternate Trunk Identity is going to be the solution.

On Tue, Sep 25, 2012 at 5:27 PM, PE <peeip989 at gmail.com> wrote:

...

Greetings fellow voipsters,

Have any of you done a SIP trunk integration between Broadsoft and 3CX? Or, more specifically, I have a customer with a 3CX device (don't ask) that is registered and I can send an INVITE, but their end denies the call (sends a 480 Temporarily Unavailable response) because it is having trouble routing it to the destination in the 3CX system. This is because they are expecting only the extension (4-digits), which I can send in the To: header but the SIP URI is the full, registered User ID so that the SBC knows how to get it to them. They are expecting only 4 digits in both the INVITE URI header and the To header.

I know I can create a complex/convoluted header manipulation with the SBC but it just feels like there must be another way.

Anyone know how to config the 3CX -- or even have a decent workaround -- to support this?

Thanks

It is B2BUA. 3CX registers to EM, EM registers to Acme. Note, we also have handsets behind the same Edgemarc that are doing transparent proxy. I don't think that plays a role here but thought I'd throw it out there. Thanks Pete On Tue, Oct 2, 2012 at 10:34 AM, Zak Rupas <zak at simplesignal.com> wrote:

Are you using B2BUA or the old school EM trunking setup?

*Thanks?*

Zak Rupas | Tier 3 Engineer

[image: Description: Description: cid:image001.png at 01CBDE2D.5E1CC730]

Support Line 303-242-8616 Option 1

www.simplesignal.com

*From:* voiceops-bounces at voiceops.org [mailto: voiceops-bounces at voiceops.org] *On Behalf Of *PE *Sent:* Tuesday, October 02, 2012 8:21 AM *To:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] Broadsoft / 3CX SIP Trunks

**grumble**

There's an Edgemarc in the middle and it is throwing a 404 because it doesn't know what to do with the call. I think I am now sending what the 3CX wants but unfortunately a proxy is required for this implementation.

I knew it was too soon to declare victory. Back to scratching my head.

On Tue, Oct 2, 2012 at 8:33 AM, PE <peeip989 at gmail.com> wrote:

Thanks all. It is too early to declare victory but based on my tests it looks like the Acme SIPConnect feature + Broadworks Alternate Trunk Identity is going to be the solution.

On Tue, Sep 25, 2012 at 5:27 PM, PE <peeip989 at gmail.com> wrote:

Greetings fellow voipsters,

Have any of you done a SIP trunk integration between Broadsoft and 3CX? Or, more specifically, I have a customer with a 3CX device (don't ask) that is registered and I can send an INVITE, but their end denies the call (sends a 480 Temporarily Unavailable response) because it is having trouble routing it to the destination in the 3CX system. This is because they are expecting only the extension (4-digits), which I can send in the To: header but the SIP URI is the full, registered User ID so that the SBC knows how to get it to them. They are expecting only 4 digits in both the INVITE URI header and the To header.

I know I can create a complex/convoluted header manipulation with the SBC but it just feels like there must be another way.

Anyone know how to config the 3CX -- or even have a decent workaround -- to support this?

Thanks