[SIPForum-techwg] Draft Version 5 - remaining discussion points

[Chris Sibley]

FYI - I inadvertently listed a comment as coming from Rohan when it was
really Ernst's comment. I have made the correction below (in RED). 

Thanks,

--Chris


From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Chris Sibley
Sent: Monday, March 13, 2006 1:45 PM
To: SIP Forum Tech WG
Subject: [SIPForum-techwg] Draft Version 5 - remaining discussion points

IP PBX / SP Interop WG team members,
Following is a list of final discussion points derived from the "master
list" of 2/27 - 3/2 comments, along with my comments on each. 
I look forward to hearing your thoughts and getting this wrapped up! 
Thanks,
--Chris
--------------------------------------------------------------
Rohan Mahy wrote:
Section 14.1 2nd para 
Do we want to add that they MUST also send a:inactive/sendonly/recvonly?
[Chris Sibley] 
I'm not sure I understand why? Paragraph two states that an endpoint
should be prepared to receive an SDP offer containing all zeros in the
connection field, which would presumably be coming from an older SIP
(i.e. RFC 2543-compliant) endpoint. In that case the endpoint making the
offer wouldn't be capable of adding a directionality indicator to the
SDP, would it?
--------------------------------------------------------------
Cullen Jennings wrote:
"Validation can be performed using CRL, OSCP" is a pretty confused line.
How 
about deleting all the draft that no one understands.
[Chris Sibley] 
I agree that this line can be improved. I suggest that we change it to:
"Validation steps include checking the status of the certificate as well
as the status of all the certificates in the certificate chain using
CRLs or other mechanisms such as OCSP."
--------------------------------------------------------------
Rohan Mahy wrote:
I think SIP Application Server (SAS) is vague enough and used for 
enough contradictory things that we should use a different name for it. 
I propose "SIP Gateway Service (SGS)".
[Chris Sibley]
Works for me - does anyone out there object to this change in
terminology?
--------------------------------------------------------------
Cullen Jennings wrote:
Given I don't know of enterprise PBX that do reliable provisional stuff,
I 
don't think I would make that mandatory. I could not see any features
that 
needed it.
[Chris Sibley] 
This currently isn't mandatory for the PBX so I don't believe any
changes are required.
--------------------------------------------------------------
Cullen Jennings wrote:
Do you really want 3725
[Chris Sibley] 
This has already been discussed on the list. The previous decision was
that the guidance provided by 3725 (particularly the call flows) would
add value to the overall specification (as long as it was noted that the
PBX only needed to support it in the "receive only" direction.)
--------------------------------------------------------------
Cullen Jennings wrote:
4028 - Why? Do you really care?
[Chris Sibley] 
This has already been discussed on the list. The previous decision was
that implementing the timers would not be required, but would add value
to the overall specification particularly in the area of billing (e.g.
determining that an endpoint has died and when it is appropriate to stop
billing for any active calls associated with the endpoint.)
--------------------------------------------------------------
Hadriel Kaplan wrote:
Section 11.1.1:
Paragraph 3 says the Enterprise SPS is part of the service-provider's
trust-domain. I beg to differ. I would think few service-providers would
(a) implicitly believe any/all P-Asserted-Identity URIs sent from an
Enterprise, or (b) pass private identity info to an Enterprise, or (c)
not anonymize calls to the Enterprise for caller-id-blocked calls. For
example the current spec would imply that a privacy-requested call from
an Enterprise through a service-provider to another Enterprise would
leave the PAI header intact the whole way through.
I think what you're really looking for is to use the
P-Preferred-Identity from the PBX to the service-provider to identify
its specific private-identity. The service-provider can then do what
they will with it internally depending on the service they provide as
long as they follow RFC 3325.
[Chris Sibley] 
This has already been discussed on the list. Draft version 3 actually
did call for the use of P-Preferred-Identity. This was changed to
P-Asserted-Identity in draft version 4 (based on group feedback.)
--------------------------------------------------------------
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.)
--------------------------------------------------------------
Ernst Horvath wrote:
Nit (15.1 last para): Cut-through might be done on detection of early 
media at the RTP port rather than on receipt of SDP in a provisional 
response, as previously discussed in depth on the SIPPING mailing list.

[Chris Sibley] 
This sounds like a reasonable thing to do, but is there an RFC or other
"spec" we can legitimately reference?
--------------------------------------------------------------
Ernst Horvath wrote:
11.2.1: add ";user=phone" 
Ditto in both URIs in 11.3. <<<<

[Chris Sibley] 
I made the corrections to the 11.2.1 examples. However, I missed the
11.3 example when making the draft 5 revisions. I will correct that
prior to publishing the final document.
--------------------------------------------------------------
Ernst Horvath wrote:
- Section 14.3 "the decision to utilize DTMF relay or in-band signaling 
SHOULD be a user-configurable option." It is not clear why this should 
be a user matter. It is more likely to be the enterprise's 
administration that will wish to control this, not the user
[Chris Sibley] 
Agreed. By "user" I meant the Enterprise "as a whole" not the individual
end-user. That said, I think the text indicating user configurability
should probably just be removed. Does anyone disagree?
--------------------------------------------------------------






**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 - Cbeyond 
**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20060313/0e6da490/attachment.html