Subject: RE: [Sipping] How to Get Outbound Services from A Non-Local Proxy ?

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 17 Aug 2001 14:33:36 +0100

The 3GPP requirement is clear, i.e. that the outbound proxies are identified
at registration time to the UAs default proxy and vice versa. I believe that
the reason for this is the one already indicated, which is to reduce the
number of lookups to the 3GPP HSS at session establishment time, thus
cutting out some of the delays in session establishment. Note that at the
same time as this is done, the mechanisms for establishing authentication
and integrity protection between the UE and the P-CSCF/S-CSCF are also
performed, and if we do not do these at registration, they would also have
to be performed at session establishment.

The current proposed method for doing this is to invent a new header called
path. Having looked at ways of making this more general purpose, the
specification of this got very complex. Therefore the view being taken in
3GPP is that the documentation of this would be left 3GPP specific (i.e.
outside IETF). The mechanism by which it works is shown in slide 14 of my
presentation to the SIPPING working group in London - see SIPPING additional
web site for this.

This mechanism only involves the P-CSCF (default proxy), the I-CSCF (1st
outbound proxy) and the S-CSCF (2nd outbound proxy). It does not involve the
UA.

We have looked at other mechanisms, but nobody has yet come up with a
mechanism that looks clean for two outbound proxies. Every proposal so far
seems to have had some sort of kludge.

At the end of the day, the SIP mechanism 3GPP uses to solve this is open to
change, and I would be perfectly happy to adopt something providing it can
be shown to work as well as new 3GPP specific header. We are not yet in that
attractive position.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Dean Willis[SMTP:[email-masked]]
> Sent: 	09 August 2001 14:27
> To: 	Henning Schulzrinne; Sipping (E-mail)
> Subject: 	Re: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy?
> 
> 
> Yep. Same problem.
> 
> In the current 3GPP work, a Path: header is used to accumulate route
> information duriing REGISTER. It's sort of like record-routing REGISTER.
> 
> The resultant route information is stored, with on the phone or its
> default
> proxy (I've heard conflicting reports here), and is inserted into Route:
> headers on appropriate messages emitted by the node that stored the PATH.
> 
> This has the effect of source-routing all mobile-originated INVITEs
> through
> exactly the same route that was traversed by REGISTER.
> 
> My feeling is that this is an awfully heavy and restrictive technique to
> apply in order to get outbound services from a non-local proxy. It induces
> many side-effects, such as requiring a registration in order to place
> calls.
> 
> 3GPP has carried this even further by assuming that since REGISTERS are
> authenticated and the signaling channel may be integrity protected at
> layer
> 2 that there is no need to perform authentication of INVITES, but that's
> another can of worms.
> 
> --
> Dean
> 
> ----- Original Message -----
> From: "Henning Schulzrinne" <[email-masked]>
> To: <[email-masked]>
> Cc: "Sipping (E-mail)" <[email-masked]>
> Sent: Monday, August 06, 2001 7:07 PM
> Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy?
> 
> 
> > Rumor has it that 3GPP is planning to 'enhance' SIP by a header called
> > Path. It might be helpful if the 3GPP experts could indicate whether
> > this is the same problem.
> >
> > Eric Burger wrote:
> > >
> > > I guess the bang reminded me why I didn't want to hack the Request-URI
> in
> > > the first place.
> > >
> > > I will readily concede that
> sip:[email-masked]
> > > will work if myproxy.com understands to parse the RHS and continue
> routing,
> > > and that sip:[email-masked];user=url will
> always
> > > work.
> > >
> > > However...
> > >
> > > We seem to really be mixing the meaning of a Request-URI.  I think
> that's
> > > why we're getting such push-back and counter-suggestions like
> preloading
> > > Route (won't work), maddr (works sometimes), etc.
> 
> 
> 
> _______________________________________________
> Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Aug 2001 11:24:05 -0500

Two points:

1) The message from IESG is clear -- 3GPP specific extensions will not 
be tolerated by IESG, especially if those extensions break 
interoperability with standard SIP systems. Of course, anyone is free to 
build a proprietary protocol. They just can't all it SIP, claim that it 
is an Internet protocol, or reference an RFC which defines that 
protocol. Interoperability is of penultimate importance.

2) The Path header approach is NOT A REQUIREMENT. It is a PROPOSED 
SOLUTION associated with an set of requirements which have not been 
explicitly stated -- so perhaps determining the requirements, and 
generalizing them would give us a mechanism for evaluating proposed 
solutions.

