External Caller id

In your trunk definition under options add this:

sendrpid=yes

Thanks for quick reply :)

I followed your instructions and this killed my abbility to dial out from trunk completely. After deleting sendrpid=yes calls went out again.

with same issues as before off course... :(

If you are located in Canada we can give you very cheap incoming DID channels with callerID.

We use Thirdland MTE and have no problems with there standard configuration

I am located in Amsterdam... And I have Incoming caller ID, just have issues with outbound caller id...

P asserted identity is different than rpid

under your trunk section there is columns for Sip header 1 / 2 etc

Add

P-Asserted-Identity: "${CALLERID(name)" <sip:${CALLERID(num)}@your.ip.com>

ignoring the line wrap of course.

Hi Erik,

Your comments on the forum have allready been extremely usefull to me, thanks for that!

I tried your solution, but also killed my abbility to dial out from trunk completely. After deleting calls went out again.

I am doing something wrong... :) What did you mean by "ignoring the line wrap"... This part is probably lost in translation...

give me the exact format of the p-asserted-id tag that they want you to send dont use < > because the forums will wipe out your whole post... substitute &lt; for < and &gt; for >

do you know how to use wireshark? It would be great if you could capture your sip packets to see what you are sending.

yum install wireshark (if its not installed on the MTE box)

then

tshark -ni eth0 -f 'host 64.152.60.78' -w test.pcap

substitute the ip address of the IP of your provider of termination services

and substitute the applicable network interface for eth0

while that is running make a test call with the P asserted tag we created. If the format is OK then we need to investigate if the # in the tag is wrong and/or a number other than one provided by the provider. its possible they are blocking the call because its not their number.

P-Asserted-Identity: &lt sip:xx@yy &gt (where xx is the cli and yy is my IP)

Concerning WireShark I am familiar with it but have it not installed on MTE... I am also not a developer/programmer. I posted the question on the forum to see if there was a quick fix...

It is now Friday afternoon here in Holland, my development team is packing in for the weekend :)

So doing a trace would have to wait till monday.

But hope you can help me based on exact format my carier needs...

make Header Line 1 say this:

P-Asserted-Identity: < sip:${CALLERID(num)}@yy > where yy is your ip

if calls fail, you will need to capture a trace and verify the # is correct. If the # is correct and owned by the provider you'll need to contact them tell them to stop being a scheissekopf, because you sent them the call exactly the way they claimed and they are now rejecting the calls outright.

it would be a lot easier if they honored Remote-Party-ID headers because those give additional features like screened for private mode.

Hi Erik,

Tried it. Doesn't work... So Monday I'll capture the trace. Thanks for your help.

Made some traces and it seems that variables are off. If put in

P-Asserted-Identity: < sip:${CALLERID(num)}@yy >

Traces show that the P-asserted identity is left blank, It kills my breakout.

When I hardcode DID in same string so:

P-Asserted-Identity: < sip:01604924674@yy >

Everything works as a charm. And my carier delivers the right Caller ID.

What can be wrong as it is not on Carier side.

so with variables, the value is completely blank.... do you not have default callerID set for the tenant?

Hi Erik,

Thanks once again for your valuable input!!! It seems that MTE needs better manuals. I had the tenant settings set so they couldn't manage CallerId and then the default Caller ID field was empty.

Now it works.... :)

Thanks

SIP Header

we are attempting to use this feature, the list is added the problem we are having it it doesn't appear to be doing anything.

looking at a sip header dip we there is no P-Asserted-Identity information at all..

is there something that needs to be done to activate this..?

George

SIP Header

We are attempting to use this feature, the line is added, the problem we are having is it doesn't appear to be doing anything.

Looking at the sip header dup there is no P-Asserted-Identity information at all..

Is there something that needs to be done to activate this..?

George

whatever you stick in there will appear inside a SipAddHeader() but you must make sure the header is formatted exactly the way the RFC states.

We hard set the settings

P-Asserted-Identity: "NAME" &ltsip:+1PHONENUMBER@IP&gt

and nothing like its not being written to the header, what am I missing..?

Thanks

George

You might check this: In my version(s) (which are admittedly behind pretty far), my tenants act a little flaky. If I do not populate a default External Caller ID Name and Number in Tenant Management, nothing I set in the User Extension Caller ID area will ever fire during a call, at least when I look at them at the VoIP / ISDN PRI gateway. Once those items in Tenant Management are set, I can then change things in User Extensions and things will work. Not sure where this stands as a bug in the recent versions.

