|
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
Avaya, Inc.
(732) 852-2609
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,
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:
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
Avaya, Inc.
(732) 852-2609
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
Avaya, Inc.
(732) 852-2609
|