[SIPForum-discussion] Offer Answer spec.

[ashish rawat]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20140519/0addaac7/attachment-0002.html>