[Home]

Summary:ASTERISK-06026: overriding callerid in sip.conf does not work
Reporter:Jan-Peter Koopmann (jkoopmann)Labels:
Date Opened:2006-01-10 01:54:19.000-0600Date Closed:2011-06-07 14:10:37
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch6183.diff
Description:Hi,

in my dialplan I use Set(CALLERID(number)) and Set(CALLERID(name)) to set what I want. Unfortunatly one of my SIP peers needs the Displayname and Username in FROM to be equal:

SIP/2.0 403 Displayname and Username in FROM must be equal
Via: SIP/2.0/UDP 84.167.87.77:5060;branch=z9hG4bK4714c80c;rport=5060
From: "Koopmann" <sip:032229115417@tel.t-online.de>;tag=as412803df


Obviously the "Koopmann" comes from a Set(CALLERID(name)=Koopmann) in the dialplan. So I though putting a suitable callerid statement in the sip.conf peer  should help:

[sip_t-online]
type=peer
...
callerid=032229115417 <032229115417>

But to my big surprise the problem persists and the SIP Header From still shows my name instead of the callerid in sip.conf. From the documentation the callerid parameter should override callerid (and I suppose callername), should it not?
Comments:By: Russell Bryant (russell) 2006-01-10 23:02:09.000-0600

Are you still doing Set(CALLERID(name)=Koopmann) in your dialplan?  If so, this is expected behavior.
By: Jan-Peter Koopmann (jkoopmann) 2006-01-11 00:11:33.000-0600

I am and I know that's the cause. It is just not the expected behaviour (at least I do not expect it). If in your dialplan you usually set your CALLERID name and number, there should still be the possibility to override it in outgoing iax and sip peers. There are rare cases in which your SIP/IAX partners expect special CALLERID values (number _and_ name) and if you cannot override this in the peer section you will have to plan for exceptions in your dialplan for each and every peer behaving like this.

If this is the expected behaviour I would like to change this into a feature request. I would love to see the possibility to override number and name in peer sections.

Kind regards,
 JP
By: Mark Spencer (markster) 2006-01-11 00:55:26.000-0600

The function of the "callerid" variable is to override *incoming* callerid, not outgoing callerid which can be changed by the variables you're using in your dialplan.  Further there are other parameters (e.g. fromuser) to change the settings you're asking about.
By: Jan-Peter Koopmann (jkoopmann) 2006-01-11 01:24:24.000-0600

Hi Markster,

thanks for the answer. I will head over to voip-wiki and change the documentation so it is clear that the override only works for incoming calls (even though I recall this not working for at lease one phone-* combination on 1.0.9).

One thing puzzles me (must be my bad karma): You mentioned that fromuser should do what I want. This is not the case here. Fromuser is explicitly set and still the SIP header looks like described which is rejected from T-Online SIP gateway here in Germany.

I _know_ I can fix this in the the dialplan and I did (which again breaks the idea of the LCR script I use but anyways). But:

1. If fromuser should change the behaviour it either does not or I am not using the correct syntax (again something I would like to add to voip-wiki then). I am currently just using fromuser=032229115417. Is there a way to change the callername as well? All my experiments with fromuser only changed the username in the sip: part. T-Online complains that the displayname must be equal to the username so what I need to change is

From: "Koopmann" <sip:032229115417@tel.t-online.de>  to
From: "032229115417" <sip:032229115417@tel.t-online.de>

I fail to see how I can achieve this with fromuser.


2. If fromuser is not able to change the callername in the From: SIP Header and the only current solution is to use Set(CALLERID(name)) I would like to change this to a feature request since it would make the life of a few people a bit simpler if you can override the displayname as well in the peer section.

Kind regards,
 JP
By: twisted (twisted) 2006-01-11 09:50:26.000-0600

I don't see how setting the callerid name in your dialplan should EVER break an LCR script.  

