[SIPForum-techwg] Draft Version 5 - remaining discussion poin ts
Elwell, John
john.elwell at siemens.com
Tue Mar 14 03:19:03 EST 2006
Chris,
Ernst Horvath wrote:
- Section 9.1, bullet 2. If the PBX is a SIP proxy, the UA will need to
provide authentication credentials, which does not seem reasonable. Does
this mean the PBX must be a B2BUA? We have made this comment before, but
nothing seems to have happened.
[Chris Sibley]
Yes, this has been discussed before. Our specification intentionally makes
no assumption as to the physical or logical configuration of the PBX. It can
be implemented as a pure proxy or it can be a B2BUA. So, *IF* the PBX
manufacturer chose to architect their PBX as a pure proxy, *AND IF* they
wanted or needed to utilize Network Accounts, then yes, the credentials
would need to be provisioned on the Enterprise UAs.
However, if a PBX manufacturer chose to build their PBX as a pure proxy then
they probably would *NOT* need (nor want) to utilize Network Accounts in the
first place. Instead, they would rely on TLS for authentication (i.e. the
first option outlined in the section). Network Accounts are really only
useful if the PBX is a B2BUA (in which case they are very useful, to SP at
least.)
[JRE] I do think we need some clarification in 10.1. This describes two
methods by which the service provider can authenticate the enterprise.
However, it does not say which methods have to be supported by which side.
Clearly from the answer you gave above we cannot mandate support of the
second method (digest authentication) on the IP PBX side, because some IP
PBX architectures will be unable to support it. So in the traditional way,
maybe we should say that the SP MUST support both methods and the IP PBX
MUST support at least one method. Or alternatively say that the IP PBX MUST
support the first method (based on the IP PBX's certificate used for TLS
establishment) and MAY support the second method.
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20060314/177c3735/attachment.html
More information about the techwg
mailing list