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:99994912345678@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:99994912345678@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: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/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: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 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: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.
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: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.
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: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.
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_dra@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@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@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
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@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