1) fromuser only changes the sip uri user field.  (ie, sip:xxxx@somewhere.com - the xxxx part.)   If your provider is requiring the display name to match, then you must set the callerid name from the dialplan.

2) This sounds like a possibility.  Feel like submitting a patch for that? ;)
By: twisted (twisted) 2006-01-11 09:51:23.000-0600

Changed from Major to Minor since it's a config issue.
By: Jan-Peter Koopmann (jkoopmann) 2006-01-11 10:11:16.000-0600

Hi twisted,

usually we set the CallerID and Name in the Dialplan the way we want things to look like. Then we call the LCR logic which automatically decides on what provider to use. Since the LCR logic is a flexible script that cannot and should not pay attention to the specific SIP requirements a VoIP provider might have we now have to do dirty things like figuring out when we are going to use T-Online, then manually change the CallerID/Name, try T-Online, if it fails reset the original CallerID/Name and then call the LCR script. That's what I meant by "breaking the LCR script".

1) already done.

2) Worth an idea indeed. Can you point me in the right direction?
- Where are the config files read?
- Can I just name the parameter the way I like or is there some kind of gremium making those decisions?
- I suppose the rest is done in chan_sip.c so I will have a look there.

Problem: My C is very bad so this might just take a while.

BTW: Instead of putting the case to MINOR it might be better to make it a feature request, don't you think?


Oh and one more thing. The karma system is quite nice and I enjoy it a lot. The only thing I do not understand is this: If several documentations only talk about "override the callerid" and therefore I jump to the conclusion that this might be a bug since overriding does not work, why does this give me bad karma again? From my point of view this is simply badly documented since what really is meant here is what markster pointed out. It is simply overriding the incoming callerid only.

Why can you set a callerid in a peer configuration, when only the incoming callerids are overridden? So I agree this is not a bug, it's a feature. But please understand that the possibility of putting a callerid in a peer config might lead people to the conclusion that this should work on outgoing connections as well.

I refuse to see why mentioning this makes me a bad person. :-) But that's life. I wounder if this really brings people's attitude up.

I hope I can find the time to look at the code and maybe produce a patch. If so I will put it in here and of course get the disclaimer right first. Thanks to all for your kind help.
By: twisted (twisted) 2006-01-11 12:38:42.000-0600

That makes sense now on the LCR side.  

As far as the code goes, chan_sip.c reads in it's configuration in the function reload_config() starting at line 12254 (as of SVN rev 7924 in branch 1.2)

You can call it whatever you want, but basically I would set it to something like fromdisplayname= to keep with the fromuser/fromdomain standard.

Regarding the Karma - Basically if you look at the reason(s) your karma has been deducted, on this bug, there were two made - one for incorrectly reporting a bug when it was actually a configuration issue, and another for reporting the bug as MAJOR contrary to bug guidelines.    It in no way means anyone is a bad person.
By: Jan-Peter Koopmann (jkoopmann) 2006-01-13 07:38:12.000-0600

Hi,

I just attached a patch for a "fromdisplayname" field in the peer section. I developed this against bristuffed 0.3.0 1f and then tried to get it into the SVN trunk syntax. The first tests show that at least the version for bristuffed works as expected.

Two things:
1. Someone obviously already started development on this. At least the variable "fromname" and its use in initreqprep suggests something like this. However the variable is not set anywhere in chan_sip.c and cannot be determined in sip.conf. If noone else uses it, you may want to get rid of it.  

2. I am not sure about the part in build_rpid. Maybe someone with more experience in chan_sip.c can have a look at this.

Just in case: I have not been programming in some time therefore please excuse any errors. BTW: I just signed and faxed the disclaimer.


@twisted, regarding Karma: As I tried to point out, this case from my point of view is a bug. Not in code - agreed - but in the documentation which leads me and others to believe, callerid is working in the outgoing direction. I mentioned that the name is coming from SET(CALLERID(name)) from the very beginning and was fully aware of how to work around this in the dialplan. Meanwhile it should be clear why this is just a temporary solution/workaround though.

I put this in the MAJOR category since something was not working as expected (reading the documentation) and the only workaround is - again from my point of view - not reasonable. Once I understood that callerid is only supposed to work in the incoming direction I was about to ask you to reset this to MINOR or FR but already received the karma.

As for bug 6152: This is clearly NOT a configuration issue as a standard European ISDN feature is simply not supported by Asterisk and cannot be supported easily. It turns out that an additional CDR field is not at all sufficient since the AOC information must be kept even if channels change. I would be very suprised to see how this is solved with configuration only.

Therefore please excuse me restating that blindly giving people negative karma if those people try to assist in the development of the system is not motivating at all. Maybe you and others are of the opinion that I love to open silly bug reports for every single thing that is not working my way. This is not the case and therefore I do not enjoy being treated as such.


Kind regards,
JP
By: Jan-Peter Koopmann (jkoopmann) 2006-01-18 06:13:11.000-0600

Hi,

have you had any chance to review my patch?

Kind regards,
 JP
By: Olle Johansson (oej) 2006-01-24 11:09:24.000-0600

I am reviewing your patch now, while it can be done in the dial plan I feel there's no harm in adding it. have to discuss it with the powers ;-)
By: Olle Johansson (oej) 2006-01-24 11:13:22.000-0600

jkoopmann: Thank you for contributing to Asterisk.

The developer team feels that adding functionality that copies functions in the dial plan makes it harder to maintain the code. You can already create this functionality by setting the outbound caller ID name before dialling.

This patch is not accepted into svn trunk. Again, thank you for contributing. If you want to discuss this, we're available on #asterisk-dev in the IRC channel.
By: Digium Subversion (svnbot) 2008-01-15 16:23:18.000-0600

Repository: asterisk
Revision: 8554

U   trunk/configs/sip.conf.sample

------------------------------------------------------------------------
r8554 | oej | 2008-01-15 16:23:18 -0600 (Tue, 15 Jan 2008) | 2 lines

Make it clear that caller ID in sip.conf is used only on incoming calls (inspired by bug ASTERISK-6026)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=8554
By: Digium Subversion (svnbot) 2008-01-15 16:25:13.000-0600

Repository: asterisk
Revision: 8679

_U  team/oej/astum/
D   team/oej/astum/ChangeLog
U   team/oej/astum/apps/app_dial.c
U   team/oej/astum/asterisk.c
U   team/oej/astum/cdr/cdr_pgsql.c
U   team/oej/astum/channel.c
U   team/oej/astum/channels/chan_agent.c
U   team/oej/astum/channels/chan_features.c
U   team/oej/astum/channels/chan_iax2.c
U   team/oej/astum/channels/chan_sip.c
U   team/oej/astum/configs/sip.conf.sample
U   team/oej/astum/contrib/scripts/safe_asterisk
U   team/oej/astum/include/asterisk/channel.h
U   team/oej/astum/rtp.c
U   team/oej/astum/utils/astman.c

------------------------------------------------------------------------
r8679 | oej | 2008-01-15 16:25:13 -0600 (Tue, 15 Jan 2008) | 230 lines

Merged revisions 8517,8523-8524,8531,8538-8539,8548,8554,8560-8561,8563,8571-8572,8574,8582,8587,8589-8597,8599,8609-8610,8618,8620,8633,8642-8643,8654,8664-8665,8667,8676,8678 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r8517 | oej | 2006-01-24 11:36:45 +0100 (Tue, 24 Jan 2006) | 2 lines

Whitespace change, extra <tab> added from my tab storage.

................
r8523 | oej | 2006-01-24 12:42:09 +0100 (Tue, 24 Jan 2006) | 2 lines

Declaring conn and result static to avoid collission with realtime driver (issue 6336, pressureman)

................
r8524 | oej | 2006-01-24 12:46:29 +0100 (Tue, 24 Jan 2006) | 3 lines

- Adding whitespace that I found unused outside
- Adding "if (option_debug)" before outputting to DEBUG channel

................
r8531 | oej | 2006-01-24 13:48:44 +0100 (Tue, 24 Jan 2006) | 2 lines

- Report SIP reload in manager (issue 5742 with small changes)

................
r8538 | oej | 2006-01-24 14:21:13 +0100 (Tue, 24 Jan 2006) | 2 lines

Importing rev ASTERISK-8302 from 1.2, never send response to ACK (issue ASTERISK-6148)

................
r8539 | oej | 2006-01-24 14:53:45 +0100 (Tue, 24 Jan 2006) | 2 lines

Issue ASTERISK-6163, FreeBSD compatibility with compilation of func_odbc.c (reported by nulbyte)

................
r8548 | oej | 2006-01-24 18:47:41 +0100 (Tue, 24 Jan 2006) | 2 lines

Reverting change in revision 8539 - fixed wrong problem. Sorry.

................
r8554 | oej | 2006-01-24 19:15:20 +0100 (Tue, 24 Jan 2006) | 2 lines

Make it clear that caller ID in sip.conf is used only on incoming calls (inspired by bug ASTERISK-6026)

................
r8560 | oej | 2006-01-24 20:08:44 +0100 (Tue, 24 Jan 2006) | 2 lines

Issue ASTERISK-5935: Match realtime non-dynamic peers by IP. (siacali).

................
r8561 | oej | 2006-01-24 20:19:20 +0100 (Tue, 24 Jan 2006) | 2 lines

Issue 6114: Don't hangup on bye/also if there's no channel. (gst)

................
r8563 | oej | 2006-01-24 20:29:32 +0100 (Tue, 24 Jan 2006) | 2 lines

Blocking fix from 1.2 from being applied again.

................
r8571 | russell | 2006-01-24 21:20:05 +0100 (Tue, 24 Jan 2006) | 2 lines

convert ast_channel list to use linked list macros (issue ASTERISK-6178)

................
r8572 | russell | 2006-01-24 21:27:09 +0100 (Tue, 24 Jan 2006) | 2 lines

store the list of 'atexit' functions using linked list macros (issue ASTERISK-6169)

................
r8574 | oej | 2006-01-24 21:41:08 +0100 (Tue, 24 Jan 2006) | 2 lines

Don't reset scheduled ID until we actually end the scheduled event.

................
r8582 | mattf | 2006-01-24 22:45:42 +0100 (Tue, 24 Jan 2006) | 2 lines

Updates from royk to safe_asterisk (ASTERISK-5069) Thanks!

................
r8587 | mattf | 2006-01-24 23:06:37 +0100 (Tue, 24 Jan 2006) | 2 lines

Make sure safe_asterisk retains previous script defaults

................
r8589 | kpfleming | 2006-01-24 23:33:58 +0100 (Tue, 24 Jan 2006) | 1 line


................
r8590 | kpfleming | 2006-01-24 23:34:06 +0100 (Tue, 24 Jan 2006) | 1 line


................
r8591 | kpfleming | 2006-01-24 23:38:17 +0100 (Tue, 24 Jan 2006) | 10 lines

Merged revisions 8588 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r8588 | kpfleming | 2006-01-24 16:32:09 -0600 (Tue, 24 Jan 2006) | 2 lines

ensure that channel cannot become zombie after we check but before we try to start indications

........

................
r8592 | kpfleming | 2006-01-24 23:40:20 +0100 (Tue, 24 Jan 2006) | 1 line


................
r8593 | kpfleming | 2006-01-24 23:40:57 +0100 (Tue, 24 Jan 2006) | 1 line


................
r8594 | kpfleming | 2006-01-24 23:41:45 +0100 (Tue, 24 Jan 2006) | 1 line


................
r8595 | kpfleming | 2006-01-24 23:42:43 +0100 (Tue, 24 Jan 2006) | 10 lines

Merged revisions 8173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r8173 | russell | 2006-01-17 20:49:21 -0600 (Tue, 17 Jan 2006) | 2 lines

remove ChangeLog from the 1.2 branch.  It will only be present in the tags.

........

................
r8596 | kpfleming | 2006-01-24 23:43:30 +0100 (Tue, 24 Jan 2006) | 1 line


................
r8597 | kpfleming | 2006-01-24 23:43:57 +0100 (Tue, 24 Jan 2006) | 2 lines

clean up remaining already-merged revisions

................
r8599 | kpfleming | 2006-01-24 23:45:41 +0100 (Tue, 24 Jan 2006) | 2 lines

remove extraneous characters from property

................
r8609 | kpfleming | 2006-01-25 02:52:58 +0100 (Wed, 25 Jan 2006) | 10 lines

Merged revisions 8608 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r8608 | kpfleming | 2006-01-24 19:50:52 -0600 (Tue, 24 Jan 2006) | 2 lines

ensure hangup cause code is handled properly when channel does not return a frame (issue ASTERISK-6186)

........

................
r8610 | kpfleming | 2006-01-25 02:53:15 +0100 (Wed, 25 Jan 2006) | 1 line


................
r8618 | russell | 2006-01-25 06:37:29 +0100 (Wed, 25 Jan 2006) | 3 lines

don't leak almost 200 bytes for each new channel and store the active
channel list using the linked list macros (issue ASTERISK-6170)

................
r8620 | russell | 2006-01-25 06:39:25 +0100 (Wed, 25 Jan 2006) | 1 line


................
r8633 | oej | 2006-01-25 10:50:28 +0100 (Wed, 25 Jan 2006) | 2 lines

Issue ASTERISK-6189 - patch by markster, imported from 1.2

................
r8642 | oej | 2006-01-25 13:01:07 +0100 (Wed, 25 Jan 2006) | 3 lines

From now on, apply maxexpiry and minexpiry to all subscriptions. Thanks to fourcheeze in the IRC channel
for pointing this out.

................
r8643 | oej | 2006-01-25 13:11:30 +0100 (Wed, 25 Jan 2006) | 3 lines

- Remove unused option to transmit_state_notify
- Allow for expiry=0 in subscription requests that only wants *one* update and that's it.

................
r8654 | kpfleming | 2006-01-25 15:52:43 +0100 (Wed, 25 Jan 2006) | 3 lines

don't queue a congestion frame on a channel that will be immediately hung up anyway
clean up/organize code block

................
r8664 | russell | 2006-01-25 19:12:55 +0100 (Wed, 25 Jan 2006) | 2 lines

store agent_pvt list using linked list macros (issue ASTERISK-6182)

................
r8665 | russell | 2006-01-25 19:24:32 +0100 (Wed, 25 Jan 2006) | 3 lines

store feature_pvt list using linked list macros
(issue ASTERISK-6190, with additional changes to prevent a memory leak in unload_module)

................
r8667 | russell | 2006-01-25 19:41:12 +0100 (Wed, 25 Jan 2006) | 1 line


................
r8676 | russell | 2006-01-25 20:06:37 +0100 (Wed, 25 Jan 2006) | 2 lines

use arg parsing macros in the AGENT dialplan function (issue ASTERISK-6078, with small mods)

................
r8678 | russell | 2006-01-25 20:16:14 +0100 (Wed, 25 Jan 2006) | 11 lines

Merged revisions 8677 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r8677 | russell | 2006-01-25 14:14:43 -0500 (Wed, 25 Jan 2006) | 3 lines

don't call ast_update_realtime with uninitialized variables if we get a
registration with an expirey of 0 seconds (issue ASTERISK-6016)

........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=8679