Subject: [BLISS] draft-ietf-bliss-shared-appearances-00: comments and questions

From: "Brett Tate" <[email-masked]>
Date: Mon, 13 Oct 2008 17:09:32 -0400

The following are a few comments and questions concerning
draft-ietf-bliss-shared-appearances-00.

Concerning appearance seize, how does the seized appearance (from
PUBLISH) actually get associated with outgoing INVITE appearance?  More
specifically, is the outbound proxy/b2bua receiving the INVITE supposed
to assume this INVITE corresponds to the PUBLISHed seized appearance?
And if so, what is explicitly/implicitly tying the two together?

If PUBLISH not used to seize the appearance (prior to sending INVITE),
section 5.3 indicates that the caller PUBLISHes the appearance from
NOTIFY.  Since the Appearance Agent is already aware of the current
appearance status, at what point in the flow is such a PUBLISH needed?

Concerning incoming calls, why using Alert-Info to indicate the
appearance instead of defining or using another header?  I ask mainly
because I'm not currently aware of a defined value for indicating that
the Alert-Info's absoluteURI should be ignored.

The following are a few nits:

Section 1: "aappearance".

Section 10.2: Paragraph starting "F1 to F4" is not correctly formatted
within the txt version.  Within the same paragraph, "sate" should be
"state".

Thanks,
Brett
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Fri, 17 Oct 2008 09:32:59 -0500

Hi Brett,

Thanks for your comments on the draft - see my replies below.

Thanks,
Alan

> And if so, what is explicitly/implicitly tying the two together?

These are very good questions that we will try to address in the next 
version.  In some cases, if some or all of the dialog information is 
available from the SIP stack prior to sending the INVITE, it could be 
possible to include this information in the PUBLISH - this would allow 
very good correlation between the PUBLISH and the INVITE.  However, 
since some SIP stacks may not be able to do this, the other alternative 
is for the server to match the Contact URI in the INVITE with the local 
target URI in the PUBLISH.  This is a weaker coupling but might be good 
enough for most purposes.

Do you have a scenario in mind where this coupling is critical?

> appearance status, at what point in the flow is such a PUBLISH needed?

This is another area we need to clarify as we update the call flows and 
text.  There are two possible options - the UA could publish upon 
receipt of a 100 Trying or from a 180 Ringing.  The 180 Ringing is of 
more interest to other UAs in the group, but the 100 Trying might be 
sooner, which could result in fewer appearance contention issues.

> the Alert-Info's absoluteURI should be ignored.

The Alert-Info parameter  needs to get more attention in the 
discussion.  We need to resolve this issue.  I think the reason we chose 
Alert-Info is because the appearance number tells a UA where to render 
alerting information (i.e. which lamp should be lit).  It would also be 
possible to define a new header field for this.

> within the txt version.  Within the same paragraph, "sate" should be

Thanks - we'll correct these.

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 20 Oct 2008 16:58:29 -0400

Thanks for the response.  Reply inline. 

<snip>

> > PUBLISH) actually get associated with outgoing INVITE appearance?  
> > More specifically, is the outbound proxy/b2bua receiving the INVITE 
> > supposed to assume this INVITE corresponds to the PUBLISHed 
> seized appearance?
> These are very good questions that we will try to address in 
> the next version.  In some cases, if some or all of the 
> dialog information is available from the SIP stack prior to 
> sending the INVITE, it could be possible to include this 
> information in the PUBLISH - this would allow very good 
> correlation between the PUBLISH and the INVITE.  However, 
> since some SIP stacks may not be able to do this, the other 
> alternative is for the server to match the Contact URI in the 
> INVITE with the local target URI in the PUBLISH.  This is a 
> weaker coupling but might be good enough for most purposes.
> 

I'm mainly just attempting to understand the proposal.  If an appearance
number has been explicitly seized using PUBLISH, it would seem desirable
to include the appearance number within the INVITE to reduce confusion.
Without such explicit indication, the Appearance Agents's involvement
with the outbound INVITE would be required to make assumptions to
correlate the successful PUBLISH to INVITE.

