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

[Kovar, William (Bill)]

Robert,
 
An accurate example of the msg flow is the Call Hold Sip Service example
found at the tech-invite website at:
http://www.tech-invite.com/Ti-sip-service-1.html#fig0
 
Using the above scenario as a reference, my problem specifically happens
between msgs 6-8.
Msg 6 is the 200 OK back from Alice in response to a HOLD request from
Bob. In this response I see a Contact header in the form Contact:
<sip:1.0.1.0>
 
DUM uses this value as the req-Uri remote target and sends ACK
 
Msg 8 is a re-Invite to go off Hold. DUM's provideOffer() method
constructs the Invite using the mRemoteTarget variable to construct the
RLine in the Dialog class. The INVITE looks like this:
INVITE sip:1.0.1.0 SIP/2.0
 
DUM eventually generates a 408 after 32 seconds on this Invite.
 
So my question becomes: I want the Invite to point to Alice but the
Invite that DUM creates has no user part. And it has no user part
because the last Contact Header update (msg 6, 200 OK) changed it to
have no user part, which DUM cached. Is this causing the 408 or is there
something else.
 
 
Bill Kovar
bkovar at avaya.com
Avaya, Inc.
(732) 852-2609
 



  _____  

	From: Robert Sparks [mailto:rjsparks at nostrum.com] 
	Sent: Friday, November 17, 2006 11:56 PM
	To: Kovar, William (Bill)
	Cc: Scott Godin; resiprocate-devel at list.sipfoundry.org
	Subject: Re: [reSIProcate] Request Line construction problems
during shuffle re-invite in Dialog::makerequest()
	
	
	Bill - it will help if you actually give us the flow messages.
	
	
	A Contact that looks like
	Contact: <sip:10.0.0.1> is quite legal in a 200 to an INVITE.
	
	
	Are you seeing something that looks like
	Contact: <sip:@10.0.0.1>? That one isn't legal.
	
	
	There are no differences in the requirements for what goes into
the Contact for an initial INVITE
	or any subsequent reINVITE in that dialog.
	
	
	
	
	
	
	On Nov 17, 2006, at 6:31 PM, Kovar, William ((Bill)) wrote:


		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
		 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061120/9db5749e/attachment.htm>