Subject: [Sip] Re: [Sip-implementors] Comments on bis-06

From: Robert Sparks <[email-masked]>
Date: Sat, 16 Feb 2002 23:19:02 -0600

[email-masked] wrote:

> Hi,
> 
> Few comments on bis-06.
> 
> Section 8.2, UAS behavior: there is no mention on sending responses. It'd
> be helpful to point to the sections for sending responses. Would it be
> Section 17.2.4 (transaction layer)  or 19.2.2 (transport layer)? For
> requests, it is clear that UAC Core keeps track of the list of servers to
> try for sending requests. For responses, it is not clear to me which layer
> keeps the list.

Normally a UA core would hand the response to the server transaction that
passed it the request. Section 8.3 talks about cases where a UA core might
not want to do that.

We'll work to clarify this.

> 
> Line 1931: Should the reference for 3xx response processing here be Section
> 8.1.4.5 instead of Section 13.2.2?

Yes - fixed.

> 
> Line 1985: Shouldn't the "request out of order" error be 400 instead of
> 500?

As far as I know 500 was chosen arbitrarily. Jonathan notes that 500 makes
sense given that the request would succeed if it was sent again as is at
a later time.

> 
> Line 2030: It states that Accept header MAY be present in the INVITE.
> However, in Table 2, Header summary, Accept header in INVITE is m* meaning
> the header SHOULD be sent. Which is correct? Similar comment applies for
> Accept header in 2xx response (Line 2182).

I think MAY is correct. We'll review and make sure the text and table are
consistant

> 
> Line 2337: It states that (when the UAS responses to BYE), "The UAS MUST
> still respond to any pending requests received for that dialog, (which can
> only be an INVITE)." Any pending request can be OPTIONS as well in addition
> to INVITE although unlikely.

I'll let Gonzalo comment on this one.

> 
> Line 3063: It states "Eventually, the server transaction decides to send a
> final response. For unreliable transports, that response is retransmitted
> periodically, and for reliable transports, its sent once." I don't think
> this is true for 2xx responses to INVITE over reliable transport.

It is true from the server transaction's perspective. Retransmission of
2xx-INVITE is done by the TU. This is pointed out early in section 17.

> 
> Section 17.1.3, Matching Responses to Client Transactions: This describes
> the mechanism using branch id in Via. Don't we also need a description used
> in the earlier versions for backwards compatibility, as Section 17.2.3
> does?

No - the response will contain the id this client transaction added to the
request.

> 
> Section 17.2.4: Handling Transport Errors: I think this section describes
> transport error handling for sending responses for responses to non-INVITE
> and non-2xx responses to INVITE. I am not sure where the transport error
> handling is done for 2xx responses to INVITE. If the first attempt to send
> a 2xx response to INVITE encounters transport errors, is it Transport Layer
> that is to try the next server or UAS Core that is to try the next one? If
> it is the UAS core, when the 2xx response is sent to the next server, is
> the timer reset starting at T1?

Jonathan - could you comment on this?

> 
> On Response code 482 Loop Detected: I recall a discussion in the list a
> while back on using "482 Request Merged" or something like that. Is there a
> reason why we are using 482 "Loop Detected" still?

History - the reason phrase just hasn't been updated. I'll start a discussion
on updating it. But remember that the reason phrase is just informational.
482 Eat Spam! means the same thing as 482 Request Merged.

RjS

> 
> Thanks,
> YoungSun
> 
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Sun, 17 Feb 2002 19:22:24 +0200

Hello,

> I'll let Gonzalo comment on this one.

I already fixed this when I marked bug#113 (non-INVITE overlapping
transactions) as resolved.

Thanks for the comment,

Gonzalo