[reSIProcate] Request Line construction problems during shuffle re-invite in Dialog::makerequest()

Fri Nov 17 18:31:44 CST 2006

Scott,

In trying to identify who is violating the SIP spec....
I send an Invite which gets answered with a 200 that has a malformed
Contact header, i.e. no userinfo part.
DUM sends the ACK to the malformed URI successfully.
I Send an re-Invite using provideOffer() and Req-URI for the Invite is
bad. The Invite times-out.

This is really baffling me as to who is breaking the spec because some
have told me that the Contact header in this form is OK except for the
initial invite.

Anybody have an opinion??

Bill Kovar
bkovar at avaya.com
Avaya, Inc.
(732) 852-2609

  _____  

	From: Scott Godin [mailto:slgodin at icescape.com] 
	Sent: Tuesday, November 07, 2006 8:02 PM
	To: Kovar, William (Bill); resiprocate-devel at list.sipfoundry.org
	Subject: RE: [reSIProcate] Request Line construction problems
during shuffle re-invite in Dialog::makerequest()

	What you are doing sounds fine.

	The request line on your the outbound re-invite is likely from
the contact header of the 200 from the initial invite - I'm assuming it
is a server invite session.

	Scott

	From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
Kovar, William (Bill)
	Sent: Tuesday, November 07, 2006 6:55 PM
	To: resiprocate-devel at list.sipfoundry.org
	Subject: [reSIProcate] Request Line construction problems during
shuffle re-invite in Dialog::makerequest()

	All,

	I'm seeing a problem with Dialog::makerequest() when receiving a
ReInvite. The provideOffer() method attempts to build the INVITE message
and does so with an invalid Request Line, i.e. INVITE sip:domain.com
where the user part is missing. Below are snips from the log showing the
incoming INVITE, the provideOffer(), and the subsequent prints in
makerequest().

	The complete sequence is shown in the attached trace, but a pair
of connected sessions, that are being managed by a B2B, is being sent a
re-invite, which I have to provideOffer() to the other side of the B2B.
The provideOffer() is being done from within onAnswer() within the same
DUM and thread instance (but using DumThread and StackThread). I put
some prints into Dialog::makerequest() and found that it was accessing a
member variable, mRemoteTarget.Uri, within the Dialog. The Re-invite
comes in on 1 session, and I'm sending the offer on a different session,
the call ids are different and hence the dialogs should be different. 

	I'm on a older version of resip from SVN (circa mar 06) but just
pulled down the 1.0.1 tarball and didn't see any change to Dialog.cxx
that would address this.

	Is what I am trying to do legal and if so, any ideas why the
request line is being built incorrectly?

	Bill Kovar

	INVITE sip:55123 at 135.8.116.33:5060 SIP/2.0
	Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bKD256464603538333231180b.0
	Via: SIP/2.0/UDP
135.8.52.54:36092;psrrposn=1;received=135.8.52.54;branch=z9hG4bK-d87543-
7e2466749713bd4c-1--d87543-;rport=36092
	Max-Forwards: 69
	Record-Route: <sip:135.8.52.181:5060;lr>
	Contact:
<sip:55501 at 135.8.52.54:36092;rinstance=47c2eadfce5cb0e5>
	To: "IC 7.1 B2B"<sip:55123 at avaya.com>;tag=87167f3f
	From: <sip:55501 at avaya.com>;tag=d52d576b
	Call-ID:
e03e8a100527ad51ZTU2NTMzOTg2ZDMyYzc4MWNiYjc4MzMzMGUwNGJkYWM.
	CSeq: 3 INVITE
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY,
MESSAGE, SUBSCRIBE, INFO
	Content-Type: application/sdp
	User-Agent: X-Lite release 1003l stamp 30942
	P-Asserted-Identity: sip:55501 at avaya.com
	Content-Length: 231

	v=0
	o=- 9 4 IN IP4 135.8.52.54
	s=CounterPath eyeBeam 1.5
	c=IN IP4 0.0.0.0
	t=0 0
	m=audio 17010 RTP/AVP 0 127
	a=fmtp:127 0-15
	a=rtpmap:127 telephone-event/8000
	a=sendonly
	a=x-rtp-session-id:663EBBA451B741909024C82821116262

	Fixed SDP (Eyebeam sends an old style Hold with Connection =
0.0.0.0 which is problematic for me...)
	o=- 9 4 IN IP4 135.8.52.54
	s=CounterPath eyeBeam 1.5
	c=IN IP4 135.8.52.54
	t=0 0
	m=audio 17010 RTP/AVP 0 127
	a=fmtp:127 0-15
	a=rtpmap:127 telephone-event/8000
	a=sendonly
	a=x-rtp-session-id:663EBBA451B741909024C82821116262

	Problematic DUM code:
	INFO | 20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 |
ServerInviteSession.cxx:154 | InviteSession::Connected: provideOffer
	INFO | 20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 |
InviteSession.cxx:2032 | Transition InviteSession::Connected ->
InviteSession::SentReinvite
	DEBUG | 20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 |
Dialog.cxx:834 | +++++++ mRemoteTarget.Uri =
sip:135.8.135.123;transport=tcp
	DEBUG | 20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 |
Dialog.cxx:836 | +++++++ Rline = INVITE sip:135.8.135.123;transport=tcp
SIP/2.0
	DEBUG | 20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 |
Dialog.cxx:901 | Dialog::makeRequest: INVITE
sip:135.8.135.123;transport=tcp SIP/2.0
	Via: SIP/2.0/
;branch=z9hG4bK-d87543-2a190f6cd355ba15-1--d87543-;rport
	Max-Forwards: 70
	Route: <sip:135.8.52.181:5060;lr>
	Route: <sip:135.8.135.123;lr;transport=tcp>
	Contact:
<sip:55123 at 135.8.116.33:5060;rinstance=013fc72a18699110>
	To: "Kowen's IPA
321"<sip:32100 at avaya.com>;tag=092b1eb9f80db1ee1345461dba00
	From: "55123"<sip:55123 at avaya.com>;tag=fc7a402d
	Call-ID: 092b1eb9f80db1ef1345461dba00
	CSeq: 2 INVITE
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, NOTIFY
	Content-Length: 0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061117/7595f432/attachment.htm>