[Home]

Summary:ASTERISK-02055: SIP Re-invite still broken on some phones
Reporter:bfranks (bfranks)Labels:
Date Opened:2004-07-18 16:54:43Date Closed:2011-06-07 14:10:15
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) SIP_DEBUG.txt
( 1) sip.conf.txt
Description:SIP reinvite still does not work on some devices.  The Polycom IP phones do not seem to like the current method of invite.

There was a bug that was resolved earlier (see link below), but the code did not make it into the CVS.  Was the disclaimer ever received and if so, is there a reason why it was not included?

This was the original Bug and Patch:
http://bugs.digium.com/bug_view_page.php?bug_id=0000663

Thanks,

- Brent
Comments:By: Mark Spencer (markster) 2004-07-18 17:10:35

The patch in 663 is not relevant.  Are you SURE you're running cvs HEAD?  This bug smells extremely bogus.
By: bfranks (bfranks) 2004-07-18 18:49:14

Positive, I am running CVS as of yesterday.

Running a sniffer shows that the Polycom IP endpoints are still receiving UDP packets from our Asterisk box.  Reinvite fails.

- Brent
By: Mark Spencer (markster) 2004-07-18 20:15:09

You should post a trace of the session, and also where you feel Asterisk is in violation of RFC in its reinvite.
By: Mark Spencer (markster) 2004-07-18 20:17:58

And just to be sure -- you *do* know you can turn off reinvite on that phone with "canreinvite=no"...
By: bfranks (bfranks) 2004-07-18 21:18:10

Mark,

I will post a trace of the session tommorow when I get back into the office.  I am sorry to bring this up, if this is causing some sort of issue.  However, all I know is it doesn't work for me, regardless of what the RFC states.  If everything is in check with the RFC I will contact Polycom tommorow, and you can close the bug.  Believe me, I trust your judgement and if you think this is bogus, I'll be the first one to agree with you.  Also, please do not take this report as me critcizing.  That was/is not my intention at all by any means.

Finally, for each sip peer, canreinvite=yes.

- Brent
By: Mark Spencer (markster) 2004-07-18 21:59:45

If you don't spot an RFC violation, post it anyway, but importantly, send the trace to polycom -- they may be able to find what they dislike about it more quickly.

If you set "canreinvite=no" then it will allow your phone to operate by disabling the sending of reinvites.

Bugs like this do irritate me, but mainly because of my distaste for SIP's complexity which leads to situations like this.  Please don't take my at times unpleasant reactions to bugs personally -- I certainly don't take bugs as personal criticisms, I'm just hoping for a legitimate light at the end of the tunnel here somewhere.
By: bfranks (bfranks) 2004-07-18 22:12:20

Fair enough, thanks for the clairification.  Lord knows you have enough other things to worry about.

I'll gather more data and post Monday.  As per the phone operating, I have been using canreinvite=no since the inception of our project (January 12) and figured I would just try it again for the heck of it.  The phones were/are function using reinvite=no.  Additionally, they are functional with reinvite=yes, but from our end, it looks like the reinvite is sent, but the Polycom's don't change the media path as they should.

I'll gather some more conclusive info and forward on to Polycom.
(I sure hope Polycom dedicates someone to * development/integration, it seems like alot of people are using these phones)
By: Mark Spencer (markster) 2004-07-19 21:27:04

Any more information now?
By: bfranks (bfranks) 2004-07-19 22:18:11

Sorry, didn't get any traces today.

Today was very bad day in IT land, and didn't have chance to work on it.  Will get it Tuesday.
By: Mark Spencer (markster) 2004-07-20 18:53:47

Hate to pester, but did you get a chance to make those logs?
By: bfranks (bfranks) 2004-07-22 16:13:23

I have attached a SIP debug between two Polycom IP 500's.  A packet sniffer shows that the packets are still being sent to the * server and then to the phone.

- B
By: Mark Spencer (markster) 2004-07-22 19:37:20

This debug does not indicate a reinvite is being attempted.
By: bfranks (bfranks) 2004-07-22 20:32:23

I have uploaded by sip.conf.  Additionally, with the debug, I had only enabled canreinvite=yes on 2123 and 2124.

In my test, I called from 2124 to 2123 as you can see w/ the debug.
By: Mark Spencer (markster) 2004-07-22 20:36:51

I don't spot anything in your config that immediately looks wrong, but your debug clearly indicates no reINVITE being attempted.

I suggest you find someone on IRC that can help ou try to narrow this problem down.
By: bfranks (bfranks) 2004-07-22 20:40:46

Ok, back to the bogus part..

I just found some old posts, and not sure if this is still an issue or not, but from the posts it looks like it is.

In my extensions.conf I have t in my dial statement.

Sorry, if this is the cause?
By: Mark Spencer (markster) 2004-07-22 20:43:10

That is definitely it.  Using 't' requires us to be in the middle to see the digits.
By: bfranks (bfranks) 2004-07-22 20:53:00

Really sorry for the stupid oversight.

Looking at the sip.conf.sample shows that there is no transfer config option.

So basically there is no way to get transfer and reinvite's to work together?
By: Mark Spencer (markster) 2004-07-22 21:01:57

Nope