Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Sep 2003 13:36:07 -0400

I don't have much problem putting a dial string in a tel uri
except for the words that seem to me to indicate that it's
not allowed.  I actually argued with Henning et al to explicitly
allow a dial string, but they thought it was too much of
a quagmire.  I would prefer to have a rule/convention/whatever
that differentiated a dialstring from a phone number, but I
actually can't think of any case where there is an overlap
(that is, where a dial string in a context could be a 
number in the same context but not the same destination).

It would seem to me, however, that given the words in 
2806bis, it has to change, or an RFC has to be created that
allows dial strings in a tel uri.  I don't think you can finesse
it any other way.

Do you agree that there is a need to distinguish a translated
tel uri (which would be a sip uri which may have a numeric username)
from a dialstring or an untranslated number?  How would you
propose to do that?

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 1:21 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> 
> Rosen, Brian wrote:
> > What part of:
> > 
> > "Dial strings are beyond the scope of this document."
> > is not clear?
> 
> To me, "out of scope" is different than "can't be used for". 
> (It is akin 
> to the off-label use of drugs - for purposes other than what they are 
> marketed for.)
> 
> So, if I can describe a phone context in which dial strings can be 
> considered to be phone numbers, then I can encode dial 
> strings that way.
> 
> If necessary, we could write a separate draft that explicitly 
> describes 
> doing so. I don't think it is necessary - it is up to the phone to 
> decide how to map dial strings into numbers. If it happens to 
> do so by 
> simply attaching a phone context to the dial string then that is its 
> business.
> 
> This is just a degenerate case of the phone containing a dial plan.
> 
> > cf draft-ietf-iptel-rfc2806bis-02
> > 
> >    There are at least two ways one can envision making a telephone
> >    connection. In the first approach, a URI contains the 
> dial string,
> >    which is then passed to an entity that can reproduce the actions
> >    ...
> > 
> >    Another approach has the URI specify the telephone 
> number, which can
> >    be either globally unique or only be valid within a 
> local context.
> >    ... The document below assumes the second model.  
> > 
> > I think it is crystal clear that a 2806bis compliant UA cannot
> > put a dial string in a tel uri. 
> 
> Can you describe to me what sorts of transformations to the 
> dial string 
> are acceptable for inclusion in a tel uri, vs those that are not?
> 
> Apparently you think the null transformation isn't 
> acceptable. What if I 
> put a "." in front of the dial string? Would that make you 
> feel better?
> 
>  > That was the intention.
> > The folks in iptel who wrote that seemed quite clear that 
> dial strings
> > were a quagmire that they didn't want to walk in, and they defined
> > a tel uri as not containing a dial string.
> 
> Local numbers with contexts are also a quagmire that they did 
> walk into. 
> What I am suggesting simply leverages that in what I am arguing is a 
> compliant way.
> 
> > That's okay, but we need a way to pass a dial string, and know
> > it's a dial string, in a sip uri.
> 
> What I am suggesting requires no changes, and allows those 
> who need to 
> know with a way to distinguish dial strings.
> 
> 	Paul
> 
> P.S. What I am suggesting requires use of a phone-context 
> within which a 
> valid dial string has an unambiguous meaning. But this can always be 
> accomplished. If need be, the UAC can use its own FQDN as the 
> phone-context, so that everything including its own private 
> speed dial 
> numbers have unique definitions. So I might have something like:
> 
> 	INVITE tel:*3;phone-context=myphone.acme.com
> 	To: tel:*3;phone-context=myphone.acme.com
> 	From: sip:[email-masked]
> 	Route: sip:proxy.acme.com;lr
> 
> This would go off to proxy.acme.com, which would apply the 
> dial plan for 
> myphone.acme.com. It would look up my private definition for *3 and 
> substitute it.
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Sep 2003 17:25:59 -0400

Rosen, Brian wrote:
> not allowed. 

As I said in prior message, I don't think 2806bis disallows this - it 
only declares it out of scope. Putting it back in scope could be done by 
another draft, but I also think it can be put in scope by policy of an 
endpoint without violating the letter of the draft.

 > I actually argued with Henning et al to explicitly

Again, as I said in prior message, I think this can simply be an issue 
for the owners of the context to resolve:

- If there is some conflict between the format of dial strings and the 
translated results, then the node doing the translation should change 
the context in the translation.

- If there is no conflict between dial strings and the translated 
results, then the translator can leave the context unchanged.

> allows dial strings in a tel uri.  I don't think you can finesse

I am trying. Maybe you don't agree my finesse is valid, but you didn't 
answer my questions that were intended to highlight the finesse:

 >>dial string are acceptable for inclusion in a tel uri, vs those that
 >>are not?
 >>
 >>Apparently you think the null transformation isn't acceptable.
 >>What if I put a "." in front of the dial string? Would that make you
 >>feel better?

> from a dialstring or an untranslated number?  How would you

I agree that any node which understands the phone context must be able 
to make this distinction if it matters. (It doesn't always matter, if 
translation is idempotent.)

I would propose to do that by having the node doing the translation 
change the context, from one that indicates dial strings requiring 
translation to one indicating translated numbers not requiring further 
translation.

Note that a translation that yields a global number will remove the 
context, which serves the purpose.

So, some contexts identify dial strings, some don't. The nodes that 
understand the context can know which it is. This is just one aspect of 
understanding the context.

	Paul