[SR-Users] Configuration Issue on Kamailio.
Laura
red_dra at plugit.net
Tue Aug 30 09:30:37 CEST 2016
Dear Daniel and list,
i tried to use and test the restore_mode --> auto and this is what will
fix my issue.
Now ,the problem i have is that on my kamailio.cfg i need to use a replace..
Inside the branch_route[MANAGE_BRANCH] i use an uac_replace_to("$ru");
Why this ?.. because i use tech prefix for all my customers... for
examples 1234+E164number (without + ofcourse).. So with that replace i
write the color inside my CDR over the TO field .. this is useful for
the billing engine.
With that command i receive on my log.. and of course the replace is not
working..
Aug 30 06:25:08 vm-itz-01 /usr/sbin/kamailio[6441]: ERROR: uac
[replace.c:761]: restore_uris_reply(): failed to find/parse FROM hdr
Aug 30 06:25:13 vm-itz-01 /usr/sbin/kamailio[6418]: ERROR: uac
[replace.c:273]: replace_uri(): decline FROM replacing in sequential
request in auto mode (has TO tag)
How can i resolve that ? any idea guys ?
Laura
Il 10/08/16 17:34, Daniel Grotti ha scritto:
>
> 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
>
>
>
> _______________________________________________
> 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/20160830/569ac3b1/attachment.html>
More information about the sr-users
mailing list