Incorrect from ext uri when invite


#1

Hi,

I’m using asterisk version Asterisk 1.6.2.18

when i place invite to callee phone show incorrect uri.

below is the send and receive invite packet.

May i know how can i fix this from ext header…?

From: “102” sip:[b][u]101[/u][/b]@xxxxx;tag=as78194461

caller = 101
callee = 102

caller —
Pyi-}E/@wDINVITE sip:101@xxxxx SIP/2.0
Record-Route: sip:xxxxx;nat=yes;ftag=1784142251;lr=on
Via: SIP/2.0/UDP xxxxx;branch=z9hG4bKf803.f9e76a36.0
Via: SIP/2.0/UDP 192.168.2.43:5062;rport=4453;received=xxxxx;branch=z9hG4bK1670592688
From: “102” sip:102@xxxxx;tag=1784142251
To: sip:101@xxxxx
Call-ID: 836867432@192.168.2.43
CSeq: 2 INVITE
Contact: sip:102@xxxxx:4453
Content-Type: application/sdp

callee —
i-}PyER)@{>7INVITE sip:101@xxxxx SIP/2.0
Via: SIP/2.0/UDP xxxxx;branch=z9hG4bK4620586a;rport
Max-Forwards: 70
From: “102” sip:101@xxxxx;tag=as78194461
To: sip:101@xxxxx
Contact: sip:101@xxxxx
Call-ID: 5d02c0a043cff08a4c7be0687290bbdf@xxxxx
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.2.18

Thanks & Regards,


#2

You need to find where you have manipulated the caller ID or fromuser.


#3

Hi,

Thanks but sipusers, sippeers, sipregs and voicemail is from mysql database.
callerid, fromuser and username is correct set in the table.
below is the table from sipusers for 101 & 102,

name, username, host, sippasswd, fromuser, fromdomain, mailbox, callerid
101, 101, dynamic, 101, 101, xxxxx.com, 101, 101
name, username, host, sippasswd, fromuser, fromdomain, mailbox, callerid
102, 102, dynamic, 102, 102, xxxxx.com, 102, 102

where else do i need to check? or is it a bug in this version?

Thanks


#4

As you have set fromuser, to 101, it is behaving as intended.

If you need to set fromuser, you may still be able to send caller ID by enabling sendrpid, but that is subject to the downstream system accepting Remote-Part-ID headers.


#5

Hi,

i enable sendrpid but the downstream doesnt accept.
may i know can how can i fix this?

Thanks,


#6

You will have to ask whoever operates the downstream. Note that responsible SIP service providers will be very selective in what caller ID they accept because it would otherwise be very easy spoof caller ID for fraudulent purposes. I would expect them ony to accept caller IDs for numbers that you can prove you own.

Where the downstream requires the from user to be set so as to identify the client, there are four tactics I’m aware of:

  1. Do not allow caller ID to be supplied;
  2. Use RPID;
  3. Use asserted identites;
  4. Use the user friendly part of the from header.

You say (2) doesn’t work for you. You are already using (4) by accident, and it doesn’t work.

Asterisk doesn’t support (3), although it may be possible using AddHeader.

Alternatively, you are forcing the value of fromuser in error, in which case you want to null it in the database.


#7

actually there is no other provider.
it just a simple setup like below.

UA101 <—> ASTERISK <—> UA102

when 101 make a call to 102. 102 client receive the call it appear on screen from callerid=101 and fromuser=102@xxxxxx
i also tried set fromuser to null and set dialplan callerid(num)=101 but getting same result.

i also tested on asterisknow
using the same setup on the callee side the screen appear callerid=101 and fromuser=101@xxxxxx which is correct.

is there a way to correct it?


#8

fromuser serves no useful purpose when connecting to simple phones.


#9

already null it in database still the same.
when i set
1)callerid=paul, fromuser=101/null, username=101
2)callerid=frank, fromuser=102/null, username=102

example on invite
101 invite 102, 102 on screen display Paul and 101@xxxxxx
when call ended 102 go to his call log saw Paul. and it try to call Paul he unable to identify Paul extension number.

any solution?


#10

101/null looks wrong.

I don’t use realtime. You need to achieve the equivalent of having a non-realtime configuration with no fromuser= lines.

I would have assumed that resulted from doing either:

update xxxxx set fromuser = NULL where …

or

update xxxxx set fromuser = ‘’ where …

It almost looks as though you have done:

update xxxxx set fromuser = ‘101/null’ where …

which wouldn’t make sense.


#11

Incidentally, this looks like a new install. You should not be using 1.6.x or 1.4.x for new installs, as they are no longer supported.


#12

yup is a new install.
oh so the only solution for this is to install 1.8 version? no other solution for this?


#13

No. The solution to the problem is not to set fromuser. That will not change for 1.8, as far as I know.

Are you using some GUI that you haven’t mentioned, which is limiting your ability to control the setting of fromuser? I can’t imagine one of the common GUIs doing that, as the way that setting it breaks CLID would be too obvious. fromuser is generally only needed when the peer is a PABX and expecting a simple phone.

The reason that you should be using 1.8 is that you will not get any bugs in 1.6.2.x fixed, and as it is a new install, you should not have any legacy constraints that prevent your updating.


#14

i already tried not to set fromuser…
im not using any gui… but using asterisk realtime sip

this is my config

sipusers => odbc,asterisk,sipusers
sippeers => odbc,asterisk,sipusers
sipregs => odbc,asterisk,sipregs
voicemail => odbc,asterisk,voiceboxes

and my dialplan

exten => _1XX,1,Dial(SIP/${EXTEN})
exten => _1XX,n,Hangup


#15

Could I suggest that you get a non-realtime configuration working first.


#16

okie thanks for suggestion.
will try on non-realtime first…