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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 26 Aug 2003 08:34:17 -0400

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
gateway processing section that interprets a set of rules to
expand the user name into a url.  We use this capability in
many interesting ways.  For example, you can force routing of a
call to a particular gateway (if site policy permits it).  Typically,
to do this we put some alpha prefix on the number. Thus:
sip:[email-masked];user=phone means that the call
will be passed to the Pittsburgh PBX gateway calling extension 4826.  
You could get to the same phone by dialing 
sip:[email-masked];user=phone, but that may route a different 
way (for example, it could be routed to a local gateway, to the 
local PBX, and then over a tie line between the local PBX and the 
Pittsburgh PBX).  We do this by creating rules in the ruleset
that match the pitpbx prefix.  We have a matching regexp and a
replacement regexp, so that a general purpose substitution is
possible (the actual expansion of the example would be
sip:[email-masked]).

If you tried calling sip:pitpbx4826 without the user=phone, we would
try to find a user named pitbbx4826 in our registrar's database.

Brian

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Monday, August 25, 2003 2:49 PM
> To: [email-masked]
> Subject: Re: AW: [Sip] SIPIT Interop problem with ;user=phone
> 
> 
> 
> sip:[email-masked] means send it to foo.com and foo will figure it out.
> 
> sip:[email-masked];user=phone means send to to foo.com and foo 
> will figure it
> out. 
> 
> Right now it is totally random if the UA puts in the 
> user=phone or not and
> the proxies (as far as I can tell) mostly ignore it. I'm 
> having a hard time
> figuring out what the requirement is for this extra 1 bit of 
> information
> that currently has no semantic meaning. There is a certain amount of
> operational experience that indicates this flag is not needed.
> 
> I think the whole thing is bogus unless someone can clearly state a
> requirement that says why the proxy might need to know some 
> extra bit of
> information and clearly says how the UA would set this bit of 
> information
> based on something the user entered on the UA.
> 
> Defining something that all UAs will set to the same value or 
> all proxies
> will ignore is useless.
> 
> Cullen
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Tue, 26 Aug 2003 16:02:53 -0700

The Cisco proxy can be configured several different ways but at best the
user=phone flag ends up being a hint to what to try first - in all the
deployed cases I have can think of, checking the registry first then if that
fails going to the dial plan seemed like it would work.

The real problem is on the UAS. Does the digit map/dial plan or whatever it
is called have entries in it that indicate some strings of digits dialed by
users will get user=phone and other won't? Is there some other way for the
human dialing the UA to indicate what should happen? Unless this gets really
well specified and everyone supports it, I'm not sure any of this is going
to help much. 

Anyway, I think the problem is that it is not clear what the requirements
are for this flag. 
 
Cullen

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 27 Aug 2003 08:27:48 +0300

Rosen, Brian writes:

 > Pittsburgh PBX).  

why can't your proxy check if the number begins with 300 and then route
the call the same way it now routes a pitpbx call?  who is adding pitpbx
in front of the number?

-- juha

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Aug 2003 09:21:18 -0700

The more this conversation goes on, the more it looks like people are using
this flag in an implementation specific way and it currently has no
specified meaning.

On 8/27/03 8:25, "Dean Willis" <[email-masked]> wrote:

> On Tue, 2003-08-26 at 07:34, Rosen, Brian wrote:
> 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
> 
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 Aug 2003 10:25:43 -0500

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 Aug 2003 17:00:43 -0500

> local PBX, and then over a tie line between the local PBX and the 

My goodness, that is different. While it is a very reasonable "user
part", I would not have considered "pitpbx4826" a dial string, and my
first hunch would be that it's simply invalid when combined with
user=phone. (it probably isn't which means we DO have a spec clarity
problem). I would have been much more likely to encode this as
sip:[email-masked], which means to me "whatever 4826 means to
pitpbx.marconi.com", which is what I think you wanted to express.

It might be reasonable for proxy "marconi.com" to route (this is
expressible in TRIP) all digit sequences starting with 300 to
pitpbx.marconi.com, and potentially even strip off the matched digits so
there's no uncertainty at pitpbx. Going this way lets you make a dynamic
route-optimization decision at the proxy as to whether it would be more
efficient to route via PSTN. In any case, it lets one use
[email-masked], again with no user=phone.

I think you've gone down a very different design path that requires a
heck of a lot more work in setting up gateways and intelligence for
string-manipulation in those gateways than might have been required by
other design paths. It'll work, sort of, with the right equipment, but
seems overly complex.

Maybe it's time to write a book about how to build
usable/useful/maintainable SIP networks for the enterprise?

Remember: failures induced by convoluted implementations do not
necessarily entail a design flaw in the components used in that
implementation. Or, as I like to say, baroque is probably broken.

--
Dean