[SR-Users] Kamailio with Blox SBC (opensips based) - Wrong CSeq

[Daniel-Constantin Mierla]

Kamailio itself doesn't alter CSeq method, unless you do something in
the configuration file.

Looking at the traces, the broken CSeq comes like that to Kamailio --
first part here indicates that 192.168.0.1:5060 is Kamailio, and next
shows the packet sent by .0.33 to .0.1 (kamailio):

U 2015/06/22 17:08:52.730652 192.168.0.1:5060 -> 192.168.0.3:6060
SIP/2.0 100 trying -- your call is important to us

...

U 2015/06/22 17:08:52.735438 192.168.0.33:5060 -> 192.168.0.1:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.0.1;branch=z9hG4bK3504.df39a8277f82eb6121d9c32883c70ead.0;received=192.168.0.1;rport=5060
Via: SIP/2.0/UDP 192.168.0.3:6060;branch=z9hG4bK0a9b.47eca853.0
Max-Forwards: 70
To: <sip:1001 at 192.168.1.3:8000>;tag=krTfxNsCTuX
From: "PhonerLite" <sip:1000 at 192.168.1.3:8000>;tag=3066030555
Call-ID: SBCbFhRRnpBd3ZEUWNUVF8gQWVZREoKMXhvWVMSVCUxUzIVWSpCCUJ4cEdWZV1NQ0tFYQ
CSeq: 1
Contact: <sip:1001 at 192.168.0.33:5060>
Record-Route: <sip:192.168.0.1;lr=on>
User-Agent: MAYAH 4.9.12.0-2.1.0.45
Content-Length: 0


So, if I got it right that .0.1 is kamailio, then the problem is not in
kamailio at all.

Cheers,
Daniel

On 22/06/15 17:41, kai.ohnacker at cbc.de wrote:
> In the txt file you can find the ngrep traffic.
>
> Cheers, 
> Kai
>
> ---------------------------------------------------------
>
> Perhaps you have an ngrep of the sip traffic?
>
> --fred
>
> -----Ursprüngliche Nachricht-----
> Von: sr-users [mailto:sr-users-bounces at lists.sip-router.org] Im Auftrag von Fred Posner
> Gesendet: Montag, 22. Juni 2015 16:39
> An: sr-users at lists.sip-router.org
> Betreff: Re: [SR-Users] Kamailio with Blox SBC (opensips based) - Wrong CSeq
>
>
> On 06/22/2015 10:30 AM, kai.ohnacker at cbc.de wrote:
>> Hello,
>>
>> my setup is a kamailio server as registrar and Blox as SBC.
>>
>> Blox is a freeware GUI with Opensips as framework.
>>
>> Kamailio is located in the private network and Blox operates with 2 NICs
>> (private and public)
>>
>> Now the following problem:
>>
>> If I make a call from public (phonerlite) to private (mayah), the
>> connection don't reach the "framed" state and is "broken" after 30 sec.
>>
>> After evaluating the log files, I found that the CSeq from Kamailio is
>> wrong.
>>
>> The invite comes from
>>
>> CSeq: 9 INVITE
>>
>> The reply is with CSeq 1
>>
>> SIP/2.0 180 Ringing
>> Via: SIP/2.0/UDP 192.168.0.3:6060;branch=z9hG4bK38ae.cf317344.0
>> Max-Forwards: 70
>> To: <sip:1001 at 192.168.1.3:8000>;tag=qTKGZvr0ItW
>> From: "PhonerLite" <sip:1000 at 192.168.1.3:8000>;tag=1005520878
>> Call-ID:
>> SBCbFgsQn5HcHpEUxJUVF8gQWVZREt6QwJvWVJkXCdAUzdkXl41CUJ4cEdWZV1NQ0tFYQ
>> CSeq: 1
>> Contact: <sip:1001 at 192.168.0.33:5060>
>> Record-Route: <sip:192.168.0.1;lr=on>
>> User-Agent: MAYAH 4.9.12.0-2.1.0.45
>> Content-Length: 0
>>
>> And here the information from the opensips log files:
>>
>>                 Jun 22 14:30:32 localhost blox-0-9-6-beta[1975]:
>> ERROR:core:parse_cseq: no method found
>>
>> Jun 22 14:30:32 localhost blox-0-9-6-beta[1975]: ERROR:core:parse_cseq:
>> bad cseq
>>
>> Jun 22 14:30:32 localhost blox-0-9-6-beta[1975]:
>> ERROR:core:get_hdr_field: bad cseq
>>
>> Perhaps someone of you knows this failure or can tell me how to solve
>> this problem?
>>
>> Cheers,
>>
>> Kai
>>
>>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150622/613fc97a/attachment.html>