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

Mon Nov 20 10:48:51 CST 2006

Robert,

Thanks for you explanation, which is what I had originally suspected but
wanted some validation. It seems that the proxy (one does exist) is
forwarding the re-Invite correctly, but the UAS on the other side was
not handling the re-Invite correctly.

Your info helps me to identify the exact source of the problem.

Thanks!!

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

  _____  

	From: Robert Sparks [mailto:rjsparks at nostrum.com] 
	Sent: Monday, November 20, 2006 10:57 AM
	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()

	With what you've sent so far (you gave me the scenario with that
link, but not the exact bits, so I'm still having to guess a little), 
	DUM is doing exactly the right thing (and cannot do anything
different without violating the spec). To check my guesses:

	1) The initial invite has a record route header field when it
reaches the recipient and when the 200 OK reaches the caller.
	     Thus there is a non-empty route set established at each
end, containing exactly the one proxy.
	2) The 200 OK to the re-INVITE putting the call on hold has the
Contact you show below.

	Unless you are in a network where 1.0.1.0 makes sense, Alice's
UA has returned something that breaks the call. There's nothing
	the proxy or Bob's UA can or should do to try to fix it. Any
subsequent request from Bob must go to the proxy based on the Route 
	header field and then will probably die (unless 1.0.1.0 is
routable from the proxy's perspective). Alice's UA is obligated to put
	a value in that Contact that can be used to get back to it (or
something sharing it's dialog state).

	The presence of a user part or not is not relevant. Alice's UA
is quite free to provide a URI with no user part - it just has to route
back correctly.

	RjS

	On Nov 20, 2006, at 8:37 AM, Kovar, William ((Bill)) wrote:

		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/ae2d5509/attachment.htm>