[asterisk-bugs] [JIRA] (ASTERISK-28287) Pjsip rewrite port in from/to headers on reply

Joshua C. Colp (JIRA) noreply at issues.asterisk.org
Wed Feb 13 08:14:47 CST 2019


     [ https://issues.asterisk.org/jira/browse/ASTERISK-28287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua C. Colp closed ASTERISK-28287.
-------------------------------------

    Resolution: Not A Bug

A helpful individual on the community forum pointed out that according to RFC3261 (19.1.1 and 19.1.2) a port is not allowed in To or From headers, so the parser likely doesn't store such information and strips them out instead.

> Pjsip rewrite port in from/to headers on reply
> ----------------------------------------------
>
>                 Key: ASTERISK-28287
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28287
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 16.0.0
>         Environment: CentOS Linux release 7.5.1804 (Core)
> Asterisk 16.0.0
> PJPROJECT version currently running against: 2.7.2
>            Reporter: Aleksandr Khomutov
>            Severity: Minor
>              Labels: pjsip
>
> Hello! I have problems configuring chan_pjsip. In response to requests from my softswitch, the asterisk rewrites the headers from and to the port, removes the port from there. Tell me how to make it so that the asterisk does not do this? This problem is not observed for the chan_sip driver.
> ```
> 2019/02/13 10:31:09.351381 85.12.217.3:5060 -> 10.227.228.4:5061
> INVITE sip:73432875561 at 10.227.228.4:5061;user=phone SIP/2.0
> Via: SIP/2.0/UDP 85.12.217.3:5060;rport;branch=z9hG4bK-8ae2b6262f5011e99bf22c44fd84c5e0;sig=35ee398c
> Via: SIP/2.0/UDP 85.12.217.3:5060;rport;branch=z9hG4bK-8ae2b0362f5011e99bf22c44fd84c5e0;sig=e4f91997
> Via: SIP/2.0/UDP 85.12.217.3:5062;rport=5062;branch=z9hG4bK-8ae293762f5011e99bf22c44fd84c5e0
> From: <sip:73432786060 at 85.12.217.3:5062;user=phone>;tag=8ae26efa2f5011e99bf22c44fd84c5e0
> To: <sip:73432875561 at 10.227.228.4:5061;user=phone>
> Call-ID: 8ae26f222f5011e99bf22c44fd84c5e0 at 85.12.217.3
> CSeq: 1 INVITE
> Contact: <sip:73432786060 at 85.12.217.3:5062;user=phone>
> Content-Type: application/sdp
> Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, REFER, REGISTER, UPDATE
> Max-Forwards: 69
> User-Agent: TS-v4.6.0-07a
> Cisco-Guid: 2329864784-793776617-2616339524-4253337056
> Content-Length:   312
> Record-Route: <sip:AQEAEOAgaLvZEqxL3Z9L9avyD5MDAAQ6GnBx at 85.12.217.3;lr>
> Record-Route: <sip:AQEAEEiS5FS8Xjpm4lEkLYOwprwDAARDhHft at 85.12.217.3;lr>
> v=0
> o=- 1550035858 1550035858 IN IP4 85.12.217.17
> s=-
> c=IN IP4 85.12.217.17
> t=0 0
> m=audio 27044 RTP/AVP 0 8 18 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=ptime:20
> a=sendrecv
> a=silenceSupp:off - - - -
> 2019/02/13 10:31:09.352290 10.227.228.4:5061 -> 85.12.217.3:5060
> SIP/2.0 401 Unauthorized
> Via: SIP/2.0/UDP 85.12.217.3:5060;rport=5060;received=85.12.217.3;branch=z9hG4bK-8ae2b6262f5011e99bf22c44fd84c5e0;sig=35ee398c
> Via: SIP/2.0/UDP 85.12.217.3:5060;rport;branch=z9hG4bK-8ae2b0362f5011e99bf22c44fd84c5e0;sig=e4f91997
> Via: SIP/2.0/UDP 85.12.217.3:5062;rport=5062;branch=z9hG4bK-8ae293762f5011e99bf22c44fd84c5e0
> Record-Route: <sip:AQEAEOAgaLvZEqxL3Z9L9avyD5MDAAQ6GnBx at 85.12.217.3;lr>
> Record-Route: <sip:AQEAEEiS5FS8Xjpm4lEkLYOwprwDAARDhHft at 85.12.217.3;lr>
> Call-ID: 8ae26f222f5011e99bf22c44fd84c5e0 at 85.12.217.3
> From: <sip:73432786060 at 85.12.217.3;user=phone>;tag=8ae26efa2f5011e99bf22c44fd84c5e0
> To: <sip:73432875561 at 10.227.228.4;user=phone>;tag=z9hG4bK-8ae2b6262f5011e99bf22c44fd84c5e0
> CSeq: 1 INVITE
> WWW-Authenticate: Digest  realm="centrex",nonce="1550035869/1ef0271eb3e86940bce3fc40fc143ef5",opaque="6f75f93b26037d9b",algorithm=md5,qop="auth"
> Server: centrex
> Content-Length:  0
> ```
> Full config:
> ```
> [global]
> type=global
> user_agent=centrex
> default_from_user=centrex
> default_realm=centrex
> [transport-udp]
> type=transport
> protocol=udp    ;udp,tcp,tls,ws,wss
> bind=0.0.0.0:5061
> [opensips-endpoint](!)
> type=endpoint
> send_pai=no
> send_rpid=no
> ;send_rpid=yes
> rpid_immediate=no
> trust_id_outbound=no
> trust_id_inbound=no
> context=from_opensips
> from_domain=sbc.profintel.ru
> sdp_session=Centrex v.1.0
> disallow=all
> allow=alaw
> allow=ulaw
> t38_udptl_maxdatagram=20
> t38_udptl=yes
> ;---nat
> rtp_symmetric=yes
> force_rport=yes
> rewrite_contact=yes
> [opensips-auth](!)
> type=auth
> auth_type=userpass
> realm=centrex
> [opensips-aor](!)
> type=aor
> max_contacts=1
> [opensips_sbc1](opensips-aor)
> [opensips_sbc1](opensips-auth)
> password=oemae8angoc4utoh2aeP
> username=opensips_sbc1
> [opensips_sbc1](opensips-endpoint)
> auth=opensips_sbc1
> aors=opensips_sbc1
> accountcode = opensips_sbc1
> [opensips_sbc2](opensips-aor)
> [opensips_sbc2](opensips-auth)
> password=oemae8angoc4utoh2aeP
> username=opensips_sbc2
> [opensips_sbc2](opensips-endpoint)
> auth=opensips_sbc2
> aors=opensips_sbc2
> accountcode = opensips_sbc2
> [opensips_sbc2]
> type=identify
> endpoint=opensips_sbc2
> match=10.227.228.18
> [opensips_sbc1]
> type=identify
> endpoint=opensips_sbc1
> match=10.227.228.169
> ```



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



More information about the asterisk-bugs mailing list