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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Aug 2003 11:37:14 -0400

We have gateways that do that.  It works fine because
a real phone number is a good dial string in most dialing plans, 
and we want to process that call with our dial plan rules.  
Sometimes it isn't, but our routing rules can take the
From as part of the rule so we can fix things like having
a 9 prefix in the dial plan, but the gateway just using
an external E.164.

Our routing rules would process such a call and rewrite
the URI to not have the user=phone and forward it.
Of course, if the forward was to itself it would
then go through its loop again and look it up in
the registration database.

You are the weird one because you have both a phone
and a gateway with the same AOR, unless you are relying
on the gateway not registering as the phone number it
has on its port.  We've seen a gateway that did that.

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Wednesday, August 27, 2003 11:26 AM
> To: Rosen, Brian
> Cc: 'Cullen Jennings'; [email-masked]
> Subject: RE: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> On Tue, 2003-08-26 at 07:34, Rosen, Brian wrote:
> > We might be weird, but lack of user=phone indicates to our proxy
> > that we should look up the user part in our registered user list.
> > Including user=phone means we pass the user string to our
> 
> You're weird ;-). We look up the user part first, becasue 
> guess what --
> SOME gateways slap a user=phone on the end of any call coming 
> from PSTN,
> and I really want to be able to divert that to a SIP UA that isn't a
> PSTN phone but registers with a user-part that looks like a phone
> number.
> 
> How would your system be able to handle that? Insert routing 
> table logic
> in your phone number processing that diverts the call back to a non
> user=phone format and reprocesses it?
> 
> My believf: The only responsible thing to do with a 
> user=phone is ignore
> it.
> 
> --
> Dean
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Wed, 27 Aug 2003 12:32:38 -0500

> has on its port.  We've seen a gateway that did that.

I'm sorry somebody sent you a defective gateway. I hope you were able to
get it fixed.

Gateways, at least multiline gateways, should NEVER EVER register.
That's deeply evil! They get calls from PSTN, turn them into SIP
INVITES, and send them out (ostensibly, to the default proxy). They get
SIP INVITES from their IP side, turn the user part into a phone number,
and signal it out to PSTN. Very simple business. Having gateways
"register" leads to insanity like trying to send a regisration request
for every phone number in the NANP, or in a given area code, or the
like. That's whay we have TRIP, with its prefix-ranges and weights.

A telephone number is not an address of record. It's the user-part of an
address of record and must be evaluated in the context of some domain to
be meaningful. By convention, we assume that a telephone number having a
leading + is evaluated in the E.164 domain context. It doesn't really
have to be (not a MUST), but it's a useful convention. Anything else, we
have to "guess at" the context, unless the context is specifically
stated in the right-hand-side production of a SIP(S) URI.

The user=phone parameter was meant as a hint to help guess the
evaluation context. The original argumentation for it was that
user=phone would help disambiguate a case where there were cearly two
different AORs with the same "user part" in a given domain -- a case
that I don't believe we've found to exist. In some environments it is
clearly not meaningful. In other environments, it MIGHT be. 

The question: Is the utility of the parameter in those environments
sufficient to justify the complexity that it apparently creates?

--
Dean