[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Iptel] Re: Review of draft-antti-rfc2806bis-08 - The tel URIfor Telephone Calls

Conroy, Lawrence (SMTP) wrote:

2) final sub-point: Perhaps "resource associated with a telephone number" might
be less easily confused with telephone numbers as a resource? (I've read too
many SG2//SPAN//... documents :).
where? "resources identified by a phone number" seems clear enough.

7) I disagree. The program on my PC knows the context in which it works; if I
select a number from my address book it will detect where this involves
a call external to the ISPBX and will process this to include the "public
escape digit", in our case "9". This is passed via ISDN signalling to the
ISPBX from the ISDN phone that is in turn driven by the program. This is
a dialer application, as it DOES have to deal with dialing plans - my
address book doesn't, and the phone doesn't. I think that this is an
immediate counter-example, so I'd suggest that it is left as is in -08.
Please look at the wording of http://www1.cs.columbia.edu/sip/drafts/draft-ietf-iptel-rfc2806bis-01.txt to see if this is acceptable.


8)  I took the parenthetical clause to mean DID or MSN/partial number or
    sub-addressing service. Whilst we COULD spell out all of the options,
    the use of "DID" (DDI over here) to encompass all of these services
    seems better, IMHO.
I've simply omitted this since 'tel' does support extensions and sub-addresses. Again, please see the new text.

9)  Oops - what was this section meant to cover?

What's now in the tel-for-SIP appendix.

10) Big point:: If this is the sense of the group, then I'll live with it.
However, I don't like it at all, as it is perfectly possible to identify
a number of contexts in which an address resolves to the same termination
point (usually to a call centre somewhere in India). Programming the same
drop point for the "same" number used in different countries/contexts does
happen, so whilst this is by no means always the case, this doesn't mean
that it never happens. Multiple contexts can be valid for a given number,
IMHO, so I don't think we should ban them.
The perception was that it would be tedious to identify all the contexts and that in some circumstances, it would be better to designate a new context that encompasses several individual ones. I'm agnostic on this one, but this has to be resolved one way or the other. I'm having a hard time seeing where such multiple contexts would appear. They clearly won't appear in the phone-puts-numbers-in-URI case. A web page or directory seem about the only case, and seem rare even there. Even if the number is the same, listing a few instances like

dial tel:1234;context=+1 in the UA
dial tel:1234;context=+49 in Germany

seems good enough.

In most cases, it seems that the number, while valid in multiple contexts, only needs to be made unambiguous by labeling it with one.


12) I agree with you both - I don't see how we can avoid prohibiting ISUP
    non-decadic signals (useful for some private systems) whilst blocking
    the non-decadic dialed digits, so I guess we have to leave it as is -
    I take the last sentence to discourage their use anyway.
I don't think they are going to be common and the people that really, really need them will hopefully know what to do with them.

13) That's why it's a SHOULD rather than a MUST; how does this proposed
    additional text help? Please can we leave this as is (it has been
    through enough iterations already :).




17) only if we want a circular reference :)



RFC 3261 does explain the syntax.






18) Absolutely agree with this - unfortunately, it clashes with reality 
right now :(



Perhaps we should put in a sentence to clarify that:



    "This basic approach is can be onerous, in that the OBP may maintain 
a number

    of different contexts, and so may be forced to add a phone-context 
appropriate

    to the private number plan associated with the call to any tel: URI 
it generates,

    interpreting this based either on the identity of the originating 
phone user

    and the number they specify in the call".




Please see new text and suggest improvements if necessary.




all the best,
  Lawrence





_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel