[SIPForum-discussion] Offer Answer spec.

[ashish rawat]

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:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:176
a=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 Regards
N.Murali
+918527804299


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/97e81e2b/attachment-0002.html>