This thread has gone on for a long time. There is some good/accurate
info and some very wrong info here. This is a complex topic that is
widely misunderstood. I *strongly* encourage you to read the
offer-answer draft referenced earlier. It is a compilation of
information from multiple RFCs and with a lot of
clarification/interpretation.
I've not kept track entirely, but I think Atilla and Bob have it right.
Bob does give you some pragmatic advice. It technically violates 3261.
But it is advice for the UAC in a case when the UAS is non-conforming.
In such cases you are really on your own. What works will depend on what
the UAS expected when it violated the specs.
A bit more inline below
On 3/11/2011 5:07 AM, Jaiswal, Sanjiv (NSN - IN/Bangalore) wrote:
> Hi Attila,
>
> Take for example the early media is established with
> invite/18x/PRACK/200k(of PRACK).
> Now announcement is played and after that if endpoint want to change the
> media( for established dialog) then as per you mention , end point has
> to send update with change media stream. And Sending 200 OK (new offer
> ) and ACK (SDP ) doesn't make any difference.
> Is this correct?
There are a couple of ways to accomplish your objective:
- as you suggest, finish up the INVITE transaction, then do a reINVITE
or UPDATE with new o/a to switch the media. This all within the same
dialog.
- a "tricky" way to do this is, after the announcement is done,
send your new sdp answer in a 200 ok to the INVITE, but with a
*different* to-tag. This means you had one early dialog for the
announcement, and a different dialog for the actual call.
This is entirely legitimate. (But not all UACs will handle it
properly.)
Thanks,
Paul
> Regards
> Sanjiv
>
> ________________________________
>
> From: ext Attila Sipos [mailto:[email protected]]
> Sent: Friday, March 11, 2011 3:18 PM
> To: Jaiswal, Sanjiv (NSN - IN/Bangalore); ext ashok kumar
> Cc: [email protected]; Nitin Kapoor
> Subject: RE: [Sip-implementors] Different SDP Session Version in 183&
> 200 OK
>
>
>
>
> Hi Sanjiv,
>
> The behaviour you describe is not permitted.
>
> As Bob Penfield correctly said:
> There can be only one offer/answer in a single INVITE transaction. There
> can be a second offer/answer exchange on an early dialog (i.e. before
> the 200 on the INVITE), but that second offer/answer must be in a PRACK
> (scenario 5) or UPDATE (scenario 6) and only when the initial answer
> delivered in a reliable provisional response (scenario 3).
>
> Best Regards
>
> Attila
>
>
> -----Original Message-----
> From: Jaiswal, Sanjiv (NSN - IN/Bangalore)
> [mailto:[email protected]]
> Sent: Fri 11/03/2011 09:20
> To: ext ashok kumar; Attila Sipos
> Cc: [email protected]; Nitin Kapoor
> Subject: RE: [Sip-implementors] Different SDP Session Version in 183&
> 200 OK
>
> Hi Ashok,
>
> The SDP from 183 is considered as Answer of initial offer.
> Different SDP in 200 OK is considered as new offer and then it is must
> to send the ACK with SDP answer for second negotiation to successful.
>
> Regards
> Sanjiv
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of ext
> ashok kumar
> Sent: Friday, March 11, 2011 1:58 PM
> To: Attila Sipos
> Cc: [email protected]; Nitin Kapoor
> Subject: Re: [Sip-implementors] Different SDP Session Version in 183&
> 200 OK
>
> Hi Attila,
>
> Agree with you but what happens when 183 and 200 OK have different SDPs
> from
> the terminating endpoint. Then which SDP should be considered as an
> answer.
> RFC 3261 does not talk about this. And in case of Nitin's scenario, SDPs
> are
> different since session version is incremented (though all other
> contents
> remain same).
>
> Only when the same answer is placed in 18X and 200 then only the SDP in
> 18X
> will be considered as an answer.
>
> Please correct me if I'm wrong.
>
> Thanks,
> Ashok
>
>
> On Wed, Mar 9, 2011 at 7:40 PM, Attila Sipos
> <[email protected]>wrote:
>
>> 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
>
>
>
>
>
>
>
> .
>
> _______________________________________________
> 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
