Hey,
I have noticed that the XML body of the dialog messages contains a version attribute. The server is counting the versions using the latest subscription as a reference point, and the phone is counting the versions from the first subscription ( at reboot ).
Which is the correct way to count these versions?
Consider :
10:00 Subscription 10:05 Notification version 1 10:35 Notification version 2 11:01 Subscription 11:05 Notification version X
Is X = 3 because it is the third notification or 1 because it is the first after the last subscription? If it's version 1, it could confuse the phone cause a notification that is sent at the same time as the notification would have a confusing version.
On the other hand, each subscription, has it's own versioning, so would it not logically follow that the different subscriptions for the same device have seperate versioning?
From my phone : BLF Notify received for line: 3 has older version: 3 last version:135
To confirm my theory, I redialed the number 133 times, and once the version number had run up to 136, the lights started flashing again.
Is this a bug in Grandstream, Kamailio, or perhaps an RFC which was unclear?
Thanks,
David
Hey,
I had a look at rfc3265, 4.3.2. I find the language is ambigious :
" it ignores the NOTIFY message containing the state delta (except for the version number, which it retains to detect message loss),"
Why would it retain the version number if the versions will be reset after it resends a SUBSCRIPTION ?
"Any event package that supports delta changes to states MUST include a version number that increases by exactly one for each NOTIFY transaction in a subscription."
It speaks of incrementing, but it says nothing of resetting on a renewal of ths subscription...
kamailio.org@spam.lublink.net wrote:
Alright, I finally found the proper RFC, http://www.rfc-editor.org/rfc/rfc4235.txt
Section 4.1 :
"version: This attribute allows the recipient of dialog information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a subscription. Versions MUST be representable using a non-negative 32 bit integer."
Versions are scoped within a subscription, so when a new subscription is started, ( after the 1 hour expiry ), the version should be reset as it is a new subscription and therefore a new scope ?
When the subscription expires, is it renewed or is a new subscription created? Is the scope separate, or is it the same subscription updated?
Thanks,
David
kamailio.org@spam.lublink.net wrote:
for the version number, which it retains to detect message loss),"
Why would it retain the version number if the versions will be reset
after it resends a SUBSCRIPTION ?
"Any event package that supports delta changes to states MUST include
a version number that increases by exactly one for each NOTIFY transaction in a subscription."
It speaks of incrementing, but it says nothing of resetting on a
renewal of ths subscription...
version attribute. The server is counting the versions using the latest subscription as a reference point, and the phone is counting the versions from the first subscription ( at reboot ).
first after the last subscription? If it's version 1, it could confuse the phone cause a notification that is sent at the same time as the notification would have a confusing version.
On the other hand, each subscription, has it's own versioning, so
would it not logically follow that the different subscriptions for the same device have seperate versioning?
From my phone : BLF Notify received for line: 3 has older version: 3
last version:135
To confirm my theory, I redialed the number 133 times, and once the
version number had run up to 136, the lights started flashing again.
Is this a bug in Grandstream, Kamailio, or perhaps an RFC which was
unclear?
Hello,
On 12/15/09 2:20 AM, kamailio.org@spam.lublink.net wrote:
I think this is another questionable thing about SIP. IMO, it is same subscription if the dialog attributes do not change (call-id, from tag and to tag). But others can argue is it a new subscription. Anyone else on this one?
Cheers, Daniel
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
The proper RFC for generic subscription/notify questions is RFC 3265.
"3.1.1 Subscription Duration SUBSCRIBE requests SHOULD contain an Expires header (defined in SIP [2]). This expires value indicates the duration of the subscription. In order to keep subscriptions effective beyond the duration communicated in the Expires header, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE message on the same dialog as defined in SIP [2]"
This indicates to me that it's the same subscription as long as you refresh it.
RFC4235 refers to RFC 3265 for general terminology about subscriptions.
/O
OK, it turns out that the presence application is properly updating subscriptions within a dialog, and creating new subscriptions outside a dialog.
The difficultly is that I am rewriting the To: header, since I used dirty tools, it was dropping ;tag=, so the server thought it was a new dialog and the phone the same dialog.
I am testing to make sure that the issue is resolved.
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
On 12/15/09 4:37 PM, David wrote:
This should be fixed once r-uri is used instead of To header, right? I am trying to find some time to fix it, maybe with a mod param option.
Cheers, Daniel
Hi Daniel,
Some time ago we posted a patch to try to accomplish what you mention: http://sip-router.org/tracker/index.php?do=details&task_id=18
Hope it helps.
Regards: Francisco
Hello Francisco,
somehow I missed that patch, thanks for reminder! Is it against sip-router or kamailio 1.5.x?
I checked it quickly and the only thing that does not seem ok is how the r-uri is taken in modules/dialog/dlg_handlers.c:
- instead of:
+ if(parse_orig_ruri(msg)< 0) { + LM_ERR("bad request or missing RURI\n"); + return -1; + } +
should be:
+ if(parse_sip_msg_uri(msg)< 0) { + LM_ERR("bad request or missing RURI\n"); + return -1; + } +
and instead of:
+ &(msg->first_line.u.request.uri) );
should be
+ GET_RURI(msg) );
This ensures that latest R-URI value is taken -- you used to get original r-uri.
If someone can test and report, I will commit quickly.
Cheers, Daniel
On 12/16/09 4:07 PM, Francisco Javier Lizarán Vilches wrote:
Hi Daniel,
El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla < miconda@gmail.com> escribió:
I'm a Francisco's workmate. The patch is against kamailio 1.5. We have been using this patch in our test environment for a couple of months without problems.
BTW, we have noticed that in the dialog-info+xml body the <target uri="..."> is set to the same value as the <identity> for both local and remote elements. Is this correct? or should they be set to the local and remote contact instead?
Best regards,
Santi
Hello Santiago,
On 12/16/09 7:07 PM, Santiago Gimeno wrote:
there are not problems related to code bugs, just that does not seem to use latest version of r-uri. Do you need the original r-uri or the version updated in config?
Maybe Klaus is more familiar with the RFC specs, being the author of the modules. I would need to dig the RFCs.
Cheers, Daniel
Hi Daniel,
2009/12/16 Daniel-Constantin Mierla miconda@gmail.com
The reason why we needed the original r-uri instead of the latest is that we had problems in this scenario:
A, B and C are registered in Kamailio which acts as a presence server as well. C is subscribed to the presentity of B. If A calls B, Kamailio performs a location lookup and updates the r-uri (sip:B@XXX.XXX.XXX.XXX). The problem comes when the pua_dialoginfo module tries to send a PUBLISH to this uri and Kamailio is not located in this uri so we get this error:
DBG:pua_dialoginfo:dialog_publish: do not send PUBLISH to external URI sip:B@XXX.XXX.XXX.XXX
So we solved this by taking the original uri (sip:B@mydomain.comsip%3AB@mydomain.com) instead of using the latest.
Maybe we did something wrong and there was a better approach to solve this. What do you think?
Thanks. Best regards,
Santi
Hi,
We have posted the patch here:
http://sip-router.org/tracker/index.php?do=details&task_id=20
It's against kamailio-1.5.
Hope it helps,
Best regards,
Santi
2009/12/17 Santiago Gimeno santiago.gimeno@gmail.com
Hello,
I reworked a bit the patch for req_uri storage in dialog structure and applied the rest. All happened for kamailio 3.0, changes therefore are in GIT: http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.0.x-from-git
Would be great if you can test. Documentation is not yet updated, there is a new parameter to specify what to use to populate the ruri column, here is something that you can use for your case (where you need original uri):
modparam("dialog", "ruri_pvar", "$avp(s:uri)")
route { ... $abp(s:uri) = $ou; ... }
Klaus, when you have time, please have a second look over the changes in dialoginfo module.
Thanks, Daniel
On 12/17/09 5:28 PM, Santiago Gimeno wrote:
Daniel-Constantin Mierla wrote:
Hi Daniel!
RURI patch looks good. Regarding "contact" patch: It looks like the dlg-info struct only stores the from_contact, but not the to_contact. Thus, "target" will be not set except for provisional responses (case DLGCB_EARLY). Why?
regards klaus
Hello,
On 12/20/09 1:58 PM, Klaus Darilion wrote:
I saw that the to_contact is taken from the reply (iirc), maybe Santiago has more insights since they wrote the patch.
Cheers, Daniel
Hi,
I saw that the to_contact is taken from the reply (iirc), maybe Santiago has more insights since they wrote the patch.
The reason why we implemented it that way was our lack of knowledge ... we just tried to do it the same way as the to-tag ... just getting it from the reply. I'm sure there are better ways to do it. Should we take it directly from the dialog structure?
Best regards,
Santi
Santiago Gimeno wrote:
Actually I do not know what the contact URI is used for. Anyway, I think a more consistent approach would be to get it from dialog structure, add it to dialoginfo structure, and use it for generating all PUBLISH, not only EARLY ones.
regards klaus
Best regards,
Santi
Hello,
On 12/17/09 10:15 AM, Klaus Darilion wrote:
contacts uri are in the structure, in 'contact' array field -- they are needed to build the BYEs.
Cheers, Daniel
Without reading the RFC I suspect the version to be increased within the subscription. So, if there is a NEW subscription, the version will be reset. If it is a re-subscription (to keep the current subscription alive) the version will not be reset.
So, how to differ between NEW and RE-subscription? If the SUBSCRIBE contains a to-tag, then it is a RE-subscription. If there is no to-tag, than it is a new subscription.
regards klaus
kamailio.org@spam.lublink.net wrote:
-
Daniel-Constantin Mierla -
David -
Francisco Javier Lizarán Vilches -
kamailio.org＠spam.lublink.net
-
Klaus Darilion -
Olle E. Johansson -
Santiago Gimeno