On Mon, 2008-10-27 at 16:53 -0400, Dale Worley wrote: > After talking to Scott, I've pulled together a list of things that can > be improved by using base64: > > Revising how we generate Call-Ids and related matters. > > The application can supply to CallId a hostport string. If this 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 the base64 representation (in a suitable alphabet > -- see below) of a 64-bit (actually, 66-bit) crypto-random number, and > NNN is a decimal counter. (The application can provide a string to > replace "s".) > > If the application provides a hostport string, the format is: > > [EMAIL PROTECTED] > > where XXXXXX is the base64 representation of a 32-bit (actually, > 36-bit) crypto-random number, and NNN is a decimal counter. > > Tags generated by CallId::getNewTag will be 6 base64 characters rather > than 8 hex characters. > > Via branch-id counter parts will be 3 base64 characters rather than 4 > hex characters, and the signed-branch and loopdetectkey will be 22 > base64 characters rather than 32 hex characters. > > This will require enhancing the NetBase64Codec class to generate > and decode base64 encodings in non-standard alphabets. > > In regard to the encoding alphabet: > > base64 requires 3 characters other than the letters and digits. The > standard characters are '+', '/', and '='. BranchId uses two > separator characters, '-' and '~', although they can be located by > counting characters, so the same character can be used for both. > > RouteState signatures will be 22 base64 characters, rather than 32 hex > characters. RouteState uses 4 separator characters, '!', '.', '~', > and '*'. > > BranchIds and RouteStates must/should (respectively) be 'token' > character strings. Call-Ids can contain 'word' characters, which > includes all the 'token' characters. Unfortunately, tokens may not > contain '/', but RouteState currently can generate them. > > The available token characters are: > > - already used to separate subfields > . RouteState delimiter > ! RouteState delimiter > % used for %-escaping > * RouteState delimiter > _ to be used to replace '/' in base64 > + can be interpreted as space in URIs > ` replaces '=' in base64 > ' replaces '+' in base64 > ~ RouteState delimiter > > Can loopdetectionkey be reduced to, say, 32 bits, rather than the full > 128 bits?
I'd prefer not to mess with that right now, since it could cause false loop detections if two loops generated the same hash. We'll already have saved 20 bytes per via with the change you've outlined. Please remember to update the sipx-readroute script in sipXtools to match the new encoding. Good job. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
