[Serusers] ACK for non-2XX not record-routed
Emmanuel Hislen
hislen at alcatel-lucent.com
Thu Mar 22 17:54:57 CET 2007
OK thanks!
No this is not urgent, I mostly wanted to know if I was missing
something or not since I'm rather new to Record Routing. I just found by
chance the other day that my ACK (from A) was misssing the Route header
in this scenario, so I added it and I was just looking for a way to test
my change. I don't expect this scenario to be used too often either.
I might give the patch a try though.
Regards,
Emmanuel.
Miklos Tirpak wrote:
> ok, I agree, this is a bug. I tried to explain it in the description of
> SER-212, but probably it is not enough detailed.
>
> The problem is basically that loose_route() removes the route HF from
> the INVITE, so the locally generated ACK for non-2xx final response (and
> local CANCEL as well!) should remove the same route HF. But tm module
> does not know that the route HF was removed when it builds the ACK,
> because it is working with the incoming INVITE message buffer instead of
> the outgoing one.
>
> We have changed SER-212 in the bug tracker from "bug" to "wishlist",
> because folks claimed that nobody reported this problem, so the patch is
> not urgent. Until now!!! You are the one who has reported it :)
>
> Anyway, Andrei said that there may be a better way to implement the same
> which does not require message parsing, so this is the reason why the
> patch is in on-hold state. If you problem is urgent, use the patch, or
> vote for changing it back from "wishlist" to "bug".
>
> Regards,
> Miklos
>
> On 03/22/2007 12:50 AM, Emmanuel Hislen wrote:
>> Hi,
>>
>> Agreed on the definition of Route Set, and I have no intention to modify
>> it in-dialog. I'm just worried by the fact that SER doesn't remove the
>> Route header from a request that was record-routed to it before sending
>> it to the next hop.
>>
>> Here are the SIP messages to illustrate what I mean...
>>
>> Setup:
>>
>> UA A ------> SER ------> UA B
>>
>> A is 192.168.1.236
>> SER is 192.168.1.77
>> B is 192.168.1.239
>>
>>
>> Here is the body of my simple ser.cfg for completeness:
>>
>> **********
>> # ------------------------- request routing logic -------------------
>>
>> # main routing logic
>>
>> route{
>>
>> # initial sanity checks -- messages with
>> # max_forwards==0, or excessively long requests
>> if (!mf_process_maxfwd_header("10")) {
>> sl_send_reply("483","Too Many Hops");
>> break;
>> };
>> if (msg:len >= 2048 ) {
>> sl_send_reply("513", "Message too big");
>> break;
>> };
>>
>> xlog("L_DBG","===> Main Route logic...\n");
>>
>> # we record-route all messages -- to make sure that
>> # subsequent messages will go through our proxy; that's
>> # particularly good if upstream and downstream entities
>> # use different transport protocol
>> if (!method=="REGISTER") {
>> xlog("L_DBG","===> Doing Record Route...\n");
>> record_route();
>> }
>>
>> # subsequent messages withing a dialog should take the
>> # path determined by record-routing
>> if (loose_route()) {
>> xlog("L_DBG","===> Loose Routing logic...\n");
>> if ((method=="INVITE" || method=="REFER") &&
>> !has_totag()) {
>> sl_send_reply("403", "Forbidden");
>> break;
>> };
>>
>> # mark routing logic in request
>> append_hf("P-hint: rr-enforced\r\n");
>> route(1);
>> break;
>> };
>>
>> xlog("L_DBG","===> No Loose Routing involved...\n");
>>
>> if (uri!=myself) {
>> xlog("L_DBG","===> NOT for ME...\n");
>> # mark routing logic in request
>> append_hf("P-hint: outbound\r\n");
>> route(1);
>> break;
>> };
>>
>> if (uri==myself) {
>>
>> xlog("L_DBG","===> for ME...[method <%rm> r-uri
>> <%ru>]\n");
>>
>> if (method=="ACK") {
>> route(1);
>> break;
>> } else if (method=="CANCEL") {
>> route(1);
>> break;
>> } else if (method=="INVITE" || method=="OPTIONS") {
>> route(3);
>> break;
>> } else if (method=="REGISTER") {
>> route(2);
>> break;
>> };
>> };
>>
>> route(1);
>> }
>>
>> route[1]
>> {
>> # send it out now; use stateful forwarding as it works reliably
>> # even for UDP2TCP
>> if (!t_relay()) {
>> sl_reply_error();
>> };
>> }
>>
>> route[2]
>> {
>> #
>> -----------------------------------------------------------------
>> # REGISTER Message Handler
>> #
>> -----------------------------------------------------------------
>> # we don't expect ANY Register in this setup...
>> sl_send_reply("401", "Unauthorized");
>> break;
>> }
>>
>> route[3]
>> {
>> #
>> -----------------------------------------------------------------
>> # INVITE Message Handler
>> #
>> -----------------------------------------------------------------
>>
>> if (uri=~"^sip:[0-9]*@") { # PSTN
>> xlog("L_DBG","===> for PSTN...\n");
>>
>> rewritehost("192.168.1.239"); # PSTN GW
>> avp_write("i:45", "inv_timeout");
>> route(1);
>> break;
>> } else {
>> xlog("L_DBG","===> NOT for PSTN...\n");
>>
>> sl_send_reply("404", "User Not Found");
>> break;
>> }
>> }
>> **********
>>
>> Now A calls B, call successful. This shows handling of an ACK to a 2XX
>> response.
>>
>> (I'm removing SDP bodies to keep it short)
>>
>> INVITE captured on A:
>>
>> **********
>> 181742.720: SENDING to 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> INVITE sip:85307 at 192.168.1.77:5060;user=phone SIP/2.0
>> To: <sip:85307 at 192.168.1.77:5060;user=phone>
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817361 INVITE
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK0115514019052115
>> Max-Forwards: 70
>> Allow: REFER,OPTIONS,BYE,CANCEL,ACK,INVITE
>> Supported: replaces
>> Contact: sip:192.168.1.236:5060
>> Content-Type: application/sdp
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> User-Agent: Foo-Bar
>> Content-Length: 205
>> **********
>>
>> INVITE captured on B, has Record-Route from SER:
>>
>> **********
>> 181747.640: RECEIVED from 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> INVITE sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> Record-Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> To: <sip:85307 at 192.168.1.77:5060;user=phone>
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817361 INVITE
>> Via: SIP/2.0/UDP 192.168.1.77;branch=z9hG4bK4014.1299ece.0
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK0115514019052115
>> Max-Forwards: 16
>> Allow: REFER,OPTIONS,BYE,CANCEL,ACK,INVITE
>> Supported: replaces
>> Contact: sip:192.168.1.236:5060
>> Content-Type: application/sdp
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> User-Agent: Foo-Bar
>> Content-Length: 205
>> **********
>>
>> --------------------
>>
>> 200 OK captured on B, has Record-Route:
>>
>> **********
>> 181749.780: SENDING to 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 192.168.1.77;branch=z9hG4bK4014.1299ece.0
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK0115514019052115
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817361 INVITE
>> Allow: REFER,OPTIONS,BYE,CANCEL,ACK,INVITE
>> Supported: replaces
>> Record-Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> Contact: <sip:85307 at 192.168.1.239:5060;user=phone>
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> Content-Type: application/sdp
>> Server: Foo-Bar
>> User-Agent: Foo-Bar
>> Content-Length: 204
>> **********
>>
>> 200 OK captured on A, has Record-Route:
>>
>> **********
>> 181744.870: RECEIVED from 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> SIP/2.0 200 OK
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK0115514019052115
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817361 INVITE
>> Allow: REFER,OPTIONS,BYE,CANCEL,ACK,INVITE
>> Supported: replaces
>> Record-Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> Contact: <sip:85307 at 192.168.1.239:5060;user=phone>
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> Content-Type: application/sdp
>> Server: Foo-Bar
>> User-Agent: Foo-Bar
>> Content-Length: 204
>> **********
>>
>> --------------------
>>
>> ACK captured on A, has Route header:
>>
>> **********
>> 181744.880: SENDING to 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> ACK sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817361 ACK
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK0115521825db60f5
>> Max-Forwards: 70
>> Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> User-Agent: Foo-Bar
>> Content-Length: 0
>> **********
>>
>> ACK captured on B, has NO Route header, has Record-Route header:
>>
>> **********
>> 181749.800: RECEIVED from 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> ACK sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> Record-Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817361 ACK
>> Via: SIP/2.0/UDP 192.168.1.77;branch=0
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK0115521825db60f5
>> Max-Forwards: 16
>> User-Agent: Foo-Bar
>> Content-Length: 0
>> P-hint: rr-enforced
>> **********
>>
>> --------------------
>> --------------------
>>
>> Now A re-INVITEs B, B rejects with 415, this shows handling of an ACK
>> to a non-2XX response.
>>
>>
>> re-INVITE captured on A, has Route header
>>
>> **********
>> 181775.580: SENDING to 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> INVITE sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817362 INVITE
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK01155e16dc5473f3
>> Max-Forwards: 70
>> Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> Contact: sip:192.168.1.236:5060
>> Content-Type: application/sdp
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> User-Agent: Foo-Bar
>> Content-Length: 200
>> **********
>>
>> re-INVITE captured on B, has NO Route header, has Record-Route header:
>>
>> **********
>> 181780.500: RECEIVED from 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> INVITE sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> Record-Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817362 INVITE
>> Via: SIP/2.0/UDP 192.168.1.77;branch=z9hG4bK1014.fff3b3e5.0
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK01155e16dc5473f3
>> Max-Forwards: 16
>> Contact: sip:192.168.1.236:5060
>> Content-Type: application/sdp
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> User-Agent: Foo-Bar
>> Content-Length: 200
>> P-hint: rr-enforced
>> **********
>>
>> --------------------
>>
>> 415 captured on B:
>>
>> **********
>> 181780.510: SENDING to 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> SIP/2.0 415 Unsupported Media Type
>> Via: SIP/2.0/UDP 192.168.1.77;branch=z9hG4bK1014.fff3b3e5.0
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK01155e16dc5473f3
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817362 INVITE
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> Server: Foo-Bar
>> User-Agent: Foo-Bar
>> Content-Length: 0
>> **********
>>
>> 415 captured on A:
>>
>> **********
>> 181775.600: RECEIVED from 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> SIP/2.0 415 Unsupported Media Type
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK01155e16dc5473f3
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817362 INVITE
>> Accept: application/sdp
>> Accept-Encoding:
>> Accept-Language: en
>> Server: Foo-Bar
>> User-Agent: Foo-Bar
>> Content-Length: 0
>> **********
>>
>> --------------------
>>
>> ACK captured on A, has same Route header as re-INVITE as per RFC3261
>> section 17.1.1.3:
>>
>> **********
>> 181775.600: SENDING to 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> ACK sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> CSeq: 1817362 ACK
>> Via: SIP/2.0/UDP 192.168.1.236:5060;branch=z9hG4bK01155e16dc5473f3
>> Max-Forwards: 70
>> Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> User-Agent: Foo-Bar
>> Content-Length: 0
>> **********
>>
>> ACK captured on B, still has Route Header !?!?!?!:
>>
>> **********
>> 181780.510: RECEIVED from 192.168.1.77:5060
>> -----------------------------------------------------------------------------
>>
>> ACK sip:85307 at 192.168.1.239:5060;user=phone SIP/2.0
>> Via: SIP/2.0/UDP 192.168.1.77;branch=z9hG4bK1014.fff3b3e5.0
>> From: <sip:192.168.1.236:5060>;tag=b2ce30d4-2062aaaa-ec187086
>> Call-ID: f40a387b-3-2062aaaa at 192.168.1.236
>> To:
>> <sip:85307 at 192.168.1.77:5060;user=phone>;tag=d85b805d-2062aaaa-ef187086
>> CSeq: 1817362 ACK
>> Route: <sip:192.168.1.77;ftag=b2ce30d4-2062aaaa-ec187086;lr>
>> User-Agent: Sip EXpress router(0.9.6 (i386/linux))
>> Content-Length: 0
>> **********
>>
>> --------------------
>>
>>
>> I'm under the impression that SER handles the second ACK as if it was
>> the ACK for a non-2XX response to an initial INVITE (reasonably
>> assuming initial INVITES have usually no Route header). In other words
>> SER assumes that this ACK is not supposed to be Record Routed and
>> therefore does not remove the Route header. Something like that...
>>
>> Let me know what you think.
>>
>> Thanks,
>>
>> Emmanuel.
>>
>>
>> Miklos Tirpak wrote:
>>> Hello,
>>>
>>> comments inline
>>>
>>> On 03/20/2007 09:52 AM, Greger V. Teigre wrote:
>>>> I'm not sure that I understand what you mean is wrong. It would be
>>>> easier to follow if you include the ACKs. And non-2xxs, what is
>>>> exactly the exchange? A full SIP trace would help...
>>>> g-)
>>>>
>>>> Emmanuel Hislen wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> I've been using SER (0.9.6) as a Proxy doing Loose Routing between
>>>>> 2 endpoints.
>>>>>
>>>>>
>>>>> If I place a call I can see how the ACK for the 2XX response to the
>>>>> INVITE is properly handled (Route header removed, Record-Route
>>>>> inserted).
>>>>>
>>>>> Now with the call still up, I do a re-INVITE which is rejected with
>>>>> a 415. The re-INVITE request sent by UAC contained a Route header,
>>>>> as it was an in-dialog request in a record-routed dialog. Now as
>>>>> per RFC3261 section 17.1.1.3:
>>>>>
>>>>> If the INVITE request whose response is being acknowledged had
>>>>> Route
>>>>> header fields, those header fields MUST appear in the ACK. This is
>>>>> to ensure that the ACK can be routed properly through any
>>>>> downstream
>>>>> stateless proxies.
>>>>>
>>>>>
>>>>> My UAC complied with the above, but SER seemed to choke on this:
>>>>>
>>>>> whereas the ACK for 2XX was successfully routed by SER in the
>>>>> original INVITE, the ACK for non-2XX (looking exactly the same:
>>>>> same Request URI, same IP destination, same Route header, ...
>>>>> different Via branch of course) is not handled properly: yes the
>>>>> ACK reaches UAS but it still has the Route header in it, and no
>>>>> Record-Route was added. And I'm guessing that if there had been
>>>>> another proxy in the Route Set on the way to the UAS it would have
>>>>> been bypassed.
>>>
>>> just to make some definition clear: Route set is the collection of
>>> Route headers, the Record-route headers are used only to learn the
>>> route-set. So the missing Record-route header does not have any
>>> impact of the ACK routing, however could have an impact of routing
>>> the BYE for example in your case. But the RFC says that the in-dialog
>>> requests do not modify the previously learned route-set:
>>>
>>> "12.2 Requests within a Dialog
>>> ...
>>> Requests within a dialog MAY contain Record-Route and Contact header
>>> fields. However, these requests do not cause the dialog's route set
>>> to be modified, although they may modify the remote target URI.
>>> Specifically, requests that are not target refresh requests do not
>>> modify the dialog's remote target URI, and requests that are target
>>> refresh requests do. For dialogs that have been established with an
>>> INVITE, the only target refresh request defined is re-INVITE (see
>>> Section 14). Other extensions may define different target refresh
>>> requests for dialogs established in other ways.
>>>
>>> Note that an ACK is NOT a target refresh request."
>>>
>>> But be careful with modifying the route-set in SER (not with
>>> record-routeing but with modifying the route headers directly)!
>>> More info: http://tracker.iptel.org/browse/SER-212?page=all
>>>
>>> Regards,
>>> Miklos
>>>
>>>>>
>>>>>
>>>>> SER traces for ACK-2XX:
>>>>>
>>>>>> 0(13574) ===> Loose Routing logic...
>>>>>> 0(13574) parse_headers: flags=-1
>>>>>> 0(13574) DEBUG: t_newtran: msg id=89 , global msg id=88 , T on
>>>>>> entrance=0xffffffff
>>>>>> 0(13574) parse_headers: flags=-1
>>>>>> 0(13574) parse_headers: flags=60
>>>>>> 0(13574) t_lookup_request: start searching: hash=41794, isACK=1
>>>>>> 0(13574) parse_headers: flags=28
>>>>>> 0(13574) DEBUG: t_lookup_request: e2e proxy ACK found
>>>>>> 0(13574) parse_headers: flags=4
>>>>>> 0(13574) DEBUG: totag for e2e ACK found: 0
>>>>>> 0(13574) SER: forwarding ACK statelessly
>>>>>
>>>>>
>>>>> SER traces for ACK-non-2XX:
>>>>>
>>>>>> 0(13574) ===> Loose Routing logic...
>>>>>> 0(13574) parse_headers: flags=-1
>>>>>> 0(13574) DEBUG: t_newtran: msg id=92 , global msg id=91 , T on
>>>>>> entrance=0xffffffff
>>>>>> 0(13574) parse_headers: flags=-1
>>>>>> 0(13574) parse_headers: flags=60
>>>>>> 0(13574) t_lookup_request: start searching: hash=41807, isACK=1
>>>>>> 0(13574) DEBUG: RFC3261 transaction matched, tid=007d7195499e33a1
>>>>>> 0(13574) DEBUG: t_lookup_request: transaction found (T=0xb616ae48)
>>>>>> 0(13574) DEBUG: cleanup_uac_timers: RETR/FR timers reset
>>>>>> 0(13574) DEBUG: add_to_tail_of_timer[2]: 0xb616ae90
>>>>>> 0(13574) DEBUG:destroy_avp_list: destroying list (nil)
>>>>>> 0(13574) receive_msg: cleaning up
>>>>>
>>>>>
>>>>> This doesn't seem right, am I missing something here?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Emmanuel.
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> Serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> Serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>
>
More information about the sr-users
mailing list