> > If PUBLISH not used to seize the appearance 
> > (prior to sending INVITE), section 5.3 
> > indicates that the caller PUBLISHes the 
> > appearance from NOTIFY.  Since the Appearance 
> > Agent is already aware of the current 
> This is another area we need to clarify as we update the call 
> flows and text.  There are two possible options - the UA 
> could publish upon receipt of a 100 Trying or from a 180 
> Ringing.  The 180 Ringing is of more interest to other UAs in 
> the group, but the 100 Trying might be sooner, which could 
> result in fewer appearance contention issues.

This is somewhat related to the open issue at the end of 5.1.  A mode of
operation where PUBLISH only needed for line-seize and
re-synchronization would be useful.

> > Concerning incoming calls, why using Alert-Info 
> > to indicate the appearance instead of defining 
> > or using another header?  I ask mainly because 
> > I'm not currently aware of a defined value for 
> > indicating that the Alert-Info's absoluteURI 
> > should be ignored.  
> 
> The Alert-Info parameter needs to get more attention 
> in the discussion.  We need to resolve this issue.

For the reason mentioned, I currently prefer a new header.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Venkatesh <[email-masked]>
Date: Mon, 20 Oct 2008 16:54:30 -0700

Brett:

Replies inline...

> correlate the successful PUBLISH to INVITE.

[Venkatesh] While I understand this may be a desirable, I am not sure I
understand the use-case you had in mind where having this information alone
in the INVITE would be useful. The application requiring information about
appearances could subscribe to the AoR "like" any other User-Agent and
gather all information about the call by the time it receives the INVITE?

> For the reason mentioned, I currently prefer a new header.

[Venkatesh] RFC 2206 provides a list of reserved/test URL's. My
understanding is that these reserved name spaces are ignored by the client.
My thinking was to have applications use these reserved domains in cases
where they don't intend to provide any other useful information in the
Alert-Info URL? Defining a new header for communicating this information
this seems like an overkill to me. It also, probably takes the scope of this
document out of BLISS and moves it to SIP/SIPPING?

Thanks
Venkatesh

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Oct 2008 07:41:10 -0500

A comment below.

Thanks,
Alan

> correlate the successful PUBLISH to INVITE.

Well, I think loose coupling between the appearance agent and the proxy 
is actually a good thing for the design.  And architects can always 
tightly couple them without any problems.

Here's how I look at it.  The PUBLISH to seize the appearance is just 
that - it just reserves it for a particular UA in the appearance group.  
At that point, it should not be tied to any specific call - it is up to 
the UA what to do with the appearance.  Shortly after, the INVITE is 
sent - at this point, there is not tight coupling either, but there is 
no need for it.  As soon as an early dialog is created with a 18x or a 
dialog with a 2xx, then the UA sends another PUBLISH.  At this point the 
appearance is correlated with the dialog, and this is when it needs to 
be.  The appearance agent shares this information with the other UAs in 
the group.  Unless there is some requirement that we haven't discussed, 
I think this works.

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 21 Oct 2008 09:41:39 -0400

>> I'm mainly just attempting to understand the proposal.
>> If an appearance number has been explicitly seized 
>> using PUBLISH, it would seem desirable to include 
>> the appearance number within the INVITE to reduce 
>> confusion.  Without such explicit indication, the 
>> Appearance Agents's involvement with the outbound 
>> INVITE would be required to make assumptions to
> [Venkatesh] While I understand this may be a 
> desirable, I am not sure I understand the use-case 
> you had in mind where having this information alone 
> in the INVITE would be useful. The application 
> requiring information about appearances could 
> subscribe to the AoR "like" any other User-Agent 
> and gather all information about the call by the 
> time it receives the INVITE?
	
I'll provide the response within the reply to Alan concerning the topic.

<snip>

> [Venkatesh] RFC 2206 provides a list of 
> reserved/test URL's. My understanding is that 
> these reserved name spaces are ignored by the 
> client. My thinking was to have applications 
> use these reserved domains in cases where they 
> don't intend to provide any other useful 
> information in the Alert-Info URL? Defining a 
> new header for communicating this information 
> this seems like an overkill to me. It also, 
> probably takes the scope of this document out 
> of BLISS and moves it to SIP/SIPPING?
	
