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.
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
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@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@freenet.ag
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Atle Samuelsen -
Jan Andres -
SIP