Jump to content
KAZOOcon: hackathon signup and details here! ×

Edit History

RuhNet

RuhNet

I did quite a bit of experimentation with similar Cisco phones in the past. After much work, I was never able to get them to send the domain, rather than the IP in requests. This is of course generally fine with single-tenant PBX systems, but doesn't work with Kazoo.  Modifying the headers with Kamailio/OpenSIPS is of course an option as you mention. However, the issue is that unless your system only has a single account, or at least only a single account is using Cisco phones, you'd have to have some sort of dynamic way to figure out which account/realm to associate the incoming Cisco phone with.

You could write a little external API service that handled this, and have Kamailio use HTTP (or AMQP if you wanted) to lookup the proper realm from the API by either using the incoming IP, or from a code of some sort included in the username, or possibly from the MAC address on the request (I don't remember if Cisco phones send MAC along with all requests or not.)

I'm not aware of any way to be able to lookup a realm/account for a particular device from the Kazoo API, since most things require the account or realm as the starting point for Kazoo to know which DB to search for the device in to begin with. So it's likely that a fully integrated solution isn't possible, without some custom code somewhere that keeps track of which devices belong where. 

Actually, now that I think about it, you could maybe encode the realm in the username, and have Kamailio strip it off and rewrite the domain using it.

So for example, you could set your username to:

cisco101_customer.sip.domain.com

and have Kamailio treat anything past the underscore as the realm when useragent is Cisco, extract it, and rewrite.

I don't know if the periods would give a problem with SIP user but if so you could always substitute them for two underscores or something like that and have Kamailio do a regex substitution on it before using as the realm.

This should be reasonably easy to implement in the native Kazoo Kamilio config script.

RuhNet

RuhNet

I did quite a bit of experimentation with similar Cisco phones in the past. After much work, I was never able to get them to send the domain, rather than the IP in requests. This is of course generally fine with single-tenant PBX systems, but doesn't work with Kazoo.  Modifying the headers with Kamailio/OpenSIPS is of course an option as you mention. However, the issue is that unless your system only has a single account, or at least only a single account is using Cisco phones, you'd have to have some sort of dynamic way to figure out which account/realm to associate the incoming Cisco phone with.

You could write a little external API service that handled this, and have Kamailio use HTTP (or AMQP if you wanted) to lookup the proper realm from the API by either using the incoming IP, or from a code of some sort included in the username, or possibly from the MAC address on the request (I don't remember if Cisco phones send MAC along with all requests or not.)

I'm not aware of any way to be able to lookup a realm/account for a particular device from the Kazoo API, since most things require the account or realm as the starting point for Kazoo to know which DB to search for the device in to begin with. So it's likely that a fully integrated solution isn't possible, without some custom code somewhere that keeps track of which devices belong where. 

Actually, now that I think about it, you could maybe encode the realm in the username, and have Kamailio strip it off and rewrite the domain using it.

So for example, you could set your username to:

cisco101_customer.sip.domain.com

and have Kamailio treat anything past the underscore as the realm when useragent is Cisco, extract it, and rewrite.

I don't know if the periods would give a problem with SIP user but if so you could always substitute them for two underscores or something like that and have Kamailio do a regex substitution on it before using as the realm. This should be reasonably easy to implement in the native Kazoo Kamilio config script.

RuhNet

RuhNet

I did quite a bit of experimentation with similar Cisco phones in the past. After much work, I was never able to get them to send the domain, rather than the IP in requests. This is of course generally fine with single-tenant PBX systems, but doesn't work with Kazoo.  Modifying the headers with Kamailio/OpenSIPS is of course an option as you mention. However, the issue is that unless your system only has a single account, or at least only a single account is using Cisco phones, you'd have to have some sort of dynamic way to figure out which account/realm to associate the incoming Cisco phone with.

You could write a little external API service that handled this, and have Kamailio use HTTP (or AMQP if you wanted) to lookup the proper realm from the API by either using the incoming IP, or from a code of some sort included in the username, or possibly from the MAC address on the request (I don't remember if Cisco phones send MAC along with all requests or not.)

I'm not aware of any way to be able to lookup a realm/account for a particular device from the Kazoo API, since most things require the account or realm as the starting point for Kazoo to know which DB to search for the device in to begin with. So it's likely that a fully integrated solution isn't possible, without some custom code somewhere that keeps track of which devices belong where. 

Actually, now that I think about it, you could maybe encode the realm in the username, and have Kamailio strip it off and rewrite the domain using it.

So for example, you could set your username to:

cisco101_customer.sip.domain.com

and have Kamailio treat anything past the underscore as the realm when useragent is Cisco, extract it, and rewrite.

I don't know if the periods would give a problem with SIP user but if so you could always substitute them for two underscores or something like that and have Kamailio do a regex substitution on it before using as the realm.

×
×
  • Create New...