|
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
What
you are doing sounds fine.
The
request line on your the outbound re-invite is likely from the contact header
of the 200 from the initial invite – I’m assuming it is a server invite
session.
Scott
From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Kovar, William (Bill)
Sent: Tuesday, November 07, 2006 6:55
PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject:
[reSIProcate] Request Line construction problems during shuffle re-invite in
Dialog::makerequest()
I'm
seeing a problem with Dialog::makerequest() when receiving a ReInvite. The
provideOffer() method attempts to build the INVITE message and does so with an
invalid Request Line, i.e. INVITE sip:domain.com where the user part is
missing. Below are snips from the log showing the incoming INVITE, the
provideOffer(), and the subsequent prints in
makerequest().
The
complete sequence is shown in the attached trace, but a pair of connected
sessions, that are being managed by a B2B, is being sent a re-invite, which I
have to provideOffer() to the other side of the B2B. The provideOffer() is
being done from within onAnswer() within the same DUM and thread instance (but
using DumThread and StackThread). I put some prints into Dialog::makerequest()
and found that it was accessing a member variable, mRemoteTarget.Uri, within
the Dialog. The Re-invite comes in on 1 session, and I'm sending the offer on
a different session, the call ids are different and hence the dialogs should
be different.
I'm on
a older version of resip from SVN (circa mar 06) but just pulled down the
1.0.1 tarball and didn't see any change to Dialog.cxx that would address
this.
Is
what I am trying to do legal and if so, any ideas why the request line is
being built incorrectly?
INVITE
sip:55123@xxxxxxxxxxxx:5060 SIP/2.0
Via:
SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bKD256464603538333231180b.0
Via:
SIP/2.0/UDP
135.8.52.54:36092;psrrposn=1;received=135.8.52.54;branch=z9hG4bK-d87543-7e2466749713bd4c-1--d87543-;rport=36092
Max-Forwards:
69
Record-Route:
<sip:135.8.52.181:5060;lr>
Contact:
<sip:55501@xxxxxxxxxxx:36092;rinstance=47c2eadfce5cb0e5>
To:
"IC 7.1
B2B"<sip:55123@xxxxxxxxx>;tag=87167f3f
From:
<sip:55501@xxxxxxxxx>;tag=d52d576b
Call-ID:
e03e8a100527ad51ZTU2NTMzOTg2ZDMyYzc4MWNiYjc4MzMzMGUwNGJkYWM.
CSeq:
3 INVITE
Allow:
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO
Content-Type:
application/sdp
User-Agent:
X-Lite release 1003l stamp 30942
P-Asserted-Identity:
sip:55501@xxxxxxxxx
Content-Length:
231
v=0
o=- 9
4 IN IP4 135.8.52.54
s=CounterPath
eyeBeam 1.5
c=IN
IP4 0.0.0.0
t=0
0
m=audio
17010 RTP/AVP 0 127
a=fmtp:127
0-15
a=rtpmap:127
telephone-event/8000
a=sendonly
a=x-rtp-session-id:663EBBA451B741909024C82821116262
Fixed
SDP (Eyebeam sends an old style Hold with Connection = 0.0.0.0 which is
problematic for me...)
o=- 9
4 IN IP4 135.8.52.54
s=CounterPath
eyeBeam 1.5
c=IN
IP4 135.8.52.54
t=0
0
m=audio
17010 RTP/AVP 0 127
a=fmtp:127
0-15
a=rtpmap:127
telephone-event/8000
a=sendonly
a=x-rtp-session-id:663EBBA451B741909024C82821116262
Problematic DUM
code:
INFO |
20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 |
ServerInviteSession.cxx:154 | InviteSession::Connected: provideOffer
INFO |
20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 | InviteSession.cxx:2032 |
Transition InviteSession::Connected -> InviteSession::SentReinvite
DEBUG
| 20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 | Dialog.cxx:834 |
+++++++ mRemoteTarget.Uri = sip:135.8.135.123;transport=tcp
DEBUG |
20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 | Dialog.cxx:836 | +++++++
Rline = INVITE sip:135.8.135.123;transport=tcp SIP/2.0
DEBUG |
20061107-180909.164 | SipSwitch | RESIP:DUM | 5064 | Dialog.cxx:901 |
Dialog::makeRequest: INVITE sip:135.8.135.123;transport=tcp
SIP/2.0
Via:
SIP/2.0/
;branch=z9hG4bK-d87543-2a190f6cd355ba15-1--d87543-;rport
Max-Forwards:
70
Route:
<sip:135.8.52.181:5060;lr>
Route:
<sip:135.8.135.123;lr;transport=tcp>
Contact:
<sip:55123@xxxxxxxxxxxx:5060;rinstance=013fc72a18699110>
To:
"Kowen's IPA
321"<sip:32100@xxxxxxxxx>;tag=092b1eb9f80db1ee1345461dba00
From:
"55123"<sip:55123@xxxxxxxxx>;tag=fc7a402d
Call-ID:
092b1eb9f80db1ef1345461dba00
CSeq:
2 INVITE
Allow:
INVITE, ACK, CANCEL, OPTIONS, BYE, NOTIFY
Content-Length:
0
|