RE: [Serusers] cancel and 487 relay

Hi Jiri, I probably didn't make myself clear. In this case, it is not really a race condition. It happens when one user picks up a branch. Ser sends out CANCEL to all other branches. The issue is that ser propagates the 487 to the upstream caller. It should absorb the 487 because it is a ser generated branch. And the 487 to the caller can disrupt the call depending on the UA implementation. Thanks, Richard > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: Sunday, October 17, 2004 5:55 PM > To: Richard; 'ser users' > Subject: Re: [Serusers] cancel and 487 relay > > > At 11:33 PM 10/17/2004, Richard wrote: > >Hi, > > > >I ran into some issues. Hope that someone can enlighten me. When ser does > a > >parallel forking, it uses its uac to initiate a new call. The scenario is > >Phone A calls phone B via ser. In ser, it forks into two branches, one > for > >phone B and one for phone C. To call phone C, ser's uac initiates the > call. > >When Phone B picks up the call, ser sends a CANCEL to phone C and cancesl > >the call. The following diagram illustrates the sip call flow. For > >simplicity, I didn't include any message involving Phone B. > > > >Packet # Phone A ------- (ser UAC) -------- ser --------- Phone C > >0 | INVITE ----------------> | | > >1 | | INVITE -> | | > >2 | <----------- 100 trying | | > >3 | | | INVITE -> | > >4 | | | <- 100 trying | > >5 | | | <- 183 | > >6 | <-------------- 183 | | > >7 | | CANCEL -> | | > >8 | |<- 200canceling| | > >9 | | | CANCEL -> | > >10 | | | <- 487 | > >11 | | | <- 200 OK | > >12 | | | ACK -> | > >13 | | <- 487 | | > >14 | | ACK -> | | > >15 | | | ACK -> | > >16 | <--------------- 487 | | > >17 | ACK ---------------> | | > >18 | | | ACK -> | > > > >Per rfc, 487 and its ACK are hop-by-hop, i.e. ACK is generated at each > hop. > >Ser correctly does it at Packet 12. The problem happens after packet 14. > >Somehow ser doesn't think this ACK of Packet 14 is an acknowledgement of > >Packet 13. > > that's strange. I don't know why it is this way without seeing the > packets. (I have to admit that even if I received them, my current > worload would not allow me to study them.) > > > So it is forwarded to Phone C. Not sure if I can use ser.cfg to > >absorb it without forwarding. Anyway, not a big deal for an extra ACK. > The > >big problem is that somehow ser relays the 487 back to Phone A. It > doesn't > >seem right. In Packet 10, 487 is to cancel the original INVITE at Packet > 3 > >which has a record-route of Phone A, ser. So 487 has the same "Via" field > >back to Phone A. When this 487 is relayed back to Phone A, it already > gets > >the 200 OK from Phone B and has an active conversation. > > well that's a race condition -- if caller cancelled, then the 487 should > propagate to UAC. If at the same time one of the called parties answered, > the UAC will see the 200 too. The case that caller hangs up at the same > point of time when called party happens simply happens. > > > Depending on the > >implementation, Phone A may choose to close the call because of the 487. > > > >Any help is highly appreciated. > > > >Thanks, > >Richard > > > > > > > > > > > > > >_______________________________________________ > >Serusers mailing list > &gt;serusers(a)lists.iptel.org > >http://lists.iptel.org/mailman/listinfo/serusers > > -- > Jiri Kuthan http://iptel.org/~jiri/