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
