El Domingo, 29 de Junio de 2008, Stagg Shelton escribió:

I guess where I am most confused is the interaction that AVP has on the current message. Does AVP have the ability to rewrite the current message URI before I use t_relay to send it to its destination? Is it as simple as the following:

avp(s:$rU) = $oU;

The above is incorrent, you cannot do "avp(s:$rU), it makes no sense. An AVP must have an intenger or string identifier:

avp(s:name1) avp(s:name1) avp(i:1) avp(i:2)

But you cannot do:

avp(s:$rU) <-- Why it???

Anyway what I mean is that if you have modified RURI (maybe using alias_db_lookup, lookup('location')...) you still can get the **original**RURI via $ou, $oU... variables.

Example:

------- RURI = sip:boby@domain.com

alias_db_lookup(); # Now RURI => 201@domain.com

$ou => sip:boby@domain.com

lookup('location'); # Now RURI => 201@99.88.100.123:5060

$ou => sip:boby@domain.com -------

El Domingo, 29 de Junio de 2008, Stagg Shelton escribió:

Thank you Iñaki. Not only did I find that my syntax made no sense, I also found that openser would not start because of it.

I believe that I have found my solution with your help. The below syntax appears to be working with the results I intended.

     alias_db_lookup("dbaliases");

     if (!lookup("location")) {

                      ...

             }
     }
     else
     {
       avp_pushto("$ru/username", "$oU");
     }

What the above does for me is that OpenSER can receive an invite from one of my SIP providers. I can determine if the call is intended for one of the PBX's that are registered to OpenSER and appropriately route the call to the PBX that serves the number.

Hi, first this complex syntax is not needed anymore: avp_pushto("$ru/username", "$oU"); because you can just do: $rU = $oU;

But anyway I can't understand why you do it. In your case, please re-read the doc of "lookup" function. When you do: if (!lookup("location")) { that will change the RURI ****just**** in the case the original RURI is an AoR existing in the "location" table, this is: that user is registered in OpenSer. But in the case it's not registered then the RURI ***won't*** be changed so you don't need, at all, to restore the RURI.

Well, imagine an example with your code:

- There is an alias: boby@domain.com => 201@domain.com

- 201@domain.com is not registered in OpenSer.

- Your code:

=> RURI = boby@domain.com

alias_db_lookup("dbaliases"); => RURI = 201@domain.com

if (!lookup("location")) { => User not registered so RURI still is 201@domain.com and this block is not executed .... } else { avp_pushto("$ru/username", "$oU"); => Now RURI = boby@domain.com }

The question is: why do you need RURI being the original? it makes no sense (IMHO).

Regards.

Hi Stagg,

This is a common issue when you have an Asterisk with multiple extensions and a single registration to OpenSER. A trick you can do is to save the username part of the RURI (the extension) and restore if the location lookup (for registrations) was successful:

...... $avp(s:tmp) = $rU; if ( !lookup("location")) { # no location found sl_send_reply("404","Not Found"); exit; } # registration found -> restore the username part $rU = $avp(s:tmp)

t_relay();

......

Note that is is better to use an AVP (or a variable) to store the username before the lookup, instead of using the $oU (original username). Original username is the username that openser received from the net, but you may consider that your script does other RURI processing (like aliases) before the lookup("location") - so you need the username value from before the lookup and not the received one.

Regards, Bogdan

Stagg Shelton wrote:

I will re-read the lookup function documentation.

The reason why I am having to do this is because in my particular case I have many asterisk PBX's registering to OpenSER. When asterisk registers to OpenSER it has a contact id in the REGISTER message of s@w.x.y.z . After using alias_db_lookup OpenSER is using the contact id in the To: field. When the message gets to asterisk, I cannot route it to the correct extension, IVR, Queue because the message is being sent to s@w.x.y.z instead of 5551212@w.x.y.z

Thanks Stagg

On Jun 29, 2008, at 6:08 PM, Iñaki Baz Castillo wrote:

...

El Domingo, 29 de Junio de 2008, Stagg Shelton escribió:

...

Thank you Iñaki. Not only did I find that my syntax made no sense, I also found that openser would not start because of it.

I believe that I have found my solution with your help. The below syntax appears to be working with the results I intended.

    alias_db_lookup("dbaliases");

    if (!lookup("location")) {

                     ...

            }
    }
    else
    {
      avp_pushto("$ru/username", "$oU");
    }

