Subject: ??: [Sip] Questions regarding Offer/Answer model...

From: "Chen Zaifeng,BISC TD DEW5(BJ)" <[email-masked]>
Date: Tue, 15 Apr 2003 09:45:44 +0800

See my understanding inline.

>  -----????-----
> ???: 	Patrick Lam [mailto:[email-masked]] 
> ????:	Monday, April 14, 2003 1:09 PM
> ???:	[email-masked]
> ??:	[Sip] Questions regarding Offer/Answer model...
> 
> Dear all:
> 
> On p.80 of RFC 3261, it states that:
> 
> "> If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE.  For this specification, that is only the final 2xx response to that INVITE.  That same exact answer MAY also be placed in any provisional responses sent prior to the answer.  The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.> "> 
> 
> My questions are:
> 1.	Is the answer from 1xx valid then???  If so, why does it state that the answer can only be present in 2xx on one hand, but on the other hand if the answer is present in 1xx, the answers from 2xx must be ignored??? 
[Chen Zaifeng,BISC TD DEW5(BJ)]  
1xx is valid, of course, and:
Firstly, the 2xx must contain an answer
Secondly, the 1xx non-reliable may contain an answer, but must be the same as the one in 2xx
Lastly, The UAC will accept the first answer which might in 2xx or 1xx (the same answer)
Therefore, I think the description picked out from rfc3261 has nothing to do with rfc3262 
> 2.	What about the UAS > "> changes> ">  its mind on the answer after it sends 1xx response (e.g. the callee answers the call from a different UA), and wants to incorporate the changes into 2xx responses????
[Chen Zaifeng,BISC TD DEW5(BJ)]
UAS can not changes its mind...
P80 of RFC 3261:
 o  Once the UAS has sent or received an answer to the initial
     offer, it MUST NOT generate subsequent offers in any responses
     to the initial INVITE.  This means that a UAS based on this
     specification alone can never generate subsequent offers until
     completion of the initial transaction.
> 3.	Can 100 Trying carry > '> answers> "> ?
[Chen Zaifeng,BISC TD DEW5(BJ)]  
I think it can not.
100 trying is an unreliable "automatic response" that is generated  by transaction layer,
it might not be aware of session description which provided by TU, check 17.2.1 of rfc3261
for more.
And, P183, 21.1.1 of rfc3261:
The 100 (Trying) response is different from other provisional responses, in that it is never
forwarded upstream by a stateful proxy.
 
> Thanks very much in advance,
> 
> Patrick
> 
> 
> 
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Nataraju A.B." <[email-masked]>
Date: Tue, 15 Apr 2003 08:10:37 +0530

The comments inline...
  ----- Original Message ----- 
  From: Chen Zaifeng,BISC TD DEW5(BJ) 
  To: 'Patrick Lam' ; [email-masked] 
  Sent: Tuesday, April 15, 2003 7:15 AM
  Subject: ??: [Sip] Questions regarding Offer/Answer model...

  [Nataraju A.B.]
  The SDP parameters carried in the 1xx response should be same as that could be carried in teh 2xx response. since SDP parameters to be sent back is same in both the states. This also can be justified by the fact that the SDP parameters are all preconfigured one's. The same info is available when UAS is replying back with alerting indication(180 RINGING ) OR connect request(200 OK)

  [Nataraju A.B.]
  Chen Zaifeng's comments are correct, since the information available in TU will be same in both the alerting indication (180 RINGING ) state as well as connect request(200 OK)