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:


    > 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users