How to increment dialog calee_cseq value when using t_uac_dlg via xmlrpc for generating INFO requests
9 Sep
2014
9 Sep
'14
5:15 p.m.
Hi,
I am using Kamailio 4.1.1 and dlg_manage() function for processing SIP
requests with dialog module. After call is established Kamailio is being
used for generating in-dialog INFO request toward caller (using t_uac_dlg
function via xmlrpc). INFO messages are correctly generated but dialog
calee_cseq value is not being incremented with every message. That
represents a problem since other SIP requests generated by callee side
(like OPTIONS) are not in order, and there is no correct information about
calee_cseq value in dialog memory records.
The question is how can I increment dialog calee_cseq value when local INFO
request toward caller is being generated using t_uac_dlg via xmlrpc?
Thx,
Drazen
9 Sep
9 Sep
5:32 p.m.
Hello,
On 09/09/14 16:15, Drazen Rep wrote:
Hi,
I am using Kamailio 4.1.1 and dlg_manage() function for processing SIP
requests with dialog module. After call is established Kamailio is
being used for generating in-dialog INFO request toward caller (using
t_uac_dlg function via xmlrpc). INFO messages are correctly generated
but dialog calee_cseq value is not being incremented with every
message. That represents a problem since other SIP requests generated
by callee side (like OPTIONS) are not in order, and there is no
correct information about calee_cseq value in dialog memory records.
The question is how can I increment dialog calee_cseq value when local
INFO request toward caller is being generated using t_uac_dlg via xmlrpc?
such
feature is not available at this moment.
If the callee hasn't sent yet a message, the proxy won't have any clue
on what is going to be initial cseq used by callee, because there is no
constraint to start from 1 in the SIP RFC.
In the master branch (to become 4.2), I added recently support to
increment the cseq towards caller, with the main target to handle
authentication challenge from gateways/termination providers. In other
words, dialog module has some capabilities towards handling cseq
differences, but exactly what you need is not there.
To get that, probably a new rpc command has to be exported by dialog
module, to catch cseq updates, because t_uac_dlg is from tm module, with
no relation to dialog. So, overall, it is about writing some c code to
dialog module -- as starting point you can look at dlg_cseq.{c,h} files
to see how cseq can be updated and eventually at dlg_bridge rpc command
to see how a request within dialog can be sent (it sends a REFER withing
dialog) or dlg terminate (which sends BYE).
On the other hand, maybe there are other options for your needs, what is
the purpose for INFO requests sent by the proxy?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany
10 Sep
10 Sep
3:46 p.m.
Hi,
On 09.09.2014., at 16:32, Daniel-Constantin Mierla <miconda(a)gmail.com
If the callee hasn't sent yet a message, the proxy won't have any clue on
> what is going to be initial cseq used by callee, because there is no
> constraint to start from 1 in the SIP RFC.
That is true, but my intention was anyway to intercept callee requests
(i.e. OPTIONS and BYE) and alter CSeq: header values based on current
dialog callee_cseq value if subsequent request is in-dialog (
if(is_known_dlg()) and if($ft==$dlg(to_tag)) ).
Maybe I can use $dlg_var(key) variable for that purpose? It is not well
documented so question would be when can I initialize it (i.e. right after
dialog creation or only after subsequent request)? And of course how can I
increment value of this variable when local INFO request toward caller is
being generated using t_uac_dlg via xmlrpc? Is it possible to address this
INFO request (created by tm module function) inside config file at all?
In the master branch (to become 4.2), I added recently support to increment
Thank you for the tip will take a look but unfortunately I am not a native
C programmer.
On the other hand, maybe there are other options for your needs, what is
wrote:
I am using Kamailio 4.1.1 and dlg_manage() function
for processing SIP
requests with dialog module. After call is established Kamailio is being
used for generating in-dialog INFO request toward caller (using t_uac_dlg
function via xmlrpc). INFO messages are correctly generated but dialog
callee_cseq value is not being incremented with every message. That
represents a problem since other SIP requests generated by callee side
(like OPTIONS) are not in order, and there is no correct information about
callee_cseq value in dialog memory records.
such feature is not available at this moment.
The question is how can I increment dialog callee_cseq value when local
INFO
request toward caller is being generated using t_uac_dlg via xmlrpc?
the cseq towards caller, with the main target to
handle authentication
challenge from gateways/termination providers. In other words, dialog
module has some capabilities towards handling cseq differences, but exactly
what you need is not there.
Had a quick look - great option, but indeed not what I need for this case.
To get that, probably a new rpc command has to be exported by dialog
> module, to catch cseq updates, because t_uac_dlg is from tm module, with no
> relation to dialog. So, overall, it is about writing some c code to dialog
> module -- as starting point you can look at dlg_cseq.{c,h} files to see how
> cseq can be updated and eventually at dlg_bridge rpc command to see how a
> request within dialog can be sent (it sends a REFER withing dialog) or dlg
> terminate (which sends BYE).
the purpose for INFO requests sent by the proxy?
I am trying to build a proxy server which will send tariff information
(AOC) toward IPphones/gateways (caller side) during the call via INFO
messages with XML body.
Thank you for your help,
Drazen
11 Sep
11 Sep
2:06 p.m.
Hi,
On Wed, Sep 10, 2014 at 2:46 PM, Drazen Rep wrote:
If the callee hasn't sent yet a message, the proxy won't have any clue on
> what is going to be initial cseq used by callee, because there is no
> constraint to start from 1 in the SIP RFC.
That is true, but my intention was anyway to intercept callee requests
(i.e. OPTIONS and BYE) and alter CSeq: header values based on current
dialog callee_cseq value if subsequent request is in-dialog (
if(is_known_dlg()) and if($ft==$dlg(to_tag)) ).
Maybe I can use $dlg_var(key) variable for that purpose? It is not well
documented so question would be when can I initialize it (i.e. right after
dialog creation or only after subsequent request)? And of course how can I
increment value of this variable when local INFO request toward caller is
being generated using t_uac_dlg via xmlrpc? Is it possible to address this
INFO request (created by tm module function) inside config file at all?
Finally got this done via using 'event_route[tm:local-request]' and
'$dlg_var(key)' variable for that dialog. It is working as expected. Will
see if this approach brings new problem to solution.
I am using
Kamailio 4.1.1 and dlg_manage() function for processing SIP
requests with dialog module. After call is established Kamailio is being
used for generating in-dialog INFO request toward caller (using t_uac_dlg
function via xmlrpc). INFO messages are correctly generated but dialog
callee_cseq value is not being incremented with every message. That
represents a problem since other SIP requests generated by callee side
(like OPTIONS) are not in order, and there is no correct information about
callee_cseq value in dialog memory records.
such feature is not available at this moment.
The question is how can I increment dialog
callee_cseq value when local
INFO request toward caller is being generated using
t_uac_dlg via xmlrpc?
In the master branch (to become 4.2), I added recently
support to
Thank you for your help,
Drazen
increment the cseq towards caller, with the main
target to handle
authentication challenge from gateways/termination providers. In other
words, dialog module has some capabilities towards handling cseq
differences, but exactly what you need is not there.
Had a quick look - great option, but indeed not what I need for this case.
To get that, probably a new rpc command has to be exported by dialog
module, to catch cseq updates, because t_uac_dlg
is from tm module, with no
relation to dialog. So, overall, it is about writing some c code to dialog
module -- as starting point you can look at dlg_cseq.{c,h} files to see how
cseq can be updated and eventually at dlg_bridge rpc command to see how a
request within dialog can be sent (it sends a REFER withing dialog) or dlg
terminate (which sends BYE).
Thank you for the tip will take a look but unfortunately I am not a native
C programmer.
On the other hand, maybe there are other options for your needs, what is
the purpose for INFO requests sent by the proxy?
I am trying to build a proxy server which will send tariff information
(AOC) toward IPphones/gateways (caller side) during the call via INFO
messages with XML body.
5:19 p.m.
Hello,
good to hear you found a solution. You can create a wiki page on our
project site if you want to share your experience, or if you write it in
your own site/blog, you can list it in the wiki as a link.
Cheers,
Daniel
On 11/09/14 13:06, Drazen Rep wrote:
Hi,
On Wed, Sep 10, 2014 at 2:46 PM, Drazen Rep wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany
I am using Kamailio 4.1.1 and dlg_manage()
function for
processing SIP requests with dialog module. After call is
established Kamailio is being used for generating in-dialog
INFO request toward caller (using t_uac_dlg function via
xmlrpc). INFO messages are correctly generated but dialog
callee_cseq value is not being incremented with every message.
That represents a problem since other SIP requests generated
by callee side (like OPTIONS) are not in order, and there is
no correct information about callee_cseq value in dialog
memory records.
The question is how can I increment dialog callee_cseq value
when local
INFO request toward caller is being generated using
t_uac_dlg via xmlrpc?
such feature is not available at this moment.
If the callee hasn't sent yet a message, the proxy won't have
any clue on what is going to be initial cseq used by callee,
because there is no constraint to start from 1 in the SIP RFC.
That is true, but my intention was anyway to intercept callee
requests (i.e. OPTIONS and BYE) and alter CSeq: header values
based on current dialog callee_cseq value if subsequent request is
in-dialog ( if(is_known_dlg()) and if($ft==$dlg(to_tag)) ).
Maybe I can use $dlg_var(key) variable for that purpose? It is not
well documented so question would be when can I initialize it
(i.e. right after dialog creation or only after subsequent
request)? And of course how can I increment value of this variable
when local INFO request toward caller is being generated using
t_uac_dlg via xmlrpc? Is it possible to address this INFO request
(created by tm module function) inside config file at all?
Finally got this done via using 'event_route[tm:local-request]' and
'$dlg_var(key)' variable for that dialog. It is working as expected.
Will see if this approach brings new problem to solution.
In the master branch (to become 4.2), I added recently support
to increment the cseq towards caller, with the main target to
handle authentication challenge from gateways/termination
providers. In other words, dialog module has some capabilities
towards handling cseq differences, but exactly what you need
is not there.
Had a quick look - great option, but indeed not what I need for
this case.
To get that, probably a new rpc command has to be exported by
dialog module, to catch cseq updates, because t_uac_dlg is
from tm module, with no relation to dialog. So, overall, it is
about writing some c code to dialog module -- as starting
point you can look at dlg_cseq.{c,h} files to see how cseq can
be updated and eventually at dlg_bridge rpc command to see how
a request within dialog can be sent (it sends a REFER withing
dialog) or dlg terminate (which sends BYE).
Thank you for the tip will take a look but unfortunately I am not
a native C programmer.
On the other hand, maybe there are other options for your
needs, what is the purpose for INFO requests sent by the proxy?
I am trying to build a proxy server which will send tariff
information (AOC) toward IPphones/gateways (caller side) during
the call via INFO messages with XML body.
Thank you for your help,
Drazen
_______________________________________________
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
3727
days inactive
3729
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Drazen Rep