o Juha Heinanen [10/15/09 15:32]:
i build latest trunk sems and noticed that when sems receives a call,
plays announcement, and then sends bye, request uri in the bye is not
contact uri of caller, but from uri of caller. this is not correct.
are you sure it is not the URI from the Contact of the ACK rather than
the From uri? I think its correct to update remote uri from ACK Contact
uri.
what was changed some time ago is that remote uri would not be
overwritten with empty uri, and remote uri could be set explicitely with
outgoing request (r1023).
consider this flow (from sipp uac scenario slightly changed, latest trunk).
U 192.168.5.106:5061 -> 192.168.5.106:5070
INVITE sip:[email protected]:5070 SIP/2.0.
Via: SIP/2.0/UDP 192.168.5.106:5061;branch=z9hG4bK-10355-1-0.
From: sipp <sip:[email protected]:5061>;tag=10355SIPpTag001.
To: sut <sip:[email protected]:5070>.
Call-ID: [email protected].
CSeq: 1 INVITE.
Contact: sip:[email protected]:5061.
Max-Forwards: 70.
Subject: Performance Test.
Content-Type: application/sdp.
Content-Length: 137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 192.168.5.106.
s=-.
c=IN IP4 192.168.5.106.
t=0 0.
m=audio 6000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 192.168.5.106:5070 -> 192.168.5.106:5061
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.5.106:5061;branch=z9hG4bK-10355-1-0.
From: sipp <sip:[email protected]:5061>;tag=10355SIPpTag001.
To: sut
<sip:[email protected]:5070>;tag=136DAD38-4AD728CC000DAC87-B7325B90.
Call-ID: [email protected].
CSeq: 1 INVITE.
Server: Sip Express Media Server (1.1.0-dev-r1543 (i386/linux)).
Contact: <sip:[email protected]:5070>.
Content-Type: application/sdp.
Content-Length: 145.
.
v=0.
o=sems 1069083426 1847543839 IN IP4 192.168.5.106.
s=session.
c=IN IP4 192.168.5.106.
t=0 0.
m=audio 10000 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
#
U 192.168.5.106:5061 -> 192.168.5.106:5070
ACK sip:[email protected]:5070 SIP/2.0.
Via: SIP/2.0/UDP 192.168.5.106:5061;branch=z9hG4bK-10355-1-5.
From: sipp <sip:[email protected]:5061>;tag=10355SIPpTag001.
To: sut
<sip:[email protected]:5070>;tag=136DAD38-4AD728CC000DAC87-B7325B90.
Call-ID: [email protected].
CSeq: 1 ACK.
Contact: sip:[email protected]:5061.
Max-Forwards: 70.
Subject: Performance Test.
Content-Length: 0.
.
#
U 192.168.5.106:5070 -> 192.168.5.106:5061
BYE sip:[email protected]:5061 SIP/2.0.
Via: SIP/2.0/UDP 192.168.5.106:5070;branch=z9hG4bKP2vSya6k.
From: sut
<sip:[email protected]:5070>;tag=136DAD38-4AD728CC000DAC87-B7325B90.
To: sipp <sip:[email protected]:5061>;tag=10355SIPpTag001.
CSeq: 10 BYE.
Call-ID: [email protected].
User-Agent: Sip Express Media Server (1.1.0-dev-r1543 (i386/linux)).
Max-Forwards: 70.
Content-Length: 0.
.
#
U 192.168.5.106:5061 -> 192.168.5.106:5070
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.5.106:5070;branch=z9hG4bKP2vSya6k.
From: sut
<sip:[email protected]:5070>;tag=136DAD38-4AD728CC000DAC87-B7325B90.
To: sipp <sip:[email protected]:5061>;tag=10355SIPpTag001.
Call-ID: [email protected].
CSeq: 10 BYE.
Contact: <sip:192.168.5.106:5061;transport=UDP>.
Content-Length: 0.
.
has something changed recently that could have broken sems like this?
-- juha
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
--
Stefan Sayer
VoIP Services
[email protected]
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev