Summary:ASTERISK-13518: One audio stream not working after transfer
Reporter:drasha (drasha)Labels:
Date Opened:2009-02-05 03:41:21.000-0600Date Closed:2009-05-19 14:36:22
Versions:Frequency of
Environment:Attachments:( 0) asterisk_dump.log
( 1) transfer.zip
Description:Copy of mail from asterisk-dev list:

I have encountered problem with REFER handling when using Asterisk. I will try
to give as much information as possible so this is going to be a bit lengthy

In my setup I have:
3 VoIP phones with numbers 3063, 3082 and 7777
1 custom telephony application that I will refer to as OptimTalk from now on.
(I keep this names so that they are the same as the names in SIP messages)

1) OptimTalk creates a call to number 3063 (all calls go through Asterisk)
2) OptimTalk creates a call to number 3082
3) OptimTalk internally bridges RTP streams from these calls so that numbers
  3063 and 3082 can talk together
4) Number 3063 transfers the call to 7777
5) 3082 and 7777 should talk together while the streams still flow through

Problem occurs in point 5) because number 7777 can hear 3082 but not vice versa.

I have attached captured SIP messages as they were caught by tshark on the
machine that Asterisk is running on. Each message is in separate file labeled
Not all the SIP messages are here - only the relevant ones.

Ad 1) [files 01_... - 04_...]
Two INVITEs are sent, creating two calls
- between OptimTalk and Asterisk (Call-Id:3d0c17a0-6bb5-122c-2780@
- between Asterisk and 3063 (Call-Id:201d66817a4b0265062a611560fbdf99@vutbr.cz)

Ad 2) [files 05_... - 08_...]
Two INVITEs are sent, creating two calls
- between OptimTalk and Asterisk (Call-Id:3f949740-6bb5-122c-2780@
- between Asterisk and 3082 (Call-Id:30b6b781732060ad7bad01646556630b@vutbr.cz)

Ad 4) [rest of files]
3063 creates call to 7777 - again two invites and two calls
- between 3063 and Asterisk
- between Asterisk and 7777 (Call-Id:56e79bf513b8244b5cbda2e90cdded1a@vutbr.cz)

3063 sends reINVITE to 7777, changing SDP audio attribute from a=sendrecv to
a=sendonly. Call with id cf13916b9c856f11a0d52fa4848ff1c2@ is

3063 sends REFER to Asterisk. Call-Id in Refer-To header is
cf13916b9c856f11a0d52fa4848ff1c2%40192.168.32.84 (call between 3063 and Asterisk
in point 4). To-tag and from-tag are tags of OptimTalk and 3063 respectively.
Asterisk responds with 202 ACCEPTED (msg. 16) and then sends NOTIFY (msg. 17)

Then there is BYE between Asterisk and 3063 - messages are not included.


To me it looks normal, but there must be some problem. I would be very grateful
if you could help me tracking down this issue.

Btw. scenario without OptimTalk is working well, but as OptimTalk does not
receive any SIP messages after the first two INVITEs and before the last BYEs so
I think it is not a problem of its code.
Comments:By: drasha (drasha) 2009-03-12 14:21:37

It's been over a month since I reported this issue. I understand that this bug doesn't have a priority, but as the time passes I am needing it more and more. Could you please give me a hint on where (which files or functions) to hunt for this bug?


By: snuffy (snuffy) 2009-03-12 17:41:23

I understand that you have given parts of a tshark capture.

Please upload a sip debug trace from asterisk as this could also help in getting your issue resolved.

By: drasha (drasha) 2009-03-15 17:02:41

Ok, I have added the asterisk dump

By: Joshua C. Colp (jcolp) 2009-05-19 14:36:21

This issue has been fixed by my direct rtp setup change. We were putting the wrong IP address and port in the SDP, causing this issue to occur.