Hi Nitin,
I did not get to know the complete call flow which you are trying to do.
However, there could be two possibilities:
1> 183 Session Progress is reliable provisional response (PRACK procedure)
If this is the case then the 200 OK from the termination contains the new
offer in your case because the session version is incremented.
But If I see the contents of the 183 Session Progress and 200 OK then all
the session description remains same which means terminating endpoint is not
trying to modify any aspects of the session and hence no need to increment
the session version. See below the excerpts from rfc 3264:
" 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. "
2> 183 Session Progress is non-reliable provisional response
In this case, the answer must be in the reliable non-failure message from
the terminating endpoint which is 200 OK from the terminating endpoint in
your case.
so SDP answer in 183 Session Progress should be ignored. But having said
that there is a bit confusion in what rfc 3261 says:
" If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE."
Hope it helps you.
Thanks,
Ashok
On Wed, Mar 9, 2011 at 3:18 AM, Nitin Kapoor <[email protected]> wrote:
> Dear All,
>
> I have one call scenario where my termination is sending the SDP in 183 as
> well as in 200 OK also. As far as i know if we are getting SDP in 183
> session progress then my UAC can ignore the SDP in 200 OK. Also most of the
> time SDP is same.
>
> But here i noticed the slight difference of "Session Version". Here when my
> termination is sending 188 Session Progress with SDP is sending the SDP as
> below.
>
> I can see that my Termination is incrementing "*Session Version*" for SDP
> in 183 & 200 OK in same dialog..
>
> *183 with SDP*
>
> S_OWNER : o=TLPMSXP2 22660 *22660* IN IP4 69.90.230.210
> S_NAME : s=sip call
> S_CONNECT : c=IN IP4 69.90.230.217
> TIME : t=0 0
> M_NAME : m=audio 59072 RTP/AVP 18 4 8 98
>
> 200 OK with SDP:
>
> S_OWNER : o=TLPMSXP2 22660 *22661* IN IP4 69.90.230.210
> S_NAME : s=sip call
> S_CONNECT : c=IN IP4 69.90.230.217
> TIME : t=0 0
>
> Could anyone please let me know if that is okay to increment the session
> version and if any supported document is there?
>
> Thanks,
> Nitin
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
