I agree.
Especially note that O/A adds a separate set of constraints. And this
can potentially cause some trouble.
Assume the invite contained an offer and the 180 contained an answer, so
that the o/a cycle is complete. The UPDATE might contain another offer,
or it might not. In some cases (i.e. when preconditions are in use) it
may be clear to both A and B that another o/a cycle is required before
the invite can complete. In that case the problem should not occur
because the 200 will be delayed awaiting satisfactory resolution of the
preconditions.
But if it appears that things are ready to go after the initial o/a, and
are simply awaiting an answer by B, then a new offer in the UPDATE can
be problematic. All the timing cases I mentioned earlier can occur. If
the new o/a results in a different media configuration, then the
ambiguity in understanding by the two sides will likely lead to
communication problems.
As a result, either A should refrain from making a new offer in this
case, or be very careful to make it in such a way that there will be no
ambiguities. And B must be very careful about its answer in the same
way. I don't have time to think through the issues right now, but it
seems that things might not be too bad if all A did in the second offer
was propose a subset of what was agreed to in the initial o/a. (But
don't hold me to that.)
Paul
B, Nataraju wrote:
> I don't agree with you.
>
> It's something like this.
>
> Soon after you receive a 1xx, UAC can send an UPDATE to modify the offer
> from what was sent in INVITE. At this point in time you are not allowed
> to send re-INVITE but UAC can only send an UPDATE.
>
> This is again constrained by offer-answer state machine also; I mean
> there can be only one outstanding offer-answer negotiation open at any
> point in time.
>
> This does not mandate, UPDATE should not be sent once the dialog is
> confirmed. You are allowed to send either UPDATE or re-INVITE, once the
> dialog is confirmed. It depends on particular applications; either
> UPDATE or re-INVITE would be sent out for session modification.
>
> Hope this clarifies your question.
>
> Some more points inline...
>
> Thanks,
> Nataraju A B
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
> [mailto:sip-implementors-
>> [EMAIL PROTECTED] On Behalf Of Chandra Sekhar Murthy M.V.V.
>> Sent: Thursday, April 12, 2007 3:52 PM
>> To: Nina Garaca; [EMAIL PROTECTED]
>> Subject: Re: [Sip-implementors] Question about UPDATE request
>>
>> Hi nina..,
>> First I want to tell something ..when UPDATE message can be sent..
>> After sending INVITE request..you can may or may not
> receive
>> provisional responces (1xx) ,you can send UPDATE message..but you
> should
>> not send UPDATE message after receiving successful response
>> (2xx)..because..when 200 ok is received for that INVITE request..then
>> Dialog will be established.as you send ACK message...
>> Finnaly you should not UPDATE message with in a dialog..
>>
>> Regards,
>> Chandra Sekhar Murthy M.v.v
>> [EMAIL PROTECTED]
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Nina
>> Garaca
>> Sent: Thursday, April 12, 2007 3:33 PM
>> To: [EMAIL PROTECTED]
>> Subject: [Sip-implementors] Question about UPDATE request
>>
>> Hi All,
>>
>> I have some questions regarding the UPDATE request:
>>
>> Q1: Is it a valid situation for UPDATE response (read response to
> UPDATE
>> request) to come after the 2xx final response to the initial INVITE?
>> Will it update the remote target of the dialog.
>> A B
>>
>> INVITE
>> |-------------------------------------->|
>> 180 rel
>> |<--------------------------------------| /Early dialog established/
>> PRACK
>> |-------------------------------------->|
>> 200 (PRACK)
>> |<--------------------------------------|
>> UPDATE
>> |-------------------------------------->|
>> 200 OK (INVITE)
>> |<--------------------------------------|
>> 200 OK (UPDATE)
>> |<--------------------------------------|
>>
> [ABN] all the transactions are completed independently.
> You are expected to receive 200-UPD after 200-INV.
>
> Yes it does update the remote target in success scenarios.
>
>> Q2: What is happening if this was non 2xx final response such as 408
> or
>> 481or maybe 491? This is very strange situation because 2xx to INVITE
>> has already established the confirmed dialog, and 408 or 481 to UPDATE
>> should tear down the dialog. 491 response should cause sending the
>> UPDATE once more. Am I right?
>>
> [ABN] ideally 2xx to INV and followed by 408/481 to UPD should lead to
> dialog termination, because soon after call acceptance the UAS might
> have switched off (this lead to 408). In general any request receives
> 408/481 should have an impact of the dialog also.
>
>> Q3: I understand that UPDATE shouldn't be used when confirmed dialog
> is
>> established, but still , what is happening if the final response to
>> reINVITE hasn't been received yet, is it valid to try to UPDATE the
>> dialog?
>>
> [ABN] Not exactly, see my comments above.
>
>> Q4: Q1 and Q2 in the case of reINVITE.
>>
>>
> [ABN] earlier points apply here also...
>
>> Thanks very match in advance.
>> Nina.
>>
>> --
>> Nina Garaca
>> Software Development & Testing
>>
>> ---
>>
>> "ZESIUM mobile" d.o.o.
>> Valentina Vodnika 8/9
>> 21000 Novi Sad
>> Serbia
>> Tel: +381 (0)21 472 15 48
>> Fax: +381 (0)21 472 15 49
>> Mob: +381 (0)63 16 15 891
>> E-mail: [EMAIL PROTECTED]
>>
>> _______________________________________________
>> 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
