Hello All,
I am having an issue with sipx where my udp invite packet is too large. While everything locally appears to be handled correctly with a fragmented udp packet, my provider is refusing to support it. They also are not ready for sip over tcp yet. Upon examination of my invite packets, I have realized that for some reason sipx is adding itself into the Via headers three times, each with what seems to be unreasonably large branch id's. My goal is to get the invite packet size down to a level that my provider can accept without issue. My provider is set up as a sip trunk in sipx. I also have my provider set up through "internet calling" and I can complete calls from my soft phone with direct internet dialing (i.e. sip:[EMAIL PROTECTED]). In that scenario, sipx only adds itself to the Via Header list once, thereby reducing the initial invit by nearly 250 bytes, which is quite a bit with around a 1300 byte limit. Unfortunately, in order to use sipx as a true pbx, I need to be able to dial something like '918885551212' as an internal extension, and transform it and send it out on the sip trunk. Internet dialing is very difficult (i.e. impossible for my users) to do from a hard phone. I don't know yet what all the sipXbridge is supposed to offer in ver 4.0, but I know that I don't need a full b2bua, and I definitely do not want to route media, I need a direct media path. I am basically looking for some advice on reducing my invite packet size, if that is at all possible. I am running sipx 3.10.1 on the CentOS version that comes bundled from sipfoundry on ISO. U 10.0.6.200:5060 -> 172.16.240.1:5060 INVITE sip:[EMAIL PROTECTED]:5060;transport=udp SIP/2.0 Record-Route: <sip:10.0.6.200:5060;lr;sipXecs-rs=%2Afrom%7EMzYwZjdjNTctZGQyZi1kZDExLTk wNmUtMDAwNDRiMDJmYmFj.400_authrules%2Aauth%7E%21839cc0f7ee25a3f95ea3d5bc c6b84472> Date: Tue, 03 Jun 2008 13:19:19 GMT Cseq: 1 INVITE User-Agent: Ekiga/2.0.12 From: "Travis Hegner" <sip:[EMAIL PROTECTED]>;tag=360f7c57-dd2f-dd11-906e-00044b02fbac Call-Id: [EMAIL PROTECTED] To: sip:[EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED]:5061;transport=udp Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 196 Max-Forwards: 16 Via: SIP/2.0/UDP 10.0.6.200;branch=z9hG4bK-sipXecs-8b32018bb4b4e02079df3c36366f403929c6 Via: SIP/2.0/UDP 10.0.6.200;branch=z9hG4bK-sipXecs-8b2f05d0b08ce1d07bdf862c7f1691aeb71f%5 28ef725b018d0d1412e64d09aeba57e Via: SIP/2.0/UDP 10.0.6.200;branch=z9hG4bK-sipXecs-8b2ac4c6163c23245d11b470b435d93a885b%b 4564dc674dc5257d2f008094764cdf4 Via: SIP/2.0/UDP 10.0.6.3:5095;branch=z9hG4bK2cdc7c57-dd2f-dd11-906e-00044b02fbac;rport=5 095 X-Sipx-Spiral: true v=0 o=- 1212499159 1212499159 IN IP4 10.0.6.3 s=Opal SIP Session c=IN IP4 10.0.6.3 t=0 0 m=audio 5034 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 In the above trace, 10.0.6.3, is my softphone, and 10.0.6.200 is my sipx box. Notice how sipx puts itself into via headers 3 times. This eats up some valuable space considering I cannot have a fragmented udp packet sent to the provider. Any suggestions are greatly appreciated. Travis
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
