[sipcore] draft-roach-sipcore-rfc3265bis-00

["Ian Elz" <[e-mail]>]

Adam,

A few of comments on the draft.

Sections 4.5 and 4.5.1 define how to target SUBSCRIBE to a device using
gruu. Is it worth including in this section that to target a SUBSCRIBE
to a dialog at the device you need to use the Target-Dialog header? The
use of T-D would depend upon the event package but including it here
would provide a reminder that event packages should consider this if
necessary.

Now a more complex issue:

You are proposing that the first NOTIFY establishes the SUBSCRIBE
dialog. What impact does this have on the establishment of the route set
at the UAC as defined in RFC3261?

Normal RFC3261 has the UAS route set taken from Record-Route in the
initial request. The UAS then copies the Record-Route back into the 2xx
response (or reliable provisional response) which is then used by the
UAC to set its the route set. This ensures that the route sets in the
UAC and UAS align.

Section 4.3 of the draft proposes that the initial SUBSCRIBE has the
normal Record-Route which establishes the UAS route set but that the
NOTIFY also has Record-Route performed by proxies. This leaves the
possibility that the route set at the UAC and UAS may not align.

This proposal to establish route sets by separate Record-Route actions
is in variance to the actions specified in RFC3261 and should be
described in the draft.

I also have a concern as to what will happen with the route set if the
SUBSCRIBE Record-Route is returned in the 2xx and the NOTIFY also
includes a Record-Route. Which one is used to establish the route set at
the subscriber. Do we take the one which arrives first? Do we take the
one which arrives second? There is no issue if they are the same but
what if they differ? Should there be a requirement that proxies MUST
include themselves in the NOTIFY Record-Route if they included
themselves in the SUBSCRIBE Record-Route and to exclude themselves in
the NOTUFY if they were not in the SUBSCRIBE Record-Route.

If we are to use the Record-Route in the NOTIFY then the draft should
explicitly state what should happen at the subscriber end. Should the
2xx response to the NOTIFY include a copy of the Record-Route taken from
the NOTIFY? What does the notifier end do if it then receives this
Record-Route?

There is one more related issue:

What happens if the 2xx to the SUBSCRIBE transaction is never received
by the subscriber. Based upon the non-INVITE client transaction in
RFC3261 the termination of the transaction upon expiry of Timer F will
inform the TU. In normal cases the TU would terminate the transaction
and drop the dialog In this case if the NOTIFY has been received before
the 2xx then this should be treated as the 2xx from the transaction
perspective. This almost goes as far as defining a separate client
SUBSCRIBE transaction. 

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 118 9024948
[e-mail]