[SIPForum-discussion] Offer Answer spec.

Tue May 20 07:17:48 UTC 2014

Hello Ashish,

Kindly refer section 2.2 and 2.5 offer answer model in RFC 4317.It may
helps your query

But i can't understand your issue here.can you brief the issue you are
facing in this scenario?
if it is codec issue then change the codec settings at both end to have a
right negotiation.The complete trace/call flow will help to understand the
issue.

*-- Thanks and RegardsN.Murali*

On Tue, May 20, 2014 at 11:12 AM, ashish rawat <ashish_rawat1986 at yahoo.co.in
> wrote:

> Hello Murali,
>
> This is not a fax call. For some reason this provider offers both T38 and
> audio in a single offer (which is rare but technically not incorrect).
> Call is dropped by CUBE with invalid SDP as it recieves T38 in the SDP
> answer from Broadsoft in the 3rd Invite transaction. Although CUBE has
> already rejected the T38 stream in the 2nd Invite transaction earlier.
>
> Thanks,
> Ashish Rawat
>   On Tuesday, 20 May 2014 10:35 AM, Murali Natesh <murali87ece at gmail.com>
> wrote:
>
>
> Hello Ashish,
>
> It looks like unsuccessful changeover of a fax call.
>
> Could you please provide answer/verify the following in order to
> troubleshoot further.
>
> 1.What is the error response from CUBE towards Broadsoft is it 488 not
> acceptable or 600? share me the whole SDP parameters.
>
> 2.Whether both end T.38 is enabled?
>
> 3.Could you please confirm whether you are having something like the
> following parameters in SDP of first fax Invite
>
>
>
>
>
>
> *a=T38FaxVersion:0a=T38MaxBitRate:14400a=T38FaxRateManagement:transferredTCF
> a=T38FaxMaxBuffer:262a=T38FaxMaxDatagram:176a=T38FaxUdpEC:t38UDPRedundancy*
>
> 4.On which end the FAX tone is emitted and which end it is detected?
>
> 5.If T.38 is not acceptable at any one of the end fax should fall back to
> G.711 or G.729 whatever it may be.why cube   is sending again third invite
> with T.38?
>
> 6.Whether the fax is successful here(in third invite which is succesful) ?
>
> 7.Could you please share the Pcap trace if possible?
>
>
>
>
>
> *-- Thanks and RegardsN.Murali <%2B918527804299>*
>
>
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20140520/e7f827d0/attachment-0002.html>