No subject

o=3Droot 771287585 771287587 IN IP4 10.0.0.229
c=3DIN IP4 10.0.0.229
a=3Dinactive

The Broadsoft device then takes the call off of hold and sends:
o=3DBroadWorks 562265 3 IN IP4 172.16.18.130
c=3DIN IP4 172.16.18.130
a=3Dsendrecv

The increase in SDP session version to "3" triggers Asterisk to process the=
 SDP.  Remember from up above, the last modified SDP that Asterisk processe=
d had the SDP session version at "2".

Try setting ignoresdpversion=3Dyes in sip.conf for this peer and let us kno=
w if that works.  It will force Asterisk to process the SDP, ignoring the s=
dp session version.

Here is what the RFC says in section 8 in regards to modifying the session.
{quote}
8 Modifying the Session

   At any point during the session, either participant MAY issue a new
   offer to modify characteristics of the session.  It is fundamental to
   the operation of the offer/answer model that the exact same
   offer/answer procedure defined above is used for modifying parameters
   of an existing session.

   The offer MAY be identical to the last SDP provided to the other
   party (which may have been provided in an offer or an answer), or it
   MAY be different.  We refer to the last SDP provided as the "previous
   SDP".  If the offer is the same, the answer MAY be the same as the
   previous SDP from the answerer, or it MAY be different.  If the
   offered SDP is different from the previous SDP, some constraints are
   placed on its construction, discussed below.

   Nearly all aspects of the session can be modified.  New streams can
   be added, existing streams can be deleted, and parameters of existing
   streams can change.  When issuing an offer that modifies the session,
   the "o=3D" 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.
{quote}

So, that pretty much sums it up.  The "o=3D" line MUST be identical except =
that the version in the origin field MUST increment by one from the previou=
s SDP.  That did not happen from what was sent from the Broadsoft.  Therefo=
re, Asterisk treated it as a no-op and responded back properly with the sam=
e previous SDP.
               =20
> Asterisk SIP channel handling of MOH media re-INVITES not RFC 3264 compli=
ant
> -------------------------------------------------------------------------=
---
>
>                 Key: ASTERISK-20633
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-206=
33
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.15.0
>         Environment: asterisk 1.8.15.0 on CentOS 5
>            Reporter: sohosys
>         Attachments: mohdebug.pdf
>
>
> When asterisk is connected to a SIP peer that uses a re-INVITE to place a=
 call on Music On Hold, but omits the "a=3Dsendrecv" tag in the SDP the han=
dling of the SDP offer by Asterisk is not RFC 3264 compliant. This is the c=
ase when interoperating with Broadsoft Broadworks , Cisco Call Manager and =
presumably some other IP PBXs.
> When the call is placed on hold the connected Broadworks platform first r=
equests that the current media is stopped by sending a re-INVITE with a=3D=
=E2=80=9Dinactive=E2=80=9D in the SDP. Asterisk accepts this SDP offer and =
starts MOH. The connected Broadworks platform then sends another re-INVITE =
with a new media endpoint IP address and port belonging to a media server t=
hat is streaming the MOH (this re-INVITE does not contain =E2=80=9Ca=3Dsend=
recv=E2=80=9D in the SDP, but does contain a new media endpoint IP and port=
). Asterisk ACKs the SDP offer with =E2=80=9Ca=3Dinactive=E2=80=9D based on=
 what appears to be logic that says =E2=80=9Cthe media was previously inact=
ive, and the re-INVITE does not explicitly request sendrecv, so we assume t=
hat the intention is to leave the media inactive=E2=80=9D.
> According to RFC 3264 =E2=80=9CIf the offerer wishes to both send and rec=
eive media with its peer, it MAY include an a=3Dsendrecv" attribute, or it =
MAY omit it, since sendrecv is the default.=E2=80=9D
> The RFC compliant method of handling this SDP offer would be to evaluate =
each re-INVITE without regard to the previous media state and assume the de=
fault of sendrecv when there is no a=3Dinactive, a=3Dsendonly, or a=3Drecvo=
nly in the SDP.
> I have confirmed with both Broadsoft and Cisco that their products by des=
ign do not send a=3Dsendrecv in the SDP when directing media to a media ser=
ver to playback MOH or IVR prompts, and they both claim that this is RFC co=
mpliant, and the RFC supports their claims.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira