Subject: RE: [Sipping] Question on ReInvite procedures

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Aug 2001 23:41:17 -0400

> -----Original Message-----
> From: Bert Culpepper [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2001 5:15 PM
> To: 'Hemant Agrawal'; [email-masked]
> Subject: RE: [Sipping] Question on ReInvite procedures
> 
> 
> This kind of behavior is discussed in draft-rosenberg-sip-3pcc-01.txt.
> It STRONGLY RECOMMENDs that UAs do not change their address and port
> assignments in responses to re-INVITEs when asked to change 
> the address
> and port they send media to. 

Actually, I do not think that the 3pcc document actually makes this
recommendation, nor does bis, as I can recall. At one time, we discussed
this as a strong recommendation in order to enable flow 2 from 3pcc. But,
since it was generally agreed that you can't REQUIRE this behavior,
especially when codec changes are involved, so flow 2 was not recommended.
Neither of the two recommended flows rely on a UA maintaining the same SDP.
Thus, while keeping the same address/port is probably a good idea, it is not
needed for the recommended 3pcc flows.

> RFC2543bis touches 
> on this in
> appendix B but for a little different scenario.  That is, 
> re-INVITE w/o
> SDP, 200 with "previous SDP" (offer), and ACK with SDP 
> (answer).  In the
> first paragraph of section B.4 it states "... the offerer SHOULD offer
> the same SDP it provided previously if it has no reason to change
> anything." 

Well, this scenario is a bit different. Here, we are talking about a
"triggered offer", where the UA is prodded into making an offer. In the case
above, we are talking about an answer to an offered SDP. 

> It's up to implementers to comply with the recommendation
> above for 3pcc to work.

No, as I said, flow 2 is not recommended so you don't need this behavior.
What is needed is the ability to accept INVITE w/o SDP, since this is the
cornerstone of flows 1 and 3. When people ask me what is the most important,
yet most frequently overlooked SIP capability to implement in a UA, it is
that. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Bert Culpepper" <[email-masked]>
Date: Fri, 31 Aug 2001 12:29:13 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, August 30, 2001 11:41 PM
> To: 'Bert Culpepper'; 'Hemant Agrawal'; [email-masked]

I see the recommendation I referred to has been removed in the 02 version of
the I-D.  (I must do better at keeping up with the revisions :).