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

[Robert Sparks]

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