Support per channel DID setting for sip in addition to zap

Note that to permit sip trunk channels, the zapchandids sql table needs to allow non-numeric channels (int->varchar) as must the javascript page validation. The patch currently makes changes to functions.inc.php only

As an extra feature for sip trunks it is possible in "[Zap] Channel DIDs" page to use the magic string 'siptoheader' to have the DID taken from the sip To: header rather than statically configured. This is very useful for some types of trunk in which the DID is advertised there.

Please find attached a revised patch that adds the ability to automatically modify the datatype of the channel field as required to store non numeric sip channel names

Please find attached a patch to page.zapchandids.php that allows channels to be non numeric so as to accept sip trunk channel names. The patch also removes reference to zap.

The sip To: header sometimes has more or less space between the header name and the content so I have amended the patch to cut at the : delimiter rather than assume four characters. The DID in the sip To: header can now be accepted as To:DID@host To :DID@host To : DID@host etc in addition to the common To: DID@host

May I please have feedback on this patch. Are there any changes required before it can be adopted.

Nick,

I haven not had time to load and test this (although changed the state to Need Testing so that we can get some feedback.

If we go this route, we probably want to modify the GUI with some radio button or similar to indicate the type of channel, specify the "To" field for DIDs in the case of sip channels, probably handle iax channels as well, and see if we can't have a select box for the sip/iax channels vs. using text which can lead to typos, etc.

just some thoughts

Ok

I guess that you are proposing radio buttons to distinguish the channel tech so that different technologies with the same channel name do not clash. The likelihood of a clash is small but if the radio button on the page automatically adds the Zap/ SIP/ or IAX/ prefix that would remove all risk. Note that the channel field in the database would then need to contain all the channel info including the prefix so that a full match against the incoming call could be made.

The use of a magic string to support the to header was copied from the CID stuff. Without it the database table would need an extra field. I suppose the page could have a button which was translated to a magic string in the database.

I think the addition of IAX would be very simple. The context for an IAX trunk would have to be set to from-trunk-iax-TRUNKNAME for it to work. I can add support for IAX channel names as I expect them to be but I do not have facilities to test IAX.

The disadvantage in using a select box over text is that it does not permit the user to bypass bugs in asterisk. There are a couple currently - the username is displayed in the channel name instead of the peername and the ip address is displayed in the channel name if the trunk uses a nat proxy

I have attached a patch sipiaxchandid.patch which I hope works with IAX too. It does not make any further changes to the web page

I am going to divert this out of 2.6. If we make this change I would like to see it thought out better without 'hidden' fields, etc. It should explicitly choose which channel, etc. (on top of being renamed from 'zap...'

#860 was closed deferred here.