To summarize the discussion so that it can be put in an issue and be
scheduled for work:
The goals are:
- Allow Call-Ids to specify the host that generated them (to make them
more human-readable) by:
- When the application code can provide a host/port, use it to
construct Call-Ids, and additionally shorten other fields of
Call-Ids where that is enabled.
- Shorten SIP messages by shortening coded binary fields:
- Change coded binary fields from hexadecimal to modified base64.
- Shorten the number of bits in coded binary fields where the current
values are longer than necessary.
- Encode binary fields in characters (modified base64) that require
no escaping in any SIP context.
- Define a "modified base64", using characters that have no special
meaning in SIP or other aspects of sipX, for tersely encoding binary
fields.
1) Allow application to supply host/port for generating Call-Ids.
The application can supply to CallId a hostport string -- if so, the
application is responsible for ensuring that there is no other
contemporaneous sipX application using the same hostport string. This
is usually done by having the string specify the domain name of the
application's host (which may be different from its SIP domain) and a
port that the application has open.
If the application provides a hostport string, the Call-Id format is:
s-xxxxxx-...@hostport
where XXXXXX is a 6-character (36-bit) modified base64 crypto-random
number, and NNN is a decimal counter. (Reduced from 16 hex digits,
but the hostport is added.)
If the hostport is not supplied, Call-Ids will be generated in a
format that is similar to the current format, but 5 characters
shorter:
s-XXXXXXXXXXX-NNN
where XXXXXXXXXXX is an 11-character (66-bit) modified base64
crypto-random number. NNN is a decimal counter. (Reduced from 16 hex
digits.) ("s" stands for "session". The application can provide a
string to replace "s".)
2) Tags
Tags generated by CallId::getNewTag will be 6-character (36-bit)
modified base64 crypto-random numbers. (Reduced from 8 hex digits.)
3) Via branch values
Via branch-id counter parts will be 3 modified base64 (18-bit)
characters (reduced from 4 hex characters). signed-branch will be 11
base64 characters (66-bits) (reduced from 32 hex characters).
loopdetectkey will be 11 base64 characters (66-bits) (reduced from 32
hex characters).
4) RouteState signature
The RouteState signature will be 11-character modified base64
(66-bits) (reduced from 22 base64 characters). Additionally, '/' will
no longer be used in encoding, as it is not used in modified base64.
5) sipx-readroute script must be modified to handle both the old and
new formats.
5) Modified base64
Enhance or augment the NetBase64Codec class to generate and decode
base64 encodings in the following non-standard alphabet:
In regard to the encoding alphabet:
base64 requires 3 characters other than the letters and digits. The
standard characters are '+', '/', and '='.
BranchIds and RouteStates must/should (respectively) be 'token'
character strings. Call-Ids can contain 'word' characters, which
include all the 'token' characters.
The non-alphanumeric token characters are:
- BranchId delimiter
. RouteState delimiter
! RouteState delimiter
% used for %-escaping
* RouteState delimiter
_ unused
+ can be interpreted as space in URIs
` unused
' unused
~ RouteState delimiter, BranchId delimiter
This allows us to define the following characters for modified base64:
_ replaces '+'
` replaces '/'
' replaces '='
Dale
_______________________________________________
sipx-dev mailing list
sipx-dev@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
