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
