manishankar-417 / sipml5

Automatically exported from code.google.com/p/sipml5
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Too large SIP INVITE #207

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Use "call.htm" to ring to our softphone
2. Get console log

What is the expected output? What do you see instead?

INVITE sent from sipML demo client looks like:

SEND: INVITE sip:890667@SOME_IP SIP/2.0
Via: SIP/2.0/WS 
df7jal23ls0d.invalid;branch=z9hG4bKrK5ZqboSAlEXt0akfso8Gmt11gdIW7Lq;rport
From: "xxx"<sip:xxx@SOME_IP>;tag=o0s6cvc3fOqCrJDBl6ks
To: <sip:890667@SOME_IP>
Contact: 
"xxx"<sip:xxx@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>
;+g.oma.sip-im;language="en,fr"
Call-ID: d91773aa-94e9-6501-fec7-c5bb4183c2be
CSeq: 27588 INVITE
Content-Type: application/sdp
Content-Length: 2153
Route: <sip:SOME_IP:5061;lr;sipml5-outbound;transport=udp>
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2014.12.11
Organization: Doubango Telecom

v=0
o=- 1396133180087307800 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS lzr5PZt4LtPpWcsZUCUR1qHEBjlMKoIqTH6X
m=audio 59018 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 SOME_IP
a=rtcp:59018 IN IP4 SOME_IP
a=candidate:927070022 1 udp 2122260223 10.100.1.62 59018 typ host generation 0
a=candidate:927070022 2 udp 2122260223 10.100.1.62 59018 typ host generation 0
a=candidate:1356517016 1 udp 2122129151 192.168.0.113 59019 typ host generation 
0
a=candidate:1356517016 2 udp 2122129151 192.168.0.113 59019 typ host generation 
0
a=candidate:2042760118 1 tcp 1518280447 10.100.1.62 0 typ host tcptype active 
generation 0
a=candidate:2042760118 2 tcp 1518280447 10.100.1.62 0 typ host tcptype active 
generation 0
a=candidate:509162088 1 tcp 1518149375 192.168.0.113 0 typ host tcptype active 
generation 0
a=candidate:509162088 2 tcp 1518149375 192.168.0.113 0 typ host tcptype active 
generation 0
a=candidate:2652797075 1 udp 1686052607 ....IP.... 0 59018 typ srflx raddr 
10.100.1.62 rport 59018 generation 0
a=candidate:2652797075 2 udp 1686052607 ....IP.... 59018 typ srflx raddr 
10.100.1.62 rport 59018 generation 0
a=ice-ufrag:RPxFms8wiWI5IlRc
a=ice-pwd:hCHAywwEOSOKDVaY2iDKU2x7
a=ice-options:google-ice
a=fingerprint:sha-256 
D5:A9:B0:8C:48:E0:42:29:16:1F:23:0B:7C:DE:21:C4:6A:95:35:15:35:C4:B4:0A:B6:8D:CC
:8D:9E:04:4F:D7
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3750920709 cname:DG+SRwTY3AQck0d0
a=ssrc:3750920709 msid:lzr5PZt4LtPpWcsZUCUR1qHEBjlMKoIqTH6X 
ba040669-b2bb-46fc-aab1-bfad0c2faa5d
a=ssrc:3750920709 mslabel:lzr5PZt4LtPpWcsZUCUR1qHEBjlMKoIqTH6X
a=ssrc:3750920709 label:ba040669-b2bb-46fc-aab1-bfad0c2faa5d

As you can see -- it's really really big. It's bigger than UDP frame can pack 
in one frame -- so our flow is broken. Using TCP -- it's OK.

How can we remove unnecessary info from this SIP message to make it smaller -- 
for example as below?

INVITE sip:XXX@SOME_IP:10000 SIP/2.0

Content-Length: 255
Via: SIP/2.0/UDP SOME_IP:12094;rport;branch=z9hG4bKIfKCYQ_O11ZA6mvNgcr7GA..
From: "klient" <sip:0rs5jc0ke6@SOME_IP:10000>;tag=147736343574
To: <sip:XXX@SOME_IP:10000>
Contact: <sip:0rs5jc0ke6@SOME_IP:12094>
CSeq: 1 INVITE
Max-Forwards: 70
Call-ID: 84074609@SOME_IP
Content-Type: application/sdp

v=0
o=- 1422529973 1422529973 IN IP4 alior-proxy-02.alfavox.local
s=-
c=IN IP4 SOME_IP
t=0 0
m=audio 15420 RTP/AVP 0
a=rtpmap:0 pcmu/8000
m=video 16290 RTP/AVP 99
a=fmtp:99 profile-level-id=420014;packetization-mode=1
a=rtpmap:99 h264/90000

What version of the product are you using? On what operating system?

Chrome 40.0

Please provide any additional information below.

Original issue reported on code.google.com by pbilin...@gmail.com on 29 Jan 2015 at 2:56