17 Aug
2012
17 Aug
'12
11:47 a.m.
Hey All,
I was wondering if anyone could point me to the right direction on the
following issue:
I use registrar with path to store contacts after main proxy. There I
have properly stored received db field (original address of the NAT
router).
When I query the registrar, I get the user contact details (natted ones)
in 302 redirect. However at this point I cannot access received avp (or
I did not find a way yet, except calling reg_fetch_contacts which I
would prefer not to since it doubles the work lookup does).
Is there any catch which could save me in this scenario? After loopkup()
is there any pseudovariable which I can inspect to find out user's
contact data? Any other way to extract received contact data out of
contact info?
Thanks in advance for any kind of tip!
DanB
17 Aug
17 Aug
12:13 p.m.
If it helps someone else, got in the mean time another way of accessing
it, via transformations on top of $du:
$(du{uri.param,received}).
The question which still stands: is there more "automated" way to
properly handle 302 redirect when the contact is behind NAT?
DanB
O
12:42 p.m.
Hello,
On 8/17/12 11:13 AM, DanB wrote:
If it helps someone else, got in the mean time another
way of
accessing it, via transformations on top of $du:
$(du{uri.param,received}).
$du is the address of next hop and it is set due to the Path headers in
this case. In the case there is no intermediary proxy, it will be the
address of the NAT router.
In case you have many contacts for same users, then you have to look
also at the other branches, which are accessible via $branch(...).
The question which still stands: is there more "automated" way to
properly handle 302 redirect when the contact is behind NAT?
This might not work
for multiple contacts. I even wonder if there is a
RFC saying what to do in the case there are many contacts with different
Path headers. Path headers have to be turned into Route headers after
lookup(), but for redirects?!? Shall Path should be added in reply? Any
IETF guru around that can shed some light?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
1:50 p.m.
Daniel,
As always experience counts the most (I did not consider the multiple
contacts scenario).
Here is what I cooked now after your advice (for the sake of proper
archiving). In the end I will process the rcv contact parameter (which
will become ruri param) in the proxy sitting in front of registrar and
set the $du out of it.
"""
if (!lookup("location")) {
$var(rc) = $rc;
t_newtran();
switch ($var(rc)) {
case -1:
case -3:
send_reply("404", "Not Found");
exit;
case -2:
send_reply("405", "Method Not Allowed");
exit;
}
}
# Populate received contact parameter if found in db
$var(received) = $(du{uri.param,received});
if !strempty( $var(received) ) {
$ru = $ru + ";rcv="+ $var(received);
}
$var(i)=0;
while($var(i)<$branch(count)) {
$var(received) = $(branch(dst_uri)[$var(i)]{uri.param,received});
if !strempty( $var(received) ) {
$(branch(uri)[$var(i)]) = $(branch(uri)[$var(i)]) + ";rcv="+
$var(received);
}
$var(i) = $var(i) + 1;
}
sl_send_reply("302", "Locator Redirect");
exit;
"""
Thanks again!
DanB
On 08/17/2012 11:42 AM, Daniel-Constantin Mierla wrote:
Hello,
On 8/17/12 11:13 AM, DanB wrote:
If it helps someone else, got in the mean time
another way of
accessing it, via transformations on top of $du:
$(du{uri.param,received}).
$du is the address of next hop and it is set due to the Path headers in
this case. In the case there is no intermediary proxy, it will be the
address of the NAT router.
In case you have many contacts for same users, then you have to look
also at the other branches, which are accessible via $branch(...).
The question which still stands: is there more "automated" way to
properly handle 302 redirect when the contact is behind NAT?
This might not work
for multiple contacts. I even wonder if there is a
RFC saying what to do in the case there are many contacts with different
Path headers. Path headers have to be turned into Route headers after
lookup(), but for redirects?!? Shall Path should be added in reply? Any
IETF guru around that can shed some light?
Cheers,
Daniel
12:37 p.m.
Hello,
On 8/17/12 10:47 AM, DanB wrote:
Hey All,
I was wondering if anyone could point me to the right direction on the
following issue:
I use registrar with path to store contacts after main proxy. There I
have properly stored received db field (original address of the NAT
router).
did you take the received parameter from the Path header? Otherwise
received (ie. the received column value) is usually the source ip/port.
The received parameter of Path is stored along with it in the
appropriate column.
Cheers,
Daniel
When I query the registrar, I get the user contact
details (natted
ones) in 302 redirect. However at this point I cannot access received
avp (or I did not find a way yet, except calling reg_fetch_contacts
which I would prefer not to since it doubles the work lookup does).
Is there any catch which could save me in this scenario? After
loopkup() is there any pseudovariable which I can inspect to find out
user's contact data? Any other way to extract received contact data
out of contact info?
Thanks in advance for any kind of tip!
DanB
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
12:41 p.m.
Hey Daniel,
Yeah, got the header out of received from path. Actually I have
de-coupled registrations which work and store just fine the received
parameter out of INVITEs which are querying the registrar using lookup.
In the end I have ended up using received parameter if present in $du
after lookup and appending it to contact (removing it after in the proxy
which sits in front of registrar). Here is the code snippet for anyone
needing it in the future:
"""
if (!lookup("location")) {
$var(rc) = $rc;
t_newtran();
switch ($var(rc)) {
case -1:
case -3:
send_reply("404", "Not Found");
exit;
case -2:
send_reply("405", "Method Not Allowed");
exit;
}
}
# Populate received contact parameter if found in db
$var(received) = $(du{uri.param,received});
if !strempty( $var(received) ) {
$ru = $ru + ";rcv="+ $var(received);
}
sl_send_reply("302", "Locator Redirect");
exit;
"""
Thanks,
DanB
On 08/17/2012 11:37 AM, Daniel-Constantin Mierla wrote:
Hello,
On 8/17/12 10:47 AM, DanB wrote:
Hey All,
I was wondering if anyone could point me to the right direction on the
following issue:
I use registrar with path to store contacts after main proxy. There I
have properly stored received db field (original address of the NAT
router).
did you take the received parameter from the Path header? Otherwise
received (ie. the received column value) is usually the source ip/port.
The received parameter of Path is stored along with it in the
appropriate column.
Cheers,
Daniel
When I query the registrar, I get the user
contact details (natted
ones) in 302 redirect. However at this point I cannot access received
avp (or I did not find a way yet, except calling reg_fetch_contacts
which I would prefer not to since it doubles the work lookup does).
Is there any catch which could save me in this scenario? After
loopkup() is there any pseudovariable which I can inspect to find out
user's contact data? Any other way to extract received contact data
out of contact info?
Thanks in advance for any kind of tip!
DanB
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4480
days inactive
4480
days old
5 comments
2 participants
participants (2)
-
DanB -
Daniel-Constantin Mierla