What the above does for me is that OpenSER can receive an invite from one of my SIP providers. I can determine if the call is intended for one of the PBX's that are registered to OpenSER and appropriately route the call to the PBX that serves the number.

Hi, first this complex syntax is not needed anymore: avp_pushto("$ru/username", "$oU"); because you can just do: $rU = $oU;

But anyway I can't understand why you do it. In your case, please re- read the doc of "lookup" function. When you do: if (!lookup("location")) { that will change the RURI ****just**** in the case the original RURI is an AoR existing in the "location" table, this is: that user is registered in OpenSer. But in the case it's not registered then the RURI ***won't*** be changed so you don't need, at all, to restore the RURI.

Well, imagine an example with your code:

• There is an alias: boby@domain.com => 201@domain.com

• 201@domain.com is not registered in OpenSer.

• Your code:

  => RURI = boby@domain.com

  alias_db_lookup("dbaliases"); => RURI = 201@domain.com

  if (!lookup("location")) { => User not registered so RURI still is 201@domain.com and this

block is not executed .... } else { avp_pushto("$ru/username", "$oU"); => Now RURI = boby@domain.com }

The question is: why do you need RURI being the original? it makes no sense (IMHO).

Regards.

-- Iñaki Baz Castillo

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi Iñaki,

Most of the UAC will reject an incoming call if the RURI is not the contact they registered - and I by contact I mean URI + URI params (like SNOM encodes as contact param the line of the account)

But particularly talking about devices with PBX-like behaviour (with multiple extensions behind some registration), it really does not matter - there is impossible to force any relation between the contact (which is one) and accepted RURIs (which can be for multiple extensions).

Regards, Bogdan

Iñaki Baz Castillo wrote:

El Monday 30 June 2008 10:17:57 Bogdan-Andrei Iancu escribió:

...

Hi Stagg,

This is a common issue when you have an Asterisk with multiple extensions and a single registration to OpenSER. A trick you can do is to save the username part of the RURI (the extension) and restore if the location lookup (for registrations) was successful:

......
$avp(s:tmp) = $rU;
if ( !lookup("location")) {
   # no location found
   sl_send_reply("404","Not Found");
   exit;
}
# registration found -> restore the username part
$rU = $avp(s:tmp)

t_relay();

......

Hi Bogdan, will any SIP UA allow a call if the RURI username doesn't match the username in the "Contact" during UA registration? Well, sure a PBX would allow it (like Asterisk), but what about single phones? By my experience, most of the phone just allow receiving INVITE's for the same RURI username as the "Contact" send by the UA in the REGISTER.

El Monday 30 June 2008 03:16:30 Stagg Shelton escribió:

Also, the other reason why I want to do this is because I have many hundreds of DIDs that are assigned to many asterisk PBX's. I am thinking that having asterisk register to OpenSER and then have the DIDs as aliases to the registration credentials would be easy because it's all contained in the database.

Asterisk allows just one registration to a server. If you have two incoming DID's then it's better if your Asterisk matches the "To" header.

In fact, I don't like using the "To" header for this purpose since it can be different if it comes from a SIP already diverted call (so "To" is no one of your DID's but the original destination has forwarded the call to some of your DID's).

What I do is the following:

- When my OpenSer receives an incoming call from PSTN I convert the RURI to E164 format: RURI: 0034999000111 -> E164 = +34999000111 999000111 -> E164 = +34999000111

- Then I add a header to the INVITE: append_hf("X-E164-Called: $rU");

- Then I do the db_aliases to get the AoR of the local user associated to that E164 number. RURI: +34999000111 -> sip:user01@mydomain.com

- And later a lookup in 'locaiton' table to get the real location of the registered user. RURI: sip:user01@mydomain.com -> sip:s@IP_ASTERISK

- After that I just do the "t_relay" to send the INVITE.

- When it arrives to Asterisk it must check the header "X-E164-Called" to know which DID was called.

Regards.