Hi,
I'm trying to use *_dialoginfo modules but I'm facing to a missunderstanding, or a bug. In fact, the presence server is working and I'm also able to subscribe to dialog event. But when pua_dialoginfo uses pua to send the Publish, I don't know where it going... I even not sure publishes are really sent.
This the log :
DBG:dialog:run_create_callbacks: dialog=0xb59d30b0 DBG:pua_dialoginfo:__dialog_created: new INVITE dialog created: from=sip:alice@domain DBG:core:grep_aliases: comparing host [0:domain:0] with us [0:domain:0] DBG:core:grep_aliases: match found for: [0:domain:0] DBG:core:check_self: host == me DBG:pua_dialoginfo:build_dialoginfo: new_body: <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:alice@domain"> <dialog id="MzQ3N2FiMzhiZGIwNzhhNDhhNjcxN2Y5OGJhY2M0N2Q." call-id="MzQ3N2FiMzhiZGIwNzhhNDhhNjcxN2Y5OGJhY2M0N2Q." direction="initiator"> <state>Trying</state> <remote> <identity>sip:bob@domain</identity> <target uri="sip:bob@domain"/> </remote> <local> <identity>sip:alice@domain</identity> <target uri="sip:alice@domain"/> </local> </dialog> </dialog-info> DBG:pua_dialoginfo:dialog_publish: publish uri= sip:alice@domain DBG:pua_dialoginfo:print_publ: publ: DBG:pua_dialoginfo:print_publ: uri= sip:alice@domain DBG:pua_dialoginfo:print_publ: id= DIALOG_PUBLISH.MzQ3N2FiMzhiZGIwNzhhNDhhNjcxN2Y5OGJhY2M0N2Q. DBG:pua_dialoginfo:print_publ: expires= 0 DBG:pua:send_publish: pres_uri=sip:alice@domain DBG:pua:search_htable: core_hash= 118 DBG:pua:search_htable: record not found DBG:pua:send_publish: insert type DBG:pua:send_publish: UPDATE_TYPE and no record found DBG:pua:send_publish: request for a publish with expires 0 and no record found DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout DBG:tm:run_reqin_callbacks: trans=0xb59d3270, callback type 1, id 0 entered
Regards,
Eric.
Can you please stop cross posting between multiple mailing lists? Look first for which module is supported by whom and in which project and post only there.
Adrian
On Mar 4, 2009, at 3:01 PM, Eric PTAK wrote:
2009/3/4 Eric PTAK eric.ptak.fr@gmail.com:
Hi,
Hi, could you please ask in just *one* maillist?
On 03/04/2009 04:01 PM, Eric PTAK wrote:
According to this message, the publish has the expires value 0, therefore is no longer sent.
Does this happen for all cases or from time to time?
Cheers, Daniel
I've well seen the expires=0 but I was thinking the PS will notify with an expires=0. So I didn't thinking its a problem... I may be wrong :D And to answer you, yes, it always happens.
Thanks you,
Eric.
2009/3/4 Daniel-Constantin Mierla miconda@gmail.com
On 03/04/2009 04:36 PM, Eric PTAK wrote:
I've well seen the expires=0 but I was thinking the PS will notify with an expires=0.
But it is not a NOTIFY, it is the PUBLISH we talk here about, or did I miss something?
Cheers, Daniel
Yes we're talking about the PUBLISH.
To clear my previous mail, the NOTIFY I mentioned is the NOTIFY that the PS will send after the handle_publish().
I checked pua_dialoginfo sources, and it uses dialog module's lifetime parameter, I'll check on that.
Regards, Eric.
2009/3/4 Daniel-Constantin Mierla miconda@gmail.com
On 03/04/2009 04:45 PM, Eric PTAK wrote:
OK, clear, handle_publish() does not happen as no PUBLISH is sent by PUA.
I checked pua_dialoginfo sources, and it uses dialog module's lifetime parameter, I'll check on that.
Let me know if you discover there something wrong. I added lot of new features, but should not affect this side, however you never know...
Cheers, Daniel
After a quick source inspection, for the expires=0 : the value is taken from override_lifetime parameter from pua_dialoginfo or from the constructed dialog timeout. Both are equals to 0.
I still thinking this is not an error, because to remove a publication from the PS a PUA must publish with expires=0.
Anca from opensips answered : "In OpenSIPS you can set the 'presence_server' to configure where the Publish messages are sent"
So I've tried to change outbound_proxy pua parameter but I'm still stuck...
Eric. 2009/3/4 Daniel-Constantin Mierla miconda@gmail.com
Actually we still do not know if you use Kamailio or Opensips (which have slightly different implementations)
The PUBLISh should be sent to: publish uri= sip:alice@domain
If "domain" is yourself, it should be looped to the proxy via loopback interface (ngrep -d lo port 5060)
regards klaus
Eric PTAK schrieb:
Daniel was right ! I've changed override_lifetime pua_dialoginfo's parameter and it's now working !
Eric.
2009/3/4 Klaus Darilion klaus.mailinglists@pernau.at
It was clear from logs that pua does not send the PUBLISH, because of expire=0.
Now I am wondering how un-PUBLISH (delete the tuple) could happen if the pua does not send publish with expire=0.
Cheers, Daniel
On 03/04/2009 05:30 PM, Eric PTAK wrote:
2009/3/4 Daniel-Constantin Mierla miconda@gmail.com
It was clear from logs that pua does not send the PUBLISH, because of expire=0.
Now I am wondering how un-PUBLISH (delete the tuple) could happen if the pua
does not send publish with expire=0.
May PUA refuses expires=0 only for the first PUBLISH ? If yes, the unPUBLISH is working.
Back to the original issue and cause, why the dialog struct has his lifetime set to 0 ? Even if it work by setting up override_lifetime, there may have an error somewhere ?
Cheers, Daniel
Regards,
Eric.
I found in dialog/dlg_handlers.c line 190 : it's build a new dialog struct but does not fill lifetime. I added a line to fill it using get_dlg_timeout, and it's now working, without setting up override_lifetime !
What do you think ?
Regards,
Eric.
2009/3/4 Eric PTAK eric.ptak.fr@gmail.com
I wonder why the lifetime was 0 at all?
The lifetime should be the lifetime from the dialog module, and a liftime of 0 makes also in dialog module no sense.
regards klaus
Eric PTAK schrieb:
Hi all for a new debug day ;)
You're right Klaus, from my understanding : - the expires value is taken from the dialog struct, or from override_lifetime if it's set. ==> at this point, dialog->lifetime = 0, so if override_lifetime isn't set the expires will equal 0 too. so we need to go more deeply.
(not in call order) - the dialog struct is given via the callback and filled by the dialog module - the dialog module calls get_dlg_timeout function which return the avp lifetime or default_timeout if the avp doesn't exist - the dialog module calls run_create_callbacks which then calls registered callbacks like pua_dialoginfo's one
the weird thing, from dialog/dlg_handlers.c line 470 to 510, the dialog struct is built but the lifetime field is filled after the run_create_callbacks call...
Regards, Eric. 2009/3/5 Klaus Darilion klaus.mailinglists@pernau.at
Eric PTAK schrieb:
I remember I have come across this before. Currently the order is:
/* first INVITE seen (dialog created, unconfirmed) */ run_create_callbacks( dlg, msg);
if ( seq_match_mode!=SEQ_MATCH_NO_ID && add_dlg_rr_param( msg, dlg->h_entry, dlg->h_id)<0 ) { LM_ERR("failed to add RR param\n"); goto error; }
if ( d_tmb.register_tmcb( msg, t, TMCB_RESPONSE_OUT|TMCB_RESPONSE_FWDED, dlg_onreply, (void*)dlg, unref_new_dialog)<0 ) { LM_ERR("failed to register TMCB\n"); goto error; }
dlg->lifetime = get_dlg_timeout(msg);
I wonder if it should be changed. Shouldn't run_create_callbacks() executed later? E.g. If there is an error creating the dialog IMO it makes no sense to call the callback at all.
Daniel, what do you think?
regards klaus
On 03/05/2009 12:14 PM, Klaus Darilion wrote:
Seems the right way to do it. You can commit on trunk and let it there for testing, then backport.
Cheers, Daniel