[Kamailio-Users] Presence_Dialoginfo versioning

List overview All Threads
Download

newer

older

[Kamailio-Users] Question about...

[Kamailio-Users] Clients with late...

kamailio.org＠spam.lublink.net

15 Dec 2009 15 Dec '09

2:10 a.m.

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

Show replies by date

kamailio.org＠spam.lublink.net

15 Dec 15 Dec

2:39 a.m.

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(a)spam.lublink.net wrote:

...

kamailio.org＠spam.lublink.net

3:20 a.m.

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(a)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(a)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(a)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(a)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

10:59 a.m.

Hello, On 12/15/09 2:20 AM, kamailio.org(a)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

...

Thanks, David kamailio.org(a)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(a)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 ).

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?

-- Daniel-Constantin Mierla * http://www.asipto.com/

Olle E. Johansson

11:12 a.m.

15 dec 2009 kl. 09.59 skrev Daniel-Constantin Mierla:

...

Hello, On 12/15/09 2:20 AM, kamailio.org(a)spam.lublink.net wrote:

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

David

4:06 p.m.

...

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.

In that case, it would seem that Kamailio has a bug in it's implementation of the version numbers?

David

4:18 p.m.

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(a)spam.lublink.net wrote:

David

5:37 p.m.

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(a)spam.lublink.net wrote:

Daniel-Constantin Mierla

16 Dec 16 Dec

11:38 a.m.

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

...

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(a)spam.lublink.net wrote:

-- Daniel-Constantin Mierla * http://www.asipto.com/

Francisco Javier Lizarán Vilches

5:07 p.m.

...

-----Mensaje original----- De: users-bounces(a)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(a)lists.kamailio.org Asunto: Re: [Kamailio-Users] Presence_Dialoginfo versioning 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

...

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(a)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?

Daniel-Constantin Mierla

6:30 p.m.

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:

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(a)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

-- Daniel-Constantin Mierla *http://www.asipto.com/

Santiago Gimeno

8:07 p.m.

Hi Daniel, El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla < miconda(a)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(a)lists.kamailio.org [mailto:users-bounces@lists.kamailio.org <users-bounces(a)lists.kamailio.org>] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users(a)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(a)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-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser-project.org/cgi-bin/mailman/listinfo/users _______________________________________________ Kamailio (OpenSER) - Users mailing listUsers@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/usershttp://lists.openser-project.org/cgi-bin/mailman/listinfo/users -- Daniel-Constantin Mierla * http://www.asipto.com/ _______________________________________________ Kamailio (OpenSER) - Users mailing list Users(a)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

8:24 p.m.

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

...

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:

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> 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(a)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(a)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(a)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/

Santiago Gimeno

17 Dec 17 Dec

12:14 p.m.

Hi Daniel, 2009/12/16 Daniel-Constantin Mierla <miconda(a)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.com<sip%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

-- Daniel-Constantin Mierla * http://www.asipto.com/

Klaus Darilion

11:15 a.m.

Santiago Gimeno wrote:

...

Hi Daniel, El 16 de diciembre de 2009 17:30, Daniel-Constantin Mierla <miconda(a)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

...

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(a)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(a)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(a)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(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

Santiago Gimeno

11:17 a.m.

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

-----Mensaje original-----

De: users-bounces(a)lists.kamailio.org <mailto: users-bounces(a)lists.kamailio.org> [mailto: users-bounces(a)lists.kamailio.org] En nombre de Daniel-Constantin Mierla Enviado el: miércoles, 16 de diciembre de 2009 10:38 Para: David CC: users(a)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> 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(a)spam.lublink.net <mailto: >>> kamailio.org(a)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(a)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(a)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

Santiago Gimeno

6:28 p.m.

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(a)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

-----Mensaje original----- > De: users-bounces(a)lists.kamailio.org <mailto: > users-bounces(a)lists.kamailio.org> [mailto: > users-bounces(a)lists.kamailio.org] > > En nombre de Daniel-Constantin Mierla > Enviado el: miércoles, 16 de diciembre de 2009 10:38 > Para: David > CC: users(a)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> 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(a)spam.lublink.net <mailto: >>>> kamailio.org(a)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(a)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(a)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(a)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

20 Dec 20 Dec

12:35 a.m.

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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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/

Klaus Darilion

2:58 p.m.

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

...

Thanks, Daniel On 12/17/09 5:28 PM, Santiago Gimeno wrote:

-- Daniel-Constantin Mierla * http://www.asipto.com/

Daniel-Constantin Mierla

21 Dec 21 Dec

11:08 a.m.

Hello, On 12/20/09 1:58 PM, Klaus Darilion wrote:

...

Daniel-Constantin Mierla 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 -- Daniel-Constantin Mierla * http://www.asipto.com/

Santiago Gimeno

11:28 a.m.

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

Klaus Darilion

3:03 p.m.

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

Daniel-Constantin Mierla

18 Dec 18 Dec

10 a.m.

Hello, On 12/17/09 10:15 AM, Klaus Darilion wrote:

...

Santiago Gimeno wrote:

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

-----Mensaje original----- De: users-bounces(a)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(a)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

> 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(a)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(a)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(a)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/

Klaus Darilion

15 Dec 15 Dec

5:27 p.m.

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(a)spam.lublink.net wrote:

...

5453

days inactive

5459

days old

sr-users@lists.kamailio.org

Manage subscription

23 comments

7 participants

tags (0)

participants (7)

Daniel-Constantin Mierla
David
Francisco Javier Lizarán Vilches
kamailio.org＠spam.lublink.net
Klaus Darilion
Olle E. Johansson
Santiago Gimeno