Subject: Re: [SIP] Identification problem

From: Bertil Engelholm <[email-masked]>
Date: Mon, 13 Nov 2000 10:11:58 +0100

Jo Hornsby wrote:
> 
> 
> If, OTOH, we are looking at backwards-compatibility from a "work
> with existing SIP Implementations" standpoint, then I have to say
> that so much of Record-Route wouldn't have worked anyway (the
> spec says nothing about building Route:s in the callee -> caller
> direction), is it really worth worrying?
> 
> With this approach, we can write into bis, say, that the called
> UA, when forming requests, renames all "uri" parameters to
> "original-uri"; and appends a new "uri" parameter with the value
> of the Contact:/From:.
> 
> We now have the resilience that Jonathan was addressing (thread:
> "failure of proxy), since each proxy along the Route can see
> the final destination.  And also, if the request spiralled,
> we know where on the Route we are (since we have retained the
> original Request-URIs, too).
> 
> Now I know that this is a significant change, but as far as I can
> tell, realistically, no proxy will as yet have been able to
> Record-Route properly and/or remain call stateful, because we
> are still finding bugs.  Thus it doesn't seem as if there can be
> real objections to making such a changes, since hopefully they
> are changes towards having a fully-working mechanism (okay, I
> guess we think it works now, but it can't be more than 3 months
> since we spotted that Record-Route: can break in the reverse
> direction when a request has spiralled; how mature can
> implementations possibly be?)
> 

I thought I were the only one having these thoughts. This is
the reason why I started to suggest simplifications to SIP some
months ago. It was quite obvious that the protocol was not
complete at that time (it's not even complete today). So
to argue that a specification that is not complete and still
contain major bugs have to be backwards compatible is very 
strange to me. But I guess I have to live with that ??

The kind of solution I would like to have to this problem is
a change of the ROUTE behaviour so it behaves like VIA i.e.
you remove your "own" entry from the list instead of removing
the next servers entry. In this way it would be possible to
add any RECORD-ROUTE parameter and get it back later in ROUTE 
(if the client copies the whole RECORD-ROUTE into ROUTE). This
would make the state draft obsolete and it would also solve
my problem with identifying the call state machine. Since
this change is a pure semantic change I see no reason why
it can't be done like this ;-). 

The only syntax change needed is to add a 'hostport' 
parameter to RECORD-ROUTE instead of maddr as Jonathan
pointed out. Since this is needed for TEL-URI etc. this
parameter has to be added but I would prefere to ALWAYS 
use this new parameter instead of sometimes using maddr.
 
/Bertil

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 13 Nov 2000 12:25:43 -0000

> strange to me. But I guess I have to live with that ??

I'm not sure that this is fair.  The protocol may fall slightly
short of being complete even today (although I might argue that
it is more our understanding that is uncomplete; the protocol
_may_ be spot on already), but where does the "major bugs" come
from?

> it can't be done like this ;-). 

I don't buy this at all.  And championing it on the basis that
it's purely a semantic change seems a little weak, at best.

In fact, I would argue that such a potentially subtle change
(older implementations would think they were doing the Right
Thing, while devices downstream would be suffering major
lossage) is dangerous.  I would consider it preferable to
do something like inventing Record-Route2:/Route2:, since
then at least the intent is clear all the way, 2543 or no.
(Please note that I'm not proposing we do this.)

> use this new parameter instead of sometimes using maddr.

Unfortunately, this is not backwards compatible, whereas
what I proposed -- if one is generous -- was completely
backwards compatible.  (Technically, I think it conflicts
with the bis drafts, but that is all?)

To be honest, I've been slightly disappointed with the
lack of response to my original suggestion; inflamatory or
otherwise.  I would have thought it was controversial
enough to merit a medium-sized fire extinguisher at the
very least. &:)

I think (please do correct if I wrong) that my solution
potentially addressed all the problems in and around
this thread; it even left the way open for state to be
stored in the Request-URIs (I would prefer to see the
State header used for this, but obviously there is then
an issue of what to do if a UA don't support it).

It'd be nice if we could try and get this nailed down
once and for all[0] before the Bake-Off, whichever hammer
we use.  That way, we can all offer up our bleeding-edge
I-knocked-it-up-during-the-flight-over-here implementations
there and then, and prove it works (or doesn't, as the
case may be).  I'm sure a "simple" scenario involving
a single spiral would suffice...

Cheers,

 - Jo.

[0] Until we realise the next bug, of course. &:)