[SIPForum-discussion] Offer Answer spec.

[Paul Kyzivat]

ashish,

See comments inline.

On 5/19/14 2:43 AM, ashish rawat 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./

So far so good.

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

Why does it do this? It isn't asking for anything different than the 
current state.

> To which Broadsoft responds again responds
> with Fax m line.
> /
>
> //
> /CUBE fails this calls due to invalid sdp./

This seems justified. RFC3264 section 8.2 says:

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

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

ISTM that the MUST in 8.2 trumps the MAY in the intro of section 8 that 
you quote.

Also, the "the answerer MUST generate a valid answer" supports that.

> /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?

I did.

> /2) Is the sdp answer in the 3rd invite transaction from Broadsoft a
> legal answer?/

I don't think so.

	Thanks,
	Paul

> /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
>