A comment below.
Thanks,
Alan
Brett Tate wrote:
Thanks for the response. Reply inline.
<snip>
Brett Tate wrote:
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?
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?
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.
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.
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?
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 protected]
https://www.ietf.org/mailman/listinfo/bliss
