[sip-comm-dev] RTP stream does not terminate after re-INVITE


#1

Hi,

I've noticed a problem when the RTP stream did not terminate after a successful call tear-down. Attached is the packet dump with some of the RTP frames filtered out for brevity The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port. (frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it didn't show itself if the call was terminated by SIP communicator. The problem is still reproduceable with build 3076 even though I recorded the traffic using one of the previous releases.

Best regards,

sip-communicator-rtp-bug2.pcap (23.2 KB)

···

--
Dmitry Panov


#2

Dmitry, thank you for the report! Since I seem to remember a similar
problem from a private conversation, I created issue 877: RTP stream
does not terminate after re-INVITE in our issue tracker at
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=877.
Please track the progress of the development with respect to fixing
the problem there.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Dmitry,

На 13.11.10 17:59, Dmitry Panov написа:

Hi,

I've noticed a problem when the RTP stream did not terminate after a
successful call tear-down. Attached is the packet dump with some of the
RTP frames filtered out for brevity

It would also help to see the log files as we are unable to reproduce it.

Cheers,
Emil

···

The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port.
(frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames
starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it
didn't show itself if the call was terminated by SIP communicator. The
problem is still reproduceable with build 3076 even though I recorded
the traffic using one of the previous releases.

Best regards,
--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Emil,

I just reproduced the problem again and recorded the log (see attached). There is notthing interesting there though. After the call was terminated I could still see RTP traffic coming from my machine, port 5030 to 10.0.0.157:60002.

Please let me know how I can help further.

sip-communicator-rtp-bug_log.txt (9.71 KB)

···

On 15/11/2010 17:44, Emil Ivov wrote:

Hey Dmitry,

На 13.11.10 17:59, Dmitry Panov написа:

Hi,

I've noticed a problem when the RTP stream did not terminate after a
successful call tear-down. Attached is the packet dump with some of the
RTP frames filtered out for brevity

It would also help to see the log files as we are unable to reproduce it.

Cheers,
Emil

The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port.
(frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames
starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it
didn't show itself if the call was terminated by SIP communicator. The
problem is still reproduceable with build 3076 even though I recorded
the traffic using one of the previous releases.

Best regards,
--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov


#5

Hi,

I tried reproducing the problem, even I saw you are using
CommuniGatePro as a server, downloaded and installed it and tried
calling through it, but didn't manged to reproduce it. I never get the
reinvite with the new audio port.
Is there something specific in your configuration? Any way I can
reproduce your situation?

Thanks
damencho

···

On Mon, Nov 15, 2010 at 8:31 PM, Dmitry Panov <dmitry.panov@yahoo.co.uk> wrote:

Hi Emil,

I just reproduced the problem again and recorded the log (see attached).
There is notthing interesting there though. After the call was terminated I
could still see RTP traffic coming from my machine, port 5030 to
10.0.0.157:60002.

Please let me know how I can help further.

On 15/11/2010 17:44, Emil Ivov wrote:

Hey Dmitry,

На 13.11.10 17:59, Dmitry Panov написа:

Hi,

I've noticed a problem when the RTP stream did not terminate after a
successful call tear-down. Attached is the packet dump with some of the
RTP frames filtered out for brevity

It would also help to see the log files as we are unable to reproduce it.

Cheers,
Emil

The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port.
(frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames
starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it
didn't show itself if the call was terminated by SIP communicator. The
problem is still reproduceable with build 3076 even though I recorded
the traffic using one of the previous releases.

Best regards,
--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Damian,

You're right, there is a custom application there. I have created a very simple test case to help you reproduce the problem. Please login to the CGP admin interface (usually http://…:8010/) as postmaster, then click on Users, then PBX tab and upload the attached file.

Then call reinvite_testcase#pbx@<your_domain>. You should hear "press one". After pressing 1 you should receive the re-INVITE and hear the talking clock. Press #, that will terminate the call. After that you should see the RTP traffic.

Let me know if there is any problem.

reinvite_testcase.sppr (652 Bytes)

···

On 16/11/2010 08:01, Damian Minkov wrote:

Hi,

I tried reproducing the problem, even I saw you are using
CommuniGatePro as a server, downloaded and installed it and tried
calling through it, but didn't manged to reproduce it. I never get the
reinvite with the new audio port.
Is there something specific in your configuration? Any way I can
reproduce your situation?

Thanks
damencho

On Mon, Nov 15, 2010 at 8:31 PM, Dmitry Panov<dmitry.panov@yahoo.co.uk> wrote:

Hi Emil,

I just reproduced the problem again and recorded the log (see attached).
There is notthing interesting there though. After the call was terminated I
could still see RTP traffic coming from my machine, port 5030 to
10.0.0.157:60002.

Please let me know how I can help further.

On 15/11/2010 17:44, Emil Ivov wrote:

Hey Dmitry,

На 13.11.10 17:59, Dmitry Panov написа:

Hi,

I've noticed a problem when the RTP stream did not terminate after a
successful call tear-down. Attached is the packet dump with some of the
RTP frames filtered out for brevity

It would also help to see the log files as we are unable to reproduce it.

Cheers,
Emil

The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port.
(frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames
starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it
didn't show itself if the call was terminated by SIP communicator. The
problem is still reproduceable with build 3076 even though I recorded
the traffic using one of the previous releases.

Best regards,
--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov


#7

Hi,

it must be fixed in the next build I think its build.3082 (r7927), you
can try it and see does it works for you.
And thank you for helping me setup a test scenario to test it and fix it.

Thanks
damencho

···

On Tue, Nov 16, 2010 at 12:16 PM, Dmitry Panov <dmitry.panov@yahoo.co.uk> wrote:

Hi Damian,

You're right, there is a custom application there. I have created a very
simple test case to help you reproduce the problem. Please login to the CGP
admin interface (usually http://…:8010/) as postmaster, then click on
Users, then PBX tab and upload the attached file.

Then call reinvite_testcase#pbx@<your_domain>. You should hear "press one".
After pressing 1 you should receive the re-INVITE and hear the talking
clock. Press #, that will terminate the call. After that you should see the
RTP traffic.

Let me know if there is any problem.

On 16/11/2010 08:01, Damian Minkov wrote:

Hi,

I tried reproducing the problem, even I saw you are using
CommuniGatePro as a server, downloaded and installed it and tried
calling through it, but didn't manged to reproduce it. I never get the
reinvite with the new audio port.
Is there something specific in your configuration? Any way I can
reproduce your situation?

Thanks
damencho

On Mon, Nov 15, 2010 at 8:31 PM, Dmitry Panov<dmitry.panov@yahoo.co.uk> >> wrote:

Hi Emil,

I just reproduced the problem again and recorded the log (see attached).
There is notthing interesting there though. After the call was terminated
I
could still see RTP traffic coming from my machine, port 5030 to
10.0.0.157:60002.

Please let me know how I can help further.

On 15/11/2010 17:44, Emil Ivov wrote:

Hey Dmitry,

На 13.11.10 17:59, Dmitry Panov написа:

Hi,

I've noticed a problem when the RTP stream did not terminate after a
successful call tear-down. Attached is the packet dump with some of the
RTP frames filtered out for brevity

It would also help to see the log files as we are unable to reproduce
it.

Cheers,
Emil

The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port.
(frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames
starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it
didn't show itself if the call was terminated by SIP communicator. The
problem is still reproduceable with build 3076 even though I recorded
the traffic using one of the previous releases.

Best regards,
--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Damian,

I've just tested it with build 3082 and can confirm that the problem is fixed. Many thanks!

···

On 16/11/2010 16:09, Damian Minkov wrote:

Hi,

it must be fixed in the next build I think its build.3082 (r7927), you
can try it and see does it works for you.
And thank you for helping me setup a test scenario to test it and fix it.

Thanks
damencho

On Tue, Nov 16, 2010 at 12:16 PM, Dmitry Panov<dmitry.panov@yahoo.co.uk> wrote:

Hi Damian,

You're right, there is a custom application there. I have created a very
simple test case to help you reproduce the problem. Please login to the CGP
admin interface (usually http://…:8010/) as postmaster, then click on
Users, then PBX tab and upload the attached file.

Then call reinvite_testcase#pbx@<your_domain>. You should hear "press one".
After pressing 1 you should receive the re-INVITE and hear the talking
clock. Press #, that will terminate the call. After that you should see the
RTP traffic.

Let me know if there is any problem.

On 16/11/2010 08:01, Damian Minkov wrote:

Hi,

I tried reproducing the problem, even I saw you are using
CommuniGatePro as a server, downloaded and installed it and tried
calling through it, but didn't manged to reproduce it. I never get the
reinvite with the new audio port.
Is there something specific in your configuration? Any way I can
reproduce your situation?

Thanks
damencho

On Mon, Nov 15, 2010 at 8:31 PM, Dmitry Panov<dmitry.panov@yahoo.co.uk> >>> wrote:

Hi Emil,

I just reproduced the problem again and recorded the log (see attached).
There is notthing interesting there though. After the call was terminated
I
could still see RTP traffic coming from my machine, port 5030 to
10.0.0.157:60002.

Please let me know how I can help further.

On 15/11/2010 17:44, Emil Ivov wrote:

Hey Dmitry,

На 13.11.10 17:59, Dmitry Panov написа:

Hi,

I've noticed a problem when the RTP stream did not terminate after a
successful call tear-down. Attached is the packet dump with some of the
RTP frames filtered out for brevity

It would also help to see the log files as we are unable to reproduce
it.

Cheers,
Emil

The scenario was as follows:

1. I received an inbound SIP call (frame 1).
2. A re-INVITE arrived with the same audio address but different port.
(frame 16).
3. The call was terminated by the remote end. (frame 35).
4. The BYE request was acknowledged. (frame 45).
5. The communicator continued sending RTP data even after that (frames
starting from 46). I had to quit the program to make it stop.

The problem is reproduced every time I followed this scenario but it
didn't show itself if the call was terminated by SIP communicator. The
problem is still reproduceable with build 3076 even though I recorded
the traffic using one of the previous releases.

Best regards,
--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Dmitry Panov

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net