interworking(2/2) of INVITE and UPDATE
OKUMURA Shinji <[email protected]> Thu, 22 Apr 2010 17:23:18 +0900
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
Hi all,
>At this chance, I want to hear your opinion about the
>interworking of INVITE and UPDATE.
>
>This is related to chapter 4 in a offeranswer draft,
5.2 Receiving an UPDATE
There are 3 cases described in the text.
- A UAS that receives an UPDATE before it has generated a final
response to a previous UPDATE on the same dialog MUST return a 500
response to the new UPDATE.
A B
| |
|UPDATE CSeq:m |
|------------------------------>|
|UPDATE CSeq:n(>m) |
|==============================>|
| 500 (UPDATE CSeq:n)|
|<==============================|
| |
- If an UPDATE is received that contains an offer, and the UAS has
generated an offer (in an UPDATE, PRACK or INVITE) to which it has
not yet received an answer, the UAS MUST reject the UPDATE with a 491
response.
A B
| |
| offer0| (in an UPDATE, PRACK or INVITE)
|<------------------------------|
|UPDATE(offer1) |
|==============================>|
| 491 (UPDATE)|
|<==============================|
| |
- Similarly, if an UPDATE is received that contains an
offer, and the UAS has received an offer (in an UPDATE, PRACK, or
INVITE) to which it has not yet generated an answer, the UAS MUST
reject the UPDATE with a 500 response.
A B
| |
|offer0 | (in an UPDATE, PRACK or INVITE)
|------------------------------>|
|UPDATE(offer1) |
|==============================>|
| 500 (UPDATE)|
|<==============================|
| |
I am interested in the following cases that is not described clearly.
INVITE(no offer) and UPDATE(offer)
A B
| |
|reINVITE(no offer) |
|------------------------------>|
|UPDATE(offer1) |
|==============================>|
| 500 (UPDATE)|
|<==============================|
| |
IMO UA-B should reject the UPDATE with 500.
A B
| |
| reINVITE(no offer)|
|<------------------------------|
|UPDATE(offer1) |
|==============================>|
| 491 (UPDATE)|
|<==============================|
| |
IMO UA-B should reject the UPDATE with 491.
A B
| |
|UPDATE(offer1) |
|------------------------------>|
|reINVITE(no offer) |
|==============================>|
| 500 (INVITE)|
|<==============================|
| |
IMO UA-B should reject the UPDATE with 500.
A B
| |
| UPDATE(offer1)|
|<------------------------------|
|reINVITE(no offer) |
|==============================>|
| 491 (INVITE)|
|<==============================|
| |
IMO UA-B should reject the UPDATE with 491.
A B
| |
| reINVITE(no offer)|
|<------------------------------|
|1xx-rel(offer0) |
|------------------------------>|
|UPDATE(offer1) |
|==============================>|
| 491 (UPDATE)|
|<==============================|
| |
IMO UA-B should reject the UPDATE with 491.
A B
| |
|reINVITE(no offer) |
|------------------------------>|
| 1xx-rel(offer0)|
|<------------------------------|
|UPDATE(offer1) |
|==============================>|
| 500 (UPDATE)|
|<==============================|
| |
IMO UA-B should reject the UPDATE with 500.
Certainly in all cases UA A should not send a request
(UPDATE or reINVITE) that is probably rejected.
Do you have any questions or comments?
Just to be sure these are BCPs.
Regards,
Shinji
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP