17 Oct
2004
17 Oct
'04
11:33 p.m.
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