Setting custom outbound SIP parameters on a bridge

[datamerge]

I have set up some bridges to remote systems (non 3CX). They work great except that they expect to see my extension number in the user part of the FROM: field. On a bridge none of the fields except for the displayname part of the from field are configurable.

Is there some sneaky back door way to set this?

 

[andreasc]

Hi there ,

What Version of the PBX are you using ?
Edit a bridge go to Advance and on Outbound Parameters (SIP Filed) what Variable are you using ?

 

[datamerge]

Hi Andreas

It is v15. The only outbound variable available on the Outbound paramters under advanced is the FROM: Displayname. This is good, but the return number is the virtual extension number of the bridge, so the callee can't call back from their own call log. I would like to be able to change the FROM: user part as I can in a SIP trunk.

 

[andreasc]

Hi Andreas

It is v15. The only outbound variable available on the Outbound paramters under advanced is the FROM: Displayname. This is good, but the return number is the virtual extension number of the bridge, so the callee can't call back from their own call log. I would like to be able to change the FROM: user part as I can in a SIP trunk.

Hi ,

I think you need to check this
http://www.3cx.com/docs/bridging-asterisk-pbx/ and this
https://www.3cx.com/community/threads/bridging-3cx-with-an-asterisk-pbx.44726/

also can you take a screenshot of an invite ?
by default if you call throw a bridge you can see the extension number and the bridge prefix

 

[datamerge]

I have read the documents and they were helpful. However, I am not connecting to asterisk. I am bridging to other commercial products. They expect to see the extension number in the from: user part. Currently this is set (not changeable) to the bridge number. Calls work perfectly in both directionsHowever, when a remote user receives an incoming call from a 3cx user, they see the remote user name fine, but the number they see is the 3cx bridge extension number. This means they can't call back directly from their call log.

 

[andreasc]

the issue is what the commercial product you are using is sending.
if you can not fix this from the commercial product site i suggest you to do it delete the bridge and do it as a sip trunk .
In the sip trunk there are options to control INBOUND parameters .

 

[datamerge]

The issue is not receiving from the third party pbx. It is sending to the third party pbx. The third party pbx(s) use the from: header to get the caller id, which is as per the RFC. 3cx puts the bridge extension number in there instead of the calling extension number. I was hoping to be able to modify the from part in the outbound sip fields as I can in a sip trunk.

 

[andreasc]

ok now i understand what do you want to achieve.
As i said
1) attach a screenshot of the invite and highlight what do you want to change exactly.
2) you can delete the bridge and configure it as a Sip Trunk where more INBOUND and OUTBOUND Parameters are available

 

[leejor]

The issue may be that most other commercial PBXs only allow registrations to the in the form of an extension, not a trunk. The Bridge trunk option, in 3CX, allows it to behave as a SIP provider so the far end PBX can register to it, as it would any other provider. Unfortunately, using the Bridge options (at this point) doesn't allow the same flexibility in modifying the headers, as does a SIP trunk. Sounds like a feature request might be in order. It shouldn't be that difficult to move the same options available with a SIP trunk, over to a bridge trunk.

 

[datamerge]

Unfortunately, using the Bridge options (at this point) doesn't allow the same flexibility in modifying the headers, as does a SIP trunk. Sounds like a feature request might be in order. It shouldn't be that difficult to move the same options available with a SIP trunk, over to a bridge trunk.

You've got it Lee! That is exactly the issue. I did originally use SIP trunks, but it means you need to create multiple DIDs for every SIP trunk because the SIP trunk treats the remote party as external. Bridging is nice as incoming DIDs are implicitly internal. Even when I configure SIP trunks to a carrier, I have to change the FROM: User part to "Outbound Caller ID". It is set to authid by default.

I am not aware of any SIP providers that don't use the FROM: header to indicate the caller ID.

I was hoping there might be a back door way to get this info into my bridge.

Andreas, I attached a screenshot from a sip trunk outbound parameters page to show you what I want.

 

[andreasc]

Hi datamerge,

Upgrade to SP4 then edit the bridge and press ok .
Try know to reproduce and let me know the results.

 

[datamerge]

I will do this as soon as it comes for Linux Andreas. I just updated to Linux SP3 and got my reports, fax and Exchange sync, so I am very happy right now.

 

[andreasc]

how smooth and fast was the update ?

anw if you are in the build 15.0.60903.0 try this with the bridge

 

[datamerge]

The update was very smooth. I have updated three Linux and one Windows in the past hour or so. It took about 5 minutes and I had to run through a config wizard again on a couple of them, but not all which was a bit strange. All 4 systems had no issues.

I did try the bridge again, but it still shows the caller ID on the other system as E.G. Mark Dutton (10007). What I would like to show is Mark Dutton (110)

It is not a show stopper for me, but it would be nice to get the call back number coming through correctly if possible.

 

[AramS_3CX]

Hi datamerge,

You need to configure your "other commercial product" (sorry, I don't know the name of it) to get the caller ID information from the "Remote-Party-ID" header.
The user part of "From" header can't be modified. This is our policy. But to provide to users the ability to have the real caller number we implemented the "Remote-Party-ID" header. Your device can easily get the caller ID from that header.
For example, in your case SIP INVITE will have the following headers:
.....
From: "Mark Dutton"<sip:[email protected]:5060;rinstance=a334rt3g7c2602cc54>;tag=8e4faw4f
.....
Remote-Party-ID: "Mark Dutton"<sip:[email protected]:5060>;party=calling
....

Hope your other product can do this and this solution will help you.

 

[datamerge]

Yes I have seen the header. Unfortunately, the other systems (two different types) don't have the option to get the caller ID from an alternative source. That was why I was hoping I might be able to do something sneaky to change the from: header.

 

[NickD_3CX]

The only other thing I can suggest would be, in the "Advanced" tab of the bridge, to change the "From : Display Name" to be populated with the "CallerNum" variable, so that INVITE would look something like:

.....
From: "110"<sip:[email protected]:5060;rinstance=a334rt3g7c2602cc54>;tag=8e4faw4f
.....
Remote-Party-ID: "110"<sip:[email protected]:5060>;party=calling
....

Now if the the other side can take the "From : Display Name" and use it as the calling number, then that would be another way to go, however you would loose the actual name being display on the devices as that would not be sent.

Other than that, I can't think of any other way this can be achieved through the use of Bridges, so the other option would be to replace that with a Generic SIP Trunk.
I know it has been mentioned earlier, and I agree it is quite a bit more of a tedious procedure, but it will give you a lot more flexibility.

 

[datamerge]

Yeah thanks Nick. I started out that way (with trunks). It was just nice to have that implicit connection between all handsets via a bridge. As I know the limitations I can live with them and I can as you say do the trunk thing if it becomes that important. Perhaps one day we will see those extra options appear in bridges.