i started to test sr presence and for some reason sr does not send out any publish request when i issue one via pua_mi.
i have in route [xmlrpc_requests]:
xlog("L_INFO", "Handling XMLRPC $rm from <$si> with body <$(rb{re.subst,/[\n\r\t]//g})>\n"); set_reply_no_connect(); set_reply_close(); dispatch_rpc();
syslog shows that sr receives xmlrpc request:
Aug 29 19:42:13 sip /usr/sbin/pres-serv[2118]: INFO: Handling XMLRPC POST from <127.0.0.1> with body <<?xml version='1.0'?><methodCall><methodName>mi</methodName><params><param><value><string>pua_publish</string></value></param><param><value><string>sip:jh@vm.test.fi</string></value></param><param><value><int>7776000</int></value></param><param><value><string>message-summary</string></value></param><param><value><string>application/simple-message-summary</string></value></param><param><value><string>.</string></value></param><param><value><string>a.1313821931.6178.2.0</string></value></param><param><value><string>P-Flags: 0</string></value></param><param><value><string>Messages-Waiting:yesVoice-Message: 1/1 (0/0)</string></value></param></params></methodCall>>
and wireshark shows that sr xmlrpc server responds to it with 200 ok. but after than nothing happens, i.e., according to wireshark no publish request is sent out. i have pua and pua_mi modules loaded and outbound proxy defined:
modparam("pua", "outbound_proxy", "sip:127.0.0.1:5082")
there is no error messages in syslog. any idea why sr does not send publish to outbound proxy? this used to work with opensips.
-- juha
i added some debug to pua_mi/mi_pua_publish() function and pua/send_publish() function and got to syslog:
Aug 29 20:57:41 sip /usr/sbin/pres-serv[3861]: INFO: pua_mi [mi_func.c:254]: send publish Aug 29 20:57:41 sip /usr/sbin/pres-serv[3861]: INFO: pua [send_publish.c:403]: pres_uri=sip:jh@vm.test.fi Aug 29 20:57:41 sip /usr/sbin/pres-serv[3861]: INFO: pua_mi [mi_func.c:258]: publish result <418>
pua/send_publish() function and it spits out 418 in this piece of code:
presentity= search_htable(&pres, hash_code); if(publ->etag && presentity== NULL) { lock_release(&HashT->p_records[hash_code].lock); return 418; }
any idea, how this hash table gets its contents, because looks like send_publish() does not find presentity sip:jh@vm.test.f although it exists in presentity db table?
-- juha
Juha Heinanen writes:
pua/send_publish() function and it spits out 418 in this piece of code:
presentity= search_htable(&pres, hash_code); if(publ->etag && presentity== NULL) { lock_release(&HashT->p_records[hash_code].lock); return 418; }
any idea, how this hash table gets its contents, because looks like send_publish() does not find presentity sip:jh@vm.test.f although it exists in presentity db table?
if pua module gets hash table contents from pua table, it is in my case empty. i tested again the same setup in my opensips presence server environment, and pua publish worked fine. has anyone succeeded with sr pua send_publish?
-- juha
Hello,
On 8/29/11 8:49 PM, Juha Heinanen wrote:
Juha Heinanen writes:
pua/send_publish() function and it spits out 418 in this piece of code:
presentity= search_htable(&pres, hash_code); if(publ->etag&& presentity== NULL) { lock_release(&HashT->p_records[hash_code].lock); return 418; }
any idea, how this hash table gets its contents, because looks like send_publish() does not find presentity sip:jh@vm.test.f although it exists in presentity db table?
if pua module gets hash table contents from pua table, it is in my case empty.
looking at the xmlrpc command content, I see the E-Tag value set, for the first publish, shouldn't it be empty and the presence server returns the value to be used later for updates?
At the first sight, the condition in the C piece of code above reads like: if the etag value is publish command is set, there must be a presentity structure.
Cheers, Daniel
Daniel-Constantin Mierla writes:
looking at the xmlrpc command content, I see the E-Tag value set, for the first publish, shouldn't it be empty and the presence server returns the value to be used later for updates?
daniel,
my app that sends mi pua publish, takes etag from presentity table (if presentity exists there) and then places it in mi pua publish command. this works in opensips.
At the first sight, the condition in the C piece of code above reads like: if the etag value is publish command is set, there must be a presentity structure.
this is how i interpret it too. perhaps in case of sr, my app needs to get it from pua table instead or always use "." as etag value.
-- juha
On 8/29/11 10:06 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
looking at the xmlrpc command content, I see the E-Tag value set, for the first publish, shouldn't it be empty and the presence server returns the value to be used later for updates?
daniel,
my app that sends mi pua publish, takes etag from presentity table (if presentity exists there) and then places it in mi pua publish command.
The presentity table is built when a PUBLISH is received, did you sent another PUBLISH before so that you have a record in this table? Or how was it added in this table so that you could get the etag value?
At the first sight, the condition in the C piece of code above reads like: if the etag value is publish command is set, there must be a presentity structure.
this is how i interpret it too. perhaps in case of sr, my app needs to get it from pua table instead or always use "." as etag value.
In the xmlrpc command, there was an etag value, have you tried with '.' as etag?
Cheers, Daniel
Daniel-Constantin Mierla writes:
The presentity table is built when a PUBLISH is received, did you sent another PUBLISH before so that you have a record in this table? Or how was it added in this table so that you could get the etag value?
there are several sources that can send publish for user's voicemail box. for example, user can listen voicemails by calling to his/her voicemail box and in that case publish is send by sems. another possibility is that use listens voicemail on web page and in that case web app sends the publish. in both cases, the app first checks from presentity table which etag to use, because it has no way to know that some other app has sent publish for the same presentity in the meantime.
In the xmlrpc command, there was an etag value, have you tried with '.' as etag?
i haven't tried with "." etag yet. i'll try that tomorrow.
-- juha
On 8/29/11 10:23 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The presentity table is built when a PUBLISH is received, did you sent another PUBLISH before so that you have a record in this table? Or how was it added in this table so that you could get the etag value?
there are several sources that can send publish for user's voicemail box. for example, user can listen voicemails by calling to his/her voicemail box and in that case publish is send by sems. another possibility is that use listens voicemail on web page and in that case web app sends the publish. in both cases, the app first checks from presentity table which etag to use, because it has no way to know that some other app has sent publish for the same presentity in the meantime.
OK, I see, so in this case the condition in should be relaxed to allow sending publish with etag even there is no presentity in pua table.
Cheers, Daniel
In the xmlrpc command, there was an etag value, have you tried with '.' as etag?
i haven't tried with "." etag yet. i'll try that tomorrow.
-- juha
Daniel-Constantin Mierla writes:
In the xmlrpc command, there was an etag value, have you tried with '.' as etag?
i haven't tried with "." etag yet. i'll try that tomorrow.
mi pua publish from different UAs on same presentity seems to work ok, when UAs always use "." as tag param.
-- juha
Hello,
On 8/30/11 7:43 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
In the xmlrpc command, there was an etag value, have you tried with '.' as etag?
i haven't tried with "." etag yet. i'll try that tomorrow.
mi pua publish from different UAs on same presentity seems to work ok, when UAs always use "." as tag param.
based on a quick look over the code, allowing any etag should be possible by just removing the condition of an existing presentity when etag value is given and provide the etag to building PUBLISH headers. But is has to be tested, since I had no testbed setup for such case.
I am attaching the patch, would be great if you can test and report the results. Please check if a new record is inserted in the table when 200 ok comes to such publish.
Thanks, Daniel
Hi Juha,
have had any time to try the patch I sent? Thinking of committing it, but no presence server environment at hand for me to try it quickly...
Thanks, Daniel
On 9/7/11 6:59 PM, Daniel-Constantin Mierla wrote:
Hello,
On 8/30/11 7:43 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
In the xmlrpc command, there was an etag value, have you tried with '.' as etag?
i haven't tried with "." etag yet. i'll try that tomorrow.
mi pua publish from different UAs on same presentity seems to work ok, when UAs always use "." as tag param.
based on a quick look over the code, allowing any etag should be possible by just removing the condition of an existing presentity when etag value is given and provide the etag to building PUBLISH headers. But is has to be tested, since I had no testbed setup for such case.
I am attaching the patch, would be great if you can test and report the results. Please check if a new record is inserted in the table when 200 ok comes to such publish.
Thanks, Daniel
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
Daniel-Constantin Mierla writes:
have had any time to try the patch I sent? Thinking of committing it, but no presence server environment at hand for me to try it quickly...
daniel,
sorry, i forgot about it. is it really a good idea to allow any etag? would it be better to require that etag matches if given and is not "."? i was able to solve my problem by always using ".", when there are more than one source that can issue publish for the same presentity.
-- juha
Hello,
On 9/12/11 9:47 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
have had any time to try the patch I sent? Thinking of committing it, but no presence server environment at hand for me to try it quickly...
daniel,
sorry, i forgot about it. is it really a good idea to allow any etag?
based on your previous emails, looked like useful when publishing is done from different points, personally I haven't come to such needs.
would it be better to require that etag matches if given and is not "."? i was able to solve my problem by always using ".", when there are more than one source that can issue publish for the same presentity.
By using ".", the presence server will create a new e-tag, right? It is not an update to an existing presence document, but creation of a new one.
Perhaps the best would be to me able to control this matching, to force or not when etag is present. From code point of view, even there is no record in PUA matching the etag, the publish is sent and added in PUA table only in case of 200ok. So, if there is no etag match on server side, then the return code should be 412 (iirc atm), so no new record added in pua. All seemed to be fine, anyhow, ultimately we can leave the patch for 3.3 if you don't need it and nobody else wants it for the moment -- I can upload it on tracker for availability.
Cheers, Daniel
Daniel-Constantin Mierla writes:
By using ".", the presence server will create a new e-tag, right? It is not an update to an existing presence document, but creation of a new one.
yes, it is considered a new presence document, which replaces an old one if any. same as if a single ua crashes and is restarted: it will issue a publish without etag.
Perhaps the best would be to me able to control this matching, to force or not when etag is present. From code point of view, even there is no record in PUA matching the etag, the publish is sent and added in PUA table only in case of 200ok. So, if there is no etag match on server side, then the return code should be 412 (iirc atm), so no new record added in pua.
yes, error code should be returned if an etag is present in publish, which does not match what presence server expects.
All seemed to be fine, anyhow, ultimately we can leave the patch for 3.3 if you don't need it and nobody else wants it for the moment -- I can upload it on tracker for availability.
if others don't have other opinions, lets put the patch on hold.
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen