Hi Daniel
Semms now we have ankther problem...
b_rr weites in db correctly.
But when ack is sending from A side it try to send to B side to cantact ip,
ignoring record-route headers...
I will try to debug this.
If you have any idea I can test it.
Thank you.
--
WBR
Sergey Basov
28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" <
sergey.v.basov(a)gmail.com> написал:
Hi Daniel.
Seems all is ok now.
I applyed your patch and add my additional debug string.
Now result is:
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
[tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](84)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
[tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](349)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
[tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - b_rr:
[<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,
<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](556)
Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos
[tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: [](0) -
b_rr: [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,
<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](556)
- s_rr: [](0)
Seems this issue is solved.
Can you apply this patch to 5.0 branch?
Then may be Pete Kelly will install nightly build of the 5.0.1 and
confirm that issu is solved.
I does not have such count of sbc for test )
Thank you Daniel.
--
Best regards,
Sergey Basov e-mail: sergey.v.basov(a)gmail.com
2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
many thanks Sergey for troubleshooting, it saved a lot of time!
Hopefully I caught the issue. Can you test with latest master branch and
let me know if works?
Cheers,
Daniel
On 28.04.17 14:57, Sergey Basov wrote:
> Some more debug
>
> after adding debug output after each iteration I got:
>
> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](84)
> Apr 28 15:51:51 csbc-uat
/usr/sbin/kamailio[13743]: DEBUG: topos
> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.
sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.
zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn
TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.
TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](348)
> Apr 28 15:51:51 csbc-uat
/usr/sbin/kamailio[13743]: DEBUG: topos
> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-
4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
>
> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) -
> b_rr: [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB-
4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](554)
> - s_rr: [](0)
>
> So size are computed correctly, but part of record-routes
> disappears.... And we can see correct size of the record but only last
> part of the record-routes
>
> Hope it helps
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.basov(a)gmail.com
>
>
> 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.basov(a)gmail.com>om>:
>> One more detail
>>
>> When debug=3 I see in logs (look at size of record and it contents)
>>
>> Apr 28 14:16:44 csbc-uat /usr/sbin/kamailio[13287]: DEBUG: topos
>> [tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr: [](0) -
>> b_rr: [](0) - s_rr:
>> [<sip:10.56.42.33;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;
did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3
Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR
xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:
5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;
did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3
Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR
xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>](453)
>>
>> 453 - is a real size of shown header
>>
>> s_rr parses normal, but b_rr
>>
>> Apr 28 14:16:48 csbc-uat /usr/sbin/kamailio[13273]: DEBUG: topos
>> [tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr: [](0) -
>> b_rr: [<sip:10.56.42.33:5090;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;
did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAQAAAAOAAAAAAAAAAAAAAAA>](553)
>> - s_rr: [](0)
>>
>> 553 - seems a real correct size of the recordroute header and it
>> differs from size with \0 at the end
>>
>>
>> --
>> Best regards,
>> Sergey Basov e-mail: sergey.v.basov(a)gmail.com
>>
>>
>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <sergey.v.basov(a)gmail.com>om>:
>>> Hi All.
>>>
>>> I just try to pass call throught 3 kamailio.
>>> I got result like yours
>>>
>>> If you need testers for patch - I am ready )
>>>
>>> --
>>> Best regards,
>>> Sergey Basov e-mail: sergey.v.basov(a)gmail.com
>>>
>>>
>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla <
miconda(a)gmail.com>gt;:
>>>> There seems to be an issue saving
the record-route list for b-side in
>>>> topos_d table -- first two are saved but then there are only 0
characters
>>>> instead of the rest of record
routes:
>>>>
>>>> '<sip:192.168.252.75;r2=on;lr=on;ftag=A1;did=072.87c;rtpi=1;
nat=no;rtpi=1>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'
>>>>
>>>> I will have to dig a bit into the code.
>>>>
>>>> Cheers, Daniel
>>>>
>>>>
>>>> On 27.04.17 14:30, Pete Kelly wrote:
>>>>
>>>> Yes no problem. I wanted to come but the life schedule would not
allow it
>>>> this time.
>>>>
>>>>
>>>> On 27 April 2017 at 13:11, Daniel-Constantin Mierla <
miconda(a)gmail.com>
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> time, I need more time :-) ... with Kamailio World Conference
around the
>>>>> corner, I am caught in a lot
of admin tasks...
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 27.04.17 13:11, Pete Kelly wrote:
>>>>>
>>>>> Hi Daniel
>>>>>
>>>>> Is there anything else you need on this?
>>>>>
>>>>> On 26 April 2017 at 15:06, Pete Kelly <pkelly(a)gmail.com>
wrote:
>>>>>> Hi Daniel
>>>>>>
>>>>>> It's CSeq 1, fromtag A1
>>>>>>
>>>>>> DB attached
>>>>>>
>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla <
miconda(a)gmail.com>
>>>>>> wrote:
>>>>>>> Can you paste here the from tag or cseq for the dialog you
are
referring
>>>>>>> to? Because the
number of frames are not matching my pcap viewer.
>>>>>>>
>>>>>>> Send also the db dump, they should reveal if something is
broken
there.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>> On 26.04.17 14:46, Pete Kelly wrote:
>>>>>>>
>>>>>>> Ah I see why it is confusing
>>>>>>>
>>>>>>> This setup maintains a Call-ID through an SBC downstream, so
the
>>>>>>> INVITE's you see have the same Call-ID but they have a
different
>>>>>>> fromtag/cseq, Wireshark shows them all as one call which is
annoying when
>>>>>>> looking at the
viewer!
>>>>>>>
>>>>>>> If you check the first call only between 252.70 and 252.75
you
will see
>>>>>>> INVITE (frame 4),
200OK (frame 16) with lots of RR headers.
>>>>>>>
>>>>>>> The ACK generated by topos (frame 21) only contains 1 Route
header, it
>>>>>>> should contain more
so the request can hop through the proxy
chain as shown
>>>>>>> in frame 16.
>>>>>>>
>>>>>>> I see the example from Sergey is working, but there is only 1
RR
header
>>>>>>> in this example - as
you can see from my example the topos module
uses the
>>>>>>> first RR header but
ignores the other 5.
>>>>>>>
>>>>>>> I have the DB dump and logfiles from this call too if
useful.
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>>>
>>>>>>> On 26 April 2017 at 12:41, Daniel-Constantin Mierla <
miconda(a)gmail.com>
>>>>>>> wrote:
>>>>>>>> As I could notice upon a quick look, there seems to be
two calls
-- two
>>>>>>>> INVITE requests
having same call id but different cseq. Can you
confirm
>>>>>>>> this is the case?
Because the capture doesn't seem to have all
the
>>>>>>>> incoming/outgoing
messages, some are missing.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>> On 26.04.17 12:59, Sergey Basov wrote:
>>>>>>>>> You give to us very hard callflow...
>>>>>>>>>
>>>>>>>>> Without any pauses between responces..
>>>>>>>>>
>>>>>>>>> Some requests go through 127.0.0.1... But responces
from
127.0.0.1
>>>>>>>>> not present.
>>>>>>>>>
>>>>>>>>> There are peers from which invites not present in
dump. I can
not see
>>>>>>>>> ful path of
the initial Invite, but there is responses.
>>>>>>>>>
>>>>>>>>> I will send dump in next email directly.
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>> Sergey Basov e-mail:
sergey.v.basov(a)gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly
<pkelly(a)gmail.com>om>:
>>>>>>>>>> Attached is the pcap from latest nightly.
>>>>>>>>>>
>>>>>>>>>> As you can see (frame 21) the ACK is incorrect, I
believe it
should
>>>>>>>>>> specify
>>>>>>>>>> all the hops from the 200OK (frame 16) so that
the hop by hop
ACK
>>>>>>>>>> can be
>>>>>>>>>> routed via the proxy chain.
>>>>>>>>>>
>>>>>>>>>> topoh module works fine.
>>>>>>>>>>
>>>>>>>>>> Pete
>>>>>>>>>>
>>>>>>>>>> On 26 April 2017 at 05:18, Sergey Basov <
sergey.v.basov(a)gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> I dont know how nightly builds are done.
>>>>>>>>>>>
>>>>>>>>>>> Just try with latest 5.0.1 nightly and send
new dump.
>>>>>>>>>>>
>>>>>>>>>>> As I understud topos module done to remove
record-route
headers to
>>>>>>>>>>> hide
>>>>>>>>>>> topology... Am I wright, Daniel?
>>>>>>>>>>>
>>>>>>>>>>> And try to disable topos module and enable
topoh module. Will
it
>>>>>>>>>>> all
work
>>>>>>>>>>> as you expecrs?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> WBR
>>>>>>>>>>> Sergey Basov
>>>>>>>>>>>
>>>>>>>>>>> 25 апр. 2017 г. 11:31 PM пользователь
"Pete Kelly"
>>>>>>>>>>> <pkelly(a)gmail.com>
>>>>>>>>>>> написал:
>>>>>>>>>>>
>>>>>>>>>>>> I have tried with 5.0.1 from today (25th
April).
>>>>>>>>>>>>
>>>>>>>>>>>> Are you saying build for 26th will have
some fixes?
>>>>>>>>>>>>
>>>>>>>>>>>> On 25 April 2017 at 18:59, Sergey Basov
<
sergey.v.basov(a)gmail.com>
>>>>>>>>>>>>
wrote:
>>>>>>>>>>>>> Actualy latest fixes to 180/183/200,
ACK and memory leak
was
>>>>>>>>>>>>> pushed to
>>>>>>>>>>>>> 5.0 and master branch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, please try with latest 5.0.1
nightly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> WBR
>>>>>>>>>>>>> Sergey Basov
>>>>>>>>>>>>>
>>>>>>>>>>>>> 25 апр. 2017 г. 8:55 PM пользователь
"Pete Kelly"
>>>>>>>>>>>>> <pkelly(a)gmail.com>
>>>>>>>>>>>>> написал:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Call is with sipp but first goes
through another SBC to
clean up
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> SIP (in case of problems with
sipp via headers etc).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The traces I've done are
actually with 4.4.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Will they be OK or would you
prefer 5.0.1? The problem is
>>>>>>>>>>>>>> exactly the
>>>>>>>>>>>>>> same on both.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 25 April 2017 at 16:25, Sergey
Basov
>>>>>>>>>>>>>> <sergey.v.basov(a)gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Hi.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you send dump of the call
with kamailio 5.0.1 nightly?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And does you make call using
sipp?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> WBR
>>>>>>>>>>>>>>> Sergey Basov
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 25 апр. 2017 г. 5:57 PM
пользователь "Pete Kelly"
>>>>>>>>>>>>>>> <pkelly(a)gmail.com>
>>>>>>>>>>>>>>> написал:
>>>>>>>>>>>>>>>> Looks like from last
night:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
5.0.1+0~20170425013247.36+trusty
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 25 April 2017 at
15:42, Daniel-Constantin Mierla
>>>>>>>>>>>>>>>> <miconda(a)gmail.com>
wrote:
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to be sure, it is
5.0.1 build from last night or quite
>>>>>>>>>>>>>>>>> recent? There
>>>>>>>>>>>>>>>>> were some fixes in
the past days to topos module.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Daniel
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 25.04.17 15:59,
Pete Kelly wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Daniel
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry for the delayed
response to this, the ACK is for a
>>>>>>>>>>>>>>>>> 200OK yes
>>>>>>>>>>>>>>>>> and the problem still
persists in latest 4.4 and the
5.0.1
>>>>>>>>>>>>>>>>> nightly build.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have all DB
entries/kam logs/pcap files.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you check the
attached pcap, 192.168.70.70 and
>>>>>>>>>>>>>>>>> 192.168.252.70 are
>>>>>>>>>>>>>>>>> the same instance of
Kamailio, it is being used to
bridge the
>>>>>>>>>>>>>>>>> 2 networks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Frame 34 shows the
200OK with lots of Record-Route etc,
and
>>>>>>>>>>>>>>>>> frame 35
>>>>>>>>>>>>>>>>> shows topos in
action.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> However the ACK that
is relayed in Frame 38 seems to be
>>>>>>>>>>>>>>>>> missing all
>>>>>>>>>>>>>>>>> the Route information
that was supplied in the 200OK,
this
>>>>>>>>>>>>>>>>> causes the ACK to
>>>>>>>>>>>>>>>>> be relayed directly
to the Contact, breaking the proxy
chain.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Pete
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 22 February 2017
at 18:31, Daniel-Constantin Mierla
>>>>>>>>>>>>>>>>>
<miconda(a)gmail.com> wrote:
>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> is the ACK for
200ok? Or an ack for a negative
response?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Can you get a
pcap for such situation with all messages
>>>>>>>>>>>>>>>>>> related to
>>>>>>>>>>>>>>>>>> the call?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Daniel
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 22/02/2017
17:20, Pete Kelly wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am using the
topos module when bridging 2 networks
with
>>>>>>>>>>>>>>>>>> Kamailio.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The INVITE/200OK
part of the transaction is working
fine
>>>>>>>>>>>>>>>>>> (i.e. the
>>>>>>>>>>>>>>>>>> Contact on both
sides matches correctly the
corresponding
>>>>>>>>>>>>>>>>>> network).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> However when the
ACK is sent into Kamailio, instead of
>>>>>>>>>>>>>>>>>> realising
>>>>>>>>>>>>>>>>>> the next hop is
myself and skipping it, Kamailio is
sending
>>>>>>>>>>>>>>>>>> the ACK directly
>>>>>>>>>>>>>>>>>> to itself as a
packet, causing the call setup to break.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Does anyone have
any advice for this situation?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>>>> SIP Express
Router (SER) and Kamailio (OpenSER) -
sr-users
>>>>>>>>>>>>>>>>>> mailing
>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>>
sr-users(a)lists.sip-router.org
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
http://lists.sip-router.org/ cgi-bin/mailman/listinfo/sr-users
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Daniel-Constantin
Mierla
>>>>>>>>>>>>>>>>>>
www.twitter.com/miconda --
www.linkedin.com/in/miconda
>>>>>>>>>>>>>>>>>> Kamailio Advanced
Training - Mar 6-8 (Europe) and Mar
20-22
>>>>>>>>>>>>>>>>>> (USA) -
>>>>>>>>>>>>>>>>>>
www.asipto.com
>>>>>>>>>>>>>>>>>> Kamailio World
Conference - May 8-10, 2017 -
>>>>>>>>>>>>>>>>>>
www.kamailioworld.com
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Daniel-Constantin
Mierla
>>>>>>>>>>>>>>>>>
www.twitter.com/miconda --
www.linkedin.com/in/miconda
>>>>>>>>>>>>>>>>> Kamailio Advanced
Training - May 22-24 (USA) -
www.asipto.com
>>>>>>>>>>>>>>>>> Kamailio World
Conference - May 8-10, 2017 -
>>>>>>>>>>>>>>>>>
www.kamailioworld.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>>>>> Kamailio (SER) - Users
Mailing List
>>>>>>>>>>>>>>>>
sr-users(a)lists.kamailio.org
>>>>>>>>>>>>>>>>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr- users
>>>>>>>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Daniel-Constantin Mierla
>>>>>>>>
www.twitter.com/miconda --
www.linkedin.com/in/miconda
>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
www.asipto.com
>>>>>>>> Kamailio World Conference - May 8-10, 2017 -
www.kamailioworld.com
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Daniel-Constantin Mierla
>>>>>>>
www.twitter.com/miconda --
www.linkedin.com/in/miconda
>>>>>>> Kamailio Advanced Training - May 22-24 (USA) -
www.asipto.com
>>>>>>> Kamailio World Conference - May 8-10, 2017 -
www.kamailioworld.com
>>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierla
>>>>
www.twitter.com/miconda --
www.linkedin.com/in/miconda
>>>> Kamailio Advanced Training - May 22-24 (USA) -
www.asipto.com
>>>> Kamailio World Conference - May 8-10, 2017 -
www.kamailioworld.com
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla
>>>
www.twitter.com/miconda --
www.linkedin.com/in/miconda
>>> Kamailio Advanced Training - May 22-24 (USA) -
www.asipto.com
>>> Kamailio World Conference - May 8-10, 2017 -
www.kamailioworld.com
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users(a)lists.kamailio.org
>>>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
--
Daniel-Constantin Mierla
www.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) -
www.asipto.com
Kamailio World Conference - May 8-10, 2017 -
www.kamailioworld.com