15 Dec
2009
15 Dec
'09
1: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
15 Dec
15 Dec
1: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:
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
2: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 
9:59 a.m.
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?
Cheers,
Daniel
Thanks,
David
kamailio.org(a)spam.lublink.net wrote:
_______________________________________________
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/
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 
10: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
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?
3: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:
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 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?
4: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:
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 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?
16 Dec
16 Dec
10:38 a.m.
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:
--
Daniel-Constantin Mierla
* http://www.asipto.com/
15 dec 2009 kl. 09.59 skrev Daniel-Constantin
Mierla:
_______________________________________________
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
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 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?
4: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:
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
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:
--
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 15 dec 2009 kl. 09.59 skrev Daniel-Constantin
Mierla:
_______________________________________________
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
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
5: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:
_______________________________________________
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/
-----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:
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
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:
--
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
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 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
7: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
7:24 p.m.
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(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.
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:
_______________________________________________
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/
-----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:
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
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
17 Dec
17 Dec
11:14 a.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
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
* http://www.asipto.com/
10: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
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:
_______________________________________________
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
-----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:
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
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
10: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
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-----
-- 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
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
5: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
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(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
* 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
19 Dec
19 Dec
11:35 p.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/
20 Dec
20 Dec
1:58 p.m.
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(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/
21 Dec
21 Dec
10: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/
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?
10: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
2: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
18 Dec
18 Dec
9 a.m.
Hello,
On 12/17/09 10:15 AM, Klaus Darilion wrote:
Santiago Gimeno wrote:
contacts uri are in the structure, in
'contact' array field -- they are
needed to build the BYEs.
Cheers,
Daniel
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
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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:
-- 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
_______________________________________________
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
-----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
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
>
--
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
15 Dec
15 Dec
4: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:
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
5246
days inactive
5252
days old
23 comments
7 participants
participants (7)
-
Daniel-Constantin Mierla -
David -
Francisco Javier Lizarán Vilches -
kamailio.org＠spam.lublink.net
-
Klaus Darilion -
Olle E. Johansson -
Santiago Gimeno