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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 27 Aug 2001 21:19:56 +0100

See inline

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

> ----------
> From: 	Dean Willis[SMTP:[email-masked]]
> Sent: 	17 August 2001 17:24
> To: 	Drage, Keith (Keith)
> Cc: 	Henning Schulzrinne; Sipping (E-mail)
> Subject: 	Re: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy	?
> 
> 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.
> 
Sorry. but while the RFC and the draft specify means for extensions to be
made to the syntax in a body outside IETF, then the end result will still be
SIP. Compatibility mechanisms, as defined in ITU-T Recommendation Q.1400,
are meant to ensure that interoperability is still possible if the extension
is not supported by one side. If the result is not meant to be SIP, then all
discussion of IANA registration and the associated extension mechanisms
needs to be taken out of the drafts, as the drafts define what SIP is.

Note: I do also accept that the best extension is one that is widely
implemented, and IETF is the place to ensure that that takes place in SIP.

> 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.
> 
I do not believe I said Path was a requirement, it is however the current
accepted solution. I did also say that if a solution came along that fitted
the requirements, which are demonstrated in TS23.228, then we would look on
that. I would point out that we have investigated seriously all the
alternative solutions that have been put on the table in 3GPP, and so far
found problems with them all.

> 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.
> 
As I have not seen the notes, and did not attend the ad-hoc session, I
cannot yet comment.

> 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
> 
> 
> Drage, Keith (Keith) wrote:
> 
> > 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
> > 
> 
> 
> 
> _______________________________________________
> 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: Tue, 28 Aug 2001 13:20:01 -0500

> As I have not seen the notes, and did not attend the ad-hoc session, I

Cullen's notes are posted at:

http://www.softarmor.com/sipwg/meets/ietf51/minutes/privacy-nonlocal.html

along with other notes from the meetings at IETF51.

--
Dean