Looping SIP messages in an OpenSER proxy
Emin Gabrielyan
2007-04-16
Switzernet Sārl
Looping
SIP messages in an OpenSER proxy
1...... Configuration
of the experiment
2...... Replies
of the proxy server to REGISTER requests
3...... Modifications
of INVITE requests and provisional replies to INVITE requests
4...... A
remark concerning t_check_trans()
5...... Related
files or cached links
6...... Other
experiments related to OpenSER
Looping of SIP messages in a SIP proxy is useful for examining the replies of a proxy server and for viewing the contents of transmitted SIP messages.
The OpenSER servers routing logic treats with the messages only upon their arrivals. When the message is arrived we can view and analyze the entire buffer of the message. However we are not able to see the replies generated by the proxy server. We are also unable to see all modifications done by the proxy server while processing the message. The pseudo-variables referring to the message buffer and its parts do not show the state of the modified message.
The reply messages of the proxy server and the transmitted messages of the proxy server can be seen if these messages arrive once again to the proxy server. Instead of sending the requests to their true destinations, they can be redirected back to the proxy server. These requests will arrive back with their contents of the moment when they were leaving the proxy server. Replies follow always the path of the requests in the reverse direction (thanks to the stack of Via header fields which recorded the path of the request). So a reply of the proxy server would be looped back to the proxy server if its request traversed such a looped path.
The SIP messages must be looped through the proxy server only once. For this purpose before looping messages the first time we add a special P-hint header in the message. We then check the messages for a presence of such a P-hint header in order to not loop the messages if they were already looped.
1. Configuration of the experiment
We are using a proxy server running OpenSER version 1.2.0. Its IP address is 192.168.1.15.
We are using two Grandstream Budge Tone-100 SIP phones. The first one with a phone number 10 is located at IP address 192.168.1.10, and the second one with a phone number 11 is located at IP address 192.168.1.11.
2. Replies of the proxy server to REGISTER requests
In this section we present a configuration file which permits us to see the replies of our proxy server to REGISTER requests. When we receive an incoming REGISTER message and if the message has not been already looped, we resend this message back to proxy (192.168.1.15) and we stop the processing. When this REGISTER request arrives to our proxy the second time, we will not loop it anymore and it will be processed normally:
if(!search("P-hint: [Ss]elf-[Ll]ooped"))
{
if(method=="REGISTER")
{
append_hf("P-hint: Self-looped request\r\n");
t_relay("192.168.1.15");
exit;
}
}
Thanks to such a looping the replies will follow the same path and will pass once through our proxy server. As a result, each REGISTER request will appear twice and we will see once the reply message of our proxy server:
0(2606) onreply_route[1] {...}
0(2606) an on-going transaction ...
0(2606) [ 200 (OK) from 192.168.1.15:5060 concerning REGISTER ]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK709c.3a3a4087.0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK6e90e945988ddf9c
From: <sip:10@192.168.1.15>;tag=b6948c8266ca318e
To: <sip:10@192.168.1.15>;tag=4f4b3fc66ce1848604aacd9b43692540.fe8a
Call-ID: 63b86fbc70ebec8c@192.168.1.10
CSeq: 1749 REGISTER
Contact: <sip:10@192.168.1.10>;expires=150
Server: OpenSER (1.2.0-notls (i386/linux))
Content-Length: 0
0(2606) [ End of 200 flagged 1 ]
The full message exchange is here: [htm], [txt], [doc].
The diagram of the message exchange between proxy and one SIP phone:
3. Modifications of INVITE requests and provisional replies to INVITE requests
The INVITE request is modified by the proxy server before transmission. The modified INVITE request can be seen if we transmit it back to the proxy server.
Here is a code added after end of the routing logic script (see the configuration file):
if(!search("P-hint: [Ss]elf-[Ll]ooped"))
{
if(method=="INVITE")
{
append_hf("P-hint: Self-looped request\r\n");
t_relay("192.168.1.15");
exit;
}
}
The INVITE message will be sent back again to the proxy server. The INVITE as it arrived the first time from the SIP phone is shown below:
0(3866) [ INVITE from 192.168.1.10:5060 ]
INVITE sip:11@192.168.1.15 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK5f7e00cd4321b8bd
From: <sip:10@192.168.1.15>;tag=a9943d4a1d5ea6cb
To: <sip:11@192.168.1.15>
Contact: <sip:10@192.168.1.10>
Supported: replaces
Call-ID: 8c9610bb07a0ca8b@192.168.1.10
CSeq: 28292 INVITE
User-Agent: Grandstream BT110 1.0.8.33
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Type: application/sdp
Content-Length: 224
v=0
o=10 8000 8000 IN IP4 192.168.1.10
s=SIP Call
c=IN IP4 192.168.1.10
t=0 0
m=audio 5004 RTP/AVP 4
18 97
a=sendrecv
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=ptime:60
0(3866) [ End of INVITE flagged 3 ]
The INVITE after modifications done by OpenSER proxy server is below:
0(3866) [ INVITE from 192.168.1.15:5060 ]
INVITE sip:11@192.168.1.11 SIP/2.0
Record-Route:
<sip:192.168.1.15;lr=on;ftag=a9943d4a1d5ea6cb>
Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK8fa7.6de876e6.0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK5f7e00cd4321b8bd
From: <sip:10@192.168.1.15>;tag=a9943d4a1d5ea6cb
To: <sip:11@192.168.1.15>
Contact: <sip:10@192.168.1.10>
Supported: replaces
Call-ID: 8c9610bb07a0ca8b@192.168.1.10
CSeq: 28292 INVITE
User-Agent: Grandstream BT110 1.0.8.33
Max-Forwards: 69
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Type: application/sdp
Content-Length: 224
P-hint: usrloc applied
P-hint: Self-looped request
v=0
o=10 8000 8000 IN IP4 192.168.1.10
s=SIP Call
c=IN IP4 192.168.1.10
t=0 0
m=audio 5004 RTP/AVP 4 18 97
a=sendrecv
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=ptime:60
0(3866) [ End of INVITE flagged 4 ]
We see in the modified INVITE request the impact of the record_route() function and of the lookup("location") function. The lookup("location") function modified the first line of the message and replaced 11@192.168.1.15 by 11@192.168.1.11.
The provisional reply of the proxy server can be seen due to the looped path of the request and correspondingly also the replies (due to the stack of Via fields):
0(3866) [ 100 (Giving a try) from 192.168.1.15:5060 concerning INVITE ]
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK8fa7.6de876e6.0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK5f7e00cd4321b8bd
From: <sip:10@192.168.1.15>;tag=a9943d4a1d5ea6cb
To: <sip:11@192.168.1.15>
Call-ID: 8c9610bb07a0ca8b@192.168.1.10
CSeq: 28292 INVITE
Server: OpenSER (1.2.0-notls (i386/linux))
Content-Length: 0
0(3866) [ End of 100 flagged 3 ]
The provisional reply will not be generated if we use t_relay("0x01") instead of t_relay() function (with no flags t_relay() sends a provisional reply by default).
The full log of this scenario is available [htm], [txt], [doc]. Since record_route() function is called during processing of INVITE, all transactions of the SIP dialog (related to the current phone call) will also follow the looped path of INVITE (see for example the BYE messages in the full log).
The call setup transaction is schematically shown in the following diagram:
4. A remark concerning t_check_trans()
The function t_check_trans() informs whether the currently received message belongs to an on-going transaction or if the message starts a new transaction. In case of processing a retransmitted request this function will take recovery actions and will exit the script processing. See a forum discussion. The function t_lookup_request() probably does not take actions, but it is not supported in OpenSER version 1.2.0.
In our configuration file we try to identify if the currently received message belongs to an on-going transaction or not by using flags (instead of using t_check_trans()). However flags are not reliable. For some messages of an on-going transaction the flags can be lost [htm].
5. Related files or cached links
Discussion of t_check_trans() on the forum [cached], [forum]
Discussion of transaction flags on the forum [cached], [forum]
Manual page of t_lookup_request() function [cached], [manual]
Manual page of t_relay() function [cached], [manual]
6. Other experiments related to OpenSER
Examining the STUN settings of a SIP phone
Creating and sending INVITE and CANCEL SIP text messages
Direct calls between two SIP phones without passing through a SIP proxy
SIP messages, transactions, and dialogs (understanding SIP exchanges by experimenting)
The path of SIP signalling messages (understanding Via, Record-Route, and Route headers)
SIP transaction flags in OpenSER
Looping SIP messages in an OpenSER proxy (viewing messages transmitted by server)