asterisk users - Jan 2008 - Packet2Packet bridging occurring when not wanted

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

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
>

On Jan 12, 2008 7:11 PM, Cameron Jenkins <milkman at the-milk-bar.com>
wrote:
>
> 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.
>
Seems like you are having a NAT issue. It would be nice if you posted
your exact network setup, what endpoints you are using and how they
are configured (including your SIP.conf) maybe someone could guide you
in the right direction if they knew what was going on.