[Serusers] cancel and 487 relay

Richard richard at o-matrix.org
Mon Oct 18 10:29:27 CEST 2004


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 at 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
> >serusers at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serusers
> 
> --
> Jiri Kuthan            http://iptel.org/~jiri/




More information about the sr-users mailing list