Subject: [Sipping] Explanation for semantics of "a new modification" //: RE: About "rollback of re-Invite"

From: [email-masked]
Date: Tue, 17 Feb 2009 14:16:14 +0800

What is a new modification? This is another good question people once 
asked.
Without clear definition for extension, anything or its combination 
defined in chapter 8 of RFC3264 MUST be treated as a new modification, 
that is:
Adding a Media Stream, 
Removing a Media Stream, 
Modifying a Media Stream, 
Putting a Unicast Media Stream on Hold(or from on hold to active)
"Modifying a Media Stream" can be further divided into:
Modifying Address, Port or Transport, 
Changing the Set of Media Formats, 
Changing Media Types, 
Changing Attributes.

And if we can say something form a nested transaction, there MUST be 
correspond definition. In RFCs, there are two of such definition:
1. Precondition
It is defined in RFC3312(Quality-of-Service 
precondition)\4032(Precondition Framework)\5027(Security Preconditions), 
and the suspending\resuming semantic of session modification is clear. So, 
it is a typical nested transaction.

2. Intuitionistic(user point of view) requirement for rejecting session 
modification
It is defined in RFC3261. From users's point of view, it is a kind of late 
committment. And it is useful for users to rejecting session modification.

3. 3GPP usage of Offer/Answer to refine(reduce) codec set
In chapter 8.3.2 of RFC3264, refining(reduce) codec set is a kind of 
modification, and there is no definition as RFC3312 to define 
sub-transaction concept. So, I do not think this kind of Offer/Answer can 
be treated as sub-transaction of the original one in semantics of current 
RFCs.
And if one side send a new UPDATE during the pending Re-INVITE, the other 
side can has two choose:
o if the UA can accept the UPDATE, and after Offer/Answer, the 
modification MUST be committed.
o if the UA can not accept the UPDATE(for example, can not accept it 
without the user's permition), the UA MUST reject UPDATE. 
I MUST point out that in RFCs semantics, the third rule should be omitted.

But 3GPP really has such usage. And I think the original requirement of 
obeys the concept of nested transaction, so I list it here. 

And the classification of a new modification is quit simple. At list, it 
is not harder than the judgement of whether Precondition has been 
satisfied.

--------------------------------------------------------
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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Feb 2009 07:33:53 +0100

Hi,
 
I am a little confused about the statements about the "3GPP usage".
 
I don't think the "refine codec set" use-case is 3GPP specific. Anyone
can refine/reduce the codecs, after one has learned what set of codecs
both ends support.
 
Also, I am not sure whether "user permission" is needed in order to
refine the codec set. Users normally don't care (they shouldn't have to
care) what codecs are used.
 
So, in my opinion the 3GPP use-case is part of the "Modifying a Media
Stream" case.
 
Regards,
 
Christer

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 17. helmikuuta 2009 8:16
	To: Christer Holmberg
	Cc: [email-masked]
	Subject: Explanation for semantics of "a new modification" //:
RE: About "rollback of re-Invite"

	What is a new modification? This is another good question people
once asked. 
	Without clear definition for extension, anything or its
combination defined in chapter 8 of RFC3264 MUST be treated as a new
modification, that is: 
	Adding a Media Stream, 
	Removing a Media Stream, 
	Modifying a Media Stream, 
	Putting a Unicast Media Stream on Hold(or from on hold to
active) 
	"Modifying a Media Stream" can be further divided into: 
	Modifying Address, Port or Transport, 
	Changing the Set of Media Formats, 
	Changing Media Types, 
	Changing Attributes. 
	
	And if we can say something form a nested transaction, there
MUST be correspond definition. In RFCs, there are two of such
definition: 
	1. Precondition 
	It is defined in RFC3312(Quality-of-Service
precondition)\4032(Precondition Framework)\5027(Security Preconditions),
and the suspending\resuming semantic of session modification is clear.
So, it is a typical nested transaction. 
	
	2. Intuitionistic(user point of view) requirement for rejecting
session modification 
	It is defined in RFC3261. From users's point of view, it is a
kind of late committment. And it is useful for users to rejecting
session modification. 

	3. 3GPP usage of Offer/Answer to refine(reduce) codec set 
	In chapter 8.3.2 of RFC3264, refining(reduce) codec set is a
kind of modification, and there is no definition as RFC3312 to define
sub-transaction concept. So, I do not think this kind of Offer/Answer
can be treated as sub-transaction of the original one in semantics of
current RFCs. 
	And if one side send a new UPDATE during the pending Re-INVITE,
the other side can has two choose: 
	o if the UA can accept the UPDATE, and after Offer/Answer, the
modification MUST be committed. 
	o if the UA can not accept the UPDATE(for example, can not
accept it without the user's permition), the UA MUST reject UPDATE. 
	I MUST point out that in RFCs semantics, the third rule should
be omitted. 
	
	But 3GPP really has such usage. And I think the original
requirement of obeys the concept of nested transaction, so I list it
here. 
	
	And the classification of a new modification is quit simple. At
list, it is not harder than the judgement of whether Precondition has
been satisfied. 

	--------------------------------------------------------
	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.

---

From: [email-masked]
Date: Tue, 17 Feb 2009 15:15:01 +0800

Dear Christer Holmberg

Perhaps the sequence of my representation makes the misconceive :).

I mean this:

Not considering the 3GPP usage, we have the same point of view. That is: 
"refine codec set"  is part of the "Modifying a Media Stream".   

Then let us discuss more on the 3GPP usage. Considering preconditon and 
"refine codec set":

F1: adding new media stream such as vedio. And the UA can not accept the 
modification without the user's permition.
F3: "refine codec set"
As precondition is used, the user will only be notified(usually with a new 
notification of small windows). But when it recv F3("refine codec set") ,
if UA treats it as a new modification, it can not accept it at once. So, 
it should be rejected with 504.

      UAC                    UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         |
       |-------------------->|
       | F4 2xx UPT          |
       |<--------------------|
       |                     |
       | F5 180 ringing      |
       |<--------------------|
       |                     |
       | F6 4xx/5xx/6xx INV  |
       |<--------------------|
       | F7     ACK          |
       |-------------------->|
       |                     |

To make the sequences(which usually used in 3GPP) mentioned above 
effective, I think we should point it out that the Offer/Answer pair in 
F3/F4(only "refine codec set" or precondition) is part of the one 
triggered by Re-INVITE(F1). I need to point out that the definition of 
this perhaps should be issued by 3GPP.

I think if omitting the third rule, the draft may be more clear and 
simple. But I think as we talked about the problem, any well known 
situation should be considered.
But I am not participant of 3GPP, so I am waiting for your comments.

Gaoyang

"Christer Holmberg" <[email-masked]> 
2009-02-17 14:33

收件人
<[email-masked]>
抄送
<[email-masked]>
主题
RE: Explanation  for semantics of "a new modification"  //: RE: About 
"rollback of re-Invite" - 3GPP usage

Hi,

I don't think the "refine codec set" use-case is 3GPP specific. Anyone can 
refine/reduce the codecs, after one has learned what set of codecs both 
ends support.
 
Also, I am not sure whether "user permission" is needed in order to refine 
the codec set. Users normally don't care (they shouldn't have to care) 
what codecs are used.

Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: 17. helmikuuta 2009 8:16
To: Christer Holmberg
Cc: [email-masked]
Subject: Explanation for semantics of "a new modification" //: RE: About 
"rollback of re-Invite"

--------------------------------------------------------
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.

---

From: [email-masked]
Date: Tue, 17 Feb 2009 15:31:43 +0800

Dear Christer Holmberg

I am agree with you that "refining/choosing the codec" should not be "user 
permission" issue if the there is no special billing policy for codecs.

