[SR-Users] Configuration Issue on Kamailio.
Daniel Grotti
dgrotti at sipwise.com
Wed Aug 10 17:34:46 CEST 2016
Hey,
are you using uac_replace_from() in your uplink leg (INVITEs) or are you
changing $fu directly ?
I think using uac_replace_from() and then using:
modparam("uac","restore_mode","auto")
should do the trick.
Daniel
rt Vienna, ATU64002206
On 08/10/2016 02:35 PM, Laura wrote:
>
> Ciao Daniel,
>
> here the data you request..
>
> Of course Kamailio2 use the color 9990 to send the call to CISCO Gw
> because its a required.. so CISCO send back the call with 9990 to
> Kamailio2 and it to Kamailio1 and after that to Customer..
>
> What I espect was that CISCO replied 9990 to Kamailio2, Kama2 replied
> 9053 to Kamailio1 and Kamailio1 replied 9999 to Customer1.
>
> Here the sip trace you request
>
> Kamailio1 --> Kamailio2
>
> U 2016/08/10 10:54:29.269917 2.2.2.2:5060 -> 3.3.3.3:5060
> INVITE sip:90534912345678 at 3.3.3.3 SIP/2.0.
> Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
> Via: SIP/2.0/UDP
> 2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
> Via: SIP/2.0/UDP
> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
> Max-Forwards: 69.
> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:90534912345678 at 3.3.3.3>.
> Contact: <sip:151512345678 at 1.1.1.1:5060>.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
> CSeq: 102 INVITE.
> Date: Wed, 10 Aug 2016 08:54:27 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE.
> Supported: replaces, timer.
> Content-Type: application/sdp.
> Content-Length: 308.
> User-Agent: Fagians VOIP 2.4.
> .
> v=0.
> o=root 869935480 869935480 IN IP4 1.1.1.1.
> s=Asterisk PBX 1.8.32.3.
> c=IN IP4 x.x.x.x.x.
> t=0 0.
> m=audio 36398 RTP/AVP 3 18 8 101.
> a=rtpmap:3 GSM/8000.
> a=rtpmap:18 G729/8000.
> a=fmtp:18 annexb=no.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:20.
> a=sendrecv.
>
>
> Kamailio2 --> CISCO.. LCR need to use 9990 to send call to CISCO..
>
> U 2016/08/10 10:54:29.301085 3.3.3.3:5060 -> 4.4.4.4:5060
> INVITE sip:99904912345678 at 4.4.4.4 SIP/2.0.
> Record-Route: <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>.
> Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
> Via: SIP/2.0/UDP
> 3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0.
> Via: SIP/2.0/UDP
> 2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
> Via: SIP/2.0/UDP
> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
> Max-Forwards: 68.
> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:99904912345678 at 4.4.4.4>.
> Contact: <sip:151512345678 at 1.1.1.1:5060>.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
> CSeq: 102 INVITE.
> Date: Wed, 10 Aug 2016 08:54:27 GMT.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE.
> Supported: replaces, timer.
> Content-Type: application/sdp.
> Content-Length: 309.
> User-Agent: Fagians VOIP 2.4.
> .
> v=0.
> o=root 869935480 869935480 IN IP4 1.1.1.1.
> s=Asterisk PBX 1.8.32.3.
> c=IN IP4 x.x.x.x..
> t=0 0.
> m=audio 58242 RTP/AVP 3 18 8 101.
> a=rtpmap:3 GSM/8000.
> a=rtpmap:18 G729/8000.
> a=fmtp:18 annexb=no.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:20.
> a=sendrecv.
>
>
> CISCO ---> Kamailio2 180/200 messages
>
> U 2016/08/10 10:54:29.361634 4.4.4.4:5060 -> 3.3.3.3:5060
> SIP/2.0 183 Session Progress.
> Via: SIP/2.0/UDP
> 3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
> 2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:99904912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
> Date: Wed, 10 Aug 2016 08:54:29 GMT.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
> Server: Cisco-SIPGateway/IOS-12.x.
> CSeq: 102 INVITE.
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
> SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
> Allow-Events: telephone-event.
> Contact: <sip:99904912345678 at 4.4.4.4:5060>.
> Record-Route:
> <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
> Content-Disposition: session;handling=required.
> Content-Type: application/sdp.
> Content-Length: 249.
> .
> v=0.
> o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
> s=SIP Call.
> c=IN IP4 x.x.x.x.
> t=0 0.
> m=audio 18838 RTP/AVP 3 101.
> c=IN IP4 83.147.65.249.
> a=rtpmap:3 GSM/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:10.
>
>
> U 2016/08/10 10:54:39.486505 4.4.4.4:5060 -> 3.3.3.3:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP
> 3.3.3.3:5060;branch=z9hG4bK5c29.c1bcba318da7a0a1ae45efbe2ee682c5.0,SIP/2.0/UDP
> 2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
> 185.24.22
> 0.141:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
> To: <sip:99904912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
> Date: Wed, 10 Aug 2016 08:54:29 GMT.
> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
> Server: Cisco-SIPGateway/IOS-12.x.
> CSeq: 102 INVITE.
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
> SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
> Supported: replaces.
> Allow-Events: telephone-event.
> Contact: <sip:99904912345678 at 4.4.4.4:5060>.
> Record-Route:
> <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
> Content-Type: application/sdp.
> Content-Length: 249.
> .
> v=0.
> o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
> s=SIP Call.
> c=IN IP4 x.x.x.x.
> t=0 0.
> m=audio 18838 RTP/AVP 3 101.
> c=IN IP4 83.147.65.249.
> a=rtpmap:3 GSM/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-16.
> a=ptime:10.
>
>
>
>
>
> Il 10/08/16 13:33, Daniel Grotti ha scritto:
>> Ciao Laura,
>> would be interesting to see the INVITE from kamailo2-->Cisco and see
>> the headers there, as well as the 180/200 from Cisco->kamailio2.
>> As Carsten said, probably Cisco is messing up From/To headers. The
>> 9990 color is not present in any of the INVITEs you provided, so
>> would be nice to understand where is come from.
>>
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> On 08/10/2016 12:27 PM, Laura wrote:
>>>
>>> Sorry for delay on my reply..
>>>
>>>
>>> I need to expalin better the situazione..
>>>
>>> Customer1 Ip : 1.1.1.1
>>> Kamailio1 ip : 2.2.2.2
>>> Kamailio2 ip: 3.3.3.3
>>> CiscoGW ip: 4.4.4.4
>>>
>>> Kamailio1 is on USA for example
>>> Kamailio2 is on Germany for example
>>>
>>> Customer1 --> Kamailio platform1 --> Kamailio Platform2 --> CISCO GW
>>> SIP/TDM for PTSN termination
>>>
>>> Customer1 is sending a call using his specific color 9999 to number
>>> 4912345678 and from sender 151512345678
>>>
>>> U 2016/08/10 09:54:29.250974 1.1.1.1:5060 ->2.2.2.2:5060
>>> INVITE sip:*9999*4912345678 at 2.2.2.2 SIP/2.0.
>>> Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK06b62a40;rport.
>>> Max-Forwards: 70.
>>> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
>>> To: <sip:*9999*4912345678 at 2.2.2.2>.
>>> Contact: <sip:151512345678 at 1.1.1.1:5060>.
>>> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
>>> CSeq: 102 INVITE.
>>> User-Agent: Asterisk PBX 1.8.32.3.
>>> Date: Wed, 10 Aug 2016 08:54:27 GMT.
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE.
>>> Supported: replaces, timer.
>>> Content-Type: application/sdp.
>>> Content-Length: 309.
>>> .
>>> v=0.
>>> o=root 869935480 869935480 IN IP4 1.1.1.1.
>>> s=Asterisk PBX 1.8.32.3.
>>> c=IN IP4 1.1.1.1.
>>> t=0 0.
>>> m=audio 15710 RTP/AVP 3 18 8 101.
>>> a=rtpmap:3 GSM/8000.
>>> a=rtpmap:18 G729/8000.
>>> a=fmtp:18 annexb=no.
>>> a=rtpmap:8 PCMA/8000.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>> a=ptime:20.
>>> a=sendrecv.
>>>
>>>
>>> After that the Kamailio1 platform is checking the LCR and route it
>>> with the color of its supplier (9053) to Kamailio2. Kamailio2 is a
>>> supplier of Kamailio1
>>>
>>> U 2016/08/10 09:54:29.2525272.2.2.2:5060 -> 3.3.3.3:5060
>>> INVITE sip:*9053*4912345678 at 3.3.3.3 SIP/2.0.
>>> Record-Route: <sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
>>> Via:
>>> SIP/2.0/UDP2.2.2.2:5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0.
>>> Via: SIP/2.0/UDP
>>> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
>>> Max-Forwards: 69.
>>> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
>>> To: <sip:*9053*4912345678 at 3.3.3.3>.
>>> Contact: <sip:151512345678 at 1.1.1.1:5060>.
>>> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
>>> CSeq: 102 INVITE.
>>> Date: Wed, 10 Aug 2016 08:54:27 GMT.
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
>>> INFO, PUBLISH, MESSAGE.
>>> Supported: replaces, timer.
>>> Content-Type: application/sdp.
>>> Content-Length: 308.
>>> User-Agent: Fagians VOIP 2.4.
>>> .
>>> v=0.
>>> o=root 869935480 869935480 IN IP4 1.1.1.1.
>>> s=Asterisk PBX 1.8.32.3.
>>> c=IN IP4 51.254.158.37.
>>> t=0 0.
>>> m=audio 36398 RTP/AVP 3 18 8 101.
>>> a=rtpmap:3 GSM/8000.
>>> a=rtpmap:18 G729/8000.
>>> a=fmtp:18 annexb=no.
>>> a=rtpmap:8 PCMA/8000.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>> a=ptime:20.
>>> a=sendrecv.
>>>
>>> Kamailio2 use its LCR and send the call to Cisco Gateway that use
>>> its color and send the call on termination to TDM Switch.
>>> Naturally Kamailio2 receive the replies from Cisco and send it back
>>> to Kamailio1.
>>>
>>>
>>> Here is the Session progress Kamailio1 receive from Kamailio2 that
>>> it got from Cisco.
>>>
>>> U 2016/08/10 09:54:29.375669 3.3.3.3:5060 ->2.2.2.2:5060
>>> SIP/2.0 183 Session Progress.
>>> Via:
>>> SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
>>> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
>>> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
>>> To: <sip:*9990*4912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
>>> Date: Wed, 10 Aug 2016 08:54:29 GMT.
>>> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
>>> CSeq: 102 INVITE.
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
>>> Allow-Events: telephone-event.
>>> Contact: <sip:99904912345678 at 4.4.4.4:5060>.
>>> Record-Route:
>>> <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
>>> Content-Disposition: session;handling=required.
>>> Content-Type: application/sdp.
>>> Content-Length: 251.
>>> User-Agent: Fagians VOIP 2.4.
>>> .
>>> v=0.
>>> o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
>>> s=SIP Call.
>>> c=IN IP4 83.147.127.247.
>>> t=0 0.
>>> m=audio 58240 RTP/AVP 3 101.
>>> c=IN IP4 83.147.127.247.
>>> a=rtpmap:3 GSM/8000.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>> a=ptime:10.
>>>
>>> To: <sip:99904912345678 at 4.4.4.4>;tag=5F0E7DF4-172F. ->> 9990 is the
>>> color that use CISCO to terminate the call on TDM Switch
>>>
>>> After some other messages Kamailio1 receive the 200 OK and send it
>>> back to Customer1
>>>
>>>
>>> Kamailio2 --> Kamailio1
>>>
>>> U 2016/08/10 09:54:39.507885 3.3.3.3:5060 ->2.2.2.2:5060
>>> SIP/2.0 200 OK.
>>> Via:
>>> SIP/2.0/UDP2.2.2.2:5060;rport=5060;branch=z9hG4bK5c29.8288fcc6bf463fb8f82d3609b0c4893c.0,SIP/2.0/UDP
>>> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
>>> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
>>> To: <sip:*9990*4912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
>>> Date: Wed, 10 Aug 2016 08:54:29 GMT.
>>> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
>>> CSeq: 102 INVITE.
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
>>> Supported: replaces.
>>> Allow-Events: telephone-event.
>>> Contact: <sip:99904912345678 at 4.4.4.4:5060>.
>>> Record-Route:
>>> <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
>>> Content-Type: application/sdp.
>>> Content-Length: 251.
>>> User-Agent: Fagians VOIP 2.4.
>>> .
>>> v=0.
>>> o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
>>> s=SIP Call.
>>> c=IN IP4 83.147.127.247.
>>> t=0 0.
>>> m=audio 58240 RTP/AVP 3 101.
>>> c=IN IP4 83.147.127.247.
>>> a=rtpmap:3 GSM/8000.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>> a=ptime:10.
>>>
>>> Kamailio1 --> Customer1
>>>
>>> U 2016/08/10 09:54:39.5120362.2.2.2:5060 -> 1.1.1.1:5060
>>> SIP/2.0 200 OK.
>>> Via: SIP/2.0/UDP
>>> 1.1.1.1:5060;received=1.1.1.1;branch=z9hG4bK06b62a40;rport=5060.
>>> From: "151512345678" <sip:151512345678 at 1.1.1.1>;tag=as7f0dee78.
>>> To: <sip:*9990*4912345678 at 4.4.4.4>;tag=5F0E7DF4-172F.
>>> Date: Wed, 10 Aug 2016 08:54:29 GMT.
>>> Call-ID: 406a307158b1016b3a9936cd476b3c89 at 1.1.1.1:5060.
>>> CSeq: 102 INVITE.
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER.
>>> Supported: replaces.
>>> Allow-Events: telephone-event.
>>> Contact: <sip:99904912345678 at 4.4.4.4:5060>.
>>> Record-Route:
>>> <sip:3.3.3.3;lr;did=4f3.9ce2;nat=yes>,<sip:2.2.2.2;lr;did=4f3.8501;nat=yes>.
>>> Content-Type: application/sdp.
>>> Content-Length: 249.
>>> User-Agent: Fagians VOIP 2.4.
>>> .
>>> v=0.
>>> o=CiscoSystemsSIP-GW-UserAgent 9803 1571 IN IP4 4.4.4.4.
>>> s=SIP Call.
>>> c=IN IP4 51.254.158.37.
>>> t=0 0.
>>> m=audio 56710 RTP/AVP 3 101.
>>> c=IN IP4 51.254.158.37.
>>> a=rtpmap:3 GSM/8000.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>> a=ptime:10.
>>>
>>> So the real question is how to fix that on Kamailio ?..
>>>
>>> We need to use always the original messages and data into sdp header
>>> when we talk with other parts..
>>>
>>> On our configuration we permit to transit that modified messages..
>>> like you can see Customer1 is getting back datas modified from CiscoGW.
>>>
>>>
>>> Hope that will be more clear to you all..
>>>
>>>
>>> Anyone can suggest us a way ?
>>>
>>>
>>> Regards
>>>
>>> Laura
>>>
>>>
>>> Il 01/08/16 14:25, Carsten Bock ha scritto:
>>>> Hi,
>>>>
>>>> do you use "uac_replace_from" or "uac_replace_to" in your logic?
>>>>
>>>> If not, it seems to me, that your supplier is messing around with
>>>> the SIP-Replies.
>>>>
>>>> Thanks,
>>>> Carsten
>>>>
>>>> 2016-08-01 14:10 GMT+02:00 Laura <red_dra at plugit.net
>>>> <mailto:red_dra at plugit.net>>:
>>>>
>>>> Dear list,
>>>>
>>>> i'm asking here a question about Kamailio config.
>>>>
>>>> We are testing a wide area configuration of Kamailio over separates
>>>> countries and we are still facing with an issue.
>>>>
>>>> We configured Kamailio 4.3.5 with dialog support over the TM
>>>> modules and
>>>> we use LCR module for menage ours LCRs rule set profiles.
>>>>
>>>> For some technicals reasons we use tech prefix for our customer
>>>> so for
>>>> exaples customer1 send traffic to us with 1111 prefix,
>>>> customer2 send
>>>> traffic to us with 2222 and something similar..
>>>>
>>>> Our supplier, of course, are using tech prefix too so for
>>>> examples if i
>>>> want to send the call to supplier1 i need to use tech prefix
>>>> 1789 or
>>>> something similar..
>>>>
>>>> The point is..
>>>>
>>>>
>>>> When customer1 is sending an invite to us.. it send us
>>>> something like
>>>> (Bangladesh mobile 8801xxx)
>>>>
>>>> INVITE sip:11118801xxxxxxx at aaa.bbb.ccc.ddd
>>>>
>>>> Our Kamailio will reply with the Trying and then it goes to LCR
>>>> module
>>>> and match our supplier1 so it make a new invite like this
>>>>
>>>> INVITE sip:17898801xxxxxx at supplier.ip
>>>>
>>>> The problem come when supplier1 reply to us and we replies back to
>>>> customer1..
>>>>
>>>> Customer1 view the From: field with the 17898801xxxxxx
>>>> numbers.. and
>>>> some of our customers don't like it.
>>>>
>>>> We don't use anymore the topoh module becuase we found some
>>>> troubles
>>>> using it.. so..
>>>>
>>>> Is there a way that we can use for fix this situation ?
>>>>
>>>>
>>>> Best regards.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>>>> mailing list
>>>> sr-users at lists.sip-router.org
>>>> <mailto:sr-users at lists.sip-router.org>
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Carsten Bock
>>>> CEO (Geschäftsführer)
>>>>
>>>> ng-voice GmbH
>>>> Millerntorplatz 1
>>>> 20359 Hamburg / Germany
>>>>
>>>> http://www.ng-voice.com
>>>> mailto:carsten at ng-voice.com <mailto:carsten at ng-voice.com>
>>>>
>>>> Office +49 40 5247593-40
>>>> Fax +49 40 5247593-99
>>>>
>>>> Sitz der Gesellschaft: Hamburg
>>>> Registergericht: Amtsgericht Hamburg, HRB 120189
>>>> Geschäftsführer: Carsten Bock
>>>> Ust-ID: DE279344284
>>>>
>>>> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
>>>> http://www.ng-voice.com/imprint/
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160810/c1d3c939/attachment.html>
More information about the sr-users
mailing list