Subject: [Sip] RFC 3261 Ambiguous SIP URI table in 19.1.1

From: "Matthew Gardiner" <[email-masked]>
Date: Tue, 7 Nov 2006 13:35:11 -0000

Hi,

I am attempting to tighten up our SIP stack's behaviour regarding which URI parameters/fields to display/hide in header fields. This quest led me to a table known as "Table 1" in section 19.1.1(?) of RFC 3261. This table seems to present whether or not fields such as port and transport are optional or mandatory in headers, such as the "Contact" header. My understanding of this table leads me to believe that the only mandatory field for all header categories is the host address - that's why an 'm' character only appears in the "host" row.

So, apparently, all of the other fields are either optional or not allowed. Surely this constraint only applies when those fields have a their default value? What happens if a field assumes a non-default value, surely then the presentation of this value becomes mandatory in some header field somewhere?

Could someone clarify how, if at all, this table is to be interpreted regarding non-default values for URI parameters/fields?

thanks
Matt   
_______________________________________________
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: <[email-masked]>
Date: Tue, 7 Nov 2006 21:03:06 +0200

Hi,

I have a couple of comments on the current Outbound draft. These have
nothing to do with the normative behavior, but would be useful additions
from information/motivation point of view:

- Section 3.3 discusses why multiple connections are good for
reliability. The main motivation there is that multiple connections to
separate proxies protect against the failure of an individual proxy. An
additional motivation, which is currently missing, is related to
multihomed UAs. Such UAs would benefit from multiple connections from
different interfaces (or IP addresses) even if there is only a single
outbound proxy. This would protect against the failure of an individual
access link or the path between the particular interface and the proxy.
For instance it is quite realistic that in a few years there are many
UAs that have both cellular wireless interface (3G, WiMAX, ...) and a
WLAN interface, and whenever there is a WLAN available, they could be
multihomed and have a separate SIP registration/connection from each
interface. In the wireless access the risk of the access link/coverage
going down is quite big, so the benefit would be real.

I believe the current outbound mechanism supports this scenario already,
but it would be good to explain it in Section 3.3 as another reason for
doing mulitiple connections. I suppose q-values can be used to inform
the proxy which connection the UA prefers (for instance the one using
WLAN)?

- Section 4.4 has some discussion on why some
implementations/deployments might want to use a larger value for TCP
keeplive timer than the default 95-120 seconds. The main reason offered
is that the load on the servers might be too excessive. Another, perhaps
even more pressing, reason has to do with wireless devices. In many
cellular radio networks the frequent keepalive traffic will drain the
battery of the devices quite fast, so they would like to send the
keepalives as rarely as possible. 

Again, the spec allows higher values (bounded by the actual NAT/FW
timers, of course), so this is not a problem, but it would be good to
add this consideration explicitly in the draft.

If the authors and the WG see these as useful additions, I can propose
some specific text for both cases.

Regards,
	Markus