[Serusers] Sometimes registrar module's desc_time_order options fail

wangji wangji at bjut.edu.cn
Fri Feb 20 16:55:54 CET 2004


Hi all,
     My network is like this:
    ----------------------------
   |                                    |
   |                                    |
   |    Private network    | ----------- NAT----------Internet -----------------   SER server
   |                                    |
   |                                    |
    ----------------------------
And I use SER+mysql DB.
For a SIP terminal there are only one number and for a number there are only one SIP terminal. For a call I need to know only one URI. So that I set :
modparam("registrar", "append_branches", 0)
That mean I must get the last register infomation for a SIP terminal because of NAT port maybe change when SIP terninal reboot(Maby power off and power on so that maybe no unregister packets sent). So that I set:
modparam("registrar", "desc_time_order", 1)
to get the most current URI.
I don't know what mean with the parm default_q, sometimes I set it as 50, sometimes use default value 0.
But SER often call to the URI wrong.
Looking my recorder:
I use a SIP terminal named 1001. The terminal register multi times. So I can get many
I get usrloc information by command "serctl ul show" like this:
===Domain list===
---Domain---
name : 'location'
size : 512
table: 0x402e7998
d_ll {
    n    : 2
    first: 0x402e99a0
    last : 0x402e9a80
}

...Record(0x402e99a0)...
domain: 'location'
aor   : '1001'
~~~Contact(0x402e9b48)~~~
domain : 'location'
aor    : '1001'
Contact: 'sip:1001 at 218.107.145.102:7035'
Expires: 131
q      :       0.00
Call-ID: '3BAFC06D5BD54939A3114CABF35D1FE0 at novsky.com'
CSeq   : 11838
replic : 0
State  : CS_SYNC
Flags  : 1
next   : 0x402e9be8
prev   : (nil)
~~~/Contact~~~~
~~~Contact(0x402e9be8)~~~
domain : 'location'
aor    : '1001'
Contact: 'sip:1001 at 218.107.145.102:7011'
Expires: 36
q      :       0.00
Call-ID: 'D125943999FF4907BCD175EEFE3DE24A at novsky.com'
CSeq   : 43236
replic : 0
State  : CS_SYNC
Flags  : 1
next   : 0x402e99e0
prev   : 0x402e9b48
~~~/Contact~~~~
~~~Contact(0x402e99e0)~~~
domain : 'location'
aor    : '1001'
Contact: 'sip:1001 at 218.107.145.102:7080'
Expires: 1794
q      :       0.00
Call-ID: '9658F25C5E3040C1AE4C3405032B7558 at novsky.com'
CSeq   : 63264
replic : 0
State  : CS_NEW
Flags  : 1
next   : (nil)
prev   : 0x402e9be8
~~~/Contact~~~~
.../Record...
...Record(0x402e9a80)...
domain: 'location'
aor   : '1000'
~~~Contact(0x402e9ac0)~~~
domain : 'location'
aor    : '1000'
Contact: 'sip:1000 at 218.201.88.163:1083'
Expires: 2565
q      :       0.00
Call-ID: '3350078894 at 172.16.3.80'
CSeq   : 4
replic : 0
State  : CS_SYNC
Flags  : 1
next   : (nil)
prev   : (nil)
~~~/Contact~~~~
.../Record...

In the list we can find that last register use NAT port 7080 by check expires time.
I use this terminal -- 1001 to call 1001, It should return 486 BUSY in normal. But it didn't reponse.
See that packet I get by tethereal:
291.677702 218.107.145.102 -> 218.201.88.164 SIP/SDP Request: INVITE sip:1001 at novsky.com, with session description
291.702534 218.201.88.164 -> 218.107.145.102 SIP Status: 407 Proxy Authentication Required
291.822811 218.107.145.102 -> 218.201.88.164 SIP Request: ACK sip:1001 at novsky.com
291.824597 218.107.145.102 -> 218.201.88.164 SIP/SDP Request: INVITE sip:1001 at novsky.com, with session description
291.868197 218.201.88.164 -> 218.107.145.102 SIP Status: 100 trying -- your call is important to us
291.870300 218.201.88.164 -> 218.107.145.102 SIP/SDP Request: INVITE sip:1001 at 218.107.145.102:7035, with session description
292.045669 218.201.88.164 -> 218.107.145.102 SIP/SDP Request: INVITE sip:1001 at 218.107.145.102:7035, with session description
294.065633 218.201.88.164 -> 218.107.145.102 SIP/SDP Request: INVITE sip:1001 at 218.107.145.102:7035, with session description
298.105648 218.201.88.164 -> 218.107.145.102 SIP/SDP Request: INVITE sip:1001 at 218.107.145.102:7035, with session description
I find SER get the wrong URI and send to NAT port 7035.
It sometimes happens but not always.
How to deal with that.


Br,

Wangji


More information about the sr-users mailing list