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

From: "Mark Watson"<[email-masked]>
Date: Wed, 6 Mar 2002 17:29:02 -0000

Juha,

If I understand rightly, your 'architectural' objection is to the use of
Register for something related to outbound service - the principle you would
like upheld being that Registration is a function related only to inbound
service. Right ?

If so, I think you are way way too late - 3GGP use of Register does all
sorts of things related to outbound service already: choice of Service CSCF
(home proxy), setting up of registration state in S-CSCF & HSS (subscription
database), authentication & determination of session keys, etc. etc.

As Georg mentions in his other post, this was all discussed some time ago (I
remember a long thread about authentication being done only at Registration
with subsequent messages relying on the session keys obtained at
registration). In the 3GPP IMS you cannot send any messages at all (except
REGISTER) until you have registered.

So, without revisiting this point (i.e. accepting that, in 3GGP at least,
Register is not related only to inbound service), what is your objection to
the Path proposal for discovery of the service route for outbound calls ?

I see you arguing about the technical merits of different solutions to
discovery of a service route for outbound calls (i.e. using DHCP & DNS), but
this is surely a technical argument, not an architectural one, and there
does not seem to be any consensus that DHCP & DNS can do the things that
Path is proposed for.

Regards...Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 06 March 2002 11:43
> To: Mayer Georg
> Cc: Dean Willis; Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
> Subject: AW: [Sip] Path to Working Group Item
> 
> 
> Mayer Georg writes:
> 
>  Our aim was not to pollute any area of serious work and I am sorry if
>  you got that impression - we are happy that SIP and SIPPING groups
>  undertook and still undertake major efforts to enable also 
> the specific
>  3GPP requirements. The 3GPP IMS uses SIP in a specific way, as a
>  private network uses SIP in a different way, etc..
> 
> enabling specific 3gpp ims requirements in ietf sip specifications is
> fine as long as the requirements don't contradict with the 
> sip protocol
> architecture.  the path header proposal unfortunately does so and
> therefore there is no way it can accepted.  you simply can't add the
> path header to sip without a major rewrite of the existing sip
> specifications (the rfc and the bis).
> 
> -- juha
> 
> 
> _______________________________________________
> 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: Wed, 6 Mar 2002 19:50:05 +0200

> like upheld being that Registration is a function related only to inbound

yes, see the message that i sent a few minutes ago.  i don't want have
time to repeat it.

 > database), authentication & determination of session keys, etc. etc.

that is fine.  i have no intention to try to change how 3gpp ims
operates.  i send a few notes what i don't like about it, but i
understand that you have long time ago decided on the walled garden
architecture and will not open it up.  what you decide in 3gpp ims,
doesn't however have no implications on the ietf sip architecture. so
please don't try to bring the walled garden model also to ietf.

 > the Path proposal for discovery of the service route for outbound calls ?

as long as you don't try to change existing ietf sip protocol
architecture and keep the path for yourself, i could not care less about
it.

 > does not seem to be any consensus that DHCP & DNS can do the things that

dhcp and srv records happen to be the ietf way of doing discovery.
there is ietf consensus and working group documents about it.  before
that consensus is changed or augmented, it is your task to show what is
wrong with procedure that i outlined in the previous message and that i
have copied below.  

and even if we assume that you are able to find a real flaw in how i
proposed to solve YOUR discovery problem with existing means, the fix is
not to add anything to the register process, because as i have said soon
thousand times, a sip user must be able to do the discovery without
registration, which is only used in sip if someone want to receive
inbound requests.

-- juha
------------------------------------------
by the way, no one in your tag team has yet been able to provide a
convincing reason why even a 3gpp ua ua would need the path information.
as we know, the ua can always get its requests to its home proxy by
using the outbound proxy of the visited network and optionally a loose
source route to the home proxy that it can find from the dns.  then the
entry proxy of the home network can (based on local subscriber
information) forward the request to whatever internal proxy is needed to
handle it.  the entry proxy, by the way, doesn't need to record route
itself, which means that only the initial message of each dialog would
need to go via it.

so my second suggestion is that unless you can show some fundamental
flaw in the above process, you stop crying after the path response on
this mailing list.