Subject: RE: [SIP] isomorphic clarification

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2000 04:47:01 -0400

Comments below (keeping full messages to establish some context here; its an
old thread):

> -----Original Message-----
> From: Itamar Gilad [mailto:[email-masked]]
> Sent: Wednesday, August 16, 2000 12:49 PM
> To: 'Henning Schulzrinne'; Jonathan Rosenberg
> Cc: Garret Wilson; SIP List
> Subject: RE: [SIP] isomorphic clarification
> 
> 
> 
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Sat, August 12, 2000 12:53 AM
> > To: Jonathan Rosenberg
> > Cc: Garret Wilson; SIP List
> > Subject: Re: [SIP] isomorphic clarification
> > 
> > 
> > Jonathan Rosenberg wrote:
> > > 
> > > Garret Wilson wrote:
> > > >
> > > > The SIP specification states that, "Two requests or 
> > responses are defined to
> > > > be isomorphic for the purposes
> > > > of this document if they have the same values for the 
> > Call-ID, To, From and
> > > > CSeq header fields."
> > > 
> > > The -01 draft also mentions that the Request URIs must be 
> > identical, to
> > > support spirals.
> > > 
> > > As an additional thing, the *top* Vias must be the same, 
> in order to
> > > detect merged requests. We should add this here and 
> elsewhere in the
> > > document as needed.
> > 
> > Might be good to have an example for this.
> > 
> > > 
> > > You later write:
> > > > I just realized that the latest spec explains how to 
> > compare URIs. The
> > > > question remains that, if two URI's are equal yet not 
> > identical in string
> > > > format, are two From headers (for example) which contain 
> > these two URIs
> > > > considered to have the "same value" as per the definition 
> > of isomorphic?
> > > 
> > > Yes. Two FRoms are equal if (1) their URIs match under URI 
> > comparison,
> > > (2) their From parameters match, based on standard matching 
> > rules for
> > > header parameters (case sensitive equality of both name 
> and value).
> > 
> > Presumably parameters missing in one of the From/To are 
> ignored in the
> > comparison. 
> 
> Not necessarily. I think 'tag' is a special case. In a UAC 
> when checking if
> a 200 response matches an existing call leg you need to be 
> able to compare
> its To: header which has a tag to the To: header of the 
> original INVITE,
> which usually doesn't have a tag, and get the result that the 
> two are the
> same.  I think that this is the reason for the To/From 
> comparison rules that
> disregard a missing tag.  With other (generic-param) 
> parameters this may not
> be the case.  For example:
> 	From: sip:[email-masked];extparam=1
> and 
> 	From: sip:[email-masked]
> 
> may not necessarily be the same.
> 

We aren't talking about matching responses to requests. We're talking about
whether two requests are the same. In that case, the comparison would not
special
case the tags. 

Cliff later writes:
> One possible source of confusion is that the definition of 
> "isomorphic"
> includes both requests and responses, but the RFCbis never 
> uses the word
> "isomorphic" in relation to responses.
> 
> I'm not sure that there is any particular significance to isomorphic
> responses. For example, if the UAS sends a 183 to start an early media
> session, and then sends a second 183 to modify that session, 
> the two 183's
> are isomorphic, but they are not identical and both need to 
> be processed.
> 
> On the other hand, the draft on reliable provisional 
> responses doesn't use
> the word "isomorphic". Perhaps isomorphic reliable 
> provisional responses
> should be defined there, and the definition would need to 
> include matching
> RSeqs.
> 

Although less critical, a definition of isomorphic responses would be nice.
For example, a proxy will retransmit an ACK on a retransmit of a 4xx
response. But, a totally different 4xx response (received as the result of
an error downstream), might cause some kind of error logging or something.

I would guess isomoprhic responses have the same To, From, Call-ID, CSeq,
top Via, and response code.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 18 Sep 2000 11:33:30 +0100

> > "isomorphic" includes both requests and responses, but the
> > RFCbis never uses the word "isomorphic" in relation to
> > responses.
> > 
> > I'm not sure that there is any particular significance to
> > isomorphic responses. For example, if the UAS sends a 183
> > to start an early media session, and then sends a second
> > 183 to modify that session, the two 183's are isomorphic,
> > but they are not identical and both need to  be processed.
> > 
> > On the other hand, the draft on reliable provisional responses
> > doesn't use the word "isomorphic". Perhaps isomorphic reliable
> > provisional responses should be defined there, and the
> > definition would need to include matching RSeqs.
> 
> Although less critical, a definition of isomorphic responses
> would be nice.  For example, a proxy will retransmit an ACK on
> a retransmit of a 4xx response. But, a totally different 4xx
> response (received as the result of an error downstream), might
> cause some kind of error logging or something.
>
> I would guess isomoprhic responses have the same To, From,
> Call-ID, CSeq, top Via, and response code.

Actually, couldn't we make it easier than this?  Since all To s
with different responses should have different tags, couldn't the
"response code" be dropped as a contributing factor?  (The case
where this would fail would be a legacy one where a UAS didn't
support 487; or where Contact was not used, and thus a proxy did
a forking search, and transitioned for stateful to stateless too
early).

Just a thought.

 - Jo.