Sending folded SIP header fields

Need to send multi lined and folded sip this:

tel:+8657022210249; index=1,;user=phone;cause=302; index=1.1
i jus know this:
same => n,SIPAddHeader(History-Info: tel:+8657022210249; index=1,sip:18945632xx@172.20.XX.XX\;user=phone\;cause=302; index=1.1)


anyone help?

is there a technical reason you need them to be folded ?

not really ,just because the sbc side need us to send the sip message like that.

I suggest you ask them where in the SIP protocol specification this is even
mentioned, let alone suggested as a possible requirement to comply with.


It’s included, by reference from [RFC 2822: Internet Message Format](https://RFC 2822) (email) at RFC 3261: SIP: Session Initiation Protocol

It is a “can” requirement, so it is only enforceable on the receiver, and is completely optional for the sender.

ya, and i don’t know how add /r/n/t in dialplan ,and have test in a agi:
channel.exec(“SIPAddHeader”,“History-Info:<tel:” + request.getDnid() + “>; index=1,\n”
+ “<sip:” + transferNo + “;user=phone;cause=302>;index=1.1”);
seams it works.

but use tcpdump the right format is :slight_smile:

but use agi don’t have the “…”:

0d 0a 09 in hexadecimal represents carriage return (0D), line feed (0A), and tab (09) respectively. In ASCII encoding, these three hexadecimal values represent these special characters.

You need an SBC that implements SIP.

SIP proxy/SBCs that follow RFC might not like line breaks in a header. I’ve seen errors thrown when the header/tags are not in the proper format.

@sinoee Did they give you a format to follow? Can you post it?

If they don’t like line breaks in the permitted places (where the syntax permits linear white space), they don’t follow the RFCs! The issue here is that the SBC is requiring them where they are permitted by not mandated, when a compliant implementation would accept them in permitted places, but would not require them in every, or even any, permitted place.

I misspoke, line breaks such as an LF can be fine. You cannot use /t (tab) in headers and CRLF (/r/n) is considered an End Of Line. So I guess we need to know what the provider is actually expecting because folded SIP lines are unfolded to be processed.

Tabs are perfectly legal, and CR LF is legal, but LF is not. E.g.:

SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators.

LWS = [*WSP CRLF] 1*WSP ; linear whitespace
SWS = [LWS] ; sep whitespace

See RFC 3261: SIP: Session Initiation Protocol Note that this does mean that line folding is directly in the SIP RFC.

RFC 2616 defines CRLF as:


and defines LWS, directly in terms of tab and space:

LWS = [CRLF] 1*( SP | HT )

There is a recommendation not to actually look for the CR and to treat LF as CR LF.

so is it /r/n support in dialplan? like

same => n,SIPAddHeader(P-Asserted-Identity: <sip:${EXTEN}@172.20.XX.XX>,/r/n/t<tel:${EXTEN}>)

same => n,SIPAddHeader(History-Info: <tel:${CLID}>; index=1,/r/n/t<sip:${DST}@172.20.XX.XX\;user=phone\;cause=302>; index=1.1)

It is not something that Asterisk needs to do, as the UAS must handle the header when it sent on one line. Depending on the context, a folding is equivalent to either a single space, or nothing at all.

I think, if you can get a newline substituted into the command parameters, it may stay. I think that is something that causes people when they use SHELL, in which case they don’t want the newline.

You might be able to use BASE64_DECODE.

However, if you need to do this, you are dealing with a broken implementation of SIP, and one that is broken in a way that I’ve never heard of before.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.