Subject: [SIP] Transaction identification, again

From: Bertil Engelholm <[email-masked]>
Date: Mon, 23 Oct 2000 14:23:42 +0200

Hi,

I think there are still a few question marks regarding 
transaction identification in SIP. I'll try and describe
how I understand the specification and what problems I
see.

Here is an example call chain :

        ------      ------      ------      ------
        |    |----->| P2 |----->|    |      |    |
        |    |      ------      |    |      |    |      ------
Ca ---->| P1 |                  | P4 |----->| P5 |----->| Cb |
        |    |      ------      |    |      |    |      ------
        |    |----->| P3 |----->|    |      |    |
        ------      ------      ------      ------

Ca INVITEs Cb at P1. P1 forks two bransches, one to P2 and
the other to P3. Both P2 and P3 proxy the INVITE to P4 with
the same requestURI (Cb@P4). 

The first problem is for P4 to realize the the two INVITEs 
coming from P2 and P3 is not the same. They will have the
same Call-Leg, Cseq and requestURI. If I understand the
specification correct this is solved by having P4 look in
the topmost via header. In this way P4 will detect that one
comes from P2 and the other from P3 therefore they are
two different INVITEs and not a retransmission.

The next problem arises when the two INVITEs arrives at P5
because now the topmost via will be the same (P4). The
specification seems to handle this problem by letting each
proxy ad a global unique identifier as one of the branch
values in it's via header (a hash of a sequence number, 
own IP address and requestURI). In this way P5 will now
be able to detect that the two INVITEs are different because
P4 will use different sequence numbers for the two INVITEs. 

The problems I can't see a solution for is :

How will P5 be able to detect a retransmission if it gets
a global unique identifier in each request ? If P4 is
stateful it could save the sequence number it used the
last time and use it again in the retransmission but 
if P4 is stateless that's not possible. So if P4 is
stateless it has to go on generating new sequence 
numbers for each request. This means that P5 can't
detect a retransmission. Or have I missed something ?

If P1 CANCEL one of the branches, how will P5 be able
to detect which INVITE transaction it relates to ? 
It only has Call-Leg + Cseq to use and they are the
same for both INVITEs.

-- 
Bertil Engelholm
Ericsson 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, 23 Oct 2000 16:03:52 +0100

> Here is an example call chain :

No.  The moment that P4 detects it has seen two requests
which are isomorphic if one _does not consider_ the topmost
Via, then P4 knows it is at the tip of a request merge,
and thus should take appropriate action.

I would recommend returning a 4xx (say 482 with reason
"Request Merge", or something) to all secondary requests.

For more information, look at:
http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt

> detect a retransmission. Or have I missed something ?

If P4 is behaving statelessly, it can ensure that it
generates the same branch parameter for retransmitted
requests by making it a hash of [Request-URI, From, To,
Call-ID, CSeq, topmost-Via (including branch parameter)],
for example.

> It only has Call-Leg + Cseq to use and they are the

The CANCEL requests should still have different topmost-Vias
which correspond to the topmost-Vias in the original INVITEs.

HTH,

 - Jo.