Hi Juha, you are right, the ACK is not OK. But unlike the other problem concerning the route-set, this one is not so easy to fix.
Let me explain the problem: At the moment, the 200 ACK is generated from the reply. As the transaction is supposed to be destructed by receipt of the first positive reply (as required by the RFC), the original INVITE containing the route-set is not available anymore. The correct behavior would be to let AmSipDialog generate the 200 ACK (which would, at the same time, enable a couple of other nice call-flows). Unfortunatly, this is not supported by the unixsockctrl and binrpcctrl plugins. Whereby this could be enabled very easely in binrpcctrl (SER support for this is already implemented), the unixsockctrl would need a lot more work. So, the other solution (thus disabling ACK support in the SEMS application) would be to destroy the transaction first when timer B hits. This would also mean that sipctrl would take full control of the 200 ACK. At the moment, it is only implemented in SipCtrlInterface.cpp. Choosing this solution would mean to change the state machine in a non-RFC compliant way, thus simulating SER's behavior for UAC transactions. So the choice is: - (1) keep the correct state machine, send ACKs from AmSipDialog break unixsockctrl support and modify binrpcctrl to support sending ACKs. - (2) modify the state machine and simulate SER's behavior in sipctrl. This modification should be canceled after we dropped unixsockctrl and enable support for ACKs in SEMS applications. Take the blue or the red pill ;-) Cheers, Raphael. Juha Heinanen wrote: > in a2bua case, ack that sems sends to ok from re-invite to a is not > correct. i think the reason is that sems sends the ack according to the > route information in the ok to the re-invite (which didn't include any). > according to rfc3261, in-dialog requests must use the route set that was > learned when the dialog was originally setup. that was correct in > re-invite that sems sent to a, but not anymore in the ack to its ok. > > -- juha > > -------------------------------------------------------------------- > > a to sems invite: > > Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 > Message Header > Record-Route: <sip:192.98.101.10;r2=on;lr> > Record-Route: <sip:192.98.101.10:5070;r2=on;lr> > Record-Route: <sip:192.98.101.10;lr;n1;dm> > Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bK35ec.c49a4dd.0 > Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bK35ec.b49a4dd.0 > Via: SIP/2.0/UDP > 192.168.0.3:5020;received=192.168.1.2;rport=59365;branch=z9hG4bKtjwmktzp > Max-Forwards: 68 > To: <sip:[EMAIL PROTECTED]> > From: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=fdnqm > Call-ID: [EMAIL PROTECTED] > CSeq: 607 INVITE > Contact: <sip:[EMAIL PROTECTED]:59365> > Content-Type: application/sdp > Allow: > INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE > Supported: replaces,norefersub,100rel > User-Agent: Twinkle/1.1 > Content-Length: 348 > P-Flags: 0 > P-App-Param: Language=fi > P-App-Name: conf_auth > > sems to b invite (b is sems conference app): > > Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0 > Message Header > Via: SIP/2.0/UDP 192.98.101.10:5090;branch=z9hG4bK2w6JLaJN > From: "Juha Heinanen" <sip:[EMAIL > PROTECTED]>;tag=5774C843-4804850100041596-B62FFB90 > To: sip:[EMAIL PROTECTED] > CSeq: 10 INVITE > Call-ID: [EMAIL PROTECTED] > Contact: <sip:[EMAIL PROTECTED]:5090> > Max-Forwards: 68 > Allow: > INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE > Supported: replaces,norefersub,100rel > User-Agent: Twinkle/1.1 > P-Flags: 0 > P-App-Param: Language=fi > P-App-Name: conf_auth > Content-Type: application/sdp > Content-Length: 348 > > b to sems ok: > > Status-Line: SIP/2.0 200 OK > Message Header > Record-Route: <sip:192.98.101.10;r2=on;lr> > Record-Route: <sip:192.98.101.10:5080;r2=on;lr> > Via: SIP/2.0/UDP 192.98.101.10:5090;branch=z9hG4bK2w6JLaJN > From: "Juha Heinanen" <sip:[EMAIL > PROTECTED]>;tag=5774C843-4804850100041596-B62FFB90 > To: sip:[EMAIL PROTECTED];tag=19E6CF03-4804850100042825-B6B2EB90 > CSeq: 10 INVITE > Call-ID: [EMAIL PROTECTED] > Server: Sip Express Media Server (1.0.0-pre-r880M (i386/linux)) > Contact: <sip:[EMAIL PROTECTED]:5090> > Content-Type: application/sdp > Content-Length: 224 > > sems to a re-invite: > > Request-Line: INVITE sip:[EMAIL PROTECTED]:59365 SIP/2.0 > Message Header > Via: SIP/2.0/UDP 192.98.101.10:5090;branch=z9hG4bK7tcMAa44 > Route: <sip:192.98.101.10;lr;n1;dm> > Route: <sip:192.98.101.10:5070;r2=on;lr> > Route: <sip:192.98.101.10;r2=on;lr> > From: <sip:[EMAIL PROTECTED]>;tag=75BE3D2F-480484F9000E7EAE-B6B2EB90 > To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=fdnqm > CSeq: 10 INVITE > Call-ID: [EMAIL PROTECTED] > Contact: <sip:[EMAIL PROTECTED]:5090> > Content-Type: application/sdp > Content-Length: 224 > > a to sems ok: > > Status-Line: SIP/2.0 200 OK > Message Header > Via: SIP/2.0/UDP 192.98.101.10:5090;branch=z9hG4bK7tcMAa44 > To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=fdnqm > From: <sip:[EMAIL PROTECTED]>;tag=75BE3D2F-480484F9000E7EAE-B6B2EB90 > Call-ID: [EMAIL PROTECTED] > CSeq: 10 INVITE > Contact: <sip:[EMAIL PROTECTED]:5070> > Content-Type: application/sdp > Allow: > INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE > Server: Twinkle/1.1 > Supported: replaces,norefersub > Content-Length: 210 > > sems to a ack: > > Request-Line: ACK sip:[EMAIL PROTECTED]:5070 SIP/2.0 > Message Header > Via: SIP/2.0/UDP 192.98.101.10;branch=z9hG4bK8tcMAa6c > From: <sip:[EMAIL PROTECTED]>;tag=75BE3D2F-480484F9000E7EAE-B6B2EB90 > To: "Juha Heinanen" <sip:[EMAIL PROTECTED]>;tag=fdnqm > Call-ID: [EMAIL PROTECTED] > Max-Forwards: 10 > CSeq: 10 ACK > _______________________________________________ > Semsdev mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/semsdev > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
