[SR-Users] Configuration Issue on Kamailio.
Laura
red_dra at plugit.net
Wed Aug 10 12:27:53 CEST 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160810/20a17cf4/attachment.html>
More information about the sr-users
mailing list