The "user permission" is about things such as adding of media type.
The modification triggered by F1/F2 is not committed by user, then the 
same one(as a new modification) triggered by F3/F4 can not be acceptted by 
UA itself.

And it is restricted that only  "refining the codec" can be treated as 
sub-transaction of the origianl one, "adding the codec" is not.

Gaoyang

UAC                    UAS
       | session established |
       |<===================>|
       |                     |
       | F1  re-INVITE (SDP) |
       |-------------------->|
       | F2 1xx-rel (SDP)    |
       |<--------------------|
       | F3   UPDATE         |
       |-------------------->|
       | F4 2xx UPT          |
       |<--------------------|
       |                     |
       | F5 180 ringing      |
       |<--------------------|
       |                     |
       | F6 4xx/5xx/6xx INV  |
       |<--------------------|
       | F7     ACK          |
       |-------------------->|
       |                     |

收件人
<[email-masked]>
抄送
<[email-masked]>
主题

Hi,

 

Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 17 Feb 2009 08:54:04 +0100

Hi,	

>I am agree with you that "refining/choosing the codec" should not be "user permission" issue if the there is no special billing policy for codecs. 
>	
>The modification triggered by F1/F2 is not committed by user, then the same one(as a new modification) triggered by F3/F4 can not be acceptted by UA itself. 
>	
>And it is restricted that only  "refining the codec" can be treated as sub-transaction of the origianl one, "adding the codec" is not. 

My issue is that it will be impossible to make sure everyone has a common understanding of what a "sub-transaction" is, and what isn't, and you will end up with interoperability problems - unless you come up with a generic and easy to understand/apply rule.

For example, if I change some properties (ptime etc) for an existing codec, is that always a sub-transaction, is it sometimes a sub-transaction, or is it never a sub-transaction?

Also, assume I use pre-conditions, and add a stream. But, the re-INVITE is then rejected. Now, since this is a "nested transaction", I assume you propose that a full fallback would be performed in this case?

Regards,

Christer

	Gaoyang 
	
	UAC                    UAS 
	       | session established | 
	       |<===================>| 
	       |                     | 
	       | F1  re-INVITE (SDP) | 
	       |-------------------->| 
	       | F2 1xx-rel (SDP)    | 
	       |<--------------------| 
	       | F3   UPDATE         | 
	       |-------------------->| 
	       | F4 2xx UPT          | 
	       |<--------------------| 
	       |                     | 
	       | F5 180 ringing      | 
	       |<--------------------| 
	       |                     | 
	       | F6 4xx/5xx/6xx INV  | 
	       |<--------------------| 
	       | F7     ACK          | 
	       |-------------------->| 
	       |                     | 

	2009-02-17 14:33 

		收件人
		<[email-masked]> 
		抄送
		<[email-masked]> 
		主题
		RE: Explanation  for semantics of "a new modification"  //: RE: About "rollback of re-Invite" - 3GPP usage

	Hi, 

	I don't think the "refine codec set" use-case is 3GPP specific. Anyone can refine/reduce the codecs, after one has learned what set of codecs both ends support. 
	  
	Also, I am not sure whether "user permission" is needed in order to refine the codec set. Users normally don't care (they shouldn't have to care) what codecs are used. 
	  
	So, in my opinion the 3GPP use-case is part of the "Modifying a Media Stream" case. 
	  
	Regards, 
	  
	Christer 

	

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 17. helmikuuta 2009 8:16
	To: Christer Holmberg
	Cc: [email-masked]
	Subject: Explanation for semantics of "a new modification" //: RE: About "rollback of re-Invite"

	What is a new modification? This is another good question people once asked. 
	Without clear definition for extension, anything or its combination defined in chapter 8 of RFC3264 MUST be treated as a new modification, that is: 
	Adding a Media Stream, 
	Removing a Media Stream, 
	Modifying a Media Stream, 
	Putting a Unicast Media Stream on Hold(or from on hold to active) 
	"Modifying a Media Stream" can be further divided into: 
	Modifying Address, Port or Transport, 
	Changing the Set of Media Formats, 
	Changing Media Types, 
	Changing Attributes. 
	
	And if we can say something form a nested transaction, there MUST be correspond definition. In RFCs, there are two of such definition: 
	1. Precondition 
	It is defined in RFC3312(Quality-of-Service precondition)\4032(Precondition Framework)\5027(Security Preconditions), and the suspending\resuming semantic of session modification is clear. So, it is a typical nested transaction. 
	
	2. Intuitionistic(user point of view) requirement for rejecting session modification 
	It is defined in RFC3261. From users's point of view, it is a kind of late committment. And it is useful for users to rejecting session modification. 

	3. 3GPP usage of Offer/Answer to refine(reduce) codec set 
	In chapter 8.3.2 of RFC3264, refining(reduce) codec set is a kind of modification, and there is no definition as RFC3312 to define sub-transaction concept. So, I do not think this kind of Offer/Answer can be treated as sub-transaction of the original one in semantics of current RFCs. 
	And if one side send a new UPDATE during the pending Re-INVITE, the other side can has two choose: 
	o if the UA can accept the UPDATE, and after Offer/Answer, the modification MUST be committed. 
	o if the UA can not accept the UPDATE(for example, can not accept it without the user's permition), the UA MUST reject UPDATE. 
	I MUST point out that in RFCs semantics, the third rule should be omitted. 
	
	But 3GPP really has such usage. And I think the original requirement of obeys the concept of nested transaction, so I list it here. 
	
	And the classification of a new modification is quit simple. At list, it is not harder than the judgement of whether Precondition has been satisfied.

---

From: [email-masked]
Date: Tue, 17 Feb 2009 16:07:10 +0800

Dear Christer Holmberg:

I mentioned that:
Without clear definition for extension, anything or its combination 
defined in chapter 8 of RFC3264 MUST be treated as a new modification.
It is clear. 

Gaoyang

2009-02-17 15:54

收件人
<[email-masked]>
抄送
<[email-masked]>
主题
RE: RE: Explanation  for semantics of "a new modification"  //: RE: About 
"rollback of re-Invite" - 3GPP usage

Hi, 

>I am agree with you that "refining/choosing the codec" should not be 
"user permission" issue if the there is no special billing policy for 
codecs. 

My issue is that it will be impossible to make sure everyone has a common 
understanding of what a "sub-transaction" is, and what isn't, and you will 
end up with interoperability problems - unless you come up with a generic 
and easy to understand/apply rule.

For example, if I change some properties (ptime etc) for an existing 
codec, is that always a sub-transaction, is it sometimes a 
sub-transaction, or is it never a sub-transaction?

Also, assume I use pre-conditions, and add a stream. But, the re-INVITE is 
then rejected. Now, since this is a "nested transaction", I assume you 
propose that a full fallback would be performed in this case?

Regards,

Christer

                 Gaoyang 
 
                 UAC                    UAS 
                        | session established | 
                        |<===================>| 
                        |                     | 
                        | F1  re-INVITE (SDP) | 
                        |-------------------->| 
                        | F2 1xx-rel (SDP)    | 
                        |<--------------------| 
                        | F3   UPDATE         | 
                        |-------------------->| 
                        | F4 2xx UPT          | 
                        |<--------------------| 
                        |                     | 
                        | F5 180 ringing      | 
                        |<--------------------| 
                        |                     | 
                        | F6 4xx/5xx/6xx INV  | 
                        |<--------------------| 
                        | F7     ACK          | 
                        |-------------------->| 
                        |                     | 

                 2009-02-17 14:33 

                                 收件人
                                 <[email-masked]> 
                                 抄送
                                 <[email-masked]> 
                                 主题
                                 RE: Explanation  for semantics of "a new 
modification"  //: RE: About "rollback of re-Invite" - 3GPP usage

                 Hi, 
 
                 I am a little confused about the statements about the 
"3GPP usage". 
 
                 I don't think the "refine codec set" use-case is 3GPP 
specific. Anyone can refine/reduce the codecs, after one has learned what 
set of codecs both ends support. 
 
                 Also, I am not sure whether "user permission" is needed 
in order to refine the codec set. Users normally don't care (they 
shouldn't have to care) what codecs are used. 
 
                 So, in my opinion the 3GPP use-case is part of the 
"Modifying a Media Stream" case. 
 
                 Regards, 
 
                 Christer 

 

                 From: [email-masked] [mailto:[email-masked]] 
                 Sent: 17. helmikuuta 2009 8:16
                 To: Christer Holmberg
                 Cc: [email-masked]
                 Subject: Explanation for semantics of "a new 
modification" //: RE: About "rollback of re-Invite"

                 What is a new modification? This is another good question 
people once asked. 
 
                 And if we can say something form a nested transaction, 
there MUST be correspond definition. In RFCs, there are two of such 
definition: 
                 1. Precondition 
                 It is defined in RFC3312(Quality-of-Service 
precondition)\4032(Precondition Framework)\5027(Security Preconditions), 
and the suspending\resuming semantic of session modification is clear. So, 
it is a typical nested transaction. 
 
                 2. Intuitionistic(user point of view) requirement for 
rejecting session modification 
                 It is defined in RFC3261. From users's point of view, it 
is a kind of late committment. And it is useful for users to rejecting 
session modification. 

                 In chapter 8.3.2 of RFC3264, refining(reduce) codec set 
is a kind of modification, and there is no definition as RFC3312 to define 
sub-transaction concept. So, I do not think this kind of Offer/Answer can 
be treated as sub-transaction of the original one in semantics of current 
RFCs. 
                 And if one side send a new UPDATE during the pending 
Re-INVITE, the other side can has two choose: 
                 o if the UA can accept the UPDATE, and after 
Offer/Answer, the modification MUST be committed. 
                 o if the UA can not accept the UPDATE(for example, can 
not accept it without the user's permition), the UA MUST reject UPDATE. 
                 I MUST point out that in RFCs semantics, the third rule 
should be omitted. 
 
                 But 3GPP really has such usage. And I think the original 
requirement of obeys the concept of nested transaction, so I list it here. 

                 And the classification of a new modification is quit 
simple. At list, it is not harder than the judgement of whether 
Precondition has been satisfied. 
 
                 --------------------------------------------------------
                 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.

                 --------------------------------------------------------
                 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.

---

From: [email-masked]
Date: Tue, 17 Feb 2009 16:26:25 +0800

Dear Christer Holmberg:

And I once talked about  the way "Offer/Answer committed at once". I said 
a joke that: if Offer/Answer just committed no matter what the final 
response(of Re-INVITE) is will make Re-INVITE behaves just like UPDATE. 
Then why we still need Re-INVITE anymore. I don't think it is siutable 
make Re-INVITE disabled.

Modification is inherent transactional. The early stage of banking system 
did not use transaction in its process of modification of data, but now 
they all use it.
The reason is that transaction can meet the demand of more and more 
complex modification process.

Session modification in the future can be same. And what we need is a 
robust solution, not as simple as better :).

And there is really no invention or violation of current RFCs in my draft. 

Gaoyang

收件人
<[email-masked]>
抄送
<[email-masked]>
主题

Hi, 

Regards,

Christer

                 Gaoyang 
 
                 UAC                    UAS 
                        | session established | 
                        |<===================>| 
                        |                     | 
                        | F1  re-INVITE (SDP) | 
                        |-------------------->| 
                        | F2 1xx-rel (SDP)    | 
                        |<--------------------| 
                        | F3   UPDATE         | 
                        |-------------------->| 
                        | F4 2xx UPT          | 
                        |<--------------------| 
                        |                     | 
                        | F5 180 ringing      | 
                        |<--------------------| 
                        |                     | 
                        | F6 4xx/5xx/6xx INV  | 
                        |<--------------------| 
                        | F7     ACK          | 
                        |-------------------->| 
                        |                     | 

                 2009-02-17 14:33 

                                 收件人
                                 <[email-masked]> 
                                 抄送
                                 <[email-masked]> 
                                 主题

                 Hi, 

 

                 Regards, 
 
                 Christer

---

From: [email-masked]
Date: Tue, 17 Feb 2009 17:24:05 +0800

Dear Christer Holmberg

In fact, omitting the "3GPP usage", the solution in my draft have the same 
effect with your.

Combination of yours and mine, "3GPP usage":
o if the UA can accept the UPDATE, and after Offer/Answer, the 
modification MUST be committed. This obeys your way.
o if the UA can not accept the UPDATE(for example, can not accept it 
without the user's permition), the UA MUST reject UPDATE. This is also 
without violation of your way.

And the nested transaction concept of "precondition" and "late commitment 
of 200OK of Re-INVITE" is clear now.
And most important, the door is opened for envolution and extension in the 
future.

I am waiting for your comments on the combination.

Gaoyang

收件人
<[email-masked]>
抄送
<[email-masked]>
主题

Hi, 

Regards,

Christer

                 Gaoyang 
 
                 UAC                    UAS 
                        | session established | 
                        |<===================>| 
                        |                     | 
                        | F1  re-INVITE (SDP) | 
                        |-------------------->| 
                        | F2 1xx-rel (SDP)    | 
                        |<--------------------| 
                        | F3   UPDATE         | 
                        |-------------------->| 
                        | F4 2xx UPT          | 
                        |<--------------------| 
                        |                     | 
                        | F5 180 ringing      | 
                        |<--------------------| 
                        |                     | 
                        | F6 4xx/5xx/6xx INV  | 
                        |<--------------------| 
                        | F7     ACK          | 
                        |-------------------->| 
                        |                     | 

                 2009-02-17 14:33 

                                 收件人
                                 <[email-masked]> 
                                 抄送
                                 <[email-masked]> 
                                 主题

                 Hi, 

 

                 Regards, 
 
                 Christer

---

From: [email-masked]
Date: Tue, 17 Feb 2009 20:00:25 +0800

Dear Christer Holmberg

I showed the drawbacks of "Offer/Answer committed at once"  in another 
draft. I want to reaffirm that:

o rude commit pending state becasue of precondition not OK.

o commit state the user just want to reject.

o ignore the session state(which can be rollbacked to) that can assure the 
continuity of session.

o closed the door for envolution and extension of nested-transactional 
usages in the future.

And with combination of yours and mine, all the problem mentioned above is 
not exsit. And the combination obeys the issue 3GPP concerns.

I think it makes the best of both worlds.

Gaoyang

收件人
<[email-masked]>
抄送
<[email-masked]>
主题

Hi, 

Regards,

Christer

                 Gaoyang 
 
                 UAC                    UAS 
                        | session established | 
                        |<===================>| 
                        |                     | 
                        | F1  re-INVITE (SDP) | 
                        |-------------------->| 
                        | F2 1xx-rel (SDP)    | 
                        |<--------------------| 
                        | F3   UPDATE         | 
                        |-------------------->| 
                        | F4 2xx UPT          | 
                        |<--------------------| 
                        |                     | 
                        | F5 180 ringing      | 
                        |<--------------------| 
                        |                     | 
                        | F6 4xx/5xx/6xx INV  | 
                        |<--------------------| 
                        | F7     ACK          | 
                        |-------------------->| 
                        |                     | 

                 2009-02-17 14:33 

                                 收件人
                                 <[email-masked]> 
                                 抄送
                                 <[email-masked]> 
                                 主题

                 Hi, 

 

                 Regards, 
 
                 Christer