yeah that's not a bug, the information is required whether its on the tenant level or on the extension level.

the problem we have is with our new carrier we can pass any number for an out bound caller ID, example a customer can but in 123-456-7890 and the call will complete with a caller ID of 123-456-7890.

Now god for bid the customer has a problem and calls 911, they will see the same caller ID which doesn't go any were. Now if the customer can talk and tell them were he is everything is okay, we get hit with a major charge for the call but the EMPs can respond. NOW lets say the customer can't talk and let them were they are, we're screwed.

It would seem that by using the SIP Header and adding the P-Asserted-Identity header for 911 would fix the problem. Only it seems MTE has a problem and the information even though entered into the SIP Header field its not being adde4d to the sip header.

we even hard set the setting and still nothing, now this seems to be a bug..

George

did you capture the the sip packets to make sure they header left your box?

well figured out a few problems. this is going to be a different use (lighter weight) server so rather then using 64bit like on everything else we elected to use the ISO 32 bit. we installed this server from the MTE ISO installing 1.6, it seems all kinds of stuff was broken.

I just installed 1.4 from the ISO, we applied a patch for the DTMF codes so it now works with a SONUS switch.

the P-Asserted-Identity headers are also now being added. Still have the same questions though.

how to make a caller ID different from a 911 ID for customers with multiple locations..?

Thank

George

1 tenant, multiple locations, and you want to have different 911 callerID per location? that ones tricky, you'd likely have to utilize the Custom Tag field in the extension and create a custom outbound script that sets callerid based on the entry in Custom Tag.

yes, that's exactly what we are wanting to do.. we have about 20 customers with several locations so this is a problem for us trying to cover our butts.

I was looking at that and wondering if that might be a way but there is no documentation on that feature.. in all the doc's are months out of date...

from what I can tell at this point what ever is set for the p-asserted-identity is the caller ID and 911 and we really need then to be different but correct.. waiting for upstream provider to get information back on what header info is sent to where..

George

From what my upstream carrier is telling me we need to send a different number in the PAssert for 911 calls than regular termination calls..

any clue how to make this happen..? is this something Alex is going to have to add on an extension level to use a set route for 911 calling..?

George

a different p-asserted? or a legitimate one?

you just need a custom outbound route with an extra SipAddHeader() just for your 911 calls. The custom tag field of each extension is an ASTDB entry so you could do something like

SipAddHeader( P-Asserted-Identity: <sip:yournumber@your.ip>)

trying that again..

SipAddHeader( P-Asserted-Identity: <sip:${DB(path/to/key)}@your.ip>)

our ASTDB is in the default location, if I'm going to use the Customer Tag what key is are we looking for..?

Thanks

George

just put some bs data in there and do a asterisk -rx 'database show' | grep bsdata

that will let you know what kind of pattern you are looking for.

>> just put some bs data in there and do a asterisk -rx 'database show' | grep bsdata

with out knowing whats in there or whats written how do you write bs data ..? I don't have the code to know this information..

please enlighten..

Thanks

George

go into user extension.. there is a field called custom tag.. put in shitthissucks

then asterisk -rx "database show" | grep shitthissucks

that will let you know how and what key was named for the specific extension.

George, I think i know why your P-asserted is missing when you program it in the trunk manually... I found this in macro-tl-dialout-base

exten => dial-SIP,n,SipAddHeader,${EVAL(${HEADER})} ;;=Asterisk-1.4

;;exten => dial-SIP,n,SipAddHeader(${EVAL(${HEADER})}) ;;=Asterisk-1.6

however the listed 1.4 method does not work, comment out the 1.4 method and uncomment the 1.6 method and give that a whirl.

Thanks for the help Eric,

her is what we came up with that is working GREAT for a truck for 911 while at the same time letting the customer adjust the caller ID for regular called

P-Asserted-Identity: < sip:${DB(TL/${tenant}${TL_DASH}${MYEXTENSION}/tag)}@ip.address>

minus the space after the first <

Thanks

George

yeah it seems there are several problems in using the ISO to install using Asterisk 1.6,

I wound up re-installing the system using the ISO installing Asterisk 1.4 and everything seems to be working pretty well over all

George