Manpreet Singh wrote:
> Paul
>
> Thanks for the doc. It was very informative. The doc although stresses
> pretty much on 1xx-rel reponses for call flows. The question that came up
> was if the 18x ( non-reliable ) carried an answer A and then a 200OK carried
> B ( something that shouldnt happen ), which answer would the UAC ignore.
In the case, the UAS in non-compliant to the spec. There is usually no
attempt to specify behavior in non-compliant cases, so you can use your
judgment.
> Assuming that only a reliable response completes the offer/answer for the
> transaction, 18x should be ignored but then 18x has already been used for
> early media, so would that mean 200OK answer B will be ignored? But if
> answer B is ignored then would this be taken as complete offer/answer for
> INVITE transaction considering 18x was unreliable?
Somebody already pointed out some text that gives advice on this. (Use
the one from the 18x and ignore the one in the 2xx.) I know of devices
that use them both.
Which tactic you use depends on what kind of defect in the UAS you want
to survive.
> Also in the document, there is a part saying:
>
> In pattern 5, PRACK request can contain an offer only if the non-
> reliable response which it acknowledges contains an answer in the
> previous offer/answer exchange.
>
>
> Please correct me if I am wrong but why would a PRACK be used to acknowledge
> a non-reliable response? Isnt PRACK genereted when 100rel is sent in the 18x
> making it reliable?
Yeah, looks like a bug. Copying Takuya.
Paul
> Thanks
> Manpreet
>
> -----Original Message-----
> From: Paul Kyzivat
> To: Manpreet Singh
> Cc: Christer Holmberg (JO/LMF); [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [email protected]
> Sent: 7/19/2006 7:28 PM
> Subject: Re: [Sip-implementors] [SIPForum-discussion] Offer in a 200OK
> for
> Invite transaction.
>
> You should have a look at:
>
> http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeranswer
> -01.txt
>
> It would have answered this question, and may answer others you will
> encounter.
>
> Paul
>
> Manpreet Singh wrote:
>> Chris
>>
>> This answer was very helpful.
>>
>> So even when 18x carries the answer, till its reliable, the
> offer/answer is
>> not complete. Which means 200OK MUST carry the same answer again to
> complete
>> the offer/answer. So the 200OK SDP in this case would really be
> treated more
>> as an answer needed to complete the offer/answer for INVITE
> transaction and
>> both these answers MUST be identical right? Otherwise it would confuse
> the
>> UAC.
>>
>> Somesh, it will only ignore other responses if the 18x was reliable.
> But if
>> was not then it will expect the same answer to be followed in the
> 200OK to
>> complete the offer/answer for that transaction.
>>
>> Manpreet
>>
>> -----Original Message-----
>> From: Christer Holmberg (JO/LMF)
> [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, July 19, 2006 5:43 PM
>> To: [EMAIL PROTECTED]; Manpreet Singh; [EMAIL PROTECTED]
>> Cc: [email protected]
>> Subject: RE: [Sip-implementors] [SIPForum-discussion] Offer in a 200OK
>> forInvite transaction.
>>
>>
>> Hi,
>>
>> An unreliable 18x does not complete the offer/answer transaction
> (eventhough
>> you know what the answer is), so you can't send an new offer at that
> point.
>> Also, even if the 18x would be sent reliably, and complete the
> offer/answer
>> transaction, you can not send a new offer in the 200 OK. You can have
> at
>> most one offer/answer transaction per SIP transaction.
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Somesh
> S
>> Shanbhag
>> Sent: 20. heinäkuuta 2006 0:27
>> To: Manpreet Singh; [EMAIL PROTECTED]
>> Cc: [email protected]
>> Subject: Re: [Sip-implementors] [SIPForum-discussion] Offer in a 200OK
>> forInvite transaction.
>>
>> Hi Manpreet,
>>
>> RFC 3261 section 13.2.1 has the following clause ...
>>
>> "
>>
>> 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 "
>>
>> So, UAC MUST treat 183 session progress as the answer and shall ignore
> in
>> subsequent responses to INVITE.
>>
>> Hope this helps
>> Thanks
>> Somesh S. Shanbhag
>>
>>
>>
>> Manpreet Singh <[EMAIL PROTECTED]> wrote: For the INVITE
>> transaction where the offer was sent in an INVITE and the answer
> coming back
>> in 183, would it be valid to send a new offer in the 200OK? So the
>> question is whether the 200OK can be used to send a "new" Offer (
>> different from the answer in 183 ) for the INVITE transaction once
> 183 has
>> completed the offer/answer part of that transaction. Only UPDATE can
> be
>> used for early dialog changes as per my understanding and a 200OK
> still
>> constitutes early dialog so it wont be valid to send a new offer in
> 200OK?
>> Although 200OK can carry the same SDP as 183 which would mean
> nothing or
>> would not be considered as early dialog change in capability.
>>
>> Please correct me if I am wrong.
>>
>> Thanks
>>
>> Manpreet
>> _______________________________________________
>> discussion mailing list
>> [EMAIL PROTECTED]
>> http://sipforum.org/mailman/listinfo/discussion
>>
>>
>>
>> -----------------------------------------
>> SIMPLICITY IS THE BEAUTY.
>> BE NATURAL LIVE NATURAL.
>> -----------------------------------------
>> Somesh S. Shanbhag
>> Focus Area - VoIP Team (FA-VoIP)
>> Mascon Global Communication Technologies Enterprise of Mascon Global
> Limited
>> #59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070
> Karnataka
>> INDIA
>> Website: http://www.mgl.com/
>> -----------------------------------------
>>
>> ---------------------------------
>> Do you Yahoo!?
>> Get on board. You're invited to try the new Yahoo! Mail Beta.
>> _______________________________________________
>> 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
