VoIP Mailing List Archives

[gordon+asterisk at dro...]

Heres a weird one...

Call comes in on mISDN channel. Little bit of dialcode (in a macro) looks
up the number in the astdb and puts an name to it. No real magic there,
and it works well.

Same macro also has parameter passed in to put a prefix on the name - this
is set in the DDI handling and is dependent on the number called and
allows phone users to see which number was called (company trading under
different names with different phone numbers type of thing). Again, no
issues there - it's working nicely.

Until someone calls in withholding their number.

Then no amount of Set(CALLERID(name)=somethin) will work. Even if I
explicitly do a Set before the dial, it seems to get ignored.

Extract from console output:

-- Executing NoOp("mISDN/3-1", "CallerID is still "DDI+Joby" <123>") in new stack

(the result of an earlier 'force' by me in the macro)

-- Executing Set("mISDN/3-1", "CALLERID(all)=Test <123>") in new stack

(explicit set)

-- Executing NoOp("mISDN/3-1", "CallerID is still "Test" <123>") in new stack

(and test)

-- Executing Dial("mISDN/3-1", "IAX2/299&SIP/299||WwTton") in new stack

the final dial ...

So no-matter what, I would expect to see Test and 123 on the phone.
However I see Unknown Unknown on it when I call in, withholding the
number. If I call in and don't withhold the number, then I see Test and
123 as expected.

I'm sure it's not a phone issue either as far as I can tell - eg. from
this extract of tshark output:

Via: SIP/2.0/UDP 1.2.3.4:5060;branch=z9hG4bK693cea19;rport
From: "Unknown" <sip:Unknown at 1.2.3.4>;tag=as646048bf
SIP Display info: "Unknown"
SIP from address: sip:Unknown at 1.2.3.4
SIP tag: as646048bf
To: <sip:299 at 81.31.100.110:5062;transport=udp>

(some IP addresses changed to protect the guilty

I'm using a Grandstream GXP2000 here, but a colleague is using a Snom and
sees the same thing as I do. (I'm remote from the LAN, colleague is on the
same LAN, but I don't think that has anything to do with it)

So is this some artifact of mISDN bludgeoning it's way into the SIP stack
and forcing caller ID to be unknown, or what?

It's asterisk 1.2.26.1 if this makes any difference at this point. Latest
mISDN drivers as far as I'm aware.

If I call into the system on a SIP or IAX trunk, then it "just works".
(and does the right thing when I withhold number), it's just withheld
number mISDN calls that thwart my changing of the caller ID!

So why can't I change caller ID on an incoming mISDN call when the caller
withholds their number!?!

It's very frustrating.

Any insight welcome.

Thanks,

Gordon

[support at drdos.info]

Gordon Henderson wrote:

[gordon+asterisk at dro...]

On Thu, 13 Mar 2008, Doug Lytle wrote: