Subject: RE: [SIP] 3PCC and the re-invite response

From: Igor Slepchin <[email-masked]>
Date: Fri, 1 Dec 2000 16:53:12 -0500

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> 
> My post was to solve the SDP exchange loop
> problem of using 3pcc to pull the subscribers
> off of hold.
> 
> Otherwise, the flow in the following post works.
> http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html
> 

What I'm saying is that I don't see this as a problem with 3pcc at all.
Given Figure 1 in
http://search.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-01.txt, why
would A change the media in 200OK to the second INVITE? Instead of inventing
workarounds for eccentric UAs, it would be much easier to define what a
"sane" UA can and cannot do (e.g., it cannot change SDP just because it
received a re-INVITE, there should be another valid reason for the change).

---
Igor Slepchin

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 18:28:48 -0500

> received a re-INVITE, there should be another valid reason for the
change).

The main reason during call setup is because
codecs and other stuff may not have been
fully negotiated.  Another reason is because
many current UA's respond to hold SDP with
hold SDP.  Thus both sides would be passing
hold SDP with 0.0.0.0 as connection addresses,
and the call would not get established.

After a call has been established, the
SDP-change-loop can occur if one of the sides
chooses not to use the SDP information that it
used prior to the hold.  Many current
implementation tend to use a different port when
coming off hold, thus the race condition tends
to occur often.