RFC3264 Problem RRS feed

  • Question

  • Hi!!


    I Have a problem when try to put on-hold a call from Comunicator. The scenario is:

    I make a call from Comunicator to a user of an IP-PBX. The IP-PBX user answer the call. I try to put on-hold this call from Comunicator but don't works.

    I have analyzed the trace and I have seen that when comunicator send the re-Invite to put on hold the call it makes a new offer (sends a modified SDP) but it doesn't increase the Session Version Field in the "o="line regarding the same field  of the first Invite.


    RFC3264 "An Offer/Answer Model with the Session Description Protocol" (par. 8 Modifying the Session), specifies that:


    "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=" 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


    Regards Tonino

    Tuesday, July 17, 2007 9:38 AM

All replies

  • Hi Tonino,

    Can you update this post? Is this still an issue with the RTM version?


    Wednesday, September 19, 2007 6:28 PM