Hi,
I noticed that if I do an attended transfer (REFER with Replaces) while
the call from the transferer to the transfer destination has not been
answered yet, and the transferee then terminates the call to the
transferer with a BYE before CANCELing the INVITE with Replaces (to the
transfer destination), then a couple of weird things happen:
1. The transferee sends a duplicate NOTIFY (180 Ringing),
rather than sending a NOTIFY indicating that the INVITE w/ Replaces
has been terminated.
2. Nua leaks memory on the transferee.
But, if the transferee CANCELs the INVITE w/ Replaces to the transfer
destination before sending the BYE to the transferer, then no memory is
leaked and the final NOTIFY says "503 Service Unavailable".
After more investigation on the transferee side, it seems as though the
trigger for the memory leak and incorrect NOTIFY content is the 200 OK
from the transferer (in response to the BYE) arriving at the transferee
before the 487 Request Terminated arrives from the transfer destination.
So, even if the transferee sends the BYE to the transferer before sending
the CANCEL to the transfer destination, sometimes the 487 from the
transfer destination still arrives after the 200 from the transferer, and
the bad behaviour is still seen.
This is what I see happening if the transfer destination delays its 487
response to the CANCEL until after the transferer sends its 200 OK for the
BYE:
XFEREE XFERER XFER DEST
|------ INVITE -------->| |
|<--- 100 Trying -------| |
|<--- 180 Ringing ------| |
|<----- 200 OK ---------| |
|-------- ACK --------->| |
| |------ INVITE -------->|
| |<--- 100 Trying -------|
| |<--- 180 Ringing ------|
|<- REFER w/ Replaces --| |
|---- 202 Accepted ---->| |
|-------------------- INVITE ------------------>|
|<----------------- 100 Trying -----------------|
| |<--- 487 Req Term -----|
| |-------- ACK --------->|
|<---------------- 180 Ringing -----------------|
|-- NOTIFY (180 Ring) ->| |
|<----- 200 OK ---------| |
|-------------------- CANCEL ------------------>|
|-------- BYE --------->| |
|<------------------ 200 OK --------------------|
|<----- 200 OK ---------| |
?!->|-- NOTIFY (180 Ring) ->| |
|<- 481 Call Not Exist -| |
|<----------- 487 Request Terminated -----------|
|--------------------- ACK -------------------->|
And, nua leaks memory:
hsb_number = 1
hsb_bytes = 148
hsb_rbytes = 152
This is what I see happening if the transferer terminates its call with
the transferee by sending a BYE before the transferee terminates the call:
XFEREE XFERER XFER DEST
|------ INVITE -------->| |
|<--- 100 Trying -------| |
|<--- 180 Ringing ------| |
|<----- 200 OK ---------| |
|-------- ACK --------->| |
| |------ INVITE -------->|
| |<--- 100 Trying -------|
| |<--- 180 Ringing ------|
|<- REFER w/ Replaces --| |
|---- 202 Accepted ---->| |
|-------------------- INVITE ------------------>|
|<----------------- 100 Trying -----------------|
| |<--- 487 Req Term -----|
| |-------- ACK --------->|
|<---------------- 180 Ringing -----------------|
|-- NOTIFY (180 Ring) ->| |
|<----- 200 OK ---------| |
|<------- BYE ----------| |
|------ 200 OK -------->| |
|-------------------- CANCEL ------------------>|
|<------------------ 200 OK --------------------|
|<----------- 487 Request Terminated -----------|
|--------------------- ACK -------------------->|
|----- NOTIFY (503) --->| |
|<- 481 Call Not Exist -| |
In this sequence, the second NOTIFY is correct, but the nua still leaks
memory:
hsb_number = 1
hsb_bytes = 148
hsb_rbytes = 152
NOTE: I've also seen a segmentation violation in a call to strlen from
Sofia's thread (the thread that Sofia starts on its own, NOT the thread I
called su_root_run from). Unfortunately, (for reasons I'd rather not get
into) I can't provide you with a call stack trace. At this point, I'm
assuming that the same problem that's causing the misbehaviour described
above also caused my seg-fault, but this obviously could be an incorrect
assumption.
--Jen
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Sofia-sip-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
