| 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 |