Summary:	ASTERISK-02700: SIP hold/transfer fails
Reporter:	tjd (tjd)	Labels:
Date Opened:	2004-10-28 05:33:21	Date Closed:	2011-06-07 14:10:03
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) calleehold-110.txt ( 1) calleehold-111.txt ( 2) callerhold-110.txt ( 3) callerhold-111.txt ( 4) sip-hold.patch
Description:	SIP hold or transfer (INVITE with "a=sendonly") fails when authorisation is required. ****** ADDITIONAL INFORMATION ****** p->lastinvite isn't being recorded "proxy auth" sent.  The subsequent INVITE is treated as if it were unrelated, and a new SIP channel is opened instead of setting the current one to "sendonly".  See patch.
Comments:	By: Mark Spencer (markster) 2004-10-28 09:17:30 This patch is definitely not right, as it sts the lastinvite before a call is authenticated. Can you attach a debug of what happens and what you think should be happening? By: tjd (tjd) 2004-10-28 18:17:18 I have two tests.  In both, extension 110 (test) calls 111 (test2). - In the first test, 111 puts 110 on hold ("callee" files).  This works. - In the second test, 110 puts 111 on hold ("caller" files).  This doesn't work.  A "proxy auth" is required on this INVITE. The SIP logs are from the phones (SNOM 190s), and not Asterisk. By: Mark Spencer (markster) 2004-10-28 18:27:18 Just for future reference, the information in your bugnote, if placed in the original request, would have saved me a substantial amount of diagnostic time and investigation in the code.  In the future, please try to provide as much relevant information as possible about the bug as per the bug guidelines. By: Mark Spencer (markster) 2004-10-28 18:36:36 How about submitting the "sip debug" of a call setup with the transfer not working the way you believe it should.  Also how about setting "insecure=very" if you don't want authentication on the secondary invite. By: tjd (tjd) 2004-10-28 18:51:51 Sorry markster... Just confirm you want the *Asterisk* SIP debug.  Otherwise the "callee" files are the transaction that works, the "caller" files are the transaction that doesn't.  (ie. the hold works on one phone and not the other, depending who called). I also tried "insecure=very".  I saw this in the code, and it didn't fix the problem.  I didn't log it though. Also, I'm a little confused as to why there is a proxy auth required on the "hold" in the first place.  It happens when the caller sends an INVITE to put the callee on hold.  But the caller has already authenticated on the original call INVITE. Yet when the callee puts the caller on hold, it has never done a proxy auth and is never asked to.  And it works.  That seems backward to me. Either way, if a proxy auth is sent, the retransmission of the hold INVITE is treated as a new invite and opens up a new SIP channel. By: Olle Johansson (oej) 2004-11-09 01:32:13.000-0600 Still a problem? By: tjd (tjd) 2004-11-10 21:08:48.000-0600 Yep, still an issue.  The patch I did fixes the problem for the SNOM 190 but predictably breaks other SIP phones.  From what I can tell, the SNOM deals with the CSeq number a little differently.  I really need to read the SIP RFC to get up to speed.  Just need some time :-) And I don't have any SNOM 190s for testing anymore, which is why I stopped!  I'll have another couple in a week or so... By: Olle Johansson (oej) 2004-11-11 11:54:55.000-0600 I would like to see an Asterisk SIP debug of this transaction, so we can see how Asterisk treats the re-invite with the hold instruction. You need both "sip debug" turned on as well as "set debug 10" to get a reasonable amount of logging. Thank you. By: Olle Johansson (oej) 2004-11-11 14:33:23.000-0600 Reading the source, I can't find out how we handle re-invites in Asterisk. Seems like most INVITEs are treated as a new call. By: Olle Johansson (oej) 2004-11-14 10:07:26.000-0600 Testing with my SNOM 200, Asterisk can't handle a re-invite at all. It opens up a new call. We need to figure out what to do when putting a call on hold - should we simply park the call? By: Mark Spencer (markster) 2004-12-01 00:44:51.000-0600 Invites are not treated as a new call when lastinvite > 0.  Perhaps we can talk on IRC to straighten this out? By: Brian West (bkw918) 2004-12-04 01:45:28.000-0600 Some phones like the polycom drop the call and start a new call or so I have noticed. bkw By: Olle Johansson (oej) 2004-12-13 02:10:30.000-0600 This might be depending on pedantic setting... By: twisted (twisted) 2004-12-28 10:43:31.000-0600 tjd, did you contact markster on IRC to figure this out?  What's the status here?    Is this issue still an issue? By: tjd (tjd) 2004-12-31 03:44:36.000-0600 Nope, not yet.  I've been in hospital :-( I've just checked out Asterisk from CVS and will test in the next day or two (while I have a SNOM 190 lying around). By: tjd (tjd) 2005-01-01 01:32:28.000-0600 Looks good to me.  The hold and transfer works on the SNOM 190, and my Zyxel Wifi phone hasn't broken either! Case closed? By: twisted (twisted) 2005-01-01 01:34:48.000-0600 Glad to hear it's working.  Hope everything is okay with you, and, oh, btw, happy new year!