Yes; RFC 2606 provides uri possibilities.  However unless something is
documented concerning the topic, it is indeterminate as to how the
receivers will act.  Even if documented, it can cause non desired
behavior until devices have been updated to expect receiving such a uri
and know how to interpret the situation; however the worst case would
likely just be a useless dns query and related log failure.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 21 Oct 2008 10:31:56 -0400

> > If an appearance number has been explicitly 
> > seized using PUBLISH, it would seem desirable 
> > to include the appearance number within the 
> > INVITE to reduce confusion.  Without such 
> > explicit indication, the Appearance Agents's 
> > involvement with the outbound INVITE would be 
> > required to make assumptions to correlate the 
> > successful PUBLISH to INVITE.  
> 
> Well, I think loose coupling between the 
> appearance agent and the proxy is actually a 
> good thing for the design.  And architects can 
> always tightly couple them without any problems.
> 
> Here's how I look at it.  The PUBLISH to seize 
> the appearance is just that - it just reserves 
> it for a particular UA in the appearance group.  
> At that point, it should not be tied to any 
> specific call - it is up to the UA what to do 
> with the appearance.  Shortly after, the INVITE 
> is sent - at this point, there is not tight 
> coupling either, but there is no need for it.  
> As soon as an early dialog is created with a 18x 
> or a dialog with a 2xx, then the UA sends 
> another PUBLISH.  At this point the appearance 
> is correlated with the dialog, and this is when 
> it needs to be.  The appearance agent shares 
> this information with the other UAs in the 
> group.  Unless there is some requirement that we 
> haven't discussed, I think this works.

For a line-seize call setup, the appearance agent would be sending some
useless notifies associated with the INVITE until the caller PUBLISHes
that the INVITE is associated with the seized appearance.  More
specifically, appearance agent may send NOTIFY without appearance for
the 18x dialog and then have to send another one when the caller decides
to PUBLISH that the dialog is associated with the seized appearance.

I'd prefer the caller be able to communicate such information within the
outgoing INVITE.

Similarly for origination situation without PUBLISH line-seize, section
5.3 indicates appearance agent selects the appearance.  If there is an
allocated seized appearance (obtained from PUBLISH) without
corresponding INVITE, is appearance agent supposed to allocate a non
seized appearance or assume INVITE corresponds to the seized appearance?

Thanks,
Brett

---

From: Venkatesh <[email-masked]>
Date: Tue, 21 Oct 2008 13:47:09 -0700

Replies Inline....

> to PUBLISH that the dialog is associated with the seized appearance.

[Venkatesh] I am not sure why you classify this as useless? Your source of
confusion probably comes from combining the "appearance agent" function with
call/INVITE processing. Infact these are two different applications and are
orthogonal to each other. The PUBLISH/NOTIFY model is simply indicating that
a UA 'seized' a line to place an outbound call. It can choose to provide the
SIP dialog related information once the call is established or when it
believes it is ready to provide this information to other parties in the
group. For example, you may delay providing the SIP dialog ID's until a user
places the call on hold at which point, a "call pickup" requires knowledge
of the dialog.  If I understand your argument correctly, what you are
describing is a UA that advertises line seize information in the PUBLISH in
'arbitrary' messages even with in the same call? I think what we are
proposing is that a UA either publish this information in *all* requests if
it wants to use the line seize  or not advertise it at all and let the
"appearance agent" handle this for the UA. The UA needs to decide what model
it wants to use and stick to it once it decides on the approach?

> seized appearance or assume INVITE corresponds to the seized appearance?

[Venkatesh] I am not I understand your question? The "appearance agent" has
nothing to do with orgination INVITE processing and does not allocate a
"line" when a INVITE is received. Infact, it is not even required to see the
origination INVITE. If it receives a PUBLISH w/o a specific request for a
line for a "dialog" it allocates a free line. It associates the line with
the "dialog id" in the PUBLISH payload and uses this information for
construction dialog states for subsequent PUBLISH requests.

---

