Privacy ID on AVAYA IP Office

[hadala]

Hello,

I'm looking for some explanations about the Privacy (CLIR) on the AVAYA IP Office.
When I place an incoming call on my IP Ofiice (with blocking the caller id) I can see that the number shown on my phone is the P-Asserted-Identity.
I can see the field : "privacy : id", and in SIP FROM I have the field "anonymous" <sip:anonymous@anonymous.invalid>.
Instead of showing me Anonymous on the phone, the IP Office showing me the P-Asserted-Identity number!
There are no clear documentation about the CLIR on the Avaya IP Office.
Could you please help me?

Thank you,

 

[hadala]

Any Idea?

 

[hairlessupportmonkey]

I suspect actually the SIP provider has the WRONG field fill out when sending caller ID.

Gamma do it all the time, with held numbers always show up on gamma SIP trunks.

ACSS - SME
General Geek

 

[hadala]

Hello,

Thank you for your fast reply.
The SIP provider don't have a WRONG field (because I'm the SIP Provider!! ).
I work for an ITSP and we trying to do some interworkings tests to validate the IP Office 500 in our network.
Look at the incoming call, this is a "simplified" INVITE request:

FROM : "Anonymous" <sip:anonymous@anonymous.invalid>
Privacy: id
P-Asserted-Identity: "09XXXXXXXX" <sip:09XXXXXXXX@sip.domain>

In the Phone:
I see Anonymous, and when I unhook the phone, I see the caller ID.

Why the phone displays the P-Asserted-Identity field when I unhook the phone instead of just Anonymous??
I think it's a bug from AVAYA, but maybe some AVAYA expert on this forum can give me the response.

 

[hairlessupportmonkey]

Ok, so what version of software is the IPO on?

ACSS - SME
General Geek

 

[hairlessupportmonkey]

rel 7 has this available now:

· Association Method: Default = Source IP Address. Software level = 7.0
The setting allows the method by which a SIP line can become associated with an incoming SIP request to be changed.

· Pre-IP Office 7.0: The system associates incoming SIP requests with a particular SIP line in its configuration by matching the source IP address of the request to. If no match is found the request is ignored. This means that in pre-IP Office 7.0 systems, each SIP line must have a unique IP address or fully qualified domain name that can be resolved to an address.

· IP Office 7.0 and higher: The match criteria used for each line can be varied. The search for a line match for an incoming request is done against each line in turn using each lines Association Method. The order of line matching uses the configured Line Number settings until a match occurs. If no match occurs the request is ignored. This method allow multiple SIP lines with the same address settings. This may be necessary for scenarios where it may be required to support multiple SIP lines to the same ITSP. For example when the same ITSP supports different call plans on separate lines or where all outgoing SIP lines are routed from the system via an additional on-site system.

· By Source IP Address
This option uses the source IP address and port of the incoming request for association. The match is against the configured remote end of the SIP line, using either an IP address/port or the resolution of a fully qualified domain name. This matches the method used by pre-IP Office 7.0 systems.

· "From" header hostpart against ITSP domain
This option uses the host part of the From header in the incoming SIP request for association. The match is against the ITSP Domain Name above.

· R-URI hostpart against ITSP domain
This option uses the host part of the Request-URI header in the incoming SIP request for association. The match is against the ITSP Domain Name above.

· "To" header hostpart against ITSP domain
This option uses the host part of the To header in the incoming SIP request for association. The match is against the ITSP Domain Name above.

· "From" header hostpart against DNS-resolved ITSP domain
This option uses the host part of the FROM header in the incoming SIP request for association. The match is found by comparing the FROM header against a list of IP addresses resulting from resolution of the ITSP Domain Name above or, if set, the ITSP Proxy Address on the Transport tab.

· "Via" header hostpart against DNS-resolved ITSP domain
This option uses the host part of the VIA header in the incoming SIP request for association. The match is found by comparing the VIA header against a list of IP addresses resulting from resolution of the ITSP Domain Name above or, if set, the ITSP Proxy Address on the Transport tab.

· "From" header hostpart against ITSP proxy
This option uses the host part of the “From” header in the incoming SIP request for association. The match is against the ITSP Proxy Address on the Transport tab.

· "To" header hostpart against ITSP proxy
This option uses the host part of the From header in the incoming SIP request for association. The match is against the ITSP Proxy Address on the Transport tab.

· R-URI hostpart against ITSP proxy
This option uses the host part of the Request-URI in the incoming SIP request for association. The match is against the ITSP Proxy Address on the Transport tab.


ACSS - SME
General Geek

 

[hadala]

Hello,

I have the last release 7.0(12) of the 27 may 2011.
I tried with all of the options that you send me above.
It appear that I can see the INVITE but the IPO don't keep the call.
That don't affect the displaying on the phone but the Association with the IPO.
If you have an IPO can you please tell me if when you call with a privacy identity that shows you the caller-id when you unhook the phone?
If not can you told me if in the INVITE request you can see the P-Asserted-Identity?

Thank you for your time and help

 

[hairlessupportmonkey]

the IPO generally only gives out what it receives.

It will be worth studying how the IPO handles SIP more closely and seeing if you can get your side to work with it.

what are you using to deliver the trunks?

We are a 50% holder in a SIP provider using a Genband M6 from Broadsoft / broadworks, and we dont have this issue.


ACSS - SME
General Geek

 

[hadala]

Hello,

The IPO only gives out what it receives.
That sentence is true, but just tell me if it's works for you, what did you receive?

We don't send whatever we want but we work with the RFC3325 for the CLIR (Calling Line identification Restriction).

In this RFC, you can see that you must send in the FROM header "Anonymous" <sip:anonymous@anonymous.invalid>

In the other side we have to know who is the caller (here in France it's the LAW) and in the same time for CDR and billing we have to know who is the caller.

So, we have to send the Caller-ID in one another field like the P-Asserted-Identity, but we will not display it.

Now I see the IPO INVITE Request with the blocking caller-id for an outbound call, and I have exactly the same thing with an inbound call :

"Anonymous" <restricted@sip.domain> instead of "Anonymous" <sip:anonymous@anonymous.invalid>
In the same time I have the P-Asserted-Identity field and the Privacy:id.

So why the IPO display the Caller-ID for an inbound call?
Why he show me the P-Asserted-Identity field?
Maybe he don't understand the Privacy:id but in the same time when you make a call with blocking your number he put this header! So He have to understand it, no?

So I don't think that the IPO only give what out what he receives but he give out what he want!

Thank you