[SIPForum-techwg] Interoperability Draft v3 - scope and conformance

[Chris Sibley]

John Elwell wrote:

> [JRE] I think the only standards track RFCs involved are 3261 and
3264, so
> unless you have in mind some optional aspects of these I would hope
the
> necessary support at UAs would be covered by required conformance to
3261
> and 3264. RFC 3725 is a difficult specification to mandate. Firstly it
> describes several methods of achieving 3PCC without definitively
mandating
> any one, so mandating (or recommending) this RFC requires some
> qualification
> as to which method(s) are applicable. But I would see this as being
> largely
> applicable to a B2BUA, if there is one.  (Are we ruling out proxy-only
> realisations of PBX? I don't see how a proxy can conform to 3725?).
For a
> UA
> it is not clear what requirements are imposed by 3725 that are not
already
> covered by 3261 and 3264. In fact I thought the whole idea of 3725 was
to
> identify methods that would work with standard UAs.

I agree that RFC 3725 is a difficult specification to mandate due to the
fact that the document is comprised mostly of recommendations and
"should" language. Speaking as a SP, however, I do see significant value
in having the ability to perform third-party call control of customer
endpoints. Just referencing RFC 3261 and 3264 really isn't enough to
make this happen due to the fact that multiple 3PCC call flows are
possible under these RFCs, all of which are technically "legitimate".
However, many of these flows have serious issues (hence the reason 3725
exists in the first place).

As Alan suggested, (if we do keep 3725 as a requirement in the list) I
think it would definitely make sense to add some clarifying text. For
example, perhaps explicitly referencing section 11 of RFC 3725
(cut-and-pasted below for reference) would be sufficient?

<snip>

Most of the work involved in supporting third party call control is
   within the controller.  A standard SIP UA should be controllable
   using the mechanisms described here.  However, third party call
   control relies on a few features that might not be implemented.  As
   such, we RECOMMEND that implementors of user agent servers support
   the following:

   o  Offers and answers that contain a connection line with an address
      of 0.0.0.0.

   o  Re-INVITE requests that change the port to which media should be
      sent

   o  Re-INVITEs that change the connection address

   o  Re-INVITEs that add a media stream

   o  Re-INVITEs that remove a media stream (setting its port to zero)

   o  Re-INVITEs that add a codec amongst the set in a media stream

   o  SDP Connection address of zero

   o  Initial INVITE requests with a connection address of zero

   o  Initial INVITE requests with no SDP

   o  Initial INVITE requests with SDP but no media lines

   o  Re-INVITEs with no SDP

   o  The UPDATE method [7]

   o  Reliability of provisional responses [6]

   o  Integration of resource management and SIP [2].


Thanks,

--Chris

> 

**********************************************************************
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 
**********************************************************************-----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On
> Behalf Of Elwell, John
> Sent: Wednesday, December 14, 2005 5:58 AM
> To: Alan Johnston; Horvath Ernst
> Cc: SIP Forum Tech WG
> Subject: RE: [SIPForum-techwg] Interoperability Draft v3 - scope and
> conformance
> 
> Alan,
> 
> A couple of comments one of your responses to Ernst:
> 
> John
> 
> > -----Original Message-----
> > From: Alan Johnston [mailto:ajohnston at tello.com]
> > Sent: 13 December 2005 17:01
> > To: Horvath Ernst
> > Cc: SIP Forum Tech WG
> > Subject: Re: [SIPForum-techwg] Interoperability Draft v3 -
> > scope and conformance
> >
> > Hi Ernst,
> >
> > I have a few responses to your excellent comments, as some of
> > the text
> > you are questioning was my suggestion.  I'll leave the rest
> > for Chris ;-)
> >
> > Thanks,
> > Alan Johnston
> > sip:ajohnston at tello.com
> >
> > Horvath Ernst wrote:
> >
> > >Chris,
> > >
> > >Section 5, standards support, is a formal statement of conformance
> > >requirements and should therefore be as clear and exact as
possible.
> > >Unfortunately this is not the case since section 5 does not
> > explain what
> > >support of an RFC exactly means - nearly all the RFCs listed define
> > >various roles and functions which may not all be relevant in
> > our case.
> > >IOW, a global conformance request is not specific enough in
> > many cases.
> > >
> > >Perhaps it would help if you added some text to section 5 to say
that
> > >the RFCs must be supported as specified in subsequent
> > sections of this
> > >specification.
> > >
> > >Another big problem is that for some of the RFCs listed in section
5
> > >there are no use cases in the rest of the document although they
are
> > >marked as mandatory (e.g. REFER, Referred-by, event
> > framework, MWI). My
> > >proposal is to either remove those RFCs for this 1st edition
> > or add some
> > >text in subsequent sections with at least a rudimentary
> > description of
> > >their intended use (for example, must the SAS or PBX be able
> > to act as
> > >subscriber or as notifier or both? Must the SAS or PBX be
> > able to send
> > >or to receive REFER messages, and what can be included in a
REFER?).
> > >
> > >Finally, in section 16, references, nearly all informative
references
> > >(16.2) are marked M in section 5, so should those references be
> > >normative and moved to 16.1?
> > >
> > >
> > >Some nits:
> > >
> > >- In section 3 change "legal" to "conformant".
> > >
> > >- In section 3 a firewall would not provide address/port
> > translation - a
> > >NAT would do that.
> > >
> > >- In section 4, point 2 says that signalling considerations
> > between the
> > >SIP Application Server, Trunking Gateway and Signalling Gateway are
> > >outside scope. Should there be a similar statement about signalling
> > >considerations between the IPPBX and IP phones?
> > >
> > >- Also in section 4, is signalling between a SIP Proxy
> > Server and a SIP
> > >Application Server or between a SIP Proxy Server and an
> > IPPBX within or
> > >outside the scope of this document?
> > >
> > >- Depending on the answers to the previous two comments, is
> > the scope of
> > >this document limited to signalling between the two SIP
> > Proxy Servers?
> > >
> > >- In section 5, RFC 3264 could be implemented by phones
> > without any PBX
> > >involvement, so why is it mandated for PBX? Similarly for
> > RFC 2833, and
> > >for recommended RFC 3959 and 3960.
> > >
> > >- Also in section 5, what is the relevance of Basic
> > Authentication (RFC
> > >2617)?
> > >
> > >
> > >
> > RFC 3261 deprecates Basic Authentication, so we do not want
> > to recommend
> > it here.  The previous RFC referenced here was the MD5 spec, and I
> > suggested it be changed to RFC 2617 since this is what RFC 3261
> > references.  However, I am also uncomfortable with the mention of
> > Basic.  This should either be qualified to say excluding Basic
> > Authentication, or instead reference Section 22.4 of RFC 3261.
> >
> > >- What is the relevance of 3rd party call control, which is M for
the
> > >SAS and R (receive only) for the PBX? How can the PBX
> > recognise a 3pcc
> > >call?
> > >
> > >
> > Support of 3pcc by a UA (not acting as a controller) requires a few
> > things - accepting O/A exchanges in the 200 OK/ACK instead of
> > INVITE/200
> > OK exchange and also some SDP such as held SDP and SDP with no media
> > lines (see Section 5 of
> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-an
> > swer-examples-06.txt).
> > Perhaps these should be explicitly mentioned in this recommendation.
> [JRE] I think the only standards track RFCs involved are 3261 and
3264, so
> unless you have in mind some optional aspects of these I would hope
the
> necessary support at UAs would be covered by required conformance to
3261
> and 3264. RFC 3725 is a difficult specification to mandate. Firstly it
> describes several methods of achieving 3PCC without definitively
mandating
> any one, so mandating (or recommending) this RFC requires some
> qualification
> as to which method(s) are applicable. But I would see this as being
> largely
> applicable to a B2BUA, if there is one.  (Are we ruling out proxy-only
> realisations of PBX? I don't see how a proxy can conform to 3725?).
For a
> UA
> it is not clear what requirements are imposed by 3725 that are not
already
> covered by 3261 and 3264. In fact I thought the whole idea of 3725 was
to
> identify methods that would work with standard UAs.
> 
> >
> > >- Mandatory PKI support is implied by text on TLS, but the only
> > >reference related to PKI is RFC 2560 (OCSP). Why was this
> > particular one
> > >picked - an implementation can use other ways of checking a
> > certificate.
> > >Should other PKI RFCs be added as well?
> > >
> > >
> > >
> > I don't agree that mandatory PKI support is required by this
> > recommendation. I do agree that the text only mentioning OCSP is not
> > quite right.   I  think it should say something like the following:
> >
> > Certificates received over TLS MUST be verfied and MAY be validated.
> > Verification steps include verifying that the certificate has not
> > expired, that the issuing CA is one the PBX trusts, and
> > finally that the
> > subject of the certificate matches the server's host name or
> > SIP URI.
> > Validation can be performed using a CRL, OCSP, or other approaches.
> >
> > If you agree with a statement such as the one above
> [JRE] I think the above text is good.
> 
> , are
> > there any other
> > PKI RFCs that need to be referenced?
> >
> > >Thanks,
> > >Ernst Horvath
> > >Siemens AG
> > >
> > >
> > >
> > >_______________________________________________
> > >techwg mailing list
> > >Send mail to: techwg at sipforum.org
> > >Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> >
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg