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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 03 Aug 2015 14:45:29 -0500

Hi,

A couple of thoughts on this:

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.

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.

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"

Ben.

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
>>

---

From: "Isomaki Markus (Nokia-TECH/Espoo)" <[email-masked]>
Date: Thu, 6 Aug 2015 10:31:28 +0000

Hi,

This is very good feedback. See inline.

Ben Campbell [mailto:[email-masked]] 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.

> 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

---

> >>> 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.)
> >>>
> >>> 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:
> >>>
> >>> 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
> >>> 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.
> >>
> >> consider  the subscription state to be "neutral" until it receives a
> >> NOTIFY  message with a Subscription-State header [RFC6665] whose
> >> value is  "active".
> >>
> >>> subscriptions to the presence event package. That is where the
> >>> SUBSCRIBE (F2) in
> >>> 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.
> >>>
> >>> 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."
> >>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 10 Aug 2015 09:45:10 -0600

On 8/6/15 4:31 AM, Isomaki Markus (Nokia-TECH/Espoo) wrote:
> Hi,
>
> This is very good feedback.

Indeed, thanks to you both.

> See inline.

+1

> 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…

I like that proposal.

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

Yes.

I'll work on a revised I-D this week.

Peter

-- 
Peter Saint-Andre
https://andyet.com/