There is a draft which tries to clarify what is legal.
http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-13
Offer Answer RFC Ini Est Early
-------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N
2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N
5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y
Table 1: Summary of SIP Usage of the Offer/Answer Model
According to Table 1 it seems that you could be allowed scenario 4
followed
by scenario 2.
Nitin, if you are sending SDP with your INVITE then obviously you can't
have 4 followed by 2.
Ashok said:
>>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.
No, the SDP answer in the 183 should not be ignored.
The extract from 3261 says that the answer MUST be in the 200 OK.
It also says (as you quoted):
That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer.
And...
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.
So if it receives the 18x with SDP as an answer then it MUST ignore any
SDP in the 200 OK.
Regards
Attila
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
ashok kumar
Sent: 09 March 2011 13:19
To: Nitin Kapoor
Cc: [email protected]
Subject: Re: [Sip-implementors] Different SDP Session Version in 183 &
200 OK
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
1> 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
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
