Subject: [dispatch] Questions regarding draft-kaplan-sipping-interop-bcp-02

From: "Dale Worley" <[email-masked]>
Date: Fri, 17 Jul 2009 15:33:55 -0400

Section 2:

There are two broad areas of SIP interoperation.  One is "phone to
PBX", which is assumed to be between a UA and a proxy for its domain.
The other is "SIP trunking", that is, between two proxies, often in
different administrative domains.  The recommendations in this draft
seem to cover both areas, and it's likely that the two areas cannot be
clearly separated.  Nonetheless, a naive reader (me) would likely
infer from the author's employer that the draft only covers "SIP
trunking" problems.  An expansion of the Applicability section would
dispel this misinterpretation earlier in the text, and would prevent
some readers from leaving off finishing reading the document.

Section 4.3:

Just after the regexp is the statement "Note this is after removing
visual-separators, and any user parameters."  Given he need for
accuracy here, this statement is problematic because
"visual-separator" is not a defined term in regard to SIP URIs
(although it is for tel: URIs), and "user parameter" is not defined at
all in the grammar (although people generally know what the term
means).

The initial part of a SIP URI is officially called "user".

Isn't the maximum length of an E.164 number 15 digits?  If so, why are
16-digit numbers also restricted?

A more clearly defined specification is:

   It is RECOMMENDED that SIP domains not allocate SIP URI AoR 
   user parts which match the following regular expression syntax, 
   unless the URI is intended to have the same significance as
   the corresponding E.164 number:

   ^+?([-.()]*[0-9]){11,16}[-.()]*(;.*)?$ 

   This regular expression is to be compared to the user part after
   removing any escaping.  The characters "*" and "#", although
   allowed in tel: URIs, are not allowed in E.164 numbers, and so user
   parts containing them are not included in this prohibition.

In regard to the statement

   It is RECOMMENDED, that the SIP Working Group address the 
   fundamental issue of E.164 or telephone number scope in SIP URI's.  

I don't see what issue needs to be addressed, as the working group's
opinion is well-defined and well-known, and nobody has advanced any
argument to change it.

   The TEL URI also has specific syntactic and usage issues beyond 
   simply lack of broad industry support, which may be a reason for not 
   supporting it. 

This is more interesting, since the question to be answered is "Why
don't implementers follow the clear intention of the specification,
and what might be done about that?"

In regard to the URI schemes that are used in various locations, we
need a general statement that elements should tolerate sip:, sips:,
and tel: URIs in all situations, excepting when the element must
understand the URI to process the message.  E.g., there is no excuse
for rejecting a syntactically correct From URI, because an element
never needs to understand the semantics of the From URI.

Similarly, there are situations where a default action is specified to
be taken when the element does not understand a URI which might
otherwise cause it to take specific action.  In such cases, an element
should take the default action for such URIs rather than rejecting the
message outright.

Section 4.4:

   Although the Tel URI has not seen much usage itself using the "tel" 
   scheme, it is quite common to see SIP URI's containing Tel-URI 
   parameters - i.e., Tel URI's in the form of SIP URI's.  There are 
   many URI parameters defined for Tel-URI that are popular, and thus 
   frequently appear in SIP URI's, for example in the request-URI. 
    
What is not made clear here is that these parameters show up as
"user-part parameters", which is a syntax feature not defined in RFC
3261.  Naively, the above paragraph suggests that these parameters
show up as URI-parameters.  This could be fixed by amending the first
sentence to say "... quite common to see SIP URI's user-parts
containing Tel-URI parameters ...", and adding an example:  "E.g.,
sip:+12125551212;phone-context=[email-masked]"

   The most common interoperability problem in this area is the 
   placement of the Tel URI parameters, for example the "tgrp" and 
   "trunk-context" parameters from [RFC4904], and the "rn", "npdi", and 
   "cic" parameters from [RFC4694].  RFC 3261 section 19.1.6 is very 
   clear that the entire telephone-subscriber portion, including 
   parameters, is placed in the userinfo portion of a SIP URI.  Thus 
   the Tel-URI parameters become user parameters for SIP, not SIP URI 
   parameters. 
    
