Subject: RE: [Sip] Path to Working Group Item

From: "Mark Watson"<[email-masked]>
Date: Tue, 5 Mar 2002 13:57:12 -0000

I would support this becoming a WG item.

Juha seemed to be suggesting that Record-Route could be introduced to
Register instead, but the semantics do seem slightly different to me (I
thought Record-Route established a route for the duration of the dialog, but
Registers don't set up a dialog). Plus the symmetry difference.

So, I'd prefer to see the Path proposal go forwards.

Regards...Mark

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: 01 March 2002 23:08
> To: [email-masked]'
> Subject: [Sip] Path to Working Group Item
> 
> 
> There has been considerable discussion on the PATH header on the list
> indicating more than significant interest to consider it a working 
> group item.  Are there any objections?
> 
> Brian
> 
> _______________________________________________
> 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: [email-masked]
Date: Tue, 5 Mar 2002 16:53:57 +0200

> So, I'd prefer to see the Path proposal go forwards.

the path proposal includes much more than fulfilling the valid
requirement, i.e., learning the path to the registered user.  if you
want to call the header path instead of record-route, that is not a big
deal to me, but those parts of the path proposal that break the sip
protocol architecture are.  

in sip, register request accomplishes one and only one thing: lets
others to learn that i'm available for calls and how their calls can
reach me.  the path proposal on the table is changing that in a
fundamental way by establishing to the registering party a service route
that it should be using when it makes calls.  that part of the proposal
breaks the sip protocol architecture and is thus unacceptable.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 5 Mar 2002 11:51:00 -0600

> breaks the sip protocol architecture and is thus unacceptable.

Are you saying that it is in general unacceptable to use proxies to provide
value-added services for outbound calls? I'd find that a hard position to
support, as one of the big advantages claimed for SIP has been its ability
to enable value-added services for both inbound and outbound calls. I give
some examples in another post on this topic. So it's just a question of
figuring out where to get those outbound services from . . .

The Path proposal doesn't (or at least shouldn't, if it does let's correct
the wording ) REQUIRE that the UA exclusivelt use a specific technique to
discover an exclusive service proxy. It simply provides an option for doing
so. I'd argue that this approach MAY inform the registering party of a
service route that MAY be used to get to to certain services. There MAY be
other mechanisms available to convey this information as well -- this draft
certainly doesn't claim to be the ONLY way to do this.

Now certain operators in certain networks providing phones to certain users
MAY set the phones up to where such usage is the default condition, but that
doesn't violate any architectural principle any more than does giving away
free browsers that have Yahoo set as their home page. Operators are free to
shoot themselves in both feet if they want to, and I'm sure many will do so
repeatedly . . . fortunately, others MAY not.

--
Dean

---

From: [email-masked]
Date: Tue, 5 Mar 2002 21:10:07 +0200

Dean Willis writes:

 > value-added services for outbound calls? 

no, i don't object to that, but that information has nothing to do with
register message, whose function is to let others to reach the
registering party.

 > So it's just a question of

sip uses dns for that purpose, not something piggy packed to register
message, whose purpose has nothing to do with outbound calls and that a
sip ua doesn't even need to send in order to make outbound calls.  in
sip we simply can't have a service that an ua is not able to locate
unless it first registers itself.  that kind of requirement totally
break the sip protocol architecture.

if you are not happy with dns for locating services, you can in the 3gpp
group either invent another sip message for that purpose.

 > so. 

what kind of option is that a 3gpp ua can't make any calls without first
registering itself and if it does register itself, gets back a service
route that is must use in order to make those calls.  i don't see any
optionality in that.

-- juha