Subject: RE: Call legs and Cseq

From: Itamar Gilad <[email-masked]>
Date: Wed, 2 Feb 2000 17:43:21 +0200

Just to make sure:

reqMsg1 == reqMsg2 (duplicate requests) IFF the To, From, Call-ID and CSeq
headers are identical (addresses and tags only in the To and From headers).

msg1 and msg2 belong to the same Call-leg if 
    the Call-ID is the same and 
    (msg1.To == msg2.To && msg1.From == msg2.From) || 
    (msg1.To == msg2.From && msg1.From == msg2.To)

( ==  means the addresses and tags are the same)

Is that right? 

BTW, you cannot identify duplicate responses using the first rule.

Itamar

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2000 3:17 PM
> To: Liberati, Ernest
> Cc: [email-masked]'
> Subject: Re: Call legs and Cseq
> 
> 
> Ernest,
> 
> Your confusion is quite understandable.
> 
> A SIP call leg denotes the (abstract) notion of an end-to-end
> connection, regardless of whether any proxies are on the 
> signaling path.
> This means that (in SIP terminology) there are no A-B and B-C legs but
> only an A-C leg. Obviously a (forking) proxy needs to know about those
> other "leg segments" but they are not considered legs as such. This is
> different from the PSTN switch notion of legs.
> 
> As for the CSeq number, the UAs involved in a leg choose CSeq 
> numbers in
> increasing order for different transactions but independent of each
> other. The fact that they can initiate transactions at overlapping
> points in time implies that the CSeq number spaces are separate in the
> two directions, i.e. the transaction {i,A,C,42} is *not* the same
> transaction as {i,C,A,42} even though the legs {i,A,C} is the same as
> the leg {i,C,A} where i is the Call-ID and 42 is the CSeq.
> 
> "Liberati, Ernest" wrote:
> > 
> > Hi,
> > 
> > For a SIP call that involves phone with UAC, host with UAS, 
> and Proxy Server
> > components, shown below, I need some help to clear my 
> confusion on call legs
> > and Cseq.
> > 
> > 1. Do call legs exist between all adjacent components 
> (e.g., A - B, B - C,
> > ...)?
> > 
> > 2. Does a call leg include the requests in both directions 
> (e.g., B - C and
> > C - B)?
> > 
> > 3. The most recent definition of a call leg, that I have found, is a
> > combination of local- and remote-addresses (including tags) 
> and the Call-ID.
> > How do the Request URI, To, and From address relate to local- and
> > remote-addresses?
> > 
> > 4. Within a call leg, is the Cseq incremented for each 
> transaction in each
> > direction?
> > 
> 
> -- 
> Anders Kristensen <[email-masked]>,
> http://www-uk.hpl.hp.com/people/ak/
> Hewlett-Packard Labs, Bristol, UK
>

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 02 Feb 2000 17:02:03 +0000

> headers are identical (addresses and tags only in the To and From headers).

Yes. Obviously, reqMsg1 and reqMsg2 may in fact differ in other headers
(although this should never happen), but for the purpose of identifying
and filtering out retransmissions they're the same.

> ( ==  means the addresses and tags are the same)

Yes. 

> BTW, you cannot identify duplicate responses using the first rule.

No, not quite. If the request was sent without a To tag the UAC needs to
take into account the possibility that a UAS has added this to the
response, and must also be prepared to handle multiple responses with
different To tags (these belonging to different legs).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Feb 2000 01:15:51 -0500

> and filtering out retransmissions they're the same.

This is the case as specified in RFC2543, but two issues have been
discovered since, and discussed on the list, which probably require two
more fields thrown in there.

First is loop detection. As we discussed on the list, there are valid
cases where a message is not a loop even though it hits the same server
twice; namely, when the request URI is different between the two. In
this case, the request and its looped version will differ by the request
URI (and parts of the Via too). Here, the fact that the request URI is
different is important. 

Another issue is request merging (the reverse of forking). In this case,
two messages arrive from different upstream servers, with the same
request URI, To, From, Call-ID and CSeq. Whilst it is OK to effectively
ignore this problem, and treat the two as retransmissions, better
performance is achieved by considering them as separate requests. See:

http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt

for a discussion of the options and their various consequences. Thus,
one could include the topmost Via in the determination of equality.

> > ( ==  means the addresses and tags are the same)

Almost. One would not compare two messages to determine if they are part
of the same call-leg. Rather, when an INVITE is sent and/or received for
the first time, the call leg is established by extracting the local and
remote addresses. Whether they are extracted from the To or From depends
on whether the INVITE was sent or received. Then, subsequent messages
are determined to be part of the call leg by matching the To  (From) to
the remote (local) participant if the message is a request (response),
and the From (To) to the local (remote) participate if the message is a
response (request). 

> different To tags (these belonging to different legs).

For a proxy, the branch ID parameter will also need to be looked at if
the proxy forked, to determine which forked request the response
corresponds to.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com