Subject: RE: [SIP] transaction identification

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 4 Sep 2000 19:31:50 -0700

Bertil,

There's a difference between removing marginally useless headers/features
and changing the whole protocol syntax - thereby making the protocol no
longer backwards compatible.

There are too many SIP implementations already out there to make these
changes now (even if as implementors we would like to make these
simplifications). 

I beleive the recent discussions about simplifying the SIP syntax were
suggesting that implementations SHOULD generate messages in the canonical
form but still MUST still be able to parse anything (for backwards compat) -
as distinct from removing these annoying elements form the protocol
altogether.

Regards,

Robert. 
 
> > I think we should welcome opportunities to simplify the 
> spec by removing
> > marginally useful features.
> 
> This was exactly what I suggested a few weeks ago. I'm glad that you
> also agree that we should try and remove "unnecessary" things from 
> the specification. The things I beleave is marginally useful features 
> which could be removed is :
> 
> * The compact form.
> * The comma separated lists.
> * Line folding.
> 
> There are also a number of other things I would like to remove
> from the protocol which does not add any functionality what so
> ever to the protocol. I.E :
> 
> * The possibility to add extra spaces basically whereever you like.
> * The possibility to use upper and lower case as you like.
> 
> These things are not that important to remove but since I beleave
> they only add unnecessary complexity without any gain at all I
> would prefer having them removed. 
> 
> /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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Sep 2000 00:36:38 -0400

Neil writes:
> > > What you copy from Record-Route into Route depends on whether
> > > the UA finds the Record-Route in a request or a response.
> > > If it is in a response then it copies the Record-Route into
> > > Route header fields. If it finds it in a request it only copies
> > > the maddr param and any port [bis-01]. The remainder of the
> > > Route name-addr value being taken from the originating
> > > name-addr value, i.e. the Contact or From header.
> > 
> > Well, the name-addr is part of the URI. The question is: what about
> > Record-Route parameters? Seems like these should be copied. The spec
> > should be clarified in that regard.
> 
> I am not sure I follow you. Are you proposing that generic 
> Record-Route params are copied into Route? This wouldn't 
> help as any salient parameters would be lost when the preceding
> Server pops the Route into the Request URI. The spec is already 
> clear about what is copied from where in constructing Route
> when it comes to URI params. But this has it's own problems
> if you are banking on getting any params back from there.
> Which URI would you expect to get it back from as it differs
> depending whether the caller or callee sends the request.

I'm just trying to ensure that we don't lose the possibility of
extensibility.
I understand the issue about not getting these parameters back. But, when
we say in the spec "copy the URI" it should always mean the whole URI.

Shiv writes:
>>
>> Unless there\'s loud protest, it will vanish soon, so speak up if 
>you\'re
>> fond of Via hiding.
>>
>
>I should start by saying I am not fond of Via hiding. It will make me 
>happy if is goes away.
>
>However, I see an overall problem in SIP+SDP as being leaking
>internal network topololgy information. Firewalls go out
>of the way to hide this kind of information, which SIP is giving
>away.
>
>I think a narrow scope of attempting to hide only the topology should 
>suffice. Hiding every hop is probably not necessary. Problem areas 
>should include \'Contact:\' and SDP.

The argument isn't that there is no need to hide topology; the argument is
that via hiding is not achieving this goal. A much better was is through
back to back UAS/UAC that not only strips the Vias, but also hides From,
SDP, and other components that contain even more sensitive information.

Sharath writes:
> Implementing loop detection in *stateless proxies*, is it essential to
> compute the first part of branch id as a hash of To, From, 
> CallID, Cseq in
> addition to RequestURI and topmost Via.
> 
> Is it not sufficient to simply use the request URI and 
> topmost Via alone for
> the hash computation since the other values are not going to 
> change anyway ?
> I am not sure I understand why these fields are being used 
> for the hash
> computation even in the case of stateless proxies.

Yes, I think that would be OK. There is no compelling reason
they are included; its just typical to include them in 
transaction identification computations. 

> The second part of the branch could be computed as the hash 
> of outgoing
> request uri + some server instance ?

No. That won't make it unique across requests in the reverse direction after
a spiral. It would have to also include the topmost Via of the incoming
request.

-Jonathan R.