"userinfo portion" should be "user portion", as the SIP URI syntax
allows phone numbers to be followed by a password part, and presumably
such an inserted telephone-subscriber portion can be followed by a
password part (yuck).

Section 5.1:

In regard to failure responses to REGISTER requests:

   [What can we say here that UA's will actually do?] 

"In any circumstance the UA MUST take care that it never generates
retries of requests without using a suitable back-off strategy.  If
the UA receives a response which suggests that a particular
modification of the request is likely to be successful, it MAY send
the modified request immediately.  The UA MAY NOT retry any failing
request with a long-term average frequency of more than one request
sent (new client transaction initiated) per 5 minutes regardless of
what responses it receives."

Making sure that UAs do not flood systems is a critical need.

Section 5.2:

Let's add "SIP elements MUST process provided Contact URIs opaquely."

Section 5.5:

Shouldn't this section refer to sections 2.4 to 2.6 (various forms of
transfer) in RFC 5359 (the service examples RFC)?

Section 6.1:

I suggest softening the first recommendation to require SDP only in
initial INVITEs, but permitting offer-less re-INVITEs.  The latter is
very useful in implementing MOH, and since the dialog path is already
established, it is unambiguous what media/codecs the UAS and the
middleboxes support/permit *in that dialog*, even if call routing is
affected by media/codecs.

Section 6.4:

   [Note: one trick some vendors use is to pretend the unacceptable 
   response was not received and send a CANCEL - should we recommend 
   that?] 

That's an interesting idea, since it seems to permit the INVITE to
fail-over to another destination which might generate an acceptable
answer.  But thinking more about it, I don't think that works -- the
CANCEL gets a 200 response but doesn't do anything (since the UAS has
already progressed the dialog to confirmed), and the UAS will
retransmit the 200.  What is needed is to eat the 200 response with
the unacceptable answer so that all upstream proxies have a chance to
fork the request to additional destinations.  But that means that the
proxy that eats the 200 must be well downstream, near the UAS that
generated the 200, but must know what the UAC considers unacceptable.
It's hard to make that work unless the proxy that eats the 200 is also
the one that generates further forks, and also services the UAC.

The only workable solution I can think of is for the INVITE to carry
"Request-Disposition: no-cancel" so that the intermediate proxies
continue to generate forks even though one UAS responds 200.  Then the
UAC will receive all the 200s as they are generated.  If it doesn't
like the answer in one 200, it can BYE that dialog.  If it receives a
200 with an answer it likes, it can then CANCEL the INVITE to suppress
further forking.

That's messy, but it might make sense for a UAC to use it as a
fallback strategy.  Assuming that the intermediate proxies support
Request-Disposition, it is even standardized.

Section 7:

The Call-Info header is used in the call-completion architecture
(draft-bliss-ietf-call-completion).  I suspect that many other "rare"
headers are used sporadically in other situations.

A better recommendation is to remind implementers that an
implementation MUST ignore header fields, URI-parameters, and
header-parameters that it does not understand.  Conversely,
implementations MUST reject requests with unknown option-tags in
Require header fields.  If implementations follow these rules,
extraneous information should not cause interoperation problems, since
SIP features are designed (remarkably carefully!) to be
upward-compatible under these rules.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jul 2009 17:37:30 -0400

Dale,
Thanks for the detailed review!
I will take your comments for the next rev of the doc. (I thought I had fixed one of them already but realized not in the rev I submitted - d'oh)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dale Worley
> Sent: Friday, July 17, 2009 3:34 PM
> To: DISPATCH
> Subject: [dispatch] Questions regarding draft-kaplan-sipping-interop-bcp-
> 02
> 
> Section 2:
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch