search

aldanaalc / webrtc2sip

Automatically exported from code.google.com/p/webrtc2sip
0 stars 0 forks source link

Bad Request - Not following indicated Service-Routes #11

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.when want to make a call from Chrome to IMSDroid

What is the expected output? What do you see instead?
make an audio and video communication
Bad Request - Not following indicated Service-Routes

What version of the product are you using? On what operating system?
WebRTC2SIP, Open IMS Core, Chrome 21 and IMSDroid /v2.0.509, Ubuntu 12.04

Please provide any additional information below.

SIP/2.0 400 Bad Request - Not following indicated Service-Routes
Via: SIP/2.0/TCP 
192.168.0.104:46305;branch=z9hG4bK5pZCxXDCocWoAvgFVghlRdwTpSw4klIp;rport=46305;r
eceived=192.168.0.104
To: <sip:alice@open-ims.test>;tag=bbefbf7b7128ead5ec8132128b760533.ee81
From: <sip:bob@open-ims.test>;tag=89sgNfS7F8gM2KWG4DTT
Call-ID: 8fb8d6d3-5fe0-f3ce-bede-7f1b4068fc83
CSeq: 31965 INVITE
Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))
Warning: 392 192.168.0.104:4060 "Noisy feedback tells:  pid=3072 
req_src_ip=192.168.0.104 req_src_port=1060 in_uri=sip:alice@open-ims.test 
out_uri=sip:alice@open-ims.test via_cnt==2"
Content-Length: 0

sigcomp id=
DEBUG | 20121125-002338.023 | repro | RESIP:TRANSPORT | 3030178624 | 
TcpBaseTransport.cxx:263 | Processing write for [ V4 192.168.0.104:46305 WS 
target domain=unspecified mFlowKey=30 ]
DEBUG | 20121125-002338.023 | repro | RESIP:TRANSPORT | 3030178624 | 
ConnectionManager.cxx:59 | Found fd 30
DEBUG | 20121125-002338.036 | repro | RESIP:TRANSPORT | 3030178624 | 
ConnectionBase.cxx:121 | In State: NewMessage
DEBUG | 20121125-002338.037 | repro | RESIP:TRANSPORT | 3030178624 | 
ConnectionBase.cxx:171 | ConnectionBase::process setting source [ V4 
192.168.0.104:46305 WS target domain=unspecified mFlowKey=30 ]
DEBUG | 20121125-002338.037 | repro | RESIP:TRANSPORT | 3030178624 | 
Transport.cxx:382 | incoming from: [ V4 192.168.0.104:46305 WS target 
domain=unspecified mFlowKey=30 ]
DEBUG | 20121125-002338.037 | repro | RESIP:TRANSPORT | 3030178624 | 
ConnectionBase.cxx:429 | ##Connection: CONN_BASE: 0x9d79ce0 [ V4 
192.168.0.104:46305 WS target domain=unspecified mFlowKey=30 ] received: ACK 
sip:alice@open-ims.test SIP/2.0
Via: SIP/2.0/WS 
df7jal23ls0d.invalid;branch=z9hG4bK5pZCxXDCocWoAvgFVghlRdwTpSw4klIp;rport=46305;
received=192.168.0.104
Max-Forwards: 70
To: <sip:alice@open-ims.test>;tag=bbefbf7b7128ead5ec8132128b760533.ee81
From: <sip:bob@open-ims.test>;tag=89sgNfS7F8gM2KWG4DTT
Call-ID: 8fb8d6d3-5fe0-f3ce-bede-7f1b4068fc83
CSeq: 31965 ACK
Content-Length: 0

DEBUG | 20121125-002338.037 | repro | RESIP:TRANSPORT | 3030178624 | 
Connection.cxx:400 | Connection::performReads()  read=368
DEBUG | 20121125-002338.037 | repro | RESIP:TRANSPORT | 3030178624 | 
ConnectionBase.cxx:894 | Creating buffer for CONN_BASE: 0x9d79ce0 [ V4 
192.168.0.104:46305 WS target domain=unspecified mFlowKey=30 ]
INFO | 20121125-002338.037 | repro | RESIP:TRANSPORT | 3030178624 | 
TcpConnection.cxx:42 | No data ready to read
DEBUG | 20121125-002338.037 | repro | RESIP:TRANSACTION | 3038571328 | 
TuSelector.cxx:70 | Send to TU: TU: Proxy size=0 

ServerTransactionTerminated 5pZCxXDCocWoAvgFVghlRdwTpSw4klIp
DEBUG | 20121125-002338.037 | repro | REPRO:APP | 3013393216 | Proxy.cxx:154 | 
Got: ServerTransactionTerminated 5pZCxXDCocWoAvgFVghlRdwTpSw4klIp
INFO | 20121125-002338.037 | repro | REPRO:APP | 3013393216 | 
RequestContext.cxx:73 | RequestContext::process(TransactionTerminated) 
5pZCxXDCocWoAvgFVghlRdwTpSw4klIp : numtrans=2 final=1 req=SipReq:  INVITE 
alice@open-ims.test tid=5pZCxXDCocWoAvgFVghlRdwTpSw4klIp cseq=31965 INVITE 
contact=bob@df7jal23ls0d.invalid / 31965 from(wire)

Original issue reported on code.google.com by jorges...@gmail.com on 24 Nov 2012 at 4:35

GoogleCodeExporter commented 9 years ago 
The actual issue is really with the SIPml-api.js - the following code snippet 
from the function 

tsip_dialog.prototype.request_new = function(g)

processes the Service-Route array (stored earlier during registration) and 
generates "Service-Route" headers instead of "Route" headers - see corrected 
code snippet below

            if (this.e_state == tsip_dialog_state_e.INITIAL
                    || this.e_state == tsip_dialog_state_e.EARLY) {
                for ( var s = 0; s < q.ao_uri_service_routes.length; ++s) {
                    tsk_utils_log_info("adding service route header = " + q.ao_uri_service_routes[s]);
                    x.add_header(new tsip_header_Route(q.ao_uri_service_routes[s]))
                    //x.add_header(new tsip_header_Service_Route(q.ao_uri_service_routes[s]))
                }
            }

This generate the right originating INVITE for OpenIMSCore. However, if you 
have webrtc2sip as a gateway, that does correctly drop the proxy (P-CSCF) Route 
header but does NOT direct the INVITE to the P-CSCF - instead, it sends it to 
the S-CSCF (the next Route entry). Most likely this is a bug in webrtc2sip 
(still digging around....)

HTH

Original comment by Devasis....@gmail.com on 30 Sep 2013 at 9:07