[Spce-user] call drop immediately

Tue Sep 17 09:49:46 EDT 2013

All,

A little update on this interesting rabbit-hole case - the following was
the result of a CSI:Style intercontinental investigation with the help of
Daniel Grotti from sip:wise.

The issue Theo was experiencing was surely caused by MTU fragmentation. The
MTU fragmentation was caused by the messages being oversize, but the
messages were really oversize because still carrying a few SPCE internal
headers, not removed due to a previous customization of the sems config in
fact disabling is header filtering completely - just to allow Refer
messages to pass.
Quite a backlog story for this case! Now the solution to both old and new
issues here is clearly to correct SEMS crippled configuration by defining a
"header_filter" mode (whitelist)  and extending the "header_list" parameter
list with the whole Refer family of headers (or whatever else needed within
reason) and let the B2BUA remove all the remaining internal-only headers
from the peering sessions. This should bring the situation back to normal
as of packet size without impacting any additional functionality.

Theo, let us know if this resolved your case,

Best,

Lorenzo Mangani

HOMER DEV TEAM
QXIP - Capture Engineering

On Tue, Sep 17, 2013 at 8:13 AM, Theo <axessofficetheo at gmail.com> wrote:

> Hi
>
> I have no solution for my problem. Part of this is kept in private with
> Andreas because of the info in the log files. The issue is bizarre as far
> as I can judge this. We have 3 providers. In this case each of those
> transit calls from a number of carriers which go through to this one
> customer. All works fine. EXCEPT for the transit from carrier 1, through
> provider A, who also transit for other carriers, through the same trunk
> without issues. The same carrier also sends calls through another provider
> without issues. However, calls from carrier 1 through provider A cut after
> 5 seconds, about 80% of the time.
>
> ngrep-sip complains about "SIP/2.0 400 missing CSeq header field'" - but
> The carrier, nor the provider, nor me see anything missing. Ngrep-sip from
> the point of the invite. I have decided not to worry about the sensitive
> details at this point as I have to get this resolved urgently. I see
> nothing missing in the invite. What I do see is, the second last line, that
> doesn't make sense. That should be a full domain, but where does that come
> from???
>
> Is this an issue on our box? if so, why only with this particular upstream
> carrier through this particular provider. If not, how do I get the other
> party to fix it?
>
> Thanks for any input
>
>
>
> U 2013/09/17 08:07:20.226723 127.0.0.1:5060 -> 127.0.0.1:5062
> INVITE sip:127.0.0.1:5080 SIP/2.0'
> Record-Route:
> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;ngcplb=yes;socket=udp:
> 196.41.123.113:5060>'
> Record-Route:
> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;ngcplb=yes;socket=udp:
> 196.41.123.113:5060>'
> Route: <sip:ngcp-lb at 127.0.0.1:5062
> ;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;did=3f2.531;mpd=ii;ice_caller=strip;ice_callee=strip;rtpprx=yes;vsf=V3V3Z0VMeGFUOU1OZkthYTonJjQKayohWlMrByZQLi8IKhkEHQdJAThbDQY->'
> Via: SIP/2.0/UDP
> 127.0.0.1;branch=z9hG4bK7239.6843b44cb370e058f995c996d166891a.0'
> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bK7239.908cd0b7.0'
> Via: SIP/2.0/UDP 92.240.0.12:5083;branch=z9hG4bK685c.a3419e67.0'
> From:  <sip:27214482133 at 92.240.1.12
> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODM'
> To:  <sip:27110254990 at 196.41.123.113
> ;user=phone>;tag=62DF6E4A-5237F1970000DBD6-69F4A700'
> Call-ID: hs4_bhs6_bSDg3ivb01-4893e0c5872c548cdb6488e80b76e5db-ctvvfv3'
> CSeq: 2 INVITE'
> Accept:
> application/sdp,application/isup,multipart/mixed,application/vnd.siemens.key-event,application/vnd.siemens.surpass,application/dtmf-relay'
> Contact: <sip:27214482133 at 92.240.0.12:5083;transport=udp>'
> MIME-Version: 1.0'
> Supported: timer,100rel'
> Max-Forwards: 63'
> Session-Expires: 1800;refresher=uac'
> Allow: ACK, INFO, BYE, CANCEL, INVITE, OPTIONS, NOTIFY, PRACK, UPDATE'
> Content-Type: application/sdp'
> Content-Length: 234'
> P-NGCP-Src-Ip: 92.240.1.12'
> P-NGCP-Src-Port: 5060'
> P-NGCP-Src-Proto: udp'
> P-NGCP-Src-Af: 4'
> P-Sock-Info: udp:196.41.123.113:5060'
> '
> v=0'
> o=- 2445083187 307757073 IN IP4 92.240.0.61'
> s=-'
> c=IN IP4 92.240.0.61'
> t=0 0'
> m=audio 52438 RTP/AVP 18 101'
> a=rtpmap:18 G729/8000'
> a=fmtp:18 annexb=no'
> a=rtpmap:101 telephone-event/8000'
> a=fmtp:101 0-15'
> a=sendrecv'
> a=ptime:60'
>
> #
> U 2013/09/17 08:07:20.226832 127.0.0.1:5062 -> 127.0.0.1:5060
> SIP/2.0 100 Trying'
> Via: SIP/2.0/UDP
> 127.0.0.1;branch=z9hG4bK7239.6843b44cb370e058f995c996d166891a.0'
> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bK7239.908cd0b7.0'
> Via: SIP/2.0/UDP 92.240.0.12:5083;branch=z9hG4bK685c.a3419e67.0'
> From:  <sip:27214482133 at 92.240.1.12
> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODM'
> To:  <sip:27110254990 at 196.41.123.113
> ;user=phone>;tag=62DF6E4A-5237F1970000DBD6-69F4A700'
> Call-ID: hs4_bhs6_bSDg3ivb01-4893e0c5872c548cdb6488e80b76e5db-ctvvfv3'
> CSeq: 2 INVITE'
> P-Out-Socket: udp:196.41.123.113:5060'
> Server: Sipwise NGCP Proxy 2.X'
> Content-Length: 0'
> '
>
> #
> U 2013/09/17 08:07:20.227036 196.41.123.113:5060 -> 92.240.1.12:5060
> SIP/2.0 100 Trying'
> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bK7239.908cd0b7.0'
> Via: SIP/2.0/UDP 92.240.0.12:5083;branch=z9hG4bK685c.a3419e67.0'
> From:  <sip:27214482133 at 92.240.1.12
> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODM'
> To:  <sip:27110254990 at 196.41.123.113
> ;user=phone>;tag=62DF6E4A-5237F1970000DBD6-69F4A700'
> Call-ID: hs4_bhs6_bSDg3ivb01-4893e0c5872c548cdb6488e80b76e5db-ctvvfv3'
> CSeq: 2 INVITE'
> Server: Sipwise NGCP Proxy 2.X'
> Content-Length: 0'
> '
>
> #
> U 2013/09/17 08:07:20.227510 127.0.0.1:5062 -> 127.0.0.1:5060
> SIP/2.0 400 missing CSeq header field'
> Record-Route: <sip:127.0.0.1:5062
> ;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;rtpprx=yes;ice_callee=strip;ice_caller=strip;mpd=ii>'
> Record-Route:
> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;ngcplb=yes;socket=udp:
> 196.41.123.113:5060>'
> Record-Route:
> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;ngcplb=yes;socket=udp:
> 196.41.123.113:5060>'
> Via: SIP/2.0/UDP
> 127.0.0.1;branch=z9hG4bK7239.6843b44cb370e058f995c996d166891a.0'
> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bK7239.908cd0b7.0'
> Via: SIP/2.0/UDP 92.240.0.12:5083;branch=z9hG4bK685c.a3419e67.0'
> From: <sip:27214482133 at maodi.sw1.a]''''S'''
> Content-Length: 0'
> '
>
>
>
>
>
> On Fri, Sep 13, 2013 at 4:28 PM, Theo <axessofficetheo at gmail.com> wrote:
>
>> I starting to think this is a problem on my box. However, it ONLY does it
>> with this client and ONLY from one upstream provider who route calls to us
>> from various carriers. It only happens with calls from one carrier. From
>> the sems log I have made the line below in BOLD. that should read @
>> maodi.sw1.africanaxess.co.za. It does on the first invite. Where does
>> this change into the mangled part??? And why only on calls through one
>> provider from one carrier specifically.
>>
>>
>>
>> Sep 13 16:01:18 sipwise sems[2424]: [#7ffb69f4a700] [parse_sip_uri,
>> parse_uri.cpp:332] DEBUG: Converted URI port (5080) to int (5080)
>> Sep 13 16:01:18 sipwise sems[2424]: [#7ffb69f4a700] [parse_headers,
>> parse_header.cpp:391] DEBUG: Illegal CR or LF in header name
>> Sep 13 16:01:18 sipwise sems[2424]: [#7ffb69f4a700] [received_msg,
>> trans_layer.cpp:1093] DEBUG: parse_sip_msg returned -5
>> Sep 13 16:01:18 sipwise sems[2424]: [#7ffb69f4a700] [received_msg,
>> trans_layer.cpp:1099] DEBUG: parsing error: missing CSeq header field
>> Sep 13 16:01:18 sipwise sems[2424]: [#7ffb69f4a700] [received_msg,
>> trans_layer.cpp:1101] DEBUG: Message was: "INVITE sip:127.0.0.1:5080SIP/2.0#015#012Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;rtpprx=yes;ice_callee=strip;ice_caller=strip;mpd=ii>#015#012Record-Route:
>> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Record-Route:
>> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKdf2f.16949b1e10816e7aeabf87354bed5bba.0#015#012Via:
>> SIP/2.0/UDP
>> 127.0.0.1;branch=z9hG4bKdf2f.7bc23c3315f2e5d9705a33335a27931e.0#015#012*Via:
>> SIP/2.0/UDP
>> 92.240.1.13;rport=5060;branch=z9hG4bKdf2f.584bf716.0#015#012Via:
>> SIP/2.0/UDP 92.240.0.12:5081;branch=z9hG4bKbb6b.792a931.0#015#012From:
>>  <sip:27214482133 at maodi.sw1.a]#007#032#006#023S#021#020#012#035#026.co.za
>> *>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODE#015#012To:  <
>> sip:27110254990 at 196.41.123.113;user=phone>;tag=580524BE-52331AAE00079EFB-69F4A700#015#012Call-ID:
>> hs4_bhs6_bSDdbf7b01-fb9203bf7ff514193081e8be537bc659-ctvvfv3#015#012CSeq: 2
>> INVITE#015#012Accept:
>> application/sdp,application/isup,multipart/mixed,application/vnd.siemens.key-event,application/vnd.siemens.surpass,application/dtmf-relay#015#012Contact:
>> <sip:27214482133 at 92.240.0.12:5081;transport=udp>#015#012MIME-Version:
>> 1.0#015#012Supported: timer,100rel#015#012Max-Forwards:
>> 62#015#012Session-Expires: 1800;refresher=uac#015#012Allow: ACK, INFO, BYE,
>> CANCEL, INVITE, OPTIONS, NOTIFY, PRACK, UPDATE#015#012Content-Type:
>> application/sdp#015#012Content-Length: 254#015#012#015#012v=0#015#012o=-
>> 4048552998 309592175 IN IP4 196.41.123.113#015#012s=-#015#012c=IN IP4
>> 196.41.123.113#015#012t=0 0#015#012m=audio 31636 RTP/AVP 18
>> 101#015#012a=rtpmap:18 G729/8000#015#012a=fmtp:18
>> annexb=no#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
>> 0-15#015#012a=sendrecv#015#012a=ptime:60#015#012a=rtcp:31637#015#012"
>> Sep 13 16:01:18 sipwise sems[2424]: [#7ffb69f4a700] [send,
>> transport.cpp:98] DEBUG: send  msg#012--++--#012SIP/2.0 400 missing CSeq
>> header field#015#012Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;rtpprx=yes;ice_callee=strip;ice_caller=strip;mpd=ii>#015#012Record-Route:
>> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Record-Route:
>> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKdf2f.16949b1e10816e7aeabf87354bed5bba.0#015#012Via:
>> SIP/2.0/UDP
>> 127.0.0.1;branch=z9hG4bKdf2f.7bc23c3315f2e5d9705a33335a27931e.0#015#012Via:
>> SIP/2.0/UDP
>> 92.240.1.13;rport=5060;branch=z9hG4bKdf2f.584bf716.0#015#012Via:
>> SIP/2.0/UDP 92.240.0.12:5081;branch=z9hG4bKbb6b.792a931.0#015#012From:
>> <sip:27214482133 at maodi.sw1.a]#007#032#006#023S#021#020#015#012Content-Length:
>> 0#015#012#015#012--++--
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [run,
>> udp_trsp.cpp:213] DEBUG: vv M [|] u recvd msg via UDP
>> vv#012--++--#012INVITE sip:127.0.0.1:5080 SIP/2.0#015#012Record-Route:
>> <sip:127.0.0.1:5062;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;rtpprx=yes;ice_callee=strip;ice_caller=strip;mpd=ii>#015#012Record-Route:
>> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Record-Route:
>> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKdf2f.16949b1e10816e7aeabf87354bed5bba.0#015#012Via:
>> SIP/2.0/UDP
>> 127.0.0.1;branch=z9hG4bKdf2f.7bc23c3315f2e5d9705a33335a27931e.0#015#012Via:
>> SIP/2.0/UDP
>> 92.240.1.13;rport=5060;branch=z9hG4bKdf2f.584bf716.0#015#012Via:
>> SIP/2.0/UDP 92.240.0.12:5081;branch=z9hG4bKbb6b.792a931.0#015#012From:
>>  <sip:27214482133 at maodi.sw1.a]#007#032#006#023S#021#020#012#035#026.co.za>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODE#015#012To:
>>  <sip:27110254990 at 196.41.123.113;user=phone>;tag=580524BE-52331AAE00079EFB-69F4A700#015#012Call-ID:
>> hs4_bhs6_bSDdbf7b01-fb9203bf7ff514193081e8be537bc659-ctvvfv3#015#012CSeq: 2
>> INVITE#015#012Accept:
>> application/sdp,application/isup,multipart/mixed,application/vnd.siemens.key-event,application/vnd.siemens.surpass,application/dtmf-relay#015#012Contact:
>> <sip:27214482133 at 92.240.0.12:5081;transport=udp>#015#012MIME-Version:
>> 1.0#015#012Supported: timer,100rel#015#012Max-Forwards:
>> 62#015#012Session-Expires: 1800;refresher=uac#015#012Allow: ACK, INFO, BYE,
>> CANCEL, INVITE, OPTIONS, NOTIFY, PRACK, UPDATE#015#012Content-Type:
>> application/sdp#015#012Content-Length: 254#015#012#015#012v=0#015#012o=-
>> 4048552998 309592175 IN IP4 196.41.123.113#015#012s=-#015#012c=IN IP4
>> 196.41.123.113#015#012t=0 0#015#012m=audio 31636 RTP/AVP 18
>> 101#015#012a=rtpmap:18 G729/8000#015#012a=fmtp:18
>> annexb=no#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
>> 0-15#015#012a=sendrecv#015#012a=ptime:60#015#012a=rtcp:31637#015#012--++--
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [parse_sip_uri,
>> parse_uri.cpp:332] DEBUG: Converted URI port (5080) to int (5080)
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [parse_headers,
>> parse_header.cpp:391] DEBUG: Illegal CR or LF in header name
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [received_msg,
>> trans_layer.cpp:1093] DEBUG: parse_sip_msg returned -5
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [received_msg,
>> trans_layer.cpp:1099] DEBUG: parsing error: missing CSeq header field
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [received_msg,
>> trans_layer.cpp:1101] DEBUG: Message was: "INVITE sip:127.0.0.1:5080SIP/2.0#015#012Record-Route: <sip:127.0.0.1:5062;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;rtpprx=yes;ice_callee=strip;ice_caller=strip;mpd=ii>#015#012Record-Route:
>> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Record-Route:
>> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODE;ngcplb=yes;socket=udp:
>> 196.41.123.113:5060>#015#012Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKdf2f.16949b1e10816e7aeabf87354bed5bba.0#015#012Via:
>> SIP/2.0/UDP
>> 127.0.0.1;branch=z9hG4bKdf2f.7bc23c3315f2e5d9705a33335a27931e.0#015#012Via:
>> SIP/2.0/UDP
>> 92.240.1.13;rport=5060;branch=z9hG4bKdf2f.584bf716.0#015#012Via:
>> SIP/2.0/UDP 92.240.0.12:5081;branch=z9hG4bKbb6b.792a931.0#015#012From:
>>  <sip:27214482133 at maodi.sw1.a]#007#032#006#023S#021#020#012#035#026.co.za>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODE#015#012To:
>>  <sip:27110254990 at 196.41.123.113;user=phone>;tag=580524BE-52331AAE00079EFB-69F4A700#015#012Call-ID:
>> hs4_bhs6_bSDdbf7b01-fb9203bf7ff514193081e8be537bc659-ctvvfv3#015#012CSeq: 2
>> INVITE#015#012Accept:
>> application/sdp,application/isup,multipart/mixed,application/vnd.siemens.key-event,application/vnd.siemens.surpass,application/dtmf-relay#015#012Contact:
>> <sip:27214482133 at 92.240.0.12:5081;transport=udp>#015#012MIME-Version:
>> 1.0#015#012Supported: timer,100rel#015#012Max-Forwards:
>> 62#015#012Session-Expires: 1800;refresher=uac#015#012Allow: ACK, INFO, BYE,
>> CANCEL, INVITE, OPTIONS, NOTIFY, PRACK, UPDATE#015#012Content-Type:
>> application/sdp#015#012Content-Length: 254#015#012#015#012v=0#015#012o=-
>> 4048552998 309592175 IN IP4 196.41.123.113#015#012s=-#015#012c=IN IP4
>> 196.41.123.113#015#012t=0 0#015#012m=audio 31636 RTP/AVP 18
>> 101#015#012a=rtpmap:18 G729/8000#015#012a=fmtp:18
>> annexb=no#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
>> 0-15#015#012a=sendrecv#015#012a=ptime:60#015#012a=rtcp:31637#015#012"
>> Sep 13 16:01:19 sipwise sems[2424]: [#7ffb69e49700] [send,
>> transport.cpp:98] DEBUG: send  msg#012--++--#012SIP/2
>>
>>
>> On Fri, Sep 13, 2013 at 1:00 PM, Theo <axessofficetheo at gmail.com> wrote:
>>
>>> Hi Andreas,
>>>
>>> Apologies for keeping this off list - once I've figured out the problem
>>> and if worth it for other people I will post the correct solution here. I
>>> have in the meantime figured out WHY the call is dropping, and you were
>>> spot on with the missing CSeq header field. This is a snippet of a dropped
>>> call and clearly we are sending back the SIP/2.0 400 missing CSeq header
>>> field'. What I just cannot figure out is, WHAT is missing exactly. The
>>> upstream guys are saying "nothing is missing".
>>>
>>> I do see From: <sip:27214482133 at maodi.sw1.a]''''S''' which is worrying.
>>> this should be maodi.sw1.africanaxess.co.za which is the domain
>>> associated with this customer.
>>>
>>> U 2013/09/13 11:58:07.520589 92.240.1.12:5060 -> 196.41.123.113:5060
>>>
>>> INVITE sip:ngcp-lb at 196.41.123.113;ngcpct=c2lwOjEyNy4wLjAuMTo1MDgw
>>> SIP/2.0'
>>>
>>> Route: <sip:ngcp-lb at 196.41.123.113
>>> ;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
>>> 196.41.123.113:5060>, <sip:ngcp-lb at 127.0.0.1
>>> ;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
>>> 196.41.123.113:5060>, <sip:ngcp-lb at 127.0.0.1:5062
>>> ;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;did=63b.e412;mpd=ii;ice_caller=strip;ice_callee=strip;rtpprx=yes;vsf=V3V3Z0VMeGFUOU1OZkthYTonJjQKayohWlMrByZQLi8IKhkEHQdJAThbDQY->'
>>>
>>> Via: SIP/2.0/UDP 92.240.1.12;branch=z9hG4bKa6b5.0d018653.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.0.13:5081;branch=z9hG4bKf784.ce567e76.0'
>>>
>>> From:  <sip:27214482133 at 92.240.1.12
>>> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
>>>
>>> To:  <sip:27110254990 at 196.41.123.113
>>> ;user=phone>;tag=3D4A701D-5232E1AF0004AA9D-69F4A700'
>>>
>>> Call-ID: hs4_bhs6_bSDtqpbc01-50b38cb585afe88c67431dd52af8b9dd-ctvvfv3'
>>>
>>> CSeq: 2 INVITE'
>>>
>>> Accept:
>>> application/sdp,application/isup,multipart/mixed,application/vnd.siemens.key-event,application/vnd.siemens.surpass,application/dtmf-relay'
>>>
>>> Contact: <sip:27214482133 at 92.240.0.13:5081;transport=udp>'
>>>
>>> MIME-Version: 1.0'
>>>
>>> Supported: timer,100rel'
>>>
>>> Max-Forwards: 64'
>>>
>>> Session-Expires: 1800;refresher=uac'
>>>
>>> Allow: ACK, INFO, BYE, CANCEL, INVITE, OPTIONS, NOTIFY, PRACK, UPDATE'
>>>
>>> Content-Type: application/sdp'
>>>
>>> Content-Length: 235'
>>>
>>> '
>>>
>>> v=0'
>>>
>>> o=- 3522956930 307888210 IN IP4 92.240.0.62'
>>>
>>> s=-'
>>>
>>> c=IN IP4 92.240.0.62'
>>>
>>> t=0 0'
>>>
>>> m=audio 51314 RTP/AVP 18 101'
>>>
>>> a=rtpmap:18 G729/8000'
>>>
>>> a=fmtp:18 ann
>>>
>>> #
>>>
>>> U 2013/09/13 11:58:07.520787 127.0.0.1:5060 -> 127.0.0.1:5062
>>>
>>> INVITE sip:127.0.0.1:5080 SIP/2.0'
>>>
>>> Record-Route:
>>> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
>>> 196.41.123.113:5060>'
>>>
>>> Record-Route:
>>> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
>>> 196.41.123.113:5060>'
>>>
>>> Route: <sip:ngcp-lb at 127.0.0.1:5062
>>> ;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;did=63b.e412;mpd=ii;ice_caller=strip;ice_callee=strip;rtpprx=yes;vsf=V3V3Z0VMeGFUOU1OZkthYTonJjQKayohWlMrByZQLi8IKhkEHQdJAThbDQY->'
>>>
>>> Via: SIP/2.0/UDP
>>> 127.0.0.1;branch=z9hG4bKa6b5.242fbc2bf219d6f43d00babcdc3c29f3.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bKa6b5.0d018653.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.0.13:5081;branch=z9hG4bKf784.ce567e76.0'
>>>
>>> From:  <sip:27214482133 at 92.240.1.12
>>> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
>>>
>>> To:  <sip:27110254990 at 196.41.123.113
>>> ;user=phone>;tag=3D4A701D-5232E1AF0004AA9D-69F4A700'
>>>
>>> Call-ID: hs4_bhs6_bSDtqpbc01-50b38cb585afe88c67431dd52af8b9dd-ctvvfv3'
>>>
>>> CSeq: 2 INVITE'
>>>
>>> Accept:
>>> application/sdp,application/isup,multipart/mixed,application/vnd.siemens.key-event,application/vnd.siemens.surpass,application/dtmf-relay'
>>>
>>> Contact: <sip:27214482133 at 92.240.0.13:5081;transport=udp>'
>>>
>>> MIME-Version: 1.0'
>>>
>>> Supported: timer,100rel'
>>>
>>> Max-Forwards: 63'
>>>
>>> Session-Expires: 1800;refresher=uac'
>>>
>>> Allow: ACK, INFO, BYE, CANCEL, INVITE, OPTIONS, NOTIFY, PRACK, UPDATE'
>>>
>>> Content-Type: application/sdp'
>>>
>>> Content-Length: 235'
>>>
>>> P-NGCP-Src-Ip: 92.240.1.12'
>>>
>>> P-NGCP-Src-Port: 5060'
>>>
>>> P-NGCP-Src-Proto: udp'
>>>
>>> P-NGCP-Src-Af: 4'
>>>
>>> P-Sock-Info: udp:196.41.123.113:5060'
>>>
>>> '
>>>
>>> v=0'
>>>
>>> o=- 3522956930 307888210 IN IP4 92.240.0.62'
>>>
>>> s=-'
>>>
>>> c=IN IP4 92.240.0.62'
>>>
>>> t=0 0'
>>>
>>> m=audio 51314 RTP/AVP 18 101'
>>>
>>> a=rtpmap:18 G729/8000'
>>>
>>> a=fmtp:18 annexb=no'
>>>
>>> a=rtpmap:101 telephone-event/8000'
>>>
>>> a=fmtp:101 0-15'
>>>
>>> a=sendrecv'
>>>
>>> a=pmft: T38'
>>>
>>>
>>> #
>>>
>>> U 2013/09/13 11:58:07.520906 127.0.0.1:5062 -> 127.0.0.1:5060
>>>
>>> SIP/2.0 100 Trying'
>>>
>>> Via: SIP/2.0/UDP
>>> 127.0.0.1;branch=z9hG4bKa6b5.242fbc2bf219d6f43d00babcdc3c29f3.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bKa6b5.0d018653.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.0.13:5081;branch=z9hG4bKf784.ce567e76.0'
>>>
>>> From:  <sip:27214482133 at 92.240.1.12
>>> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
>>>
>>> To:  <sip:27110254990 at 196.41.123.113
>>> ;user=phone>;tag=3D4A701D-5232E1AF0004AA9D-69F4A700'
>>>
>>> Call-ID: hs4_bhs6_bSDtqpbc01-50b38cb585afe88c67431dd52af8b9dd-ctvvfv3'
>>>
>>> CSeq: 2 INVITE'
>>>
>>> P-Out-Socket: udp:196.41.123.113:5060'
>>>
>>> Server: Sipwise NGCP Proxy 2.X'
>>>
>>> Content-Length: 0'
>>>
>>> '
>>>
>>>
>>> #
>>>
>>> U 2013/09/13 11:58:07.521217 196.41.123.113:5060 -> 92.240.1.12:5060
>>>
>>> SIP/2.0 100 Trying'
>>>
>>> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bKa6b5.0d018653.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.0.13:5081;branch=z9hG4bKf784.ce567e76.0'
>>>
>>> From:  <sip:27214482133 at 92.240.1.12
>>> ;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
>>>
>>> To:  <sip:27110254990 at 196.41.123.113
>>> ;user=phone>;tag=3D4A701D-5232E1AF0004AA9D-69F4A700'
>>>
>>> Call-ID: hs4_bhs6_bSDtqpbc01-50b38cb585afe88c67431dd52af8b9dd-ctvvfv3'
>>>
>>> CSeq: 2 INVITE'
>>>
>>> Server: Sipwise NGCP Proxy 2.X'
>>>
>>> Content-Length: 0'
>>>
>>> '
>>>
>>>
>>> #
>>>
>>> U 2013/09/13 11:58:07.521712 127.0.0.1:5062 -> 127.0.0.1:5060
>>>
>>> SIP/2.0 400 missing CSeq header field'
>>>
>>> Record-Route: <sip:127.0.0.1:5062
>>> ;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;rtpprx=yes;ice_callee=strip;ice_caller=strip;mpd=ii>'
>>>
>>> Record-Route:
>>> <sip:127.0.0.1;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
>>> 196.41.123.113:5060>'
>>>
>>> Record-Route:
>>> <sip:196.41.123.113;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
>>> 196.41.123.113:5060>'
>>>
>>> Via: SIP/2.0/UDP
>>> 127.0.0.1;branch=z9hG4bKa6b5.242fbc2bf219d6f43d00babcdc3c29f3.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.1.12;rport=5060;branch=z9hG4bKa6b5.0d018653.0'
>>>
>>> Via: SIP/2.0/UDP 92.240.0.13:5081;branch=z9hG4bKf784.ce567e76.0'
>>>
>>> From: <sip:27214482133 at maodi.sw1.a]''''S'''
>>>
>>> Content-Length: 0'
>>>
>>> '
>>>
>>>
>>> On Tue, Sep 10, 2013 at 2:43 PM, Theo <axessofficetheo at gmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> Any idea why the tcpdump get mangled when saving to a file?
>>>>
>>>> ?E???#@??){q)?3???i?SIP/2.0 200 OK
>>>>
>>>> for example? when watching it in real-time it looks fine
>>>>
>>>>
>>>> On Tue, Sep 10, 2013 at 1:33 PM, Theo <axessofficetheo at gmail.com>wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Homer is on my list of things :-) Lorenzo has been telling how great
>>>>> it is.
>>>>>
>>>>> I didn't see that in the log, but mainly because of ignorance. For
>>>>> example, I have no idea what a CSeq header field is, but straight after
>>>>> this mail i will consult my friend google on that one. I will run the
>>>>> tcpdump and wait for more examples.
>>>>>
>>>>> And speed up my homer box I guess.
>>>>>
>>>>>
>>>>> On Tue, Sep 10, 2013 at 1:03 PM, Andreas Granig <agranig at sipwise.com>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Did you recognize the "SIP/2.0 400 missing CSeq header field" in the
>>>>>> sems log? Seems like there is quite a lot broken with the clients involved
>>>>>> here.
>>>>>>
>>>>>> I think the only way to pin it down exactly is to do something like
>>>>>>
>>>>>>         tcpdump -i any -s 0 -w /path/to/trace.pcap host
>>>>>> xxx.xxx.xxx.xxx
>>>>>>
>>>>>> where xxx.xxx.xxx.xxx is this asterisk box to get a clear overview of
>>>>>> what's going on. Another (better) way to troubleshoot this stuff post
>>>>>> mortem is to install Homer, so you're able to analyze call flows which
>>>>>> happened in the past.
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>> On 09/10/2013 12:54 PM, Andreas Granig wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 09/10/2013 12:42 PM, Theo wrote:
>>>>>>>
>>>>>>>> Sep 10 11:16:06 sipwise /usr/sbin/kamailio[1971]: INFO: <script>:
>>>>>>>> New
>>>>>>>> request - M=BYE R=sip:ngcp-lb at 196.41.123.113
>>>>>>>> <mailto:sip%3Angcp-lb at 196.41.**123.113<sip%253Angcp-lb at 196.41.123.113>>
>>>>>>>> F=sip:27219763939 at 92.240.1.12
>>>>>>>> <mailto:sip%3A27219763939 at 92.**240.1.12<sip%253A27219763939 at 92.240.1.12>>
>>>>>>>> T=sip:27214235154 at 196.41.123.**113<sip%3A27214235154 at 196.41.123.113>
>>>>>>>> <mailto:sip%3A27214235154 at 196.**41.123.113<sip%253A27214235154 at 196.41.123.113>>
>>>>>>>> IP=udp:92.240.1.12:5060
>>>>>>>> <http://92.240.1.12:5060>
>>>>>>>> ID=hs4_bhs6_bSDh3kvb01-**12c39d503671664b04bbf109d85784**78-ctvvfv3
>>>>>>>>
>>>>>>>> In this case, which party tore the call down?
>>>>>>>>
>>>>>>>
>>>>>>> In this case, the IP 92.240.1.12 sent the BYE (look for IP=xxxx) in
>>>>>>> the
>>>>>>> log line.
>>>>>>>
>>>>>>> I think you're actually running into an end-to-end media negotiation
>>>>>>> issue. Caller sends SDP offer, the callee sends the answer, and the
>>>>>>> caller is not happy with it and sends the BYE. Just a wild guess,
>>>>>>> need
>>>>>>> to check the logs in detail.
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130917/da7239ef/attachment-0001.html>