[OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?
Hi, maybe this question is a bit off-topic so I'm sorry for that.
My question is about SIP providers using OpenSer that associate PSTN numbers to their local clients (SIP accounts):
Usually the client must register to OpenSer in order to receive calls. Then it will appear in location table with "Contact=sip:clientX@IP". Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222
When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like:
INVITE sip:+34999000222@gateway SIP/2.0 To: sip:+34999000222@gateway
The OpenSer will do the lookup in location table and finally send this INVITE to the clientX:
INVITE sip:clientX@IP_clientX SIP/2.0 To: sip:+34999000222@gateway
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
Thanks for any comment. Regards.
Iñaki Baz Castillo writes:
When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like:
INVITE sip:+34999000222@gateway SIP/2.0 To: sip:+34999000222@gateway
why gateway in the host part? isn't host more likely the ip or hostname of your proxy?
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
your proxy could add other headers to the invite, such as diversion or history-info, if your sip ua knows to look for them.
-- juha
El Wednesday 02 April 2008 14:49:33 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like:
INVITE sip:+34999000222@gateway SIP/2.0 To: sip:+34999000222@gateway
why gateway in the host part? isn't host more likely the ip or hostname of your proxy?
Yes, sorry, it was a failure of copy&paste ;)
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
your proxy could add other headers to the invite, such as diversion or history-info, if your sip ua knows to look for them.
Yes, that would be better than examining the "To" header, since "To" could be modified previously (forwarding and so...).
So in conclusion, it seems that there is not a extended way of handling it, rigth?
Thanks a lot.
Hola Iñaki,
El 02/04/2008, a las 16:29, Iñaki Baz Castillo escribió:
Hi, maybe this question is a bit off-topic so I'm sorry for that.
My question is about SIP providers using OpenSer that associate PSTN numbers to their local clients (SIP accounts):
Usually the client must register to OpenSer in order to receive calls. Then it will appear in location table with "Contact=sip:clientX@IP". Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222
When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like:
INVITE sip:+34999000222@gateway SIP/2.0 To: sip:+34999000222@gateway
The OpenSer will do the lookup in location table and finally send this INVITE to the clientX:
INVITE sip:clientX@IP_clientX SIP/2.0 To: sip:+34999000222@gateway
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
You can also add multiple aliases to the same user. All INVITEs to different aliases will be sent to the resolved user.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Wednesday 02 April 2008 15:35:40 Jesus Rodriguez escribió:
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
You can also add multiple aliases to the same user. All INVITEs to different aliases will be sent to the resolved user.
Yes, but after the "lookup" the RURI username will be definitively the username the client sent in the REGISTER's "Contact", so the INVITE will not change, will it?
Thanks..
Hola Iñaki,
El 02/04/2008, a las 17:40, Iñaki Baz Castillo escribió:
El Wednesday 02 April 2008 15:35:40 Jesus Rodriguez escribió:
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
You can also add multiple aliases to the same user. All INVITEs to different aliases will be sent to the resolved user.
Yes, but after the "lookup" the RURI username will be definitively the username the client sent in the REGISTER's "Contact", so the INVITE will not change, will it?
The RURI will be changed by the registered Contact value. The To: header is not modified.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Wednesday 02 April 2008 15:48:10 Jesus Rodriguez escribió:
Hola Iñaki,
El 02/04/2008, a las 17:40, Iñaki Baz Castillo escribió:
El Wednesday 02 April 2008 15:35:40 Jesus Rodriguez escribió:
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
You can also add multiple aliases to the same user. All INVITEs to different aliases will be sent to the resolved user.
Yes, but after the "lookup" the RURI username will be definitively the username the client sent in the REGISTER's "Contact", so the INVITE will not change, will it?
The RURI will be changed by the registered Contact value. The To: header is not modified.
Exactly, but a client will have (probably) just one sip account registered, so just one entry will appear in "location" table for him AoR.
Imagine a user "clientX@sip_proxy" using an Asterisk and registering with: REGISTER sip:sip_proxy SIP/2.0 To: sip:clientX@sip_proxy Contact: sip:s@ip_asterisk
It will appear in location table with "Contact=sip:clientX@IP".
Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222
When it receives a call from PSTN to +34999000222 the INVITE arriving to Asterisk will be:
INVITE sip:s@ip_asterisk SIP/2.0 To: sip:+34999000222@sip_proxy
So the info about the real PSTN number dialed by the call originator just remains in the "To" header. So the client (Asterisk) must read the "To" header in order to have a behaviour different for +34999000111 and +34999000222 (or adding in OpenSer other custom header containing also dialed number 999000222 as Juha suggests). I can't understand how using aliases in OpenSer can help here. ¿?
Thanks a lot and regards.
Hola Iñaki,
El 02/04/2008, a las 18:01, Iñaki Baz Castillo escribió:
El Wednesday 02 April 2008 15:48:10 Jesus Rodriguez escribió:
Hola Iñaki,
El 02/04/2008, a las 17:40, Iñaki Baz Castillo escribió:
El Wednesday 02 April 2008 15:35:40 Jesus Rodriguez escribió:
The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there?
You can also add multiple aliases to the same user. All INVITEs to different aliases will be sent to the resolved user.
Yes, but after the "lookup" the RURI username will be definitively the username the client sent in the REGISTER's "Contact", so the INVITE will not change, will it?
The RURI will be changed by the registered Contact value. The To: header is not modified.
Exactly, but a client will have (probably) just one sip account registered, so just one entry will appear in "location" table for him AoR.
Imagine a user "clientX@sip_proxy" using an Asterisk and registering with: REGISTER sip:sip_proxy SIP/2.0 To: sip:clientX@sip_proxy Contact: sip:s@ip_asterisk
It will appear in location table with "Contact=sip:clientX@IP".
Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222
When it receives a call from PSTN to +34999000222 the INVITE arriving to Asterisk will be:
INVITE sip:s@ip_asterisk SIP/2.0 To: sip:+34999000222@sip_proxy
So the info about the real PSTN number dialed by the call originator just remains in the "To" header. So the client (Asterisk) must read the "To" header in order to have a behaviour different for +34999000111 and +34999000222 (or adding in OpenSer other custom header containing also dialed number 999000222 as Juha suggests). I can't understand how using aliases in OpenSer can help here. ¿?
Yes, in theses cases you have to relay on To: header value. The problem is that not all "multiport" devices are "multi account" as Asterisk is and you need to use aliases to send all different DIDs to the same SIP account... some of these "multiport" devices can read the To: value and send the call to the right place even registering only one account.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Wednesday 02 April 2008 16:21:59 Jesus Rodriguez escribió:
Yes, in theses cases you have to relay on To: header value. The problem is that not all "multiport" devices are "multi account" as Asterisk is and you need to use aliases to send all different DIDs to the same SIP account... some of these "multiport" devices can read the To: value and send the call to the right place even registering only one account.
Ok, thanks.
Hi Iñaki, did you find a way to solve this problem. I have the same problem with devices that can't read the To: value. For customers with 10/100 assigned number I routed the entire root number to the customer's IP (loosing auth...), but for users with only one supplementary number it is not practicable. Has someone a suggestion for this problem? Thanks to all. Regards.
Antonio.
-----Original Message----- From: users-bounces@lists.openser.org
[mailto:users-bounces@lists.openser.org]
On Behalf Of Iñaki Baz Castillo Sent: Wednesday, April 02, 2008 6:30 PM To: users@lists.openser.org Subject: Re: [OpenSER-Users] [OT] How to handle different DID's in
incoming
calls for a registered client?
El Wednesday 02 April 2008 16:21:59 Jesus Rodriguez escribió:
Yes, in theses cases you have to relay on To: header value. The problem is that not all "multiport" devices are "multi account" as Asterisk is and you need to use aliases to send all different DIDs to the same SIP account... some of these "multiport" devices can read the To: value and send the call to the right place even registering only one account.
Ok, thanks.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hello,
in kamailio/openser, the equvalents of the operations are (see inline):
On 02/24/2009 11:17 AM, olivier taylor wrote:
What I do in SER 0.96
Before any lookup("aliases")
avp_write("$ruri/username","s:RealRuri"); //to save the Ruri
$avp(s:RealRuri) = $rU;
and just before sending the call to the user :
avp_pushto("$ruri/username", "s:RealRuri");
$rU = $avp(s:RealRuri);
You can then modify the Ruri as you want with prefix or strip if needed
strip/prefix are still there, however there are other features that can help: - string concatenation of variables using + (e.g., $var(x) = "001" + $rU;) - transformations: http://www.kamailio.org/dokuwiki/doku.php/transformations:devel
Cheers, Daniel
Hope it helps
Olivier
Antonio Reale a écrit :
Hi Iñaki, did you find a way to solve this problem. I have the same problem with devices that can't read the To: value. For customers with 10/100 assigned number I routed the entire root number to the customer's IP (loosing auth...), but for users with only one supplementary number it is not practicable. Has someone a suggestion for this problem? Thanks to all. Regards.
Antonio.
-----Original Message----- From: users-bounces@lists.openser.org
[mailto:users-bounces@lists.openser.org]
On Behalf Of Iñaki Baz Castillo Sent: Wednesday, April 02, 2008 6:30 PM To: users@lists.openser.org Subject: Re: [OpenSER-Users] [OT] How to handle different DID's in
incoming
calls for a registered client?
El Wednesday 02 April 2008 16:21:59 Jesus Rodriguez escribió:
Yes, in theses cases you have to relay on To: header value. The problem is that not all "multiport" devices are "multi account" as Asterisk is and you need to use aliases to send all different DIDs to the same SIP account... some of these "multiport" devices can read the To: value and send the call to the right place even registering only one account.
Ok, thanks.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Thanks Olivier, thanks Daniel, in this way it works. My idea was that rewrite RURI after aliases lookup (that also rewrite the RURI) was not the best solution. Thank you very much. Regards, Antonio.
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, February 25, 2009 11:36 AM To: olivier@sunforyou.be Cc: Antonio Reale; users@lists.kamailio.org Subject: Re: [Kamailio-Users] [OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?
Hello,
in kamailio/openser, the equvalents of the operations are (see inline):
On 02/24/2009 11:17 AM, olivier taylor wrote:
What I do in SER 0.96
Before any lookup("aliases")
avp_write("$ruri/username","s:RealRuri"); //to save the Ruri$avp(s:RealRuri) = $rU;
and just before sending the call to the user :
avp_pushto("$ruri/username", "s:RealRuri");$rU = $avp(s:RealRuri);
You can then modify the Ruri as you want with prefix or strip if needed
strip/prefix are still there, however there are other features that can help:
- string concatenation of variables using + (e.g., $var(x) = "001" + $rU;)
- transformations:
http://www.kamailio.org/dokuwiki/doku.php/transformations:devel
Cheers, Daniel
Hope it helps
Olivier
Antonio Reale a écrit :
Hi Iñaki, did you find a way to solve this problem. I have the same problem with devices that can't read the To: value. For customers with 10/100 assigned number I routed the entire root
number
to
the customer's IP (loosing auth...), but for users with only one supplementary number it is not practicable. Has someone a suggestion for this problem? Thanks to all. Regards.
Antonio.
-----Original Message----- From: users-bounces@lists.openser.org
[mailto:users-bounces@lists.openser.org]
On Behalf Of Iñaki Baz Castillo Sent: Wednesday, April 02, 2008 6:30 PM To: users@lists.openser.org Subject: Re: [OpenSER-Users] [OT] How to handle different DID's in
incoming
calls for a registered client?
El Wednesday 02 April 2008 16:21:59 Jesus Rodriguez escribió:
Yes, in theses cases you have to relay on To: header value. The problem is that not all "multiport" devices are "multi account" as Asterisk is and you need to use aliases to send all different DIDs to the same SIP account... some of these "multiport" devices can read
the
To: value and send the call to the right place even registering only one account.
Ok, thanks.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com
On 02/26/2009 02:56 PM, olivier taylor wrote:
It's a pleasure, I just gave an idea... Daniel did the translation.
Just take care, lookup("location") also modify the ruri.
... also it can add extra branches, so, in order to update the URI for each branch you have to use branch_route.
Cheers, Daniel
Olivier
Antonio Reale a écrit :
Thanks Olivier, thanks Daniel, in this way it works. My idea was that rewrite RURI after aliases lookup (that also rewrite the RURI) was not the best solution. Thank you very much. Regards, Antonio.
-----Original Message----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, February 25, 2009 11:36 AM To: olivier@sunforyou.be Cc: Antonio Reale; users@lists.kamailio.org Subject: Re: [Kamailio-Users] [OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?
Hello,
in kamailio/openser, the equvalents of the operations are (see inline):
On 02/24/2009 11:17 AM, olivier taylor wrote:
What I do in SER 0.96
Before any lookup("aliases")
avp_write("$ruri/username","s:RealRuri"); //to save the Ruri$avp(s:RealRuri) = $rU;
and just before sending the call to the user :
avp_pushto("$ruri/username", "s:RealRuri");$rU = $avp(s:RealRuri);
You can then modify the Ruri as you want with prefix or strip if needed
strip/prefix are still there, however there are other features that can help:
- string concatenation of variables using + (e.g., $var(x) = "001" + $rU;)
- transformations:
http://www.kamailio.org/dokuwiki/doku.php/transformations:devel
Cheers, Daniel
Hope it helps
Olivier
Antonio Reale a écrit :
Hi Iñaki, did you find a way to solve this problem. I have the same problem with devices that can't read the To: value. For customers with 10/100 assigned number I routed the entire root
number
to
the customer's IP (loosing auth...), but for users with only one supplementary number it is not practicable. Has someone a suggestion for this problem? Thanks to all. Regards.
Antonio.
-----Original Message----- From: users-bounces@lists.openser.org
[mailto:users-bounces@lists.openser.org]
On Behalf Of Iñaki Baz Castillo Sent: Wednesday, April 02, 2008 6:30 PM To: users@lists.openser.org Subject: Re: [OpenSER-Users] [OT] How to handle different DID's in
incoming
calls for a registered client?
El Wednesday 02 April 2008 16:21:59 Jesus Rodriguez escribió:
> Yes, in theses cases you have to relay on To: header value. The > problem is that not all "multiport" devices are "multi account" as > Asterisk is and you need to use aliases to send all different DIDs to > the same SIP account... some of these "multiport" devices can read >
the
> To: value and send the call to the right place even registering only > one account. > > Ok, thanks.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/2/26 Daniel-Constantin Mierla miconda@gmail.com:
... also it can add extra branches, so, in order to update the URI for each branch you have to use branch_route.
You're right. Fixed...
Cheers, Daniel
Thanks again. Regards, Antonio.
El Wednesday 02 April 2008 16:01:47 Iñaki Baz Castillo escribió:
Imagine a user "clientX@sip_proxy" using an Asterisk and registering with: REGISTER sip:sip_proxy SIP/2.0 To: sip:clientX@sip_proxy Contact: sip:s@ip_asterisk
It will appear in location table with "Contact=sip:clientX@IP".
Sorry, I mean:
It will appear in location table with "Contact=sip:s@ip_asterisk".
-
Antonio Reale -
Daniel-Constantin Mierla -
hh174 -
Iñaki Baz Castillo -
Jesus Rodriguez -
jh＠tutpro.com -
olivier taylor