[Home]

Summary:ASTERISK-17592: Call stuck with "music on hold"
Reporter:Ovidiu Sas (ovi)Labels:
Date Opened:2011-03-22 15:03:24Date Closed:2011-06-07 14:00:46
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.3 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:We have a simple call scenario: caller calls callee and callee puts caller on hold.  The caller receives music on hold.
When the callee tries to resume the call, music on hold is still being played to the caller.  What is different from a regular scenario here is the fact that the port and IP in SDP in the resume reINVITE is not the same as it was before (when the media was active).

****** ADDITIONAL INFORMATION ******

caller    (*)    callee
--INVITE-->|
          |--INVITE-->
          |<---180----
<---180----|
          |<---200----(see SDP1)
<---200----|----ACK--->
----ACK--->|
          |
          |<-reINVITE-(see SDP2)
          |----200--->
          |<---ACK----
   (music on hold)
          |
          |
          |<-reINVITE-(see SDP3)
          |----200--->
          |<---ACK----
 (still music on hold)
          |


The initial media is setup between (*) and 192.168.2.93, then it is set on hold and then, on resume, it should be re-established between (*) and 192.168.2.92 (not .93).


[SDP1]
v=0
o=- 42621871 42621871 IN IP4 192.168.2.93
s=-
c=IN IP4 192.168.2.93
t=0 0
m=audio 16390 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv


[SDP2]
v=0
o=- 42621871 42621872 IN IP4 192.168.2.93
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 16390 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendonly


[SDP3]
v=0
o=- 33675445 33675445 IN IP4 192.168.2.92
s=-
c=IN IP4 192.168.2.92
t=0 0
m=audio 16420 RTP/AVP 0 2 8 9 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729a/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
Comments:By: David Woolley (davidw) 2011-03-23 06:58:08

The session version has gone backwards, which may be sufficient to cause it to be ignored (I'm not sure about the simultaneous change in session-ID).  There is an option to ignore session version, to deal with peers with broken session versions.

If you still think this is an Asterisk bug, you need to:

1) provide the standard SIP bug reporting information - verbose and debug logging for sip set debug on and sip history output;

2) explain what ...92 and ...93 are.

Incidentally, I do not believe this affects large numbers of users, so it is not "major".
By: Ovidiu Sas (ovi) 2011-03-23 14:18:13

The "ignoresdpversion=yes" did the trick (thanks davidw for pointing that out).

Just for the record, here's the scenario that I was testing:
The callee is an opensips server which provides SCA (shared call appearance) to two SIP phones (the .92 and the .93).  Opensips was acting as a signalling B2BUA and passed SDP unchanged from the two phones to asterisk (SDP1 and SDP2 were belonging to phoneA, and when the call was retrieved by phoneB, the SDP3 from phoneB was sent to asterisk, hence the change in session version).

This bug can be closed now as a workaround has been identified.
By: Leif Madsen (lmadsen) 2011-04-01 14:23:33

Thanks davidw and ovi!