[SIPForum-discussion] Offer Answer spec.

[Ibrahim Zendah]

hi Ashih

Broadsoft answer isn't legal

RFC3264 section 8.2:

A stream that is offered with a port of zero MUST be marked with port
   zero in the answer.


can you share complete traces?


BR
Ibrahim Zendah



On Mon, May 19, 2014 at 9:43 AM, 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
>
>


-- 
*With Thanks and Regards,*


*Ibrahim B. Zendah,*

*NOC Engineer (MPLS),*


*ZTE (HK) Limited Saudi Arabia*

*Riyadh, KSA.*

*--------------------------------------------*

*Phone:- +966 - 08111463121*

*Mobile:- +966 - 549017881*

*E-mail:- ibzendah at gmail.com <ibzendah at gmail.com> <i.zendah at c.go.com.sa>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20140520/b42977e8/attachment-0002.html>