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