[Spce-user] Spce timeout for T.38 Reinvites
Daniel Grotti
dgrotti at sipwise.com
Fri Jan 24 08:01:58 EST 2014
Hi,
I know,but you said that a 408 is triggered after 9sec from a
provisionale reply 100 Trying, but 9sec should be fr_timer and not
fr_inv_timer.
Anyway, try to increase both of them:
t_reset_fr();
t_set_fr(fr_inv_timeout, fr_timeout)
Daniel
On 01/24/2014 12:38 PM, Matthew Ogden wrote:
> Hi Daniel,
>
> My normal fr_timer and fr_inv_timer in proxy/kamailio.cfg are unchanged. I
> just want to change it for faxing equipment subscribers.
>
> I'm trying to initiate the T38 invite, and allow for up to 45 seconds for
> a reply.
>
> Their gateways will also wait up to 45 seconds to initate the T38. (They
> will send a provisional 100 Trying, but only a final response on success
> or after 45 seconds to a T38 invite).
>
> Regards
>
>> -----Original Message-----
>> From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-
>> bounces at lists.sipwise.com] On Behalf Of Daniel Grotti
>> Sent: 24 January 2014 12:31 PM
>> To: spce-user at lists.sipwise.com
>> Subject: Re: [Spce-user] Spce timeout for T.38 Reinvites
>>
>> Hi,
>>
>> what are you fr_timer and fr_inv_timer in proxy/kamailio.cfg ?
>>
>> Anyway, it looks like your upstream didn't reply with a final response
> after
>> 9sec, that's quite strange.
>>
>> Daniel
>>
>>
>>
>>
>> On 01/23/2014 07:38 PM, Matthew Ogden wrote:
>>> Hi
>>>
>>>
>>>
>>> Well you are right, its passing through ROUTE_OUTBOUND, to test I
>>> thought, let me try just setting t_set_fr for everything through
>>> ROUTE_OUTBOUND, and logging it. well, it logs for every ACK and INVITE
>>> (including my T.38 INVITE), yet t_set_fr is having no impact on the
>>> T38 reINVITE timeout.
>>>
>>>
>>>
>>> My understanding is once t_set_fr is used, its used for the entire
>>> transaction (but does that mean that specific INVITE or the call
>>> transaction ID?). Either way, my test above should truly set the
>>> timeout to greater than 9 seconds. Its definitely the kamailio proxy
>>> that sending the 408 timeout if I watch "ngrep-sip b".
>>>
>>>
>>>
>>> Anyone out there with some ideas?
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 23 January 2014 02:35 PM
>>> *To:* Matthew Ogden
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Hi Matthew,
>>>
>>>
>>>
>>> Yes that is the one, i wanted to check To tag...
>>>
>>>
>>>
>>> Regarding the rounting in proxy.cfg...first INVITE went through
>>> routing block ROUTE_PSTN before ROUTE_OUTBOUND...second INVITE
>> went
>>> through ROUTE_OUTBOUND because it is sequential INVITE, has to tag
>>>
>>>
>>>
>>> ### look at this part
>>>
>>> if(loose_route()) in route[ROUTE_PRX_REQUEST] block
>>>
>>>
>>>
>>> there is code which will route sequential INVITEs directly to the
>>> ROUTE_OUTBOUD...than sems..lb...B subscriber...
>>>
>>>
>>>
>>> For that reason you put your modification in ROUTE_OUTBOUND...the bad
>>> news is that i dont have any other idea...it should work this way
>>>
>>>
>>>
>>> :(
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ivan
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>> On Thu, Jan 23, 2014 at 12:03 PM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> Are you referring to just the actual UDP packet invite as follows?
>>>
>>>
>>>
>>> U 2014/01/22 23:04:31.308587 <subscriber-ip>:5060 -> <spce-ip>:5060
>>>
>>> INVITE sip:ngcp-lb@<spce-ip>:5060;ngcpct=c2lwOjEyNy4wLjAuMTo1MDgw
>> SIP/2.0'
>>>
>>> From:
>>> <sip:2<source-number>@<subscriber-ip>:5060>;tag=acfc6e70-0-13c4-
>> 55013-95-68a0b765-95'
>>>
>>> To:
>>> <sip:<destinatio-number>@<spce-ip>:5060>;tag=678C91AA-
>> 52E0325900042C11-12800700'
>>>
>>> Call-ID: acebd2c0-0-13c4-55013-95-e27344f-95'
>>>
>>> CSeq: 3 INVITE'
>>>
>>> Via: SIP/2.0/UDP
> <subscriber-ip>:5060;branch=z9hG4bK-9b-25fd7-5aeed540'
>>>
>>> Route:
>>> <sip:<spce-ip>;lr=on;r2=on;ftag=acfc6e70-0-13c4-55013-95-68a0b765-
>> 95;ngcplb=yes;socket=udp:<spce-ip>:5060>'
>>>
>>> Route:
>>> <sip:127.0.0.1;lr=on;r2=on;ftag=acfc6e70-0-13c4-55013-95-68a0b765-
>> 95;ngcplb=yes;socket=udp:<spce-ip>:5060>'
>>>
>>> Route:
>>> <sip:127.0.0.1:5062;lr=on;ftag=acfc6e70-0-13c4-55013-95-68a0b765-
>>
> 95;did=79f.5671;mpd=ii;ice_caller=strip;ice_callee=strip;rtpprx=yes;vsf=N0
> 52
>> NGJIdExXSlZWTFBVaGg0aEE3TnY0YkhOeWd8Zg-->'
>>>
>>> Contact: <sip:<subscriber-ip>:5060>'
>>>
>>> Proxy-Authorization: Digest username="<subscriber
>>> username>FAX",realm="<subscriber-
>> ip>",nonce="UuAzhFLgMlg1KWF2hnRHnMCcBuk3SrHe",uri="sip:ngcp-
>> lb@<spce-
>> ip>:5060;ngcpct=c2lwOjEyNy4wLjAuMTo1MDgw",response="a5a32093e94732
>> 44dd92e16579383ce0",algorithm=MD5'
>>>
>>> Max-Forwards: 70'
>>>
>>> User-Agent: Brktsip/6.5.8B12 (Dialogic)'
>>>
>>> Content-Type: application/sdp'
>>>
>>> Content-Length: 282'
>>>
>>> '
>>>
>>> v=0'
>>>
>>> o=- 2211964145 0499591000 IN IP4 <subscriber-ip>'
>>>
>>> s=no_session_name'
>>>
>>> t=0 0'
>>>
>>> m=image 56016 udptl t38'
>>>
>>> c=IN IP4 <subscriber-ip>'
>>>
>>> a=T38FaxVersion:3'
>>>
>>> a=T38MaxBitRate:33600'
>>>
>>> a=T38FaxRateManagement:transferredTCF'
>>>
>>> a=T38FaxMaxBuffer:200'
>>>
>>> a=T38FaxMaxDatagram:72'
>>>
>>> a=T38FaxUdpEC:t38UDPRedundancy
>>>
>>> #
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 23 January 2014 11:27 AM
>>>
>>>
>>> *To:* Matthew Ogden
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Hmm, wierd.
>>>
>>>
>>>
>>> Can you paste here second INVITE,one with T38, without ip address/port
>>> and usernames?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ivan
>>>
>>>
>>>
>>> On Wed, Jan 22, 2014 at 10:11 PM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> Hi Ivan,
>>>
>>>
>>>
>>> The timer does seem to take make effect, but not on the T38 INVITE,
>>> only on the normal invite.
>>>
>>>
>>>
>>> Here is a number answers quickly, it still has a 9 second timeout:
>>>
>>>
>>>
>>>
>>>
>>> Here is another number that's having an issue to answer the initial
>>> invite, so you can see my server is cycling through its peers, you can
>>> also see its timeouts are exactly 30 seconds:
>>>
>>>
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 22 January 2014 02:06 PM
>>>
>>>
>>> *To:* Matthew Ogden
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Hi Matthew,
>>>
>>>
>>>
>>> You should read the file.
>>>
>>>
>>>
>>> :)
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ivan
>>>
>>>
>>>
>>> On Wed, Jan 22, 2014 at 12:08 PM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> Thanks Ivan, I'll give that a try,
>>>
>>>
>>>
>>> Whats the difference between ROUTE_OUTBOUND and ROUTE_PSTN (or
>> how can
>>> you tell)?, or where can I read more about the sections that are used
>>> in what order. or should I really just understand that from reading
>>> the file, the same way I look at a piece of PHP code etc?
>>>
>>>
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 22 January 2014 01:05 PM
>>> *To:* Matthew Ogden
>>>
>>>
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Hi Matthew,
>>>
>>>
>>>
>>> Ok, based on your picture from mail Jan 17, you got 2x INVITEs.First
>>> one, which is replied with 200 OK, and second one which doesnt go to
>>> route_pstn, it is relaying to sems directly.So, can you paste your
>>> small modification in ROUTE_OUTBOUND and test it.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Ivan
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jan 22, 2014 at 10:15 AM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> Hi Ivan,
>>>
>>>
>>>
>>> Not much in there, but there was for the end of the call.
>>>
>>>
>>>
>>>
>>>
>>> Jan 21 09:58:00 spce sems[23613]: [#7fd012c04700] [send_request,
>>> trans_layer.cpp:935] ERROR: Could not update UAC state for request.
>>>
>>> Jan 21 09:58:00 spce sems[23613]: [#7fd0125fe700] [handleSipMsg,
>>> AmSipDispatcher.cpp:51] INFO: unhandled SIP reply: BYE
>>> [code:200;phrase:[OK];i:ace566c0-0-13c4-55013-37f36-74fa9a62-37f36_;r2
>>> =on;lr=on;ftag=0CD738CB-52DE2879000894EE-12D05700;ngcplb=yes>,
>>> <sip:<Tier1IP>;lr;ftag=0CD738CB-52DE2879000894EE-
>> 12D05700>];m:<sip:27<Destination#>@@<Tier1IP-2>:5070>;hdr:[User-Agent:
>>> ECN M-Proto: udp#015#012P-NGCP-Src-Af:
>>> 4#015#012];next-r-uri:sip:27<Destination#>@<Tier1IP-2>:5070;]
>>>
>>> Jan 21 09:59:52 spce sems[23613]: [#7fd0126ff700] [handleSipMsg,
>>> AmSipDispatcher.cpp:54] WARNING: unhandled SIP reply: INVITE
>>> [code:408;phrase:[Request
>>> Timeout];i:ace566c0-0-13c4-55013-370#015#012P-NGCP-Src-Port:
>>> 5060#015#012P-NGCP-Src-Proto: udp#015#012P-NGCP-Src-Af: 4#015#012];]
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 21 January 2014 09:35 PM
>>>
>>>
>>> *To:* Matthew Ogden
>>> *Cc:* Spce-user
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> HI Matthew,
>>>
>>> Can you paste result from
>>>
>>> grep sip_timer /etc/sems/sems.conf
>>>
>>> Regards,
>>> Ivan
>>>
>>>
>>>
>>> On Tue, Jan 21, 2014 at 9:42 AM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 20 January 2014 01:35 PM
>>>
>>>
>>> *To:* Matthew Ogden
>>> *Cc:* Spce-user
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Hi Mattwhew,
>>>
>>> Can you paste logs from proxy and lb?
>>>
>>> Regards,
>>> Ivan
>>>
>>>
>>>
>>> On Mon, Jan 20, 2014 at 11:54 AM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> As per
>>> http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_set_fr
>>>
>>> (I see it is used else where in the proxy.tt2 file too).
>>>
>>>
>>>
>>> I tried putting this in proxy.custom.tt2 line 1076 (part of
>>> ROUTE_PSTN)
>>>
>>>
>>>
>>> #our fax testing is on subscriber with ext ID TN001FAX
>>>
>>>
>>>
>>> if($avp(s:caller_ext_subscriber_id) == "TN001FAX")
>>>
>>> {
>>>
>>> t_set_fr(30000);
>>>
>>> xlog("L_INFO", "Changed outbound timer for this call
>>> to 30000ms for faxing\n");
>>>
>>> }
>>>
>>>
>>>
>>> It logs it my proxy log, but 9 seconds is still the timeout of the
>>> INVITE
>>>
>>>
>>>
>>> *From:*Matthew Ogden [mailto:matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>]
>>> *Sent:* 19 January 2014 06:36 PM
>>> *To:* 'Ivan Milivojevic'
>>> *Cc:* 'Spce-user'
>>> *Subject:* RE: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Thanks Ivan
>>>
>>>
>>>
>>> That's definitely what I'm looking for, but perhaps someone out there
>>> can tell me in which section of the proxy/lb that I can have an
>>> override of the timer based on the subscriber name only. (I only need
>>> one subscriber with a much longer timeout).
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com]
>>> *Sent:* 19 January 2014 04:51 PM
>>>
>>>
>>> *To:* Matthew Ogden
>>> *Cc:* Spce-user
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> Hi Matthew,
>>>
>>> Maybe you can try with
>>>
>>>
>>> |fr_timer_avp|
>>>
>>>
>>> check also http://www.iptel.org/faq/sertimers
>>>
>>> Regards,
>>>
>>> Ivan
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jan 18, 2014 at 9:56 AM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> Thanks Ivan!
>>>
>>>
>>>
>>> There is obviously no way to make kamailio have different timeouts for
>>> different INVITE (T.38 vs the rest) types then?
>>>
>>>
>>>
>>> *From:*Ivan Milivojevic [mailto:edesibe at gmail.com
>>> <mailto:edesibe at gmail.com>]
>>> *Sent:* 17 January 2014 08:58 PM
>>> *To:* Matthew Ogden
>>> *Cc:* Spce-user
>>> *Subject:* Re: [Spce-user] Spce timeout for T.38 Reinvites
>>>
>>>
>>>
>>> HI Matthew,
>>>
>>> You can check timeout on kamailio-proxy side...
>>>
>>> # kamailio.cfg.tt2
>>>
>>> modparam("tm", "fr_timer", 9000) ### based on doc ### Timer which hits
>>> if no final reply for a request or ACK for a negative INVITE reply
>>> arrives (in seconds).
>>> modparam("tm", "fr_inv_timer", 180000)
>>>
>>> Regards,
>>>
>>> Ivan
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 17, 2014 at 6:07 PM, Matthew Ogden <matthew at tenacit.net
>>> <mailto:matthew at tenacit.net>> wrote:
>>>
>>> HI
>>>
>>>
>>>
>>> What sets the timeout for a T38 reinvite on SPCE? My timeout is 4000ms
>>> for Sems in config.yml, so clearly its not that, since this took
>>> exactly 9000ms.
>>>
>>>
>>>
>>> What timer/timeout made my SIP server cancel the reinvite? The reason
>>> I need a longer timeout is, the recipient company is answering the
>>> call, then forwarding the through a few rings (extra time before the
>>> sync can actually be caught for t.38).
>>>
>>>
>>>
>>> in this wireshark call graph,
>>>
>>> The left line is my subscriber,
>>>
>>> The middle line is sipserver
>>>
>>>
>>>
>>> Here is picture,
>>>
>>>
>>>
>>> Below and attached are the text representation
>>>
>>> Conv.| Time | subscriber |
>>> Peer |
>>>
>>> | | | my server |
>>>
>>> 2 |18:46:27.453879| INVITE SDP (g711A)
>>> | |SIP From: <sip:2XXXXXXXXX at subscriberip:5060
>>> To:<sip:0XXXXXXXXX at spceIP:5060
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> 2 |18:46:27.454546| 100 Trying|
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> 2 |18:46:27.456403| 407 Proxy Authentication
>>> Required | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> 2 |18:46:27.510806| ACK |
>>> | |SIP Request
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> 2 |18:46:27.514119| INVITE SDP (g711A) |
>>> |SIP From: <sip:2XXXXXXXXX at subscriberip:5060
>>> To:<sip:0XXXXXXXXX at spceIP:5060
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> 2 |18:46:27.514636| 100 Trying|
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 3 |18:46:27.522117| | INVITE SDP
>>> (g711A) |SIP From: <sip:2XXXXXXXXX at subscriberip
>>> To:<sip:2XXXXXXXXXX at peerip
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>> 3 |18:46:27.536103| | 100 Giving a
>>> try |SIP Status
>>>
>>> | | |(5060) <------------------
> (5060) |
>>>
>>> 3 |18:46:28.648929| | 200 OK SDP
>>> (g711A) |SIP Status
>>>
>>> | | |(5060) <------------------
> (5060) |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 2 |18:46:28.650490| 200 OK SDP (g711A)
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> 2 |18:46:28.708976 <tel:708976>| ACK
>>> | | |SIP Request
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 3 |18:46:28.710179| | ACK
>>> | |SIP Request
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 2 |18:46:28.712202| INVITE SDP (t38)
>>> | |SIP From: <sip:2XXXXXXXXX at subscriberip:5060
>>> To:<sip:0 at spceIP:5060
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> 2 |18:46:28.712970| 100 Trying|
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 3 |18:46:28.713577| | INVITE SDP
>>> (t38) |SIP From: <sip:2XXXXXXXXX at subscriberip
>>> To:<sip:2XXXXXXXXXX at peerip
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>> 3 |18:46:28.717171| | 100 Giving a
>>> try |SIP Status
>>>
>>> | | |(5060) <------------------
> (5060) |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 2 |18:46:37.713078| 408 Request Timeout
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> 2 |18:46:37.768451| ACK |
>>> | |SIP Request
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> 2 |18:46:37.770487| BYE |
>>> | |SIP Request
>>>
>>> | |(5060) ------------------> (5060) |
> |
>>>
>>> 2 |18:46:37.771110| 100 Trying|
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> 2 |18:46:37.772098| 200 OK |
>>> | |SIP Status
>>>
>>> | |(5060) <------------------ (5060) |
> |
>>>
>>> ----------------------------------------------------------------------
>>> -------
>>>
>>> 3 |18:46:37.772169| | ACK
>>> | |SIP Request
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>> 3 |18:46:37.772244| | BYE
>>> | |SIP Request
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>> 3 |18:46:37.776329| | BYE
>>> | |SIP Request
>>>
>>> | | |(5060) <------------------
> (5060) |
>>>
>>> 3 |18:46:37.776817| | 200 OK
>>> | |SIP Status
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>> 3 |18:46:37.778354| | 200 OK
>>> | |SIP Status
>>>
>>> | | |(5060) <------------------
> (5060) |
>>>
>>> 3 |18:48:28.920672| | 408 Request
>>> Timeout |SIP Status
>>>
>>> | | |(5060) <------------------
> (5060) |
>>>
>>> 3 |18:48:28.921215| | ACK
>>> | |SIP Request
>>>
>>> | | |(5060) ------------------>
> (5060) |
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
>>> http://lists.sipwise.com/listinfo/spce-user
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Spce-user mailing list
>>> Spce-user at lists.sipwise.com
>>> http://lists.sipwise.com/listinfo/spce-user
>>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> http://lists.sipwise.com/listinfo/spce-user
More information about the Spce-user
mailing list