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:
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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:
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:
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hello,
On 12/15/09 2:20 AM, 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?
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
Thanks,
David
kamailio.org@spam.lublink.net wrote:
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:
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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, is the presence module buggy in that the subscriptions are not properly managed, or is it a bug in my routing script that is perhaps causing the dialog information to be incomplete?
Thanks,
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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
On 12/15/09 4:37 PM, David wrote:
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.
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
I am testing to make sure that the issue is resolved.
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-----Mensaje original----- De: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:
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.
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
I am testing to make sure that the issue is resolved.
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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:
-----Mensaje original----- De:users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC:users@lists.kamailio.org Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:
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.
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
I am testing to make sure that the issue is resolved.
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM,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?
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?
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla *http://www.asipto.com/
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hi Daniel,
El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla < miconda@gmail.com> escribió:
Hello Francisco,
somehow I missed that patch, thanks for reminder! Is it against sip-router or kamailio 1.5.x?
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
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:
-----Mensaje original----- De: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:
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.
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
I am testing to make sure that the issue is resolved.David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
--Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hello Santiago,
On 12/16/09 7:07 PM, Santiago Gimeno wrote:
Hi Daniel,
El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> escribió:
Hello Francisco, somehow I missed that patch, thanks for reminder! Is it against sip-router or kamailio 1.5.x?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.
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?
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?
Maybe Klaus is more familiar with the RFC specs, being the author of the modules. I would need to dig the RFCs.
Cheers, Daniel
Best regards,
Santi
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:-----Mensaje original----- De:users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org> [mailto:users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC:users@lists.kamailio.org <mailto:users@lists.kamailio.org> Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning On 12/15/09 4:37 PM, David wrote: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.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, DanielHi 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 <http://sip-router.org/tracker/index.php?do=details&task_id=18> Hope it helps. Regards: FranciscoI am testing to make sure that the issue is resolved. David On 2009-12-15 04:12, Olle E. Johansson wrote:15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:Hello, On 12/15/09 2:20 AM,kamailio.org@spam.lublink.net <mailto: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? > 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?
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_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla *http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla *http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hi Daniel,
2009/12/16 Daniel-Constantin Mierla miconda@gmail.com
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?
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
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?
Maybe Klaus is more familiar with the RFC specs, being the author of the modules. I would need to dig the RFCs.
Cheers, Daniel
Best regards,
Santi
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:
-----Mensaje original----- De: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:
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.
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
I am testing to make sure that the issue is resolved.David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
Hello,
On 12/15/09 2:20 AM, 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?
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?
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
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
--Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser...
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Santiago Gimeno wrote:
Hi Daniel,
El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> escribió:
Hello Francisco, somehow I missed that patch, thanks for reminder! Is it against sip-router or kamailio 1.5.x?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?
Hi Santi!
I think you are correct. I can not remember why I implemented it different. Are the contact URIs available in the dialog structure? Then it can easily be fixed.
regards klaus
Best regards,
Santi
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:-----Mensaje original----- De: users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org> [mailto:users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org <mailto:users@lists.kamailio.org> Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning On 12/15/09 4:37 PM, David wrote: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.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, DanielHi 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 <http://sip-router.org/tracker/index.php?do=details&task_id=18> Hope it helps. Regards: FranciscoI am testing to make sure that the issue is resolved. David On 2009-12-15 04:12, Olle E. Johansson wrote:15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:Hello, On 12/15/09 2:20 AM, kamailio.org@spam.lublink.net <mailto: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? > 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?
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_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
Hi Santi!
I think you are correct. I can not remember why I implemented it different. Are the contact URIs available in the dialog structure? Then it can easily be fixed.
We have another patch that fixes this, we'll try to post it later today.
Thanks,
Santi
regards klaus
Best regards,
Santi
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:
-----Mensaje original-----
De: users-bounces@lists.kamailio.org mailto: users-bounces@lists.kamailio.org [mailto: users-bounces@lists.kamailio.org]
En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org mailto:users@lists.kamailio.org
Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:
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.
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 < http://sip-router.org/tracker/index.php?do=details&task_id=18%3E
Hope it helps.
Regards: Francisco
I am testing to make sure that the issue is resolved.
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:
> Hello, > > > On 12/15/09 2:20 AM, kamailio.org@spam.lublink.net mailto: 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? >> >> > 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? > > > 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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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
Hi Klaus,
Hi Santi!
I think you are correct. I can not remember why I implemented it different. Are the contact URIs available in the dialog structure? Then it can easily be fixed.
We have another patch that fixes this, we'll try to post it later today.
Thanks,
Santi
regards klaus
Best regards,
Santi
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:
-----Mensaje original-----
De: users-bounces@lists.kamailio.org mailto: users-bounces@lists.kamailio.org [mailto: users-bounces@lists.kamailio.org]
En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org mailto:users@lists.kamailio.org
Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:
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.
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 < http://sip-router.org/tracker/index.php?do=details&task_id=18%3E
Hope it helps.
Regards: Francisco
I am testing to make sure that the issue is resolved.
David
On 2009-12-15 04:12, Olle E. Johansson wrote:
> 15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla: > > > >> Hello, >> >> >> On 12/15/09 2:20 AM, kamailio.org@spam.lublink.net mailto: > 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? >>> >>> >> 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? >> >> >> > 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 > > _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org mailto:Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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:
Hi,
We have posted the patch here:
http://sip-router.org/tracker/index.php?do=details&task_id=20 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 mailto:santiago.gimeno@gmail.com>
Hi Klaus, Hi Santi! I think you are correct. I can not remember why I implemented it different. Are the contact URIs available in the dialog structure? Then it can easily be fixed. We have another patch that fixes this, we'll try to post it later today. Thanks, Santi regards klaus Best regards, Santi 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: -----Mensaje original----- De: users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org> <mailto:users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org>> [mailto:users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org>] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org <mailto:users@lists.kamailio.org> <mailto:users@lists.kamailio.org <mailto:users@lists.kamailio.org>> Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning On 12/15/09 4:37 PM, David wrote: 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. 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 <http://sip-router.org/tracker/index.php?do=details&task_id=18> <http://sip-router.org/tracker/index.php?do=details&task_id=18 <http://sip-router.org/tracker/index.php?do=details&task_id=18>> Hope it helps. Regards: Francisco I am testing to make sure that the issue is resolved. David On 2009-12-15 04:12, Olle E. Johansson wrote: 15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla: Hello, On 12/15/09 2:20 AM, kamailio.org <http://kamailio.org>@spam.lublink.net <http://spam.lublink.net> <mailto:kamailio.org@spam.lublink.net <mailto: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? 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? 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 _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla wrote:
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.
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
Thanks, Daniel
On 12/17/09 5:28 PM, Santiago Gimeno wrote:
Hi,
We have posted the patch here:
http://sip-router.org/tracker/index.php?do=details&task_id=20 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 mailto:santiago.gimeno@gmail.com>
Hi Klaus, Hi Santi! I think you are correct. I can not remember why I implemented it different. Are the contact URIs available in the dialog structure? Then it can easily be fixed. We have another patch that fixes this, we'll try to post it later today. Thanks, Santi regards klaus Best regards, Santi 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: -----Mensaje original----- De: users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org> <mailto:users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org>> [mailto:users-bounces@lists.kamailio.org <mailto:users-bounces@lists.kamailio.org>] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org <mailto:users@lists.kamailio.org> <mailto:users@lists.kamailio.org <mailto:users@lists.kamailio.org>> Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning On 12/15/09 4:37 PM, David wrote: 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. 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 <http://sip-router.org/tracker/index.php?do=details&task_id=18> <http://sip-router.org/tracker/index.php?do=details&task_id=18 <http://sip-router.org/tracker/index.php?do=details&task_id=18>> Hope it helps. Regards: Francisco I am testing to make sure that the issue is resolved. David On 2009-12-15 04:12, Olle E. Johansson wrote: 15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla: Hello, On 12/15/09 2:20 AM, kamailio.org <http://kamailio.org>@spam.lublink.net <http://spam.lublink.net> <mailto:kamailio.org@spam.lublink.net <mailto: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? 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? 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 _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> <mailto:Users@lists.kamailio.org <mailto:Users@lists.kamailio.org>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users ------------------------------------------------------------------------ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla
Hello,
On 12/20/09 1:58 PM, Klaus Darilion wrote:
Daniel-Constantin Mierla wrote:
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.
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?
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:
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?
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:
Santiago Gimeno wrote:
Hi Daniel,
El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> escribió:
Hello Francisco, somehow I missed that patch, thanks for reminder! Is it against sip-router or kamailio 1.5.x?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?
Hi Santi!
I think you are correct. I can not remember why I implemented it different. Are the contact URIs available in the dialog structure? Then it can easily be fixed.
contacts uri are in the structure, in 'contact' array field -- they are needed to build the BYEs.
Cheers, Daniel
regards klaus
Best regards,
Santi
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:-----Mensaje original----- De: users-bounces@lists.kamailio.orgmailto:users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users@lists.kamailio.org mailto:users@lists.kamailio.org Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning
On 12/15/09 4:37 PM, David wrote:OK, it turns out that the presence application is properlyupdating subscriptions within a dialog, and creating new subscriptions outside a dialog.
The difficultly is that I am rewriting the To: header, since Iused dirty tools, it was dropping ;tag=, so the server thought it was a new dialog and the phone the same dialog.
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, DanielHi Daniel, Some time ago we posted a patch to try to accomplish what youmention: http://sip-router.org/tracker/index.php?do=details&task_id=18 http://sip-router.org/tracker/index.php?do=details&task_id=18
Hope it helps. Regards: FranciscoI am testing to make sure that the issue is resolved. David On 2009-12-15 04:12, Olle E. Johansson wrote:15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:> Hello, > > On 12/15/09 2:20 AM, kamailio.org@spam.lublink.net > mailto: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? > 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? > The proper RFC for generic subscription/notify questions is RFC 3265.
"3.1.1 Subscription Duration SUBSCRIBE requests SHOULD contain an Expires header (definedin 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 longas you refresh it.
RFC4235 refers to RFC 3265 for general terminology aboutsubscriptions.
/O_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users_______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users-- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org <mailto:Users@lists.kamailio.org> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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:
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
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-
Daniel-Constantin Mierla -
David -
Francisco Javier Lizarán Vilches -
kamailio.org＠spam.lublink.net
-
Klaus Darilion -
Olle E. Johansson -
Santiago Gimeno