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

From: Mayer Georg <[email-masked]>
Date: Wed, 6 Mar 2002 17:33:54 +0100

Hello Juha,

thanks for the answer.

> 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).

I need to understand where you think this major break in architecture occurs. 

Look at the 3GPP UMTS architecture. There is the PS domain (packet switched) and WITHIN it is the IMS. 

If the user wants to have normal SIP services, without using all that fancy stuff that she can get from the home.net: fine! So no contradiction with SIP protocol architecture. You can do basic SIP with 3GPP - just take a client, start it and everything works. That will be so already in "older" releases, i.e. pre-IMS. Perfect. Can we agree that this is not a contradiction to SIP?

If the user wants these special services then the registration is needed. I thought we had discussed this already before, in and after SLC and got the feeling that this is not regarded as a (major or any) break of the SIP protocol architecture. It is just using the modular concept of SIP messages - use REGISTER in order to register at the Registrar and the Registrar then can do some further interesting things (like finding application servers due to user profile ....). This is even necessary when the Path header does not exist. So do we have a break here? If yes ... W-h-y-? Look at the paragraph above - you always can do all the basic SIP stuff without having REGISTER mandatory for callees. 

And now we come to the Path header. The system learns the path from the user to the Registrar and back. There were comments some months ago that path would only "record" a partial route and this could not be put to the Route header of the initial INVITE. Then we got loose routing, which allowed proxies to add intermediate hops to the route (exactly what we needed). As I understood it this solved the problems that IETF SIP(PING) experts had with the Path header. So is this the break?

Please help me to understand the major issue here - maybe we can then find a solution or a miss-interpretation. 

Thank you
Georg

_______________________________________________________
Georg Mayer - Siemens AG
Information and Communication Mobile
ICM N PG SP ST N 1
Hofmannstr. 51, 81359 Munich, Germany
Fon: +49-89-722-33114
Fax: +49-89-722-62250
Mobile: +49-172-5371233
Email: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Mittwoch, 6. März 2002 12:43
> An: Mayer Georg
> Cc: Dean Willis; Mark Watson; [email-masked]
> Betreff: 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:26:09 +0200

Please help me to understand the major issue here - maybe we can then
  find a solution or a miss-interpretation.

georg,

i welcome you as a new member of the 3gpp ims tag team.  i start get
bored to repeat the same issues in each message, but i'll try once more.

the major problem with the path header is that it breaks the currently
defined semantics of the register message.  in the rfc and in the bis,
register message has been defined for establishing a binding in the
location service and for no other purpose. according to the current sip
specifications, you only need to send a register request if you want to
be reached.  if you only want to reach others, you don't need to send
the register message.  all that text of the rfc and bis would need to be
changed if we would adopt the proposed path response as part of sip.

also, the current rfc and bis tell how and to where the ua sends a
non-invite request.  also all that text would need to be changed to take
into account the case where the ua has registered itself and received
back a path (which current UAs would not even understand).

but it is not just the question of changing the text.  i don't want the
sip protocol architecture to be changed in such a way that a user has to
register in order to be able to send non-invite requests.  the user must
be able to know to where and how to send non-invite requests without the
information it gets back from the register message.  in other words,
discovery of the route to the destination ua cannot be bundled to the
registration process.  we must have other means to accomplish it and the
current ones have been specified in the rfc and in the bis and in the
srv i-d.

so my suggestion to you is that if a 3gpp ims ua really needs the path
information before it can send a non-register request, you define the
path header as a 3gpp proprietary header in your own documents.

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.

-- juha