Hi Bobby,
The $DLG_flags or a $dlg_var(name) are the pseudo variables that should
help you. In order to use them, you must use create_dialog() [1] for the
Initial INVITE.
In the sequential requests, you should read the values only after
loose_route() [2] is called, because there's where the dialog is matched.
Please try again and let us know your results.
[1] http://www.opensips.org/html/docs/modules/devel/dialog.html#id293854
[2] http://www.opensips.org/html/docs/modules/devel/rr.html#loose-route-id
Regards,
Razvan Crainea
OpenSIPS Developer
On 05.08.2011 07:14, Bobby Smith wrote:
Thanks for the suggestion -- unfortunately I saw this previously in a
thread and thought that'd be the key, but the results from cranking
debug up the same show it to be a different transaction on receiving
the ACK and thus the value is null. :(
I've played around with this just a little bit more and by modifying
the localcache key to be $fU_$ci (from user / callid pair, or some
tag, or something related to the initial request that's available in
the script context) I can get it to work how I want, but this really
just doesn't seem like the right way to do it.
On Fri, Aug 5, 2011 at 12:08 AM, Brett Nemeroff <[email protected]
<mailto:[email protected]>> wrote:
See if setting this param on helps.
http://www.opensips.org/html/docs/modules/devel/tm.html#id293118
-Brett
On Aug 4, 2011, at 7:48 PM, Bobby Smith <[email protected]
<mailto:[email protected]>> wrote:
All,
Here's why I'm trying to accomplish:
route [subsequent_request] {
if (has_totag && is_method("ACK") {
if (MY_VAR = "cisco") {
lookup("location");
... relay and exit
}
else {
... relay and exit lr
}
}
}
onreply_route [foo] {
....
if($ua =~ "Cisco-CP79") {
MY_VAR = "cisco"
}
}
The reasons are not really relevant (it's to get rid of a really
poor UA implementation on older Cisco 79XX firmwares), but my
intent is:
1) Set a transaction-visible-only value in onreply_route [foo]
2) Retrieve it on the ACK that completes the initial invite
transaction.
My problems:
1) if MY_VAR is an $avp, it returns null on retrieving it in the
route[subsequent_request], even with the onreply flag for tm set.
2) if MY_VAR is a $var, it's process global and so, the next
transaction that comes in could share the same state (race)
3) if MY_VAR is a flag, I can't retrieve it in the route
[subsequent request]
4) if MY_VAR is a dlg_flag or a dlg_var, I can't retrieve it in
the subsequent request even if invoking create_dialog as the
first action in the routing script (if it's an initial invite).
5) The only thing I've been able to do is create a unique key via
localcache (with $fU_useragent = myvalue) and fetch it, but this
does not allow multiple UA's to register with the same fU
My question is, is there any way to set a transaction state only
value in an onreply hook, and retrieve it on the ACK?
I know according to the RFC:
The reason for this separation is rooted in theimportance
<http://rfc-ref.org/RFC-TEXTS/3261/kw-importance.html> of
delivering all 200 (OK) responses to anINVITE
<http://rfc-ref.org/RFC-TEXTS/3261/kw-invite.html> to theUAC
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>. To
deliver them all to theUAC
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>, theUAS
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uas.html> alone takes responsibility
for retransmitting them (see Section 13.3.1.4), and theUAC
<http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html> alone
takes responsibility for acknowledging them withACK
<http://rfc-ref.org/RFC-TEXTS/3261/kw-ack.html> (see Section
13.2.2.4). Since thisACK <http://rfc-ref.org/RFC-TEXTS/3261/kw-ack.html>
is retransmitted only by theUAC <http://rfc-ref.org/RFC-TEXTS/3261/kw-uac.html>, it
is
effectively considered its owntransaction
<http://rfc-ref.org/RFC-TEXTS/3261/kw-transaction.html>.
Is there a way to get this associated with the right dialog or
something? I've tried setting a dialog profile on initial
invite, storing a value in the 200 OK onreply, and retrieving it
as well in the ACK, but I get no dialog has been created (I guess
because the dialog is early or something).
Thanks for the ideas,
BobbyS
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
