[SR-Users] How to increment dialog calee_cseq value when using t_uac_dlg via xmlrpc for generating INFO requests

[Drazen Rep]

Hi,

On 09.09.2014., at 16:32, Daniel-Constantin Mierla <miconda at gmail.com>
> 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.
> >
> > 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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140910/7f625e52/attachment.html>