Domain name of TO field in invite header set to .invalid
wackazong opened this issue · 2 comments
It appears to me that OverSIP is handling this INVITE incorrectly. Can you please comment?
Architecture: sipML5 client -> OverSIP -> OpenSips Edge Proxy -> OpenSips Serving Server. Both clients are sipML5. OverSIP and the OpenSIPS edge proxy are on the same machine on Amayzon EC2.
From client (sipML5):
SEND: INVITE sip:sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKZ7xzRhqrshtFG2ItFiFuTVFaXe74V4Sz;rport
From: "calling_sq4ZYs1y5Ijlg3dkABeBR"<sip:calling_sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com>;tag=5Uxx2Lk3Wz6o6BdyNU0l
To: <sip:sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com>
Contact: "calling_sq4ZYs1y5Ijlg3dkABeBR"<sips:calling_sq4ZYs1y5Ijlg3dkABeBR@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=wss>;+sip.instance="<urn:uuid:0c9b080a-68d9-4f6e-a76c-250301e864f0>";+sip.ice;language="en"
Call-ID: d58a8f4d-d179-c1f6-f6aa-f468463fd785
CSeq: 58613 INVITE
Content-Type: application/sdp
Content-Length: 3641
Max-Forwards: 70
P-Group-Id: GLFw8cI9BRXAbHjG:Group 1
P-Expert-Profile-Id: gWwftSyHlHcPgABj:Group 1
P-Reverse-Charging: 0
P-Campaign-Id: none
P-Embed-Url: https://staging.headstore.com/caller/?version=1.5.0-rc3-0-ccb2b9e&id=GLFw8cI9BRXAbHjG&CAMPAIGN_ID=none&useWebRTC=1
P-Client-Id: IM-client/OMA1.0 sipML5-v1.2014.04.18
P-Encrypted-Rate: c7feb662ad2501c9cf4d72f045cac0e19110de68556f6a46a06dd0bd0910dfbf527c4baf96e9f371c9d61959a968b7dabde081d21c2ff20330cab506dd01656e
P-NoCallerVideo: false
P-Call-Api-Customdata: [none]
User-Agent: IM-client/OMA1.0 sipML5-v1.2014.04.18
OverSIP log:
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <WsSipApp> received WS message: type=text, length=4938
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: INFO: <SipEvents> [user] INVITE (( )) from sip:calling_sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com (UA: IM-client/OMA1.0
sipML5-v1.2014.04.18) to sip:sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com via WSS 172.31.41.198 : 15797
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <SIP Request DAwNs4FWfbBowWk6mr5nVisc8ZO65LMO> applying outgoing Outbound support
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <UserAssertion module> user asserted, adding P-Asserted-Identity for SIP Request DAwNs4FWfbBowWk6mr5nVisc8ZO65LMO
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <SIP Request DAwNs4FWfbBowWk6mr5nVisc8ZO65LMO> replying 100 "Trying"
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <WsFraming> sending text frame: payload_length=405
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <Proxy proxy_out DAwNs4FWfbBowWk6mr5nVisc8ZO65LMO> destination found in the DNS cache
May 19 09:26:01 ip-172-31-38-164 oversip[12049]: DEBUG: <Proxy proxy_out DAwNs4FWfbBowWk6mr5nVisc8ZO65LMO> trying single target: udp:54.194.12.167:5060
May 19 09:26:02 ip-172-31-38-164 oversip[12049]: INFO: <SipEvents> [user] INVITE (( [<sip:54.194.12.167:5080;transport=udp;lr;ovid=355a47e6>, <sip:2e60ea402d@staging.sipheads
tore.com:10443;transport=wss;lr;ovid=355a47e6;ob>] )) from sip:calling_sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com (UA: OpenSIPS (1.9.1-tls (x86_64/linux))) to sips:sq4ZYs1y
5Ijlg3dkABeBR@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=wss;ov-ob=2e60ea402d via UDP 54.194.12.167 : 5060
May 19 09:26:02 ip-172-31-38-164 oversip[12049]: DEBUG: <SIP Request 4257.2cbe115.0> destination is an incoming Outbound connection
May 19 09:26:02 ip-172-31-38-164 oversip[12049]: INFO: <SipEvents> [user] routing initial request to an Outbound client
May 19 09:26:02 ip-172-31-38-164 oversip[12049]: DEBUG: <SIP Request 4257.2cbe115.0> replying 100 "Trying"
It appears to me that OverSIP changes the TO: header from sip:sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.comto sips:sq4ZYs1y5Ijlg3dkABeBR@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=wss;ov-ob=2e60ea402d
The INVITE is then forwarded to the EDGE server of our SIP network running OpenSIPS, and there we get problems:
May 19 09:26:01 ip-172-31-38-164 HEADSTORE-EDGE[31425]: [54.194.12.167:5080] --[INVITE:b5a80fdb-9a64-b9c6-67a1-f52ee7ec7b57]--> [sip:172.31.32.227:5070]
May 19 09:26:01 ip-172-31-38-164 HEADSTORE-EDGE[31430]: --[OPTIONS:690c1210025daab8-31430@172.31.38.164]--> [sip:172.31.32.228:5070]
May 19 09:26:02 ip-172-31-38-164 HEADSTORE-EDGE[31420]: [SIP/2.0/UDP 54.194.12.167:5080;received=54.194.12.167;branch=z9hG4bK3b7344ab0ffe7fadc146c867ca32ebfe5687d452;rport=5080
] <--[100 - Trying:b5a80fdb-9a64-b9c6-67a1-f52ee7ec7b57]-- [172.31.32.227:5070]
May 19 09:26:02 ip-172-31-38-164 HEADSTORE-EDGE[31422]: Attempt to route with preloaded Route's [sip:calling_sq4ZYs1y5Ijlg3dkABeBR@staging.sipheadstore.com/sip:sq4ZYs1y5Ijlg3dk
ABeBR@df7jal23ls0d.invalid/sips:sq4ZYs1y5Ijlg3dkABeBR@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=wss;ov-ob=2e60ea402d/B2B.199.1666148]
Thanks for any advice.
The underlying problem is that the BYE at the end of the call does not get forwarded to the callee if the caller ends the connection. It seems to me that the initial culprit is the df7jal23ls0d.invalid domain in the to: header.
OverSIP does not rewrite the To header (unless you do that in the server.rb script). A SIP trace of the incoming SIP request and the outgoing SIP request would be very useful.
However, please use the OverSIP public mailing list for these kind of question/issues.
Ok, thanks.