[asterisk-bugs] [JIRA] (ASTERISK-23613) Endpoint identification fails when user part of From header SIP-URI contains a tel URI style parameter

Fri Jun 6 14:00:57 CDT 2014

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219144#comment-219144 ] 

Per Jensen commented on ASTERISK-23613:
---------------------------------------

I have a similar issue except that I'm getting 404's even though I have a proper context that matches.  I never get to the default context, just the 404 sent back.  My setup however, its openSIPS sending a probe via an OPTIONS packet.  

Here are the relevant lines that should explain my current plight.  

Asterisk CLI 
{noformat}
CLI output
<--- Received SIP request (421 bytes) from UDP:172.31.12.252:5060 --->
OPTIONS sip:ADDRESS(censored for security reasons) SIP/2.0
Via: SIP/2.0/UDP ADDRESS(removed for security reasons):5060;branch=z9hG4bKa1b.1fb55715.0
To: ADDRESS(censored for security reasons)
From: <sip:prober at localhost>;tag=bfb847842ed8d831146951d66a19ae48-7366
CSeq: 10 OPTIONS
Call-ID: 1fbca1b21c80bd4f-6112 at ADDRESS(censored for security reasons)
Max-Forwards: 70
Content-Length: 0
User-Agent: OpenSIPS (1.11.1-tls (x86_64/linux))

[Jun  6 17:11:31] DEBUG[29433]: res_pjsip_endpoint_identifier_ip.c:128 ip_identify: No identify sections to match against
[Jun  6 17:11:31] DEBUG[29433]: res_pjsip_endpoint_identifier_user.c:104 username_identify: Retrieved endpoint prober
<--- Transmitting SIP response (792 bytes) to UDP:ADDRESS(censored for security reasons):5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP ADDRESS(censored for security reasons):5060;rport;received=172.31.12.252;branch=z9hG4bKa1b.1fb55715.0
Call-ID: 1fbca1b21c80bd4f-6112 at 172.31.12.252
From: <sip:prober at localhost>;tag=bfb847842ed8d831146951d66a19ae48-7366
To: <sip:ADDRESS(censored for security reasons)>;tag=z9hG4bKa1b.1fb55715.0
CSeq: 10 OPTIONS
Accept: application/sdp, application/pidf+xml, application/simple-message-summary, application/xpidf+xml, application/cpim-pidf+xml, application/simple-message-summary, application/pidf+xml, message/sipfrag;version=2.0
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER, REGISTER
Supported: 100rel, timer, replaces, norefersub
Accept-Encoding: text/plain
Accept-Language: en
Content-Length:  0
{noformat}

pjsip.conf
 {noformat}
[prober]
type=endpoint
transport=simpletrans
context=default
allow=all
;dtmf_mode=auto
direct_media=no
rtp_symmetric=yes
identify_by=username

[prober]
type=identify
username=prober
{noformat}

extensions.conf
{noformat}
[default]
exten => _.,1,Hangup()
{noformat}

> Endpoint identification fails when user part of From header SIP-URI contains a tel URI style parameter
> ------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23613
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23613
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 12.1.0, 12.2.0
>         Environment: CentOS release 5.4 (Final)
>            Reporter: yaron nahum
>
> I have an Asterisk 12 with PJSIP configured working againt a Comverse (NetCentrex) Switch. The Comverse switch sends periodically Session Keep-Alive every 200 seconds using OPTIONS method.
> The asterisk is not responding to the Keep alive therefore the call is disconnected.
> Below is the debug taken from the server:
> {noformat}
> ##############################3
> [Apr 10 16:16:40] DEBUG[13801] pjsip:   sip_endpoint.c Processing incoming message: Request msg OPTIONS/cseq=2 (rdata0xa5b03b4)
> [Apr 10 16:16:40] VERBOSE[13801] res_pjsip_logger.c: <--- Received SIP request (393 bytes) from UDP:172.16.60.160:5080 --->
> OPTIONS sip:172.16.60.160:5061;transport=UDP SIP/2.0^M
> Via: SIP/2.0/UDP 172.16.60.160:5080^M
> From: <sip:39919002;cpc=ordinary at 172.16.60.160:5080;user=phone>;tag=1^M
> To: <sip:039988120 at 172.16.60.160:5060>;tag=9d105b31-3396-4aa5-afe3-c519ee8b5db2^M
> Call-ID: 1-17908 at 172.16.60.160^M
> Cseq: 2 OPTIONS^M
> Contact: sip:39919002 at 172.16.60.160:5080^M
> Max-Forwards: 60^M
> Subject: Simulator^M
> Content-Length: 0^M
> ^M
> [Apr 10 16:16:40] DEBUG[17772] pjsip:   sip_endpoint.c Distributing rdata to modules: Request msg OPTIONS/cseq=2 (rdata0xb411493c)
> [Apr 10 16:16:40] DEBUG[17772] pjsip:    dlg0xb4111eb4 .Received Request msg OPTIONS/cseq=2 (rdata0xb411493c)
> [Apr 10 16:16:40] DEBUG[17772] pjsip:    tsx0xb7d74764 ...Transaction created for Request msg OPTIONS/cseq=2 (rdata0xb411493c)
> [Apr 10 16:16:40] DEBUG[17772] pjsip:    tsx0xb7d74764 ..Incoming Request msg OPTIONS/cseq=2 (rdata0xb411493c) in state Null
> [Apr 10 16:16:40] DEBUG[17772] pjsip:    tsx0xb7d74764 ...State changed from Null to Trying, event=RX_MSG
> [Apr 10 16:16:40] DEBUG[17772] pjsip:    dlg0xb4111eb4 ....Transaction tsx0xb7d74764 state changed to Trying
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: Function session_inv_on_tsx_state_changed called on event TSX_STATE
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: The state change pertains to the session with sipp
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: The inv session does NOT have an invite_tsx
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: The transaction involved in this state change is 0xb7d74764
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: The current transaction state is Trying
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: The transaction state change event is RX_MSG
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: The current inv state is CONFIRMED
> [Apr 10 16:16:40] DEBUG[17772] res_pjsip_session.c: Method is OPTIONS
> {noformat}

--
This message was sent by Atlassian JIRA
(v6.2#6252)