By Date: <-- -->
By Thread: <-- -->

Format of sipXphone Contact headers - requesting a change

Title: Message
I believe the contact header is derived from the line definition.  If you create a line definition with a username and set that as your outbound line (as opposed to just an IP address) the contact should include it.
 
-
Bob
-----Original Message-----
From: sipx-dev-bounces (at) list.sipfoundry.org [mailto:sipx-dev-bounces (at) list.sipfoundry.org] On Behalf Of support (at) LanScapeCorp.com
Sent: Monday, January 30, 2006 4:28 PM
To: sipx-dev (at) list.sipfoundry.org
Cc: support (at) LanScapeCorp.com
Subject: [sipX-dev] Format of sipXphone Contact headers - requesting a change

Hi,
 
We have been performing testing using the sipXphone and our line of scalable SIP proxy
and RTP media server products for voice and video. LanScape voice and video SIP server
products can be reviewed at the following URLs:
 
Scalable Sip Centrex Proxy server:
http://www.lanscapecorp.com/ProductPages/CentrexProxy.asp
 
High performance RTP Media proxy:
http://www.lanscapecorp.com/ProductPages/VoipMediaProxy.asp

Some customers want to use the SipXphone so we perform upfront interop testing to make sure
basic functionality works.

We wanted to make a recomendation to you regarding how your Contact headers are
being formatted. We tested using SipXphone versioin 2.6.0.27

We noticed that your code creates Contact headers something like:
 
Contact: sip:10.0.0.2
instead of:
 
sip:username (at) 10.0.0.2:port
 
What we would like to see is that you always make sure the username is part of a contact header.
The port value is not so critical but the user name is really important to help reduce extra proxy
procesing.

For example: Here is a "200 Ok" response from the SipXphone after it decides it want to accept
an INVITE:

SIP/2.0 200 OK
From: 222 <sip:222 (at) lanscapecorp.dnsalias.com:7000>;tag=c923c43;x-UaId=xxxxx-yyyy-zzzzzz;x-PsId=4D724D22-A5AF-4C50-A01A-76B162933D64
To: <sip:111 (at) lanscapecorp.dnsalias.com:7000>;tag=25882
Call-Id: b217ba35-f6bb-4bb5-ba89-39b226fcbab3-000013b4 (at) 192.168.1.2
Cseq: 210904266 INVITE
Content-Type: application/sdp
Content-Length: 163
Via: SIP/2.0/UDP 192.168.1.2:7000;branch=z9hG4bKf968a2ddba0e290a869b664c5acf6a178.0;received=70.92.187.124
Via: SIP/2.0/UDP 192.168.1.2:10000;received=192.168.1.2:10000
Record-Route: <sip:70.92.187.124:7000;lr>
Date: Mon, 30 Jan 2006 22:58:03 GMT
Contact: sip:10.0.0.2
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE
User-Agent: sipX/2.5.2 (WinNT)
Accept-Language: en
Supported: sip-cc, sip-cc-01, timer, replaces
 
v=0
o=sipX 5 5 IN IP4 10.0.0.2
s=phone-call
c=IN IP4 10.0.0.2
t=0 0
m=audio 13002 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000/1
a=rtpmap:101 telephone-event/8000/1
 
 
Our SIp server products perform complex SIP protocol fixups when they detect that things are not
quite right with the received SIP protocol data (the exact same way a dedicated session border
controller operates). In this case, our server code fixed up things as expected but had to perform
more processing than normal. Tha'ts what caught our eye.

Anyway, please check the SIP RFC and try to format your Contact headers using username (at) host:port syntax.
 
Thanks and happy VOIPing!



LanScape support
 
 
_______________________________________________
sipx-dev mailing list
sipx-dev (at) list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-dev