From: Venkatesh <[email-masked]>
Date: Tue, 21 Oct 2008 14:51:57 -0700

Replies....

> likely just be a useless dns query and related log failure.

[Venkatesh] We can definitely document UA's ignore the URI if it they
contain the reserved domains outlined in RFC 2206 but thought that was the
intent of of RFC 2206. IMO, it is easier to document this if this is what we
need, rather than defining a new header in SIPPING (assuming it will not get
frowned upon and rejected in SIPPING); and updating all network elements to
allow support for this new header.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 21 Oct 2008 18:46:38 -0400

> > For a line-seize call setup, the appearance 
> > agent would be sending some useless notifies 
> > associated with the INVITE until the caller 
> > PUBLISHes that the INVITE is associated with 
> > the seized appearance.  More specifically, 
> > appearance agent may send NOTIFY without 
> > appearance for the 18x dialog and then have 
> > to send another one when the caller decides
> [Venkatesh] I am not sure why you classify this 
> as useless? Your source of confusion probably 
> comes from combining the "appearance agent" 
> function with call/INVITE processing. Infact 
> these are two different applications and are 
> orthogonal to each other. 

I agree that they may be separate; however they may be combined.  More
specifically, the outbound proxy/b2bua application server can also act
as an appearance agent.

> The PUBLISH/NOTIFY model is simply indicating that 
> a UA 'seized' a line to place an outbound call.

SUBSCRIBE is also within the model.  And when middle boxes like
proxy/b2bua see related incoming/outgoing INVITEs, there would need to
be a policy concerning when to send NOTIFY.  It can seed NOTIFY per
local policy 1) based upon observations or 2) wait until PUBLISH
received.

<snip>

> If I understand your argument correctly, what you 
> are describing is a UA that advertises line seize 
> information in the PUBLISH in 'arbitrary' messages 
> even with in the same call? 

I don't understand your interpretation of what I have been discussing.
One of my comments was that it would be desirable to allow the outbound
proxy/b2bua recognize that an INVITE is associated with a seized
appearance.  The following are a couple of options.

1) Send the PUBLISHed seized appearance number within an outbound
INVITE.  The outbound proxy/b2bua (also acting as the users appearance
agent) could then recognize that this INVITE is associated with the
seized appearance.  If appropriate, the appearance content could
obviously be removed from INVITE prior to proxying the request.

2) Communicate the not yet sent INVITE's Call-ID and From tag when
PUBLISHing the line-seize.

> I think what we are proposing is that a UA either 
> publish this information in *all* requests 

I don't understand "publish this information in *all* requests".

> if it wants to use the line seize  or not advertise 
> it at all and let the "appearance agent" handle 
> this for the UA. The UA needs to decide what 
> model it wants to use and stick to it once it 
> decides on the approach?

I agree that there could be multiple models and approaches to all of
this.  I'll wait until the next version of the draft before commenting
upon restricting a device to always or never use line-seize; it
currently sounds like non desirable limitation.

> > I'd prefer the caller be able to communicate such 
> > information within the outgoing INVITE.
> >
> > Similarly for origination situation without 
> > PUBLISH line-seize, section 5.3 indicates 
> > appearance agent selects the appearance.  If 
> > there is an allocated seized appearance (obtained 
> > from PUBLISH) without corresponding INVITE, is 
> > appearance agent supposed to allocate a non 
> [Venkatesh] I am not I understand your question? 
> The "appearance agent" has nothing to do with 
> origination INVITE processing and does not allocate 
> a "line" when a INVITE is received. Infact, it is 
> not even required to see the origination INVITE. 
> If it receives a PUBLISH w/o a specific request for 
> a line for a "dialog" it allocates a free line. 
> It associates the line with the "dialog id" in the 
> PUBLISH payload and uses this information for 

According to section 5.3, the appearance agent would see the INVITE and
select the appearance.

Section 5.3: "A UA that does not need to select a particular appearance
number (or doesn't care) would just send an INVITE as normal to place an
outbound call.  The Appearance Agent would select an available
appearance and notify all subscribed UAs of the selection.  The UA
placing the call then publishes the use of this appearance number."
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss