As your first solution with UAC module:
"As a plan B we instead opted for sending via uac module the invite to an
oversip instance (it's open-source since a week or two), which triggers
an HTTP request towards APNS, and on kamailio check with inv-timers
every few seconds whether the client came on
Alex Balashov escribió:
On 08/07/2012 04:34 PM, Neven Boric wrote:
So, am I missing something or does set_advertised_port actually only
accept literal values?
Correct, set_advertised_port does not accept PVs. There is an entire
category of legacy core functions, and some module functions,
On 08/07/2012 04:34 PM, Neven Boric wrote:
So, am I missing something or does set_advertised_port actually only
accept literal values?
Correct, set_advertised_port does not accept PVs. There is an entire
category of legacy core functions, and some module functions, for which
that is true.
Hi,
I'm trying to use Kamailio as an outbound proxy behind a NAT (all
clients and kamailio itself are behind the same NAT):
UACs -> Kamailio -> NAT router -> PBX (hosted, public server)
I figured I could detect the external source port used by the router by
periodically sending an OPTIONS re
Klaus,
I see the following:
AVPs are special variables that are attached to SIP transactions. It is a
list of pairs (name,value). Before the transaction is created, the AVP list
is attached to SIP request. Note that the AVP list works like a stack, last
added value is retrieved first, and ther
Once you know it you will find it :-)
http://www.kamailio.org/wiki/cookbooks/3.3.x/pseudovariables#avps
regards
Klaus
On 07.08.2012 18:22, Brandon Armstead wrote:
Klaus,
Thank you for this detailed explanation. This is essentially what I
figured was happening. I was able to use htable t
Klaus,
Thank you for this detailed explanation. This is essentially what I
figured was happening. I was able to use htable to work around it.
I guess however I am still confused as to where there is any public
documentation on this specific bit. Had I've not been working with
Kamailio for y
AVPs are associated with the transaction. If you "spiral" a request
through the same proxy, then for the proxy it is a new transaction.
Thus, when processing the request a second time, there is a new
transaction and you do not have access to the AVPs of the previous
transaction.
Workarounds a