reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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

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

From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
Sent: Friday, November 17, 2006 11:56 PM
To: Kovar, William (Bill)
Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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
Avaya, Inc.
(732) 852-2609