[sipcore] RFC4244bis - size of responses

["Elwell, John" <[e-mail]>]

The History-Info header field can get quite lengthy where a request has undergone a great deal of branching and retargeting. The entire accumulated set of hi-entries is reflected in the response. Thus a response can be considerably larger than a request from an H-I point of view, although other material in the request and not in the response might negate this. It does mean, however, that H-I can take some responsibility for a response being considerably larger overall than a request in some circumstances, particularly on the earlier hops (not on the final hop, of course). If an earlier hop has a low MTU size, this could cause a problem with UDP. Existing RFC 3261 guidance on maximum request sizes to be sent over UDP (200 bytes below maximum MTU size) might not be sufficient to cover this.

At present the inclusion of H-I in a response is subject to the option tag being placed by the UAC in the Supported header field. However, the need for this is being challenged in another thread, so it could be that H-I will be unconditionally reflected in the response. In any case, a UAC will not know about MTU sizes on downstream links, so this the option tag is not a solution to the response size problem.

What are the possible solutions?
- Override the RFC 3261 guidance on maximum request size for sending over UDP by specifying a larger contingency, sufficient to accommodate most H-I response scenarios.
- Specify that TCP is to be used when H-I is used.
- Specify that H-I should be dropped from a response to be sent over UDP if it would cause the response to exceed the maximum MTU size.

John