[ANI when forwarding]

*BUMP*

 

I'm still looking for this. NexSIP, pbxnsip, you guys still here?

 

Thanks!

[ANI when forwarding]

Did you try all the CID types on the trunk? P aasterted, No Indication, etc., we had this requirement a while back and were able to change the CID type on our inbound trunk to acomplish this, we did have 2 trunks though 1 for in and 1 for out.

 

Yep, tried that. We only have 1 trunk configured. What could the inbound / outbound trunk add to the picture? It doesn't change all that much. Fact will remain that it sends out our SIP account name, instead of a number. See codebox below, this is the invite the PBX makes when it starts a new call for the redirection.

 

 

Real:

INVITE sip:316148xxxxx@test.winitu.com SIP/2.0
Via: SIP/2.0/UDP 10.1.2.250:5060;branch=z9hG4bK-0cef403e1f3262153d574353882d0166;rport
From: "ocsproduction" <sip:ocsproduction@test.provider.com>;tag=852891320
To: <sip:316148xxxxxx@test.provider.com;user=phone>
Call-ID: 9415cdaa@pbx
CSeq: 2199 INVITE
Max-Forwards: 70
Contact: <sip:ocsproduction@10.1.2.250:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE
Accept: application/sdp
User-Agent: pbxnsip-PBX/4.0.1.3438
Related-Call-ID: 1761cef4@pbx
Content-Type: application/sdp
Content-Length: 233

 

Instead of the sip:ocsproduction@test.provider.com, we want it to give the extension ANI, which is a DID. So e.g. FROM: <sip:0123456DID@test.provider.com>.

[ANI when forwarding]

Set the ANI on the extension, set the CID on the incoming trunk to no indication.

 

This does not work. We have one SIP account, which has multiple DID numbers attached to it. When we set the ANI on the extension it works correctly when calling from the extension. However, when calls are forwarded / redirected, it does NOT use the extension ANI, but the SIP account name. This is not expected behaviour, well.. at least not wanted in our case.

 

All that we would like is some kind of a setting where we can choose how the FROM header is generated for redirection..

[ANI when forwarding]

That is going to be tricky.

 

The only thing that comes to my mind is to loop the request through the PBX to shake off the original caller-ID. Pretty dirty, IMHO not really worth thinking about it.

 

There is no time-of-day ANI representation, that part is clear!

 

Hi,

 

sorry to drag up such an old topic, but this is exactly what we have been trying to do for some time now. Could you elaborate on how one could achieve this? I have been trying to loop the call through the PBX to get rid of the original caller, but I cannot get it to work. Is there any other option since this post? Is this still possible by looping?

 

Duplicating the trunk (as nexSIP suggests) is not really an option, since we want to do this for ~ 10 different DID's. This would mean we would have to create 10 trunks, but our SIP provider only allows 2 registrations per account.

 

Thanks!

[SOAP access in the new version problem]

I've just solved the problem by changing the "HTTP/1.1" protocol to: "HTTP/1.0"

 

Could someone with acces to the wiki / support site please update this, took me some good time to find this solution... If it was put on the wiki correctly, the php script on the server work almost directly.

 

Also, if this person could make it possible to download the files, in stead of copying them, it would be a lot more easy. Also, the php on the wiki is malformed and has some small errors.

[OCS <TLS> pbxnsip]

TLS port setting is in Admin->Settings->Ports page

 

At the moment I have tried editing the settings, renewing the certs and creating the config on a windows and linux machine. However I am still unable to get it to work. I'm trying to get in touch with an SSL / windows cert expert, but no luck so far

[OCS <TLS> pbxnsip]

Hello Kaj, Hello pbxnsip,

 

I guess we can find the solution for this challenge in this AudioCodes Document about:

 

Configuring AudioCodes Gateways to Operate in TLS Transport Mode with Microsoft™ Mediation Server

 

In step II it tells about the Mediations Server Preparation, and a hotfix for this TLS Setup. (it is not MTLS like normal between all OCS Roles)

 

This is for OCS - non R2 We're working with R2.

 

 

My verdict is, in your case:

 

1. OCS is doing an outbound call and presenting its certificate. Pbxnsip is simply accepting it. Does it make an crl (Certificate Revocation List) check to the rootCA? I guess not.

 

2. But OCS is not accepting the certificate presented by pbxnsip. Maybe the hotfix will ease this.

 

Please give the AudioCodes document a try. btw: I am sure you dont need to buy a commercial certificate! If it does not work with the windows CA, it will never work with a payed one! Lets save the money

 

Best regards,

Jan

 

1. I guess this is a question towards pbxnsip, I have no clue. Sounds plausible. But isn't crl the base of secure communications?

 

2. I could give it a try, but it doesn't state the R2. I would image that MS has included the hotfix in R2.

 

Anyways, I'll try to do some more magic with the certificates. Perhaps I'm missing a step somewhere. I'll try to get a nice wireshark trace as well.

 

Thanks for the help!

 

Kaj

 

Edit: Is it possible to somehow alter the port to which pbxnsip sends the TLS traffic to? It looks like it is sending it to port 5061, but this is the wrong port, since OCS wants internal TLS traffic on 5061, external (whatever type of transport) on port 5060. The audiocodes manual Jan referred to also states that they change the TLS port to 5060.

 

Also: The cert has to be valid, since when I go to https://url-of-pbxnsip/ on the mediation server it says the cert is valid.

[OCS <TLS> pbxnsip]

This should be a certificate problem. IF you get one, make sure that you use a 1024-bit certificate. I remember there was an issue using more than 1024 bits.

 

I did do that. It looks like the pbxnsip does not accept the certificate presented by the Mediation server. So it is possible? Have you had any experience doing this?

[OCS <TLS> pbxnsip]

Hello everybody,

 

At the moment we have setup a nice testing environment with OCS R2, integrated with Exchange UM. Everything was working fine with TCP transport. However we want to step up the security a notch and are trying to get TLS transport working. However, I seem to have gotten the settings correct for TLS, but calling to OCS does not work. Calling from OCS is working fine. Calling to OCS (from PSTN for example) however is not. As far as I can see the TLS handshake fails, which is odd, because it does work the other way.

 

What I am wondering, is there anyone else who has been able to set up pbxnsip to OCS with TLS?

 

If that's the case, we'll be trying to get some real certs instead of the one's from our own enterprise-CA.

 

Thanks!

 

Kaj