----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Bob Penfield" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, August 06, 2001 7:09 PM
Subject: Re: [Sip-implementors] Query on tags in From field and
Retransmission of INVITE responses in TCP !!
>
> Please see inline comments below.
>
>
>
>
> "Bob Penfield" <[EMAIL PROTECTED]> on 08/06/2001 06:16:43 PM
>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Youngsun
> Song/Telcordia)
> Subject: Re: [Sip-implementors] Query on tags in From field and
Retransmis
> sion of INVITE responses in TCP !!
>
>
>
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Saturday, August 04, 2001 4:45 PM
> Subject: RE: [Sip-implementors] Query on tags in From field and Retransmis
> sion of INVITE responses in TCP !!
>
>
> >
> > Hi,
> >
> > I have similar questions on Retransmission over TCP, Section 14.4.2,
> bis-4.
> > Suppose the following scenario.
> >
> > [A] --- TCP---- [Proxy1]------UDP ----- [Proxy2] ----TCP------[B]
> >
> > (1) A sends an INVITE which gets eventually proxied to B. B doens't send
> > any response.
> > Does Proxy1 retransmit INVITE following retransmission algorithms used
> for
> > UDP?
>
> >Yes, if it is a stateful proxy.
>
> I thought a proxy supporting TCP must be a stateful proxy because of the
> required retransmission support.
> In bis-04, Section 17.3, it states that:
>
> "Proxies that accept TCP connections MUST be stateful when handling the
TCP
> connection...
> Otherwise, if the proxy were to lose a request, the TCP client would never
> retransmit it."
That is true. I was looking at only the UDP side. Although, some
implementors might interpret the spec as allowing statefulness on the TCP
side and statelessness on the UDP side. That may be legal, but certainly
unwise.
>
> >
> > (2) A sends an INVITE which gets eventually proxied to B. B sends 200
OK
> > which gets eventually forwarded to A.
> > A doesn't send ACK. Does Proxy2 retransmit 200 OK following
> retransmission
> > algorithms used for UDP?
>
> >Actually, it is the UAS [B] that re-transmits the 200-OK (in accordance
> with
> >section 14.4.2 of bis-04 which applies to UAs not proxies).
>
> >
> > (3) Section 14.3,2, Reliable Transport Protocol, does not say anything
> > about retransmission of responses for non-INVITE messages. Does the UAS
> > using TCP need to retransmit a final response when receiving a
> > retransmitted non-INVITE request?
>
> >You cannot retransmit responses for non-invite requests because there is
> not
> >an ACK for responses to non-invite requests and thus there is no way to
> know
> >whether or not the response got back to the UAC.
>
> True, but the UAS keeps the timer and retransmits the response on demand
> for the duration of the timer (10*T2).
> In bis-04, Section 14.3.1, it states that:
>
> "Servers retransmit the response upon receipt of a request retransmission.
> After the
> server sends a final response, it cannot be sure the client has received
> the response, and thus SHOULD cache
> the results for at least 10 *T2 seconds to avoid having to, for example,
> contact the user or location server
> again upon receiving a request retransmission."
Yes, the UAS must "remember" the response it sent in case it gets a
re-transmission of the request. I think this always applies because you
don't necessarily know if there is UDP somewhere between the UAS and the UAC
even though your connection is TCP.
>
> > YoungSun
> >
> >
> >
> >
> >
> > [EMAIL PROTECTED] on 07/26/2001 01:41:05 PM
> >
> > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > cc: (bcc: Youngsun Song/Telcordia)
> > Subject: RE: [Sip-implementors] Query on tags in From field and
> Retransmis
> > sion of INVITE responses in TCP !!
> >
> >
> >
> >
> > Here is the explanation in bis-04 for re-transmitting responses:
> >
> >
> > 14.4.2 Reliable Transport Protocol
> > A user agent using a reliable transport protocol such as TCP, SCTP or
> > TLS MUST NOT retransmit requests, but uses the same algorithm as for
> > unreliable transport protocols (Section 14.4.1) to retransmit
> > responses until it receives an ACK. A client MAY give up on the
> > request if there is no response within a client-defined timeout
> > interval.
> >
> > It is necessary to retransmit 2xx responses as their
> > reliability is assured end-to-end only. If the chain of
> > proxies has an unreliable transport protocol link in the
> > middle, it could lose the response, with no possibility of
> > recovery. For simplicity, we also retransmit non-2xx
> > responses, although that is not strictly necessary.
> >
> >
> >
> > -----Original Message-----
> > From: Viswanathan, Sriram C (Sriram) [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, July 26, 2001 11:16 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Sip-implementors] Query on tags in From field and
> Retransmission
> > of INVITE responses in TCP !!
> >
> >
> >
> > Hi,
> >
> > I have question on the RFC related to the "From" field. In the "From"
> field
> > there is a requirement to define a "tag" parameter (MUST). I am unable
to
> > create a
> >
> > scenario wherein this would be required from the UAC perspective.
> >
> > Also, could anyone indicate as to why the retransmission of INVITE
> > responses
> >
> > are done for a TCP connectivity. TCP itself is a reliable transport.
Even
> > if
> > we have intermediate proxies or other carriers I am assuming that when
> they
> > implement UDP on the way, they would have retransmission logic built in.
> > The
> > other thing is if a SIP message indicates that the transport is TCP and
> if
> > any proxy on the way does not support this transport there is supposed
to
> > be
> > an error code returned back. Is this correct?
> >
> >
> > Would appreciate if anyone could throw some light on this or even if
> > possible any web site which indicates a link to this kind of info.
> >
> > Thanks,
> > Sriram
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> >
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
