[Spce-user] call drop immediately
Theo
axessofficetheo at gmail.com
Wed Sep 25 04:32:28 EDT 2013
Ok this is finally resolved, with the kind help of Daniel and Lorenzo. For
future reference, below the problem. The solution was to change
modparam("uac","restore_mode","auto") to modparam("uac","restore_mode",
"none")
I am not entirely sure if there are any adverse effects to doing this. If
anybody can think of any, please let us know. I have not picked up any
problems after changing this.
The reason for changing it was:
The problem is the following, and it's related to the kamailio UAC module.
This module works like this:
"It adds an alternative implementation to the AUTO mode for
uac_replace_from/to() by using the dialog module to store the URIs.
Here is the excerpt from the README file explaining this:
If you set restore_mode to AUTO, the URI will be modified automatically
in all subsequent requests and replies in that dialog.
There are two ways in which the AUTO mode can be achieved.
1) One uses the rr module and appends to the Record-Route header a
parameter containing some strings from which the original and new
URI can be computed. The problem with this mode is that it relies on the
fact the parties will send the Route exactly as it was received. In
case there is a change, the resulting URIs will not be correct.
2) The other one uses the dialog module to store the original and new
URI.
If you already use dialog module in your configuration, this is the
advisable mode. All you need to do to use this is to call dlg_manage()
before calling uac_replace_to(). It works by storing the URIs as dialog
variables and registering callbacks in dialog module for in dialog
requests."
In our case, NGCP use the FIRST one, so we stored a string in the RR
header in order to restore the original From for the sebsequent request
(RE-INVITE).
Which parameter we use is set in the following line:
modparam("uac", "rr_from_store_param", "vsf")
And if you look at a capture of a call, you can see the paramenter in
the 200 OK from NGCP to the caller:
<sip:127.0.0.1:5062;lr=on;ftag=KmsqOjkyLjI0MC4wLjEyOjUwODM;
did=2ec.3bc;mpd=ii;ice_caller=strip;ice_callee=strip;rtpprx=yes;vsf=
V3V3Z0VMeGFUOU1OZkthYTonJjQKayohWlMrByZQLi8IKhkEHQdJAThbDQY->
Now, the problem seems that your caller sent a Re-INVITE with a
truncated Route header, so NGCP was not able to look up properly the
original From.
>From UAC module:
"The problem with this mode is that it relies on the fact the parties
will send the Route exactly as it was received. In case there is a
change, the resulting URIs will not be correct."
I think this it the problem in your case.
See also:
http://lists.sip-router.org/pipermail/sr-users/2012-July/073837.html
On Wed, Sep 18, 2013 at 11:00 AM, Daniel Grotti <dgrotti at sipwise.com> wrote:
> Theo,
>
> do you have another pcap to send to us ?
>
> Daniel
>
>
>
> On 09/17/2013 11:07 PM, Theo wrote:
> > Hi
> >
> > Those headers are now gone and it would appear the size is comfortably
> > below 1500 now.
> >
> >
> > On Tue, Sep 17, 2013 at 9:22 PM, Lorenzo Mangani
> > <lorenzo.mangani at gmail.com <mailto:lorenzo.mangani at gmail.com>> wrote:
> >
> > Hi Theo,
> >
> > Do the packets still reach the peer with the extra headers or were
> > they removed as intended?
> >
> >
> > Best,
> >
> > Lorenzo Mangani
> >
> > HOMER DEV TEAM
> > QXIP - Capture Engineering
> >
> >
> >
> > On Tue, Sep 17, 2013 at 9:11 PM, Theo <axessofficetheo at gmail.com
> > <mailto:axessofficetheo at gmail.com>> wrote:
> >
> > Hi
> >
> > CSI has nothing on us! I have corrected the sems config - the
> > whitelist is back. Applied. I still have the same problem
> though...
> >
> > Any more thoughts?
> >
> >
> > On Tue, Sep 17, 2013 at 3:49 PM, Lorenzo Mangani
> > <lorenzo.mangani at gmail.com <mailto:lorenzo.mangani at gmail.com>>
> > wrote:
> >
> > 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
> > <mailto: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
> > <http://127.0.0.1:5060> -> 127.0.0.1:5062
> > <http://127.0.0.1:5062>
> > INVITE sip:127.0.0.1:5080 <http://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
> > <http://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
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODM'
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://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
> > <http://127.0.0.1:5062> -> 127.0.0.1:5060
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODM'
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://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
> > <http://196.41.123.113:5060> -> 92.240.1.12:5060
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODM'
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://127.0.0.1:5062> -> 127.0.0.1:5060
> > <http://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
> > <http://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
> > <http://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
> > <mailto: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
> > <http://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:5080
> > <http://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
> > <http://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
> > <http://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
> > <http://026.co.za
> >*>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODE#015#012To:
> > <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://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
> > <http://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
> > <http://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
> > <http://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
> > <http://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
> > <http://026.co.za
> >>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODE#015#012To:
> > <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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:5080
> > <http://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
> > <http://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
> > <http://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
> > <http://026.co.za
> >>;tag=KmsqOjkyLjI0MC4wLjEyOjUwODE#015#012To:
> > <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <mailto: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
> > <http://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
> > <http://92.240.1.12:5060> -> 196.41.123.113:5060
> > <http://196.41.123.113:5060>
> >
> > INVITE sip:ngcp-lb at 196.41.123.113
> > <mailto:sip%3Angcp-lb at 196.41.123.113
> >;ngcpct=c2lwOjEyNy4wLjAuMTo1MDgw
> > SIP/2.0'
> >
> > Route: <sip:ngcp-lb at 196.41.123.113
> > <mailto:sip%3Angcp-lb at 196.41.123.113
> >;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
> 196.41.123.113:5060
> > <http://196.41.123.113:5060>>,
> > <sip:ngcp-lb at 127.0.0.1
> > <mailto:sip%3Angcp-lb at 127.0.0.1
> >;r2=on;lr=on;ftag=KmsqOjkyLjI0MC4wLjEzOjUwODE;ngcplb=yes;socket=udp:
> 196.41.123.113:5060
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
> >
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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 <tel: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
> > <http://127.0.0.1:5060> -> 127.0.0.1:5062
> > <http://127.0.0.1:5062>
> >
> > INVITE sip:127.0.0.1:5080
> > <http://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
> > <http://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
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
> >
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://196.41.123.113:5060>'
> >
> > '
> >
> > v=0'
> >
> > o=- 3522956930 <tel: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
> > <http://127.0.0.1:5062> -> 127.0.0.1:5060
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
> >
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://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
> > <http://196.41.123.113:5060> -> 92.240.1.12:5060
> > <http://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
> > <mailto:sip%3A27214482133 at 92.240.1.12
> >;user=phone>;tag=KmsqOjkyLjI0MC4wLjEzOjUwODE'
> >
> > To: <sip:27110254990 at 196.41.123.113
> > <mailto:sip%3A27110254990 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
> > <http://127.0.0.1:5062> -> 127.0.0.1:5060
> > <http://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
> > <http://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
> > <http://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
> > <mailto: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
> > <mailto: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
> > <mailto: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>
> > <mailto:
> sip%3Angcp-lb at 196.41.__123.113
> > <mailto:
> sip%253Angcp-lb at 196.41.123.113>>
> > F=
> sip:27219763939 at 92.240.1.12 <mailto:sip%3A27219763939 at 92.240.1.12>
> > <mailto:
> sip%3A27219763939 at 92.__240.1.12
> > <mailto:
> sip%253A27219763939 at 92.240.1.12>>
> > T=
> sip:27214235154 at 196.41.123.__113
> > <mailto:
> sip%3A27214235154 at 196.41.123.113>
> > <mailto:
> sip%3A27214235154 at 196.__41.123.113
> > <mailto:
> sip%253A27214235154 at 196.41.123.113>>
> > IP=udp:92.240.1.12:5060
> > <http://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
> > <mailto:Spce-user at lists.sipwise.com>
> > http://lists.sipwise.com/listinfo/spce-user
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Spce-user mailing list
> > Spce-user at lists.sipwise.com
> > http://lists.sipwise.com/listinfo/spce-user
> >
>
> _______________________________________________
> 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/20130925/3015ba17/attachment-0001.html>
More information about the Spce-user
mailing list