Re: [Stox] Review for stox-7248bis-02

["Isomaki Markus (Nokia-TECH/Espoo)" <[e-mail]>]

Hi,

This is very good feedback. See inline.

Ben Campbell [mailto:[e-mail]] wrote:
> 
> The additional text in 04 about waiting for a NOTIFY with an active state helps.
> But it might be worth adding an initial "pending" notify exchange to (at least)
> 5.2.1.
> 

I agree with this.

> On the architectural question: I think that the "more complex"
> architecture is also the more relevant one. But, you could ignore this completely
> by just changing "SIP User" to "Presence Server" in 5.2.* .
> Unless I'm forgetting something, the architectural questions should not change
> the interactions to the left of the presence server. Then the architectural note
> could simply state that this may be a separate presence server, or it may be co-
> located with the SIP UA, but the relevant XMPP to SIP flow is the same either
> way.
> 

This is my understanding too. One way to address this would be to change "SIP User" to "SIP User (Agent) or Presence Server" in 5.2.*. Section 4 would be modified to say that presence subscriptions can be handled directly by a SIP User (Agent) or by a Presence Server acting on SIP User's behalf. In either case the message flow from the X2S GW's perspective is identical. The interaction between the Presence Server (when present) and the User Agent (winfo, PUBLISH, ...) could be verbally explained as already in Section 4, but it can be said it is out of scope of the diagrams in Section 5.2.*, as that interaction is hidden from the XMPP-SIP interworking perspective.

> Also,the idea of a SIP "server" is architecturally vague--there's no such animal
> defined in the SIP standards. I suggest calling it a SIP Proxy in 5.2.*. In 5.3.*, it
> could either be a "SIP Proxy + S2X GW", or just a "S2X GW"
> 

Perhaps just change it to "SIP Proxy" where applicable.

> Ben.
> 

Markus

---

> 
> 
> On 26 Jul 2015, at 16:22, Peter Saint-Andre - &yet wrote:
> 
> > I've posted -04 to address this feedback.
> >
> > Peter
> >
> > On 7/23/15 12:04 AM, Peter Saint-Andre - &yet wrote:
> >> Hi Markus, thanks for the continued review.
> >>
> >> On 7/22/15 6:30 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote:
> >>> Hi Peter,
> >>>
> >>> I checked the revised draft (-03) and it addresses the issues I
> >>> raised below. But that brought up another thing still.  It's been
> >>> really long since I've been dealing with SIP Presence, but I think
> >>> that the message flows in 4.2.1 may still need a couple of
> >>> clarifications:
> >>>
> >>> 1.)
> >>>
> >>> In SIP, if the subscription is not immediately authorized (neither
> >>> accepted or rejected), it is possible that a 200 OK response to the
> >>> SUBSCRIBE is sent immediately followed by a NOTIFY with subscription
> >>> state "pending". If the SIP User later on positively authorizes the
> >>> subscription, another NOTIFY with subscription state "active" is
> >>> generated. The potential "pending" state does not seem to be covered
> >>> in the current diagram, but it probably should be. The question is
> >>> just what happens in XMPP-to-SIP GW if it gets a NOTIFY with
> >>> "pending"
> >>> subscription state. To my understanding the subscription state would
> >>> remain "neutral" on the XMPP side. Would that mean that the
> >>> XMPP-to-SIP GW would not send anything to the XMPP side in that
> >>> case, i.e. only a NOTIFY indicating subscription state as "active"
> >>> would cause the message (F10) to be triggered? In that case, maybe
> >>> this kind of addition would be enough:
> >>>
> >>> OLD:
> >>>
> >>>  In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD
> >>> consider  the subscription state to be "neutral" until it receives a
> >>> NOTIFY  message.  Therefore, the SIP user or SIP server at the SIP
> >>> user's  domain SHOULD immediately send a NOTIFY message containing a
> >>> Subscription-State header [RFC6665] whose value contains the string
> >>> "active" (see Section 5 below).
> >>>
> >>> NEW:
> >>>
> >>>  In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD
> >>> consider  the subscription state to be "neutral" until it receives a
> >>> NOTIFY  message.  Therefore, the SIP user or SIP server at the SIP
> >>> user's  domain SHOULD immediately send a NOTIFY message containing a
> >>> Subscription-State header [RFC6665] with value "active" (see Section
> >>> 5  below). In case the XMPP-to-SIP gateway initially receives one or
> >>> more  NOTIFY messages with Subscription-State "pending", it MUST
> >>> respond  to them on the SIP side, but not generate any presence
> >>> stanzas towards the  XMPP User.
> >>
> >> That it better. The only further change I would make is:
> >>
> >>  In accordance with [RFC6665], the XMPP-to-SIP gateway SHOULD
> >> consider  the subscription state to be "neutral" until it receives a
> >> NOTIFY  message with a Subscription-State header [RFC6665] whose
> >> value is  "active".
> >>
> >> Also, I think it would make sense to change SHOULD to MUST here.
> >>
> >>> 2.)
> >>>
> >>> If you look at RFCs 3856 and 3857, the typical scenario in SIP
> >>> presence is: There is a SIP Presence Server handling the
> >>> subscriptions to the presence event package. That is where the
> >>> SUBSCRIBE (F2) in
> >>> 4.2.1 goes. But typically the Presence Server would not forward the
> >>> SUBSCRIBE to the SIP User in way shown in (F3). Instead, the
> >>> Presence Server and SIP User would interact via the 'presence.winfo'
> >>> event package (RFC 3857), to which the SIP User would be subcribed.
> >>> So, when the Presence Server gets a SUBSCRIBE to SIP User's
> >>> Presence, it generates a 'presence.winfo' NOTIFY the SIP User, who
> >>> will that way learn about the new subscription. The SIP User would
> >>> then authorize the subscription by some interaction (for instance
> >>> using XCAP) with the Presence Server. In this scenario, presence
> >>> updates from the SIP User would also not be sent as NOTIFYs, but as
> >>> PUBLISH messages to the Presence Server, who would then generate
> >>> NOTIFYs to all active subscribers.
> >>>
> >>> It is however possible that the Presence Server acts in a Proxy
> >>> mode, in which case (as far as I remember), it just passes the
> >>> SUBSCRIBEs and NOTIFYs through as in the current diagram in 4.2.1.
> >>> If we don't want to go into the more complex diagrams, it would
> >>> suffice just to say (already in terminology or in 4.2.1): "In these
> >>> examples it is assumed that the SIP Server acts as a proxy for
> >>> Presence event package and the actual Presence Agent resides with
> >>> the SIP User."
> >>
> >> Yes, the latter seems reasonable. However, also pointing to RFC 3857
> >> seems like a good idea.
> >>
> >> Peter
> >>