Hi,
I'm currently using the sbc application of SEMS (version 1.6), and I
noticed something odd when controlling active calls with
sems-list-active-calls: a call is still marked as active after being
canceled.
In the following scenario:
PROXY1 SEMS SBC PROXY2
| | |
| INVITE bob | |
|-------------->| INVITE bob |
| 100 |-------------->|
|<--------------| 100 |
| |<--------------|
| | 180 |
| 180 |<--------------|
|<--------------| |
| | |
| CANCEL bob | |
|- - - - - - - >| |
| 200 | |
|< - - - - - - -| |
| 487 | |
|<--------------| |
| ACK bob | |
|-------------->| |
| | CANCEL bob |
| |- - - - - - - >|
| | 487 |
| |<--------------|
| | 200 |
| |< - - - - - - -|
| | ACK bob |
| |-------------->|
the sems-list-active-calls shows the call corresponding to the To-tag
("yyy" for concision) of the leg between SEMS SBC and PROXY2 as still
active, and this call never disappears from this list.
The last information i can see about this call "yyy" in the logs is:
[processingCycle, AmSession.cpp:346] DEBUG: vv S [xxx|yyy] Cancelling,
stopped, 1 UACTransPending, 0 usages vv
[processEvents, AmEventQueue.cpp:85] DEBUG: before processing event
(15AmSipReplyEvent)
[process, AmSession.cpp:638] DEBUG: AmSession processing event
[processEvents, AmEventQueue.cpp:89] DEBUG: event processed (15AmSipReplyEvent)
[processingCycle, AmSession.cpp:415] DEBUG: ^^ S [xxx|yyy] Cancelling,
stopped, 1 UACTransPending, 0 usages ^^
and I wonder what "1 UACTransPending" refers to (I see
"0 UACTransPending" in the other leg's last messages).
Do you have an idea of what is still pending, or how to find it out?
I noticed that PROXY2 sends 487 to the invite before sending 200 to the
cancel, is this problematic for SEMS?
Thanks
--
Camille
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
