Explanation for "draft-gaoyang-sipping-session-state-criterion-01.txt"-2009/02/16-1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




1. Recommendation of signal flow
For usage of SIP/SDP, UA is better to avoid triggering a new modification of session while the previous one is in pending state.

For examples, when UAC want to triggering a new modification, it should Cancel the current Re-INVITE, and then trigger a new Re-INVITE(F11):

UAC                   UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         | <- UPDATE request include state
       |-------------------->|    notification
       | F4 2xx UPT          |
       |<--------------------|
       |                     |
       | F5 180 ringing      |
       |<--------------------|
       |                     |
       | F6   Cancel         |
       |-------------------->| <- UAC request termination of Re-INVITE
       | F7    2xx           |
       |<--------------------|
       | F8   487 INV        |
       |<--------------------| <- final response of Re-INVITE
       | F9     ACK          |
       |-------------------->|
       |                     |
       | F11  re-INVITE (SDP)|
       |-------------------->| <- Re-INVITE request inclue a new
                                 modification

And when UAS want to triggering a new modification, it can just send 4xx to current Re-INVITE, and then trigger a new Re-INVITE.

2. Why UPDATE during INVITE has no such ambiguous state of session as Re-INVITE?
Unsuccessful INVITE will terminate session and dialog, so it is meaningless to talk about session state after unsuccessful INVITE.
But unsuccessful Re-INVITE will not terminate session and dialog, so it is meaningful to talk about session state after unsuccessful Re-INVITE.

3. Triggering a new modification while the previous one is in pending state
The behavior like this is unfriendly(or immoderate), but legal. But while the new modification is committed, the previous one in pending state MUST be discarded.

===================================
高扬/固网软件开发一部/中心研究院/中兴通讯
Tel    : 87211
MSN    : tzgynew@xxxxxxxxxxx
e_mail : gao.yang2@xxxxxxxxxx
Addr   :南京市雨花台区紫荆花路68号 210012
===================================

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux