16 Aug
2012
16 Aug
'12
1:15 p.m.
Hi, the new RFC 6665 mandates that the subscription dialog is made
*after* the first NOTIFY from the UAS (rather than after the 200 to
the initial SUBSCRIBE). This means that the UAC MUST take the route
set from the *first* received NOTIFY (instead of taking it from the
200 to the initial SUBSCRIBE).
Therefore a proxy compliant with RFC 6665 MUST always add RR to
in-dialog NOTIFY requests and thus, I propose that the default SR
script file implements it.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
16 Aug
16 Aug
1:56 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Hi, the new RFC 6665 mandates that the subscription
dialog is made
*after* the first NOTIFY from the UAS (rather than after the 200 to
the initial SUBSCRIBE). This means that the UAC MUST take the route
set from the *first* received NOTIFY (instead of taking it from the
200 to the initial SUBSCRIBE).
Therefore a proxy compliant with RFC 6665 MUST always add RR to
in-dialog NOTIFY requests and thus, I propose that the default SR
script file implements it.
Sorry, I mean "doing record_route() for in-dialog NOTIFY's".
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:20 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Sorry, I mean "doing record_route() for in-dialog
NOTIFY's".
More rationale:
The problem is that, according to the new RFC 6665 (which obsoletes
RFC 3265), the UAC creates the dialog and gets the route set when the
first NOTIFY arrives (instead of taking it from the 200 to the initial
SUBSCRIBE):
RFC 6665:
------------
Section 4.4.1 has been updated to specify that dialogs should be
created when the NOTIFY arrives. Previously, the dialog was
established by the SUBSCRIBE 200...
-----------
Therefore, an UAC compliant with RFC 6665 will ignore the Record-Route
headers in the SUBSCRIBE 200 and will wait for the first NOTIFY to get
the Record-Route headers and set them as the route set of the dialog.
If such a NOTIFY does not contain RR then the UAC will fail to create
the route set and the next re-SUBSCRIBE will miss them.
So in short: every proxy in the path of a subscription MUST add RR to
in-dialog NOTIFY requests, and thus Kamailio default script file
should perform record_route() for in-dialog NOTIFY requests.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:52 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
Why don't providing a patch?
Klaus
PS: Don't you have git write privileges?
On 16.08.2012 13:15, Iñaki Baz Castillo wrote:
Hi, the new RFC 6665 mandates that the subscription
dialog is made
*after* the first NOTIFY from the UAS (rather than after the 200 to
the initial SUBSCRIBE). This means that the UAC MUST take the route
set from the *first* received NOTIFY (instead of taking it from the
200 to the initial SUBSCRIBE).
Therefore a proxy compliant with RFC 6665 MUST always add RR to
in-dialog NOTIFY requests and thus, I propose that the default SR
script file implements it.
Regards.
3:57 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Why don't providing a patch?
Klaus
PS: Don't you have git write privileges?
I will do :)
I just wanted to discuss first the issue :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:07 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
The PUA module will need to be updated too. At the moment this caches
the RRs from the 2XX response to the SUBSCRIBE. To support the new RFC
it will need to process and reverse the RRs from the NOTIFY and store
that instead.
Probably needs to be under control of a modparam so that the old
behaviour is still available for use with older network configurations.
There may well be other changes to Presence, PUA, and RLS to make them
conform to this new RFC.
Regards,
Peter
On Thu, 2012-08-16 at 15:57 +0200, Iñaki Baz Castillo wrote:
2012/8/16 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Why don't providing a patch?
Klaus
PS: Don't you have git write privileges?
I will do :)
I just wanted to discuss first the issue :)
4:20 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
> Why don't providing a patch?
>
> Klaus
>
> PS: Don't you have git write privileges?
Done:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=d6…
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:41 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
The PUA module will need to be updated too. At the moment this caches the RRs from the
2XX response to the SUBSCRIBE. To support the new RFC it will need to process and reverse
the RRs from the NOTIFY and store that instead.
Probably needs to be under control of a modparam so that the old behaviour is still
available for use with older network configurations.
There may well be other changes to Presence, PUA, and RLS to make them conform to this
new RFC.
Hi Peter, let me explain it a bit more the issue (which is not so
"new" in RFC 6665 but also in 3265 obsoleted now by 6665):
1) An UAC sends an initial SUBSCRIBE and the proxy forks it to 2 servers/UAS.
2) Both servers reply 200 but the proxy absorbs the last one (as per RFC 3261).
3) The UAC just receives the first 200 from server-1, retrieves the
Record-Route headers and To-tag and creates the route set of the
dialog.
4) UAC receives the first instant NOTIFY from server-1. Its dialog is
already formed so no need to inspect the Record-Route headers in the
NOTIFY.
5) And then UAC receives the first NOTIFY from server-2. The UAC must
then create a *second* subscription dialog having as remote-tag the
From-tag of the NOTIFY and as route set the Record-Route values of the
NOTIFY (so the proxy MUST add Record-Route).
6) So the UAC manages two dialogs, but just received a 200 for the first one.
Note about step 3 above: The UAC could receive the NOTIFY from
server-1 *before* the SUBSCRIBE 200 from server-1, and if so, UAC
should create the dialog with the data retrieved from the NOTIFY and
then "ignore" the 200 arriving later.
So RFC 3265 *already* mandates that the proxy MUST add Record-Route to
SUBSCRIBE and in-dialog NOTIFY requests:
http://tools.ietf.org/html/rfc3265#section-3.1.5
The *only* difference in RFC 6665 is that the UAC MUST generate the
dialog upon the receipt of the NOTIFY (of each NOTIFY with different
From-tag I mean), rather than creating it if the SUBSCRIBE 200 arrives
first.
Since I expect that PUA module will never send a SUBSCRIBE for which
parallel forking would take place, creating the dialog with the data
retrieved from the SUBSCRIBE 200 is good enough IMHO.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:47 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
16 aug 2012 kl. 16:41 skrev Iñaki Baz Castillo:
2012/8/16 Peter Dunkley
<peter.dunkley(a)crocodile-rcs.com>
If the notify state in the first NOTIFY is terminated there will be no new dialog.
Right?
/O
The PUA module will need to be updated too. At the moment this caches the RRs from the
2XX response to the SUBSCRIBE. To support the new RFC it will need to process and reverse
the RRs from the NOTIFY and store that instead.
Probably needs to be under control of a modparam so that the old behaviour is still
available for use with older network configurations.
There may well be other changes to Presence, PUA, and RLS to make them conform to this
new RFC.
Hi Peter, let me explain it a bit more the issue (which is not so
"new" in RFC 6665 but also in 3265 obsoleted now by 6665):
1) An UAC sends an initial SUBSCRIBE and the proxy forks it to 2 servers/UAS.
2) Both servers reply 200 but the proxy absorbs the last one (as per RFC 3261).
3) The UAC just receives the first 200 from server-1, retrieves the
Record-Route headers and To-tag and creates the route set of the
dialog.
4) UAC receives the first instant NOTIFY from server-1. Its dialog is
already formed so no need to inspect the Record-Route headers in the
NOTIFY.
5) And then UAC receives the first NOTIFY from server-2. The UAC must
then create a *second* subscription dialog having as remote-tag the
From-tag of the NOTIFY and as route set the Record-Route values of the
NOTIFY (so the proxy MUST add Record-Route).
6) So the UAC manages two dialogs, but just received a 200 for the first one.
Note about step 3 above: The UAC could receive the NOTIFY from
server-1 *before* the SUBSCRIBE 200 from server-1, and if so, UAC
should create the dialog with the data retrieved from the NOTIFY and
then "ignore" the 200 arriving later.
So RFC 3265 *already* mandates that the proxy MUST add Record-Route to
SUBSCRIBE and in-dialog NOTIFY requests:
http://tools.ietf.org/html/rfc3265#section-3.1.5
The *only* difference in RFC 6665 is that the UAC MUST generate the
dialog upon the receipt of the NOTIFY (of each NOTIFY with different
From-tag I mean), rather than creating it if the SUBSCRIBE 200 arrives
first.
Since I expect that PUA module will never send a SUBSCRIBE for which
parallel forking would take place, creating the dialog with the data
retrieved from the SUBSCRIBE 200 is good enough IMHO.
4:51 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Olle E. Johansson <oej(a)edvina.net>et>:
If the notify state in the first NOTIFY is terminated
there will be no new dialog.
Right?
Right, the UAC should release resources for that dialog.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:53 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
16 aug 2012 kl. 16:51 skrev Iñaki Baz Castillo:
2012/8/16 Olle E. Johansson <oej(a)edvina.net>et>:
Which dialog :-)
The one that never existed?
Do we now have "early dialogs" in subscribe/notify?
/O
If the notify state in the first NOTIFY is
terminated there will be no new dialog.
Right?
Right, the UAC should release resources for that dialog.
4:58 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Olle E. Johansson <oej(a)edvina.net>et>:
XDDD right
2012/8/16 Olle
E. Johansson <oej(a)edvina.net>et>:
Which dialog :-)
The one that never existed? If the notify state in the first NOTIFY is
terminated there will be no new dialog.
Right?
Right, the UAC should release resources for that dialog. Do we now have "early dialogs" in
subscribe/notify?
It would be really cool. Let's document a spec for it xD
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
7:48 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
Am 16.08.2012 13:15, schrieb Iñaki Baz Castillo:
Hi, the new RFC 6665 mandates that the subscription
dialog is made
*after* the first NOTIFY from the UAS (rather than after the 200 to
the initial SUBSCRIBE). This means that the UAC MUST take the route
set from the *first* received NOTIFY (instead of taking it from the
200 to the initial SUBSCRIBE).
How about the NOTIFYer? Which route set should the
NOTIFYer use? The one
learned from the intial SUBSCRIBE or then one from the 2xx response to
the first NOTIFY?
regards
Klaus
9:44 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/16 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Am 16.08.2012 13:15, schrieb Iñaki Baz Castillo:
The 200 it replied to the initial SUBSCRIBE.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Hi, the new RFC 6665 mandates that the
subscription dialog is made
*after* the first NOTIFY from the UAS (rather than after the 200 to
the initial SUBSCRIBE). This means that the UAC MUST take the route
set from the *first* received NOTIFY (instead of taking it from the
200 to the initial SUBSCRIBE).
How about the NOTIFYer? Which route set should the NOTIFYer use? The one
learned from the intial SUBSCRIBE or then one from the 2xx response to the
first NOTIFY? 
17 Aug
17 Aug
12:19 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
Iñaki Baz Castillo writes:
Therefore, an UAC compliant with RFC 6665 will ignore
the Record-Route
headers in the SUBSCRIBE 200 and will wait for the first NOTIFY to get
the Record-Route headers and set them as the route set of the dialog.
If such a NOTIFY does not contain RR then the UAC will fail to create
the route set and the next re-SUBSCRIBE will miss them.
So in short: every proxy in the path of a subscription MUST add RR to
in-dialog NOTIFY requests, and thus Kamailio default script file
should perform record_route() for in-dialog NOTIFY requests.
inaki,
your summary is not correct. it is enough to add rr header to the FIRST
notify after dialog creating subscribe.
would it be difficult for kamailio presence server to somehow (in a
header) indicate that the notify is the first one?
-- juha
12:28 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/17 Juha Heinanen <jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
Sure but, how to distinguish the *first* in-dialog NOTIFY and any
other later? No way.
Therefore, an UAC compliant with RFC 6665 will
ignore the Record-Route
headers in the SUBSCRIBE 200 and will wait for the first NOTIFY to get
the Record-Route headers and set them as the route set of the dialog.
If such a NOTIFY does not contain RR then the UAC will fail to create
the route set and the next re-SUBSCRIBE will miss them.
So in short: every proxy in the path of a subscription MUST add RR to
in-dialog NOTIFY requests, and thus Kamailio default script file
should perform record_route() for in-dialog NOTIFY requests.
inaki,
your summary is not correct. it is enough to add rr header to the FIRST
notify after dialog creating subscribe. would it be difficult for kamailio presence server to
somehow (in a
header) indicate that the notify is the first one?
So it would just work with Kamailio as presence server and via a
custom header/param in a NOTIFY request? that's really ugly.
And what about if I use another presence server? or what about if my
Kamailio is just an outbound proxy and knows nothing about what kind
of servers are behind it?
BTW SER default config files perform record_route() for *all* the
requests (initial and in-dialog), which is a bit "exagerate" and
useless in many cases, but in fact is not a problem.
And BTW, RFC 3265 (obsoleted by 6665) suggests adding RR to *all* the
NOTIFY requests:
http://tools.ietf.org/html/rfc6665#section-4.3
4.3. Proxy Behavior
If a proxy
wishes to see all of the SUBSCRIBE and NOTIFY requests for a given
dialog, it MUST add a "Record-Route" header field to the initial
SUBSCRIBE request and all NOTIFY requests. It MAY choose to include
"Record-Route" in subsequent SUBSCRIBE requests; however, these
requests cannot cause the dialog's route set to be modified.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:36 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
Iñaki Baz Castillo writes:
So it would just work with Kamailio as presence server
and via a
custom header/param in a NOTIFY request? that's really ugly.
And what about if I use another presence server? or what about if my
Kamailio is just an outbound proxy and knows nothing about what kind
of servers are behind it?
there could a module param in presence server that tells if this extra
header or param is added or not. i don't see anything ugly about it.
i'm sure many kamailio users are adding all kind of proprietary headers
when message spirals through their proxys.
-- juha
12:39 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/17 Juha Heinanen <jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
And what about the rest of objections in my previous mail?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
So it would just work with Kamailio as presence
server and via a
custom header/param in a NOTIFY request? that's really ugly.
And what about if I use another presence server? or what about if my
Kamailio is just an outbound proxy and knows nothing about what kind
of servers are behind it?
there could a module param in presence server that tells if this extra
header or param is added or not. i don't see anything ugly about it.
i'm sure many kamailio users are adding all kind of proprietary headers
when message spirals through their proxys.
12:54 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
Iñaki Baz Castillo writes:
And what about the rest of objections in my previous
mail?
regarding this:
Sure but, how to distinguish the *first* in-dialog
NOTIFY and any
other later? No way.
i would imagine that presence server does know when subscription is
created and first notify is sent.
and of course one would use this feature only when sip proxy and
presence server are both based on kamailio run by the same service
provider.
regarding obsoleted rfc, i don't see a big need to support it. if rr
missing from notifys would be a big problem, kamailio users would
already have noticed it.
-- juha
1:03 p.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2012/8/17 Juha Heinanen <jh(a)tutpro.com>om>:
regarding this:
Sure.
Sure but, how to distinguish the *first*
in-dialog NOTIFY and any
other later? No way.
i would imagine that presence server does know when subscription is
created and first notify is sent. and of course one would use this feature only when sip
proxy and
presence server are both based on kamailio run by the same service
provider.
So you suggest the presence module to insert a custom header/param in
the first NOTIFY of a subscription just to avoid the intermediary
proxi(es) to do record-routing, but at the same time all the default
script files for SER in sip-router sources call record_route() for
*every* requests (initial and in-dialog). And you really want to avoid
something that both RFC 3265 and 6665 suggest (adding RR for *every*
NOTIFY).
Honestly, I think adding the "feature" you propose is a waste of time
and a not needed complexity. The custom header check could be,
probably, more expensive than just adding RR to every NOTIFY.
regarding obsoleted rfc, i don't see a big need to
support it. if rr
missing from notifys would be a big problem, kamailio users would
already have noticed it.
The problem takes place when a RFC 6665 strict compliant UAC expects
to create the dialog with the Record-Route headers retrieved from the
first NOTIFY. Taking into acount that this requirement appears in RFC
6665 which has been published in July 2012, I expect that no one
existing UAC will suffer it (but maybe new devices do). So Kamailio
users cannot noticed this problem (yet).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
19 Feb
19 Feb
8:50 a.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
Am 16.08.2012 21:44, schrieb Iñaki Baz Castillo:
2012/8/16 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Just re-reading this old thread I wonder how the first NOTIFY should be
sent? The NOTIFY needs some route headers to sned the first notify.
Thus, I suspect that the notifier should use an "early route set" to
send the first NOTIFY (learnt from the RR headers in the SUBSCRIBE) and
further NOTIFYs should use the route set learnt from the RR headers in
the response to the first NOTIFY.
Is this correct?
thanks
Klaus
Am 16.08.2012 13:15, schrieb Iñaki Baz Castillo:
The 200 it replied to the initial SUBSCRIBE.
Hi, the new RFC 6665 mandates that the
subscription dialog is made
*after* the first NOTIFY from the UAS (rather than after the 200 to
the initial SUBSCRIBE). This means that the UAC MUST take the route
set from the *first* received NOTIFY (instead of taking it from the
200 to the initial SUBSCRIBE).
How about the NOTIFYer? Which route set should the NOTIFYer use? The one
learned from the intial SUBSCRIBE or then one from the 2xx response to the
first NOTIFY?
9:59 a.m.
New subject: default config: do loose_route() for in-dialog NOTIFY as per new RFC 6665
2014-02-19 8:50 GMT+01:00 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Just re-reading this old thread I wonder how the first
NOTIFY should be
sent? The NOTIFY needs some route headers to sned the first notify.
Thus, I suspect that the notifier should use an "early route set" to send
the first NOTIFY (learnt from the RR headers in the SUBSCRIBE) and further
NOTIFYs should use the route set learnt from the RR headers in the response
to the first NOTIFY.
Is this correct?
The problem is that subscription dialogs are created *after* the first
NOTIFY is received by the SUBSCRIBE originator (instead of being created
after receipt of the 200 OK), and thus the proxy MUST add Record-Route in
the NOTIFY requests (which of course are an in-dialog requests).
In case of INVITE, the dialog is created with the receipt of the 1XX or
200, so adding Record-Route to in-dialog requests (i.e. the ACK, UPDATE,
re-INVITE...) is useless.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3713
days inactive
4265
days old
21 comments
5 participants
participants (5)
-
Iñaki Baz Castillo -
Juha Heinanen -
Klaus Darilion -
Olle E. Johansson -
Peter Dunkley