Wondering how others handle DID routing?
I have seen some former posts that talk about using alaias_db, however the request URI gets changed to the users SIP URI and the receiving device (asterisk) cant distinguish the DID as a result.
Any thoughts are appreciated.
-dan
You can do it however you like, but a common way this is handled is to map the DID to a registrar AOR using alias_db, then to revert the user part of the request URI to the DID (having stored it in a variable prior to the alias_db lookup).
However, not all registrants can accept an invite to a different RURI than the Contact binding they registered. Some want exactly that one and none other than. But if you're sure your registrant can, that would be the way to do it.
"Daniel W. Graham" dan@cmsinter.net wrote:
Wondering how others handle DID routing?
I have seen some former posts that talk about using alaias_db, however the request URI gets changed to the users SIP URI and the receiving device (asterisk) cant distinguish the DID as a result.
Any thoughts are appreciated.
-dan
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
Yeah that was what I was thinking but wasn't confident it was the most efficient or 'right' way of handling it. Sounds like it is my best option. I do have registrants that can't accept the behavior so I will probably add a column to the subscriber table or add a usr_preference to distinguish the type of registrant and check for the condition before processing alias_db.
Thanks for the reply and the tips, much appreciated!
On Aug 15, 2013, at 2:56 PM, "Alex Balashov" <abalashov@evaristesys.commailto:abalashov@evaristesys.com> wrote:
You can do it however you like, but a common way this is handled is to map the DID to a registrar AOR using alias_db, then to revert the user part of the request URI to the DID (having stored it in a variable prior to the alias_db lookup).
However, not all registrants can accept an invite to a different RURI than the Contact binding they registered. Some want exactly that one and none other than. But if you're sure your registrant can, that would be the way to do it.
"Daniel W. Graham" <dan@cmsinter.netmailto:dan@cmsinter.net> wrote: Wondering how others handle DID routing?
I have seen some former posts that talk about using alaias_db, however the request URI gets changed to the users SIP URI and the receiving device (asterisk) cant distinguish the DID as a result.
Any thoughts are appreciated.
-dan
________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Thursday 15 August 2013 20:55:27 Alex Balashov wrote:
You can do it however you like, but a common way this is handled is to map the DID to a registrar AOR using alias_db, then to revert the user part of the request URI to the DID (having stored it in a variable prior to the alias_db lookup).
You don't have to store the DID, it is available in $tU. A simple way to implement is to add to route[RELAY]:
route[RELAY] { #avp(dst_rewriterurito) is 1 if client want DID (from usr_preferences) if($avp(dst_rewriterurito)) { $rU=$tU; } ... }
Yes, but there is absolutely no requirement, arising from the standards, that the To URI have any relationship to the RURI. The To header is, from a semantic point of view, a purely cosmetic commentary on the intended logical destination of the call. Most endpoints will put the dialed digits in there, but they don't have to.
Also, formatting changes to the RURI prior to this point, like the usual network edge stripping and prepending, are likely to render it unequal to To.
Daniel Tryba daniel@pocos.nl wrote:
On Thursday 15 August 2013 20:55:27 Alex Balashov wrote:
You can do it however you like, but a common way this is handled is
to map
the DID to a registrar AOR using alias_db, then to revert the user
part of
the request URI to the DID (having stored it in a variable prior to
the
alias_db lookup).
You don't have to store the DID, it is available in $tU. A simple way to implement is to add to route[RELAY]:
route[RELAY] { #avp(dst_rewriterurito) is 1 if client want DID (from usr_preferences) if($avp(dst_rewriterurito)) { $rU=$tU; } ... }
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
I didn't think of pulling from to header, but in my case the to changes so I think storing in avp may be my only option. Since the call will be sent to an asterisk farm, I think I'll have to prepend rU with did after alias db lookup so while in 'asterisk land', the did and associated user is retained so it can ultimately be sent back to kamailio again where the rU would be replaced with only the did before calling relay.
I assume a location lookup needs performed before I insert the did back in otherwise a location match will not be found?
Daniel W. Graham CMSInter.net LLC 989.400.4230
On Aug 16, 2013, at 4:48 AM, "Alex Balashov" abalashov@evaristesys.com wrote:
Yes, but there is absolutely no requirement, arising from the standards, that the To URI have any relationship to the RURI. The To header is, from a semantic point of view, a purely cosmetic commentary on the intended logical destination of the call. Most endpoints will put the dialed digits in there, but they don't have to.
Also, formatting changes to the RURI prior to this point, like the usual network edge stripping and prepending, are likely to render it unequal to To.
Daniel Tryba daniel@pocos.nl wrote:
On Thursday 15 August 2013 20:55:27 Alex Balashov wrote:
You can do it however you like, but a common way this is handled is
to map
the DID to a registrar AOR using alias_db, then to revert the user
part of
the request URI to the DID (having stored it in a variable prior to
the
alias_db lookup).
You don't have to store the DID, it is available in $tU. A simple way to implement is to add to route[RELAY]:
route[RELAY] { #avp(dst_rewriterurito) is 1 if client want DID (from usr_preferences) if($avp(dst_rewriterurito)) { $rU=$tU; } ... }
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Saturday 17 August 2013 06:50:25 Daniel W. Graham wrote:
I didn't think of pulling from to header, but in my case the to changes so I think storing in avp may be my only option.
As Alex mentioned, the to header might be filled with something else. In my use case people fooling around with To for calls between registered endpoints on the same kamailio might break this (possibly leaving badly configured endpoints open to abuse).
I assume a location lookup needs performed before I insert the did back in otherwise a location match will not be found?
Yes, loopup will set $ru (and maybe $du) if succesfull. Afterwards you can change $rU at will.
-
Alex Balashov -
Daniel Tryba -
Daniel W. Graham