Summary:	ASTERISK-07972: SDP information incorrect if canreinvite is globally undefined
Reporter:	Mathieu Rene (math)	Labels:
Date Opened:	2006-10-20 15:23:58	Date Closed:	2011-06-07 14:02:46
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I had a problem I couldnt hear audio as soon as an incoming sip calls gets answered by a phone, but when it was getting to voicemail everything was fine. rtp debug clearly showed there was no inbound RTP and a sip debug showed that the SDP message send to the sip provider contained the local ip address of my ip phone instead of the public IP address of asterisk. I have canreinvite=no in the sip.conf user entry, but not globally (even tough there was no re-invite going on as there was only one invite message at the beginning of the trace). As soon as I added canreinvite=no in the [general] section, the SDP message was corrected and everything worked perfectly.
Comments:	By: Anthony LaMantia (alamantia) 2006-10-20 17:07:33 Can you show the output of sip show peer on the peers involved? when you can canreinvite=no set for the peer and not  in the general section.. By: Mathieu Rene (math) 2006-10-21 00:49:37 [unrevealant entries truncated] vtl-gw*CLI> sip list peers Name/username              Host            Dyn Nat ACL Port     Status linksys-spa/linksys-spa    10.0.0.138       D   N      5060     Unmonitored pap2/pap2                  10.0.0.132       D   N      5060     Unmonitored 15 sip peers [Monitored: 1 online, 0 offline Unmonitored: 6 online, 8 offline] [lot of stuff truncated to fit mantis display] vtl-gw*CLI> sip list users Username          Def.Context      ACL  NAT linksys-spa         outgoing         No   Always pap2                   outgoing         No   Always 5145551155       pstn-incoming    No   RFC3581 The call is coming from SIP/5145551155 and is answered by SIP/pap2 By: Anthony LaMantia (alamantia) 2006-11-06 17:12:57.000-0600 i need  the output of "sip show peer" for each peer involved.. it also would be best if you attach the output as a textfile to this issue. By: Joshua C. Colp (jcolp) 2006-11-15 16:50:37.000-0600 1.4 and trunk have the capability to have media go directly between endpoints before the call is even established, it's called early bridging. By default canreinvite is assumed to be yes so what was happening is that the media stream was getting setup directly from the start as canreinvite was assumed to be yes. You might try the nonat option or as you discovered, the no option makes it work fine too. If you would like to see the default value of canreinvite changed you might try talking on the developer mailing list and listing the reasons, or talking to oej on IRC. Peace!