[SIPForum-discussion] Offer Answer spec.

Tue May 20 06:02:23 UTC 2014

Hi Kunal,

Thanks for response. 
 In this particular call flow:-

For some reason this provider offers both T38 and 
audio in a single offer (non zero port) (which is rare but technically not incorrect)
Call is dropped by CUBE with invalid SDP as it receives 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. 

I did further reading of the RFC and what I could infer is that Broadsoft is wrong in sending as T38 as answer in the 3rd invite transaction.

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

It would have been perfectly legal to send T38 as an answer if  T38 would not have been rejected in earlier offer/answer . Broadsoft can send the same sdp as long as it is a valid answer.

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

Moreover looks like the RFC snippet pointed by Broadsoft is applicable for the entity which is offering the SDP(in
this case CUBE-SP for 3rd transaction)  and not to the entity
receiving the offer(in this case broadsoft for 3rd transaction)
 for that particular transaction. 

The
offer MAYbe 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."

But 

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

Looks like there is no single place in the RFC which talks about our scenario however going through different section above is what I could infer. 

Thanks &
Regards,

Ashish
Rawat 

Thanks,Ashish Rawat
On Tuesday, 20 May 2014 8:37 AM, Kunal Narula <narula.kunal at gmail.com> wrote:

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/5f26d762/attachment-0002.html>