[Serusers] rewriting the outgoing URI to its alias

Greger V. Teigre greger at teigre.com
Wed Jun 14 12:42:03 CEST 2006


Ok, now I see. First of all:
The username is, as I stated in my overview, a confusing term. The 
authentication username does not have to have anything to do with the 
username part of the AOR. Thus, you may well configure the UA with 
2075634 and still authenticate with 8000

If that is not feasible, for some reason, you should use 
Remote-Party-Id. In the SIP to PSTN space, this is the field normally 
used for setting the A-number for billing and caller-id. The AOR in From 
is used only when the Remote-Party-Id is lacking. Let's say you want an 
anonymous call going to the PSTN, you must use privacy=full in 
Remote-Party-Id. The From should ex. be "anonymous" 
<anonymous at mydomain.invalid> (set by the user agent when anonymous is 
turned on).

If you change the From, you a) break the RFC-compliance b) override 
anonymous if set

If you still insist on changing From, you will find multiple examples of 
>From manipulations using the regex capabilities of the subst() function 
found in textops.
g-)



Andy Thomas wrote:
>
> 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 at 10.0.0.2 
> <mailto:8000 at 10.0.0.2> to 442074567 at 10.0.0.1 
> <mailto:442074567 at 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 at 10.0.0.2 
> <mailto:2075634 at 10.0.0.2>  when a call goes out.
>
>  
>
> Andy
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Greger V. Teigre [mailto:greger at teigre.com]
> *Sent:* 13 June 2006 06:57
> *To:* Andy Thomas
> *Cc:* serusers at lists.iptel.org
> *Subject:* Re: [Serusers] rewriting the outgoing URI to its alias
>
>  
>
> 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
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Greger V. Teigre [mailto:greger at teigre.com]
> *Sent:* 12 June 2006 09:33
> *To:* Andy Thomas
> *Cc:* serusers at lists.iptel.org <mailto:serusers at lists.iptel.org>
> *Subject:* Re: [Serusers] rewriting the outgoing URI to its alias
>
>  
>
> 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 at domain.com 
> <mailto:sip:myuser at 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 at realm
> Friendly name/displayname: "My name"
>
> Out of this info, the From header is constructed:
> From: "My name" <sip:username at 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 at 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 at domain.com <mailto:sip:username at 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 at lists.iptel.org <mailto:Serusers at lists.iptel.org>
> http://lists.iptel.org/mailman/listinfo/serusers
>   
>  
>
>
> ------------------------------------------------------------------------
>
>
>  
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
> http://lists.iptel.org/mailman/listinfo/serusers
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060614/d1444117/attachment.htm>


More information about the sr-users mailing list