[asterisk-bugs] [JIRA] (ASTERISK-26201) Asterisk fails to re-activate an inactive media session (after remote HOLD)

[Joshua Colp (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231443#comment-231443 ] 

Joshua Colp commented on ASTERISK-26201:
----------------------------------------

The SDP from the Broadworks doesn't appear to be conforming to the RFC (3264). It's seemingly passing through the SDP and it's being non-compliant. The specific part of the RFC that is applicable:

{noformat}
When issuing an offer that modifies the session,
   the "o=" line of the new SDP MUST be identical to that in the
   previous SDP, except that the version in the origin field MUST
   increment by one from the previous SDP.  If the version in the origin
   line does not increment, the SDP MUST be identical to the SDP with
   that version number.  The answerer MUST be prepared to receive an
   offer that contains SDP with a version that has not changed; this is
   effectively a no-op.  However, the answerer MUST generate a valid
   answer (which MAY be the same as the previous SDP from the answerer,
   or MAY be different), according to the procedures defined in Section
   6.
{noformat}

Initially it works as expected, with the version being incremented in the SDP. Afterwards though it's a different session identifier and has a version less than the previous. Without ignoresdpversion set to yes the code assumes it has not changed. Setting it to yes stops the version check from happening and it's processed as normal.

>  Asterisk fails to re-activate an inactive media session (after remote HOLD)
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-26201
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26201
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.22.0
>            Reporter: Rudi
>            Assignee: Unassigned
>         Attachments: ast_dump.txt, hold_no_sound.pcap
>
>
> 1. Phone A (our PBX) calls Phone B (Broadworks) to establish a call
> 2. Phone B transfers (attendant transfer) a call to Phone C (Broadworks) and so puts call on hold until call is transferred
> 3. when Phone C is on the line there is only one way audio from Phone C to Phone A.
> Examining SIP trace:
> 1. Start Hold - we receive ReInvite with sendonly and we reply with recvonly
> 2. We receive ReInvite with empty attribute and we answer with recvonly
> 3. We recieve ReInvite without SDP and we answer with sendrecv
> 4. End Hold - we receive ReInvite with empty attribute and we answer with sendrecv



--
This message was sent by Atlassian JIRA
(v6.2#6252)