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

From: Igor Slepchin <[email-masked]>
Date: Fri, 1 Dec 2000 21:00:37 -0500

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

If that's the case, scenario in Figure 1 of the 3pcc draft will not work no
matter how much we try to fix it. In particular, that would mean that
http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html won't work as
well, since both A and B would keep returning "on hold" SDP to the 3pcc
forever. Hence, automatically putting other party on hold just because you
were put on hold sounds like very wrong behavior. Just as you say in another
email, some phones return on hold media even for INVITEs with no SDP, which
plainly cannot be fixed. So isn't it better to fix the UAs instead of
creating workarounds that don't always work anyway?

> The main reason during call setup is because
> codecs and other stuff may not have been
> fully negotiated. 
<..>
> 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.

The loop will only happen if an implementation is constantly changing its
SDP on _every_ re-Invite. Such implementation is clearly broken. Otherwise,
all you need in the worst case is an extra re-Invite from 3pcc to B.

>  Many current
> implementation tend to use a different port when
> coming off hold, thus the race condition tends
> to occur often.

I think that this behavior should be specifically discouraged; there is
little reason to change ports after going "off hold". And even if a UA does
change ports, this will only result in one extra re-INVITE from 3pcc, not a
loop.

That said, I do agree that your solution works. However, I don't think that
it gives you many advantages over standard INVITE with SDP approach and it
seems like an unnecessary exception from SIP media negotiation model.

Thank you,
Igor Slepchin

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

---

From: "Brett Tate" <[email-masked]>
Date: Sat, 2 Dec 2000 19:51:13 -0500

> creating workarounds that don't always work anyway?

Gethin's flow works for 3pcc call setup.  However
a no-call REFER (if still valid) or hold-then-transfer
A to B through controller also works and allows
A to hear/see the call progress/fail.

The hold part that I assume I referred to deals with
re-INVITE-without-SDP and ACK-with-SDP to
indicate that the sender no longer has the receiver
on hold.  This is currently being discussed in thread
"[SIP] Re: No SDP => take off hold?
[WAS: 3PCC and the re-invite response]".

> all you need in the worst case is an extra re-Invite from 3pcc to B.

Changing ports on every re-INVITE is not "broken"
since rfc2543 allows it, and it is a test for advance
SIP media.  However I too would hate to constantly
receive a new SDP in 200 response to a session
timer extending INVITE.  But I assume at this point,
all rfc2543 can do is "strongly discourage port hopping
SDP's for no other reason besides changing ports".

> seems like an unnecessary exception from SIP media negotiation model.

I'm all for discouraging ports changing when
coming off hold.  But lets discuss the INVITE
without SDP stuff in thread
"[SIP] Re: No SDP => take off hold?
[WAS: 3PCC and the re-invite response]".

Thanks for the response.  Maybe one of the
3pcc authors can organize a bof at the
IETF meeting if there is enough interest
in this stuff.

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 03 Dec 2000 10:11:22 -0600

>Maybe one of the

Yes, I believe there is interest, since 3pcc is a fundamental feature, used
in other drafts, such as
<draft-rosenberg-sip-app-components-00.txt>

Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Brett Tate
Sent: Saturday, December 02, 2000 6:51 PM
To: Sip Mail List
Subject: Re: [SIP] 3PCC and the re-invite response