> For the complete documentation index, see [llms.txt](https://prosbcdocs.telcobridges.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prosbcdocs.telcobridges.com/telecom-references/sip-and-voip/script-parameters-definition-for-sip.md). # Script Parameters Definition for SIP ### request\_uri Enables access to the Request-Line URI. For example, if the Request-Line is: ``` Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0 ``` Then the retrieved request\_uri will be "sip:4175162082\@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". In the routing scripts, to retrieve only the called number, this script can be used: ``` if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/ call_params[:called] = $1 end ``` #### request\_uri\_forward\_enabled This call parameter controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. Values for this parameter are "0", "1", "false" or "true. * 0/false: Request uri is not forwarded to outgoing call leg * 1/true: Request uri is forwarded to outgoing call leg The default value for this parameters is false. #### sip\_scheme (Available in Toolpack 3.1+) This call parameter indicates the scheme (generally "sip" or "sips") of the incoming call. This also allows the control of the scheme used for the outgoing call (regardless if request\_uri\_forward\_enabled is used or not) Note: sips scheme must only be used on TLS NAPs (will cause call routing failure if NAP has only UDP or TCP transport types). ### sip\_header values Contains custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: **Note:** The SIP header is in string format. **string format:** ``` call[ :sip_header ] = "P-my-custom-header:value1 \nP-my-custom-header2:value2 \nP-my-custom-header3:value3" ``` (Note: \n above are actual newline characters, not '' followed by 'n') * PCAP sample: ![TB Custom SIP Headers](https://docs.telcobridges.com/w/images/c/c9/TB_Custom_SIP_Headers.pcap) List of sip headers that will not appear in call\[:sip\_header] since they are already processed by the SIP stack: ``` Accept Error-Info Remote-Party-ID Accept-Contact Event Replaces Accept-Encoding Expires Reply-To Accept-Language From Request-Disposition Alert-Info In-Reply-To Subject Allow Max-Forwards Subscription-State Allow-Events MIME-version Supported Also Min-Expires Timestamp Anonymity Min-SE To Authorization Organization Unsupported Authentication-Info Path User-Agent Call-ID Priority Via Call-Info Privacy Warning Contact Proxy-Authenticate WWW-Authenticate Content-Disposition Proxy-Authorization Require Content-Encoding Proxy-Require Response-Key Content-Language P-Media-Authorization Retry-After Content-Length P-Preferred-Identity RPID-Privacy Content-Type P-Asserted-Identity Route CSeq RAck RSeq RAck Reason Security-Client Reason Record-Route Security-Server Date Refer-To Security-Verify Diversion *Referred-By Server Encryption Reject-Contact Service-Route Session-Expires ``` Note: Since version 3.0.57, Referred-By is now a SIP custom parameter ### sip header parameters The routing script can read (and modify) some SIP header parameters (user parameters, URI parameters or header parameters) from some SIP headers (To, From, P-Asserted-Identity, Remote-Party-ID, Contact). #### Available parameters * **call\[ :calling\_parameters ]** (SIP "From" header) * **call\[ :called\_parameters ]** (SIP "To" header) * **call\[ :private\_address\_parameters ]** (SIP "P-Asserted-Identity" or "Remote-Party-ID" header) * **call\[ :supp\_private\_address\_parameters ]** (SIP supplementary/second "P-Asserted-Identity" header) * **call\[ :preferred\_id\_parameters ]** (SIP "P-Preferred-Identity" header) * **call\[ :contact\_parameters ]** (SIP "Contact" header) These parameters (if present) contain a hash with 3 keys: user\_param, uri\_param and header\_param. Each of this key points to a string that contains all the parameters found in the corresponding SIP header. * **User parameters** (parameters between the user name/number and the host). Example \ * **URI parameters** (parameters at the end of the URI). Example \;**param=value**> * **Header parameters** (outside the URI). Example \>;**param=value** Example to print all parameters of SIP "To" header: call\[ :called\_parameters ].inspect -> '{ :user\_param => "name1=value1;name2=value2", :uri\_param => "name=value", :header\_param => "name=value;example\_param\_without\_value" }' Example to modify (replace) the URI parameters of SIP "To" header: call\[ :called\_parameters ]\[ :uri\_param ] = "user=phone" #### Exceptions **Note:** Some parameters are reported as their own call attribute (oli, isub, cpc, transport) so they have the same representation for all protocols (SS7, IDSN, SIP). They will not appear in the generic SIP header parameters structures above. #### Forwarding from inbound to outbound call #### Legacy behavior (For base\_routing version 1.32 or older) By default, the parameters are not forwarded in a SIP to SIP call flow. The parameters **will be forwarded** when: * accessed (read) from either the inbound or outbound call parameters * written in either the inbound or outbound call parameters #### Current behavior (For Toolpack 3.0.118+, with base\_routing version 1.33+) SIP headers host and parameters are forwarded by default. A route attribute "forward\_sip\_domain" (along with filter script "forward\_sip\_domain.rb") will control, per route, if SIP headers host+parameters must be forwarded. #### Example use Example to print the user parameters: ``` if call[:calling_parameters] puts "user parameters = #{call[:calling_parameters][:user_param].inspect}" end ``` Example SIP "From" header: From:;test5=val5;test6=val6 And the resulting content in the routing script: call\[:calling\_parameters].inspect -> {:user\_param=>"test1=val1;test2=val2", :uri\_param=>"test3=val3;test4=val4", :header\_param=>"test5=val5;test6=val6"} Example to overwrite inbound leg calling parameters with new parameters for the outbound leg: ``` call [:calling_parameters] = { :user_param => "user_param7=7;user_param8=8", :uri_param => "uri_param9=value9", :header_param => "header_paramA=A" } ``` Example to add user=phone and keep all other uri parameters. ``` call[:calling_parameters] ||= {} # Create a hash if not already present call[:calling_parameters][:uri_param] ||= "" # Create a string if not already present call[:calling_parameters][:uri_param] += ";" if call[:calling_parameters][:uri_param] != "" call[:calling_parameters][:uri_param] += "user=phone" ``` ![BackToMain](https://docs.telcobridges.com/w/images/1/1e/BackToMain.png) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://prosbcdocs.telcobridges.com/telecom-references/sip-and-voip/script-parameters-definition-for-sip.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.