27 Jul
2007
27 Jul
'07
5:24 a.m.
One of our clients, using a Nokia E90, is having problems connecting to
anything.
His INVITE looks like this:
U 123.236.98.24:55031 -> 11.22.33.44:5060
INVITE sip:1747XXXXXXX@our.proxy.com;user=phone SIP/2.0.
Route: <sip:our.proxy.com;lr;transport=UDP>.
Via: SIP/2.0/UDP
192.168.1.229:5060;branch=z9hG4bK3e89pocn1m7mkuiefdjljsj;rport.
From: <sip:1101XXXXXXX@our.proxy.com>;tag=ls57mprkkdhc7kku07de.
To: <sip:1747XXXXXXX@our.proxy.com;user=phone>.
Contact: <sip:1101XXXXXXX@123.236.98.24:55045;transport=UDP>.
Supported: 100rel,sec-agree.
CSeq: 980 INVITE.
Call-ID: pyBXpNNeoIcFBM7qVqVKrBneC2kxeM.
Allow: INVITE,ACK,BYE,CANCEL,REFER,NOTIFY,OPTIONS,PRACK.
Expires: 120.
Privacy: none.
User-Agent: Nokia RA-6 V 07.24.0.3.
P-Preferred-Identity: sip:1101XXXXXXX@our.proxy.com.
Max-Forwards: 70.
Proxy-Authorization: Digest
qop=auth,realm="our.proxy.com",nonce="46a713c0c887788778a731de0355c04db1896d23",algorithm=MD5,username="1101XXXXXXX",cnonce="0dad64affaabb2fa9c93611ec864e363",nc=00000001,uri="sip:1747XXXXXXX@our.proxy.com;user=phone",response="197f8a8b4b3d39281a147c2d9d2b6a28".
Content-Type: application/sdp.
Accept: application/sdp.
Content-Length: 447.
.
v=0.
o=Nokia-SIPUA 63353630343979125 63353630343979125 IN IP4 123.236.98.24.
s=-.
c=IN IP4 123.236.98.24.
t=0 0.
m=audio 49152 RTP/AVP 96 0 8 97 18 98 13.
a=sendrecv.
a=ptime:20.
a=maxptime:200.
a=fmtp:96 mode-change-neighbor=1.
a=fmtp:18 annexb=no.
a=fmtp:98 0-15.
a=rtpmap:96 AMR/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:8 PCMA/8000/1.
a=rtpmap:97 iLBC/8000/1.
a=rtpmap:18 G729/8000/1.
a=rtpmap:98 telephone-event/8000/1.
a=rtpmap:13
The server received this packet, but never responds to it. It simply
never sends a reply. It's as though it doesn't recognise this as a
proper INVITE.
The ONLY thing I noticed about this that's completely non-standard, is
that every other packet seems to have this period after it (indicating,
perhaps, the end of a line... I don't know enough about the display of
ngrep to tell). This INVITE does not. It goes almost immediately into
the next packet, and it's almost as though this one never ends.
Has anyone seen this before? Is there anything weird about this INVITE
that would cause SER to ignore it?
N.
27 Jul
27 Jul
10 a.m.
On Thu, Jul 26, 2007 at 10:24:18PM -0400, SIP wrote:
[...]
a=rtpmap:18 G729/8000/1.
a=rtpmap:98 telephone-event/8000/1.
a=rtpmap:13
[...]
The ONLY thing I noticed about this that's completely non-standard, is
that every other packet seems to have this period after it (indicating,
perhaps, the end of a line... I don't know enough about the display of
ngrep to tell). This INVITE does not. It goes almost immediately into
the next packet, and it's almost as though this one never ends.
It looks like there's a part missing at the end (the last line isn't
complete). In other words, the packet is probably fragmented.
Unfortunately you can't tell this from ngrep's output.
If the packet is fragmented, and the second fragment is dropped on the
way (due to broken firewalls or sth), then the kernel will not be able
to reassemble the packet, and it won't even be processed by SER. Which
would explain that no reaction is observed.
Note also that with ngrep you won't see the successive fragments if you
use a filter expression like "port 5060", because the port numbers are
only contained in the first fragment.
Regards,
Jan
--
Jan Andres <jan.andres(a)freenet.ag>
10:56 a.m.
Hi,
try to disable some codecs, and see if it suddenly starts working,
disable all wich you are not useing..
-A
* Jan Andres <jan.andres(a)freenet-ag.de> [070727 09:00]:
On Thu, Jul 26, 2007 at 10:24:18PM -0400, SIP wrote:
[...]
a=rtpmap:18 G729/8000/1.
a=rtpmap:98 telephone-event/8000/1.
a=rtpmap:13
[...]
The ONLY thing I noticed about this that's completely non-standard, is
that every other packet seems to have this period after it (indicating,
perhaps, the end of a line... I don't know enough about the display of
ngrep to tell). This INVITE does not. It goes almost immediately into
the next packet, and it's almost as though this one never ends.
It looks like there's a part missing at the end (the last line isn't
complete). In other words, the packet is probably fragmented.
Unfortunately you can't tell this from ngrep's output.
If the packet is fragmented, and the second fragment is dropped on the
way (due to broken firewalls or sth), then the kernel will not be able
to reassemble the packet, and it won't even be processed by SER. Which
would explain that no reaction is observed.
Note also that with ngrep you won't see the successive fragments if you
use a filter expression like "port 5060", because the port numbers are
only contained in the first fragment.
Regards,
Jan
--
Jan Andres <jan.andres(a)freenet.ag> _______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6328
days inactive
6328
days old
2 comments
3 participants
participants (3)
-
Atle Samuelsen -
Jan Andres -
SIP