[OpenSIPS-Users] In dialog requests misrouted
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu May 27 15:42:18 CEST 2010
Hi Bruce,
by simply looking at a reply, is hard to say if you are the right entity
to do the fix. Like here, both 1 and 2 see the private contact in the
reply coming from 4 (same test) but only 2 should do the fixing (it is
on the NAT edge).
As best practice, the proxy should remember that the request was send
somewhere behind a NAT and to accordingly handle the replies (without
any extra check).
Instead of using asterisk, maybe you can use opensips as B2BUA - it is
much lighter.
Regards,
Bogdan
Bruce Borrett wrote:
> Hi Bogdan
>
> I believe I have found the culprit, I managed to get a copy of server
> 1's config, and they are using uac_nat_test("19") in their reply
> route, that is completely wrong is it not? Replies would always be
> fixed? Currently these guys have clients with sbc's connecting
> straight to their server, and from their server straight to asterisk
> pstn gateways. We too just had a simple sbc connecting directly to
> their server. I believe they have hacked there config to a state so
> fubar, that it can only work in that setup. The only way I think we
> might solve this without any hacks to our config is to put a bunch of
> asterisk servers between us and them?
>
> Regards,
> Bruce
>
>
> ------------------------------------------------------------------------
> *From:* Bogdan-Andrei Iancu <bogdan at voice-system.ro>
> *To:* OpenSIPS users mailling list <users at lists.opensips.org>
> *Sent:* Tue, 25 May, 2010 21:28:02
> *Subject:* Re: [OpenSIPS-Users] In dialog requests misrouted
>
> Hi Bruce,
>
> Bruce Borrett wrote:
> > Hi Bogdan
> >
> > Just to complicate things a bit, 4.4.4.4 is the public ip of the nated
> > device... I made a mistake in my trace where I changed the contact
> > address in the initial 200 (from 4.4.4.4), it should have been the
> > nated ip, 5.5.5.5 for example... So you will see then that 2 is in
> > fact fixing the contact, but 1 is then fixing it again...
> why 2 is doing again? if you see a public IP (like 4) in contact, do not
> fix it again!
> >
> > For now we have managed to create a workaround whereby we perform a
> > "lookup location" on any acks, cancels or byes received from 1.1.1.1,
> > this function fixes the ruri to the correct one from the location
> > table, and sends it out correctly. This seems to be working fine so
> far...
> yeah, but it is really a ugly hack that my break SIP routing - ACK is a
> sequential request and must be routed contact + route set only.
>
> Regards,
> Bogdan
> >
> > Thank you for your help,
> >
> > Regards,
> > Bruce
> >
> >
> > ------------------------------------------------------------------------
> > *From:* Bogdan-Andrei Iancu <bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>>
> > *To:* OpenSIPS users mailling list <users at lists.opensips.org
> <mailto:users at lists.opensips.org>>
> > *Sent:* Fri, 21 May, 2010 12:57:37
> > *Subject:* Re: [OpenSIPS-Users] In dialog requests misrouted
> >
> > Hi Bruce,
> >
> > It is a logical problem. The chain is: 3 -> 1 -> 2 -> 4, and when the
> > reply goes back, the NAT traversal must be done by the border entity
> > (first in the public net). So, if 4 is behind nat, then 2 must do it and
> > not 1 (like in your case)
> >
> > Because 1 (and not 2) is "fixing" the contact , the routing info gets
> > lost (the 4 hop is lost). So, guilty is 2 for not fixing the contact in
> > 200 OK from 4.
> >
> > Regards,
> > Bogdan
> >
> > Bruce Borrett wrote:
> > > Hi Bogdan
> > >
> > > Thank you for your reply, that is exactly how I understood it.
> > >
> > > Here is another fuller trace for a better understanding of the
> > > problem, which I believe to be uac_nat_test. On both servers , when a
> > > 200 is received, uac_nat_test is returning true because it is finding
> > > the top via (next hop for reply) to be different to the source ip
> > > (previous hop of reply):
> > >
> > > Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
> > >
> > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> > >
> > > INVITE sip:1111111111 at 2.2.2.2 SIP/2.0
> > > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38>
> > > Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK5be8.eeb63911.0
> > > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060
> > > From: "22222222222" <sip:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > > To: <sip:1111111111 at 2.2.2.2>
> > > Contact: <sip:2222222222 at 3.3.3.3>
> > > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > > CSeq: 102 INVITE
> > > User-Agent: Asterisk PBX
> > > Max-Forwards: 69
> > > Date: Tue, 18 May 2010 06:29:00 GMT
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > > Supported: replaces
> > > X-CRE-ID: "sbc-tp-04-1274164140.30823.0
> > > X-DIALSTRING: SIP/ico-bry-001/1111111111
> > > Content-Type: application/sdp
> > > Content-Length: 259
> > >
> > > v=0
> > > o=root 4296 4296 IN IP4 3.3.3.3
> > > s=session
> > > c=IN IP4 3.3.3.3
> > > t=0 0
> > > m=audio 10060 RTP/AVP 18 101
> > > a=rtpmap:18 G729/8000
> > > a=fmtp:18 annexb=no
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-16
> > > a=silenceSupp:off - - - -
> > > a=ptime:60
> > > a=sendrecv
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Internet Protocol, Src: 2.2.2.2 (2.2.2.2), Dst: 4.4.4.4 (4.4.4.4)
> > >
> > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> > >
> > > INVITE sip:1111111111 at 4.4.4.4 SIP/2.0
> > > Record-Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38>
> > > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38>
> > > Via: SIP/2.0/UDP 2.2.2.2;branch=z9hG4bK5be8.91dcf496.0
> > > Via: SIP/2.0/UDP
> > > 1.1.1.1;rport=5060;received=1.1.1.1;branch=z9hG4bK5be8.eeb63911.0
> > > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060
> > > From: "2222222222" <sip:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > > To: <sip:1111111111 at 2.2.2.2>
> > > Contact: <sip:2222222222 at 3.3.3.3>
> > > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > > CSeq: 102 INVITE
> > > User-Agent: Asterisk PBX
> > > Max-Forwards: 68
> > > Date: Tue, 18 May 2010 06:29:00 GMT
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > > Supported: replaces
> > > X-CRE-ID: "sbc-tp-04-1274164140.30823.0
> > > X-DIALSTRING: SIP/ico-bry-001/1111111111
> > > Content-Type: application/sdp
> > > Content-Length: 259
> > >
> > > v=0
> > > o=root 4296 4296 IN IP4 3.3.3.3
> > > s=session
> > > c=IN IP4 3.3.3.3
> > > t=0 0
> > > m=audio 10060 RTP/AVP 18 101
> > > a=rtpmap:18 G729/8000
> > > a=fmtp:18 annexb=no
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-16
> > > a=silenceSupp:off - - - -
> > > a=ptime:60
> > > a=sendrecv
> > >
> > >
> > >
> > >
> > >
> > > Internet Protocol, Src: 4.4.4.4 (4.4.4.4), Dst: 2.2.2.2 (2.2.2.2)
> > >
> > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> > >
> > > SIP/2.0 200 OK
> > > Via: SIP/2.0/UDP
> 2.2.2.2;branch=z9hG4bK5be8.91dcf496.0;received=2.2.2.2
> > > Via: SIP/2.0/UDP
> > > 1.1.1.1;rport=5060;received=1.1.1.1;branch=z9hG4bK5be8.eeb63911.0
> > > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060
> > > Record-Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38>
> > > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38>
> > > From: "2222222222" <sip:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > > CSeq: 102 INVITE
> > > User-Agent: Asterisk PBX 1.6.0.9
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > > Supported: replaces, timer
> > > Contact: <sip:1111111111 at 4.4.4.4>
> > > Content-Type: application/sdp
> > > Content-Length: 290
> > >
> > > v=0
> > > o=root 2115801714 2115801714 IN IP4 4.4.4.4
> > > s=Asterisk PBX 1.6.0.9
> > > c=IN IP4 4.4.4.4
> > > t=0 0
> > > m=audio 12004 RTP/AVP 18 101
> > > a=rtpmap:18 G729/8000
> > > a=fmtp:18 annexb=no
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-16
> > > a=silenceSupp:off - - - -
> > > a=ptime:60
> > > a=sendrecv
> > >
> > >
> > >
> > >
> > >
> > >
> > > Internet Protocol, Src: 2.2.2.2 (2.2.2.2), Dst: 1.1.1.1 (1.1.1.1)
> > >
> > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> > >
> > > SIP/2.0 200 OK
> > > Via: SIP/2.0/UDP
> > > 1.1.1.1;rport=5060;received=1.1.1.1;branch=z9hG4bK5be8.eeb63911.0
> > > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK55985828;rport=5060
> > > Record-Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38>
> > > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38>
> > > From: "2222222222" <sip:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > > CSeq: 102 INVITE
> > > User-Agent: Asterisk PBX 1.6.0.9
> > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > > Supported: replaces, timer
> > > Contact: <sip:1111111111 at 4.4.4.4>
> > > Content-Type: application/sdp
> > > Content-Length: 290
> > >
> > > v=0
> > > o=root 2115801714 2115801714 IN IP4 4.4.4.4
> > > s=Asterisk PBX 1.6.0.9
> > > c=IN IP4 4.4.4.4
> > > t=0 0
> > > m=audio 12004 RTP/AVP 18 101
> > > a=rtpmap:18 G729/8000
> > > a=fmtp:18 annexb=no
> > > a=rtpmap:101 telephone-event/8000
> > > a=fmtp:101 0-16
> > > a=silenceSupp:off - - - -
> > > a=ptime:60
> > > a=sendrecv
> > >
> > >
> > >
> > >
> > > ACK is sent with 2.2.2.2 in ruri, instead of 4.4.4.4:
> > >
> > > Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
> > >
> > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> > >
> > > ACK sip:1111111111 at 2.2.2.2:5060 SIP/2.0
> > > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38>
> > > Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK5be8.eeb63911.2
> > > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK07b01eaf;rport=5060
> > > Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38>
> > > From: "2222222222" <sip:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > > Contact: <sip:2222222222 at 3.3.3.3>
> > > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > > CSeq: 102 ACK
> > > User-Agent: Asterisk PBX
> > > Max-Forwards: 69
> > > Content-Length: 0
> > >
> > >
> > >
> > >
> > > The ACK is not relayed on to 4.4.4.4, and so 4.4.4.4 just keeps
> > > retransmitting 200 replies. Later the BYE from 1.1.1.1 also has an
> > > incorrect ruri and so it is also not sent on to 4.4.4.4 as follows:
> > >
> > > Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
> > >
> > > User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
> > >
> > > BYE sip:1111111111 at 2.2.2.2:5060 SIP/2.0
> > > Record-Route: <sip:1.1.1.1;lr=on;ftag=as1a75bb38>
> > > Via: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK6be8.2fa52b26.0
> > > Via: SIP/2.0/UDP 3.3.3.3:5060;branch=z9hG4bK02874f97;rport=5060
> > > Route: <sip:2.2.2.2;lr=on;ftag=as1a75bb38>
> > > From: "2222222222" <sip:2222222222 at 3.3.3.3>;tag=as1a75bb38
> > > To: <sip:1111111111 at 2.2.2.2>;tag=as5bd164c9
> > > Call-ID: 7a98e4540899dde2053dc8a11cee1a04 at 3.3.3.3
> > > CSeq: 103 BYE
> > > User-Agent: Asterisk PBX
> > > Max-Forwards: 69
> > > Reason: Q.850 ;cause=16; text="Normal Clearing"
> > > X-Asterisk-HangupCauseCode: 16
> > > Content-Length: 0
> > >
> > > I believe we would have been able to fix this issue by using the
> > > dialoq module on both servers, but I do not know much about the dialog
> > > module yet, and unfortunately we have no control over one of the
> > > opensips servers. i also thought of trying to use the b2bua modules on
> > > just our server, but once again i will first need to learn more about
> > > those, but for now, we have managed to create a workaround whereby we
> > > rewrite the ruri for all acks, byes and cancels with the ip retrieved
> > > from the location table (using avp_db_query), which seems to be
> > > working, for now. I hope to find a more reliable fix.
> > >
> > > Thanks for the help.
> > > Bruce
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > > *From:* Bogdan-Andrei Iancu <bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>
> > <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>>
> > > *To:* OpenSIPS users mailling list <users at lists.opensips.org
> <mailto:users at lists.opensips.org>
> > <mailto:users at lists.opensips.org <mailto:users at lists.opensips.org>>>
> > > *Sent:* Tue, 18 May, 2010 17:54:01
> > > *Subject:* Re: [OpenSIPS-Users] In dialog requests misrouted
> > >
> > > Hi Bruce,
> > >
> > > The ACK for a 200OK is routed based on the route set - this the RR
> set +
> > > the contact of the other party. So, the ACK will have in RURI the
> > > contact of the other party (from 200 OK) and the RR set as Route hdrs.
> > >
> > > Regards,
> > > Bogdan
> > >
> > > Bruce Borrett wrote:
> > > > Hi
> > > >
> > > > We are trying to migrate from an SBC to Opensips 1.6. When we are
> > > > sending calls to another provider who are using Openser, they
> are not
> > > > taking the contact address from our 200 replies, instead they are
> > > > putting our Openser address in the RURI of all Acks, Byes and
> Cancels.
> > > > Am I right in saying that this is incorrect? Im not sure where they
> > > > are getting this address either, maybe from the To: field, or
> from the
> > > > record route header?
> > > >
> > > > Is there a way to match the message received to a transaction and
> > > > route the message to the contact in the original invite stored
> by TM?
> > > > Or perhaps some better way of solving this?
> > > >
> > > > Here are the messages:
> > > >
> > > > SIP/2.0 200 OK
> > > > Via: SIP/2.0/UDP
> > > >
> > >
> >
> xx.xxx.0.33;rport=5060;received=41.221.0.33;branch=z9hG4bKb9fc.f1cf4e03.0
> > > > Via: SIP/2.0/UDP xx.xxx.0.42:5060;branch=z9hG4bK3d3a5800;rport=5060
> > > > Record-Route: <sip:xx.xxx.1.13;lr=on;ftag=as5e3b3ce0>
> > > > Record-Route: <sip:xx.xxx.0.33;lr=on;ftag=as5e3b3ce0>
> > > > From: "xxxxxxx7239" <sip:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>
> > <mailto:xxxxxxx7239 at xx.xxx <mailto:xxxxxxx7239 at xx.xxx>>
> > > <mailto:xxxxxxx7239 at xx.xxx <mailto:xxxxxxx7239 at xx.xxx>
> > <mailto:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>>>.0.42>;tag=as5e3b3ce0
> > > > To: <sip:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>>
> > > <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> > <mailto:xxxxxx0114 at xx.xxx
> <mailto:xxxxxx0114 at xx.xxx>>>.1.13>;tag=as33b0f85f
> > > > Call-ID: 4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>
> > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>>
> > > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>
> > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>>>.0.42
> > > > CSeq: 102 INVITE
> > > > User-Agent: Asterisk PBX 1.6.0.9
> > > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> > > > Supported: replaces, timer
> > > > Contact: <sip:xxxxxxx0114 at xx.xxx <mailto:xxxxxxx0114 at xx.xxx>
> <mailto:xxxxxxx0114 at xx.xxx <mailto:xxxxxxx0114 at xx.xxx>>
> > <mailto:xxxxxxx0114 at xx.xxx <mailto:xxxxxxx0114 at xx.xxx>
> <mailto:xxxxxxx0114 at xx.xxx <mailto:xxxxxxx0114 at xx.xxx>>>.236.105>
> > > > Content-Type: application/sdp
> > > > Content-Length: 290
> > > >
> > > >
> > > > ACK sip:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>>
> > <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>>>.1.13:5060 SIP/2.0
> > > > Record-Route: <sip:xx.xxx.0.33;lr=on;ftag=as5e3b3ce0>
> > > > Via: SIP/2.0/UDP xx.xxx.0.33;branch=z9hG4bKb9fc.f1cf4e03.2
> > > > Via: SIP/2.0/UDP xx.xxx.0.42:5060;branch=z9hG4bK5e0350ba;rport=5060
> > > > Route: <sip:xx.xxx.1.13;lr=on;ftag=as5e3b3ce0>
> > > > From: "xxxxxxx7239" <sip:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>
> > <mailto:xxxxxxx7239 at xx.xxx <mailto:xxxxxxx7239 at xx.xxx>>
> > > <mailto:xxxxxxx7239 at xx.xxx <mailto:xxxxxxx7239 at xx.xxx>
> > <mailto:xxxxxxx7239 at xx.xxx
> <mailto:xxxxxxx7239 at xx.xxx>>>.0.42>;tag=as5e3b3ce0
> > > > To: <sip:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>>
> > > <mailto:xxxxxx0114 at xx.xxx <mailto:xxxxxx0114 at xx.xxx>
> > <mailto:xxxxxx0114 at xx.xxx
> <mailto:xxxxxx0114 at xx.xxx>>>.1.13>;tag=as33b0f85f
> > > > Contact: <sip:xxxxxx7239 at xx.xxx <mailto:xxxxxx7239 at xx.xxx>
> <mailto:xxxxxx7239 at xx.xxx <mailto:xxxxxx7239 at xx.xxx>>
> > <mailto:xxxxxx7239 at xx.xxx <mailto:xxxxxx7239 at xx.xxx>
> <mailto:xxxxxx7239 at xx.xxx <mailto:xxxxxx7239 at xx.xxx>>>.0.42>
> > > > Call-ID: 4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>
> > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>>
> > > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>
> > <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx
> <mailto:4b3419c86b29e5ce5a387a1b74f7effc at xx.xxx>>>.0.42
> > > > CSeq: 102 ACK
> > > > User-Agent: Asterisk PBX
> > > > Max-Forwards: 69
> > > > Content-Length: 0
> > > >
> > > > Thank you very much in advance..
> > > > Bruce
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
More information about the Users
mailing list