The Bliss IE draft for Shared Appearances
(http://tools.ietf.org/id/draft-ietf-bliss-shared-appearances-03.txt)
requires proxies to add an Alert-Info header into INVITEs sent to shared
users (5.4):

"The Appearance Agent MUST be able to communicate with the forking proxy
to learn about incoming calls and also to pass the appearance number to
the proxy to insert in the Alert-Info header field."

Can anyone comment on this requirement and how we might implement it?
It seems to me that it would force the SAA and the Proxy to be
co-resident, and an authplugin in the Proxy would have to communicate
with the SAA process on every outgoing INVITE.

In http://tools.ietf.org/id/draft-anil-sipping-bla-02.txt (which is what
SAA currently implements), this header is mentioned but is not marked as
Required, and in the current implementation of SAA, we do not insert
this header.  The Polycom sets select an appearance-number (called
x-line-id in this version of the draft) and duly report it to the SAA
without the Proxy knowing or caring.

The purpose of this field is to attempt to force all UAs to present the
call on the same "line" key, as a shared line may have several
appearances on a UA.  Then users can communicate to each other to say,
for example, "pick up the call on line 2".  I personally have a lot of
trouble with this idea, since "line 2" doesn't map to anything concrete
- it does not mean a physical button labelled "line 2", it means the
second appearance of this particular registration; and it might be in
different places on different sets; it might even share a line key if a
set has only one key for the appearance group... 

I am not entirely convinced that the Proxy needs to be involved, or
should be involved, in telling UAs where to present a call.  Any other
opinions out there?

Thanks,
Carolyn


_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to