<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Wed, Sep 10, 2014 at 2:46 PM, Drazen Rep wrote:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> 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.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">><br>> 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?<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">such feature is not available at this moment.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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)) ).</div><div><br></div><div>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?</div><div><br></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div><div>Had a quick look - great option, but indeed not what I need for this case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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).<br></blockquote><div><br></div><div>Thank you for the tip will take a look but unfortunately I am not a native C programmer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On the other hand, maybe there are other options for your needs, what is the purpose for INFO requests sent by the proxy?</blockquote><div><br></div>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.</div></div></blockquote><div> </div><div>Thank you for your help,</div><div><br></div><div>Drazen</div></div><br></div></div>