[asterisk-dev] [asterisk-users] Solved: Re: Asterisk 13.18.3 PJSIP. Wrong Port in Contact Header in Reply to REGISTER?

Joshua C. Colp jcolp at sangoma.com
Mon Jan 13 09:53:00 CST 2020


On Mon, Jan 13, 2020 at 11:49 AM Benoit Panizzon <benoit.panizzon at imp.ch>
wrote:

> Hi Joshua
>
> > Configuring individual PJSIP transports bound to the specific IP
> addresses
> > and then configuring the transport explicitly on things may do such a
> > thing.
>
> I believe this is what I have done.
>
> [transport-udp-vm]
> type=transport
> protocol=udp
> bind=157.161.10.32:5060
> tos=cs3
> cos=3
> allow_reload=yes
> symmetric_transport=yes
>
> [transport-udp-commerce]
> type=transport
> protocol=udp
> bind=157.161.10.98:5060
> tos=cs3
> cos=3
> allow_reload=yes
> symmetric_transport=yes
>
> [imp]
> type=endpoint
> transport=transport-udp-vm
> context=fromimp
> aors=imp
> disallow=all
> allow=g722
> allow=alaw
> tos_audio=ef
> tos_video=af41
> cos_audio=5
> cos_video=4
> tone_zone=ch
> language=de
> trust_id_inbound=no; sonst wird From aus PAI gebaut GNAH!!!!
> trust_id_outbound=yes
> send_pai=no
> send_rpid=no; NoGo, nicht RFC Konform
> send_diversion=yes
> 100rel=required
> t38_udptl=yes
> direct_media=no
> media_address=157.161.10.32
> bind_rtp_to_media_address=yes
> media_use_received_transport=yes
> user_eq_phone=yes
>
> [endpt-siptrunk](!)
> type=endpoint
> transport=transport-udp-commerce
> disallow=all
> allow=g722
> allow=alaw
> context=from-undefined ; # DEFINE in ENDPOINT
> allow_subscribe=yes
> mwi_subscribe_replaces_unsolicited=yes
> tos_audio=ef
> tos_video=af41
> cos_audio=5
> cos_video=4
> 100rel=required
> device_state_busy_at=2
> tone_zone=ch
> language=de
> user_eq_phone=yes
> send_pai=no ; PAI nicht senden.
> redirect_method=user
> send_diversion=yes
> media_encryption_optimistic=yes
> media_encryption=sdes
> identify_by=auth_username
> t38_udptl=yes
> user_eq_phone=yes
> direct_media=no
> rewrite_contact=yes
> media_address=157.161.10.98
> bind_rtp_to_media_address=yes
> media_use_received_transport=yes
> trust_id_inbound=yes ; darf unterdr├╝cken
> trust_id_outbound=no ; senden anonymous wenn privacy requested ist.
>
> Then a registering EP using this template:
>
> [4679-1003](endpt-siptrunk)
> auth=4679-1003
> aors=4679-1003
> context=from-pbx-trunk-local
>
> [4679-1003](auth-userpass-siptrunk)
> username=4679-1003
> password=*****
>
> [4679-1003](aor-single-siptrunk)
> ; keine overrides
>
> Now on a Call from Asterisk (source 157.161.10.98) to Registered
> Endpoint 4679-1003 (157.161.10.228) I see this exchange:
>
> 10.228 <=============> 10.98
>
> => Invite + SDP from 10.228
> <= 180 Ringing, Via: 10.228;received=10.228 Contact:<sip:
> 157.161.10.32:5060>
> So here I have the WRONG ip in the Contact header.
>
> Now 10.228 ist sending it's PRACK to 10.32 which is intentionally
> blocked on the firewall, to test this scenario. The PRACK is resent
> until the 30sec timer expires.
>
> Any idea on how to solve this issue?
>

Is the network the same on both interfaces? Your IP address bind makes it
seem as so. How does the routing of the packets on the system actually work
for the interfaces? Otherwise without digging deeply into things, nothing
else comes to mind.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200113/01502a4f/attachment.html>


More information about the asterisk-dev mailing list