Subject: Re: [SIP] Transaction identification, again

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

Jo Hornsby wrote:
> 
> > 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.
> 
> 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.

OK, that's makes sence even though I can't read that out
from the specification. Where is request merging described ? 

> 
> For more information, look at:
> http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt
> 
> > 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 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.

This also makes sence since we came up with the same solution 8-).
But the specification does not say anything about that this
is what you need to do. So the VIA chapter maybe needs an
update on this part. 

> 
> > 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.
> 
> The CANCEL requests should still have different topmost-Vias
> which correspond to the topmost-Vias in the original INVITEs.
> 
> HTH,
> 
>  - Jo.
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
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