[SIPForum-discussion] [Sip-implementors] Offer in a 200OK for Invite transaction.
Manpreet Singh
msingh at ibasis.net
Thu Jul 20 14:03:50 UTC 2006
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.
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?
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?
Thanks
Manpreet
-----Original Message-----
From: Paul Kyzivat
To: Manpreet Singh
Cc: Christer Holmberg (JO/LMF); someshss at yahoo.com; discussion at sipforum.org;
sip-implementors at cs.columbia.edu
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:christer.holmberg at ericsson.com]
> Sent: Wednesday, July 19, 2006 5:43 PM
> To: someshss at yahoo.com; Manpreet Singh; discussion at sipforum.org
> Cc: sip-implementors at cs.columbia.edu
> 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: sip-implementors-bounces at cs.columbia.edu
> [mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of Somesh
S
> Shanbhag
> Sent: 20. heinäkuuta 2006 0:27
> To: Manpreet Singh; discussion at sipforum.org
> Cc: sip-implementors at cs.columbia.edu
> 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 <msingh at ibasis.net> 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
> discussion at sipforum.org
> 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
> Sip-implementors at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20060720/0853bede/attachment-0005.html>
More information about the discussion
mailing list