Subject: RE: [Sip] Local vs Remote ringback on 180

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 4 Jul 2002 16:55:06 +0200

Hello,

comment inline

> [DA] Is the use of the TCP/SCTP is good enough to say that
> e2e provisional responses with answer are reliable?

I don't think so for "reliable provisional responses".  Retransmissions
are not needed when using TCP but a PRACK from the UAC is still needed
for "reliable provisional responses".

[DA] I mean, that the 100rel is only needed for the UDP. The reliable transport protocols do not need a help from session control protocols.

Greetings,
Denis Alexeitsev

_______________________________________________
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: "Bert Culpepper" <[email-masked]>
Date: Thu, 4 Jul 2002 11:37:08 -0400

Hi Denis,

I don't know that the use of TCP is a substitute for 100rel.  PRACK
provides knowledge that the receiver's UA "processed" the provisional
response.  TCP only guarantees the message was received at the host.  I
may be off-base here, if so others can correct me.

Regards,
Bert

Alexeitsev, D wrote:
> [DA] I mean, that the 100rel is only needed for the UDP. The
> reliable transport protocols do not need a help from session
> control protocols.
>
> Greetings,
> Denis Alexeitsev
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 04 Jul 2002 18:43:14 +0300

Hi Alexeitsev,

I think I get your point :) I'll try to answer.

Like Bert said, when TCP is used, "reliable provisional response" from a SIP point of view means that the response is allowed to contain an
offer/answer. An "unreliable provisional response", EVEN if sent reliably from a transport layer (TCP) point of view, means that it is NOT
allowed to contain an offer/answer (it MAY contain, but the same SDP has to be sent later anyway).

Now, you could argue that every 18x sent using TCP should always be considered as a "reliable provisional response" from a SIP point of view,
and that PRACK is never needed. Now, that WOULD probably work fine - IF:

1. ...PRACK was only used for what it originally was supposed to be used for - making sure provisional responses are delivered reliably and in
order.

HOWEVER, nowadays PRACK also has defined offer/answer rules, which means we in some cases MUST use it to send SDP (for example if a reliable 18x
contains an offer, the PRACK MUST contain the response, so the PRACK MUST be sent).

2. ...there would never be a TCP/UDP conversion in an intermediate proxy. Now the proxy would have to generate the PRACKs on the hop where UDP
is used.

3. ...the SIP APPLICATION would be transport aware. Currently (as I can remember) only the transaction handler, which needs to know if to
retransmit messages or not, needs to be transport aware.

Now, if you want to argue that it's better to make SIP application transport aware, than sending "useless" PRACKs in the network, and you want
proxies to start generating PRACKs, I do NOT want to take part in that discussion :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 08 Jul 2002 14:43:10 +0300

> may be off-base here, if so others can correct me.

PRACK is end-to-end. TCP/UDP/SCTP is hop-by-hop. That is, if you send a
response using TCP you know that it will reach the next proxy, but you
know nothing about the remote UA.

About special casing the scenario where all the Via headers show that
TCP is used, it would be adding extra complexity for a little gain
(KISS). In addition, think of the interactions with remote Contact
updates from TCP to UDP using re-INVITEs.

Regards,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo