[asterisk-users] Packet2Packet bridging occurring when not wanted

[Andrew Joakimsen]

Packet2Packet has nothing to do with re-invite (well I guess if you
reinvite the RTP stream you can't use Packet2Packet on that box).

What Packet2Packet means is the RTP handler in Asterisk receives a
packet from say a SIP softphone and then sends that exact packet to
the SIP or IAX provider the call is going to without any additional
processing. This reduces the memory and CPU usage of Asterisk. See in
your own logs:

#
#
Sent RTP P2P packet to 210.8.38.129:13312 (type 08, len 000160)
#
Sent RTP P2P packet to 10.0.0.20:32120 (type 00, len 000160)
#
Sent RTP P2P packet to 210.8.38.129:13312 (type 08, len 000160)
#
Sent RTP P2P packet to 10.0.0.20:32120 (type 00, len 000160)
#
Sent RTP P2P packet to 210.8.38.129:13312 (type 08, len 000160)
#
Sent RTP P2P packet to 10.0.0.20:32120 (type 00, len 000160)
#
supermarket*CLI>


On Jan 12, 2008 7:11 PM, Cameron Jenkins <milkman at the-milk-bar.com> wrote:
> Hi,
>
> I have Asterisk set up on Fedora with a single SIP trunk, with a few
> handsets configured. The Asterisk box has both public and private
> addressing, so "canreinvite=no" is set on both the SIP trunk and handset
> configurations so I can get around the nasty NAT issues.
>
> One odd behaviour I am seeing is certain destinations are resulting in
> different SIP codes being sent back to Asterisk, which then initiates
> unwanted Packet2Packet bridging.
>
> http://www.pastebin.ca/849961 <--- Working call. Line 280 shows a "SIP/2.0
> 183 Session Progress" and the RTP stream works as intended. I hung the call
> up before being answered in case you were wondering where the answer part of
> the debug occurs
>
> http://www.pastebin.ca/849965 <--- Non-working call. Line 235 shows a
> "SIP/2.0 180 Ringing", and for some odd reason, Packet2Packet bridging is
> initiated despite "canreinvite=no" being set.
>
> This in turn causes me some one way audio behaviour, and I've got no idea
> how to fix it. Anyone able to offer any suggestions.
>
> Regards,
> Cameron Jenkins
>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>