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@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@1.1.1.1>;tag=as7f0dee78. >> To: <sip:90534912345678@3.3.3.3>. >> Contact: <sip:151512345678@1.1.1.1:5060>. >> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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@1.1.1.1>;tag=as7f0dee78. >> To: <sip:99904912345678@4.4.4.4>. >> Contact: <sip:151512345678@1.1.1.1:5060>. >> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@1.1.1.1>;tag=as7f0dee78. >> To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. >> Date: Wed, 10 Aug 2016 08:54:29 GMT. >> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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@1.1.1.1>;tag=as7f0dee78. >> To: <sip:99904912345678@4.4.4.4>;tag=5F0E7DF4-172F. >> Date: Wed, 10 Aug 2016 08:54:29 GMT. >> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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@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@1.1.1.1>;tag=as7f0dee78. >>>> To: <sip:*9999*4912345678@2.2.2.2>. >>>> Contact: <sip:151512345678@1.1.1.1:5060>. >>>> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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@1.1.1.1>;tag=as7f0dee78. >>>> To: <sip:*9053*4912345678@3.3.3.3>. >>>> Contact: <sip:151512345678@1.1.1.1:5060>. >>>> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@1.1.1.1>;tag=as7f0dee78. >>>> To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F. >>>> Date: Wed, 10 Aug 2016 08:54:29 GMT. >>>> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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@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@1.1.1.1>;tag=as7f0dee78. >>>> To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F. >>>> Date: Wed, 10 Aug 2016 08:54:29 GMT. >>>> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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@1.1.1.1>;tag=as7f0dee78. >>>> To: <sip:*9990*4912345678@4.4.4.4>;tag=5F0E7DF4-172F. >>>> Date: Wed, 10 Aug 2016 08:54:29 GMT. >>>> Call-ID: 406a307158b1016b3a9936cd476b3c89@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@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_...@plugit.net >>>>> <mailto:red_...@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:11118801xxxx...@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:17898801xxx...@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@lists.sip-router.org >>>>> <mailto:sr-users@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:cars...@ng-voice.com <mailto:cars...@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@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@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@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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users