[SIPForum-discussion] Offer Answer spec.

[Kunal Narula]

8 <http://tools.ietf.org/html/rfc3264#section-8> Modifying the Session


 *As per SIP RFC 3264,Section 8*

*Origin*

*o=<username> <session id> <version> <network type> <address*

*type>*

*<address>*

  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 6.


Yes, it is legal as codec is narrowed from PCMU & Video to PCMU & T.38 to
T.38 only in IInd re-invite.

 Hope this helps.


Thanks!
Kunal


On Mon, May 19, 2014 at 12:13 PM, ashish rawat <ashish_rawat1986 at yahoo.co.in
> wrote:

> *Hello Experts,*
>
>
> *I have a situation here:- *
>
> *Below is the call flow:-*
>
>
> *"o" field here refrers to the session id and version no. in the sdp.  *
>
> *  CUBE-SP             Broadsoft*
>
> *    ------->Invite1 *
> *m=audio*
> *m=video*
> *o= 197--197*
> *                <---183*
> *                   m=audio*
> *                   m=0 video *
> *                   o=767-1*
>
> *                <----200 Ok*
> *                  m= audio*
> *                  m= 0 video*
> *                  o= 767-1*
>
> *   ----->Invite2*
> *               <----200 Ok*
> *                   m=audio*
> *                   m=T38*
> *                   o=767-2*
>
> *  ------> Ack*
> *m=audio*
> *m=0 T38*
> *o=197-198*
>
>
> *------> Invite3*
> *m=audio*
> *m=0 T38*
> *o=197-198*
>
> *              <----200 Ok*
> *                m=audio*
> *                m=T38*
> *                o= 767-2*
>
>
> *Here if you look 2nd Invite transaction Broadsoft sends T38 offer  in the
> 200 Ok . Cube rejects T38 stream and only audio in negotiated.*
>
> *Now CUBE sends another invite which is third Re-invite with same sdp as
> it has send in the sdp answer of the previous invite transaction. Notice
> sdp session version is same.  To which Broadsoft responds again responds
> with Fax m line. *
>
> *CUBE fails this calls due to invalid sdp.*
>
>
> *Broad soft says since we have sent same sdp session version number hence
> they just copy their previous sdp offer in the sdp answer in the 3rd
> invite.*
>
>
> *RFC quoted by Broadsoft.*
>
> *Section: 8 Modifying the 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."*
>
>
> *I have following observations to make:-*
>
> *1) RFC quoted states "MAY". It may be same or different.*
>
> *2) Further in the section 8 only*
>
> *"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."*
>
> *Note as per procedures in section 6.*
>
>
> *Here's snippet from section 6*
>
> *An offered stream MAY be rejected in the answer, for any reason.  If*
> *   a stream is rejected, the offerer and answerer MUST NOT generate*
> *   media (or RTCP packets) for that stream*
>
>
> *   Questions:-*
>
>
> *1) Can anyone point me to the more relevant section of the RFC if there
> is one? *
> *2) Is the sdp answer in the 3rd invite transaction from Broadsoft a legal
> answer?*
>
> *Thanks,*
>
> *Ashish Rawat*
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>


-- 
GOD BLESS U
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140520/e4180949/attachment-0001.html