RE: [Sipping] Question on ReInvite procedures

> -----Original Message-----
> From: sipping-admin@ietf.org
> [mailto:sipping-admin@ietf.org]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, August 30, 2001 11:41 PM
> To: 'Bert Culpepper'; 'Hemant Agrawal'; sipping@ietf.org
> Subject: RE: [Sipping] Question on ReInvite procedures
>
>
>
>
>
>
> > -----Original Message-----
> > From: Bert Culpepper [mailto:bert.culpepper@intervoice-brite.com]
> > Sent: Wednesday, August 22, 2001 5:15 PM
> > To: 'Hemant Agrawal'; sipping@ietf.org
> > 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.
>

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

> > 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
> jdrosen@dynamicsoft.com                     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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP