22 Jul
2004
22 Jul
'04
3:47 p.m.
The problem seems to be something to do with sip_registrar sending
messages...
I don't quite understand how mdump() works... because when admin logs
off/logs in.. I see in the log that msilo is trying to send messages to
test1 as well? And of course this user is still offline... surely
mdump() should only send the messages for the user who has just
registered...
Any ideas?
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@iptel.org]
Sent: 22 July 2004 14:10
To: Dave Bath
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] mdump() errors
you may need to filter the messages coming from msilo (ser host) and not
call failure route for those (if src_ip==127.0.0.1 or src_ip==ser_ip
skip failure route).
Daniel
On 7/22/2004 2:51 PM, Dave Bath wrote:
call_id=1bcf7e00-23427(a)161.30.94.68,
d
>-cced, code=477
>
>interface: eth0 (161.30.94.64/255.255.255.224)
>filter: ip and ( port 5060 )
>match: UDP
>#
>U 81.86.136.86:5060 -> 161.30.94.68:5060
>REGISTER sip:sip.dev.inmarsat.com SIP/2.0..Via: SIP/2.0/UDP
>81.86.136.86:50
>60;rport;branch=z9hG4bKDA365D6C01604EF4ABC2FED4B3AAF541..From: Dave
Bath
><s
>ip:admin@sip.dev.inmarsat.com>;tag=1598567160..To: Dave Bath
><sip:admin@sip
>.dev.inmarsat.com>..Contact: "Dave Bath"
><sip:admin@81.86.136.86:5060>..Cal
>l-ID: F64F298D25B34CB69E54236E6B62A53B@sip.dev.inmarsat.com..CSeq:
43904
>RE
>GISTER..Expires: 1800..Max-Forwards: 70..User-Agent: X-Lite release
>1103m..
>Content-Length: 0....
>#
>U 161.30.94.68:5060 -> 81.86.136.86:5060
>SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP
>81.86.136.86:5060;rport=5060;bra
>nch=z9hG4bKDA365D6C01604EF4ABC2FED4B3AAF541..From: Dave Bath
><sip:admin@sip
>.dev.inmarsat.com>;tag=1598567160..To: Dave Bath
><sip:admin@sip.dev.inmarsa
>t.com>;tag=b27e1a1d33761e85846fc98f5f3a7e58.3ce6..Call-ID:
>F64F298D25B34CB6
>9E54236E6B62A53B@sip.dev.inmarsat.com..CSeq: 43904
>REGISTER..WWW-Authentica
>te: Digest realm="sip.dev.inmarsat.com",
>nonce="40ffa3926d16f7926917b380f86
>83ceb509974df"..Server: Sip EXpress router (0.8.12
>(i386/linux))..Content-L
>ength: 0..Warning: 392 161.30.94.68:5060 "Noisy feedback tells:
>pid=23430
>req_src_ip=81.86.136.86 req_src_port=5060
>in_uri=sip:sip.dev.inmarsat.com o
>ut_uri=sip:sip.dev.inmarsat.com via_cnt==1"....
>#
>U 81.86.136.86:5060 -> 161.30.94.68:5060
>REGISTER sip:sip.dev.inmarsat.com SIP/2.0..Via: SIP/2.0/UDP
>81.86.136.86:50
>60;rport;branch=z9hG4bKA3FF9ABFFB7945CBB01DA4A460F991E9..From: Dave
Bath
><s
>ip:admin@sip.dev.inmarsat.com>;tag=1598567160..To: Dave Bath
><sip:admin@sip
>.dev.inmarsat.com>..Contact: "Dave Bath"
><sip:admin@81.86.136.86:5060>..Cal
>l-ID: F64F298D25B34CB69E54236E6B62A53B@sip.dev.inmarsat.com..CSeq:
43905
>RE
>GISTER..Expires: 1800..Authorization: Digest
>username="admin",realm="sip.de
>v.inmarsat.com",nonce="40ffa3926d16f7926917b380f8683ceb509974df",respo
n
s
>e="
>96729bb402fed85833dd6e1fb0cb08c9",uri="sip:sip.dev.inmarsat.com"..Max-
F
o
>rwa
>rds: 70..User-Agent: X-Lite release 1103m..Content-Length: 0....
>#
>U 161.30.94.68:5060 -> 81.86.136.86:5060
>SIP/2.0 200 OK..Via: SIP/2.0/UDP
>81.86.136.86:5060;rport=5060;branch=z9hG4b
>KA3FF9ABFFB7945CBB01DA4A460F991E9..From: Dave Bath
><sip:admin@sip.dev.inmar
>sat.com>;tag=1598567160..To: Dave Bath
><sip:admin@sip.dev.inmarsat.com>;tag
>=b27e1a1d33761e85846fc98f5f3a7e58.29ec..Call-ID:
>F64F298D25B34CB69E54236E6B
>62A53B@sip.dev.inmarsat.com..CSeq: 43905 REGISTER..Contact:
><sip:admin@81.8
>6.136.86:5060>;q=0.00;expires=1800..Server: Sip EXpress router (0.8.12
>(i38
>6/linux))..Content-Length: 0..Warning: 392 161.30.94.68:5060 "Noisy
>feedbac
>k tells: pid=23427 req_src_ip=81.86.136.86 req_src_port=5060
>in_uri=sip:si
>p.dev.inmarsat.com out_uri=sip:sip.dev.inmarsat.com via_cnt==1"....
>###
>
>-----Original Message-----
>From: Daniel-Constantin Mierla [mailto:daniel@iptel.org]
>Sent: 22 July 2004 12:01
>To: Dave Bath
>Cc: serusers(a)lists.iptel.org
>Subject: Re: [Serusers] mdump() errors
>
>The error is related to sendto() function. If it is not the situation
>shown in the error messages, please send the network dumps including
the
>REGISTER request that triggers the mdump(). The error messages are
>underlined below.
>
>Daniel
>
>On 7/22/2004 12:50 PM, Dave Bath wrote:
>
>
>
>>Hey guys,
>>
>>Finally have the proper logic in place to cope with offline messages
>>and messages to UAs that don't support the MESSAGE method... however,
>>
>>
>>
>>
>at
>
>
>>the end of the REGISTER block in my ser.cfg I try and call mdump() to
d
>-57d2,
>
>
>>code=477
>>
>>Is this perhaps because m_dump() is trying to send it to the UA even
>>though the UA does not support MESSAGE? If so, is there a way I can
>>catch it? Does the registration process interrogate the UA as to which
>
>
>
>
>>--------------------------------------------------------------------- -
As a follow up to this, it seems theres some bizarre
looping going
on....
Now that I've had a UA sign on and off a few times, the number of
messages to offline users in the syslog is increasing exponentially...
If I just start with one message sent from test1-->admin while admin is
(online-but-doesn't-support-MESSAGE) then I see the message stored
correctly. If I go to Serweb I see:
sip:test1@sip.dev.inmarsat.com today 13:42
test
correctly.
When admin's UA signs off and back on again, I see the following... in
serweb
sip:test1@sip.dev.inmarsat.com today 13:42
test
sip:test1@sip.dev.inmarsat.com today 13:43
[Offline message - Thu Jul 22 13:42:58 2004] test
And the following in the error log:
Jul 22 13:43:29 sip /usr/sbin/ser[30426]: MESSAGING: Offline messages
dumped
Jul 22 13:43:29 sip /usr/sbin/ser[30431]: MESSAGING: Destination UA
does
not support MESSAGE requests. Message Stored.
Jul 22 13:43:29 sip /usr/sbin/ser[30431]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com,
o-uri=sip:admin@81.86.136.86:5060, call_id=769feac0-30426(a)161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54e
d
-7963, code=202
Jul 22 13:43:29 sip /usr/sbin/ser[30427]: MESSAGING: Message to offline
user received -> storing using msilo...
Jul 22 13:43:30 sip /usr/sbin/ser[30427]: MESSAGING: offline message
NOT
stored
Jul 22 13:43:30 sip /usr/sbin/ser[30427]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:test1@sip.dev.inmarsat.com,
o-uri=sip:test1@sip.dev.inmarsat.com,
call_id=769feac1-30431(a)161.30.94.68,
from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54e
d
-c61d, code=503
It seems that mdump() somehow doesn't pick up the fact that admin is
now
not an offline user, so it generates a new message...
any ideas?!
(*begs*)!
Very best regards,
Dave
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Dave Bath
Sent: 22 July 2004 12:58
To: serusers(a)lists.iptel.org
Subject: RE: [Serusers] mdump() errors
Ok! Well... adding in the server name to hosts file solved that
problem.. thanks for pointing me in the right direction!
However... now there's some more weirdness... as you can see, when the
registration happens, mdump() tries to send all the currently stored
messages.. but, my failure_route picks it up and enters the next line
"Destination UA does not support... ". However, I don't understand
what
happens after that... I don't understand why I then
get a "Message to
offline user received.." - that should only appear when sending to a
user which doesn't have a current location...
When not using mdump().. i.e. I'm just sending IMs using serweb to (1)
offline UAs and (2) Unsupported UAs I do not see this problem... only
the correct entries are in the log.
Perhaps I do not understand the way mdump() works?
Any thoughts gratefully receieved...
D
Jul 22 12:49:40 sip /usr/sbin/ser[23423]: MESSAGING: Offline messages
dumped
Jul 22 12:49:40 sip /usr/sbin/ser[23424]: MESSAGING: Destination UA
does
not support MESSAGE requests. Message Stored.
Jul 22 12:49:40 sip /usr/sbin/ser[23424]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com,
o-uri=sip:admin@81.86.136.86:5060, call_id=1bcf7e01-23423(a)161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54e
d
-322f, code=202
Jul 22 12:49:40 sip /usr/sbin/ser[23427]: MESSAGING: Message to offline
user received -> storing using msilo...
Jul 22 12:49:40 sip /usr/sbin/ser[23427]: MESSAGING: offline message
NOT
stored
Jul 22 12:49:40 sip /usr/sbin/ser[23427]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:test1@sip.dev.inmarsat.com,
o-uri=sip:test1@sip.dev.inmarsat.com,
call_id=1bcf7e01-23424(a)161.30.94.68,
from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54e
d
-4a28, code=503
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@iptel.org]
Sent: 22 July 2004 12:38
To: Dave Bath
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] mdump() errors
How is registered sip.dev.inmarsat.com in your DNS? mdupm() tries to
send messages to <sip:admin@sip.dev.inmarsat.com>. Is there an IP
associated with this domain or a SRV entry for it?
Daniel
On 7/22/2004 1:22 PM, Dave Bath wrote:
>Hey Daniel,
>
>Many thanks for reply. I don't think it is as stated in error
messages
>- as I have a single machine with a single NIC and
single IP. Here
are
the network
dumps foe the register statement, and corresponding syslog
entry.
Jul 22 12:17:58 sip /usr/sbin/ser[23427]: MESSAGING: Offline messages
dumped
Jul 22 12:17:58 sip /usr/sbin/ser[23419]: ERROR: udp_send:
sendto(sock,0xbd72b0f8,633,0,0xbd72a464,16): Invalid argument(22)
Jul 22 12:17:58 sip /usr/sbin/ser[23419]: CRITICAL: invalid
sendtoparameters one possible reason is the server is bound to
localhost
>and attempts to send to the net
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: msg_send: ERROR: udp_send
>failed
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: ERROR: t_forward_nonack:
>sending request failed
>Jul 22 12:17:58 sip /usr/sbin/ser[23419]: ACC: transaction answered:
>method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com,
>o-uri=sip:admin@81.86.136.86:5060,
>from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54
e
>>make sure any offline messages are delivered to
the UA.... However
>>
>>
>>
>>
>when
>
>
>
>
>>registering with a UA which doesn't support MESSAGE method (I haven't
>>got one which does support it right now..) I
get the following:
>>
>>Jul 22 11:29:20 sip /usr/sbin/ser[23423]: MESSAGING: Offline messages
>>>dumped
>>>
>>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: ERROR: udp_send:
>>>sendto(sock,0xbd72b0f8,633,0,0xbd72a
>>>
>>>464,16): Invalid argument(22)
>>>
>>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: CRITICAL: invalid
>>>sendtoparameters one possible reaso
>>>
>>>n is the server is bound to localhost and attempts to send to the net
>>>
>>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: msg_send: ERROR: udp_send
>>>
>>>
>>>
>>>
>>failed
>>
>>
>>
>>
>>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: ERROR: t_forward_nonack:
>>>sending request failed
>>>
>>>
>>>
>>>
>>>
>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>>
>>
>>
>>>Jul 22 11:29:20 sip /usr/sbin/ser[23418]: ACC: transaction answered:
>>>method=MESSAGE, i-uri=sip:
>>>
>>>admin(a)sip.dev.inmarsat.comarsat.com, o-uri=sip:admin@81.86.136.86:5060,
>>>call_id=1bcf7e00-23423(a)161.30.94
>>>
>>>.68,
>>>
>>>
>>>
>>>
>>>
>from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54
e
>>
>>
>>
>>
>
>
>
>
>>methods it supports? Perhaps if this is the case, I could only do an
>>m_dump() if the UA supported messages? Or does m_dump() have its own
>>error handling somewhere?
>>
>>Sorry for all the questions!
>>
>>NB. I don't get this message when sending an IM to an offline or an
>>online-but-message-unsupported-UA... only as part of the m_dump in my
register block...
Many thanks in advance,
Dave
/-------------------------------------/
/Dave Bath/
/dave(a)fuuz.com <mailto:dave@fuuz.com>/
/www.fuuz.com <http://www.fuuz.com>/
/07736 232085/
NOTE: The information contained in this email is intended for the
named recipients only, it may be privileged and confidential. If you
are not the intended recipient, you must not copy distribute or take
any action in reliance upon it. No warranties or assurances are made
in relation to the safety and content of this email and any
attachments. No liability is accepted for any consequences arising
from it >
>
-
>>
>>
>
>
>-
>
>
>
>
>>_______________________________________________
>>Serusers mailing list
>>serusers(a)lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>
>>
>
>
>
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
>
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
22 Jul
22 Jul
4 p.m.
New subject: [Serusers] mdump() errors
You find relevant information about how the msilo methods behave and the
impact of module's parameters on them, in the README file of the module.
When the user goes offline, mdump() returns immediately. When the user
goes online, mdump() dumps all messages stored for user which is found
in URI of To header.
When a message is stored (calling mstore()), msilo is able to notify the
sender that the destination is offline -- that happens only if you set
registrar parameter. If you don't filter out the messages sent by
mdump() and you process them in a failure route where you call mstore()
then, of course, you will get the message stored and a notification message.
If you send me the config file, I will take a look.
Daniel
On 7/22/2004 3:47 PM, Dave Bath wrote:
The problem seems to be something to do with
sip_registrar sending
messages...
I don't quite understand how mdump() works... because when admin logs
off/logs in.. I see in the log that msilo is trying to send messages to
test1 as well? And of course this user is still offline... surely
mdump() should only send the messages for the user who has just
registered...
Any ideas?
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@iptel.org]
Sent: 22 July 2004 14:10
To: Dave Bath
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] mdump() errors
you may need to filter the messages coming from msilo (ser host) and not
call failure route for those (if src_ip==127.0.0.1 or src_ip==ser_ip
skip failure route).
Daniel
On 7/22/2004 2:51 PM, Dave Bath wrote:
[...]
23 Jul
23 Jul
3:21 a.m.
New subject: [Serusers] mdump() errors
Dave,
In my opinion (just opinion), store the message or proxy back the response
depending on the situation you have.
If the callee is not login, store the message. There is a chance that the
callee's UA MIGHT support MESSAGE method for later delivery. However, there
is no guarantee as you don't know whether the callee's UA support this
method or not.
Otherwise, proxy the response back to the caller, especially if you receive
"405 Method Not Allowed". There is no point of storing the message. I don't
anticipate the callee will support the MESSAGE method, not until (s)he
change the UA. It's better to let the caller know about the fact and stop
sending IM message again. In other word, do not put a failure route for
MESSAGE method.
To be proactive, you can send an OPTION request to the UA before issuing
m_dump(). You have to call some external script or write a module for that.
A not so recommended but feasible way is check for "Allow" header or MESSAGE
method in "Contact" header. Note that the test is not conclusive as most UA
does not include these headers. Use at your own risk.
if (search("^Contact:(.*);method(.*)MESSAGE(.*)") ||
search("^Allow:(.*)MESSAGE(.*)")) {
log("Client indicate support of MESSAGE method, dump offline
message\n");
m_dump();
} else {
log("Client does not indicate support of MESSAGE method, do
nothing\n");
};
Zeus
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Dave Bath
Sent: Thursday, 22 July 2004 11:48 PM
To: daniel(a)iptel.org
Cc: serusers(a)lists.iptel.org
Subject: RE: [Serusers] mdump() errors
The problem seems to be something to do with sip_registrar
sending messages...
I don't quite understand how mdump() works... because when
admin logs off/logs in.. I see in the log that msilo is
trying to send messages to test1 as well? And of course this
user is still offline... surely
mdump() should only send the messages for the user who has
just registered...
Any ideas?
-----Original Message-----
From: Daniel-Constantin Mierla [mailto:daniel@iptel.org]
Sent: 22 July 2004 14:10
To: Dave Bath
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] mdump() errors
you may need to filter the messages coming from msilo (ser
host) and not
call failure route for those (if src_ip==127.0.0.1 or src_ip==ser_ip
skip failure route).
Daniel
On 7/22/2004 2:51 PM, Dave Bath wrote:
As a follow up to this, it seems theres some
bizarre looping going
on....
Now that I've had a UA sign on and off a few times, the number of
messages to offline users in the syslog is increasing
exponentially...
If I just start with one message sent from test1-->admin
while admin is
(online-but-doesn't-support-MESSAGE) then I
see the message stored
correctly. If I go to Serweb I see:
sip:test1@sip.dev.inmarsat.com today 13:42
test
correctly.
When admin's UA signs off and back on again, I see the
following... in
serweb
sip:test1@sip.dev.inmarsat.com today 13:42
test
sip:test1@sip.dev.inmarsat.com today 13:43
[Offline message - Thu Jul 22 13:42:58 2004] test
And the following in the error log:
Jul 22 13:43:29 sip /usr/sbin/ser[30426]: MESSAGING: Offline
messages
dumped Jul 22 13:43:29 sip /usr/sbin/ser[30431]:
MESSAGING:
Destination
UA
does
not support MESSAGE requests. Message Stored.
Jul 22 13:43:29 sip /usr/sbin/ser[30431]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com,
o-uri=sip:admin@81.86.136.86:5060,
call_id=769feac0-30426(a)161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf7686
1cbb9ed54e
d
-7963, code=202
Jul 22 13:43:29 sip /usr/sbin/ser[30427]: MESSAGING: Message
to offline
user received -> storing using msilo... Jul 22
13:43:30 sip
/usr/sbin/ser[30427]: MESSAGING: offline message
NOT
stored
Jul 22 13:43:30 sip /usr/sbin/ser[30427]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:test1@sip.dev.inmarsat.com,
o-uri=sip:test1@sip.dev.inmarsat.com,
call_id=769feac1-30431(a)161.30.94.68,
from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf7686
1cbb9ed54e
d
-c61d, code=503
It seems that mdump() somehow doesn't pick up the fact that admin is
now
not an offline user, so it generates a new
message... any ideas?!
(*begs*)!
Very best regards,
Dave
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org]
On
Behalf Of Dave Bath
Sent: 22 July 2004 12:58
To: serusers(a)lists.iptel.org
Subject: RE: [Serusers] mdump() errors
Ok! Well... adding in the server name to hosts file solved that
problem.. thanks for pointing me in the right direction!
However... now there's some more weirdness... as you can
see, when the
registration happens, mdump() tries to send all
the currently stored
messages.. but, my failure_route picks it up and enters the
next line
"Destination UA does not support... ".
However, I don't understand
what
happens after that... I don't understand why I
then get a
"Message to
offline user received.." - that should only
appear when
sending to a
user which doesn't have a current location...
When not using mdump().. i.e. I'm just sending IMs using
serweb to (1)
offline UAs and (2) Unsupported UAs I do not see
this
problem... only
the correct entries are in the log.
Perhaps I do not understand the way mdump() works?
Any thoughts gratefully receieved...
D
Jul 22 12:49:40 sip /usr/sbin/ser[23423]: MESSAGING: Offline
messages
dumped Jul 22 12:49:40 sip /usr/sbin/ser[23424]:
MESSAGING:
Destination
UA
does
not support MESSAGE requests. Message Stored.
Jul 22 12:49:40 sip /usr/sbin/ser[23424]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:admin@sip.dev.inmarsat.com,
o-uri=sip:admin@81.86.136.86:5060,
call_id=1bcf7e01-23423(a)161.30.94.68,
from=sip:test1@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf7686
1cbb9ed54e
d
-322f, code=202
Jul 22 12:49:40 sip /usr/sbin/ser[23427]: MESSAGING: Message
to offline
user received -> storing using msilo... Jul 22
12:49:40 sip
/usr/sbin/ser[23427]: MESSAGING: offline message
NOT
stored
Jul 22 12:49:40 sip /usr/sbin/ser[23427]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:test1@sip.dev.inmarsat.com,
o-uri=sip:test1@sip.dev.inmarsat.com,
call_id=1bcf7e01-23424(a)161.30.94.68,
from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf7686
1cbb9ed54e
d
>-4a28, code=503
>
7406
days inactive
7407
days old
2 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Dave Bath -
Zeus Ng