Greger,
When I dial
out via the PSTN the call goes
out showing the SER username
However, I
want the call to go out showing
the user’s alias
Lets say my
gateway is 10.0.0.1
My SER
installation is 10.0.0.2
username
8000 and alias is 2075634
The user
dials 442074567
When a call
goes out, there is an invite
from 8000@10.0.0.2 to 442074567@10.0.0.1 and so the
gateway dials 442074567 on the PSTN
However I
want the invite message to show
it is from 2075634@10.0.0.2
when a
call goes out.
Andy
Andy,
I'm still not sure what you mean when referring to the "username" and
I'm not sure what you are trying to accomplish. If you are referring to
the
Request-URI, you need to lookup based on your current Request-URI
(whatever
that is at the point in your ser.cfg you want to change RURI). However,
if you
are looking at getting a correct caller-id, you should rather use
Remote-Party-Id.
The RURI should be the callee, so setting the ruri to the
caller doesn't make sense to me. Maybe you can tell what you are trying
to
accomplish?
g-)
Andy Thomas wrote:
Greger,
Im already
doing this for calls coming
into my SER installation.
However I
want to do it the other way
around, i.e. from SER/UA to PSTN
Therefore I
want to rewrite the username
if the outgoing INVITE message to be the alias, not the location, when
sending
to the PSTN.
Andy
I see a lot of confusion on
the different user related
ids in SIP. Let me try to explain (and answer your question, Andy, at
the end
of the post...)
Let's start at the user agent(UA) side:
--------------------
AOR: Address of record is the sip:myuser@domain.com
address that you are known as, just like your email address. Many user
agents don't ask for AOR, but builds it from other parameters you need
to set
Username: The username is normally the user (before @) of AOR)
Realm: Often the domain portion of the AOR, thus AOR =
sip:username@realm
Friendly name/displayname: "My name"
Out of this info, the From header is constructed:
From: "My name" <sip:username@realm>
---
Entirely separate (but sometimes confused in user agents):
Authentication username: The user used for authentication
Authentication realm: The realm to authenticate within
Very often the authentication realm is implicitly assumed to be the
same as the
AOR realm
---
Then, the user agent will create the Contact header. The Contact header
should
be the public contact address of your current location. Thus: Contact:
sip:username@mypublicip:5060
If the user agent is behind a NAT, the mypublicip will be a private
address.
---
A sidenote: Unless registration server is explicitly specified, the
realm in
the AOR will be used for looking up the SIP registration server using
DNS SRV
or A lookups. You should avoid putting the FQDN of your SIP server in
the
realm.
Also, you may in some user agents specify outbound proxy. This is the
proxy
where the user agent will send INVITEs (and other outbound messages).
-------------------
And on the SER side:
-------------------
Authentication user/realm are used to do Digest authentication, but are
then
forgotten (i.e. not stored).
The AOR is registered in the location table, together with the Contact
header,
as well as the source ip and port (if different from Contact). The
fix_nated_register() function handles this setting of the so-called
received
parameter.
So, to the routing:
- Messages that need to be routed (i.e. do not have Route headers) will
have a
Request URI; the first line and the part after the message type: INVITE
sip:username@domain.com
- It is by changing this request URI, you do routing. The t_relay()
command uses the URI to forward the message correctly
- Before forwarding to a user agent, you want the request uri to be the
same as
the stored Contact header for the AOR you are looking up. If not, the
user
agent may reply with a 404 User not found
- The From header is NOT used for routing, and for backwards RFC
compatibility,
you should not change the From header as some UAs will use the content
of the
>From header to match a dialog (however, if your UAs from experience
still
work, there should not be a problem doing it, it's just not
RFC-compliant and
may pop up and kick your butt later ;-)
- The AOR in location table is used for looking up incoming messages if
you can
find a direct match between the Request-URI in the incoming message and
the
stored AOR. If not, you can use the aliases table (and
lookup("aliases")) to match the Request-URI with something in the
aliases table, that again will map to the AOR in the location table
---
So keeping this (fairly simple) concept in focus: Routing (regardless
of LCR,
avps or whatever) should focus on finding the correct Request-URI
before you
call t_relay().
BUT, there are ways of "messing" up this...
---
- There are several commands in SER you can use to override the
Request-URI
(forward_*). They should be avoided, unless you have a valid reason for
having
a Request-URI in the message you are forwarding that is NOT resolvable
(either
IP address or DNS name or DNS SRV/A resolvable) to the party you are
forwarding
to. The reason can be if you want the R-URI to contain the AOR and then
forward
the message to a server handling voicemail
- The dst_uri parameter (implicitly set by lookup) will tell t_relay()
to send
the message to dst_uri instead of the Request-URI. lookup() will set
this when
it finds that the Contact stored for the AOR also has an associated
received
ip:port (because the user agent was NATed)
In general trying all sorts of tricks o fix-up things the way you need
it may
not be so smart. Stick to the basics and question yourself: Is this
something I
really want to do?
----------------------
To Andy, you want the aliases table to map to the AOR (as registered by
the UA
in the REGISTER command). You do lookup("aliases") to resolve your
DID into an AOR. Then, later you can do lookup("location") to map the
AOR to the location of the UA (i.e. Contact/dst_uri). Then your
Request-URI
will be correct.
g-)
Andy Thomas wrote:
Does anyone know how I
would do this-
For all users who have
PSTN access, they are assigned
a number in the MySQL alias table which matches a PSTN DDI number.
e.g. user 8000 has an
alias of 2071231234, so on an
incoming call the lookup(“aliases”) function correctly matches the
DDI to the user.
I want my ser.cfg to
rewrite the user on an outgoing
call, if a number exists in the alias table for that user
Obviously, the
rewriteuser function will be used, but
what do I put in after that?
I have tried rewriteuser
(lookup
(”aliases”)) but that doesn’t work
Can anyone help?
_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers