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. 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. Depending on the implementation, Phone A may choose to close the call because of the 487.
Any help is highly appreciated.
Thanks, Richard
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
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 serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
UAC must receive a 487 on CANCEL, that's correct. What is not ideal is that we generate 487 localy. That helps some issues with some broken UASs but introduces an additional race condition. the dev branch does not do that. See a recent thread with Maxim on that.
-jiri
At 10:29 AM 10/18/2004, Richard wrote:
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 serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
-- Jiri Kuthan http://iptel.org/~jiri/
-
Jiri Kuthan -
Richard