3) SIPPING as a group may NOT define SIP extensions. However, it can 
develop requirements for consideration by the SIP working group.

We held an adhoc on outbound services at the recent IETF meeting. In 
that discussion, we derived several reasonable-looking requirements. We 
can go into those in greater detail once the meeting notes come back to 
me from the recorder, but as I recall, they were: 1) The ability to 
request that a message traverse a sequence of nodes (a vector) before 
being delivered to the target specified in the original Request-URI, 
with the nodes in the sequence not necessarily contiguous, 2) The 
ability for the vector to be attached or altered the UAs or  visited 
proxies as needed by specific implementations, 3) That the path taken by 
the INVITE not be restricted to specific congruence with the path taken 
by the REGISTER (Bill asserted that the S-CSCF might want to perform 
some sort of magic route optimizatin calculation), 4) That there be some 
means of dynamically informing the node which adds the vector of what 
that vector should be, in the specific case where the vector is used to 
find a "home proxy".

In general, we found requirement 4 to be completely seperable from 1, 2, 
and 3 -- it's a "different problem".

Path, Record-Route, and REGISTER form a proposed solution which is under 
consideration. There are obvious issues with some of the details of 
requirements 1, 2, and 3 listed above, but it's a valid starting point. 
Path specifically addresses most of requirement 4, and the combined 
proposal uses REGISTER to discover the vector and preloaded Route 
headers to approximate requirements 1 and 2.

We went through a number of call scenarios in the outbound-services 
adhoc meeting (with Bill Marshall participating) and found several cases 
where Path just didn't work. This seems to be resulting from the 
behavior of Route and Record-Route rather than of the Path semantics. In 
essence, it boiled down to the fact that use of Route implies that EVERY 
SIP node in the sequence be both known  before the INVITE and invariant 
across the call duration (actually, across the duration of REGISTER). 
Given the dynamicity of network topology, that's not a good thing in 
general.

This indicates a need for a new "loose source routing" model to 
accomodate the general case. We came up with a general 
loose-source-routing mechanism that appears to allow the satisfying of 
requirements 1, 2, and 3, and possibly has a fourth feature of allowing 
mixed strict and loose Routes.

Going forward, I suggest we do two things:

1) Create a submission to SIPPING explicitly defining the requirements 
for a general solution to the outbound-services problem.

2) Work with SIP to define appropriate mechnaisms. We left the 
ad-hocwith a todo assigned to Jonathan -- verifying whether the Route 
syntac in RFC2543 provides for a way to do a "loose route" modifier on a 
Route element.

--

Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Aug 2001 12:18:30 -0700

I think it would be helpful to enumerate the options systematically and
then see where they fall short. Some building blocks we have include:

- using DHCP for obtaining the local (visited network) proxy
- using naming (i.e., the user's canonical SIP name) to obtain the
user's home network proxy
- the two state and cookie header proposals

There are really two pieces here that cause concern:
(1) the necessity for registration prior to sending an INVITE; it would
be nice if the first INVITE, for example, could effect authentication,
with caching across subsequent messages.

(2) the addition of a new Path header.

> at registration time to the UAs default proxy and vice versa. I believe that

Why does this have to be at SIP REGISTER time (to be more precise than
'registration time')?

> cutting out some of the delays in session establishment. Note that at the

Since the time to visit the HSS is all high-speed Internet if
proxy-authentication is used, this additional time should be on the
order of 100 ms (one RTT), even if the HSS is on the other side of the
planet.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 19 Aug 2001 19:31:01 +0300

> order of 100 ms (one RTT), even if the HSS is on the other side of the

I will add one more thing. 3GPP call flows already include a query from the I-CSCF 
to the HSS in the "terminating" side of the call leg. What some people have been
proposing to 3GPP is to have the same query in the "originating" side of the call
leg. This will make things easier to solve the problem. If a query is not a real
problem in the terminating side, it shouldn't be a problem in the originating side.

On the other hand, we are considering a query from two nodes located in the same
network domain. I doubt they will be located two far away (perhaps they are even 
located in the same room). What I want to stress is that we can safely consider
the propagation delay as negligible.

/Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002