Re: [Kamailio-Users] Anyone doing CNAM lookups?

2008-10-24 Thread Klaus Darilion


Sajith T S schrieb:
 Klaus Darilion [EMAIL PROTECTED] wrote:
 
 What do you mean with asynchronously? Do you forward the INVITE
 without waiting for the CNAM response?
 
 Yes, CNAM queries were in a different thread.

So, how do you send the Name to the callee once the CNAM response is 
received?

regards
klaus

___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users


Re: [Kamailio-Users] Anyone doing CNAM lookups?

2008-10-24 Thread Sajith T S
Klaus Darilion [EMAIL PROTECTED] wrote:
 
 So, how do you send the Name to the callee once the CNAM response is
 received?

By calling CNAM as early as possible in INVITE processing, and then
hoping for the best. :) (And I guess it could be sent in the
subsequent messages if at all possible, but I'm not sure.  I was
trying to recall the details myself because this is pretty old code
we're talking about..)

Predictably enough, this did not work well all the time and so
customers did complain our claims of supplying caller name are wrong.
Of course it is hard to guarantee that CNAM will work all the time
unless we are willing to delay or drop calls.

-- 
the lyf so short, the craft so long to lerne.  
 -- Chaucer.


___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users


Re: [Kamailio-Users] Anyone doing CNAM lookups?

2008-10-24 Thread Sajith T S
Klaus Darilion [EMAIL PROTECTED] wrote:

 What do you mean with asynchronously? Do you forward the INVITE
 without waiting for the CNAM response?

Yes, CNAM queries were in a different thread.

-- 
the lyf so short, the craft so long to lerne.  
 -- Chaucer.


___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users


Re: [Kamailio-Users] Anyone doing CNAM lookups?

2008-10-23 Thread Brian McCrary
On Thu, Oct 23, 2008 at 07:02:38AM +0200, Klaus Darilion wrote:

Hello Klaus,

 If you need to trigger SUBSCRIBE you would need the pua module. You 
 would need to write a new module which either sends SUBSCRIBE directly 
 (via tm module) or which links into pua module (which support 
 SUBSCRIBE/NOTIFY in a generic ways).

Thanks for your response!  I was not aware of the pua module.  It looks 
like it would be a good starting point, especially with it's database 
functions.  I think I need to get to work today in setting up a new test 
server so I can play with these new modules and see what changes need to 
be made.

 Do you have a specification of the CNAM lookup (Event: type, payload ...)
 
 I am not used to CNAM (does not exist in Europe) - how does it work? Do 
 you query the CNAM database during call setup - thus delaying the call 
 setup until you got the answer from the lookup? Or is this an 
 asynchronous mechanism?

Yes, I will post the information I have from Verisign on how it works (a
little lengthy but it does a good job of describing it).  The idea is
indeed to query the database during call setup, and wait for the answer. 
Then the lookup would be forwarded to the SIP phone, ideally in the From
field or P-Asserted Identity giving the called party the name of who is 
calling them.

This info taken from the Verisign manual:

IP CNAM Connectivity

VeriSign's IP CNAM connectivity option provides IP access to calling
name databases using the services of the Session Initiation Protocol
(SIP). How IP CNAM Works CNAM Subscribers in the network can subscribe
to CNAM Notifiers' name services on a per call basis. The CNAM Notifiers
can broker those calling name subscriptions to either SS7-resident
databases or IP-resident databases.  The CNAM Notifiers, acting on
behalf of the name databases, can send a notification when those calling
name subscriptions are resolved into the name availability indicator,
calling name, if present, and permanent privacy status associated with
the calling directory number. 

If the name is not to be delivered to the called end-user equipment
because of a 'private' privacy status associated with the name, a 'From'
header display-name parameter with a value of 'private' is sent to the
called end-user equipment. If the name availability indicator reveals
that the name is not available for delivery, a 'From' header
display-name parameter with a value of 'out-of-area/unavailable' is sent
to the called end-user equipment. Otherwise, a 'From' header
display-name parameter containing the derived calling name is sent to
the called end-user equipment. 

Node Behavior
-
This section describes how the CNAM subscriber and CNAM Notifier 
functions.

CNAM Subscriber Behavior

To achieve carrier-grade availability and optimal transaction rates, the
CNAM Notifier is optimized to support stateless fetch transactions. When
the subscribe request is transmitted by a CNAM Subscriber to a CNAM
Notifier, this requirement translates to the 'Expires' header having a
value of zero (0) or, alternatively, a subscribe request with no
'Expires' header present, which implies the default value of zero (0) as
defined by the 'calling-name-info'  event package [2]. This use of
subscribe polling reduces the complexity of the calling name event,
limiting the duration of the subscription to a single calling name fetch
and avoiding the necessity to support state related procedures such as
unsubscribing and refreshing subscriptions.

The Request URI of a subscribe request contains enough information to
route the request to the appropriate CNAM Notifier, as listed in the
request routing procedures outlined in SIP. For example, a SIP URI
populated with the fully qualified domain name (FQDN) of the VeriSign
Calling Name Gateway: sip:cnam-gateway.verisign.com. CNAM Subscribers
must populate exactly one 'Event' header in the Subscriber request,
indicating they are subscribing to the calling-name event ('Event:
calling-name').1 Optionally, the CNAM Subscriber may also include within
the 'Event' header an 'id' parameter, which contains an opaque token
that identifies the specific calling name subscription within a SIP
peer-to-peer dialog (e.g. 'Event:calling-name; id=2'). The CNAM Notifier
includes this token, if present, in the corresponding Notify request.

CNAM Notifier Behavior

The CNAM Notifier confirms the Subscribe request with a final response. 
A '200 OK' response indicates that the calling name subscription has
been accepted and that the CNAM Subscriber is authorized to subscribe to
the requested calling name information.

Non-200 class final responses indicate that no subscription has been
created, and no subsequent NOTIFY response is sent. For example, if the
responsible IP-resident or SS7-resident name database is not
out-of-service because of temporary overload conditions, transmission
availability, or maintenance activities. The CNAM Notifier returns a
'503 Service 

Re: [Kamailio-Users] Anyone doing CNAM lookups?

2008-10-23 Thread Klaus Darilion


Brian McCrary schrieb:
 On Thu, Oct 23, 2008 at 07:02:38AM +0200, Klaus Darilion wrote:
 
 Hello Klaus,
 
 If you need to trigger SUBSCRIBE you would need the pua module. You 
 would need to write a new module which either sends SUBSCRIBE directly 
 (via tm module) or which links into pua module (which support 
 SUBSCRIBE/NOTIFY in a generic ways).
 
 Thanks for your response!  I was not aware of the pua module.  It looks 
 like it would be a good starting point, especially with it's database 
 functions.  I think I need to get to work today in setting up a new test 
 server so I can play with these new modules and see what changes need to 
 be made.
 
 Do you have a specification of the CNAM lookup (Event: type, payload ...)

 I am not used to CNAM (does not exist in Europe) - how does it work? Do 
 you query the CNAM database during call setup - thus delaying the call 
 setup until you got the answer from the lookup? Or is this an 
 asynchronous mechanism?
 
 Yes, I will post the information I have from Verisign on how it works (a
 little lengthy but it does a good job of describing it).  The idea is
 indeed to query the database during call setup, and wait for the answer. 
 Then the lookup would be forwarded to the SIP phone, ideally in the From
 field or P-Asserted Identity giving the called party the name of who is 
 calling them.

If the INVITE needs to get blocked during the lookup (to wait for the 
name) I wonder why the lookup is done asynchronous. IMO a simple HTTP 
request would be more efficient.

Of course if the INVITE is forward immediately and once the lookup 
finished an UPDATE with the CNAME is sent, then this sounds useful. But 
generating UPDATEs would require a B2BUA.

In general I think this is not easy to achieve with Kamailio as you have 
to delay the INVITE till the NOTIFY is received. Due to the Kamailio 
architecture this will easily block all Kamailio processes and thus 
Kamailio can not process the NOTIFYs anymore.


regards
klaus



   --SUBSCRIBEt--

 This info taken from the Verisign manual:
 
 IP CNAM Connectivity
 
 VeriSign's IP CNAM connectivity option provides IP access to calling
 name databases using the services of the Session Initiation Protocol
 (SIP). How IP CNAM Works CNAM Subscribers in the network can subscribe
 to CNAM Notifiers' name services on a per call basis. The CNAM Notifiers
 can broker those calling name subscriptions to either SS7-resident
 databases or IP-resident databases.  The CNAM Notifiers, acting on
 behalf of the name databases, can send a notification when those calling
 name subscriptions are resolved into the name availability indicator,
 calling name, if present, and permanent privacy status associated with
 the calling directory number. 
 
 If the name is not to be delivered to the called end-user equipment
 because of a 'private' privacy status associated with the name, a 'From'
 header display-name parameter with a value of 'private' is sent to the
 called end-user equipment. If the name availability indicator reveals
 that the name is not available for delivery, a 'From' header
 display-name parameter with a value of 'out-of-area/unavailable' is sent
 to the called end-user equipment. Otherwise, a 'From' header
 display-name parameter containing the derived calling name is sent to
 the called end-user equipment. 
 
 Node Behavior
 -
 This section describes how the CNAM subscriber and CNAM Notifier 
 functions.
 
 CNAM Subscriber Behavior
 
 To achieve carrier-grade availability and optimal transaction rates, the
 CNAM Notifier is optimized to support stateless fetch transactions. When
 the subscribe request is transmitted by a CNAM Subscriber to a CNAM
 Notifier, this requirement translates to the 'Expires' header having a
 value of zero (0) or, alternatively, a subscribe request with no
 'Expires' header present, which implies the default value of zero (0) as
 defined by the 'calling-name-info'  event package [2]. This use of
 subscribe polling reduces the complexity of the calling name event,
 limiting the duration of the subscription to a single calling name fetch
 and avoiding the necessity to support state related procedures such as
 unsubscribing and refreshing subscriptions.
 
 The Request URI of a subscribe request contains enough information to
 route the request to the appropriate CNAM Notifier, as listed in the
 request routing procedures outlined in SIP. For example, a SIP URI
 populated with the fully qualified domain name (FQDN) of the VeriSign
 Calling Name Gateway: sip:cnam-gateway.verisign.com. CNAM Subscribers
 must populate exactly one 'Event' header in the Subscriber request,
 indicating they are subscribing to the calling-name event ('Event:
 calling-name').1 Optionally, the CNAM Subscriber may also include within
 the 'Event' header an 'id' parameter, which contains an opaque token
 that identifies the specific calling name subscription within a SIP
 peer-to-peer dialog (e.g. 

Re: [Kamailio-Users] Anyone doing CNAM lookups?

2008-10-22 Thread Klaus Darilion
Hi Brian!

If you need to trigger SUBSCRIBE you would need the pua module. You 
would need to write a new module which either sends SUBSCRIBE directly 
(via tm module) or which links into pua module (which support 
SUBSCRIBE/NOTIFY in a generic ways).

Do you have a specification of the CNAM lookup (Event: type, payload ...)

I am not used to CNAM (does not exist in Europe) - how does it work? Do 
you query the CNAM database during call setup - thus delaying the call 
setup until you got the answer from the lookup? Or is this an 
asynchronous mechanism?

regards
klaus

Brian McCrary schrieb:
 I've been using OpenSER 1.0.1 for the past couple of years, but I now 
 need to add CNAM lookups.  It looks like the presence module might be 
 what I need, although from the looks if it, it's made to respond to 
 lookups, instead of actually generate a query to another server for a 
 lookup.  
 
 I'm looking at doing CNAM lookups with Verisign which look to 
 interface with a SUBSCRIBE message, in which in return Verising sends 
 back a NOTIFY message with one of the fields being calling-name which 
 has the CNAM info in it.  
 
 Has anyone been succesful in implementing such a lookup with Verisign or 
 another CNAM database provider?
 
 Brian
 
 ___
 Users mailing list
 Users@lists.kamailio.org
 http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users